А в типовых он нормально реализован?
https://geniy1s.ru/osu-ot-chz-opyat-ne-dlya-lyudej/
ОСУ — это объемно-сортовой учет, ЧЗ вводит его как прототип маркировки, в этом случае в УПД передаются не марки, а GTIN-ы, специальные коды товаров.

Странно... В УПД должны быть именно марки. Или я что-то не понимаю?
Или это новая технология?

В том же контур есть плагин контур.маркировки, в нем спец. РС и код который и пихает ГТИН в УПД. Как раз для нетиповых самое то.

(1) да, это новое слово в ЧЗ, ОСУ, только ГТИНы, без марок. Типо упрощение. Но на деле...

(2) и как это поможет клиенту в сабже? Да и любому клиенту оптовой торговли с ассортиментом товаров тысяч в 10, например?

(4) у нас ассорт 100к. На прошлой неделе внедрили плагин. Полет норм

(5) что за плагин? Он для чего? ДЛя обработки интеграции контура с 1С, или непосредственно для работы на сайте в контуре?

(6) https://support.kontur.ru/diadoc-1s8x/47317-plagin_konturmarkirovka_osu?ysclid=mrf7y0l1fv828145783

(3) ОСУ с 2022 года, так что не новое.
Но в целом, ЧЗ на одном месте вертел) ОСУ и марки ЧЗ - это хрень, вот проверка марок ЕАЭС и РФ - хрень собачья. Строишь процессы без крипто-хвоста, а потом приходит марка ЕАЭС, которой нет в ЧЗ без хвоста и пошел нахер.

А если с хвостом отправишь на проверку, то только по 1 марке = 1 запрос (стандартно РФ условно 1000 марок можешь проверить за 1 запрос), отправляешь в ЧЗ, он перенаправляет запрос в Беларусь или Казахстан и там они по полной марке дают огрызок ответа. Че за ПЗДЦ. Раньше думал ЕАЭС со-временем уберут эту залупу, но так и осталось в разделе похеризма

(8)
Вроде как жопа нарисовалась когда добавили проверку ИНН в ЧЗ. Я вот сейчас наступил на грабли.
Через ОСУ полученный товар не проходит проверку (конфа не сильно распостраненная, разаботчик клал на допил ОСУ).
Вот думаю, убрать ИНН прокатит (косметика, РР не вступил еще)?

Причем косметика поэкземплярно норм проходит (владелец марки правильный)

У меня у одного рябит в глазах от засилия буквенных аббревиатур с упором на марки? Пора отдельный словарь заводить для них.

(11) Глоссарий:

1. ЧЗ - Честный знак.
2. ЦРПТ - "центр развития перспективных технологий", в принципе, в контексте маркировки, то-же самое, что и ЧЗ,
3. КМ - код маркировки.
4. КИЗ - код идентрификации. В принципе, чаще всего, в месагах, это то-же самое, что и КМ, но иногда без "криптохвоста", обрезок от КМ.
5. Криптохвост - криптоподпись марки. Живет только в печатной форме, ну и в СУЗ, пока его не напечатали и не нанесли на товар.
6. СУЗ - система управления заказами. В основном для производителей/импортеров, но иногда может использоваться и другими УОТ для маркировки остатков.
7. УОТ - участник оборота товаров.
8. РР - Разрешительный режим.
9. ОИСМ - сервер ЧЗ, для проверки марок. В принципе для проверки марок устарел с появлением РР, но работает, и ни кто проверки марок через него пока не отменял. И на него передаются "уведомления о реализации маркированной продукции" при продаже ее через ККТ, внутри чеков через ОФД.
10. CDN - площадка из разветвленной сети серверов для проверки марок по РР.
11. X-API-Key - токен для ККТ из ЛК ЧЗ. Скоро сдохнет, пока продлен до 01.10.2026.
12. ЛК ЧЗ - личный кабинет УОТ в ЧЗ.
13. токен - строка данных для авторизации в ЧЗ(ну, или в других местах). В зависимости от типа имеет разную длину и срок "жизни".
14. ТСПИоТ - "Техническое средство получения информации о товаре". По сути - вариант работы с РР, но авторизация не по X-API-Key, а по ФН ККТ. И канал связи - шифрованный, тем-же ФН.
15. ФН - фискальный накопитель ККТ.
16. ККТ - контрольно-кассовая техника. По сути, сам кассовый аппарат.
17. ФР - частный случай ККТ, который не самостоятельный, автономный, а работающий под управлением кассовой программы компьютера. По сути - принтер с фискальной частью, который хранит информацтю в ФН и отправляет в ОФД.
18. ОФД - оператор фискальных данных. Коммерческая структура-прослойка между ККТ и ФНС(ну, это я думаю нет смысла отдельно расшифровывать) и ОИСМ.
19. ФФД - формат фискальных данных. Сейчас актуальный - ФФД-1.2
20. КЭП - квалифицированная электронная подпись.
21. ЭЦП - свормированные с использованием КЭП электронная подпись какого-либо документа. Может быть "присоединенной" - как-бы внедренной в тело документа, так и "открепленной", в виде отдельного файла.
22. криптопровайдер - средство для формирования ЭЦП с использованием КЭП. Например КриптоПро, или встроенный в РуТокен криптопровайдер.
23. РуТокен. Аппаратный токен, чаще всего в виде "USB флешки", содержащий контейнер с ключами и сертификатом, составляющими вместе КЭП. В некоторых случаях может содержать в себе так-же встроенную программу-криптопровайдер, для вариантов 2.0/3.0.  

