При работе с маркированным товаром в конфигурации 1С:Управление торговлей (редакция 11.4) пользователи часто сталкиваются с критической ошибкой при попытке пробить чек из документа «Реализация товаров и услуг». Проблема проявляется сообщением «Деление на 0», указывающим на общий модуль РозничныеПродажи. В этой статье мы подробно разберем причины возникновения этой ситуации, проанализируем программный код и найдем способ решения через создание расширения.
Разберем ситуацию: в документе реализации присутствует одна позиция товара в количестве нескольких штук (например, 4 шт.). При этом каждый экземпляр товара имеет свой уникальный код маркировки (КМ), и, что критично, эти коды могут иметь разные GTIN (например, из разных партий или поставок). Также товар может списываться с разных номеров ГТД (разные виды запасов).
Ошибка возникает в строке 128 общего модуля РозничныеПродажи.Модуль:
СтрокаТоваровСРаспределением.Цена = (СтрокаТЧ.СуммаСНДС - СтрокаТЧ.СуммаСкидки) / СтрокаТЧ.КоличествоУпаковок;
Проблема заключается в том, что переменная СтрокаТЧ.КоличествоУпаковок в момент выполнения кода принимает значение 0. Это происходит из-за того, что механизм распределения кодов маркировки по видам запасов не смог правильно сопоставить считанные марки с физическими строками товаров в документе.
Проанализируем работу системы в связке с SQL-сервером. В типовом решении 1С выполняется запрос, который собирает данные из таблицы товаров и сопоставляет их с данными ИСМП и штрихкодами. Посмотрим на фрагмент запроса, который участвует в подготовке данных:
|ВЫБРАТЬ
| ТаблицаТовары.Номенклатура КАК Номенклатура,
| ТаблицаТовары.Характеристика КАК Характеристика,
| ТаблицаТовары.Упаковка КАК Упаковка,
| Штрихкоды.Штрихкод КАК Штрихкод,
| ВЫБОР
| КОГДА ТаблицаТовары.Упаковка = Штрихкоды.Упаковка
| ТОГДА 2
| ИНАЧЕ 1
| КОНЕЦ КАК ПриоритетШтрихКода
|ПОМЕСТИТЬ Штрихкоды
|ИЗ
| ТаблицаТовары КАК ТаблицаТовары
| ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ШтрихкодыНоменклатуры КАК Штрихкоды
| ПО ТаблицаТовары.Номенклатура = Штрихкоды.Номенклатура
Когда мы имеем дело с серверной базой данных, результат выборки без явной сортировки может возвращаться в произвольном порядке. Если у одной номенклатуры несколько GTIN и несколько записей в справочнике штрихкодов, система может выбрать «не тот» штрихкод в качестве основного. Это приводит к тому, что при последующем соединении в процедуре ТаблицаТоваровСРаспределениемКодовМаркировкиИСМП данные «расползаются».
Особую сложность добавляет распределение по видам запасов. Если товар в количестве 4 штук распределился на 2 разные ГТД, система создает промежуточную таблицу. Если порядок строк в этой таблице не совпадает с порядком распределения кодов маркировки, возникают пустые строки (с нулевым количеством), на которых и происходит «падение» системы.
Для исправления этой ошибки мы воспользуемся механизмом расширений, чтобы не снимать конфигурацию с поддержки. Наша задача — обеспечить стабильный порядок строк при подготовке данных для видов запасов.
РеализацияТоваровУслуг.ДанныеДляВидовЗапасов.НомераСтрок проходило корректно, необходимо принудительно отсортировать таблицу значений перед ее дальнейшей обработкой.Пример кода в расширении для модуля менеджера документа РеализацияТоваровУслуг:
&После("ДанныеДляВидовЗапасов")
Функция Испр_ДанныеДляВидовЗапасов(ДокументСсылка, МенеджерВременныхТаблиц)
// Получаем результат стандартной обработки
Результат = ПродолжитьВызов(ДокументСсылка, МенеджерВременныхТаблиц);
// Если результат является таблицей значений, выполняем жесткую сортировку
// по аналитике учета и количеству. Это позволит процедурам распределения
// в общем модуле "РозничныеПродажи" корректно сопоставить данные.
Если ТипЗнч(Результат) = Тип("ТаблицаЗначений") Тогда
Результат.Сортировать("АналитикаУчетаНоменклатуры, КоличествоУпаковок");
КонецЕсли;
Возврат Результат;
КонецФункции
Помимо программного исправления, следует проверить нормативно-справочную информацию. Рассмотрим, на что стоит обратить внимание:
GTIN, которые встречаются в кодах маркировки. Если система находит КМ с неизвестным GTIN, она может некорректно определить владельца штрихкода.ГТД, что иногда временно решает проблему без правки кода.Резюме: Ошибка «Деление на 0» при печати чека в УТ 11.4 — это следствие неудачного сопоставления кодов маркировки и строк документа при наличии разных GTIN или нескольких ГТД. Применение принудительной сортировки в расширении позволяет стабилизировать работу алгоритма на серверных базах и обеспечить успешную фискализацию чеков.