Почему необходимость ввода кода маркировки не годится для аудита продаж маркированного товара

Задача

Аптека продаёт маркированные лекарства. Вопрос, который рано или поздно задаёт собственник или проверяющий: где маркируемый товар ушёл из кассы без кода маркировки? И второй, следом: не ушёл ли один и тот же код в двух чеках?

Вопрос звучит просто, но штатными средствами не решается — и не потому, что разработчики что-то забыли, а потому что все типовые механизмы устроены вокруг другого вопроса.

Что умеет типовая конфигурация

Разбор по выгрузке «1С:Розница 8. Аптека», ред. 3.0 (3.0.13.357) — 368 отчётов и 376 обработок, из них по теме маркировки 15 и 29. Четыре ближайших к задаче:

Общее у всех: они отвечают на вопрос «что стало с кодами, которые мы уже пробили». Документ ЧекККМ в источниках данных отраслевого отчёта о расхождениях не участвует вообще, а ПроверкаДокументовИСМП смотрит по одному документу и требует живого доступа к ГИС МТ.

Вопрос «где кода не было изначально» не закрыт ничем.

Ловушка: реквизит, название которого обещает не то

Первое, что приходит в голову при взгляде на метаданные документа, — реквизит табличной части ЧекККМ.Запасы.НеобходимостьВводаКодаМаркировки. Название читается как «этот товар требует кода маркировки». Логика напрашивается: берём строки, где НеобходимостьВводаКодаМаркировки = Истина, а код не введён, — вот и ответ.

Так делать нельзя. Смотрим, откуда реквизит берёт значение (Documents\ЧекККМ\Ext\ObjectModule.bsl, типовой модуль):

НоваяСтрока.НеобходимостьВводаКодаМаркировки =
    ДанныеШтрихкода.СтруктураДанныеНоменклатуры.НеобходимостьВводаКодаМаркировки;

Значение приходит из разбора штрихкода в момент подбора строки. Это не свойство номенклатуры и не признак «товар подлежит маркировке» — это снимок того, что вернул разбор ШК при добавлении позиции в чек. Дальше по модулю от него пляшут проверки заполнения:

ИЛИ (НоваяСтрока.НеобходимостьВводаКодаМаркировки И НЕ ЗначениеЗаполнено(НоваяСтрока.КодМаркировки))

Остальные места использования того же реквизита — ПродажиРМК, ИнтерфейсРМКСлужебныйКлиент, ОбщегоНазначенияРМККлиентСервер, РМКФормаВыдачиПодарка. Все до одного относятся к рабочему месту кассира, то есть к процессу пробития чека.

Отсюда следствие: строка, попавшая в чек не через сканирование ШК — подбор из справочника, копирование чека, загрузка, обмен — остаётся с Ложь, хотя товар маркируемый. Реквизит честно выполняет свою работу (подсказать кассиру на кассе), но для аудита задним числом он непригоден: аудит, построенный на нём, молча пропустит именно те строки, ради которых затевался.

На реальных данных аптеки такие строки есть: маркируемый товар, код не введён, флаг не выставлен.

Чем заменить

Признак «товар маркируется» надо брать не из документа, а из номенклатуры:

Номенклатура.КатегорияНоменклатуры.ор_УчетМаркируемыхТоваров

Это флажок в карточке категории номенклатуры, вкладка «Маркировка и ФГИС», раздел «Маркировка ИС МДЛП» → «Маркируемая лекарственная продукция». Он описывает товар, а не обстоятельства его попадания в чек, и потому не зависит от того, как кассир добавил строку.

Признак «код не введён» — отсутствие строки в отраслевой табличной части:

И НЕ З.ор_ИдентификаторСтроки В
    (ВЫБРАТЬ
        У.ИдентификаторСтроки
    ИЗ
        Документ.ЧекККМ.ор_НомераУпаковок КАК У
    ГДЕ
        У.Ссылка = З.Ссылка
        И У.НомерКИЗ <> "")

Связь строки товара со строкой кода — по ор_ИдентификаторСтроки в пределах одного документа, не по номеру строки. Номер строки для этого не годится: он меняется при редактировании чека.

Ещё одна мелочь, на которой легко ошибиться в отчётности: количество в Запасы.Количество хранится в единице продажи. Реальное количество —

З.Количество * ЕСТЬNULL(ВЫРАЗИТЬ(З.ЕдиницаИзмерения КАК Справочник.ЕдиницыИзмерения).Коэффициент, 1)

Что делает приложенная обработка

Внешняя обработка, конфигурацию не меняет, к внешним сервисам не обращается — работает только по данным базы. Три вкладки:

1. Чеки без кода маркировки — чеки за период, где маркируемый товар продан без

кода, по одной строке на чек с числом проблемных позиций в нём: чек с одной незаполненной строкой и чек, где кода нет нигде, — случаи разной тяжести. Двойной клик открывает чек.

2. Поиск по коду — в каких чеках встречается СГТИН или его фрагмент; ищет по

НомерКИЗ, ПолныйКодМаркировки и штрихкоду строки, показывает итог по количеству.

3. Дубли кодов — коды, встречающиеся более чем в одном чеке за период. Двойной

клик переносит код на вкладку поиска.

Интерфейс строится программно, в модуле формы 400+ строк, всё в трёх запросах — разобрать и переделать под свои метаданные несложно.

Границы применимости

Обработка написана под конфигурации семейства «1С:Розница», где продажи оформляются документом ЧекККМ, а коды маркировки лежат в отраслевой табличной части ор_НомераУпаковок (отраслевые решения на базе Розницы от «1С-Рарус»).

Проверено на: «1С:Розница 8. Аптека», ред. 3.0, релиз 3.0.13.357, платформа 8.5.1.1302.

В конфигурации без этих объектов обработка не падает: при открытии она проверяет метаданные и выводит список того, чего не хватает, — чтобы было видно, что именно адаптировать. Проверено на «1С:Бухгалтерия предприятия» 3.0, где документа ЧекККМ нет вовсе: форма открывается и объясняет причину.

Для Розницы 2.3 / 3.0 без отраслевых реквизитов нужна адаптация трёх запросов (ЗаполнитьБезКода, ЗаполнитьНайденное, ЗаполнитьДубли в модуле формы) под хранение кодов маркировки в этих конфигурациях.

Зачем это может понадобиться

С введением разрешительного режима (ТС ПИоТ) касса сама блокирует продажу маркированного товара без проверки кода, и на новых релизах дыра закрывается сама собой. Актуальным остаётся аудит исторических данных: посмотреть, что происходило в чеках за прошлые периоды, до перехода. Ответственность за продажу без проверки кода маркировки — ст. 15.12.1 КоАП РФ, до 100 000 руб.; для организации, так что вопрос обычно возникает не из любопытства.