Можно и дальше продолжать, но уже надоело...
Кому интересно - продолжите или уточните, действительно аббревиатур много.

(12) Молодец.Добавлю:
КИТУ -Код идентификации транспортной упаковки.Кодирует состав КМ (КИГУ,другие КИТУ) в упаковке.Для логистики и УПД.
КИГУ -Код идентификации групповой упаковки.Для автоматизации списывания на кассах.

(13) Угу, спасибо...
Простейший пример КИГУ - это блок сигарет.
Может продаваться на ККТ сканированием марки с блока. В ЧЗ автоматически произойдет дезагрегация, и все десять марок пачек содержащихся в блоке будут выведены из оборота.
С КИТУ, такое не прокатит - ШК КИТУ не должны продаваться на ККТ, при попытке проверки его по РР - будет ошибка, что он не найден.

(12) "И вот теперь со всей этой х..ней мы попробуем взлететь..."

(12) Ну, молоток, что сказать.

(12) Люди к тебе потянутся.

(14) Что такое Разрешительный режим?

(18) Разрешительный режим.
Способ проверки маркированной продукции(точнее, конечно не самой продукции, а ее маркировки :-))) ), на CDN площадках сервиса ЧЗ. Когда проверка осуществляется не самим ККТ, в отличии от проверок на сервере ОИСМ, а кассовой программой, HTTPS запросом, и по его результатам принимается решение о возможности продажи этой продукции, в соответствии с алгоритмами и критериями проверки, заложенными в программу, для разных ТГ(товарных групп, вот еще одна аббревиатура :-) ). Соответственно продажа или разрешается, или запрещается. Отсюда и термин "Разрешительный режим".
При разрешении продажи, и пробитии чека ККТ, в него, в специальный тег 1265 передается идентификатор ответа на этот запрос и его время. Видимо для возможного дальнейшего "разбора полетов :-) ", если что-то продалось запрещенное к продаже.

PS Предвидя следующий вопрос - тег 1265 есть только в ФФД-1.2, поэтому для продажи маркированного товара нельзя применять ККТ работающие в старом ФФД-1.05. Там просто некуда передать данные проверки по РР. Хотя, сам ФФД-1.05 ни кто пока не отменял, использовать его можно, если не торгуете маркировкой и еще несколько ограничений там есть, но в принципе, он пока не отменен.

(18) Дополню (19).РР - разрешительный режим - режим продажи товара на кассах в рознице.Необходимость применения РР  регулируется законодательством по каждой ТГ с определенной даты..До наступления РР применятся УР - уведомительный режим.

(1) Нет.Конкретные марки при ОСУ не передаются.
При ОСУ в УПД появляется тэг
<ДопСведТов ПрТовРаб="1" КодТов="00000000001" ГТИН="046XXXXXXXXXXX">
    <НомСредИдентТов КолВедМарк="40"/>
