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


Описание файла обновления:
ФайлF_PLPOR_RES_911530.TXT
ОбновлениеF_PlPor_RES_911530
Назначение
ПродуктГалактика ERP 9.1
Релиз
КомпонентRES F_PlPor
Тип
Версия9.1.153.0
Дата2020-02-15 19:43:33
Проблема ПИРПервое решениеОписаниеПроектДетализация
Что изменено:Как изменено:
NEWГалактика ERP Финконтур ФРО Документы Платежное поручение Формирование возврата платежа
Убрано предупреждение «Сумма по платежному документу частично распределена по ДО, возврат возможен на сумму…» из реестра ПП при выполнении меню «Формирование возврата платежа», когда нет привязки/распределения по ДО.Добавлена дополнительная проверка сумм возвращённых или разнесенных с суммой платежа по платёжному документу
9.1.152.0ФРО Документы Платежное поручение
Подключить хелп-топик к функционалу установки даты оплатыПодключен хелп-топик к функционалу установки даты оплаты
9.1.151.0Галактика ERP Финконтур ФРО Документы Платежное поручение
При привязке нескольких ДО в платежном поручении в назначении платежа используется не вся длина для заполнения.Доработан механизм заполнения назначения платежа при выборе нескольких ДО. В назначении платежа заполняется текст допустимой длины 100 символов. Для системных типов документов 1,2,32,37 также информация переносится и в 3-ю строку.
9.1.151.0Бухгалтерская отчетность Отчеты Электронная отчетность (РФ) Налоговая отчетность
Необходимо ускорить формирование разделов 8, 9, 10 для отчета "Декларация по НДС"Оптимизирован процесс формирования разделов 8, 9, 10 для отчета "Декларация по НДС"
9.1.151.0Галактика ERP Финконтур Касса Документы Расходный кассовый ордер
F_PlPor - добавлен параметр дата, который будет передаваться в интерфейс Лицевые счета. F_OFP - добавлен параметр дата, который будет передаваться в интерфейс Лицевые счета. F_Podot - добавлен параметр дата, который будет передаваться в интерфейс Лицевые счета. z_Staff - В интерфейс принимается дата, по которой будут выводится неуволенные сотрудники.Добавлен фильтр третьим пунктом. Добавлен параметр во всех вхождениях интерфейса. Добавлена проверка на активность bounds. Добавлены тайтлы для фильтра. Изменены help-константы в интерфейсе.
9.1.150.0Настройки Галактики Бухгалтерский контур Касса Онлайн-ККТ
Подключить help-константу NastrBuch_OnlainKKT к разделу настроек "Онлайн-ККТ", а также ко всем настройкам и подразделам, расположенным в разделе "Онлайн-ККТ".Подключена help-константа NastrBuch_OnlainKKT к разделу настроек "Онлайн-ККТ", а также ко всем настройкам и подразделам, расположенным в разделе "Онлайн-ККТ".
9.1.150.0Галактика ERP Финконтур Касса Документы Приходный кассовый ордер
В ветку "Настройки Галактики Бухгалтерский контур Касса Онлайн-ККТ" добавить пользовательскую настройку "Номер COM-порта" - для использования в интеграционном компоненте. Вместо 0 визуализировать "по умолчанию". И предлагаю изменить порядок настроек: Выполнять регистрацию в ККТ Разрешать закрытие смены в ККТ Пароль оператора для ККТ Номер COM-порта Отображать системный интерфейс регистрации в ККТ Пароль администратора для ККТВ ветку "Настройки Галактики Бухгалтерский контур Касса Онлайн-ККТ" добавлена пользовательская настройка "Номер COM-порта". До выбора конкретного значения, отображется "по умолчанию", соответствующее значению 0. Установлен порядок настроек: Выполнять регистрацию в ККТ Разрешать закрытие смены в ККТ Пароль оператора для ККТ Номер COM-порта Отображать системный интерфейс регистрации в ККТ Пароль администратора для ККТ
9.1.150.0Галактика ERP Финконтур ФРО Документы Платежное поручение
Доработать функцию установки даты оплаты в платежном документеДоработан пакетный режим установки даты оплаты. При вызове функции "Установить дату оплаты" открывается окно с параметрами "Назначение платежа" - "не изменять/формировать согласно настройкам" и "Дата оплаты" - "по дате выписки/указанная дата". При ручном изменении даты оплаты механизм обработки не изменился.
9.1.149.0Галактика ERP Финконтур ФРО Документы Бухгалтерская справка
Необходимо подключить существующие точки расширения ФФД 1.05 и для бухсправок (PlPor.TiDkGal = 10).ФРО. Покдлючена регистрация ККТ для бухсправок. Данная операция доступна через пункт локального меню "Регистрация в ККТ" (пункт меню доступен только для физ.лиц). Если направление "не определено", то работает так, как если выбрана "продажа". Переименованы настройки статусов "Настройки Галактики Бухгалтерский контур Касса Онлайн-ККТ Статусы документов при регистрации "платежных поручений" на "платежных поручений (бухгалтерских справок)".
9.1.149.0Нет
Новая версия накопительного обновления словаря Галактика ERP 9.1 Alter_CumulativeВнесены изменения в словарь БД Галактики ERP 9.1
101.66680 * ЗАДАЧА В JIRA: ERP-13469.1.148.0Галактика ERP Финконтур Касса Документы Приходный кассовый ордер
- Необходимо обособить настройки по ККТ. - Необходимо добавить новый режим (ПЕРЕДАЧА В КРЕДИТ) регистрации ККТ.Настройки. - Добавлена ветка “Касса - Онлайн-ККТ. - Все настройки, относящиеся к ККТ, перенесены в отдельную ветку настроек "Онлайн-ККТ" внутри ветки "Касса". - Добавлена ветка “Касса - Онлайн-ККТ - Статусы документов при регистрации“. - Добавлены новые настройки: * “Статус кассовых ордеров при регистрации предоплат и авансов“; * “Статус кассовых ордеров при окончательной регистрации“; * “Статус платежных поручений при регистрации предоплат и авансов“; * “Статус платежных поручений при окончательной регистрации“; * “Статус накладных/актов при регистрации операции “Передача в кредит“. - Реализован конвертер для автозаполнения новых настроек, кроме последней. Заполнение осуществляется на основании статусов с кодами "4" и "5". Регистрация ККТ. - Реализован новый режим регистрации ККТ. Данный режим работает в случае, если дата проведения не заполнена в ордере/платежном поручении и, соответственно, отсутсвует распределение. Регистрация проводится на основании накладных из документов-оснований платежного/кассового документа. При регистрации осуществляет контроль на статус у накладных относительно статуса из настройки “Статус накладных/актов при регистрации операции “Передача в кредит“, который устанавливается после регистрации во избежание повторной регистрации по той же накладной. - Новый режим так же работает в случае наличия распределения по накладным не на всю спецификацию. - При регистрации по распределеню спецификации накладных для определения признака "полный расчет" или "частичный расчет и кредит" кол-во по позиции подсчитывается с учетом всех распределений (не только в данном платежном документе) данной позиции.
9.1.147.0Галактика ERP Финконтур Касса Документы Расходный кассовый ордер
Регистрация ККТ. РКО. 1. Рекламация. «Бухгалтерский контур Обработка документов Распределение платежа по ДО Распределение платежа по сопроводительным документам - Распределять платеж по рекламационным накладным» = «НЕТ». Распределение не производится. Однако, при нажатии кнопки регистрации ККТ создается ошибочная позиция распределения с признаком регистрации ККТ. 2. Исправительная. При регистрации с типом кредит формируются отрицательные суммы.Регистрация ККТ. РКО. 1. Рекламация. При регистрации более не формируется ошибочное распределение. 2. Исправительная. При регистрации по распределению накладных суммы ХО/кол-во позиций формируются со знаком "+".
9.1.146.0Управление договорами Документы Договоры
В окне редактирования договора функция «Просмотр документов» - Платежи необходимо обеспечить печать платежного поручения, поскольку пользователю установлен запрет на редактирование чужих документов , но платежи в договоре он и так видит и должен иметь возможность их распечатать.Добавлена функция в локальное меню окна "Платежи" "Печать документов. Тип RTF.
9.1.145.0Нет
Необходимо переименовать файл: typetbl.vpp - typetbl.inc tabmem.vpp - tabmem.tbl FinTypes.vpp - FinTypes.incФайлы переименованы. Необходимые изменения в исходные тексты внесены.
9.1.145.0Галактика ERP Финконтур Документы
Дата в окне "Формирование возврата платежа" по умолчанию текущая. Добавил диалоговое сообщение для пользователя.При формировании возврата платежа после нажатия кнопки "Сформировать" проверяется дата оплаты платежа. Если пользователь ввёл дату меньше текущей даты, то пользователю выводится предупреждение о том, что дата обработки не может быть меньше даты формирования. Пользователю предлагается приравнять дату обработки с датой формирования документа. Если пользователь нажмёт "Нет", то диалоговое окно закроется и мы вернёмся к окну "Формирование возврата платежа" без каких-либо изменений. При нажатии "Да" дата в сформированном документе будет такая, как указал пользователь.
9.1.144.0Галактика ERP Финконтур ФРО Документы Платежное поручение
<ФРО-Документы-Платежное поручение> Добавлено: -настройка "Настройки Галактики Бухгалтерский контур Обработка документов Разрешить модификацию внешних атрибутов при наличии проводок"; -запрет редактирования внешних атрибутов платежных поручений при наличии сформированных проводок.Доработка существующего функционала.
180.10933 * ЗАДАЧА В JIRA: ERP-8109.1.144.0ФРО Документы Платежные поручения Сторонние
Добавить пользовательскую настройку "Запрет возврата хозяйственных операций разнесенных по ДО" со значениями "да"/"нет" и значением по умолчанию "нет".Добавлена настройка : Бухгалтерский контур - Обработка документов - Распределение платежа по ДО-"Запрет возврата хозяйственных операций разнесенных по ДО". Если настройка установлена в значение нет - работает как и раньше. Если установлена в значение "Да": - Если сумма частично распределена по ДО, то по запросу можно сформировать возврат на нераспределенную сумму. - Если сумма полностью распределена, то возврат не возможен.
9.1.143.0Касса > Документы > Приходный кассовый ордер
Подключить help-константу Kassa_KORegKKT к кнопке "Регистрация в ККТ" и окну "Регистрация в ККТ" (ко всем элементам окна и локальным функциям, вызываемым из данного окна).Подключена help-константа Kassa_KORegKKT к кнопке "Регистрация в ККТ" и окну "Регистрация в ККТ" (ко всем элементам окна и локальным функциям, вызываемым из данного окна). Убраны не несущие смысл подсказки с таблиц.
9.1.142.0Галактика ERP Финконтур ФРО Операции Реестры по перечислениям
Галактика ERP Финконтур ФРО Операции Реестры по перечислениям 1. Необходимо снять контроль в случае наличия ПП без даты оплаты. 2. Необходимо изменить подход к блокировке спецификации. Статус строка должна оставаться той же, а действия блокироваться в случае отсутствия доступа.Галактика ERP Финконтур ФРО Операции Реестры по перечислениям 1. Снят контроль в случае наличия ПП без даты оплаты. 2. Изменен подход к блокировке спецификации. Статус строка более не меняется из-за отсутствия доступа, блокируются сами действия (добавление/удаление).
9.1.142.0Нет
Новая версия накопительного обновления словаря Галактика ERP 9.1 Alter_CumulativeВнесены изменения в словарь БД Галактики ERP 9.1
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. Если по ДО есть накладные/акты, то распределение по позициям спецификации накладных/актов будет запускаться только для накладных, по которым отсутствует распределение по текущей хозоперации. После завершения распределения по спецификациям выполняется регистрация в ККТ.