Информация о файле обновления Галактика F_PLPOR_RES_911440.TXT


Описание файла обновления:
ФайлF_PLPOR_RES_911440.TXT
ОбновлениеF_PlPor_RES_911440
Назначение
ПродуктГалактика ERP 9.1
Релиз
КомпонентRES F_PlPor
Тип
Версия9.1.144.0
Дата2019-10-29 23:44:01
Проблема ПИРПервое решениеОписаниеПроектДетализация
Что изменено:Как изменено:
NEWГалактика ERP Финконтур ФРО Документы Платежное поручение
<ФРО-Документы-Платежное поручение> Добавлено: -настройка "Настройки Галактики Бухгалтерский контур Обработка документов Разрешить модификацию внешних атрибутов при наличии проводок"; -запрет редактирования внешних атрибутов платежных поручений при наличии сформированных проводок.Доработка существующего функционала.
180.10933 * ЗАДАЧА В JIRA: ERP-810NEWФРО Документы Платежные поручения Сторонние
Добавить пользовательскую настройку "Запрет возврата хозяйственных операций разнесенных по ДО" со значениями "да"/"нет" и значением по умолчанию "нет".Добавлена настройка : Бухгалтерский контур - Обработка документов - Распределение платежа по ДО-"Запрет возврата хозяйственных операций разнесенных по ДО". Если настройка установлена в значение нет - работает как и раньше. Если установлена в значение "Да": - Если сумма частично распределена по ДО, то по запросу можно сформировать возврат на нераспределенную сумму. - Если сумма полностью распределена, то возврат не возможен.
9.1.143.0Касса > Документы > Приходный кассовый ордер
Подключить help-константу Kassa_KORegKKT к кнопке "Регистрация в ККТ" и окну "Регистрация в ККТ" (ко всем элементам окна и локальным функциям, вызываемым из данного окна).Подключена help-константа Kassa_KORegKKT к кнопке "Регистрация в ККТ" и окну "Регистрация в ККТ" (ко всем элементам окна и локальным функциям, вызываемым из данного окна). Убраны не несущие смысл подсказки с таблиц.
9.1.142.0Нет
Новая версия накопительного обновления словаря Галактика ERP 9.1 Alter_CumulativeВнесены изменения в словарь БД Галактики ERP 9.1
9.1.142.0Галактика ERP Финконтур ФРО Операции Реестры по перечислениям
Галактика ERP Финконтур ФРО Операции Реестры по перечислениям 1. Необходимо снять контроль в случае наличия ПП без даты оплаты. 2. Необходимо изменить подход к блокировке спецификации. Статус строка должна оставаться той же, а действия блокироваться в случае отсутствия доступа.Галактика ERP Финконтур ФРО Операции Реестры по перечислениям 1. Снят контроль в случае наличия ПП без даты оплаты. 2. Изменен подход к блокировке спецификации. Статус строка более не меняется из-за отсутствия доступа, блокируются сами действия (добавление/удаление).
9.1.141.0ФРО Документы Платежные поручения
Необходимо возможность контролировать центры-ответственности у документа-основания и платежа при ручной привязке.Добавлена системная настройка "Настройки Галактики Бухгалтерский контур Обработка документов Распределение платежа по ДО Проверять совпадение ЦО при распределении платежа по ДО". Настройка имеет 3 варианта значения ("нет", "да", "по запросу"). * При значении "нет" (по умолчанию) контроль отсутствует. * При значении "да", при ручном выборе ДО в платеже срабатывает контроль на совпадени ЦО. Если ЦО у ДО и платежа не совпадают, платеж по данному ДО не будет распределен. После проверки всех ДО, если по каким-то из ДО платеж не был распределен, будет выведено сообщение "Платеж был распределен не по всем ДО из-за несоответствия центров ответственности!". * При значении "по запросу", при несовпадении ЦО у ДО и платежа будет выведено предупреждение "Центр ответственности документа-основания № ХХХХ не соответствует центру ответственности платежа! Распределить?". Фокус на кнопке "нет". При ответе "да" платеж распределится, при ответе "нет" не распределится. В случае, если ЦО у всех выбранных ДО не совпал с платежом, выведется сообщение "Платеж не распределен из-за несоответствия центров ответственности!".
101.67166 * ЗАДАЧА В JIRA: ERP-1039.1.140.0Галактика ERP Финконтур ФРО Операции Реестры по перечислениям
ФРО - Операции - Реестры по перечислениям. Для реестров на перечисление подотчётных сумм (префикс KRPS), по которым сформировано платёжное поручение, необходимо запретить любые изменения, предполагающие изменение в платёжках (изменение реквизитов для перечисления в шапке, изменение/добавление/удаление сотрудников в спецификации, корректировку сумм).Или можно запретить вообще любые изменения, если так проще. С выдачей сообщения, например, аналогично как при попытке редактирования зарплатных реестров:"По данному реестру сформировано платёжное поручение. Редактирование реестра запрещено."Финансово-расчетные операции | Операции | Реестры по перечислениям Контроль в реестрах "KRPS". Если есть платежное поручение, редактирование/удаление реестра блокируется. Сообщения о блокировке: - "По реестру сформировано платежное поручение. Редактировать реестр запрещено.", - "По реестру сформировано и оплачено платежное поручение. Редактировать реестр запрещено.", - "По реестру сформировано платежное поручение, которое закрыто для редактирования. Редактировать реестр запрещено.".
9.1.139.0Галактика ERP Финконтур Касса
в случае если после создания и распределения в возвратных РД по ДО/ДО на предоплату без рекламационных накладных данные документы будут удалены, то вместе с удалением должно быть восстановлено распределение по позициям ДО в исходном ПДРаспреденение восстанавливается.
180.10804 * ЗАДАЧА В JIRA: ERP-4059.1.138.0Галактика ERP Финконтур Касса
Если получен аванс и по нему не было реализации либо реализовано не на всю сумму аванса, то сумма аванса (части аванса) подлежит возврату. В настоящий момент в документах, созданных при использовании функционала «Формирование возврата платежа», не осуществляется распределение платежа по ДО/ДО на предоплату, если не оформлена рекламационная накладная. Требуется возможность распределять во возвратных кассовых/банковских платежах по ДО/ДО на предоплату без рекламационных накладных и формировать чек в ККТ.При формировании возврата платежа, в окно выбора типа возвращаемого документа добавлена возможность ввода даты обработки возвратного платежа. Если дата возвратного платежа не установлена, то разнесение по ДО отрабатывать не будет.
9.1.137.0Галактика ERP Финконтур Касса Документы Приходный кассовый ордер
Регистрация в ККТ. В случае, если способ расчета аванс/предоплата/предоплата 100%/оплата кредита, предмет расчета должен автоматически установиться "Платеж".Регистрация в ККТ. В случае, если способ расчета аванс/предоплата/предоплата 100%/оплата кредита предмет расчета автоматически устанавливается "Платеж".
101.67743 * ЗАДАЧА В JIRA: ERP-7039.1.137.0Галактика ERP Финконтур ФРО Документы Входящие документы
Регистрация в ККТ. Необходимо: 1. Реализовать корректную регистрацию в ККТ платежа, содержащего одновременно и оплату по факту, и предоплату - всех его позиций. 2. Контролировать "Сумму по чеку предоплатой" суммой "Итого к оплате". Сумма предоплаты не должна превышать итога по чеку. 3. Наследовать признак регистрации ККТ в распределении по позициям ДО при множественном дроблении хозоперации в случае наличия ссылки на вышестоящий ДО на предоплату - это необходимо для корректного учёта предоплаты при регистрации последующих отгрузок. 4. Устанавливать в платёжный документ окончательный статус с кодом 4 (зарегистрирован в ККТ) только после регистрации последней операции на отгрузку.Регистрациия в ККТ. 1. Реализована возможность одновременной регистрации по ХО в которых есть накладные и в которых нет. В случае отсутствия накладных, используется распределение по ДО. 2. Суммы предоплаты в чеке контролируются суммой итого. Сумма предоплаты не превышает итого по чеку. 3. Наследуется признак регистрации ККТ при дроблении ХО при условии наличия ссылки на вышестоящее ДО на пердоплату. 4. Статус "зарегистрировано" устанавливается только после регистрации последней операции на отгрузку. Проверка осуществляется по суммы документа и суммам распределения по накладным. Если суммы распределения по накладным равны сумме по документу, считается, что произведена полная отгрузка.
101.67742 * ЗАДАЧА В JIRA: ERP-7019.1.136.0Галактика ERP Финконтур Касса Документы Авансовый отчет
При включении настройки Бухгалтерский контур - Обработка документов - Значения полей по умолчанию - Кассовые ордера - Подставлять сотрудника в АО из настройки "Общие настройки системыТабельный номер"=да не добавляется запись в авансовых ордерах.Исправлен порядок обработки заполнения полей PlPor.cPersons, PlPor.cLschet, PLPOR.PODOTCHET
101.676369.1.135.0предупреждение в собственном платежном порученииФинансово-расчетные операцииПлатежное поручение
предупреждение в собственном платежном поручении Предупреждение на базе SQL, на базе Pervasive предупреждение не появляется. Собственное платежное поручение сформировано из ФОБ (Платежный календарь - Документы - Журнал обязательств). При внесении даты оплаты (или заполнения любого другого поля) система выдает предупреждение.Проблема возникала при включении настройки Doc.DolgKontr не в 0. Погашены лишние ссылки на объект L_KatOrg::KatOrg.
101.674039.1.134.0Недопустимые символы в налоговых реквизитах платежного порученияФинансово-расчетные операцииПлатежное поручение
Недопустимые символы в налоговых реквизитах платежного поручения. Если пользователь вводит 0 в поле "Период" налоговых реквизитов ПП, то в поле "Назначение платежа" попадают некорректные символы. Из-за этого у клиента зависает обработка выгрузки таких платежных поручений в корпоративной шине КСДД/КСИИС. Подробное описание проблемы в приложенном файле в Jira ERP-212. Здесь не получилось добавить файл.При собирании строки PlPor.Tax идет проверка для поля sNalPeriod на наличие символов с кодом 254, и если такой есть , то в PlPor.Ta идет "".
101.676189.1.133.0Платежное Поручение не привязывается сотрудник в расширенной информацииФинансово-расчетные операцииПлатежное поручение
Платежное Поручение не привязывается сотрудник в расширенной информации Когда пользователь выбирает сотрудника, то все вроде отображается нормально, но когда он закрывает документ, данное поле не сохраняется в базе данных. Пол журналу не создаются записи таблиц DOCPODOTCHET, PODOTCHET. Только когда явно сделать перевыбор значения "Участвует" в из списка поля "Расчеты с подотчетными лицами", то запись сохраняется.ФРО - Документы - Платежные поручения - Собственные. При выборе сотрудника в дополнительной информации производится автоматическое сохранение.
102.1835139.1.131.0Нужна важная доработка ключа VZBASEDOCХозоперацииТиповые алгоритмы и константы
Нужна важная доработка ключа VZBASEDOC Ключ не анализирует распределение документа по акту взаимозачета.В идентификатор VzBaseDoc добавлен параметр "Сумма оплаченных позиций", который работает при установке параметра "Заполнить аналитику С/Ф" в значение "Авто с разбивкой по С/Ф". При этом для зачета будет браться не сумма С/Ф, а сумма оплаченных позиций
101.669119.1.131.0Формирование хоз.операций по спецификации не проверяет корректность ссылки на хоз.операцииКассаАвансовый отчет
Формирование хоз.операций по спецификации не проверяет корректность ссылки на хоз.операции Клиент просит добавить проверку корректности ссылок на хозоперацию в Авансовом Отчете. Скриншоты и описание ситуации - во вложении. Предложенный вариант воспользоваться функцией: "Настройка Администратор Проверка целостности таблиц Контроль целостности таблиц КБУ" Клиенту не подходит.При выполнении копирования авансового отчета, в случае когда копируется спецификация и не копируются хозяйственные операции, в позициях спецификации выполняется сброс ссылок не только на хозоперацию связанную с спецификацией, но и на хозоперацию на превышение. При выполнении синхронизации позиции спецификации АО или выполнении формирования хозяйственных операций по позициям спецификации, перед удалением связанной ХО выполняется проверка на то что связанная ХО относится к текущему АО и если она не относится, то удаление ХО не выполняется, а ссылка на нее сбрасывается. Таки образом в результате будет разорвана связь с некорректной ХО и будет сформирована новая ХО в текущем АО, с которой и будет установлена связь.
102.1990039.1.130.0возникает ошибка "переход не возможен, т.к. текущий документ не заполнен"КассаАвансовый отчет
После решения проблемы, зарегистрированной в ПИР 102.195752, возникла другая ошибка при заполненной настройке "Настройки Галактики Общие настройки системы Табельный номер". Если в новом авансовом отчете (заполнено ФИО, сумма=0) попытаться заполнить спецификацию возникает ошибка "переход не возможен,т.к. текущий документ не заполнен".исправлено
102.1980289.1.130.0Фиксирование ставки НДС при разбивании платежа на хозоперацииФинансово-расчетные операцииПлатежное поручение
Фиксирование ставки НДС при разбивании платежа на хозоперации Есть предоплата прошлого года с налогом 18%. Привязываем ДО текущего года с налогом 20%. Сумма по ДО меньше предоплаты. При привязке ДО появляется сообщение: "Платежный документ №... и ДО №... относятся к периодам действия различных ставок НДС! Зафиксировать налоги в платежном документе?" При ответе "да" фиксируется не только ставка НДС 18%, но и сумма, которая равна всему налогу с предоплаты. В данном случае требуется фиксировать только ставку 18%, а сумму пересчитывать по этой ставке от суммы хозоперации.Переработан алгоритм привязки ДО к платежным документам. Описание существующего алгоритма при привязке одного ДО к хозяйственной операции документа: 1. Сумма текущей хозоперации уменьшается до суммы задолженности по ДО. 2. Запускается обработка накладных и если включено дробление хозяйственных хозопераций в разрезе накладных, то текущая хозоперация уменьшается до суммы первой накладной, а для всех остальных накладных формируются новые хозоперации. 3. Если включена обработка суммовых разниц, то формируются хозоперации по суммовым разницам. 4. Запускается контроль соответсвия сумм хозопераций и документа и на разницу либо формируется новая хозоперация, либо уменьшается сумма документа. Описание существующего алгоритма при привязки нескольких ДО к хозяйственной операции документа: 1. Сумма текущей хозоперации уменьшается до суммы задолженности по первому ДО. 2. Запускается обработка накладных и если включено дробление хозяйственных хозопераций в разрезе накладных, то текущая хозоперация уменьшается до суммы первой накладной, а для всех остальных накладных формируются новые хозоперации. 3. Если включена обработка суммовых разниц, то формируются хозоперации по суммовым разницам. 4. Для всех последующих ДО формируется новая хозоперация на сумму задолженности по ДО (ведется контроль по не превышению суммы платежа). 5. Для каждого ДО выполняется пункт 2 и 3. 6. Запускается контроль соответсвия сумм хозопераций и документа и на разницу либо формируется новая хозоперация, либо уменьшается сумма документа. Алгоритм работы одинаковый как при привязке ДО из шапки платежного документа, так и при привязке в хозяйственной операции. Недостатки данного алгоритма в том, что при создании новых хозопераций (на остаток, или при привязке нескольких ДО), хозоперации не наследуют некоторые атрибуты исходной хозоперации (внешние атрибуты, вид платежа, аналитику). Переработан алгоритм привязки ДО и теперь он основывается на механизме дробления хозоперации. Описание нового алгоритма привязки одного ДО к хозяйственной операции. 1. Текущая хозоперация дробиться на две. Исходная хозоперация становится на сумму задолженности по ДО, а остаток на сумму разницы между исходной ХО и суммой задолженности по ДО. 2. К текущей хозоперации привязывается ДО. 3. Запускается обработка накладных и если включено дробление хозяйственных хозопераций в разрезе накладных, то текущая хозоперация уменьшается до суммы первой накладной, а для всех остальных накладных формируются новые хозоперации. 4. Если включена обработка суммовых разниц, то формируются хозоперации по суммовым разницам. Описание нового алгоритма привязки нескольких ДО к хозяйственной операции. 1. Текущая хозоперация дробиться на две. Исходная хозоперация становится на сумму задолженности по первому ДО, а остаток на сумму разницы между исходной ХО и суммой задолженности по первому ДО. 2. К текущей хозоперации привязывается ДО. 3. Запускается обработка накладных и если включено дробление хозяйственных хозопераций в разрезе накладных, то текущая хозоперация уменьшается до суммы первой накладной, а для всех остальных накладных формируются новые хозоперации. 4. Если включена обработка суммовых разниц, то формируются хозоперации по суммовым разницам. 5. Остаток становится текущей хозоперацией и к ней привязывается следующее ДО по алгоритму описанному в пунктах 1-4. 6. Пункт 5 повторяется до тех пор пока либо не закончится свободная сумма по хозоперации, либо пока не будут обработаны все ДО. Описание нового алгоритма привязки нескольких ДО к нескольким хозяйственным операции. 1. На закладке ХозОперации помечаются хозоперации к которым необходимо привязать ДО. 2. Выбор ДО необходимо выполнять с закладки ХозОперации. 3. К первой выбранной хозоперации привязывается первое выбранное ДО если сумма задолженности по ДО превышает сумму ХО, в противном случае выполняется дробление хозоперации на две. Исходная хозоперация становится на сумму задолженности по ДО, а остаток на сумму разницы между исходной ХО и суммой задолженности по ДО. 4. К текущей хозоперации привязывается ДО. 5. Запускается обработка накладных и если включено дробление хозяйственных хозопераций в разрезе накладных, то текущая хозоперация уменьшается до суммы первой накладной, а для всех остальных накладных формируются новые хозоперации. 6. Если включена обработка суммовых разниц, то формируются хозоперации по суммовым разницам. 7. Остаток становится текущей хозоперацией и выполняются пункты 3-6 до тех пор как не закончится свободная сумма по хозоперации. 8. Если сумма по хозоперации закончилась, то переходим к следующей хозоперации и выполняем для нее пункты 3-7. 9. Разноска заканчивается либо когда обработаны все хозоперации, либо когда будут привязаны все ДО. Описание нового алгоритма привязки одного или нескольких ДО в шапке платежного документа. 1. Выбор одного или нескольких ДО из шапки платежного документа. 2. Происходит автоматическая пометка всех не разнесенных по ДО хозяйственных операций. 3. Выполняется алгоритм привязки одного или нескольких ДО к помеченным хозоперациям. На каждой итерации дробления хозоперации происходит дробление БА и наследование исходной связи с ФОБ. Если в хозоперации перед привязкой ДО нет связи с ФОБ, то после привязки ДО такая связь формируется. Привязать ДО можно только к хозоперации по которой нет разноски по ДО. Для переразноски необходимо сначала отвязать ДО.
102.1985079.1.129.0платежное требованиеФинансово-расчетные операцииПлатежное требование
внесены изменения в печать платежного требования Изменения отражены в Инструкции № 66 Нацбанка от 29.03.2001 г. В эту инструкцию внесены изменения Постановлением № 451 от 05.10.18 и Постановлением № 35 от 29.01.2018 нужно сделать быстро, регистрация идет задним числом. Форма во вложенииИз списка форм печати убраны: - Платежное требование до 21.11.2014 - Платежное требование с конверсией, покупкой, продажей до 21.11.2014 Добавлена форма "Платежное требование (29.01.2018)" в соответствии с Постановлением № 35 от 29.01.2018
102.1980799.1.128.0Необработанное исключение при удалении реестра при следующих условиях.Финансово-расчетные операцииПлатежное поручение
Необработанное исключение при удалении реестра при следующих условиях. В платежном поручении на закладке "Реестры" по F7 создаю новый реестр и сразу по F8 удаляю реестр. Выдается Возникло необработанное исключение ExObjIfcNoInit (ExRef) ссылка не была инициализирована "Да" - Продолжить, "Нет" - Отлаживать в окне отладчика "Отмена" - Не выдавать больше это сообщениеУстранена причина появления исключения.
102.1967409.1.127.0КИС ФХД ТПР3 Очередь2 Ошибка обновления полей авансового отчетаКассаАвансовый отчет
КИС ФХД ТПР3 Очередь2 Ошибка обновления полей авансового отчета Оба пользователя работают с одним реестром (реестр авансовых отчетов). Пользователь А открыл документ, отредактировал его и вышел. Но если сразу же после закрытия АО пользователем А, его откроет пользователь В, то он не увидит изменения, внесенные пользователем А, пока не обновит документ или реестр документа. Необходимо, чтобы при открытии документа, подтягивались актуальные данные из базы.Исправлено.
102.1972789.1.127.0не срабатывает обновление записи в АОКассаАвансовый отчет
не срабатывает обновление записи в АО. Например: пользователь 1 внес изменения в АО в части перевыбора в поле "Фамилия, И.О." (было Иванов, стало Петров) закрыл окно редактирования АО. Пользователь 2 зашел в этот же АО - изменений нет. пользователь 2 вышел из окна редактирования АО, из списка АО, зашел заново, но изменений нет. И тут, внимание!!!!, пользователь 1 заходит снова в АО и поле "Фамилия, И.О." снова меняется на Иванов. не срабатывает признак обновления записи и запись возвращается в исходное состояние см. пир 102.196740исправлено перепроверить первоисточник 102.195752
101.666029.1.127.0Онлайн-кассы - при настройке округления в документах КОУ и полной оплате не все позиции регистрируются как "Полный расчет"КассаПриходный кассовый ордер
"Настройки Галактики Логистика Документы Управление сбытом - Округление в документах сбыта" = "математическое, 0.01" В примере клиента ПКО сформирован на полную сумму ДО и накладной, но в распределении по накладной получается последняя позиция оплачена не полностью (есть погрешность в 6-м знаке дробной части). В результате последняя позиция регистрируется в ККТ не как "полный расчёт", а как "частичный расчёт и кредит". Кроме того, НДС в ДО и накладной округлён до копеек по каждой позиции. В платёжном документе видим правильную сумму НДС из накладной (сумма округлённых значений). В промежуточном интерфейсе регистрации в ККТ по позициям тоже всё верно - округлённые НДС, а итоговая сумма НДС на 1 копейку меньше (видимо сумма точных значений) - тоже желательно поправить. См. также подробное описание во вложенных файлах.Были выполнены следующие доработки: 1. Добавлена пользовательская настройка "Настройки Галактики Бухгалтерский контур Обработка документов Распределение платежа по ДО Распределение платежа по сопроводительным документам Контролировать сумму к распределению с учетом округления" со значением по умолчанию "да". Данная настройка позволяет учитывать погрешности округления при расчете суммы к распределению по позиции. 2. В окне регистрации в ККТ итоговая сумма НДС по всем позициям получается на основании суммы округленных значений НДС каждой позиции.
102.1971829.1.127.0Исчезает поле Плательщик после конфигураций в интерфейсах платежекФинансово-расчетные операцииПлатежное поручение
Исчезает поле Плательщик после конфигураций в интерфейсах платежек. Конфигурируем одно и то же поле (номер договора) в 4 интерфейса платежных поручений: сторонние, собственные, валютные сторонние, валютные собственные. После 4го интерфейса, пропадает полностью поле Плательщик в интерфейсе редактирования платежных поручений видео Q:workulasenconfigисправлено
101.665679.1.127.0Онлайн-кассы - необходима регистрация в ККТ СОБСТВЕННЫХ платежных поручений ЗА физических лицФинансово-расчетные операцииПлатежное поручение
Просят открыть функцию регистрации в ККТ и в собственных платёжных поручениях с контрагентом-физическим лицом в поле "Платёж за" аналогично входящим п/п (ПиР 102.189412). Такими документами могут оформляться возвраты денег физическим лицам - в этом случае получателем будет банк, само физлицо указано в поле "Платёж за", а в поле "Счёт" - счёт физлица в этом банке. Соответственно требуется регистрация возврата в ККТ. Из обсуждения с клиентом: "Ещё раз уточнили у заказчика по поводу ФИЗЛИЦА в собственном платежном поручении. Так как случаев возврата не было, просят учесть как в стороннем платежном поручении, т.е. либо в поле Получатель, либо в поле Платёж за. Для примера можем рассмотреть платежки по перечислению ЗП, алиментов и т.д. Получатель платежа = Банк. Счет = счет получателя платежа ФЛ в банке-получателе, а так же в назначении платежа указывается ЛС. Для регистрации через ККТ можно тоже использовать поле ПЛАТЕЖ ЗА".Доработано. Регистрация в ККТ для собственных и сторонних ПП доступна в следующих случаях: - Если в поле "Получатель" указано физическое лицо. - Для собственных и сторонних ПП, если в поле "Платеж за" указано физическое лицо.
102.1858299.1.127.0долгое открытие списка реестров на перечисления из ппФинансово-расчетные операцииПлатежное поручение
долгое открытие списка реестров на перечисления из пп В Галактике заведено большое количество реестров. При привязке реестров в платежном поручении на вкладке "РеестрыФормирование связи документовВыбор существующего реестра" открытие списка занимает до 40 секунд? а иногда до 2-3 минут.Оптимизирована работа загрузки интерфейса при наличии сохраненного фильтра. Для ускорения загрузки интерфейса рекомендуется сохранить фильтр по периоду, за который происходит работа с реестрами. При повторной загрузке интерфейса сначала фильтруются данные по сохраненным ограничениям, затем происходит расчет прав по подразделениям.
102.1854869.1.127.0Ошибка при формировании реестра на перечислениеКассаПриказы на командировки
В "ФРО Операции Реестры на перечисление" в окно редактирования добавить в шапку и спецификацию поле "Суммы выплачиваемая" (как в реестрах Зарплаты).Доработан интерфейс Реестров на перечисление модуля ФРО. Если значение настройки "Настройки Галактики Управление персоналом Расчеты с персоналом Прочие удержания Процент удержания сбора по перечислению в банк" не равно нулю, то в шапке реестра и списке его сотрудников отображаются поля "Сумма перечисляемая" (бывшая "Сумма") и "Сумма выплачиваемая" (рассчитывается как "Сумма" - минус "Сумма сбора"; сумма сбора это "Процент удержания сбора по перечислению в банк" от "Суммы").
180.104089.1.127.0автоматическое формирования СФ на возврат предоплаты после запуска функции Формирование возврата платежаКонтуры: финансовый, бухгалтерского учетаНе знаю, какая именно часть финансового контура, научите
клиент формирует приходный кассовый ордер на предоплату, к нему привязывает ДО на предоплату. СФ на предоплату формируется автоматически (в соответствии с выставленными настройками). затеи клиент запускает функцию лок меню Формирование возврата платежа. В сформированном автоматически Расходном кассовом ордере подвязалось ДО на предоплату из приходного кассового ордера, но документ для учета НДС автоматически не сформировался. Его приходится формировать вручную во вкладке Учет НДС в РКО. Это не удобно клиентам. Можно каким-то образом в настоящее время СФ "Возврат оплаты, предоплаты" сформировать автоматически или добавить такую возможность.Добавлена пользовательская настройка "Настройки Галактики Бухгалтерский контур Обработка документов Формирование счета-фактуры при выполнении возврата платежа" со значением по-умолчанию "нет". Если данная настройка выключена, то при формировании возврата платежа в хозоперациях возвращаемого платежа выполняется только расчет налогов. Если данная настройка включена, то при формирования возврата платежа в хозоперациях возвращаемого платежа выполняется расчет налогов и формирование счетов-фактур (в соответствии с текущими настройками).
102.1966519.1.126.0Обеспечение корректной работы на докомпилированном словаре Галактики ERP 9.1Предложение по новой функциональности Галактики ERP (по системе в целом)?
Необходимо обеспечить корректную работу ресурсов на докомпилированном словаре Alter_Cumulative 9.1.15.0.Обеспечение корректной работы. Пересобраны ресурсы с учетом изменённых таблиц словаря Alter_Cumulative 9.1.15.0. Комплектность установки ресурсов обеспечена требованиями при установке.
102.1749799.1.125.0КИС ФХД ТПР2 Очередь1 Невозможно выбрать значение настройки для группы пользователейНастройкаАдминистратор настроек
Аналогично проблеме 102.174828 По настройке "Параметры работы с документами различных типов".Добавлена возможность выбора настройки "Параметры работы с документами различных типов" для группы пользователей.
102.1953869.1.125.0В кассовых ордерах не запускается автоматическое распределение по ДО/Накладным/АктамКассаПриходный кассовый ордер
В кассовых ордерах, разнесенных по ДО, не запускается автоматическое распределение по спецификациям ДО/Накладных/Актов при установке даты оплаты. Так же, при формировании кассового ордера из ДО (в случае когда автоматически проставляется дата оплаты) не запускается автоматическое распределение по спецификациям ДО/Накладных/Актов.В кассовых ордерах, разнесенным по ДО, при установке даты оплаты запускается распределение по позициям спецификации ДО и накладных/актов, а так же расчет налогов и формирование счетов-фактур (в соответствии с настройками выполненных в интерфейсе настроек "Настройки Галактики Бухгалтерский контур Обработка документов Параметры работы с документами различных типов"). При формировании кассовых ордеров из ДО, в случае если в кассовом ордере автоматически проставляется дата оплаты, запускается распределение по позициям спецификации ДО и накладных/актов, а так же расчет налогов и формирование счетов-фактур (в соответствии с настройками выполненных в интерфейсе настроек "Настройки Галактики Бухгалтерский контур Обработка документов Параметры работы с документами различных типов").
101.664749.1.124.0Онлайн-кассы - после перепривязки авансового платежа к ДО с реальной отгрузкой он не учитывается как предоплатаКассаПриходный кассовый ордер
При продаже подарочной карты (это МЦ с атрибутом "аванс") оформляется ДО с такой позицией, ПКО распределяется на эту МЦ и регистрируется в ККТ как аванс, всё верно. Затем покупатель используя эту подарочную карту приобретает реальные МЦ - оформляется новый ДО с реальной спецификацией. Далее нужно старый (авансовый) ПКО перепривязать к новому (реальному) ДО - для этого в старой хозоперации проставляется "Входит в сумму документа" = "-" и добавляется новая ХО со ссылкой на новый ДО и распределением по позициям накладной. Проблема в том, что сейчас в соответствии с решением ПиР 101.66415 тег 1215 "сумма предоплат по чеку" не формируется, поскольку в новой ХО нет распределения по старому (авансовому) ДО. Предлагается при установке "Входит в сумму документа" = "-" в старой ХО проставлять на неё ссылку в автоматически формируемой новой ХО. Далее при регистрации в ККТ для накопления тега 1215 анализировать не только распределение по ДО регистрируемой новой ХО (ПиР 101.66415), но и распределение по ДО связанной (авансовой) ХО.Алгоритм работы с платежами-авансами следующий. 1. Сначала формируется ДО с авансовыми позициями спецификации (должно содержать только авансовые позиции). 2. Данное ДО привязывается к кассовому ордеру и регистрируется в ККТ как аванс. 3. Затем формируется новое ДО с не авансовыми позициями спецификации. 4. В кассовом ордере, в хозяйственной операции к которой было привязано авансовое ДО необходимо выполнить увод хозоперации в минус с автоматическим созданием хозоперации (должна быть включена настройка "Настройки Галактики Бухгалтерский контур Обработка документов Хозяйственные операции и бухгалтерские проводки Контроль баланса при изменении признака входимости хозоперации"). 5. В автоматически созданной хозоперации отвязываем ДО с авансовыми позициями спецификации и привязываем ДО с реальными позициями. 6. Повторно нажимаем на кнопку регистрации ККТ, в результате выдается сообщение о запрете повторной регистрации аванса. Связано это с тем, что по новому ДО отсутствуют накладные. 7. После формирования накладных по ДО с реальными позициями снова нажимаем на кнопку регистрации ККТ. В результате выполняется следующее: - для хозоперации входящей в сумму документа проверяется наличие хозоперации не входящей в сумму документа и если така хозоперация существует, то проверяется есть ли к ней привязка ДО с авансовыми позициями; - если авансовые позиции существуют, то сумма текущей хозоперации (входящей в сумму документа) накапливается в поле "Сумма по чеку предоплатой", т.к. считается, что все позиции распределенные по текущей хозоперации были зарегистрированы как аванс.
101.664159.1.124.0Онлайн-кассы - повторно регистрируемый при отгрузке платеж-предоплата не учитывается как предоплатаКассаПриходный кассовый ордер
По ДО сформирован входящий платёж и корректно зарегистрирован в ККТ (как предоплата). На следующий день формируем накладную и заново регистрируем тот же ПКО - уже как "ПОЛНЫЙ РАСЧЕТ", либо "ЧАСТИЧНЫЙ РАСЧЕТ И КРЕДИТ". Но при этом тег 1215 (сумма предоплат по чеку) не формируется. См. также подробное описание клиента во вложенном файле.Для способов расчета "Полный расчет" и "Частичный расчет и кредит" доработан алгоритм определения предоплаты для распределенных позиций спецификации накладной/акта. Предоплата по позиции накладной/акта определяется на основании суммы регистрации в ККТ аналогичной позиции спецификации ДО. Допустим есть КО на 100 рублей и ДО на 100 рублей. В ДО есть Позиция1 на 30 рублей и Позиция2 на 70 рублей. После привязки ДО к КО выполнена регистрация аванса. Затем по ДО формируется накладная, выполняется ее распределение и запускается регистрация в ККТ. В накладной для Позиция1 будет найдена обработанная регистрация аванса в ККТ на 30 рублей для Позиция1 в ДО. Соответственно для Позиция2 будет найдена обработанная регистрация аванса в ККТ на 70 рублей. Итого по данному чеку будет предоплата 100 рублей. Если к КО привязать ДО с накладной (т.е. регистрация аванса не выполнялась), то для такого чека предоплата будет равна 0.
101.664369.1.124.0Онлайн-кассы - для нераспределенных по позициям ДО/накладных платежей выполнять автораспределение при запуске регистрации в ККТКассаПриходный кассовый ордер
Предлагается при регистрации платежа в ККТ выполнять автоматическое распределение по позициям ДО/накладных, если в регистрируемом платёжном документе требуемое распределение полностью отсутствует, а в настройке "Параметры работы с документами различных типов" для данного типа документов (ПП, ПКО) указано "Распределять сумму платежа" = "автоматически". Иначе в некоторых ситуациях приходится делать распределение вручную. Пример: авансовый платёж распределён по позициям ДО и зарегистрирован в ККТ (как предоплата). Потом делаем отгрузку, пытаемся зарегистрировать платёж снова (уже как полный расчёт) - но нет распределения по накладной и приходится делать его вручную, несмотря на настройку автораспределения. См. также описание клиента во вложенном файле.Если в платежном или кассовом документе проставлена дата оплаты, а в интерфейсе настройке "Настройки Галактики Бухгалтерский контур Обработка документов Параметры работы с документами различных типов" для параметра "Распределять сумму платежа" установлено значение "Автоматически", то при нажатии на кнопку "Регистрация в ККТ", для хоз.операций входящих в сумму документа и разнесенных по ДО запускается распределение по позициям спецификации ДО и накладных/актов в следующих случаях: 1. Если по ДО нет накладных, то распределение по позициям спецификации ДО выполнится только в случае отсутствия распределения для текущей хозоперации. 2. Если по ДО есть накладные/акты, то распределение по позициям спецификации накладных/актов будет запускаться только для накладных, по которым отсутствует распределение по текущей хозоперации. После завершения распределения по спецификациям выполняется регистрация в ККТ.
102.1955379.1.124.0RunTime 213 при копировании платежных документовФинансово-расчетные операцииПлатежное поручение
При копировании платежных документов у клиента возникает RunTime 213. Проблема проявляется не всегда. Удалось проявить на чистом exe в офисе. Был записан ролик и собран sil-протокол(См. по пути: q:work ebkovetsRunTimeRunTime_3). Отчет о компонентах см. во вложении.Исправлено. Решение по ПИР 102.192932 было затерто на обновлениях. Необходимо его заново выпустить.
102.1952499.1.124.0ATL5533 Ошибки при печати формы в формате FRФинансово-расчетные операцииПоручение на покупку валюты
ATL5533 Ошибки при печати формы в формате FR настройка Россия Модуль ФРО - Документы - Валютно-обменные документы. Поручение на покупку валюты. При печати формы "Поручение на покупку иностранной валюты (Сбербанк России)" выдается: --------------------------- FastReport - Ошибка --------------------------- Были обнаружены следующие ошибки: Memo41: Could not convert variant of type (UnicodeString) into type (Double) Memo43: Could not convert variant of type (UnicodeString) into type (Double) --------------------------- ОК --------------------------- Модуль ФРО - Документы - Валютно-обменные документы. Реестр распределения валюты. --------------------------- FastReport - Ошибка --------------------------- Были обнаружены следующие ошибки: Memo32: Could not convert variant of type (OleStr) into type (Double) --------------------------- ОК --------------------------- настройка Беларусь Модуль ФРО - Документы - Валютно-обменные документы. Поручение на покупку валюты. При печати формы "Заявка на покупку валюты (Минский транзитный банк)" выдается: --------------------------- FastReport - Ошибка --------------------------- Были обнаружены следующие ошибки: Memo2: Could not convert variant of type (OleStr) into type (Double) --------------------------- ОК ---------------------------ATL5533 Устранены причины ошибок при печати форм в формате FR настройка Россия Модуль ФРО - Документы - Валютно-обменные документы. Поручение на покупку валюты. При печати формы "Поручение на покупку иностранной валюты (Сбербанк России)" выдается: --------------------------- FastReport - Ошибка --------------------------- Были обнаружены следующие ошибки: Memo41: Could not convert variant of type (UnicodeString) into type (Double) Memo43: Could not convert variant of type (UnicodeString) into type (Double) --------------------------- ОК --------------------------- Модуль ФРО - Документы - Валютно-обменные документы. Реестр распределения валюты. --------------------------- FastReport - Ошибка --------------------------- Были обнаружены следующие ошибки: Memo32: Could not convert variant of type (OleStr) into type (Double) --------------------------- ОК --------------------------- настройка Беларусь Модуль ФРО - Документы - Валютно-обменные документы. Поручение на покупку валюты. При печати формы "Заявка на покупку валюты (Минский транзитный банк)" выдается: --------------------------- FastReport - Ошибка --------------------------- Были обнаружены следующие ошибки: Memo2: Could not convert variant of type (OleStr) into type (Double) --------------------------- ОК ---------------------------
101.663779.1.124.0Некорректная общая сумма в случае, когда налоги не входят в ценуКассаПриходный кассовый ордер
Некорректная общая сумма в случае, когда налоги не входят в цену Скриншоты и описание - во вложении.Выполнена доработка для способов расчета "полный расчет" и "частичный расчет" в случаях когда налоги не входят в сумму документа. Для способа расчета "полный расчет" в поле "Итого к оплате" передается итоговая сумма плюс налоги по ней. Для способа расчета "частичный расчет" в поле "Итого к оплате" передается итоговая сумма плюс налоги по ней, а в поле "Сумма по чеку постоплатой" накапливается сумма подлежащая к доплате. Кроме этого установка признака обработки в ККТ позиции распределения выполняется теперь не после закрытия окна регистрации в ККТ, а только после успешной отработки точки расширения epKO_KKTDoneConnection_v1_05.
102.1949929.1.124.0сохранять при возврате кассовых документов значение полей "Организация" и поля "Выдать"/"Принять от"КассаПриходный кассовый ордер
Реализован функционал возврата платежей для Приходного кассового ордера/Расходного кассового ордера. В связи с чем необходимо сохранять (при возврате кассовых документов) значение полей "Организация" и поля "Выдать"/"Принять от" см. ПИР 180.10848 реализовать решение на продукты 9.1 и 9.2Исправлено.
106.105629.1.124.0Сделать отдельную настройку "Разрешать запрещать создание СФ"Управление сбытомНаши счета-фактуры
Сделать отдельную настройку "Разрешать запрещать создание СФ"Изменены варианты выбора для настройки "Разрешать работу c документами для учета НДС": нет / да / только в сбыте / только в снабжении. Раздел: "Настройки Галактики Логистика Налоги, документы для учета НДС" Примечание. Для того, чтобы изменить тип настройки на пользовательский, необходимо в модуле "Настройка", меню "Настройка - Администратор настроек" выбрать настройку "Разрешать работу c документами для учета НДС" и изменить тип. Для каждого пользователя установить нужное значение настройки.
103.99359.1.123.0Печатные формы в реестрах на перечисление не подхватывают "на лету" сделанные изменения. Нужно переоткрывать интерфейс со списком реестровФинансово-расчетные операцииРеестры по перечислениям
Печатные формы в реестрах на перечисление не подхватывают "на лету" сделанные изменения. Нужно переоткрывать интерфейс со списком реестров Клиент открывает реестр, правит там данные и отправляет реестр на печать. Измененные данные реестра на печать не выходят, выходит старая информация. Переоткрытие карточки реестра не помогает - нужно переоткрывать интерфейс со списком реестров для того, чтобы на печать выводились обновленные данные.исправлено
102.1941629.1.123.0Изменение ставки НДС в переходный периодФинансово-расчетные операцииПлатежное поручение
Изменение ставки НДС в переходный период 1.Платеж в 2018г. по ставке 18%. СФ на аванс не сформирован. 2.ДО, накладная, СФ-отгрузка в 2019 году по ставке 20% 3.Привязывается ДО к платежу: ставка в платеже меняется на 20% и СФ на аванс формируется по ставке 20% Настройка "ставки для авансов" в "Параметры работы с документами различных типов" установлена в "ставки из ДО". Установить конкретную группу нельзя, т.к. платежки в 2018 году должны формироваться по ставке 18%, а в 2019- по ставке 20%, т.е. зафиксировать для всех платежей одну ставку нельзя. Пример во вложении.В локальном меню вкладки "Налоги" каталога и окна редактирования платежных документов, а также окна редактирования хозяйственной операции добавлены следующие пункты меню: - Перевод налогов в ручные; - Перевод налогов в автоматические. При выполнении данных пунктов для всех отображаемых на вкладке налогов будет выставлен атрибут ручные или соответственно автоматические. В локальном меню каталога платежных документов (подменю "Прочие...") так же добавлены вышеуказанные пункты меню. Данные операции выполняются как для текущего платежного документа, так и для группы помеченных. Переводить налоги в ручные необходимо для того что бы зафиксировать рассчитанные налоги и что бы они не были пересчитаны по ставке ндс 2019 года. В момент привязки ДО в платежном документе, так же выполняется сравнение даты ДО и даты хозяйственной операции, и если хозоперация находится в 2018 году, а ДО в 2019, то пользователю выдается запрос на выполнение перевода налогов в ручные, что бы выполнить фиксацию налогов. Аналогичная доработка выполнения и в пакетном распределении платежей. При распределение по ДО контролируются даты ДО и хозоперации, а при распределении накладных контролируются дата накладной и хозоперации. Фиксация налогов выполняется так же по запросу и перед привязкой ДО или накладной
102.1906039.1.121.0Переход на НДС 20% : доработать возможность создания корректировочного СФ к авансовому СФУправление сбытомНаши счета-фактуры
Необходимо доработать возможность создания корректировочного СФ к авансовому СФ, т.е. аванс уплачен до 01/01/2019 (выставлен авансовый СФ со ставкой НДС 18/118), доплата НДС в размере 2% (20%-18%)произведена после 01/01/2019. Нужно выставить корректировочный СФ на сумму доплаты НДС. Таким образом, вся оплаченная сумма - это доначисление только НДС, которое отражается в корректировочном СФ. Законодательство: Письмо ФНС от 23 октября 2018 г. N СД-4-3/20667@ "О ПОРЯДКЕ ПРИМЕНЕНИЯ НАЛОГОВОЙ СТАВКИ ПО НДС В ПЕРЕХОДНЫЙ ПЕРИОД" (полный текст см. во вложении): "если доплата налога в размере 2% осуществляется покупателем с 1 января 2019, то такую доплату не следует рассматривать в качестве дополнительной оплаты стоимости, с которой необходимо исчислять НДС по ставке 20/120. При получении такой доплаты налога продавцу следует выставить корректировочный счет-фактуру на разницу между показателем суммы налога по счету-фактуре, составленному ранее с НДС 18/118, и показателем суммы налога, рассчитанной с учетом размера доплаты налога;"Доработки выполнены для страны Россия. В окне редактирования хозяйственной операции финансовых и кассовых документов, добавлена закладка "Доплата НДС". На данной вкладке находятся два поля: 1) Статус хозоперации. Информационное поле, которое может отображать следующие значения: - Доплата НДС не выполнялась; - Доплата НДС; - Связь с доплатой НДС. 2) Связанный документ. Поле отображающее описание хозяйственной операции с которой установлена связь. Предназначено для формирования и удаления связи, а так же для перехода в связанный документ. Для того что бы для текущей хозоперации выполнить доплату НДС необходимо либо выполнить пункт локального меню "Обработать хозяйственную операцию как доплату НДС", либо нажать F3 в поле "Связанный документ". При этом дата оплаты хозяйственной операции (а при ее отсутствии дата выписки документа) должна быть позже 31.12.2018 и хозоперация должна входить в сумму документа. В результате пользователю будет предложено выбрать хозоперацию для которой выполняется доплата НДС. При этом к хозяйственным операциям будет применен следующий фильтр: - период до 31.12.2018 (включительно); - вид документа аналогичный текущему; - контрагент аналогичный текущему; - договор и соглашение аналогичные текущему. Данный фильтр можно изменить (локальное меню интерфейса выбора хозопераций - Установка ограничений). В случае, если у текущей хозоперации существует разноска по ДО, то выбрать можно только хозоперацию с таким же ДО. После выбора хозяйственной операции будет установлена связь между текущей и выбранной хозоперацией и на вкладке "Доплата НДС", в поле "Связанный документ" отобразится наименование выбранной хозоперации, а поле "Статус хозоперации" будет отображаться значение "Доплата НДС". Так же, в окне редактирования хозоперации, в поле "Статус" (самое первое поле сверху окна) отобразится значение "Доплата НДС". При этом, если у выбранной хозоперации было ДО, то в текущей хозоперации оно тоже будет привязно и выполнится распределение по спецификации накладной/акта и рассчитаются налоги. Был доработан расчет налогов. В случае если хозоперация является доплатой НДС, то формируется налог НДС со ставкой 20% и на сумму равную сумме хозяйственной операции. В выбранной хозоперации, в статусе появится подпись - "связь с доплатой НДС". Для того что бы отменить обработку хозоперации как доплату НДС, необходимо в поле "Связанный документ" нажать на клавишу Del. В результате связь будет удалена, а налоги по хозоперации будут пересчитаны. Для того что бы перейти в связанный документ, необходимо в поле "Связанный документ" нажать F4. При удалении платежного документа или одной из связанных хозопераций выполняется удаление связи между документами. При уводе хозоперации в "минус", в случае автоматического создания новой хозоперации, связь между документами копируется в новую хозоперацию. __________________________________________ Доработка СФ. Созданы новые типы СФ: - Корректировочный СФ, доплата НДС по авансам - Корректировочный СФ поставщика, доплата НДС по авансам Для доплатных хозопераций, описанных выше, создаются СФ с данными типами, у которых по основной ставке сумма НДС равна сумме с НДС. Доработана печать FR и текстовой форм "Корректировочный счет-фактура (c 01.10.2017)" - столбцах 8 и 9 строк "В (увеличение)" и "Всего увеличение (сумма строк В)" выводится единая сумма корректировочных авансов. Предупреждения: 1. Перед регистрацией корректировочных авансов сначала необходимо зарегистрировать обычный аванс и отгрузку. Регистрацию корректировки производить из корректировочного СФ. 2. Настройку "Налоги сопроводительных документов рассчитывать по ДО" установить в нет. Иначе в 2019г. будет ставка 18%, если ДО в 2018г.
102.1935729.1.121.0Доработать фильтрФинансово-расчетные операцииБухгалтерская справка
Доработать фильтр При установке фильтра на документы по параметру "Расчетный счет" для значения "все", нужно учитывать настройки доступа к расчетным счетам/кассам/бух.справкам. Например, на предприятии ведется 3 типа бух.справок: бс1,бс2,бс3. У пользователя установлена настройка: "Настройки Галактики Бухгалтерский контур ..доступ к бухгалтерским справкам по" доступным типам бухсправок и заданы 2 доступных типа бс1 и бс2. При установке фильтра в списке бух. справок с параметром "Расчетный счет" со значением "все", пользователю становятся доступные и документы с типом бс3.доработано аналогично касс и РС: фильтр доступен при настройке по всем типам БС
101.659919.1.121.0Онлайн-кассы - новые реквизиты в ФФД 1.05 и 1.1КассаПриходный кассовый ордер
В соответствии с прилагаемым Приказом ФНС России от 21.03.2017 N ММВ-7-20/229@ начиная с версии 1.05 формата фискальных документов (ФФД) по сравнению с ФФД 1.0 добавляется ряд новых обязательных реквизитов. То есть как только кассовый аппарат обновлён до ФФД 1.05, или 1.1 - формирование этих реквизитов становится обязательным. Там же сказано, что ФФД 1.0 полностью прекращает своё действие 31.12.2018, поэтому сейчас клиенты массово обновляют свою ККТ. Из новых реквизитов ФД для нас в первую очередь интерес представляют: 1212 "признак предмета расчета" - для каждой позиции чека, на данный момент 18 значений, см. Таблицу 29; 1214 "признак способа расчета" - для каждой позиции чека, 7 значений, см. Таблицу 28; 1215 "сумма по чеку (БСО) предоплатой (зачетом аванса и (или) предыдущих платежей)" - на весь чек; 1216 "сумма по чеку (БСО) постоплатой (в кредит)" - на весь чек; 1217 "сумма по чеку (БСО) встречным предоставлением". Предлагается реализовать новые точки расширения для передачи расширенного набора данных в ККТ. Возможно, также пользовательскую настройку "Версия формата фискальных документов" с вариантами "1.0/1.05 и выше" - для выбора вызываемых точек (обсуждаемо). epKO_isNotExistExtPoint_v1_05 - для определения версии ФФД (тогда не придётся добавлять настройку). epKO_KKTInitConnection - новая точка расширения наверное пока не нужна. epKO_KKTRegistration_v1_05 - добавить передачу реквизитов 1212 и 1214. Возможно, также ссылки на позицию накладной и распределения. epKO_KKTDoneConnection_v1_05 - добавить передачу реквизитов 1215, 1216, 1217. В системном интерфейсе регистрации показать все рассчитанные реквизиты, желательно с возможностью ручной корректировки. Вычисление реквизитов: 1212 - для начала предлагаю формировать ТОВАР (1)/УСЛУГА (4)/ПЛАТЕЖ (10). Значение "ПЛАТЕЖ" (10) - только в случае, если реквизит 1214 равен "АВАНС" (3). 1214 - если нет распределения по позициям накладной, то каждая позиция ДО это либо "ПРЕДОПЛАТА 100%" (1), либо "ПРЕДОПЛАТА" (2), либо "АВАНС" (3). Такие платежи нужно разрешить регистрировать повторно (при отгрузке). То есть при регистрации устанавливать промежуточный статус, допускающий повторную регистрацию - например, "Зарегистрирован как предоплата/аванс". "АВАНС" (3) - это когда заранее неизвестно за какой конкретно товар/услугу платят, например, при покупке подарочной карты, или при выборе услуги "аванс в счёт будущих поставок". Как вариант, можно определять по внешнему атрибуту к МЦ/услуге "Аванс", или добавить новое поле, или новое значение поля "Категория", или может есть что-то более подходящее в каталогах МЦ/услуг. "ПРЕДОПЛАТА 100%" (1), или "ПРЕДОПЛАТА" (2) - на данном этапе определить не можем, поскольку сейчас у нас нет информации о распределённой сумме платежа по позициям ДО. Пока что предлагаю формировать 1, в ближайшее время доработать распределение по позициям ДО (в рамках отдельного ПиР). "ПОЛНЫЙ РАСЧЕТ" (4) - когда позиция ПОЛНОСТЬЮ оплачена регистрируемым документом (с учётом предыдущих платежей) и дата регистрируемого платежа <= дате отгрузки. Передавать полное количество по накладной dKol (а не только оплаченное регистрируемым документом). При этом сумму предыдущих платежей по данной позиции нужно накапливать для реквизита 1215 (если дата регистрируемого платежа < дате отгрузки, то его тоже сюда включать). "ЧАСТИЧНЫЙ РАСЧЕТ И КРЕДИТ" (5) - когда позиция ЧАСТИЧНО оплачена регистрируемым документом (с учётом предыдущих платежей) и дата регистрируемого платежа <= дате отгрузки. Передавать полное количество по накладной dKol (а не только оплаченное). При этом сумму предыдущих платежей по данной позиции нужно накапливать для реквизита 1215 аналогично предыдущему пункту, а неоплаченную сумму по данной позиции - накапливать для реквизита 1216. "ПЕРЕДАЧА В КРЕДИТ" (6) - когда позиция полностью НЕ оплачена и дата отгрузки равна дате регистрируемого платежа. Передавать полное количество по накладной dKol. При этом ВСЮ сумму по данной позиции нужно накапливать для реквизита 1216. Здесь необходимо ещё решить вопрос как быть в случае передачи товара вообще без оплаты - формировать платёж на сумму 0? Сейчас так сделать не получается. "ОПЛАТА КРЕДИТА" (7) - когда дата регистрируемого платежа > даты отгрузки. Передавать оплаченное регистрируемым документом количество dKol. 1215, 1216 - накопленные соответствующие суммы по всем позициям с реквизитом 1214 = "ПОЛНЫЙ РАСЧЕТ" (4), или "ЧАСТИЧНЫЙ РАСЧЕТ И КРЕДИТ" (5), или "ПЕРЕДАЧА В КРЕДИТ" (6). 1217 - пока предлагаю формировать 0. См. также описание примеров во вложенном файле (они годовой давности, но в основном правильные, если найдём более актуальные документы - будем добавлять сюда).Для поддержки поддержки формата ФФД 1.05 или 1.1 реализованы следующие точки расширения: 1. Проверка поддержки формата ФФД 1.05 или 1.1 При существовании обработчика, а значит поддержке новых форматов, точка должна возвращать false. ExtensionPoint epKO_isNotExistExtPoint_v1_05; 2. Регистрация оплаченной позиции документа для ФФБ 1.05 ExtensionPoint epKO_KKTRegistration_v1_05 (wTiDk, // Тип документа wOperation, // Тип операции (0-не определен; 1-продажа; 2-возврат продажи; 3-покупка; 4-возврат покупки) wObjMethod, // Признак предмета расчета wCalcMethod : word; // Признак способа расчета sAdmPass, // Пароль администратора системы sOperatorPass, // Пароль оператора для ККТ sNamePos : string; // Наименование мц/услуги dKol, // Количество dPrice, // Цена dTaxRate, // Ставка dSumTax, // Сумма налога dSumTaxForOne: double; // Не округленная сумма налога за 1 позицию bModeTax : boolean; // Входимость налога wDistrType : word; // Тип распределения (1 - по ДО; 2 - по накладной/акту) cDistrPos : comp; // Ссылка на позицию распределения (для типа 1 ссылка на PlDgDist; для типа 2 ссылка на SpSopHoz) pObject : pointer); // Ссылка на драйвер кассового аппарата 3. Завершение регистрации ККТ для ФФБ 1.05 ExtensionPoint epKO_KKTDoneConnection_v1_05 (cDoc : comp; // NREC документа sAdmPass, // Пароль администратора системы sOperatorPass : string; // Пароль оператора для ККТ wPaymentType : word; // Тип оплаты (0 - наличные; 1- банковская карта) dSumPrePay, // Сумма по чеку (БСО) предоплатой (зачетом аванса и/или предыдущих платежей) dSumPostPay, // Сумма по чеку (БСО) постоплатой (в кредит) dSumConsider : double; // Сумма по чеку (БСО) встречным предоставлением pObject : pointer; // Ссылка на драйвер кассового аппарата pStr : iObjExtStr); // Объект работы со строками В случае, если реализована точка расширения №1 и она возвращает значение False, это означает что регистрация в ККТ будет выполнятся с учетом нового формата. В этом случае, в окне распределения по спецификациям накладной/акта, а так же по спецификации ДО,в позициях оплаты, появится поле "ККТ", которое может принимать значения "Да" или "Нет". Значение "Да", означает что данная позиция была обработана в ККТ. Данные поля можно редактировать вручную, а так же оно автоматически устанавливается в занчение "Да", после выполнения регистрации по позициям. В окне регистрации в ККТ для каждой позиции были добавлены поля "Предмет расчета" и "Способ расчета". Данные поля определяются для каждой позиции и передаются в точку расширения №2. Так же в окне появились поля "Сумма по чеку предоплатой" и "Сумма по чеку постоплатой". Данные поля накапливают суммы по всем позициям и передаются в точку расширения №3. Поле "Сумма по чеку предоплатой" накапливает по позициям оплаты суммы которые были зарегистрированы ранее (позиции распределения со значением поля "ККТ" = "Да"). Поле "Сумма по чеку постоплатой" накапливает по позициям суммы, которых не хватает до полной оплаты позиции. Предмет расчета определяется следующим образом: если позиция является МЦ, то она принимает значение = 1 (товар), если позиция является услугой, то она принимает значение = 4 (услуга), а если к товару или услуге указанной в позиции спецификации существует внешний строковый атрибут "Аванс" который принимает значение "1", атрибут то предмет расчета принимает значение = 10 (Аванс) Способ расчета может принимать следующие значения: 1) Предоплата 100% (значение = 1) - когда существует только распределение по спецификации ДО и позиция полностью распределена (с учетом предыдущих оплат). При этом количество передается целиком, а сумма предыдущих оплат накапливается в поле "Сумма по чеку предоплатой". 2) Предоплата (значение = 2) - когда существует только распределение по спецификации ДО и позиция не полностью распределена. При этом количество передается с учетом предыдущих оплат, а сумма предыдущих оплат накапливается в поле "Сумма по чеку предоплатой". 3) Аванс (значение = 3) - для позиции с признаком предмета расчета - "Аванс". 4) Полный расчет (значение = 4) - когда позиция спецификации накладной/акта полностью распределена (с учетом предыдущих оплат) и дата регистрируемого платежа меньше либо равна дате накладной/акта. При этом количество по позиции передается полное, а сумма предыдущих оплат накапливается в поле "Сумма по чеку предоплатой". 5) Частичный расчет и кредит (значение = 5) - когда позиция спецификации накладной/акта распределена частично (с учетом предыдущих оплат) и дата регистрируемого платежа меньше либо равна дате накладной/акта. При этом количество по позиции передается полное, сумма предыдущих оплат накапливается в поле "Сумма по чеку предоплатой", а неоплаченная сумма по позиции накапливается в поле "Сумма по чеку постоплатой". 6) Передача в кредит (значение = 6) - на данный момент режим не обрабатывается. 7) Оплата кредита (значение = 7) - когда есть распределение по позиции спецификации накладной/акта и дата регистрируемого платежа больше даты отгрузки. При этом этом количество передается оплаченное непосредственно этим платежом. В окне регистрации в ККТ, все поля кроме "Позиция", "%НДС" и "Вх." являются редактируемыми. После нажатия на кнопку "Продолжить" (окно регистрации в ККТ), все отобранные позиции передаются в ККТ с помощью точки расширения №2. Для каждой позиции передается так же ее тип распределения и ссылка на позицию распределения. В частности если распределение по позициям ДО, то передается значение "1" и ссылка на запись PlDgDist.NRec. А если распределение по позициям накладной/акта, то предается значение "2" и ссылка на запись SpSopHoz.Nrec. По завершении обработки всех позиций, вызывается точка расширения №3, которая кроме основных параметров передает сумму по чеку предоплатой и сумму по чеку постоплатой. Сумма по чеку встречным представлением на данный момент не используется и передается значение ноль. После завершения обработки, в документе выполняется установка соответствующего статуса. Для документа должны быть заведены как минимум два статуса в группе исполняемых статусов. 1) "Регистрация аванса/предоплаты ККТ" (наименование может быть указано любое) со значением в поле код = 5. 2) "Завершена регистрация ККТ" (наименование может быть указано любое) со значением в поле код = "4". В случае, если по документу была зарегистрирована хотя бы одна позиция со значениями способа расчета "предоплата 100%", "предоплата" или "аванс", то в документе будет устанавливаться статус №1. При этом из данного статуса разрешена повторная регистрация ККТ. В противном случае, после выполнения регистрации, в документе устанавливается статус №2.
102.1929329.1.120.0Рантайм при копировании платежных порученийФинансово-расчетные операцииПлатежное поручение
Рантайм при копировании платежных поручений. ФРО/Документы/Платежные поручения/Собственные. Выбираем ранее сформированное платежное поручение, запоминаем его: "CTRL-F2" и копируем: "CTRL-F3" По окончании процедуры копирования и редактирования вновь созданного платежного поручения (п/п), приступаем к созданию нового п/п, используя прием, описанный выше. Когда количество действий, связанных с использованием упомянутой функции копирования достигает или превышает трех, получаем сообщения об ошибках: Rinetime error 216 или Runtime error 213 Описание и отчет о компонентах во вложении. На тестевой базе проблемам повторяется.Исправлен рантайм при копировании ПП.
101.661169.1.120.0Огромные задержки при работе с бухгалтерскими справкамиФинансово-расчетные операцииБухгалтерская справка
после обновления возникла проблема при работе с бухгалтерскими справками. Суть проблемы заключается в том, что при попытке открытия бухсправок с большим количеством хозопераций происходит "зависание" интерфейсов, при этом наблюдается значительная нагрузка на сеть. После прогрузки интерфейсов и попытке их закрытия Галактика "зависает" на крайне продолжительное время. (Под зависанием, в данном контексте, подразумевал именно продолжительное время ожидания между командой на запуск интерфейса и его отображением на экране.При этом, главное окно Галактики полностью перестает отвечать на запросы, при наблюдаемой в диспетчере задач сетевой активности.) На сервере для таблиц oborot, hozoper, plpor было произведено перестроение индексов и обновление статистики, что никакого результата не дало. на фтп ftp://user:login@ftp.galaktika.ru в папке 2.155953 лежат сил протоколы Открытие списка бух справок.rar: логи сформированные при открытии интерфейса F_PLPOR::PLPOR файлы трассировки профайлером MSSQL в момент открытия списка бухсправок. OpenPLPor.rar Открытие конкретной бухсправки.rar: логи сформированные при открытии окна WIPLDOCEDIT интерфейса F_PLPOR::PLPOR сводный во вложенииВ интерфейсе настроек "Настройки Галактики Бухгалтерский контур Обработка документов Параметры работы с документами различных типов", на вкладке "Автоинициализация полей" добавлено поле "Отображать разноску по ФОБ в документах", со значением по умолчанию "Да". Данная настройка влияет на видимость колонки признака распределения документа по ФО в каталоге документов. Для отображения значения данного поля, выполняется пробежка по всем хозоперациям документа и проверка наличия связи с ФО и затем соответствующий результат выводится в колонке. Для бух.справок необходимо отключить отображение данного поля (если потребность в данном поле отсутствует, то его можно отключить для всех документов). В каталоге платежных документов, в окне редактирования платежного и в окне редактирования хозяйственных операций документа отключена автоинициализация закладок "Статьи бюджета" и "Оплаты". Расчеты для данных закладок выполняются только при их активации. Следует отметить, замедления связанные с закрытием окна редактирования документа, происходит из-за включенных следующих настроек интерфейса настроек "Настройки Галактики Бухгалтерский контур Обработка документов Параметры работы с документами различных типов": - Проверять распределение платежа по ДО. - Проверять формирование счет-фактур. Данные настройки следуют отключить для бух.справок.
102.1700689.1.119.0Увеличить размерность поля PLPOR.NOCHEK3(номер исполнительного документа)Финансово-расчетные операцииСводное платежное требование
При следующей докомпиляции словаря необходимо увеличить размерности поля PLPOR.NOCHEK3 с 15 хотя бы до 100 символов. В данное поле вносится информация об исполнительном документе, которая в последующем "попадает" в печатную форму сводного платежного требования(см. Вложение). Проблема в том, что в этой форме, в графе "Номер и дата исполнительного документа (при наличии)" кроме номера и даты необходимо отображать и название исполнительного документа (например, исполнительная надпись, судебный приказ и т.д.), а в 15 символов все вместить проблематично... Клиент ссылается на постановления национального банка РБ № 66.На форму платежного требования (для РБ) добавлено поле "Тип документа" (PlPor.Append, 255 символов), после даты исполнительного документа (без метки). В печатных формах сводного ПТ (RTF/бизнес-текст) данное поле печатается перед номером и датой исполнительного документа
101.660039.1.118.0Онлайн-кассы - необходимо регистрировать в ККТ авансы по ДО с учетом скидкиКассаПриходный кассовый ордер
Сейчас при регистрации в ККТ аванса по ДО в результате решения ПиР 101.62385 в точку расширения передаются полные суммы стоимости и НДС по каждой позиции спецификации ДО. Но у клиента по ДО часто предоставляются скидки, поэтому необходимо передавать суммы с учётом этих скидок (по всему ДО и по позиции). Сейчас они вынуждены делать по таким ДО фиктивный акт - для распределения по нему платежа с учётом скидок. А в новых форматах ФД 1.05/1.1 так поступать уже нельзя, поскольку при наличии акта мы не сможем правильно сформировать реквизит 1214 "признак способа расчёта" - предоплата, или аванс (ПиР 101.65991). Возможно, в новых точках расширения для ФФД 1.05/1.1 имеет смысл дополнительно передавать и полные суммы (например, для возможности отражения суммы скидки в чеке).При выполнении регистрации в ККТ аванса по ДО, в точку расширения передаются оплаченные суммы стоимости позиций ДО с учетом скидок (как по всему ДО, так и по позиции).
101.624029.1.118.0Онлайн-кассы - необходимо распределение платежа по позициям ДО (для предоплат по ДО)КассаПриходный кассовый ордер
Продолжение ПиР 101.62385 (см. п.3). Согласно п.1 статьи 4.7 54-ФЗ: 1. Кассовый чек и бланк строгой отчетности содержат, за исключением случаев, установленных настоящим Федеральным законом, следующие обязательные реквизиты: ..... наименование товаров, работ, услуг (если объем и список услуг возможно определить в момент оплаты). У некоторых клиентов практикуются авансовые платежи по ДО (когда оплачивают по ДО, но в момент оплаты ещё нет сопроводительного документа). Таким образом, необходимо передавать в ККТ оплачиваемые позиции ДО.Доработано распределение по спецификации ДО. 1) Изменен формат отображения вкладки "Оплата МЦ/услуг ДО" окна редактирования хозяйственной операции. Основное отличие заключается в добавление полей "Опл.кол-во" и "Опл.сумма", в которых отображается оплаченное количества и сумма по позиции. 2) В окне распределения по позиция ДО появились поля "Опл. кол-во" и "Кол-во оплаты". Данные поля являются вычисляемыми и рассчитываются на основании текущей оплаченной суммы по позиции спецификации ДО. 3) Поле "Кол-во оплаты" редактируемое. Для распределения относящегося к текущей хозоперации можно указать количество оплаты, на основании которого будет рассчитана соответствующая сумма оплаты. Доработана регистрация в ККТ. Раньше, если привязано ДО без накладных, в кассовый аппарат передавались данные по всем позициям ДО. Теперь выполняется контроль распределения по спецификации ДО. Если распределение по позициям ДО отсутствует, то выполнение регистрации в ККТ невозможно. А если распределение присутствует, то в ККТ передаются только распределенные позиции спецификации ДО.