При обновлении конфигурации «1С:Управление торговлей 10.3» до релиза 10.3.67.1 многие пользователи столкнулись с неприятной особенностью. При добавлении товара в существующий (не проведенный) документ через механизм подбора, данные в строках обновляются некорректно. Рассмотрим ситуацию подробнее: если мы добавляем номенклатуру, которая уже присутствует в табличной части, количество и СуммаБезСкидки увеличиваются, но вот итоговая Сумма, СуммаНДС и поле Всего застывают на прежних значениях. В этой статье мы разберем причину этого поведения, проанализируем программный код и найдем способ исправления ошибки.
Давайте проанализируем стандартный сценарий работы менеджера. Открывается существующий ЗаказПокупателя, который еще не проведен. Менеджер нажимает кнопку «Подбор», выбирает позицию, которая уже есть в документе. В этот момент ожидается, что система просто увеличит количество в существующей строке и пересчитает все финансовые показатели. Однако на практике мы видим следующее:
Количество обновляется правильно.СуммаБезСкидки (цена умноженная на новое количество) обновляется правильно.Сумма, Сумма НДС и Всего остаются старыми.Важно отметить, что если документ уже был проведен до момента подбора, ошибка может не проявляться. Это связано с тем, что алгоритмы обработки табличных частей для проведенных и непроведенных документов могут различаться в части вызова процедур актуализации данных.
Для того чтобы понять, почему так происходит, нам необходимо обратиться к конфигуратору и исследовать общий модуль ОбработкаТабличныхЧастей. Опытным путем и через сравнение версий конфигураций (10.3.66.3 и 10.3.67.1) было выяснено, что корень проблемы кроется в процедуре ПроверкаМинимальнойЦены.
Разберем логику, которую добавили разработчики в релизе 10.3.67.1. В коде появилось условие, которое проверяет, заполнена ли уже сумма в строке. Замысел был в том, чтобы не пересчитывать лишний раз то, что уже рассчитано. Но именно это условие блокирует обновление данных при подборе, так как при добавлении товара в существующую строку сумма там уже больше нуля.
Посмотрим на фрагмент кода, который вызывает сбой. В релизе 10.3.67.1 процедура ПроверкаМинимальнойЦены содержит следующий блок:
// Фрагмент кода из релиза 10.3.67.1
Если СтрокаТовара.Сумма = 0 Тогда
СтрокаТовара.Сумма = СтрокаТовара.СуммаБезСкидки * (1 - (СтрокаТовара.ПроцентАвтоматическихСкидок + СтрокаТовара.ПроцентСкидкиНаценки) / 100);
КонецЕсли;
Проанализируем эту ситуацию. Когда мы подбираем товар, система находит существующую строку. В ней уже есть какое-то количество и какая-то сумма (например, 100 рублей). Мы добавляем еще одну единицу товара. СуммаБезСкидки становится, допустим, 200 рублей. Но так как СтрокаТовара.Сумма (старая) равна 100, а не 0, условие Если СтрокаТовара.Сумма = 0 возвращает Ложь. В результате расчет новой суммы просто игнорируется.
Поскольку значение в колонке Сумма не изменилось, платформа не генерирует событие «ПриИзменении» для этой колонки. А ведь именно к этому событию «привязаны» дальнейшие расчеты НДС и итогов по документу. Цепная реакция прерывается, и пользователь видит некорректные цифры.
Самым эффективным решением (так называемым «хотфиксом») является возвращение к логике предыдущего, стабильного релиза. Нам нужно убрать условие, проверяющее равенство суммы нулю, чтобы расчет выполнялся всегда при вызове процедуры.
Порядок действий для программиста:
ОбработкаТабличныхЧастей.ПроверкаМинимальнойЦены.Если...КонецЕсли).Правильный вариант кода должен выглядеть так:
// Исправленный код (как было в 10.3.66.3)
СтрокаТовара.Сумма = СтрокаТовара.СуммаБезСкидки * (1 - (СтрокаТовара.ПроцентАвтоматическихСкидок + СтрокаТовара.ПроцентСкидкиНаценки) / 100);
После этого изменения при каждом подборе сумма будет рассчитываться заново исходя из актуальной СуммыБезСкидки, что автоматически запустит пересчет НДС и поля Всего.
Если у вас нет возможности немедленно внести изменения в конфигуратор (например, база находится на поддержке без возможности редактирования), можно воспользоваться обходным путем. Рассмотрим, как заставить программу пересчитать итоги принудительно.
В верхней части документов (таких как ЗаказПокупателя или РеализацияТоваровУслуг) есть кнопка «Цены и валюта». Нажатие на эту кнопку открывает диалоговое окно настроек. Если в этом окне просто нажать кнопку «ОК», система инициирует полный пересчет всей табличной части документа. Это «протолкнет» застрявшие значения, обновит Сумму и корректно рассчитает НДС. Однако этот способ требует ручного вмешательства при каждом подборе, поэтому программное исправление является предпочтительным.
Проанализируем, какие еще области учета затрагивает этот баг. Поскольку процедура ПроверкаМинимальнойЦены является универсальной, проблема может проявляться в целом ряде документов:
Счет на оплату покупателюРеализация товаров и услугОтчет о розничных продажахЧек ККМОсобенно критична ошибка для документов, где расчет НДС должен быть предельно точным для корректного формирования счетов-фактур. Если менеджер не заметит, что итоговая сумма документа не изменилась после добавления позиций, это приведет к расхождениям в первичных документах и налоговой отчетности.
Выясним, как лучше поступить, если вы обнаружили данную ошибку. Фирма «1С» признала наличие этой проблемы, и в последующих релизах (начиная с 10.3.68.1 и выше) данная логика была скорректирована. Если вы все еще работаете на версии 10.3.67.1, мы настоятельно рекомендуем выполнить обновление до актуального релиза (например, 10.3.70.x или свежее). Если же обновление по каким-то причинам невозможно, воспользуйтесь приведенным выше примером исправления кода в общем модуле.
Подводя итог, можно сказать, что ошибка в релизе 10.3.67.1 является классическим примером того, как избыточная оптимизация кода (попытка избежать лишних расчетов через условие Если Сумма = 0) может привести к нарушению работы базовых механизмов системы. Будьте внимательны при обновлении и всегда проверяйте работу критически важных функций, таких как подбор и расчет цен, на тестовых копиях баз данных.