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


Описание файла обновления:
ФайлF_PLPOR_RES_911230.TXT
ОбновлениеF_PlPor_res_911230
НазначениеОбщее
ПродуктГалактика 9.1
Релиз31.03.2012 : Atlantis 5.5
КомпонентF_PLPOR
ТипRES
Версия9.1.123.0
Дата2019-01-09 12:34:31
Проблема ПИРПервое решениеОписаниеПроектДетализация
Что изменено:Как изменено:
102.194162NEWИзменение ставки НДС в переходный периодФинансово-расчетные операцииПлатежное поручение
Изменение ставки НДС в переходный период 1.Платеж в 2018г. по ставке 18%. СФ на аванс не сформирован. 2.ДО, накладная, СФ-отгрузка в 2019 году по ставке 20% 3.Привязывается ДО к платежу: ставка в платеже меняется на 20% и СФ на аванс формируется по ставке 20% Настройка "ставки для авансов" в "Параметры работы с документами различных типов" установлена в "ставки из ДО". Установить конкретную группу нельзя, т.к. платежки в 2018 году должны формироваться по ставке 18%, а в 2019- по ставке 20%, т.е. зафиксировать для всех платежей одну ставку нельзя.В локальном меню вкладки "Налоги" каталога и окна редактирования платежных документов, а также окна редактирования хозяйственной операции добавлены следующие пункты меню: - Перевод налогов в ручные; - Перевод налогов в автоматические. При выполнении данных пунктов для всех отображаемых на вкладке налогов будет выставлен атрибут ручные или соответственно автоматические. В локальном меню каталога платежных документов (подменю "Прочие...") так же добавлены вышеуказанные пункты меню. Данные операции выполняются как для текущего платежного документа, так и для группы помеченных. Переводить налоги в ручные необходимо для того что бы зафиксировать рассчитанные налоги и что бы они не были пересчитаны по ставке ндс 2019 года. В момент привязки ДО в платежном документе, так же выполняется сравнение даты ДО и даты хозяйственной операции, и если хозоперация находится в 2018 году, а ДО в 2019, то пользователю выдается запрос на выполнение перевода налогов в ручные, что бы выполнить фиксацию налогов. Аналогичная доработка выполнения и в пакетном распределении платежей. При распределение по ДО контролируются даты ДО и хозоперации, а при распределении накладных контролируются дата накладной и хозоперации. Фиксация налогов выполняется так же по запросу и перед привязкой ДО или накладной
103.9935NEWПечатные формы в реестрах на перечисление не подхватывают "на лету" сделанные изменения. Нужно переоткрывать интерфейс со списком реестровФинансово-расчетные операцииРеестры по перечислениям
Печатные формы в реестрах на перечисление не подхватывают "на лету" сделанные изменения. Нужно переоткрывать интерфейс со списком реестров Клиент открывает реестр, правит там данные и отправляет реестр на печать. Измененные данные реестра на печать не выходят, выходит старая информация. Переоткрытие карточки реестра не помогает - нужно переоткрывать интерфейс со списком реестров для того, чтобы на печать выводились обновленные данные.исправлено
101.659919.1.121.0Онлайн-кассы - новые реквизиты в ФФД 1.05 и 1.1КассаПриходный кассовый ордер
В соответствии с прилагаемым Приказом ФНС России от 21.03.2017 N ММВ-7-20/229@ начиная с версии 1.05 формата фискальных документов (ФФД) по сравнению с ФФД 1.0 добавляется ряд новых обязательных реквизитов. То есть как только кассовый аппарат обновлён до ФФД 1.05, или 1.1 - формирование этих реквизитов становится обязательным. Там же сказано, что ФФД 1.0 полностью прекращает своё действие 31.12.2018, поэтому сейчас клиенты массово обновляют свою ККТ. Из новых реквизитов ФД для нас в первую очередь интерес представляют: 1212 "признак предмета расчета" - для каждой позиции чека, на данный момент 18 значений, см. Таблицу 29; 1214 "признак способа расчета" - для каждой позиции чека, 7 значений, см. Таблицу 28; 1215 "сумма по чеку (БСО) предоплатой (зачетом аванса и (или) предыдущих платежей)" - на весь чек; 1216 "сумма по чеку (БСО) постоплатой (в кредит)" - на весь чек; 1217 "сумма по чеку (БСО) встречным предоставлением". Предлагается реализовать новые точки расширения для передачи расширенного набора данных в ККТ. Возможно, также пользовательскую настройку "Версия формата фискальных документов" с вариантами "1.0/1.05 и выше" - для выбора вызываемых точек (обсуждаемо). epKO_isNotExistExtPoint_v1_05 - для определения версии ФФД (тогда не придётся добавлять настройку). epKO_KKTInitConnection - новая точка расширения наверное пока не нужна. epKO_KKTRegistration_v1_05 - добавить передачу реквизитов 1212 и 1214. Возможно, также ссылки на позицию накладной и распределения. epKO_KKTDoneConnection_v1_05 - добавить передачу реквизитов 1215, 1216, 1217. В системном интерфейсе регистрации показать все рассчитанные реквизиты, желательно с возможностью ручной корректировки. Вычисление реквизитов: 1212 - для начала предлагаю формировать ТОВАР (1)/УСЛУГА (4)/ПЛАТЕЖ (10). Значение "ПЛАТЕЖ" (10) - только в случае, если реквизит 1214 равен "АВАНС" (3). 1214 - если нет распределения по позициям накладной, то каждая позиция ДО это либо "ПРЕДОПЛАТА 100%" (1), либо "ПРЕДОПЛАТА" (2), либо "АВАНС" (3). Такие платежи нужно разрешить регистрировать повторно (при отгрузке). То есть при регистрации устанавливать промежуточный статус, допускающий повторную регистрацию - например, "Зарегистрирован как предоплата/аванс". "АВАНС" (3) - это когда заранее неизвестно за какой конкретно товар/услугу платят, например, при покупке подарочной карты, или при выборе услуги "аванс в счёт будущих поставок". Как вариант, можно определять по внешнему атрибуту к МЦ/услуге "Аванс", или добавить новое поле, или новое значение поля "Категория", или может есть что-то более подходящее в каталогах МЦ/услуг. "ПРЕДОПЛАТА 100%" (1), или "ПРЕДОПЛАТА" (2) - на данном этапе определить не можем, поскольку сейчас у нас нет информации о распределённой сумме платежа по позициям ДО. Пока что предлагаю формировать 1, в ближайшее время доработать распределение по позициям ДО (в рамках отдельного ПиР). "ПОЛНЫЙ РАСЧЕТ" (4) - когда позиция ПОЛНОСТЬЮ оплачена регистрируемым документом (с учётом предыдущих платежей) и дата регистрируемого платежа <= дате отгрузки. Передавать полное количество по накладной dKol (а не только оплаченное регистрируемым документом). При этом сумму предыдущих платежей по данной позиции нужно накапливать для реквизита 1215 (если дата регистрируемого платежа < дате отгрузки, то его тоже сюда включать). "ЧАСТИЧНЫЙ РАСЧЕТ И КРЕДИТ" (5) - когда позиция ЧАСТИЧНО оплачена регистрируемым документом (с учётом предыдущих платежей) и дата регистрируемого платежа <= дате отгрузки. Передавать полное количество по накладной dKol (а не только оплаченное). При этом сумму предыдущих платежей по данной позиции нужно накапливать для реквизита 1215 аналогично предыдущему пункту, а неоплаченную сумму по данной позиции - накапливать для реквизита 1216. "ПЕРЕДАЧА В КРЕДИТ" (6) - когда позиция полностью НЕ оплачена и дата отгрузки равна дате регистрируемого платежа. Передавать полное количество по накладной dKol. При этом ВСЮ сумму по данной позиции нужно накапливать для реквизита 1216. Здесь необходимо ещё решить вопрос как быть в случае передачи товара вообще без оплаты - формировать платёж на сумму 0? Сейчас так сделать не получается. "ОПЛАТА КРЕДИТА" (7) - когда дата регистрируемого платежа > даты отгрузки. Передавать оплаченное регистрируемым документом количество dKol. 1215, 1216 - накопленные соответствующие суммы по всем позициям с реквизитом 1214 = "ПОЛНЫЙ РАСЧЕТ" (4), или "ЧАСТИЧНЫЙ РАСЧЕТ И КРЕДИТ" (5), или "ПЕРЕДАЧА В КРЕДИТ" (6). 1217 - пока предлагаю формировать 0. См. также описание примеров во вложенном файле (они годовой давности, но в основном правильные, если найдём более актуальные документы - будем добавлять сюда).Для поддержки поддержки формата ФФД 1.05 или 1.1 реализованы следующие точки расширения: 1. Проверка поддержки формата ФФД 1.05 или 1.1 При существовании обработчика, а значит поддержке новых форматов, точка должна возвращать false. ExtensionPoint epKO_isNotExistExtPoint_v1_05; 2. Регистрация оплаченной позиции документа для ФФБ 1.05 ExtensionPoint epKO_KKTRegistration_v1_05 (wTiDk, // Тип документа wOperation, // Тип операции (0-не определен; 1-продажа; 2-возврат продажи; 3-покупка; 4-возврат покупки) wObjMethod, // Признак предмета расчета wCalcMethod : word; // Признак способа расчета sAdmPass, // Пароль администратора системы sOperatorPass, // Пароль оператора для ККТ sNamePos : string; // Наименование мц/услуги dKol, // Количество dPrice, // Цена dTaxRate, // Ставка dSumTax, // Сумма налога dSumTaxForOne: double; // Не округленная сумма налога за 1 позицию bModeTax : boolean; // Входимость налога wDistrType : word; // Тип распределения (1 - по ДО; 2 - по накладной/акту) cDistrPos : comp; // Ссылка на позицию распределения (для типа 1 ссылка на PlDgDist; для типа 2 ссылка на SpSopHoz) pObject : pointer); // Ссылка на драйвер кассового аппарата 3. Завершение регистрации ККТ для ФФБ 1.05 ExtensionPoint epKO_KKTDoneConnection_v1_05 (cDoc : comp; // NREC документа sAdmPass, // Пароль администратора системы sOperatorPass : string; // Пароль оператора для ККТ wPaymentType : word; // Тип оплаты (0 - наличные; 1- банковская карта) dSumPrePay, // Сумма по чеку (БСО) предоплатой (зачетом аванса и/или предыдущих платежей) dSumPostPay, // Сумма по чеку (БСО) постоплатой (в кредит) dSumConsider : double; // Сумма по чеку (БСО) встречным предоставлением pObject : pointer; // Ссылка на драйвер кассового аппарата pStr : iObjExtStr); // Объект работы со строками В случае, если реализована точка расширения №1 и она возвращает значение False, это означает что регистрация в ККТ будет выполнятся с учетом нового формата. В этом случае, в окне распределения по спецификациям накладной/акта, а так же по спецификации ДО,в позициях оплаты, появится поле "ККТ", которое может принимать значения "Да" или "Нет". Значение "Да", означает что данная позиция была обработана в ККТ. Данные поля можно редактировать вручную, а так же оно автоматически устанавливается в занчение "Да", после выполнения регистрации по позициям. В окне регистрации в ККТ для каждой позиции были добавлены поля "Предмет расчета" и "Способ расчета". Данные поля определяются для каждой позиции и передаются в точку расширения №2. Так же в окне появились поля "Сумма по чеку предоплатой" и "Сумма по чеку постоплатой". Данные поля накапливают суммы по всем позициям и передаются в точку расширения №3. Поле "Сумма по чеку предоплатой" накапливает по позициям оплаты суммы которые были зарегистрированы ранее (позиции распределения со значением поля "ККТ" = "Да"). Поле "Сумма по чеку постоплатой" накапливает по позициям суммы, которых не хватает до полной оплаты позиции. Предмет расчета определяется следующим образом: если позиция является МЦ, то она принимает значение = 1 (товар), если позиция является услугой, то она принимает значение = 4 (услуга), а если к товару или услуге указанной в позиции спецификации существует внешний строковый атрибут "Аванс" который принимает значение "1", атрибут то предмет расчета принимает значение = 10 (Аванс) Способ расчета может принимать следующие значения: 1) Предоплата 100% (значение = 1) - когда существует только распределение по спецификации ДО и позиция полностью распределена (с учетом предыдущих оплат). При этом количество передается целиком, а сумма предыдущих оплат накапливается в поле "Сумма по чеку предоплатой". 2) Предоплата (значение = 2) - когда существует только распределение по спецификации ДО и позиция не полностью распределена. При этом количество передается с учетом предыдущих оплат, а сумма предыдущих оплат накапливается в поле "Сумма по чеку предоплатой". 3) Аванс (значение = 3) - для позиции с признаком предмета расчета - "Аванс". 4) Полный расчет (значение = 4) - когда позиция спецификации накладной/акта полностью распределена (с учетом предыдущих оплат) и дата регистрируемого платежа меньше либо равна дате накладной/акта. При этом количество по позиции передается полное, а сумма предыдущих оплат накапливается в поле "Сумма по чеку предоплатой". 5) Частичный расчет и кредит (значение = 5) - когда позиция спецификации накладной/акта распределена частично (с учетом предыдущих оплат) и дата регистрируемого платежа меньше либо равна дате накладной/акта. При этом количество по позиции передается полное, сумма предыдущих оплат накапливается в поле "Сумма по чеку предоплатой", а неоплаченная сумма по позиции накапливается в поле "Сумма по чеку постоплатой". 6) Передача в кредит (значение = 6) - на данный момент режим не обрабатывается. 7) Оплата кредита (значение = 7) - когда есть распределение по позиции спецификации накладной/акта и дата регистрируемого платежа больше даты отгрузки. При этом этом количество передается оплаченное непосредственно этим платежом. В окне регистрации в ККТ, все поля кроме "Позиция", "%НДС" и "Вх." являются редактируемыми. После нажатия на кнопку "Продолжить" (окно регистрации в ККТ), все отобранные позиции передаются в ККТ с помощью точки расширения №2. Для каждой позиции передается так же ее тип распределения и ссылка на позицию распределения. В частности если распределение по позициям ДО, то передается значение "1" и ссылка на запись PlDgDist.NRec. А если распределение по позициям накладной/акта, то предается значение "2" и ссылка на запись SpSopHoz.Nrec. По завершении обработки всех позиций, вызывается точка расширения №3, которая кроме основных параметров передает сумму по чеку предоплатой и сумму по чеку постоплатой. Сумма по чеку встречным представлением на данный момент не используется и передается значение ноль. После завершения обработки, в документе выполняется установка соответствующего статуса. Для документа должны быть заведены как минимум два статуса в группе исполняемых статусов. 1) "Регистрация аванса/предоплаты ККТ" (наименование может быть указано любое) со значением в поле код = 5. 2) "Завершена регистрация ККТ" (наименование может быть указано любое) со значением в поле код = "4". В случае, если по документу была зарегистрирована хотя бы одна позиция со значениями способа расчета "предоплата 100%", "предоплата" или "аванс", то в документе будет устанавливаться статус №1. При этом из данного статуса разрешена повторная регистрация ККТ. В противном случае, после выполнения регистрации, в документе устанавливается статус №2.
102.1906039.1.121.0Переход на НДС 20% : доработать возможность создания корректировочного СФ к авансовому СФУправление сбытомНаши счета-фактуры
Необходимо доработать возможность создания корректировочного СФ к авансовому СФ, т.е. аванс уплачен до 01/01/2019 (выставлен авансовый СФ со ставкой НДС 18/118), доплата НДС в размере 2% (20%-18%)произведена после 01/01/2019. Нужно выставить корректировочный СФ на сумму доплаты НДС. Таким образом, вся оплаченная сумма - это доначисление только НДС, которое отражается в корректировочном СФ. Законодательство: Письмо ФНС от 23 октября 2018 г. N СД-4-3/20667@ "О ПОРЯДКЕ ПРИМЕНЕНИЯ НАЛОГОВОЙ СТАВКИ ПО НДС В ПЕРЕХОДНЫЙ ПЕРИОД" (полный текст см. во вложении): "если доплата налога в размере 2% осуществляется покупателем с 1 января 2019, то такую доплату не следует рассматривать в качестве дополнительной оплаты стоимости, с которой необходимо исчислять НДС по ставке 20/120. При получении такой доплаты налога продавцу следует выставить корректировочный счет-фактуру на разницу между показателем суммы налога по счету-фактуре, составленному ранее с НДС 18/118, и показателем суммы налога, рассчитанной с учетом размера доплаты налога;"Доработки выполнены для страны Россия. В окне редактирования хозяйственной операции финансовых и кассовых документов, добавлена закладка "Доплата НДС". На данной вкладке находятся два поля: 1) Статус хозоперации. Информационное поле, которое может отображать следующие значения: - Доплата НДС не выполнялась; - Доплата НДС; - Связь с доплатой НДС. 2) Связанный документ. Поле отображающее описание хозяйственной операции с которой установлена связь. Предназначено для формирования и удаления связи, а так же для перехода в связанный документ. Для того что бы для текущей хозоперации выполнить доплату НДС необходимо либо выполнить пункт локального меню "Обработать хозяйственную операцию как доплату НДС", либо нажать F3 в поле "Связанный документ". При этом дата оплаты хозяйственной операции (а при ее отсутствии дата выписки документа) должна быть позже 31.12.2018 и хозоперация должна входить в сумму документа. В результате пользователю будет предложено выбрать хозоперацию для которой выполняется доплата НДС. При этом к хозяйственным операциям будет применен следующий фильтр: - период до 31.12.2018 (включительно); - вид документа аналогичный текущему; - контрагент аналогичный текущему; - договор и соглашение аналогичные текущему. Данный фильтр можно изменить (локальное меню интерфейса выбора хозопераций - Установка ограничений). В случае, если у текущей хозоперации существует разноска по ДО, то выбрать можно только хозоперацию с таким же ДО. После выбора хозяйственной операции будет установлена связь между текущей и выбранной хозоперацией и на вкладке "Доплата НДС", в поле "Связанный документ" отобразится наименование выбранной хозоперации, а поле "Статус хозоперации" будет отображаться значение "Доплата НДС". Так же, в окне редактирования хозоперации, в поле "Статус" (самое первое поле сверху окна) отобразится значение "Доплата НДС". При этом, если у выбранной хозоперации было ДО, то в текущей хозоперации оно тоже будет привязно и выполнится распределение по спецификации накладной/акта и рассчитаются налоги. Был доработан расчет налогов. В случае если хозоперация является доплатой НДС, то формируется налог НДС со ставкой 20% и на сумму равную сумме хозяйственной операции. В выбранной хозоперации, в статусе появится подпись - "связь с доплатой НДС". Для того что бы отменить обработку хозоперации как доплату НДС, необходимо в поле "Связанный документ" нажать на клавишу Del. В результате связь будет удалена, а налоги по хозоперации будут пересчитаны. Для того что бы перейти в связанный документ, необходимо в поле "Связанный документ" нажать F4. При удалении платежного документа или одной из связанных хозопераций выполняется удаление связи между документами. При уводе хозоперации в "минус", в случае автоматического создания новой хозоперации, связь между документами копируется в новую хозоперацию. __________________________________________ Доработка СФ.
102.1935729.1.121.0Доработать фильтрФинансово-расчетные операцииБухгалтерская справка
Доработать фильтр При установке фильтра на документы по параметру "Расчетный счет" для значения "все", нужно учитывать настройки доступа к расчетным счетам/кассам/бух.справкам. Например, на предприятии ведется 3 типа бух.справок: бс1,бс2,бс3. У пользователя установлена настройка: "Настройки Галактики Бухгалтерский контур ..доступ к бухгалтерским справкам по" доступным типам бухсправок и заданы 2 доступных типа бс1 и бс2. При установке фильтра в списке бух. справок с параметром "Расчетный счет" со значением "все", пользователю становятся доступные и документы с типом бс3.доработано аналогично касс и РС: фильтр доступен при настройке по всем типам БС
101.661169.1.120.0Огромные задержки при работе с бухгалтерскими справкамиФинансово-расчетные операцииБухгалтерская справка
после обновления возникла проблема при работе с бухгалтерскими справками. Суть проблемы заключается в том, что при попытке открытия бухсправок с большим количеством хозопераций происходит "зависание" интерфейсов, при этом наблюдается значительная нагрузка на сеть. После прогрузки интерфейсов и попытке их закрытия Галактика "зависает" на крайне продолжительное время. (Под зависанием, в данном контексте, подразумевал именно продолжительное время ожидания между командой на запуск интерфейса и его отображением на экране.При этом, главное окно Галактики полностью перестает отвечать на запросы, при наблюдаемой в диспетчере задач сетевой активности.) На сервере для таблиц oborot, hozoper, plpor было произведено перестроение индексов и обновление статистики, что никакого результата не дало.В интерфейсе настроек "Настройки Галактики Бухгалтерский контур Обработка документов Параметры работы с документами различных типов", на вкладке "Права доступа" добавлено поле "Отображать разноску по ФОБ в документах", со значением по умолчанию "Да". Данная настройка влияет на видимость колонки признака распределения документа по ФО в каталоге документов. Для отображения значения данного поля, выполняется пробежка по всем хозоперациям документа и проверка наличия связи с ФО и затем соответствующий результат выводится в колонке. Для бух.справок необходимо отключить отображение данного поля (если потребность в данном поле отсутствует, то его можно отключить для всех документов). В каталоге платежных документов, в окне редактирования платежного и в окне редактирования хозяйственных операций документа отключена автоинициализация закладок "Статьи бюджета" и "Оплаты". Расчеты для данных закладок выполняются только при их активации. Следует отметить, замедления связанные с закрытием окна редактирования документа, происходит из-за включенных следующих настроек интерфейса настроек "Настройки Галактики Бухгалтерский контур Обработка документов Параметры работы с документами различных типов": - Проверять распределение платежа по ДО. - Проверять формирование счет-фактур. Данные настройки следуют отключить для бух.справок.
102.1929329.1.120.0Рантайм при копировании платежных порученийФинансово-расчетные операцииПлатежное поручение
Рантайм при копировании платежных поручений. ФРО/Документы/Платежные поручения/Собственные. Выбираем ранее сформированное платежное поручение, запоминаем его: "CTRL-F2" и копируем: "CTRL-F3" По окончании процедуры копирования и редактирования вновь созданного платежного поручения (п/п), приступаем к созданию нового п/п, используя прием, описанный выше. Когда количество действий, связанных с использованием упомянутой функции копирования достигает или превышает трех, получаем сообщения об ошибках: Rinetime error 216 или Runtime error 213исправлено
102.1700689.1.119.0Увеличить размерность поля PLPOR.NOCHEK3(номер исполнительного документа)Финансово-расчетные операцииСводное платежное требование
При следующей докомпиляции словаря необходимо увеличить размерности поля PLPOR.NOCHEK3 с 15 хотя бы до 100 символов. В данное поле вносится информация об исполнительном документе, которая в последующем "попадает" в печатную форму сводного платежного требования. Проблема в том, что в этой форме, в графе "Номер и дата исполнительного документа (при наличии)" кроме номера и даты необходимо отображать и название исполнительного документа (например, исполнительная надпись, судебный приказ и т.д.), а в 15 символов все вместить проблематично... Клиент ссылается на постановления национального банка РБ № 66.На форму платежного требования (для РБ) добавлено поле "Тип документа" (PlPor.Append, 255 символов), после даты исполнительного документа (без метки). В печатных формах сводного ПТ (RTF/бизнес-текст) данное поле печатается перед номером и датой исполнительного документа
101.624029.1.118.0Онлайн-кассы - необходимо распределение платежа по позициям ДО (для предоплат по ДО)КассаПриходный кассовый ордер
Продолжение ПиР 101.62385 (см. п.3). Согласно п.1 статьи 4.7 54-ФЗ: 1. Кассовый чек и бланк строгой отчетности содержат, за исключением случаев, установленных настоящим Федеральным законом, следующие обязательные реквизиты: ..... наименование товаров, работ, услуг (если объем и список услуг возможно определить в момент оплаты). У некоторых клиентов практикуются авансовые платежи по ДО (когда оплачивают по ДО, но в момент оплаты ещё нет сопроводительного документа). Таким образом, необходимо передавать в ККТ оплачиваемые позиции ДО.Доработано распределение по спецификации ДО. 1) Изменен формат отображения вкладки "Оплата МЦ/услуг ДО" окна редактирования хозяйственной операции. Основное отличие заключается в добавление полей "Опл.кол-во" и "Опл.сумма", в которых отображается оплаченное количества и сумма по позиции. 2) В окне распределения по позиция ДО появились поля "Опл. кол-во" и "Кол-во оплаты". Данные поля являются вычисляемыми и рассчитываются на основании текущей оплаченной суммы по позиции спецификации ДО. 3) Поле "Кол-во оплаты" редактируемое. Для распределения относящегося к текущей хозоперации можно указать количество оплаты, на основании которого будет рассчитана соответствующая сумма оплаты. Доработана регистрация в ККТ. Раньше, если привязано ДО без накладных, в кассовый аппарат передавались данные по всем позициям ДО. Теперь выполняется контроль распределения по спецификации ДО. Если распределение по позициям ДО отсутствует, то выполнение регистрации в ККТ невозможно. А если распределение присутствует, то в ККТ передаются только распределенные позиции спецификации ДО.
101.660039.1.118.0Онлайн-кассы - необходимо регистрировать в ККТ авансы по ДО с учетом скидкиКассаПриходный кассовый ордер
Сейчас при регистрации в ККТ аванса по ДО в результате решения ПиР 101.62385 в точку расширения передаются полные суммы стоимости и НДС по каждой позиции спецификации ДО. Но у клиента по ДО часто предоставляются скидки, поэтому необходимо передавать суммы с учётом этих скидок (по всему ДО и по позиции). Сейчас они вынуждены делать по таким ДО фиктивный акт - для распределения по нему платежа с учётом скидок. А в новых форматах ФД 1.05/1.1 так поступать уже нельзя, поскольку при наличии акта мы не сможем правильно сформировать реквизит 1214 "признак способа расчёта" - предоплата, или аванс (ПиР 101.65991). Возможно, в новых точках расширения для ФФД 1.05/1.1 имеет смысл дополнительно передавать и полные суммы (например, для возможности отражения суммы скидки в чеке).При выполнении регистрации в ККТ аванса по ДО, в точку расширения передаются оплаченные суммы стоимости позиций ДО с учетом скидок (как по всему ДО, так и по позиции).
102.1802399.1.118.0Объединенные реестр и платежная ведомость в фин. контуреФинансово-расчетные операцииРеестры по перечислениям
Объединенные реестр и платежная ведомость в фин. контуре В рамках 102.180238 планируется реализовать встраиваемые окна для отображения информации по объединенным реестру / платежной ведомости. Необходимо отобразить скрытые (в 102.178801, 102.178909) записи, используя для отображения информации по ним готовые встраиваемые окна, дополнив их информацией по документам, хоз. операциям и т.п.Доработан интерфейс Реестров на перечисления модуля ФРО. Если настройками Галактики разрешено отображение всех реестров на перечисление, в списке реестров отображаются объединенные реестры. Для объединенных реестров подключены встраиваемые окна реализованные в 102.180238. По аналогии с интерфейсом реестров на перечисления модуля ЗП, для реестров сформированных в этом модуле, в нижней панели отображаются те же закладки что и в модуле ЗП. Для реестров сформированных в модуле ФРО отображаемые закладки не изменились.
102.1883039.1.118.0сделать активной вкладку "Проводки" в платежном порученииФинансово-расчетные операцииПлатежное поручение
сделать активной вкладку "Проводки" в платежном поручении. При входе в платежное поручения активной является вкладка "Расшифровка для РЦК", возможно ли сделать доработку, чтобы активной можно было сделать вкладку "Проводки" для удобства бухгалтеров.Добавлена пользовательская настройка: "Настройки Галактики Бухгалтерский контур Обработка документов Интеграция с РЦК При открытии ПП вкладка по умолчанию" - Расшифровка для РЦК (по умолчанию) - Проводки Если включена интеграция с РЦК и настройка "Страна" = ccRus, то при открытии ПП по данной настройке будет определяться закладка, которая будет активна.
102.1910479.1.118.0Необходима возможность убирать лишние виды платежа в платёжном порученииФинансово-расчетные операцииПлатежное поручение
Клиент просит привести платежное поручение в соответствии с "Положением о платежной системе Банка России" (утв. Банком России 06.07.2017 N 595-П). Необходимо оставить только 2 варианта: "пусто" и "срочно".Добавлена пользовательская настройка: "Настройки Галактики Бухгалтерский контур Обработка документов Значения полей по умолчанию Платежные документы Настройка значений поля Вид платежа [х] пусто [ ] почтой [ ] телеграфом [ ] электронно [х] срочно [ ] клиринг символом "x" отмечены значения по умолчанию. Для ПП будут доступны виды платежа, отмеченные в данной настройке.
102.1914509.1.118.0вывод номера отчетного документа в печатную форму АО FastReportКассаАвансовый отчет
вывод номера отчетного документа в печатную форму АО FastReport Печать-Авансовый отчет FastReport (условие: Приложение "По спецификации АО") - в колонку отчета "Документ, подтверждающий производственные расходы" НЕ ВЫВОДИТСЯ ПОЛНОСТЬЮ номер отчетного документа (увеличивали длину поля "Номер документа" на форме редактирования спецификации АО согласно Пир 102.173579)Исправлен вывод номера отчетного документа в печатную форму АО FastReport
102.1918969.1.118.0Подсвечивать закрытые счета в интерфейсе платежных документовФинансово-расчетные операцииПлатежное поручение
От клиента поступило предложение: В интерфейсе платежных документов подсвечивать поле со счетом серым цветом, в случае если счет закрыт. Можно реализовать по настройке.Для платежных документов реализована подсветка поля со счетом серым цветом, если счет закрыт.
101.653279.1.117.0Добавить параметр "Источник финансирования" в параметр настройки копирования платежного порученияФинансово-расчетные операцииПлатежное поручение
Добавить параметр "Источник финансирования" в параметр настройки копирования платежного поручения Клиент хочет, что бы при копировании любой платёжки поле "Источник финансирования" - очищалось.В параметры копирования платежного поручения добавлен параметр "Источник финансирования". Если данный параметр не выбран, - в копии платежного поручения ИФ не заполняется.
102.1872569.1.117.0Перестала считаться сумма по авансовому отчету на основании спецификацииКассаАвансовый отчет
Обновление F_PlPor_res_911100 - перестала считаться сумма по авансовому отчету. По бизнес процессу куратор заполняет только спецификацию авансового отчета и на обновлении F_PlPor_res_911070 пересчитывалась сумма авансового отчета если кликнуть мышкой на шапку документа. Установлена настройка Настройки Галактики Бухгалтерский контур Обработка документов Хозяйственные операции и бухгалтерские проводки Сворачивать одноименные операции в авансовых отчетах" = Да. Проверила проблему на тестовой базе. На обновлении F_PlPor_res_911070 с настройками "Сворачивать одноименные операции в авансовых отчетах"-"да" и "Синхронизировать спецификацию авансового отчета с хозоперацией"-"да" и "нет" в хозоперациях формировалась сумма по спецификации. На обновлении F_PlPor_res_911100 изменились значения настройки ""Синхронизировать спецификацию авансового отчета с хозоперацией" на "не синхронизировать", "по запросу", "автоматически". Ни с одной из настроек сумма расходов по спецификации в Хозоперациях не формируется, поэтому и не появляется запрос на изменение суммы документа.Синхронизация суммы спецификации авансового отчета с хозоперацией осуществляется независимо от значения настройки "Настройки Галактики Бухгалтерский контур Обработка документов Хозяйственные операции и бухгалтерские проводки Сворачивать одноименные операции в авансовых отчетах". Если несколько позиций спецификации АО, при выполнении синхронизации группируются в одну хозоперацию, то каждая из позиций спецификации будет ссылаться на одну и ту же хозоперацию (раньше в таких случаях связь позиции спецификации с хозоперацией не формировалась). При удалении такой хозоперации, ссылка на нее обнуляется во всех относящихся к ней позициях спецификации. Если одна из таких позиций спецификации АО редактируется, то запускается алгоритм синхронизации, в результате которого существующая хозоперация удаляется и формируется новая, с учетом внесенных изменений в текущую позицию спецификации и с учетом группировки в разрезе ТХО.
101.655439.1.116.0Добавить в точку расширения epKO_KKTRegistrWithOutSoprDoc передачу текущего значения PlPor.NRecКассаПриходный кассовый ордер
Добавить в точку расширения epKO_KKTRegistrWithOutSoprDoc передачу текущего значения PlPor.NRec Клиент просит добавит информацию об NRec текущего PlPor для автоматического определения способа оплаты наличными или же картой: интеграцию с кассой и терминалом для эквайринга мы сделали, но из-за того, что при оплате нужно выбирать вариант "оплата наличными" или "оплата картой", пришлось разделить кассу для налички и для эквайринга, поэтому если бы у нас из точки расширения приходила бы ссылку на кассу, диалог пользователю можно было бы не выводить. "wTiDk" - не подходит, так как внутри одного типа мы хотим менять логику в зависимости от номера кассы.В точку расширения epKO_KKTRegistrWithOutSoprDoc добавлен параметр cDoc для передачи текущего значения документа (PlPor.Nrec). Описание точки расширения следующее: #doc Регистрация оплаты документа без сопроводительных документов cDoc - Nrec документа wTiDk - тип документа wOperation - тип операции (0-не определен; 1-продажа; 2-возврат продажи; 3-покупка; 4-возврат покупки) sAdmPass - пароль администратора системы sOperatorPass - пароль оператора для ККТ sNamePos - приложение (PlPor.NamePl4) sNamePl1 - основание для приема денег 1 (PlPor.NamePl1) sNamePl2 - основание для приема денег 2 (PlPor.NamePl2) sNamePl3 - основание для приема денег 3 (PlPor.NamePl3) dSum - сумма платежа dTaxRate - ставка налога dSumTax - сумма налога pObject - ссылка на драйвер кассового аппарата #end ExtensionPoint epKO_KKTRegistrWithOutSoprDoc(cDoc : comp; wTiDk, wOperation: word; sAdmPass, sOperatorPass, sNamePos, sNamePl1, sNamePl2, sNamePl3 : string; dSum, dTaxRate, dSumTax: double; pObject : pointer);
101.656569.1.116.0Онлайн-кассы - различать продажу с возвратом и возврат покупкиКассаПриходный кассовый ордер
Онлайн-кассы - различать продажу с возвратом и возврат покупкиДоработан алгоритм определения типа операции регистрации в ККТ. Алгоритм определения следующий. 1. Для стороннего платежного поручения и приходного кассового ордера: - если есть связь с возвратом (через заполненную ссылку внешнего атрибута), то если все хозоперации документа с видом платежа "возврат платежа", то тип операции - возврат покупки (4). - если связь с возвратом есть, и все типы хозоперации одинаковые и не равны "возврат платежа", то тип операции - продажа (1) - если есть связь с возвратом но все хозоперации документа имеют разные вида платежа, то тип операции - ошибка (5). - если связь с возвратом отсутствует, то тип операции продажа (1) 2. Для собственного платежного поручения и расходного кассового ордера: - если есть связь с возвратом (через заполненную ссылку внешнего атрибута), то если все хозоперации документа с видом платежа "возврат платежа", то тип операции - возврат продажи (2). - если связь с возвратом есть, и все типы хозоперации одинаковые и не равны "возврат платежа", то тип операции - покупка (3) - если есть связь с возвратом но все хозоперации документа имеют разные вида платежа, то тип операции - ошибка (5). - если связь с возвратом отсутствует, то тип операции покупка (3) Необходимо доработать драйвер кассового аппарата для поддержки нового типа операции - ошибка (5). Данный тип означает, что в документе, у которого есть связь возвратом, есть несколько хозоперации с различными видами платежа, в то время как должны быть одного.
101.657439.1.116.0Потеря преемственности. Онлайн-кассы - точка расширения epKO_KKTRegistration вызывается и при отсутствии ДО по документуКассаПриходный кассовый ордер
После решения ПиР 101.65110 точка расширения epKO_KKTRegistration вызывается даже при отсутствии ДО по документу - см. скриншот системного интерфейса регистрации во вложенном файле. До этой доработки без связи платёжного документа с ДО регистрация была невозможна. При наличии накладной/акта по ДО, но без распределения платежа по позициям этой накладной/акта регистрация была также невозможна. Если в системе нет реализации новой точки расширения epKO_KKTRegistrWithOutSoprDoc, то так всё и должно оставаться.Добавлена следующая точка расширения: #doc Проверка реализации точки расширения epKO_KKTRegistrWithOutSoprDoc. При существовании обработчика точки расширения она должна возвращать false #end ExtensionPoint epKO_isNotExistExtPointRegWOSoprDoc; Данная точка предназначена для определения наличия реализации обработчика точки расширения epKO_KKTRegistrWithOutSoprDoc. Если точка расширения epKO_isNotExistExtPointRegWOSoprDoc возвращает значение True (в случае если она не реализована то тоже будет возвращать значение True), то это означает что отсутствует реализация точки расширения epKO_KKTRegistrWithOutSoprDoc и данному клиенту запрещено выполнять регистрацию в ККТ при отсутствии в документе связи с ДО. Таким образом при выполнении регистрации в ККТ по документу без ДО будет выдаваться сообщение: "Выполнение регистрации в ККТ невозможно! Документ не связан с ДО!" Для того что бы работала функциональность регистрации в ККТ без наличия сопроводительных документов (решение по ПИР 101.65110), необходимо реализовать обработчик точки расширения epKO_isNotExistExtPointRegWOSoprDoc таким образом, что бы он возвращал значение False.
102.1903589.1.116.0Непонятные значки в печатной форме "Валютное платежное поручение (СберБанк России) на латинице" rtfФинансово-расчетные операцииВалютное платежное поручение
Непонятные значки в печатной форме "Валютное платежное поручение (СберБанк России) на латинице" rtf в разделе: Расходы и комиссии по переводу (Bank charges and commissions):Исправлено.
102.1887909.1.115.0Изменился вывод суммы в печатной форме "Заявление на аккредитив" РБФинансово-расчетные операцииВалютное заявление на аккредитив
Изменился вывод суммы в печатной форме "Заявление на аккредитив" РБ. Было: USD 500=00 (Пятьсот) долларов США Стало: USD 500=00 (Пятьсот) долларов США 00 центовФРО / Документы / Заявления на аккредитив, ФРО / Документы / Валютные заявления на аккредитив. Доработан вывод сумм в печатных формах "Заявление на аккредитив" РБ: если сумма целая (00 копеек(1/100 единиц валюты)), то дробная часть не выводится.
102.1889199.1.114.0признак ФОБ поФинансово-расчетные операцииПлатежное поручение
ПИР 102.167570 Отображение признака наличия ФОБ по платежному поручению - реализован с ошибкой: функционал отображения признака работает только, если в "Платежном документе" выбран "основной расчетный счет". Т.е. функционал будет работать только если PlPor.TiDK= PlPor.TiDKGal.Доработано отображение признака наличия ФОБ по платежного документа. Анализируется системный тип документа
102.1894129.1.114.0Онлайн-кассы - необходима регистрация в ККТ сторонних платежных поручений ЗА физических лицФинансово-расчетные операцииВходящие документы
Требуется небольшая доработка решения ПиР 101.65430. Сейчас в собственных и сторонних платёжных поручениях регистрация в ККТ становится доступна, только если контрагент - физическое лицо. Но выяснилось, что у клиента в сторонних платёжных поручениях от физических лиц чаще всего контрагентом является банк (то есть ЮРлицо). А ФИЗлицо ставится в поле "Платёж за". Необходимо доработать СТОРОННИЕ платёжные поручения, чтобы анализировались оба этих поля - если в любом из них физлицо, то делать регистрацию доступной. А в собственных п/п дорабатывать ничего не нужно.пункт лок. меню "регистрация в ККТ", визуализируется, только если контрагент - физлицо (признак в каторге). Добавлен анализ еще и на организацию в поле "Платёж за" То есть если в любом из 2-х полей физлицо, то визуализировать этот пункт лок. меню только для сторонних ПП
180.108489.1.114.0возврат плтатежа по собственным платежным документамФинансово-расчетные операцииПлатежное поручение
В рамках реализации функционала по он-лайн кассам по N 54-ФЗ Клиенту необходимо формировать чек: Возврат расхода (случай, когда Контрагент возвращает оплату). Следовательно, необходим аналогичный функционал для Собственного платёжного поручения/Расходного кассового ордера.Реализован функционал возврата платежей для Собственного платежного поручения/Расходного кассового ордера.
101.654309.1.112.0Онлайн-кассы - необходима регистрация в ККТ платежных поручений от физических лицФинансово-расчетные операцииПлатежное поручение
ст. 4, Федеральный закон от 03.07.2018 N 192-ФЗ "О внесении изменений в отдельные законодательные акты Российской Федерации" 4. Организации и индивидуальные предприниматели при осуществлении расчетов с ФИЗИЧЕСКИМИ ЛИЦАМИ, которые не являются индивидуальными предпринимателями, в безналичном порядке (ЗА ИСКЛЮЧЕНИЕМ РАСЧЕТОВ С ИСПОЛЬЗОВАНИЕМ ЭЛЕКТРОННЫХ СРЕДСТВ ПЛАТЕЖА) ... вправе не применять контрольно-кассовую технику и не выдавать (направлять) бланки строгой отчетности до 1 июля 2019 года. Перечисления физических лиц через online-банк, или терминалы оплаты относятся как раз к РАСЧЕТАМ С ИСПОЛЬЗОВАНИЕМ ЭЛЕКТРОННЫХ СРЕДСТВ ПЛАТЕЖА, по которым организации обязаны осуществлять регистрацию в ККТ. Таким образом, необходима возможность регистрации в ККТ платёжных поручений (сторонних и собственных на возврат платежа), аналогичная регистрации приходных/расходных кассовых ордеров, если контрагент в платёжном поручении - физическое лицо. Предлагается в платёжные поручения подключить реализованный функционал регистрации кассовых ордеров (ПиР 101.60610, 101.62385, 101.65110) с использованием тех же настроек и точек расширения - при таком подходе необходимость доработки пользовательских реализаций точек расширения сведётся к минимуму. В локальное меню интерфейса редактирования ПП добавить функцию "Регистрация в ККТ", дополнительно проверять признак "физическое лицо" в каталоге организаций для организации-контрагента (в противном случае функция должна быть недоступна).Для собственных и сторонних платежных поручений подключена функциональность регистрации в ККТ. В случае если включена настройка "Настройки Галактики Бухгалтерский контур Касса Выполнять регистрацию в ККТ" и реализованы точки расширения в локальном меню окна редактирования платежного поручения становится доступным пункт локального меню "Регистрация в ККТ". При этом пункт локального меню для собственных платежных поручений появляется только в случае если получатель физическое лицо, а для сторонних платежных поручений если плательщик физическое лицо. В остальном функционал аналогичен функционалу регистрации в ККТ кассовых ордеров.
102.1873229.1.112.0Исправить ошибки склонения слова "счет-фактура" в описании идентификатора VzBaseDocХозоперацииНастройка хозопераций /укажите тип документа/
Исправить ошибки склонения слова "счет-фактура" в описании параметров идентификатора VzBaseDoc. Слово "счет-фактура" - существительное мужского рода, поэтому вместо "Если к ДО относится одна СФ, она будет заполнена..." следует писать "Если к ДО относится один СФ, он будет заполнен...".Исправлены ошибки склонения слова "счет-фактура" в описании идентификатора VzBaseDoc
102.1883359.1.112.0Нужна возможность в ТХО получить значение внешнего атрибута к Basefin по документам дебитора (или кредитора) Акта взаимозачетаХозоперацииРазноска ТХО по видам документов /укажите тип документа/
Документ "Акт взаимозачета". У него есть спецификация - с одной стороны документы Дебитора, с другой Кредитора. Есть возможность привязать внешние атрибуты к Basefin как для одних документов так и для других. Нужна возможность настроить ТХО так, что бы можно было получить BaseFin.Nrec и потом получить значение привязанного атрибута с помощью TXOGetExtAttr. Пользователь в качестве внешнего атрибута использует ссылку на аналитику "счета бух.учета". Привязывает такой атрибут и к документам дебитора и к документам кредитора. В ТХО они хотят анализировать значение этого атрибута для формирования нужных им проводок. ТХО будет привязываться непосредственно к Акту.С помощью &KAU[Кау:5038][Режим:160] и &KAU[Кау:5038][Режим:161] из режимов 0 и 1 можно получить Nreс спецификации АВЗ дебитора и кредитора (нужна циклическая обработка по аналитике Спецификации сопроводительных документов)
102.1757699.1.111.0КИС ФХД ТПР2 Очередь1 Если к ПП привязан договор, то при выборе контрагента в поле Взаимозачет он не попадает в хозоперацию.Расчеты с поставщиками и получателямиЗачет обязательств
КИС ФХД ТПР2 Очередь1 Если к ПП привязан договор, то при выборе контрагента в поле "Платеж за" он не попадает в хозоперацию.Добавлена пользовательская настройка "Настройки Галактики Бухгалтерский контур Обработка документов Распределение платежа по договорам Наследовать контрагент из договора в хозяйственную операцию" со значением по умолчанию "по запросу". Данная настройка влияет на наследование контрагента договора в хозяйственную операцию платежного документа. Ранее контрагент договора всегда переносился в хозяйственную операцию, теперь данная возможность регулируется вышеуказанной настройкой. Обрабатывается при привязке договора, соглашения, товарного и финансового ПКП. При указании в платежном документе контрагента в поле "Платеж за", он автоматически переносится во все хозоперации платежного документа по которым нет разноски по ДО и Договорам. Если по хозоперации есть разноска по договору, то хозоперации присваивается контрагент из поля "Платеж за", а затем запускается обработка настройки "Настройки Галактики Бухгалтерский контур Обработка документов Распределение платежа по договорам Наследовать контрагент из договора в хозяйственную операцию", в зависимости от значения которой в хозоперации остается либо контрагент из поля "Платеж за", либо подставляется контрагент договора. При удалении в платежном документе контрагента из поля "Платеж за", он автоматически сбрасывается на контрагент платежного документа во всех хозоперациях платежного документа по которым нет разноски по ДО или по договорам. Если по хозоперации есть разноска по договору, то хозоперации присваивается контрагент платежного документа, а затем запускается обработка настройки "Настройки Галактики Бухгалтерский контур Обработка документов Распределение платежа по договорам Наследовать контрагент из договора в хозяйственную операцию", в зависимости от значения которой в хозоперации остается либо контрагент платежного документа, либо подставляется контрагент договора.
102.1860639.1.111.0Не правильно формируется платежное поручение, если установлен фильтрФинансово-расчетные операцииПлатежное поручение
Не правильно формируется платежное поручение, если установлен фильтр. После обновления происходят чудеса с созданием собственных платежных поручений Суть в том что, если создавать платежное поручение из общего списка и привязывать к нему сразу ДО (без выбора контрагента в обязательном поле), то ПП создается корректно но, если отфильтровать список по контрагенту и так же попробовать создать новое платежное поручение, не выбирая контрагента в обязательном поле, а попробовать привязать к нему ДО,то ПП создается, но из общего списка оно пропадает и курсор перескакивает на самый первый документ из всего списка. Если снять фильтры, то мы увидим, что ПП создалось, но без номера счета и суммы и получателя. Но на закладке документ-основание оно прописалось и в самом ДО обозначено, что платеж к нему привязан уже. До обновления такого не было.Если в интерфейсе ПП установлен фильтр, и выполняется создание нового документа, путем привязки ДО, то перед выполнением данной операции снимается установленный фильтр, выполняется формирование платежки по выбранному ДО, а затем возвращается исходный фильтр, при этом выполняется проверка на попадание созданной записи в условия данного фильтра. Если новый документ не удовлетворяет фильтру, то пользователю предлагается снять заданный фильтр. Если пользователь не согласился снять фильтр, то созданный документ исчезает из текущей выборки документов и увидеть его можно будет только сняв фильтр.
106.105579.1.111.0пакетное заполнение поля "Платеж за..."Финансово-расчетные операцииВходящие документы
пакетное заполнение поля "Платеж за..." Часто бухгалтерам приходится формировать массу однообразных платежных документов, в которых необходимо менять плательщика (поле "Платеж за..."). Таких документов у клиента бывает порядка 200 за раз Контрагент ДО, который привязывается к ПП, тот же, что тот, что в поле "Платеж за", и для группы ПП - один и тот же Клиент просит автоматизировать данную массовую операцию Решение видится, например, через функцию "Групповая замена поля в документах" или добавление функции "Пакетное заполнение поля Платеж за...", аналогично пакетному заполнению поля назначениеРеализована поддержка групповой замены для поля "Платеж за". Для использования групповой замены поля необходимо пометить группу платежных документов, в которых необходимо установить одинаковое значение поля "Платеж за". Затем в окне редактирования платежного документа с нужным значением поля "Платеж за", установить курсор в этом поле и выполнить пункт локального меню "Групповая замена поля в документах" или выполнить вызов команды с помощью сочетания горячих клавиш Alt+K. В результате, во всех помеченных платежных документах будет установлено значение поля "Платеж за" равное текущему. При этом будет выполнена синхронизация значения поля "Платеж за" из шапки платежного документа в поле "Контрагент" всех хозяйственных операций документа. Синхронизация выполнятся по правилам описанных в ПИР 102.175769.
101.651109.1.110.0Нужна новая точка расширения регистрации в ККТ для приходного кассового ордераКассаПриходный кассовый ордер
Нужна новая точка расширения регистрации в ККТ для приходного кассового ордера Клиент просит реализовать новую точку расширения, которая будет вызываться даже в случае отсутствия распределения: Бизнес-процесс формирования приходных кассовых ордеров. Основная масса приходных кассовых ордеров оформляется следующим образом: Плательщик приходит к сотруднику отдела кассово-банковских операций и сообщает ему, какую услугу он намеревается оплатить (внести плату по договору платного обучения, оплатить общежитие, оплатить услуги библиотеки или издательского центра и т.п., либо внести излишне выданную в подотчет сумму и т.д.). Сотрудник вводит в системе ПКО, распечатывает его, отдает плательщику, плательщик идет в кассу и оплачивает. Ни ДО ни сопроводительные документы при этом не создаются. Поэтому, назначение платежа для передачи в кассовый аппарат можно либо брать из полей назначения платежа таблицы PLPOR, но тогда это будет длинный текст, поскольку при оформлении кассового ордера указывают и номер договора и номер семестра и т.п. Поэтому, предлагаю брать назначение платежа их поля примечание, которое можно будет заполнять в ПКО по шаблону, например "Образовательные услуги", "Услуги библиотеки", "Оплата проживания в общежитии", "Возврат подотчетных сумм" и т. п. Полное описание - в файла во вложении.Добавлена новая точка расширения регистрации в ККТ для кассового ордера, в котором отсутствует разноска по первичным документам: ExtensionPoint epKO_KKTRegistrWithOutSoprDoc(wTiDk, wOperation: word; sAdmPass, sOperatorPass, sNamePos, sNamePl1, sNamePl2, sNamePl3 : string; dSum, dTaxRate, dSumTax: double; pObject : pointer); Описание входящих параметров: - wTiDk - тип документа; - wOperation - тип операции (0-не определен; 1-продажа; 2-возврат продажи; 3-покупка; 4-возврат покупки); - sAdmPass - пароль администратора системы (настройка "Настройки Галактики Бухгалтерский контур Касса Пароль администратора для ККТ"); - sOperatorPass - пароль оператора для ККТ (настройка "Настройки Галактики Бухгалтерский контур Касса Пароль оператора для ККТ"); - sNamePos - значение поля "Приложение" кассового документа (значение поля PlPor.NamePl4); - sNamePl1 - первая строка основания для приема денег в кассу (значение поля PlPor.NamePl1); - sNamePl2 - вторая строка основания для приема денег в кассу (значение поля PlPor.NamePl2); - sNamePl3 - третья строка основания для приема денег в кассу (значение поля PlPor.NamePl3); - dSum - сумма платежа (значение поля PlPor.SumPlat); - dTaxRate - ставка налога типа "НДС" (если налоги типа "НДС" отсутсвуют, то передается значение "-1"); - dSumTax - сумма всех налогов типа НДС по платежному документу (если налоги типа "НДС" отсутствуют, то передается значение "-1"); - pObject - ссылка на драйвер кассового аппарата. Алгоритм регистрации в ККТ. При нажатии на кнопку "Регистрация в ККТ" выполняется проверка, каким способом производить регистрацию. Если привязано ДО и есть распределение по спецификации накладной/акта, то регистрация выполняется по распределенным позициям спецификации накладной/акта, когда для каждой оплаченной позиции вызывается точка расширения epKO_KKTRegistration (стандартная схема). Если отсутствует ссылка на ДО, то регистрация будет проводится по всему документу с помощью одного вызова точки расширения epKO_KKTRegistrWithOutSoprDoc (новая схема). При этом, если включена настройка "Настройки Галактики Бухгалтерский контур Касса Отображать системный интерфейс регистрации в ККТ", то перед выполнением регистрации, пользователю будет отображено окно, с полученными параметрами регистрации.
102.1868899.1.110.0Atl5532. Ошибки при печати авансового отчета в FR.КассаАвансовый отчет
Atl5532. Ошибки при печати авансового отчета в FR: --------------------------- FastReport - Ошибка --------------------------- Были обнаружены следующие ошибки: Memo173: Could not convert variant of type (OleStr) into type (Double) Memo174: Could not convert variant of type (UnicodeString) into type (Double) Memo175: Could not convert variant of type (OleStr) into type (Double) Memo176: Could not convert variant of type (UnicodeString) into type (Double) Memo179: Could not convert variant of type (OleStr) into type (Double) Memo180: Could not convert variant of type (UnicodeString) into type (Double) Memo181: Could not convert variant of type (OleStr) into type (Double) Memo182: Could not convert variant of type (UnicodeString) into type (Double) --------------------------- ОК ---------------------------Указанные ошибки исправлены.
101.649799.1.109.0Добавить тип операции (wOperation) с кодом 4 "возврат покупки", для обработки при печати в ККТКассаПриходный кассовый ордер
Добавить тип операции (wOperation) с кодом 4 "возврат покупки", для обработки при печати в ККТ Клиенту необходимо напечатать чек в случае когда нужно получить обратно деньги от продавца при возврате клиентом товара: Продавец чек напечатает для СВОЕЙ кассы. Мы эти наличные вносим в НАШУ кассу. И этот факт должны зарегистрировать в НАШЕЙ кассе как ВОЗВРАТ РАСХОДА. Когда мы покупали у этого продавца, то в НАШЕЙ кассе регистрировали покупку как РАСХОД. Теперь вернули купленный товар. И должны зарегистрировать ВОЗВРАТ РАСХОДА.На данный момент для регистрации в ККТ передаются следующие типы операций: 1) Для приходного кассового ордера определяется тип операции - Продажа (значение кода = 1). 2) Для расходного кассового ордера определяется тип операции - Покупка (значение кода = 3). 3) Для расходного кассового ордера, в случае наличия связи с продажей, определяется тип операции Возврат продажи (значение кода = 2). Добавлен новый тип операции: 4) Для приходного кассового ордера, в случае наличия связи с покупкой, определяется тип операции Возврат покупки (значение кода = 4).
102.1858659.1.109.0Пропадает "Получатель" в собственных рублевых ППФинансово-расчетные операцииПлатежное поручение
После добавления колонки "Назначение платежа" в интерфейс перечня валютных собственных платежных поручений, в интерфейсе перечня и редактирования собственных рублевых платежных поручений пропадает значение "Получатель". Аналогично происходит при добавлении колонки "Договор" (dogovor.nodoc) в перечень.Исправлено.
102.1863189.1.109.0В случае, когда валюта аванса отлична от НДЕ эта сумма не выводится в отчетные формы АОКассаАвансовый отчет
В случае, когда валюта аванса отлична от НДЕ эта сумма не выводится в отчетные формы АО. Требуется доработка вывода сведений в отчет. Авансовый отчет в FastReport Настройка печати : по спецификации АО Оборотная сторона отчета: сумма расхода по отчету/колонка "в валюте" должна быть сумма в валюте, а не в НДЕисправлено
102.1863999.1.109.0ATL5532 Ошибка при печати бух.справки в формате FastReportКонтуры: финансовый, бухгалтерского учетаНе знаю, какая именно часть финансового контура, научите
ATL5532 Ошибка при печати бух.справки в формате FastReport --------------------------- FastReport - Ошибка --------------------------- Были обнаружены следующие ошибки: Memo2: Could not convert variant of type (OleStr) into type (Double) Memo6: Could not convert variant of type (OleStr) into type (Double) --------------------------- ОК --------------------------- Модуль ФРО -Документы - Бухгалтерские справкиФормат указанных полей печатной формы изменен на "текст".
102.1827479.1.108.0Необходима возможность изменить дату хозоперации к бухсправке на раньше даты самой бухсправкиФинансово-расчетные операцииБухгалтерская справка
Необходима возможность изменить дату хозоперации к бухсправке на раньше даты самой бухсправки. Пишут:До внедрения КИС ЭХД бухгалтер делал много бух справок разной датой. Сейчас чтобы уменьшить количество печатаемых справок все вводится одной бух справкой (один штрих-код), но операции проводятся разной датой. Предложение связано с проведением хозоперации в валюте. Нужен курс на дату хозоперации, а не бухсправки.Добавлена пользовательская настройка "Настройки Галактики Бухгалтерский контур Обработка документов Значения полей по умолчанию Бухгалтерские справки Дата хозоперации может быть раньше даты оплаты документа" со значением по умолчанию - "нет". Включение данной настройки позволяет пользователю в хозоперациях бух.справки указать любую дату проведения хозяйственной операции. Включение данной настройки приводит к игнорированию для бухгалтерских справок настройки "Настройки Галактики Бухгалтерский контур Обработка документов Хозяйственные операции и бухгалтерские проводки Проверять соответствие дат проведения хозопераций и документа". При установке даты оплаты в бух.справке новая дата устанавливается только в хоз.операции без даты операции. А при удалении даты, в хозоперациях дата операций остается неизменной.
106.105969.1.108.0Не та дата реестра в Сводном реестре по перечислениям с расшифровкойФинансово-расчетные операцииРеестры по перечислениям
Не та дата реестра в Сводном реестре по перечислениям с расшифровкой. В отчете Сводный реестр по перечислениям с расшифровкой в поле Дата реестра вместо даты формирования реестра выводится месяц начисления.Доработан отчет Реестра на перечисление "Сводный реестр по перечислениям с расшифровкой": значение выводимое в поле "Дата реестра" заменено на Дату формирования реестра.
101.647679.1.107.0Замедление при печати приходного кассового ордераКассаПриходный кассовый ордер
Замедление при печати приходного кассового ордера При печати на последней версии компонента F_PLPOR(9.1.106.0) на Оракл наблюдается сильное замедление печати в случае, если есть сформированные проводки. У меня удалось воспроизвести замедление на тестовой БД (Оракл). Итоговый Word-документ имеет размер от 300 до 500 Мб. Пример части информации этого файла - во вложении. Мои SMART-логи выложил в совместный обмен на имя Голдин О.Ю.Оптимизирована печать платежных документов PlPor при включенном параметре UseBrowserCacheAndSort
101.630979.1.106.0Расширить функционал групповой замены поля в документе на поле "Назначение платежа"Финансово-расчетные операцииПлатежное поручение
Расширить функционал групповой замены поля в документе на поле "Назначение платежа" Клиенту регулярно приходится менять назначение платежа во многих платёжках. Предлагает расширить функционал и на изменение назначения платежаРасширен функционал групповой замены поля в платежных документах на полях "Назначение платежа" (4 поля: PlPor.NamePl1 - PlPor.NamePl4)
102.1418579.1.106.0При быстром поиске документа (верхняя панель) не обновляется содержимое нижней панели (пока не кликнем на документе мышью)Финансово-расчетные операцииПлатежное поручение
При быстром поиске документа (верхняя панель) не обновляется содержимое нижней панели (пока не кликнем на документе мышью) Обращаем внимание, что ранее (по крайней мере на версии 8.1) это отрабатывало.Во время выполнения быстрого поиска, для корневой таблицы не посылается событие cmPositionChanged. В результате нет возможности выполнить перерисовку встроенных интерфейсов, потому что выполняется она в момент возникновения этого события. Однако, во время быстрого поиска событие cmPositionChanged посылается для всех остальных таблиц логической таблицы, что бы они перерисовывались в процессе быстрого поиска по корневой таблице. Благодаря этому, есть возможность повесить обновление встроенных интерфейсов на событие изменения позиции, допустим по таблице хозяйственных операций. Что и было сделано.
102.1838749.1.106.0Необходимо ускорить открытие карточки документа (авансовый отчёт)КассаАвансовый отчет
Касса -Документы - Авансовый отчет - ПКМ меню - Карточка документа, формирование длится более получаса. Если отвязать ДО, то открывается быстро.Исправлено корректное обращение к таблице "Сопроводительные документы".
180.107469.1.106.0Печать приходного кассового ордера. Уплыл размер шрифта расшифровки подписиКассаПриходный кассовый ордер
В печатной форме приходного кассового ордера КО-1, на квитанции к ордеру расшифровка подписи (главный бухгалтер, кассир) выходит с 6 размером шрифта Courier New, хотя во всех других полях формы все фамилии выходят 8 размером.В печатной форме приходного кассового ордера КО-1, на квитанции к ордеру расшифровка подписи (главный бухгалтер, кассир) размером шрифта, изменен с 6 до 8.
102.1839959.1.105.0Обеспечение корректной работы на докомпилированном словаре Галактики ERP 9.1Предложение по новой функциональности Галактики ERP (по системе в целом)?
Необходимо обеспечить корректную работу ресурсов на докомпилированном словаре Alter_Cumulative 9.1.12.0.Обеспечение корректной работы. На докомпилированном словаре пересобраны ресурсы работающие и изменёнными таблицами. Комплектность установки ресурсов обеспечена требованиями при установке.
102.1675709.1.104.0Отображение признака наличия ФОБ по платежному поручениюФинансово-расчетные операцииПлатежное поручение
Включили формирование ФОБ по собственным и сторонним ПД через ФРО. Стал доступен пункт Финансовые обязательства, ФОБ формируется. Но не видно по каким поручениям, уже сформировано ФОБ. В ДО есть колонка Ф, которая показывает наличие ФОБ по документу. Предлагаем доработать аналогичную колонку в интерфейсе платежных поручений, чтобы видеть, по каким документам уже сформированы ФОБВ списке платежных документов добавлена колонка (без подписи), в которой выводится информация о распределении документа по ФО, а именно: выводится буквы П, Ч, Н П - полностью распределен Ч - частично распределен Н - не распределен
102.1701689.1.104.0Пропадают фин.операцииФинансово-расчетные операцииПлатежное поручение
На предприятии ведется много различных расчетных счетов организации. В платежке проставляют проводки и финансовые операции в управленческом плане счетов. Некоторым платежкам приходиться менять раздел путем переноса стандартной функцией. При этом бух проводки сохраняются, а фин проводки пропадают.При переносе платежек в другой раздел стандартной функцией бух проводки и фин проводки сохраняются.
102.1720559.1.104.0Синхронизировать сумму к выплате с суммой начисленнойФинансово-расчетные операцииРеестры по перечислениям
При формировании суммы к выплате(SPPLBAN.SUMOPL) в реестре по перечислениям с помощью ФЛМ "Распределить сумму равномерно" и "Установить фиксированную сумму по сотруднику", значение в поле сумма начисленная(SPPLBAN.SUMUD) не меняется, в отличие от ручной корректировки.Значение в поле сумма начисленная(SPPLBAN.SUMUD) меняется при формировании суммы к выплате в реестре по перечислениям с помощью ФЛМ "Распределить сумму равномерно" и "Установить фиксированную сумму по сотруднику".
102.1833209.1.104.0Платежная ведомость удаляется несмотря на отрицательный ответ на вопрос о необходимости удаленияКассаПлатежные ведомости
Платежная ведомость удаляется несмотря на отрицательный ответ на вопрос о необходимости удаления. При попытке удаления ведомости, по которой сформированы документы, пользователю выдается сообщение с вопросом "По ведомости NNNN сформированы документы. Удалить платежную ведомость?". Но независимо от ответа удаление продолжается и если документы, сформированные по ведомости, не закрыты для редактирования, ведомость будет удалена.При удалении платежной ведомости система учитывает отрицательный ответ пользователя на вопрос о необходимости удаления записи.
102.1822679.1.103.0Не запускать пересчет прав в авансовом отчете при работе с документомКассаАвансовый отчет
Не запускать пересчет прав в авансовом отчете при работе с документом при включении настройки "Сохранять рассчитанные права при разграничении доступа" не нужно запускать пересчет прав при работе с документом(автоматическое изменение суммы).Теперь пересчет прав запускается только один раз при запуске.