</ДопСведТов>
Т.е.все количество  40 штук по одному ГТИН.

+(12) Блин!!! Как же это я ОСУ пропустил, прямо из заголовка темы!
ОСУ - Объемно-сортовой учет.
По нему марки принадлежат производителю/импортеру, эмитируются и наносятся им при выпуске/иморте продукции, и принадлежат ему до вывода продукции из оборота(продажей через ККТ или любым другим способом, например списанием).
При движении товара от производителя до потребителя, движение марок не прослеживается - только два движения - ввод в оборот* и вывод, сколько бы промежуточных контрагентов/оптовиков/поставщиков ее "в руках не подержали". В УПД передавются только GTIN-ны товаров, по сути их ЕАН ШтрихКоды, дополненные слева "0" до 14 символов. Тоесть, сам идентификатор товара и его количество. Поэтому и ОСУ. Марки в УПД не передаются(хотя, теоретически - могут, тут уже это обсуждали).
Если открыть в ЛК ЧЗ раздел "Марки" по ТГ учитываемой по ОСУ - там будет пусто(если конечно вы не производитель этого товара).
А вот при поэкземплярном учете, в отличии от ОСУ, марки переходят от производителя по цепочке оптовиков, и потом к рознице, по УПД, там есть специальные теги для этого. Пока последняя их не выведет из оборота. И в ЛК они видны, у каждого УОТ, через которого прошел этот товар.

+(22) ввод в оборот*
Ну, на самом деле это не одно движение, а несколько этапов -  заказ кодов, оплата их, получение, нанесение, ввод в оборот.
Но, все это происходит внутри СУЗ и выполняется одним контрагентом, поэтому, утрированно, не вдаваясь в подробности - это одно движение.

А, еще, из одного моего ответа в соседней теме: "ЗАБЛОКИРОВАННЫХ ОГВ КМ".
ОГВ - органы государственной власти.
Для маркировки - РосПотребНадзор, но возможны и варианты...

(19) Вопрос, как сосуществуют режимы проверки через ОИСМ и РР через CDN площадки ?

(25) Не понял вопрос?

Что мешает им "сосуществовать" - ?
Вот так и сосуществуют, независимо друг от друга.
Обычно, сначала идет проверка кассовой программой по РР, формируется по результатам тег 1265(программой! ККТ в этом не принимает участия, данные тега получает от программы в "готовом виде"), потом проверка в ОИСМ, так-же с формированием соответствующих тегов, 2106, если память не изменяет, но это уже  внутреннее дело самого ККТ, мы их сами не формируем, поэтому пох, "не на слуху", это все происходит в микропрограмме(прошивке) ФР и мы этим не рулим(и последующей печати М на чеках, если эта печать не отключена в настройках ККТ). В какой момент(при добавлении в чек со сканера/при закрытии чека) и в каком порядке происходят эти проверки - задается в алгоритмах работы кассовой программы. Наше дело только передать КМ на проверку, и послать соответствующую команду. В конечном итоге, вместе с данными для ФНС в чек(через ОФД) передаются специальные теги, составляющие "уведомление о реализации маркируемой продукции" для сервера ОИСМ и последующей передачи им данных о продаже в общую базу ЦРПТ.
Немного утрировано, но в общем как-то так.

(26) предположим, что товар подлежит разрешительному режиму, к примеру категория Антисептики.

При нажатии кнопки - пробить чек, в 1С запускается проверка средствами софта. Запрос через ТС ПиОТ отправляется в CDN площадку по шифрованному каналу связи и ждет ответ. Если связи нет, то происходит проверка в ЛМ ЧЗ (локальный модуль ЧЗ). Если все ок, формируется тег 1265 и дальше проверка осуществляется средствами ККТ через ОИСМ.

И тут самое интересное, если ОИСМ будет лежать в этот момент (например как Таском на той неделе), то чек не будет пробит и тут нужно как нивелировать эту проверку ?
Если проверка успешна - то чек печатается с отметкой [М+]

