При проверке маркировки (ОИСМ) выдает ошибку D3 на Штрихе : Маркировка

А м+ - это не, 15?

может всё-таки с построчными проверками, а не продажами?
(или - "суть не в терминах, а в сути вопроса" (с) Т.О. ?)

М+ - это просто М+ как факт. Это не = 15...

Ок. Отвечу, хотя уже устал, каждую тему уносят в сторону...

1) Весной, когда еще не внедрил РР, запускал ОИСМ,
везде ОК (15).

2) Один клиент сообщил, что на части сигарет нет М+

3) Привезли образец

4) Проверил, ответ ОИСМ некорректный, М+ в чеке нет (не помню М- или что-то другое)

5) В это время внедрял РР

6) Убедился что РР на этом образце, ответ корректный

7) В программе стал передавать ответ от РР командой в ФР.

8) После этого и на этом образце появился М+

9) Перестал вообще вызывать и анализировать проверку ОИСМ отдельной командой

10) Если проверка РР не проходит, товар в чек не попадает

11) В чеках с весны везде М+

Проблем нет, вопросов по этой теме нет....


Все довольны...

Опять 25...

Нет проверки РР построчные, продажи в конце, задержки 2-3 минуты в часы пик...

Причину ищу на форуме уже несколько месяцев, к кого есть задержки, у кого нет,
у кого Штрих, у кого Атол, в целом никто не жаются...

У меня остальные мелкие тоже не жалуются...

Буду переходить на продажи после сканирования, уже писал,
ну это весь набор команд по позиции, ежу понятно...

Не отвлекайте, плиз....

Каждый раз все одно и тоже...

Ну в принципе, с весны так и ничего до сих пор и не поменялось.. И понимания так до сих пор не пришло сути процессов (кроме того, что терминология всё-таки важна)...
Ибо:
мда.. необыкновенный случай

как же тяжело с копипастами :)
марка из методички по рр

{"code":0,"description":"ok","codes":[{"cis":"0104670540176099215<pGKy\u001D93dGVz","valid":true,"printView":"0104670540176099215<pGKy","gtin":"04670540176099","groupIds":[8],"verified":true,"found":true,"realizable":true,"utilised":true,"isBlocked":false,"expireDate":"2022-12-22T12:16:00.000Z","productionDate":"2021-04-11T00:00:00.000Z","isOwner":true,"errorCode":0,"isTracking":false,"sold":false,"packageType":"UNIT","producerInn":"7725344604","grayZone":false}],"reqId":"9345c5c5-8591-4c36-a246-ccb5c36385bc","reqTimestamp":1731336378396}

и тот же ответ если только жтин (что используется при осу)

{"code":0,"description":"ok","codes":[{"cis":"04670540176099","valid":false,"verified":false,"message":"cannot parse code. StringIndexOutOfBoundsException: Range [14, 21) out of bounds for length 14","found":false,"realizable":false,"utilised":false,"isBlocked":false,"errorCode":1}],"reqId":"94bde640-4f2b-4cef-b364-608d83df9c0f","reqTimestamp":1731336437157}

и если здесь нет разницы то мне сложно что либо добавить ...

Да, с весны ничего особо не поменялось... По факту.


Вот ОСУ, как описано в теории, и как работает на практике,
две разные вещи, на практике каждая маркировка на контроле в ЧЗ,
продана, не продана, срок годности и т.д.

И РР работает корректно...

Вот и все...

В простоте истина.

Возможно там давно уже все переиграли, и просто, не требуется
документальных подтверждений перемещений...

Я уже писал в предыдущих темах, что и КЛАССНО!

Все проще, так и нужно делать...

Производитель известен, продавец известен, второй раз не продашь...

Зачем лишний документооборот фиксировать, это все-таки не крепкий алкоголь...

А вот у меня не такой ответ, как вы привели, что по воде, что молочке,
абсолютно стандартный,
а ведь мне говорят что молочка и вода, пиво это ОСУ

Может у вас ответ из методички, а не и из реального запроса?

Грубо говоря, и мягко выражаясь, я алгоритмы проверки ответа РР не менял,
и у меня все проходит корректно, и срок реализации (годности) на молочке
на месте по сей день...