Жалоба, с которой всё началось
Розничная точка с табаком. «Управление торговлей» 11.5, кассир работает в РМК, всё как у всех.
Задача от клиента звучала так: «У нас включено “Учитывать МРЦ”, а цена из марки не подставляется. Почините».
Я открыл настройки. Галка стоит. Открыл подсказку под ней — там написано что-то про МРЦ. Сканирую марку на стенде — в строку чека падает цена из документа установки цен, та самая, старая. МРЦ, напечатанная на боку пачки в двух сантиметрах от кода, программу не интересует.
Ну ладно, думаю. Функция есть, работает криво, найду где и поправлю.
Через неделю у меня было девять версий расширения, пять зелёных прогонов тестов и очень недовольный клиент. Потому что чинить было нечего: этой функции в УТ нет вообще. Совсем. И галка тут ни при чём.
Дальше по порядку, потому что порядок в этой истории — самое интересное.
Галка, которая никого не обманывала
Первым делом я пошёл читать подсказку под флажком. Дословно, из НСтр:
«При проверке поступления табачной продукции или при сканировании табачных кодов маркировки МРЦ будет распознаваться из состава кода маркировки или запрашиваться из сервиса ГИС МТ. МРЦ может использоваться при ведении классификаторов номенклатуры или для контроля цены при оформлении розничных продаж.»
Прочитайте её ещё раз медленно. Я вот прочитал быстро — и услышал ровно то, что хотел услышать: «МРЦ распознаётся из кода, значит будет в чеке».
А там написано другое. Распознаваться — да. Для контроля цены — да. Слова «подставляться» нет. Его никто и не обещал.
Подсказка честная. Обманул себя я сам, и, судя по форумам, не только я — жалоба «галка стоит, а цена не та» гуляет по темам про табак годами.
Но одно дело — вычитать это в тексте на форме. Другое — понять, что типовая делает вместо подстановки. Полез в конфигурацию.
В Рознице — подстановка, в УТ — контроль
Вот это место я показываю всем, кто спорит.
Открываем «Розницу» 2.3, общий модуль ШтрихкодированиеРМК, строка 95:
Если ОбщегоНазначенияРМККлиентСервер.ЕстьСвойство(СоставКодаМаркировки, "МРЦСтрокой")
И ЗначениеЗаполнено(СоставКодаМаркировки.МРЦСтрокой)
И ПараметрыШтрихкодирования.УчитыватьМРЦ
И ЗначениеЗаполнено(СоставКодаМаркировки.МРЦ) Тогда
СтрокаТовары.МРЦ = СоставКодаМаркировки.МРЦ;
СвойстваДляОбновленияВСтроке.Добавить("МРЦ");
Если НЕ СоставКодаМаркировки.МРЦ = 0 Тогда
СтрокаТовары.Цена = СоставКодаМаркировки.МРЦ;
ЦенаПродажи = СоставКодаМаркировки.МРЦ;
СвойстваДляОбновленияВСтроке.Добавить("Цена");
КонецЕсли;
КонецЕсли;
СтрокаТовары.Цена = СоставКодаМаркировки.МРЦ. Вот она, та самая подстановка, под тем самым флагом УчитыватьМРЦ. В Рознице всё работает ровно так, как человек ожидает.
Теперь открываем УТ 11.5 и ищем то же самое.
Я искал по всей конфигурации — по всем модулям выгрузки, а не наугад. Присвоение цены из МРЦ в УТ одно, и оно не присвоение. Общий модуль ШтрихкодированиеМОТП:
МаксимальнаяЦена = СтрокаКодаМаркировки.МРЦ;
Если МаксимальнаяЦена = 0 Тогда
СоставКодаМаркировки = СтрокаКодаМаркировки.ДанныеРазбора.СоставКодаМаркировки;
Если СоставКодаМаркировки <> Неопределено
И СоставКодаМаркировки.Свойство("ВключаетМРЦ")
И СоставКодаМаркировки.ВключаетМРЦ Тогда
МаксимальнаяЦена = СоставКодаМаркировки.МРЦ;
КонецЕсли;
КонецЕсли;
Если МаксимальнаяЦена < МинимальнаяЦена Тогда
СтрокаКодаМаркировки.ТекстОшибки = НСтр("ru='МРЦ меньше минимальной розничной цены Р'");
КонецЕсли;
Максимальная розничная цена достаётся из марки и сравнивается с минимальной. Всё. Если МРЦ ниже МинРЦ — ругнётся. Цена в строке чека при этом не шевелится.
Одна библиотека, один флаг, один текст подсказки — и два совершенно разных потребителя. В Рознице подстановка цены, в УТ контроль цены. Ровно так, как в подсказке и написано, если читать её не как хочется, а как есть.
Тогда где в УТ вообще живёт МРЦ
Раз не в чеке, то где-то же должна.
В УТ штатная модель МРЦ — серии номенклатуры. Есть реквизит ВидыНоменклатуры.ИспользоватьМРЦМОТПСерии, есть СерииНоменклатуры.МаксимальнаяРозничнаяЦенаМОТП. Логика такая: пачки с разной МРЦ — это разные серии одного товара, у каждой серии своя цена, и дальше всё работает штатным механизмом цен.
Что интересно, конфигурация эту модель защищает. В ИнтеграцияИСМППереопределяемый есть процедура ПриОпределенииВозможностиВключенияОтключенияВеденияУчетаМРЦ, и в УТ у неё вот такое тело (через ИнтеграцияИСМПУТ):
Запрос.Текст =
"ВЫБРАТЬ
| ВидыНоменклатуры.Ссылка
|ИЗ
| Справочник.ВидыНоменклатуры КАК ВидыНоменклатуры
|ГДЕ
| ВидыНоменклатуры.ИспользоватьМРЦМОТПСерии
| И ВидыНоменклатуры.ИспользоватьСерии";
ВидыНоменклатуры = Запрос.Выполнить().Выгрузить().ВыгрузитьКолонку("Ссылка");
Если ВидыНоменклатуры.Количество() Тогда
ВозможноОтключение = Ложь;
...
ПричинаНевозможностиОтключения = Новый ФорматированнаяСтрока(ДанныеФорматированнойСтроки);
КонецЕсли;
То есть: если в базе есть виды номенклатуры, которые ведут МРЦ в сериях, — галку запрещено выключать, и на форме покажут, из-за кого именно.
А в Рознице та же процедура выглядит так:
Процедура ПриОпределенииВозможностиВключенияОтключенияВеденияУчетаМРЦ(ВозможноВключение,
ПричинаНевозможностиВключения, ВозможноОтключение, ПричинаНевозможностиОтключения) Экспорт
Возврат;
КонецПроцедуры
Пустая. Рознице нечего защищать, у неё МРЦ живёт в цене строки, а не в сериях.
Возвращаюсь к базе клиента, делаю два запроса. Видов номенклатуры с МРЦ в сериях — ноль. Серий с заполненной МРЦ — ноль.
Вот и весь ответ на вопрос «почему не работает». Галка включена, механизм, который она обслуживает, не заведён, а механизма, которого от неё ждут, в УТ нет в принципе.
Клиенту такое объяснять неприятно, но честно. Дальше начиналась собственно работа: сделать то, чего в конфигурации нет.
Я поставил хук на самое очевидное место
Дальше рассуждение, которое кажется железным. Сканирование штрихкодов в УТ проходит через ШтрихкодированиеНоменклатурыСервер.ОбработатьШтрихкоды(Форма, Объект, СтруктураПараметров, КэшированныеЗначения). Процедура экспортная, лежит в общем модуле, на входе форма, объект и всё, что нужно для заполнения строк. В Рознице подстановка цены сидит недалеко от аналогичного места. Значит, ставим &После на неё, ловим строки с марками, подменяем цену.
Собрал расширение. Развернул. Отсканировал марку.
Ничего.
Проверил, что расширение подключено. Подключено. Проверил, что процедура вызывается вообще, — поставил запись в лог прямо первой строкой обработчика. Тишина. Отсканировал обычный товар без маркировки — лог есть. Отсканировал марку — лога нет.
Вот в этот момент до меня начало доходить, что маркированный товар в РМК идёт вообще другой дорогой.
Куда на самом деле уходит скан марки
РМК в УТ — это не обработка. Отдельного объекта «РМК» в конфигурации нет: касса — это форма документа, Документ.ЧекККМ.Форма.ФормаДокументаРМК. Восемь с половиной тысяч строк в одном модуле. Приятного мало, но лезть надо туда.
Начало пути — обработчик завершения поиска по штрихкоду:
Процедура ПоискПоШтрихкодуЗавершение(ДанныеШтрихкода, ДополнительныеПараметры) Экспорт
РозничныеПродажиКлиент.РазблокироватьФорму(ЭтотОбъект);
Если ДанныеШтрихкода = Неопределено Тогда
Возврат;
КонецЕсли;
ДополнительныеПараметры = Новый Структура;
ДополнительныеПараметры.Вставить("СтандартнаяОбработка", Истина);
ДополнительныеПараметры.Вставить("ДанныеШтрихкода", ДанныеШтрихкода);
ДополнительныеПараметры.Вставить("КэшированныеЗначения", КэшированныеЗначения);
ДополнительныеПараметры.Вставить("ТребуетсяСерверныйВызов", Ложь);
СобытияФормКлиент.ПриИзмененииЭлемента(ЭтотОбъект, "ТоварыПоискПоШтрихкоду", ДополнительныеПараметры);
Если ДополнительныеПараметры.ТребуетсяСерверныйВызов Тогда
ПоискПоШтрихкодуЗавершениеНаСервере(ДополнительныеПараметры);
СобытияФормКлиент.ПриИзмененииЭлемента(ЭтотОбъект, "ЗавершитьОбработкуШтрихкода", ДополнительныеПараметры);
КонецЕсли;
Если ДополнительныеПараметры.СтандартнаяОбработка Тогда
ДанныеШтрихкодов = Новый Массив;
ДанныеШтрихкодов.Добавить(ДанныеШтрихкода);
ОбработатьШтрихкоды(ДанныеШтрихкодов);
КонецЕсли;
Смотрите, что здесь происходит. Форма создаёт структуру с двумя ключевыми флагами и отдаёт её подписчикам через СобытияФормКлиент. А подписчик — это СобытияФормИСКлиентПереопределяемый, и вот что он делает с нашими флагами:
ИначеЕсли Элемент = "ТоварыПоискПоШтрихкоду" Тогда
Если Форма.ИспользоватьАкцизныеМарки
И ДополнительныеПараметры.ДанныеШтрихкода <> Неопределено Тогда
ДополнительныеПараметры.ТребуетсяСерверныйВызов = Истина;
ДополнительныеПараметры.Вставить("ПараметрыСканирования", ШтрихкодированиеОбщегоНазначенияИСКлиент.ПараметрыСканирования(Форма));
ШтрихкодированиеОбщегоНазначенияИСКлиентСервер.ЗакодироватьШтрихкодДанныхBase64(ДополнительныеПараметры.ДанныеШтрихкода);
ДополнительныеПараметры.СтандартнаяОбработка = Ложь;
КонецЕсли;
Обратите внимание на условие. Там не «товар маркированный» — там Форма.ИспользоватьАкцизныеМарки. То есть если в базе включён учёт акцизных марок, стандартная обработка вырубается для любого скана в этой форме, а маркированный товар от обычного отделится позже, уже на сервере.
И вся ветка Если ДополнительныеПараметры.СтандартнаяОбработка — та, в которой и живёт ОбработатьШтрихкоды, — просто не выполняется.
Дальше управление уходит на сервер, там разбирается код маркировки, и на выходе получается развилка в функции ПослеОбработкиШтрихкодов (привожу сокращённо, там ещё полсотни строк заполнения структур действий):
Если РезультатОбработкиШтрихкода.ТребуетсяОбработкаШтрихкода Тогда
// ... сборка СтруктураДействийСДобавленнымиСтроками:
// ЗаполнитьЦенуПродажи / ЗаполнитьУсловияРозничныхПродаж / ЗаполнитьСтавкуНДС ...
ОбработатьШтрихкодыСервер(ДанныеДляОбработки, КэшированныеЗначения);
Иначе
ОбработатьДобавлениеСтрокСоВскрытымиПотребительскимиУпаковкамиЛокализация(
РезультатОбработкиШтрихкода.ДобавленныеСтроки,
РезультатОбработкиШтрихкода.ИзмененныеСтроки);
ОбработатьСтрокиТЧ(
РезультатОбработкиШтрихкода.ДобавленныеСтроки,
РезультатОбработкиШтрихкода.ИзмененныеСтроки,
КэшированныеЗначения);
КонецЕсли;
А ОбработатьШтрихкодыСервер — это обёртка в одну строку:
Процедура ОбработатьШтрихкодыСервер(СтруктураПараметровДействия,КэшированныеЗначения)
ШтрихкодированиеНоменклатурыСервер.ОбработатьШтрихкоды(ЭтотОбъект,Объект,СтруктураПараметровДействия,КэшированныеЗначения);
КонецПроцедуры
Вот и всё. Для маркированного товара берётся ветка Иначе, и ОбработатьШтрихкоды не вызывается вовсе. Хук стоял на процедуре, до которой марка не доезжает.
Мне на этот вывод потребовалось несколько версий расширения и один скриншот кассы от клиента. А проверяется он, как выяснилось, за минуту.
Проверка в три строки
Если у вас та же симптоматика — не гадайте, а перехватите событие сами. В харнессе на копии базы, с открытой формой РМК:
ДопПараметры = Новый Структура("СтандартнаяОбработка, ДанныеШтрихкода, КэшированныеЗначения, ТребуетсяСерверныйВызов",
Истина, ДанныеШтрихкода, Неопределено, Ложь);
СобытияФормКлиент.ПриИзмененииЭлемента(ФормаРМК, "ТоварыПоискПоШтрихкоду", ДопПараметры);
Сообщить("СтандартнаяОбработка = " + ДопПараметры.СтандартнаяОбработка);
Подсунули обычный штрихкод — увидели Истина. Подсунули код маркировки — увидели Ложь. Значит, дальше по коду форма пойдёт мимо ОбработатьШтрихкоды, и ставить туда что-либо бессмысленно.
Три строки против недели догадок. Обидно, но полезно.
Три точки, в которые можно встать
Когда стало понятно, куда идёт марка, точки нашлись сами. Их три, и все — процедуры общих модулей, то есть годятся под &После без всяких фокусов:
1. ШтрихкодированиеИСМП.ЗаполнениеСохраняемойСтрокиШтрихкодовУпаковки — сюда приходит строка марки вместе с данными разбора. Здесь же в ПараметрыСканирования лежит СсылкаНаОбъект — ссылка на документ, из которого пришло сканирование. По ней отсекаются чужие документы: расширение не должно лезть в поступления и возвраты.
2. ЧекККМЛокализация.ОбработатьИзмененнуюСтроку — принимает форму целиком и конкретную строку товаров:
Процедура ОбработатьИзмененнуюСтроку(Форма, СтрокаТЧТовары, ПараметрыЗаполнения, Количество,
ЭтоМаркируемаяПродукция = Истина) Экспорт
Здесь под рукой форма целиком: и табличные части объекта, и реквизит формы ДанныеШтрихкодовУпаковокГосИС — типовая ищет марки именно в нём, а не в Объект.АкцизныеМарки. Это единственное удобное место, чтобы разложить строки по разной МРЦ.
3. ПакетнаяОбработкаТабличнойЧастиСервер.ОбработатьСтрокиТЧ — сюда строки приезжают уже с ценой, проставленной из документа установки цен. Значит, подменять цену надо здесь, иначе типовая аккуратно затрёт то, что вы поставили раньше.
Связь между ними — собственный модуль расширения с ReturnValuesReuse = DuringRequest. Кэш живёт ровно один серверный вызов, и этого достаточно: все три шага происходят внутри одного вызова. Никаких регистров, никаких временных хранилищ — посчитали на первом шаге, забрали на третьем.
Отдельно скажу, чего я делать не стал. Расширение формы РМК — соблазнительно, там всё под рукой. Но платформа при заимствовании формы требует overlay всей структуры формы целиком (PropertyState → Form плюс Ext/Form.xml), а форма РМК живёт и меняется от релиза к релизу. Первое же обновление конфигурации — и вы чините форму, а не задачу. Свойства Module у формы в XML, кстати, не существует: попытка положить туда только модуль даёт «Свойство Module не входит в состав объекта метаданных Form». Проверено лбом.
Две пачки одного вида — и одна цена на обе
Расширение заработало. Клиент попробовал и вернулся: если пробить две пачки с разной МРЦ, обе получают одну цену.
Смотрю, как типовая ищет строку под марку. Функция ИнтеграцияИС.ПоляПоискаМаркируемойПродукции:
Функция ПоляПоискаМаркируемойПродукции(ЕстьСерии = Истина, ЕстьGTIN = Ложь,
СпецификаМаркировкаМолочнойПродукции = Ложь) Экспорт
Результат = Новый Структура;
Результат.Вставить("Номенклатура", ОбщегоНазначенияИС.ПустоеЗначениеОпределяемогоТипа("Номенклатура"));
Результат.Вставить("Характеристика", ОбщегоНазначенияИС.ПустоеЗначениеОпределяемогоТипа("ХарактеристикаНоменклатуры"));
Если ЕстьСерии Тогда
Результат.Вставить("Серия", ОбщегоНазначенияИС.ПустоеЗначениеОпределяемогоТипа("СерияНоменклатуры"));
КонецЕсли;
...
Номенклатура, характеристика, серия. Цены среди полей поиска нет. Две пачки одного вида без серий — это для типовой одна и та же строка, количество 2. И цена, естественно, одна.
Причём в конфигурации есть ровно тот флаг, который эту проблему решает:
Функция ТребуетсяПоискТоваровПриРаспределенииСУчетомЦены(СтрокаШтрихкод, ПараметрыСканирования)
Возврат ОбщегоНазначенияИСКлиентСервер.ЭтоПродукцияМОТП(СтрокаШтрихкод.ВидПродукции)
И ЗначениеЗаполнено(СтрокаШтрихкод.МРЦ)
И (СтрокаШтрихкод.ВидУпаковки = Перечисления.ВидыУпаковокИС.Групповая
Или СтрокаШтрихкод.ВидУпаковки = Перечисления.ВидыУпаковокИС.Потребительская)
И ПараметрыСканирования.ИспользуетсяРаспределениеКодовПоТоварамСУчетомМРЦ;
КонецФункции
Красиво же. «Требуется поиск товаров при распределении с учётом цены» — прямо про нашу беду.
Я поискал, где этот флаг ставится в Истина. По всей конфигурации у него два вхождения: объявление в конструкторе параметров сканирования со значением Ложь — и чтение вот в этой функции. И всё. Пользовательской настройки к нему нет, программно его никто не поднимает.
Механизм заложен, провода протянуты, выключателя не поставили.
Добавить «Цену» в поля поиска через &После нельзя: обработчик &После на функцию не подменяет её результат — вернётся типовая структура, ваша уйдёт в никуда. Проверено экспериментом, и это отдельная маленькая боль. А &Вместо на эту функцию я ставить не рискнул: она общая для всех документов маркировки, и сломать ей сопоставление в поступлениях ради кассы — плохая сделка.
Пришлось делать своими руками: считать цены по всем маркам чека, раскладывать количество по строкам и закреплять цену за конкретной строкой. И вот тут ждала мелочь, стоившая отдельной версии:
ЧекККМ.Товары.ИдентификаторСтроки — это строка(36). Не число. UUID. Типовая его так и заполняет, в том же СобытияФормИСКлиентПереопределяемый:
Если ПустаяСтрока(СтрокаТЧ.ИдентификаторСтроки) И СтрокаТЧ.МаркируемаяПродукция = 1 Тогда
СтрокаТЧ.ИдентификаторСтроки = Строка(Новый УникальныйИдентификатор);
Я честно ожидал число, получил строку, и пара часов ушла на «почему у меня не находится строка, которую я только что положил».
А ведь типовая умеет делить блок на пачки
Ещё одна находка, которую я чуть не пропустил.
Когда сканируется блок, цена пачки — это МРЦ блока, делённая на вложенность. Вложенность лежит в справочнике ШтрихкодыУпаковокТоваров, в реквизите КоличествоПотребительскихУпаковок, — обращаться в ГИС МТ для этого не нужно. Я эту арифметику написал сам.
А потом наткнулся на ШтрихкодированиеМОТП.РасчетМРЦПоСтрокамДерева:
Если РодительСтроки.ВидУпаковки = Перечисления.ВидыУпаковокИС.Групповая
И СтрокаДерева.ВидУпаковки = Перечисления.ВидыУпаковокИС.Потребительская Тогда
СтрокаДерева.МРЦ = РодительСтроки.МРЦ / РодительСтроки.КоличествоПотребительскихУпаковок;
КонецЕсли;
Та же формула, слово в слово. Типовая умеет.
Но пользы от этого ноль, и вот почему.
Во-первых, результат ложится в колонку МРЦ строки дерева упаковок — временной структуры на время обработки. Ни в документе ЧекККМ, ни в справочнике ШтрихкодыУпаковокТоваров нет ни одного реквизита с «МРЦ» в имени. Посчитали — и выбросили. Единственное место, где МРЦ в УТ хранится по-настоящему, — те самые серии.
Во-вторых, весь этот расчёт заперт вот за таким условием:
Процедура ЗапросИРасчетМРЦПоСтрокамДерева(ЗапрашиваемыеСтроки, ВычисляемыеСтроки, ПараметрыСканирования) Экспорт
...
Если Не ОбщегоНазначенияИСМПКлиентСервер.ЗначениеПараметраСканированияЗапрашиватьДанныеСервисаИСМП(
ПараметрыСканирования) Тогда
Возврат;
КонецЕсли;
Этот Возврат выкидывает и расчёт от родителя тоже. Хотя ему сервис не нужен вообще: это деление числа на число по данным, которые уже лежат в базе. Локальная арифметика заперта за флагом «ходить в ГИС МТ».
Заодно это объясняет, почему на стенде без доступа к сервису я эту ветку в глаза не видел.
Границы
Всё, что я показал, — из выгрузки «Управления торговлей» 11.5.22.182 и «Розницы» 2.3.25.23. Имена процедур и модулей вы найдёте и у себя, но номера строк и точный состав параметров от релиза к релизу плывут — проверяйте по своей конфигурации, а не по моим цитатам.
Про ERP ничего не скажу: не смотрел. Библиотека ИС МП там та же, потребители могут быть свои.
Флажок «Учитывать МРЦ» виден на форме, только если включён учёт табачной продукции, а переопределяемый метод про запрет отключения вызывается только в расширенной версии ГосИС. Так что «у меня и галки такой нет» — тоже нормальный сценарий.
И главное, что стоит сказать вслух. Стенд у меня был без оборудования: копия базы, файловый режим, ни сканера, ни ККТ, ни доступа к ГИС МТ. Логику и данные такой стенд проверяет прекрасно. Цепочку «сканер → касса» — не проверяет никак. Пять версий подряд у меня были зелёные тесты и неработающая касса у клиента, и это ровно потому, что тест дёргал мои процедуры напрямую, а не шёл дорогой, которой идёт реальный скан. Про это я напишу отдельно, там разговор длиннее.
Осадок
Задача, которая звучала как «почините галку», оказалась задачей про то, что галка не про это.
Больше всего цепляет вот что. Вся информация лежала в открытом виде и ждала, пока я догадаюсь посмотреть. Подсказка на форме честно говорила «для контроля цены». Функция в ШтрихкодированиеМОТП честно сравнивала МРЦ с минимальной ценой и ничего не присваивала. Развилка в форме РМК честно уводила маркированный товар в другую ветку. Ничего не было спрятано — я просто неделю чинил не то, потому что решил, что знаю, как оно устроено.
С тех пор, когда механизм «есть, но не работает», первым делом иду не в отладчик, а в поиск по конфигурации: где вообще упоминается то, что я собрался чинить. Если единственное упоминание — сравнение, а не присвоение, то чинить нечего, надо писать.
А клиенту в итоге пришлось объяснять так: функции нет, галка отвечает за другое, делаем расширение. Формулировка, которую никто не любит слышать, — поэтому к ней теперь прилагается скриншот с поиском по конфигурации и ровно одним найденным вхождением.
Если сталкивались с этой же историей в ERP или в свежих релизах УТ — напишите, что там с этой развилкой. У меня подозрение, что она живёт и здравствует, и хук на ОбработатьШтрихкоды не работает не только у меня.
Вступайте в нашу телеграмм-группу Инфостарт