(27) Чего это он не будет пробит?
Запрос согласия покупателя, и пробиваете.
Да, с букоффкой М на чеке будет косяк - если сервер не ответил в отведенный таймаут - будет [M], если вернул отрицательный ответ - [M-], и только в случае своевременного и положительного ответа будет [M+]. Но, это вполне допустимо.
Все это не зависимо от РР и ПИоТа, что-бы они там не возвращали.

+(28) Запрос согласия покупателя, и пробиваете.

А вот есть этот запрос и возможность согласиться, уже от возможностей и настроек Вашей кассовой программы зависит. Мне не ведомо, в чем Вы работаете, и даже если напишете, я вряд-ли подскажу что-то. Я с типовыми не работаю, у меня все свое.

(28) Ну к примеру, КМ будет в статусе отличающимся от "В обороте" или ее владельцем будем не мы, на каком этапе проверки мне будет сообщено.

На прошлой неделе столкнулся с тем, что при пробитии бытовой химии мне 1С выдало следующую ошибку (см скриншот), по этому я и пытаюсь понять, каким боком доступность ОИСМ может мне мешать бить чеки.

(30) Не пойму... Или лыжи не едут, или я е******й...
При чет тут документ "Реализация товаров и услуг" со скриншота, и РР вместе с ПИоТ - ???
Это все делается в кассовых чеках...
Или эта такая конфа, где нет кассовых чеков, а все это в этих доках делается? Ну, не знаю... Все может быть. Мне не ведомо, что там разрабы этой конфы начудили...
Что это вообще за конфа?

(31) это ERP.

Из заказа покупателя сначала оформили ПКО на предоплату, а потом в РТУ пробивали второй чек уже с товаром.
Коды маркировки могут подтянуть как с расходного ордера на товары, так же отсканировать напрямую в документ реализации.

Чек печатается из этого документа?
И, что, с таким статусом проверки ОИСМ не дает напечатать чек?

Как все заморочено... Тут не подскажу, все, что я выше писал - относится к общим принципам работы ЧЗ с маркировкой, и ни как не учитывает особенностей конкретных конфигураций 1С.

(33) Да, печатался из этого документа и чек не печатался. Долго выводилось окно - Проверяется разрешительный запрос ГИС МТ, пожалуйста ждите ...
Спустя 5-10 минут выдавало ошибки - Произошла ошибка проверки средствами ККТ по причине - Неверное состояние процесса проверки КМ.

Связал это с недоступностью ОИСМ, к сожалению не догадался вывести чек диагностики, чтоб проверить эту версию.
ОФД - Таском, проблема имела место быть 10.07.2026.

Ну, 10.07.2026 Таском глухо лежал. Ничего удивительного.
Но, по идее, это не должно было приводить к недоступности печати чеков. Как это настроить в конкретной конфе - я не подскажу...
5-10 минут... Это очень долго, 5 секунд еще-бы ладно, хотя в МР оговорено полторы...
Где-нибудь какой-нибудь таймаут не задан? Ищите в настройках.

(36) таймауты в 1с и драйвере АТОЛ на скриншотах.
В 1С вроде все по дефолту, а вот в драйвере АТОЛ не уверен.

В драйвере АТОЛ поставил дефолтные параметры, буду наблюдать.

Выходит цепочка следующая :

Проверки при разрешительном режиме

При пробитии чека с товаром подлежащего РР с помощью ТС ПиОТ отправляется запрос в ЧЗ и проверяется следующие параметры :
Наличие кода в системе
Структура кода и криптохвост.
Статус ввода в оборот.
Право собственности.
Срок годности.
Блокировка со стороны органов власти.
Соответствие цены (для отдельных товарных групп).

Если нет связи с интернетом, то запрос идет в ЛМ ЧЗ и проверяется нет ли запрета.

После проверки РР происходит проверка ОИСМ.
ОИСМ проверяет базовые технические вещи: наличие кода в системе, его структуру и корректность криптохвоста. Именно результат этой аппаратной проверки ККТ передаёт в фискальный документ и выводит в чек: [M+] (всё хорошо), [M-] (проверка провалилась) или [M] (возникла проблема со связью или касса работала в автономном режиме).

(38) Ну, вот, слава богу разобрались :-) Да, именно так все и есть, о чем я неоднократно писал.

