Откуда проблема
В одной аптеке пару раз в месяц случается одно и то же: чек пробит, а кодов маркировки в нём нет. Обмен с кассой сбоит, продажа проходит, и в 1С остаётся чек с маркированным препаратом без кода. Для «Честного знака» такая упаковка не выбыла и продолжает числиться за аптекой.
Исправлять приходится задним числом: найти такие чеки, понять, какой код был у проданной упаковки, внести его в чек и отправить в МДЛП уведомление 511. На каждом шаге есть своя ловушка, и почти все я нашёл, когда исправление «прошло», а результата не было.
Всё ниже проверено на копии рабочей базы: «1С:Розница 8. Аптека», редакция 3.0, релиз 3.0.14.123, платформа 8.5. Скриншоты сняты на демо-данных, реальных чеков и кодов в них нет.
Где в чеке лежат коды
Коды хранятся не в строке товара, а в отдельной табличной части чека ор_НомераУпаковок. Со строкой товара её связывает идентификатор строки: Запасы.ор_ИдентификаторСтроки = ор_НомераУпаковок.ИдентификаторСтроки. Сам код лежит в поле НомерКИЗ.
Признак «этой строке нужен код» тоже надо брать правильно. Штатная форма чека показывает значок ввода кодов только там, где у серии строки стоит «Маркируемый товар» (Характеристика.ор_МаркируемыйТовар). Флажок учёта маркируемых товаров в категории номенклатуры для этого не годится: на рабочей базе он дал 41 чек без кода вместо 18. Из 23 лишних 17 оказались пакетами и 3 туалетной бумагой: они лежат в «маркируемых» категориях, но кода не требуют. Остальные три: подгузники и пара товаров, у которых серия без признака маркировки. Показательный пример: один чек попадал в список «без кода» только из-за строки «Пакет» на 10 штук. После смены признака на серию в нём не осталось ни одной упаковки без кода, и из работы он пропал сам. Такие чеки при старом признаке съедают время: их открывают, ищут пропавший код и не находят, потому что его и не должно было быть. Реквизит строки «Необходимость ввода кода маркировки» тоже не подходит: в базе нашёлся чек, где товар маркируемый, код не введён, а флаг не выставлен.
Запрос, который находит чеки с маркируемыми строками без кода:
ВЫБРАТЬ
Ч.Ссылка КАК Чек,
Ч.Дата КАК Дата,
КОЛИЧЕСТВО(*) КАК ПозицийБезКода,
СУММА(З.Сумма) КАК СуммаБезКода
ИЗ
Документ.ЧекККМ.Запасы КАК З
ВНУТРЕННЕЕ СОЕДИНЕНИЕ Документ.ЧекККМ КАК Ч
ПО З.Ссылка = Ч.Ссылка
ГДЕ
З.Характеристика.ор_МаркируемыйТовар
И Ч.Дата МЕЖДУ &НачалоПериода И &КонецПериода
И НЕ З.ор_ИдентификаторСтроки В
(ВЫБРАТЬ
У.ИдентификаторСтроки
ИЗ
Документ.ЧекККМ.ор_НомераУпаковок КАК У
ГДЕ
У.Ссылка = З.Ссылка
И У.НомерКИЗ <> "")
СГРУППИРОВАТЬ ПО
Ч.Ссылка,
Ч.Дата
УПОРЯДОЧИТЬ ПО
Дата УБЫВ
Почему нельзя открыть чек и вписать код
Пробитый чек открывается только для просмотра. В форме чека при статусе «Пробит» вызывается УстановитьРежимТолькоПросмотр(), а команда «Отменить пробитие» появляется только у кассы, которая работает без подключённого оборудования.
По значку в строке окно «Ввод номеров упаковок» открывается, но добавить код в нём нельзя: кнопки неактивны, «Нужно ввести 1, введено 0».
Поэтому на практике код дописывают в обход формы, обычно универсальным редактором: добавляют строку в ор_НомераУпаковок с кодом и идентификатором строки товара и перепроводят чек. И вот тут начинается самое неприятное.
Код записан, а в базе его нет
Перепроведение проходит без единой ошибки, а кода в чеке после этого нет. Причина в типовой: перед записью чека вызывается УдалитьНеиспользуемыеНомераУпаковок, и она удаляет коды тех строк, у которых ор_СтатусЗаполненияУпаковок = 0. У чеков, пробитых без кодов, статус строк часто как раз 0. Форма чека пересчитывает статус при открытии, а в самой базе он остаётся старым.
На копии я воспроизвёл это на реальном чеке: запись «прошла», из двух дописанных кодов в базе не осталось ни одного. На других чеках тот же способ работал, потому что там статус был 1. Отсюда и ощущение «то работает, то нет».
Лечится двумя шагами. Перед записью выставить статус строки так же, как это делает типовая: 1, если кодов столько, сколько нужно, и 2, если меньше. После записи перечитать чек из базы и сверить коды, а не доверять объекту в памяти:
// перед записью: статус каждой строки, в которую добавили коды
Для Каждого КлючИЗначение Из ДобавленоНаСтроку Цикл
СтрокаЗапасов = Объект.Запасы.Найти(КлючИЗначение.Ключ, "ор_ИдентификаторСтроки");
Всего = Объект.ор_НомераУпаковок.НайтиСтроки(
Новый Структура("ИдентификаторСтроки", КлючИЗначение.Ключ)).Количество();
// НужноКодовСтроке — своя функция: 1 для части упаковки, иначе число упаковок в строке
СтрокаЗапасов.ор_СтатусЗаполненияУпаковок = ?(Всего >= НужноКодовСтроке(СтрокаЗапасов), 1, 2);
КонецЦикла;
Объект.Записать(РежимЗаписиДокумента.Проведение);
// после записи: что реально осталось в базе
ВЧеке = Новый Соответствие;
Для Каждого СтрокаКода Из Чек.ПолучитьОбъект().ор_НомераУпаковок Цикл
ВЧеке.Вставить(СтрокаКода.НомерКИЗ, Истина);
КонецЦикла;
Какой код вносить
В чек нужен код именно той упаковки, которую продали. Самой упаковки уже нет, поэтому код подбирается по данным 1С. Он должен прийти приходной накладной, оприходованием или приходным ордером с той же номенклатурой и той же серией и после этого нигде не выбыть: ни в другом чеке, ни в расходной накладной или ордере, ни в списании, ни в изготовлении лекарственных форм. Если таких свободных кодов столько же, сколько упаковок этой серии в чеке, код определён однозначно. Если больше, выбирает человек: на полке остаются упаковки с остальными кодами, и их можно исключить сканером.
Три вещи, на которые я наткнулся на реальных данных.
Код из этого же чека. Если в чеке две упаковки одной серии и у одной код уже стоит, второй его предлагать нельзя. Звучит очевидно, но в запросе «код нигде не выбыл» сам чек легко пропустить: он ещё не проведён с новым кодом или исключён из выборки как «текущий». Моя первая версия так и предлагала второй строке уже введённый код.
Дата прихода не повод отбрасывать код. В базе нашёлся чек от 26 февраля, а серия проданного препарата пришла единственной накладной, внесённой 27-го. Накладную просто внесли позже продажи, и верный код был именно в ней. Коды из приходов после даты чека я показываю, но только когда других нет, и сам не подставляю.
Код может стоять в строке другой серии. GTIN у разных серий одного препарата одинаковый, и форма чека принимает код чужой серии без вопросов. Для своей серии такой код выглядит «проданным», хотя на деле его ошибочно внесли в другой чек, и исправлять надо тот чек.
Бывает, что подбирать не из чего. Если приход внесли без кодов маркировки, в приходных документах кодов этой серии нет. Коды такой серии встречаются только в чеках, где их отсканировали при продаже, а код упаковки, проданной без сканирования, в 1С не найти никаким запросом.
Как это выглядит на живых чеках
Чтобы понять, насколько подбор вообще работает, я прогнал его по четырём чекам, которые аптека прислала как проблемные. В них было 14 упаковок без кода. Для 11 код нашёлся однозначно, для трёх остался выбор.
Среди однозначных были три «Меновазина» одной серии в одном чеке. По каждой строке отдельно вариантов три, и формально выбрать нельзя. Но свободных кодов этой серии тоже ровно три, а упаковок в чеке три, значит, ушли именно они. Поэтому сравнивать число свободных кодов надо не с одной строкой, а со всеми упаковками этой серии в чеке. Если сравнивать построчно, однозначный случай выглядит как неопределённый, и человеку приходится выбирать там, где выбирать нечего.
Однозначными оказались и обе продажи части упаковки: одна десятая пачки «Баралгина» и одна девятая пачки «Телзапа». Для них подбор смотрит прежде всего на уже вскрытые пачки, потому что блистер продают из начатой пачки, а не вскрывают новую.
Выбор остался у «Тагисты» и «Омепразола» (по два кандидата) и у «Натрия хлорида» (пять кандидатов). Здесь 1С честно не знает ответа, и решает человек у полки: те коды, которые он там отсканирует, в проданной упаковке быть не могли.
Потом я расширил прогон на все чеки из списка, это 45 упаковок, и сравнил результат с учётом даты прихода и без него. Построчно он совпал: на этих данных поздний приход встретился только в том февральском случае. Отдельно я проверил сценарий, где дата решает: сдвинул дату чека между двумя приходами одной серии, и вариантов стало не три, а один, а два кода пометились как пришедшие после продажи.
Вскрытые пачки: один код в нескольких чеках
Аптека продаёт пачку по блистерам. Код у пачки один, и он законно стоит в каждом чеке, где продали часть этой пачки. Остаток пачки типовая при проведении считает как 1,005 минус сумму долей из регистра ДолиУпаковокМДЛП по другим документам. Так же я считаю его и в своей проверке: доля строки должна в этот остаток поместиться.
Если своя проверка устроена как «код не должен стоять в других чеках», она запретит законный код. Так у меня и вышло: подбор честно предложил код вскрытой пачки, а проверка перед записью его отвергла со ссылкой на чек, где продали другие блистеры. Для части упаковки проверять надо не наличие кода в других чеках, а сумму долей.
И тут ещё две детали.
Коэффициент единицы округлён. У пачки из 9 блистеров единица имеет коэффициент 0,112. Девять блистеров по 0,112 дают 1,008, это больше 1,005, и последний блистер получит ложный отказ. Долю строки надо считать через количество первичных упаковок в единице: Количество / ор_КоличествоПервичныхУпаковок.
Код, внесённый в чек задним числом, в регистр долей не попадает. Я дописал код в чек и перепровёл его: запись о доле этого чека в ДолиУпаковокМДЛП не появилась. Значит, следующий блистер той же пачки упрётся уже в этот чек. Долю чека, которого нет в регистре, приходится брать из его строки.
Доля = ?(Первичных > 0, Количество / Первичных, Количество * Коэффициент);
Если ДоляСтроки > 1.005 - ПроданоВДругихДокументах Тогда
// пачка уже продана целиком, этот код сюда не подходит
КонецЕсли;
Дубли, которые не дубли
Отсюда же ложные дубли. Если искать коды, которые встречаются больше чем в одном чеке, почти всё найденное окажется продажей по блистерам. На рабочей базе аптеки такой поиск за всё время дал 228 кодов, и все 228 оказались вскрытыми пачками, проданными частями в пределах пачки. Один код сначала выглядел нарушением: три чека с частями одной пачки дали в сумме 1,008. Это снова округлённый коэффициент, с точной долей выходит ровно одна пачка.
Настоящий дубль другой: целая упаковка продана больше одного раза или частей продано больше, чем в пачке.
Уведомление 511
Когда код уже в чеке, выбытие надо отразить в МДЛП уведомлением 511 о розничной продаже. Структуру удобнее брать не из памяти, а из XDTO-пакета ИнтеграцияМДЛП самой конфигурации: в нашей базе это версия схемы 1.38. В уведомлении идентификатор места деятельности (subject_id), дата операции в UTC, по каждому коду sgtin, cost и vat_value, для части упаковки sold_part вида «1/10», и реквизиты чека в sale_docs: doc_type = 1, doc_number и doc_date.
Отдельно про doc_number. В чеке есть номер документа 1С и НомерЧекаККМ. Второй заполняется значением CheckNumber, которое возвращает драйвер кассы, а по стандарту 1С это номер фискального документа («Требования к разработке драйверов подключаемого оборудования», версия 4.7, параметры DocumentOutputParameters). Его я и ставлю в 511.
На базе это видно и по самим номерам. Внутри смены они идут подряд, а между сменами номер прыгает на три: закрытие и открытие смены тоже фискальные документы, и они забирают номера. Номер документа 1С так себя не ведёт, поэтому по данным легко проверить, какой из двух номеров фискальный. Если касса не вернула номер и в чеке стоит заглушка, её в уведомление лучше не брать.
Готовый XML я проверял схемой конфигурации: ФабрикаXDTO.ПрочитатьXML и Проверить() проходят, а код, укороченный на один знак, схема отвергает. Это дешёвая проверка, которая ловит опечатку в коде до отправки.
Как я проверял правки, не трогая рабочую базу
Всё описанное выше я проверял на копии рабочей базы. Сценарии записи удобнее всего гонять внутри транзакции: начать транзакцию, записать коды, перечитать чек из базы, посмотреть регистр долей и отменить транзакцию. После отмены чек возвращается в исходное состояние, и следующий сценарий начинается с тех же данных.
Так удобно проверять то, что на живой базе проверить страшно. Например, чтобы убедиться, что проверка долей не пропустит лишний блистер, я внутри транзакции дописывал в регистр долю 0,9 от другого чека и пытался записать ещё одну девятую. Запись честно отказывала. А чтобы проверить последний блистер пачки, оставлял в регистре ровно восемь девятых, и тогда запись проходила.
Второе правило простое: сравнивать старую и новую версию на одном и том же чеке. Старая версия на чеке с вскрытой пачкой выдавала ту самую ошибку, которую увидел пользователь, слово в слово, а новая записывала коды. Когда ошибку удаётся воспроизвести до исправления, после исправления ей уже веришь.
Что проверять после каждого шага
Найти чек без кода можно одним запросом. Подобрать код по приходам получается в большинстве случаев, если учесть поздние приходы, чужие серии и вскрытые пачки. Но записать код в пробитый чек так, чтобы он там остался, получается только со статусом строки и с проверкой по базе после записи. «Записано без ошибок» здесь ничего не значит.
Найти чеки без кода, поиск кода по документам и дубли можно моими обработками: для «Аптеки» (infostart.ru/1c/reports/2762433) и для типовой «Розницы 2.3» (infostart.ru/1c/tools/2800850). Если нужно восстановить коды в своей базе, подобрать их по приходам и собрать 511, это можно заказать через кнопку «Заказать консультацию».
Вступайте в нашу телеграмм-группу Инфостарт