С выходом релиза 1.3.202.1 конфигурации «Управление производственным предприятием» (УПП) многие пользователи столкнулись с критической проблемой при работе с торговым оборудованием. При попытке пробить кассовый чек на основании документов оплаты, если в заказе присутствует более одной товарной позиции, система выдает ошибку, связанную с неправильной суммой НДС, или сообщает, что чек оплачен не полностью. В этой статье мы подробно разберем, почему возникает данная ситуация, и как ее исправить программным путем.
Давайте проанализируем ситуацию. Проблема чаще всего проявляется в компаниях, где используется схема ведения взаиморасчетов «По заказам». При пробитии чека (например, из документа «Оплата от покупателя под платежную карту») наблюдаются следующие симптомы:
«Чек оплачен не полностью», так как итоговая сумма по строкам не сходится с переданным итогом.Рассмотрим причину глубже. В релизе 202.1 разработчики внедрили новый механизм распределения сумм платежа по товарным позициям. Логика этого механизма находится в общем модуле МенеджерОборудованияВызовСервера. Именно там происходит расчет коэффициента, который должен пропорционально делить оплату между товарами, но в определенных условиях этот алгоритм отрабатывает неверно.
Разберем первый вариант решения, который позволяет сохранить логику частичных оплат, но устраняет ошибку «зацикливания» всей суммы на первой строке. Нам необходимо внести изменения в процедуру ЗаполнитьТоварнуюСтрокуЧека.
Найдем в модуле МенеджерОборудованияВызовСервера следующую строку:
Если ЗначениеЗаполнено(СтрокаПозиции.СуммаПлатежа) Тогда
Проблема заключается в том, что условие срабатывает слишком часто, даже когда пересчет не требуется. Нам нужно добавить проверку, чтобы коэффициент рассчитывался только в том случае, если сумма платежа действительно отличается от суммы товарной строки. Заменим эту строку на следующий код:
Если ЗначениеЗаполнено(СтрокаПозиции.СуммаПлатежа) И СтрокаПозиции.СуммаПлатежа < СтрокаЧека.Сумма Тогда
Этот подход позволяет избежать некорректного умножения суммы строки на коэффициент, когда это не требуется, и восстанавливает нормальную работу печати чеков для многострочных заказов.
Если ваше предприятие не использует сложные схемы частичной предоплаты, при которых требуется филигранное распределение копеек между позициями в момент пробития чека постоплаты, можно применить более радикальный, но стабильный метод. Рассмотрим вариант с полным отключением проблемного блока, который был добавлен в релизе 202.1.
В той же процедуре ЗаполнитьТоварнуюСтрокуЧека модуля МенеджерОборудованияВызовСервера найдем блок кода, отвечающий за распределение оплат, и закомментируем его целиком:
// Частичная оплата
// Если ОбщегоНазначенияКлиентСервер.ЕстьРеквизитИлиСвойствоОбъекта(СтрокаПозиции, "СуммаПлатежа") Тогда
// Если ЗначениеЗаполнено(СтрокаПозиции.СуммаПлатежа) Тогда
// Коэффициент = ?(СтрокаЧека.Сумма > 0, СтрокаПозиции.СуммаПлатежа / СтрокаЧека.Сумма, 1);
// Если Коэффициент <> 1 Тогда
// СтрокаЧека.Сумма = Окр(СтрокаЧека.Сумма * Коэффициент, 2, 1);
// СтрокаЧека.Цена = Окр(СтрокаЧека.Цена * Коэффициент, 2, 1);
// СтрокаЧека.ЦенаСоСкидками = Окр(СтрокаЧека.ЦенаСоСкидками * Коэффициент, 2, 1);
// СтрокаЧека.СуммаНДС = Окр(СтрокаЧека.СуммаНДС * Коэффициент, 2, 1);
// КонецЕсли;
// КонецЕсли;
// КонецЕсли;
Проанализируем последствия: данный блок отсутствовал в предыдущих стабильных релизах (например, в ветке 1.3.194.х), и его отключение возвращает систему к старой, проверенной временем логике формирования чека. Это гарантирует, что СтрокаЧека.Сумма и СтрокаЧека.СуммаНДС будут переданы в драйвер в неизменном виде, как они рассчитаны в самом документе 1С.
Важно помнить, что фирма «1С» оперативно реагирует на подобные ошибки в тиражных решениях. Выясним, какие альтернативы ручной правке кода существуют на данный момент:
Прежде чем применять изменения в рабочей базе, выполним несколько проверочных действий:
Таким образом, мы выяснили, что причина сбоя кроется в некорректном внедрении алгоритма распределения платежей в модуле МенеджерОборудованияВызовСервера. Использование предложенных правок или установка официального патча позволит вам восстановить работоспособность кассового узла без необходимости изменять устоявшиеся бизнес-процессы предприятия и переходить с расчетов «По заказам» на расчеты «По документам».