Но, дополню немного.
ЧЗ - система "медленная". Продажи туда попадают иногда с задержкой часами, в отдельных случаях только на следующий день. Поэтому, пропустить "повторную продажу у одного продавца в течении менее 30 мин"(есть такое в списке отклонений ЧЗ) как нефик делать.
Поэтому, в продвинутых системах можно дополнительно включить опцию фиксации/проверки повторов продаж в ЛМ.
В таком случае, алгоритм немного меняется - первая проверка, при добавлении марки в чек, проверка в ЛМ.
Если в его базе проданных есть эта марка - то "СТОП", отбой продажи, марку не добавляем без каких-то дальнейших проверок по РР, ОИСМ и т.п...
А вот если ее там нет, то, все как описано. С небольшой добавкой - при закрытии чека(успешном, если все остальные проверки тоже пройдены), специальной командой фиксируем проданные марки в ЛМ, для будущих проверок.
Эта предварительная проверка, при исправной сети и функционирующем ЛМ - времени исполнения много не добавит, так, как происходит локально и на заведомо "шустром" компе.
А база проданных хранится в ЛМ месяц, и постоянно подчищается автоматически, самим ЛМ.
Больше и нет смысла - уж за месяц то попадет продажа в ОнЛайн по любому...

PS Не знаю, есть ли такое в типовых, если есть то в каких и как настраивается. В нормальных системах, реализованных "по уму" - есть.

(39) а можно про УР.

Каким образом проходит проверка в этом режиме ?
Проверяется все тоже самое, но не требуется ответ и возможности реализовать товар ?

(40) Я х.з., как правильно, но как я это себе понимаю, похоже там просто не включается РР вообще, и остается ОИСМ только. Его нельзя отключить, но его результаты "не блокирующие", "с согласия покупателя" продать можно, и "уведомление о реализации маркированного товара" будет отправлено в ОИСМ. Потому и уведомительный.
Я у себя не заморачиваюсь, включаю РР до наступления срока обязательности, по всем используемым ТГ, что-бы потом не забыть... А, что... Он особо то и не мешает, пусть живет.
Вот ОИСМ бы отключить, это да. Все проблемы на кассах обычно от него. Но, нельзя, можно только игнорировать ответы... Но, запрос и "уведомление о реализации" касса делает все равно, со всеми вытекающими :-(

(41) а вот вопрос по ЛМ ЧЗ.
При инициализации я вижу что он скачивает базы :

- минимальные цены
- блокированные GTIN
- блокированные КИЗ

Его задача синхронизировать только эти данные и проверять КМ при недоступности ТС ПиОТ ?

Да.

Опционально - можно в нем вести базу проданных, для контроля дублей. Но, еще раз - это опция, по желанию, обязательных требований нет. Как по мне - очень полезная и удобная опция. Но, это естественно будут тоько вашм продажи, эта база живет сама по себе, и ни с кем не синхронизируется. "Чужие" продажи можно проверить только ОнЛайн.

(43) а каким образом можно эту опцию включить ?

(44) Ну, в API ЛМ есть соответствущие методы.
Вот: URLЛМ + "cis/sell"
Запрос POST, марки передаются в JSON тело запроса.
Как это включить в конкретно Вашей программе, если там такое вообще предусмотрено, вопрос точно не ко мне.

+(45) Как я уже писал, у меня на кассах(фронты) работает сторонняя программа, не от 1С, от совершенно других разработчиков.
Там включается одним параметром в настройках, "Фиксировать продажи - Yes". Но, не я это писал, и как там внутри работает - "для меня черный ящик" :-)
Но, бэк(учетная система) чисто мой, на 7.7.
Там у меня одна из обработок - работа с ЛМ, его настройки, обслуживание, можно из 1С марки в нем проверять при желании. Вот:



Рамкой красной обвел кнопки сохранения/восстановления базы проданных. Ну, сохранение - понятно, просто сохраняет список проданных марок из базы ЛМ в текстовый файл.
А вот восстановление, это по сути то-же самое, что продажа, только не по одной марке, проданной в текущий момент по ККТ, а из текстового файла списком. Все это прекрасно работает.