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


Описание файла обновления:
ФайлF_SOPRHOZ_RES_911170.TXT
ОбновлениеF_SoprHoz_RES_911170
Назначение
ПродуктГалактика ERP 9.1
Релиз
КомпонентRES F_SoprHoz
Тип
Версия9.1.117.0
Дата2019-10-29 23:44:01
Проблема ПИРПервое решениеОписаниеПроектДетализация
Что изменено:Как изменено:
180.10933 * ЗАДАЧА В JIRA: ERP-810NEWФРО Документы Платежные поручения Сторонние
Добавить пользовательскую настройку "Запрет возврата хозяйственных операций разнесенных по ДО" со значениями "да"/"нет" и значением по умолчанию "нет".Добавлена настройка : Бухгалтерский контур - Обработка документов - Распределение платежа по ДО-"Запрет возврата хозяйственных операций разнесенных по ДО". Если настройка установлена в значение нет - работает как и раньше. Если установлена в значение "Да": - Если сумма частично распределена по ДО, то по запросу можно сформировать возврат на нераспределенную сумму. - Если сумма полностью распределена, то возврат не возможен.
101.66591 * ЗАДАЧА В JIRA: ERP-383NEWГалактика ERP Финконтур Хозоперации Операции Разноска хозяйственных операций Разноска ТХО по ви
<Хозоперации-Операции-Разноска хоз. операций-Складские операции-Приходный/Расходный складской ордер> Добавлен: - колонки "Объект ЦУ", "КАУ1" - "КАУ10". - функция, которая следит за отображением колонок, а так же меняет их наименование, в зависимости от настройки.Доработка существующего функционала. Изменено: -отображение колонок (для "Объект ЦУ", "КАУ1" - "КАУ10").
NEWРасчеты с поставщиками и получателями Операции Пакетное распределение платежей
В рамках задач erp-592 и erp-593 решались задачи по увеличению быстродействия пакетного распределение платежей и пакетного формирования счетов-фактур. По результатам проверки по первой задаче, т.е. распределению платежей, роста быстродействия не достигнуто. Необходимо рассмотреть возможность ускорения работы.В интерфейсе PlDocDistr переработана функция _DoFind_All_By_KatOrg В частности первичный отбор накладных идет для MSSQL и Oracle идет на DSQL. Обработку на DSQL для этого интерфейса можно отключить добавив в cfg параметр {PlDocDistr} USeDSQL = False Возможно будет даже шустрей.
9.1.116.0Нет
Новая версия накопительного обновления словаря Галактика ERP 9.1 Alter_CumulativeВнесены изменения в словарь БД Галактики ERP 9.1
9.1.115.0ФРО Документы Платежные поручения
Необходимо возможность контролировать центры-ответственности у документа-основания и платежа при ручной привязке.Добавлена системная настройка "Настройки Галактики Бухгалтерский контур Обработка документов Распределение платежа по ДО Проверять совпадение ЦО при распределении платежа по ДО". Настройка имеет 3 варианта значения ("нет", "да", "по запросу"). * При значении "нет" (по умолчанию) контроль отсутствует. * При значении "да", при ручном выборе ДО в платеже срабатывает контроль на совпадени ЦО. Если ЦО у ДО и платежа не совпадают, платеж по данному ДО не будет распределен. После проверки всех ДО, если по каким-то из ДО платеж не был распределен, будет выведено сообщение "Платеж был распределен не по всем ДО из-за несоответствия центров ответственности!". * При значении "по запросу", при несовпадении ЦО у ДО и платежа будет выведено предупреждение "Центр ответственности документа-основания № ХХХХ не соответствует центру ответственности платежа! Распределить?". Фокус на кнопке "нет". При ответе "да" платеж распределится, при ответе "нет" не распределится. В случае, если ЦО у всех выбранных ДО не совпал с платежом, выведется сообщение "Платеж не распределен из-за несоответствия центров ответственности!".
101.67630 * ЗАДАЧА В JIRA: ERP-5729.1.113.0Управление сбытом Документы Накладные на отпуск
Высвобождение платежа по исправительной накладной при формировании ордеровДобавлена настройка "Общие настройки системыЛогистикаУправление сбытомНакладная на отпускМодификация и контроль данныхВысвобождать платеж при формировании ордеров по исправительным документам" Если настройка установлена в Да, то при формировании складских ордеров выполняется высвобождение платежа.
9.1.112.0Галактика ERP Финконтур ФРО Документы Платежное поручение
Если в ПП указана сумма, потом выбираются ДО ровно на эту сумму, то в системе создаются лишние записи. Если в ПП не указана сумма и выбираются несколько ДО, то в системе все равно создаются лишние записи.Исправлена ошибка, в результате которой некорректно разбивались фин.документы/хоз.операции при привязке ДО.
101.67719 * ЗАДАЧА В JIRA: ERP-6699.1.111.0Сервис Настройка Параметры В разделе «System»
Если параметр System.UseBrowserCacheAndSort = False, то система не корректно отрабатывает выбор раздела, например в разноске хозопераций по бухсправкам при выборе раздела (Хозоперации - Операции - Разноска хозяйственных операций - ФРО), в курсовых разницах и так далее. Проявляется на субд Oracle. Замечено что типы бухсправок при выключении параметра начинают двоятся и если выбрать "правильную", то выбор срабатывает корректно.Переработан интерфейс выбора разделов рассчетныъ счетов, касс, бухсправок F_CASHBANK::SELUSDOC. Добавлено дополнительной обновление экрана. Добавлено использование fpLog.
101.676149.1.110.0Сообщение о разнице в суммах при привязке ДО к п/п.Финансово-расчетные операцииПлатежное поручение
Сообщение о разнице в суммах при привязке ДО к п/п. При формировании собственных п/п , в момент привязки к п/п документа-основания, если сумма по ДО меньше чем сумма по п/п, система не предупреждает о разнице в этих суммах. До установки обновлений (25.04.2019) в таком случае система сообщала (см. скрин во вложении). Клиент просит вернуть такую проверку.Добавлена настройка Fin.Doc.Prm.DOMakeFreeOstOnChoose Бухгалтерский контур Обработка документов Распределение платежа по ДО При одиночном выборе ДО в ПП при превышении суммы Платежа над остатком ДО формировать хозоперацию на разницу При установке в нет возвращается старый механизм привязки ДО к хозоперации без формирования записи в хозоперации на сумму превышения платежа над остатком по ДО, что в свою очередь приводит к выдаче сообщения : ------------------------- Сумма по документу (40000.00) и сумма хозяйственных операций со знаком "+" по нему (1500.00) не совпадают (по документу нет проводок). Скорректировать сумму документа? -------------------------------
103.100069.1.108.0Потеря преемственности. Перестала работать множественная привязка к одному ППФинансово-расчетные операцииПлатежное поручение
Потеря преемственности. Перестала работать множественная привязка к одному ПП. Описание проблемы от клиента - во вложении. "... После выбора контрагента и перехода в интерфейс выбора Основания в верху окна, помечаем несколько ДО для привязки. В результате привязывается только одно, на меньшую сумму." Изначально в ПП сумма не указана, после выбора нескольких ДО сумма по ним автоматически формировалась как "Сумма платежа" в ПП Режим формирования суммы платежа по ДО (Alt+D) = "Сумма по ДО" У нас на тесте подтвердилась. Выяснили , что внесено обновлением F_SoprHoz.res версии 9.1.104Не обновлялись ссылки на ДО при предоплате. Вероятно этот блок был утерян с прошлой реализации распределения. Исправлено.
101.675479.1.108.0Диадок. При настройке запрета редактирования документов полученныхотправленных через Диадок надо оставить возможность привязки ТХО.Управление сбытомРабота с Контур.Диадок
Диадок. При настройке запрета редактирования документов полученныхотправленных через Диадок надо оставить возможность привязки ТХО. Разрешать модификацию документов, отправленных через Диадок - да Разрешать модификацию документов, полученных через Диадок - даДобавлена настройка DIADOC.ALWAYSENABLECHOOSEHOZOPER Общие настройки системы Работа с Контур.Диадок При привязке Хозоперации не проверять прохождение через Диадок При включении при выборе хозоперации в окне редактирования сопроводительных документов значение настроек "Разрешать модификацию документов, отправленных через Диадок" и "Разрешать модификацию документов, полученных через Диадок" не проверяется. Изменились объектные описания DiadocFuncs.vih, DiadocFuncsExt.vih
106.107059.1.107.0потеря преемственности. Привязка нескольких ДО вал-НДЕ к платежкеФинансово-расчетные операцииПлатежное поручение
потеря преемственности. Привязка нескольких ДО вал-НДЕ к платежке В проблеме 102.201118 была решена проблема множественной привязки ДО к платежу. НО проблема решена только для рублевых ДО Для ДО вал-НДЕ проблема не решена - привязывается только один ДО и сумма делиться по нему хаотично Пример во вложенном файлесумма долга по ДО должна быть в валюте, пересекается с ПИР 103.10006 иначе неверно считается остаток долга , а при abs(round(Pick.PickKol,4) - получаем зависание и космические суммы
102.2017069.1.107.0Многократно повторяющееся модальное окно с предупреждением о расхождении между датой хозоперации и датой проводкиСкладской учетПриходные ордера
Многократно повторяющееся модальное окно с предупреждением о расхождении между датой хозоперации и датой проводки Моделировать ситуацию не удалось, сообщается со слов клиента: При работе с определенными приходными ордерами появляется модальное окно "Предупреждение Дата проводок не совпадает с датой хозяйственной операции". Приходный ордер создан из накладной, в ордере операций, проводок и алгоритмов нет. В накладной одна операция и три проводки (даты проводок расходятся с датой операции), с просмотром накладной проблем нет. Для закрытия модального окна необходимо несколько сот раз нажать "Нет", "Нет для всех", "Отмена", видимой разницы нет. Более простой вариант - удерживать клавишу Esc, но можно проскочить и закрыть все интерфейсы. Проблема проявляется ежемесячно на некоторых документах. Последовательность действий для проявления проблемы у клиента: Запустить Галактику -> Складской учет -> Приходные ордера -> Встать в поле номера ордера -> набрать номер проблемного ордера -> нажать Enter. Выставлена настройка проверки соответствий дат хозопераций и проводок (Настройки Галактики -> Бухгалтерский контур -> Обработка документов -> Хозяйственные операции и бухгалтерские проводки -> Проверять соответствие дат проведения проводок и хозоперации -> Да), менять настройку клиент не хочет. Во вложении: информация о системе, лог, статистика обращений к настройкам, скриншоты проблемы и обращения к документам.1. Убрана постоянная загрузка/выгрузка iChkSH в SHmanager 2. Добавлено запоминание ответов на вопрос "Да Для все", "Нет, для всех" по системному типу документа. Следует помнить, что ответы на эти вопросы будут сохранены да закрытия всех интерфейсов. 3. Для "Да", "Нет" ответы сохраняются пока обрабатывается текущая хозоперация
102.2011189.1.106.0Неправильное формирование платежки по нескольким ДОФинансово-расчетные операцииПлатежное поручение
После установки обновлений возникла проблема с формированием платежного поручения по нескольким ДО. Создаем платежное поручение, в окне привязки ДО помечаем три ДО, алгоритм определения задолженности - по платежам. К каждому ДО сформирована накладная на сумму ДО. Других платежей к ДО нет. Описание пользователя со скринами и отчет о компонентах (на которых проблема повторяется) во вложении. На тестевой базе повторяется (вложила отчет о компонентах на которых проблема не повторяется).Исправлено.
102.1997209.1.105.0Разноска хоз. операций. Выход за границы массива при отсутствии документов, удовлетворяющим заданным ограничениям.ХозоперацииРазноска ТХО "Все документы"
Разноска хозяйственных операций -> Учет спецоборудования и спецоснастки -> Возврат из использования -> "Отсутствуют документы, удовлетворяющие заданным ограничениям: ([Приход, ввод в эксплуатацию спецоснастки]<Возврат из использования>) Изменить ограничения?" -> [Да] -> "Выход за границы массива."Исправлено
102.2010879.1.105.0Сбрасывается валюта при распределении валютного платежа на валютно-рублевый ДОРасчеты с поставщиками и получателямиПакетное распределение платежей
При распределении валютной платежки по валютно-рублевому ДО появляется сообщение: Документ не может быть валютным. В Все хозяйственные операции и проводки по ним в выполнены в НДЕ. хотя валюта в ХО есть. И если ответить Да - валюта в документе сбрасывается.Исправлено.
102.1661109.1.105.0На алгоритм PAYDIFFRATE не должно влиять распределение по складамХозоперацииРазноска ТХО по видам документов /укажите тип документа/
По накладной распределен частичный платеж, т.е имеется закрытая платежом часть суммы. При этом, если МЦ по накладной оприходованы, т.е. имеется распределение по разрезу оприходования алгоритм в режиме &Vip_[Obj:"PAYDIFFRATE"][Рез:НеРаспр] - не находит незакрытую часть суммы накладной. Необходимо, чтобы работа алгоритма зависела только от распределения платежа, но не зависела от распределения по разрезу оприходованияИсправлена работа &Vip_[Obj:"PAYDIFFRATE"][Рез:НеРаспр] для обработки накладных c распределением по складам
102.1852329.1.105.0Привязка ТХО к документам логистикиХозоперацииРазноска ТХО по видам документов /укажите тип документа/
Следующий бизнес-процесс: Одни пользователи создают накладные в галактике, тхо не привязывают (нет поля операция и модуль хозоперации скрыт), другие пользователи могут как создавать накладные, так и привязывать ТХО к накладным. Для того чтобы случайно пользователи не меняли чужие документы стоит общая настройка: свои изменение, по всем-чтение. В то же время по привязке ТХО стоят полные права. Но пользователи, ответственные за привязку ТХО в модуле Хозоперации, не могут привязать ТХО, выдается сообщение о запрете. Предложение: при запрете редактирования чужих документов, разрешить привязку ТХО в модуле Хозоперации при учете настройки типовые проводки-доступ к формированию ТХО (если все права, то можем привязать ТХО ко всем документам и далее аналогично логике системы).реализовано только в модуле ХозОперации если настройка: "Настройки Галактики Бухгалтерский контур Типовые проводки Доступ к формированию проводок" - все права то настройка по доступу к документам не анализируется при привязке ТХО
102.1980289.1.104.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.1981709.1.103.0Не работает ручное распределение суммы платежаФинансово-расчетные операцииПлатежное поручение
При установленной настройке, распределять сумму платежа вручную, при привязке ДО к платежному/кассовому документу выполняется распределение по спецификации накладной/акта.Проблема проявляется при включенной настройке "Настройки Галактики Бухгалтерский контур Обработка документов Распределение платежа по ДО Распределение платежа по сопроводительным документам Разбивать платеж по накладным из ДО". Исправлено.
101.666359.1.102.0Потеря быстродействия при формировании хоз.операцийКассаАвансовый отчет
В авансовом отчете при формировании хоз. операций Галактика зависает При этом пользователи, работающие в Галактике с таблицей SOPRHOZ, работать не могут.Проблема с быстродействием была решена удалением и сбором статистики на БД клиента. Однако было выявлено дублирование выполнения одного из запросов, при выполнении операции удаления хозяйственной операции. Лишняя дублирующая модификация хозяйственной операции была устранена.
102.1972319.1.102.0Пометка записей только СФОХозоперацииРазноска ТХО по видам документов /укажите тип документа/
В Пир 102.192119 предлагалось разделить хозоперации СФО и спецоснастки, но выяснилось, что в настоящий момент это очень трудозатратно, поэтому предлагаю: Реализовать возможность автоматической пометки записей относящихся только к СФО, либо только к спецоснастке. Можно путем добавления отдельного пункта локального меню, а можно добавить параметр в уже существующий интерфейс "Пометка записей". Функционал необходим для всех документов раздела "Учет спецоснастки".В пометку по "+" добавлен параметр: [.] Спецоснастка/Спецодежда` .@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
102.1958879.1.102.0Онлайн кассы - после перепривязки авансового платежа к ДО с реальной отгрузкой он не учитывается как предоплата при частичной n-ой оплатеКассаПриходный кассовый ордер
Онлайн кассы - после перепривязки авансового платежа к ДО с реальной отгрузкой он не учитывается как предоплата при частичной n-ой оплате. см. ПИР 101.66474В стандартном окне редактирования хозяйственной операции добавлено поле "Источник хозоперации", которое отображает информацию о наличии связи с другой хозяйственной операцией, а так же позволяет создатьудалитьскорректировать данную связь. При наличии данной связи при регистрации в ККТ осуществляется проверка существования аванса. При выполнении привязки ДО к хозяйственной операции, которая имеет ссылку на источник хозоперации, в случае если выполняется дробление хозяйственной операции, то обе хозоперации сохраняют ссылку на источник хозоперации. Если в результате различных манипуляций с хозяйственными операциями произойдет потеря ссылки на источник хозоперации (а такая ситуация допустима), то для корректной обработки авансов в ККТ пользователю необходимо вручную указать ссылку источник хозоперации.
102.1966519.1.101.0Обеспечение корректной работы на докомпилированном словаре Галактики ERP 9.1Предложение по новой функциональности Галактики ERP (по системе в целом)?
Необходимо обеспечить корректную работу ресурсов на докомпилированном словаре Alter_Cumulative 9.1.15.0.Обеспечение корректной работы. Пересобраны ресурсы с учетом изменённых таблиц словаря Alter_Cumulative 9.1.15.0. Комплектность установки ресурсов обеспечена требованиями при установке.
101.664749.1.100.0Онлайн-кассы - после перепривязки авансового платежа к ДО с реальной отгрузкой он не учитывается как предоплатаКассаПриходный кассовый ордер
При продаже подарочной карты (это МЦ с атрибутом "аванс") оформляется ДО с такой позицией, ПКО распределяется на эту МЦ и регистрируется в ККТ как аванс, всё верно. Затем покупатель используя эту подарочную карту приобретает реальные МЦ - оформляется новый ДО с реальной спецификацией. Далее нужно старый (авансовый) ПКО перепривязать к новому (реальному) ДО - для этого в старой хозоперации проставляется "Входит в сумму документа" = "-" и добавляется новая ХО со ссылкой на новый ДО и распределением по позициям накладной. Проблема в том, что сейчас в соответствии с решением ПиР 101.66415 тег 1215 "сумма предоплат по чеку" не формируется, поскольку в новой ХО нет распределения по старому (авансовому) ДО. Предлагается при установке "Входит в сумму документа" = "-" в старой ХО проставлять на неё ссылку в автоматически формируемой новой ХО. Далее при регистрации в ККТ для накопления тега 1215 анализировать не только распределение по ДО регистрируемой новой ХО (ПиР 101.66415), но и распределение по ДО связанной (авансовой) ХО.Алгоритм работы с платежами-авансами следующий. 1. Сначала формируется ДО с авансовыми позициями спецификации (должно содержать только авансовые позиции). 2. Данное ДО привязывается к кассовому ордеру и регистрируется в ККТ как аванс. 3. Затем формируется новое ДО с не авансовыми позициями спецификации. 4. В кассовом ордере, в хозяйственной операции к которой было привязано авансовое ДО необходимо выполнить увод хозоперации в минус с автоматическим созданием хозоперации (должна быть включена настройка "Настройки Галактики Бухгалтерский контур Обработка документов Хозяйственные операции и бухгалтерские проводки Контроль баланса при изменении признака входимости хозоперации"). 5. В автоматически созданной хозоперации отвязываем ДО с авансовыми позициями спецификации и привязываем ДО с реальными позициями. 6. Повторно нажимаем на кнопку регистрации ККТ, в результате выдается сообщение о запрете повторной регистрации аванса. Связано это с тем, что по новому ДО отсутствуют накладные. 7. После формирования накладных по ДО с реальными позициями снова нажимаем на кнопку регистрации ККТ. В результате выполняется следующее: - для хозоперации входящей в сумму документа проверяется наличие хозоперации не входящей в сумму документа и если така хозоперация существует, то проверяется есть ли к ней привязка ДО с авансовыми позициями; - если авансовые позиции существуют, то сумма текущей хозоперации (входящей в сумму документа) накапливается в поле "Сумма по чеку предоплатой", т.к. считается, что все позиции распределенные по текущей хозоперации были зарегистрированы как аванс.
102.1953159.1.100.0Atl5533. Ошибка при печати формы в FR.ХозоперацииРазноска ТХО по видам документов /укажите тип документа/
Atl5533. Ошибка при печати формы в FR F_SOPRHOZ!!SOPRHOZ dts Реестр хозяйственных операций по контрагентам (штрихкод).fp3. F_SOPRHOZ!!SOPRHOZ dts Реестр хозяйственных операций с проводками (штрихкод).fp3 --------------------------- FastReport - Ошибка --------------------------- Были обнаружены следующие ошибки: Memo8: Could not convert variant of type (OleStr) into type (Double) --------------------------- ОК ---------------------------Отчет формируется без ошибок
102.1944339.1.100.0Перенос данных по налогам из ДОФинансово-расчетные операцииВалютное платежное поручение
Для реализации процесса формирования в ЭСЧФ при приобретении услуг у иностранной организации по законодательству РБ (ПИР 102.168343). Необходимо переносить информацию по налогам из валютного ДО снабжения,для случая, когда в самом ДО налоги отсутствуют, но рассчитаны в расширенной информации по позициям спецификации для уплаты в Мин.фин. Подробно - во вложении.В платежных и кассовых документах реализован новый тип налогов - "справочный". Данный налог является автоматическим, но выделяется в отдельную группу в связи с особенностью его формирования. Данный налог формируется автоматически только по ДО без сопроводительных документов либо его можно задать в окне редактирования налогов, указав соответствующий тип. Что бы данный налог сформировался по ДО автоматически, необходимы следующие условия: - контрагент налога в ДО должен отличаться от контрагента ДО. - налог в ДО должен быть сформирован по группе налогов в которой включен параметр "налог является налогом только для таможенной декларации". Таким образом, налог для таможенной декларации в ДО, который визуально можно увидеть только в расширенной информации по позиции спецификации ДО, при привязке ДО к платежному документу, будет формироваться в платежном документу с признаком "справочный" на сумму пропорциональную распределению по ДО.
106.105629.1.100.0Сделать отдельную настройку "Разрешать запрещать создание СФ"Управление сбытомНаши счета-фактуры
Сделать отдельную настройку "Разрешать запрещать создание СФ"Изменены варианты выбора для настройки "Разрешать работу c документами для учета НДС": нет / да / только в сбыте / только в снабжении. Раздел: "Настройки Галактики Логистика Налоги, документы для учета НДС" Примечание. Для того, чтобы изменить тип настройки на пользовательский, необходимо в модуле "Настройка", меню "Настройка - Администратор настроек" выбрать настройку "Разрешать работу c документами для учета НДС" и изменить тип. Для каждого пользователя установить нужное значение настройки.
102.1821919.1.099.0КИС ФХД ТПР2 Очередь1 Функционал переноса НДС из ДО при его заполнении в ФОб не учитывает зачет обязательств по данному ДО и переносит общую сумму НДС, а не сумму задолженностиПлатежный календарьЖурнал обязательств
Ручные налоги нужно дробить при дроблении хозопераций, а так же нужно объединять при объединении хозопераций. ВАЖНО - сумма раздробленных налогов по всем хозоперациям должна ровняться именно сумме ручных налогов, не расчетной сумме налогов, так как зачастую ручные налоги отличаются от расчетных на 1 копейку в большую или меньшую сторону.Реализован функционал разделения и объединения ручных налогов при выполнении разделения или объединения хозяйственных операций. При разделении хозоперации на две, для каждой хозоперации рассчитывается коэффициент изменения суммы по следующей формуле: (Новая сумма хозоперации)/(Первоначальная сумма хозоперации). Для получения новой суммы налога исходной хозоперации, сумма налога умножается на полученный коэффициент и применяется округление. Сумма налога для второй хозоперации получается путем получения разницы между старой суммой налога и новой. При объединении хозяйственных операций ручные налоги объединяются и переносятся в конечную хозоперацию, которая является результатом объединения хозяйственных операций. Функционал дробления/объединения ручных налогов реализован для следующей функциональности: - Пункт локального меню хозяйственных операций "Разделение хозопераций". - Пункт локального меню хозяйственных операций "Объединение хозопераций". - Пункт локального меню хозяйственных операций "Группировка хозяйственных операциий". - Привязка ДО с накладными и без к платежному документу, в результате чего происходит дробление хозяйственных операций. - Группировка хозопераций, вызванная отвязкой ДО. - Группировка хозопераций, вызванная отвязкой договора. - Выполнение зачета обязательств. - Выполнение отмены зачета обязательств. Изменение суммы хозоперации вручную, или в результате синхронизации суммы хозоперации при изменении суммы платежного документа - ручные налоги не корректируются (не дробятся и не объединяются). Если нужно что бы налоги изменялись с изменением суммы хозоперации необходимо воспользоваться функцией разделения или объединения хозопераций.
102.1948109.1.099.0ATL5533. Ошибка при печати отчета FR на атлантисе 5.5.33КассаАвансовый отчет
ATL5533. Ошибка при печати отчета FR на атлантисе 5.5.33 Касса Документы Авансовый отчет печать Реестр документов по текущему фильтру FR Реестр авансовых отчетов (в валюте платежа) Ошибка : Memo35: Could not convert variant of type (UnicodeString) into type (Double)Устранена причина ошибок в FR-формах Реестра авансовых отчетов (в валюте платежа): Memo35: Could not convert variant of type (UnicodeString) into type (Double)
102.1941629.1.099.0Изменение ставки НДС в переходный периодФинансово-расчетные операцииПлатежное поручение
Изменение ставки НДС в переходный период 1.Платеж в 2018г. по ставке 18%. СФ на аванс не сформирован. 2.ДО, накладная, СФ-отгрузка в 2019 году по ставке 20% 3.Привязывается ДО к платежу: ставка в платеже меняется на 20% и СФ на аванс формируется по ставке 20% Настройка "ставки для авансов" в "Параметры работы с документами различных типов" установлена в "ставки из ДО". Установить конкретную группу нельзя, т.к. платежки в 2018 году должны формироваться по ставке 18%, а в 2019- по ставке 20%, т.е. зафиксировать для всех платежей одну ставку нельзя. Пример во вложении.В локальном меню вкладки "Налоги" каталога и окна редактирования платежных документов, а также окна редактирования хозяйственной операции добавлены следующие пункты меню: - Перевод налогов в ручные; - Перевод налогов в автоматические. При выполнении данных пунктов для всех отображаемых на вкладке налогов будет выставлен атрибут ручные или соответственно автоматические. В локальном меню каталога платежных документов (подменю "Прочие...") так же добавлены вышеуказанные пункты меню. Данные операции выполняются как для текущего платежного документа, так и для группы помеченных. Переводить налоги в ручные необходимо для того что бы зафиксировать рассчитанные налоги и что бы они не были пересчитаны по ставке ндс 2019 года. В момент привязки ДО в платежном документе, так же выполняется сравнение даты ДО и даты хозяйственной операции, и если хозоперация находится в 2018 году, а ДО в 2019, то пользователю выдается запрос на выполнение перевода налогов в ручные, что бы выполнить фиксацию налогов. Аналогичная доработка выполнения и в пакетном распределении платежей. При распределение по ДО контролируются даты ДО и хозоперации, а при распределении накладных контролируются дата накладной и хозоперации. Фиксация налогов выполняется так же по запросу и перед привязкой ДО или накладной
102.1936639.1.099.0Формирование СФ из платежного поручения - блокировка по статусу из архиваФинансово-расчетные операцииПлатежное поручение
Формирование СФ из платежного поручения - блокировка по статусу из архива. Формирование документа для учета НДС не является "модификацией документа". И система должна давать формировать СФ из Платежного поручения при запрете редактирования в том числе по настройке "Настройки Галактики Общие настройки системы Работа с электронным архивом Блокировать документ Галактики по статусу из архива" = даИсправлено.
102.1931699.1.098.0Валютная сумма не совпадает с валютной суммой в распределенииФинансово-расчетные операцииВалютное платежное поручение
Когда сумма распределения меньше суммы хоз.операции, возникает запрос на уменьшение суммы хоз.операции. В результате берется распределенная по хоз.операции рублевая сумма, а потом из нее по текущему курсу рассчитывается валютная составляющая суммы. Затем в хозоперацию подставляется рублевая сумма из распределения и рассчитанная валютная сумма. При таких расчетах есть вероятность что валютная сумма не будет совпадать с валютной суммой в распределении. Во вложении пример, когда возникают расхождения, которые не устраивает клиентов. Сумма хозоперации должна совпадать с суммой распределения. Обсуждали с Яковлевым И. Н.После утвердительного ответа на запрос об уменьшении суммы хоз.операции, в валютных платежных документах из распределения берется валютная сумма, а сумма в НДе рассчитывается от нее по курсу. В рублевых платежных документах (даже при наличии ссылки на валюту) из распределения берется сумма в НДЕ, а валютный эквивалент, если он указан, рассчитывается по курсу.
101.659919.1.098.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.1906039.1.098.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г.
101.661169.1.097.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.1872569.1.095.0Перестала считаться сумма по авансовому отчету на основании спецификацииКассаАвансовый отчет
Обновление F_PlPor_res_911100 - перестала считаться сумма по авансовому отчету. По бизнес процессу куратор заполняет только спецификацию авансового отчета и на обновлении F_PlPor_res_911070 пересчитывалась сумма авансового отчета если кликнуть мышкой на шапку документа. Установлена настройка Настройки Галактики Бухгалтерский контур Обработка документов Хозяйственные операции и бухгалтерские проводки Сворачивать одноименные операции в авансовых отчетах" = Да. Проверила проблему на тестовой базе. На обновлении F_PlPor_res_911070 с настройками "Сворачивать одноименные операции в авансовых отчетах"-"да" и "Синхронизировать спецификацию авансового отчета с хозоперацией"-"да" и "нет" в хозоперациях формировалась сумма по спецификации. На обновлении F_PlPor_res_911100 изменились значения настройки ""Синхронизировать спецификацию авансового отчета с хозоперацией" на "не синхронизировать", "по запросу", "автоматически". Ни с одной из настроек сумма расходов по спецификации в Хозоперациях не формируется, поэтому и не появляется запрос на изменение суммы документа.Синхронизация суммы спецификации авансового отчета с хозоперацией осуществляется независимо от значения настройки "Настройки Галактики Бухгалтерский контур Обработка документов Хозяйственные операции и бухгалтерские проводки Сворачивать одноименные операции в авансовых отчетах". Если несколько позиций спецификации АО, при выполнении синхронизации группируются в одну хозоперацию, то каждая из позиций спецификации будет ссылаться на одну и ту же хозоперацию (раньше в таких случаях связь позиции спецификации с хозоперацией не формировалась). При удалении такой хозоперации, ссылка на нее обнуляется во всех относящихся к ней позициях спецификации. Если одна из таких позиций спецификации АО редактируется, то запускается алгоритм синхронизации, в результате которого существующая хозоперация удаляется и формируется новая, с учетом внесенных изменений в текущую позицию спецификации и с учетом группировки в разрезе ТХО.
102.1906129.1.094.0Привязка ТХО к платежным документам при запрете редактирования данных в закрытом периоде бухконтураФинансово-расчетные операцииПлатежное поручение
Привязка ТХО к платежным документам при запрете редактирования данных в закрытом периоде бухконтура Установлены настройки: "Настройки Галактики Бухгалтерский контур Закрытый отчетный период до" = 01.11.2018 "Настройки Галактики Бухгалтерский контур Модификации данных после закрытия периода" = запрещать За октябрь были проводки формирую платежный документ (платежное поручение, бухсправку, кассовый ордер) в открытом периоде бухконтура. При попытке привязать ТХО выдается сообщение "Вводить новые данные или редактировать ранее введенные можно только с датой обработки, не меньшей, чем 01/11/2018г. У записи регистрации документа учета НДС есть проводки закрытом периоде!" Причем документ создан новый, к нему никаких записей о регистрации документов для учета НДС (да и самих документов для учета НДС не создано) Скрины во вложенииПроблема проявляется при условии что настройка "Настройки Галактики Логистика Налоги, документы для учета НДС Формировать хозоперации по книге продаж/покупок" принимает значения равные либо "да" либо "только по регистрируемым в книге", привязка ТХО выполняется из шапки платежного документа и текущая дата попадает в закрытый период. Исправлено.
180.109009.1.093.0в интерфейсе "Исполняемые ДО" в нижней панели не отображаются привязанные платежиФинансово-расчетные операцииПлатежное поручение
более подробное описание во вложенииДля настройки "Настройки Галактики Бухгалтерский контур Обработка документов Распределение платежа по ДО Учитывать при расчете задолженности фин. документы в статусе оформляемый" изменено значение по умолчанию на "да". # ИНСТРУКЦИЯ ПО НАСТРОЙКЕ: Если обновление с патчем проблемы первоисточника уже было установлено, то данные изменения не будут влиять для всех новых пользователей, потому что при добавлении настройки формируется запись для "нулевого" пользователя со значением по умолчанию и данное значение может изменить только администратор. Если патч с проблемой первоисточника не был установлен в системе, то для всех пользователей будет значение по умолчанию "да".
102.1890479.1.093.0Исправить ошибку склонения слова "счет-фактура" в названии настройки.НастройкаНастройка БУХГАЛТЕРСКОГО контура
Исправить ошибку склонения слова "счет-фактура" в названии настройки "Наследовать авансовую СФ при привязке ДО" ("Бухгалтерский контур" > "Обработка документов" > "Распределение платежа по ДО"). Слово "счет-фактура" - существительное мужского рода, поэтому следует писать "Наследовать авансовый СФ при привязке ДО".исправлено
102.1889299.1.092.0Не правильно рассчитывается задолженность по платежамФинансово-расчетные операцииПлатежное поручение
Не правильно рассчитывается задолженность по платежам. При привязке нового платежа не видны платежи, ранее привязанные к ДО. Если изменить "Настройки ГалактикиБухгалтерский контурОбработка документовРаспределение платежа по ДОУчитывать при расчете задолженности оформляемые фин. документы"=да, то сумма платежей отображается корректно. Все платежные поручения оплачены, настройка влиять не должна. Описание пользователя во вложении. Отчет о компонентах во вложении. База на которой проявляется проблема выложена на FTP сервер, в директорию 2.150770.Проблема возникает из-за того, что при выключенной настройке "Учитывать при расчете задолженности оформляемые фин. документы" в расчете задолженности участвовали только документы в исполняемых или закрытых статусам. Документы без статуса или оформляемые не учитывались. Исправлено следующим образом. Переименована настройка "Настройки Галактики Бухгалтерский контур Обработка документов Распределение платежа по ДО Учитывать при расчете задолженности оформляемые фин. документы" в "Учитывать при расчете задолженности неоплаченные фин. документы". Добавлена новая пользовательская настройка "Настройки Галактики Бухгалтерский контур Обработка документов Распределение платежа по ДО Учитывать при расчете задолженности фин. документы в статусе оформляемый" со значением по умолчанию - "нет". Теперь можно отдельно настроить учитывать оплаченные или не оплаченные документы, а так де учитывать или нет документы в статусе оформляемый. В данном конкретном случае пользователям необходимо выключить настройку "Учитывать при расчете задолженности неоплаченные фин. документы" и включить настройку "Учитывать при расчете задолженности фин. документы в статусе оформляемый".
102.1757699.1.091.0КИС ФХД ТПР2 Очередь1 Если к ПП привязан договор, то при выборе контрагента в поле Взаимозачет он не попадает в хозоперацию.Расчеты с поставщиками и получателямиЗачет обязательств
КИС ФХД ТПР2 Очередь1 Если к ПП привязан договор, то при выборе контрагента в поле Взаимозачет он не попадает в хозоперацию.Добавлена пользовательская настройка "Настройки Галактики Бухгалтерский контур Обработка документов Распределение платежа по договорам Наследовать контрагент из договора в хозяйственную операцию" со значением по умолчанию "по запросу". Данная настройка влияет на наследование контрагента договора в хозяйственную операцию платежного документа. Ранее контрагент договора всегда переносился в хозяйственную операцию, теперь данная возможность регулируется вышеуказанной настройкой. Обрабатывается при привязке договора, соглашения, товарного и финансового ПКП. При указании в платежном документе контрагента взаиморасчета, он автоматически переносится во все хозоперации платежного документа по которым нет разноски по ДО и Договорам. Если по хозоперации есть разноска по договору, то хозоперации присваивается контрагент взаиморасчета, а затем запускается обработка настройки "Настройки Галактики Бухгалтерский контур Обработка документов Распределение платежа по договорам Наследовать контрагент из договора в хозяйственную операцию", в зависимости от значения которой в хозоперации остается либо контрагент взаимозачета, либо подставляется контрагент договора. При удалении в платежном документе контрагента взаиморасчета, он автоматически сбрасывается на контрагент платежного документа во всех хозоперациях платежного документа по которым нет разноски по ДО или по договорам. Если по хозоперации есть разноска по договору, то хозоперации присваивается контрагент платежного документа, а затем запускается обработка настройки "Настройки Галактики Бухгалтерский контур Обработка документов Распределение платежа по договорам Наследовать контрагент из договора в хозяйственную операцию", в зависимости от значения которой в хозоперации остается либо контрагент платежного документа, либо подставляется контрагент договора.
106.105579.1.091.0пакетное заполнение поля "Платеж за..."Финансово-расчетные операцииВходящие документы
пакетное заполнение поля "Платеж за..." Часто бухгалтерам приходится формировать массу однообразных платежных документов, в которых необходимо менять плательщика (поле "Платеж за..."). Таких документов у клиента бывает порядка 200 за раз Контрагент ДО, который привязывается к ПП, тот же, что тот, что в поле "Платеж за", и для группы ПП - один и тот же Клиент просит автоматизировать данную массовую операцию Решение видится, например, через функцию "Групповая замена поля в документах" или добавление функции "Пакетное заполнение поля Платеж за...", аналогично пакетному заполнению поля назначениеРеализована поддержка групповой замены для поля "Платеж за". Для использования групповой замены поля необходимо пометить группу платежных документов, в которых необходимо установить одинаковое значение поля "Платеж за". Затем в окне редактирования платежного документа с нужным значением поля "Платеж за", установить курсор в этом поле и выполнить пункт локального меню "Групповая замена поля в документах" или выполнить вызов команды с помощью сочетания горячих клавиш Alt+K. В результате, во всех помеченных платежных документах будет установлено значение поля "Платеж за" равное текущему. При этом будет выполнена синхронизация значения поля "Платеж за" из шапки платежного документа в поле "Контрагент" всех хозяйственных операций документа. Синхронизация выполнятся по правилам описанных в ПИР 102.175769.
102.1703739.1.090.0КИС ФХД ТПР2 Очередь1 Автоматическое создание и синхронизация спецификации авансового отчета с хозоперациейКассаАвансовый отчет
КИС ФХД ТПР2 Очередь1 Автоматическое создание и синхронизация спецификации авансового отчета с хозоперацией при установленной настройке "Синхронизировать спецификацию авансового отчета с хозоперацией" = да и "Сворачивать одноименные операции в авансовых отчетах" =НЕТ нужно АВТОМАТИЧЕСКИ создаватьпереформировывать хозоперации спецификации. Сейчас нужно вызывать принудительно. (Ctrl+Enter)Для настройки "Настройки Галактики Бухгалтерский контур Обработка документов Хозяйственные операции и бухгалтерские проводки Синхронизировать спецификацию авансового отчета с хозоперацией" изменены значения на следующие: - не синхронизировать; - по запросу; - автоматически. В случае, если в данной настройке установлены значения "по запросу" или "автоматически", а значение настройки "Настройки Галактики Бухгалтерский контур Обработка документов Хозяйственные операции и бухгалтерские проводки Сворачивать одноименные операции в авансовых отчетах" установлено в "нет", то если происходила модификация записей позиций спецификации, при уходе с вкладки "Спецификация" произойдет запуск автоматического формирования хоз.операций по позициям спецификации. Запрос на выполнение данной операции будет выдаваться только в режиме "по запросу".
102.1827479.1.090.0Необходима возможность изменить дату хозоперации к бухсправке на раньше даты самой бухсправкиФинансово-расчетные операцииБухгалтерская справка
Необходима возможность изменить дату хозоперации к бухсправке на раньше даты самой бухсправки. Пишут:До внедрения КИС ЭХД бухгалтер делал много бух справок разной датой. Сейчас чтобы уменьшить количество печатаемых справок все вводится одной бух справкой (один штрих-код), но операции проводятся разной датой. Предложение связано с проведением хозоперации в валюте. Нужен курс на дату хозоперации, а не бухсправки.Добавлена пользовательская настройка "Настройки Галактики Бухгалтерский контур Обработка документов Значения полей по умолчанию Бухгалтерские справки Дата хозоперации может быть раньше даты оплаты документа" со значением по умолчанию - "нет". Включение данной настройки позволяет пользователю в хозоперациях бух.справки указать любую дату проведения хозяйственной операции. Включение данной настройки приводит к игнорированию для бухгалтерских справок настройки "Настройки Галактики Бухгалтерский контур Обработка документов Хозяйственные операции и бухгалтерские проводки Проверять соответствие дат проведения хозопераций и документа". При установке даты оплаты в бух.справке новая дата устанавливается только в хоз.операции без даты операции. А при удалении даты, в хозоперациях дата операций остается неизменной. # ИНСТРУКЦИЯ ПО НАСТРОЙКЕ: Проверить функциональность при групповой замене даты оплаты.
101.627199.1.089.0Диадок. Добавить в лок. меню по Диадоку кнопку печать документаУправление сбытомРабота с Контур.Диадок
Диадок. Добавить в лок. меню по Диадоку кнопку Просмотр документа (Печать). Сейчас чтобы вывести документ на печать, надо сначала выбрать функцию " Диадок.Показать документ (Переход)", затем перейдя в Г.Диадок. выбрать "Просмотр Документа"В локальное меню ДО, накладных на отпуск/на прием, счетов-фактур добавлена кнопка "Диадок. Печать документа", которая позволяет открыть печатную форму документа Диадок.
102.1846709.1.089.0не найдена MSVCR120.DLLУправление сбытомРабота с Контур.Диадок
Галактика при входе в любой модуль, и вызове чего либо ( например Документы - Акт на прием услуг) выдает сообщение, что не найдена MSVCR120.DLL. При отключении C_Diadoc такой проблемы нет. Настройка "Настройки ГалактикиОбщие настройки системыРабота с Контур.Диадок" = нет" ОС - Windows Server 2012 R2Исправлено
102.1843219.1.088.0В 102.182915 доработали - в ПП тянется № договора и дата договора. Плохо одно - это внутренний № договора - надо DOGOVOR.NODOC_EXTФинансово-расчетные операцииПлатежное требование
В 102.182915 доработали - в ПП тянется № договора и дата договора. Но, тянется внутренний № договора - надо внешний.Доработано. Если к ПД привязывается Договор (например, при формировании ПТ по ДО с договором), то в ПД тянется № договора внешний.
102.1839959.1.087.0Обеспечение корректной работы на докомпилированном словаре Галактики ERP 9.1Предложение по новой функциональности Галактики ERP (по системе в целом)?
Необходимо обеспечить корректную работу ресурсов на докомпилированном словаре Alter_Cumulative 9.1.12.0.Обеспечение корректной работы. На докомпилированном словаре пересобраны ресурсы работающие и изменёнными таблицами. Комплектность установки ресурсов обеспечена требованиями при установке.
102.1829159.1.086.0№ договора и дата договора в собственном платежным требованиямФинансово-расчетные операцииПлатежное требование
В окне редактирования платежного требования, под Назначением платежа, есть поля: "Договор" и "от". Эти поля выводятся в печатную форму ПТ как Номер документа и Дата документа в блоке Назначение платежа. Поля заполняются вручную. Нужно: поля "Договор" и "от" заполнять автоматически значениями из договора в ДО, при формировании ПТ по этому ДО.Если к ПТ привязывается Договор (например, при формировании ПТ по ДО с договором) и если в ПТ не заполнены поля "Договор" и "от", то эти поля заполняются Датой и Номером привязываемого договора.