Взять кассу

[RaFaeL]

Кто знает, с МГМ должна ли работать маркировка? Я на метод write_sales_notice получаю ошибку 12 "не поддерживается в данном режиме" а у строки товара в тестовом кабинете стоит значок "КМ?". Хотелось бы понять, это я накосячил в коде или нужно менять настройки, прошивки и вот это все?

[Игорь Столяров]

МГМ должна ли работать маркировка

Маркировка с МГМ работает однозначно. Но нужно обратить внимание на детали.
1. Драйвер АТОЛ версии 10.9.0.0 и выше;
2. Фискализация МГМ под ФФД 1.2 и поддержкой работы с маркировкой (см. рисунок)
3. Прошивка минимум АТОЛ 5, но если проходит п.2. - то по идее здесь всё OK!
4. И главное - корректное составление комплексного атрибута 1261 - см. логи АТОЛ.

[RaFaeL]

Драйвер 10.9.4.5, галочка маркировки стоит, атрибут 1261 составляется, по крайней мере в логах есть большое значение и затем оно же судя по логам отправляется в base64, и ниже ошибка 12 про "данный режим".... Что хоть за режим то...

[Игорь Столяров]

Что хоть за режим то...

Здесь не нужно пытаться понять буквально ... У АТОЛа своя логика ошибок. Интернет говорит следующее:

Ошибка "Не поддерживается в данном режиме (12)" означают, что в дККТ не указан важный параметр (UIN). Для решения возникшей ошибки необходимо обратиться в компанию - разработчик, для ввода данного параметра в дККТ.

атрибут 1261 составляется, по крайней мере в логах есть большое значение

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

[RaFaeL]

Вы очищали буфер перед формированием комплексного реквизита ?

Буфер очищается при формировании, по крайней мере я формирую комплексный точно так же, как и другие комплексные методом UtilFormTlv в котором очистка идёт первой строкой, ничего своего я тут не придумывал. Ну ладно, буду дальше копать, может что и накопаю

[RaFaeL]

.

[Игорь Столяров]

очистка идёт первой строкой

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

Если Вы говорите о моём форке класса АТОЛ - то в начале метода UtilFormTlv() очищается текстовый
буфер принятия значения комплексного реквизита для записи, а я предыдущем сообщении говорил
об очистке буфера самого комплексного реквизита - см. метод: ResetParams().

И обратите внимание, что

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

[RaFaeL]

Если Вы говорите о моём форке класса АТОЛ - то в начале метода UtilFormTlv() очищается текстовый
буфер принятия значения комплексного реквизита для записи, а я предыдущем сообщении говорил
об очистке буфера самого комплексного реквизита - см. метод: ResetParams().

Он же у вас ни разу нигде не вызывается...

[Игорь Столяров]

Он же у вас ни разу нигде не вызывается

Правильно ! Потому, что комплексные реквизиты формируются в начале чека и запись реквизита очищает буфер.
Я об этом написал в комментариях ...
А с 1261 немного другая история ... И не зря же есть метод libfptr_reset_params() в самом драйвере ?

[RaFaeL]

Что передается проверил по логам, ничего лишнего там нет, только те параметры что нужны
UIN прописан
Ошибка так и осталась

[Игорь Столяров]

Ошибка так и осталась

Ну тогда попробуйте задать вопрос на форуме АТОЛ. Сразу всё расписывайте - они только по сделанному логу будут смотреть.

[RaFaeL]

В общем вроде разобрался
libfptr_write_sales_notice не нужен
Тег 1261 не нужен
Вместо него тег 1260 (аналог 1261 по составу) но на каждую позицию. Этого в классе Игоря не было в принципе, вот и пошёл неверным путём

[Игорь Столяров]

Этого в классе Игоря не было в принципе

Однозначно ! Поэтому я всегда настоятельно рекомендую понять, что Вам нужно сделать,
а не искать упорно победную последовательность нажатия клавиш.

То о чём Вы пишите - это вообще разное и, естественно, реализуется по разному:
Тег 1260 - Отраслевой реквизит предмета расчета;
Тег 1261 - Отраслевой реквизит чека.

Если Вам нужен комплексный тег 1260 - формируете его и передаёте с каждой строкой чека,
что подробно расписано в документации к драйверу, а методы для реализации уже есть в классе.

[SergioRaguzini]

Привет Всем!
Вопрос по передаче маркировки "разливного пива" в общепите для ШТРИХ-М. При продаже разливного пива, при оказании услуг общественного питания в ФР передаётся GTIN, а не марка. Также, коды в виде GTIN не подлежат проверки через ИСМ, поэтому для проверки КМ через ИСМ для GTIN необходимо отключаить передачу данных на сервер ИСМ.
Для АТОЛ, в этом случае, перед вызовом метода beginMarkingCodeValidation необходимо установить свойство LIBFPTR_PARAM_MARKING_NOT_SEND_TO_SERVER в значение TRUE и тогда все работает нормально (чеки уходят и в ОФД и в ЧЗ).

Однако, при работе с ШТРИХ, столкнулся с трудностями - если передаю (вместо полноценной марки) только GTIN (тут это в переменной LOC:mark_Barc), то в ОФД пропадает признак маркированной продукции, а вот при передаче полной марки, признак маркировки появляется (но ведь для общепита нужен только GTIN...). Возможно, это связано с неверной (в моем случае) проверкой КМ, признаюсь, не нашел в интернете похожих тем с примером для ШТРИХ-а

Код: Выделить всё

...
    ?cm_Ole{'FNOperation'}                  ! осуществляет операцию в зависимости от
 DO checkErrors:Shtr                        ! проверить на ошибку
if LOC:CashError = TRUE then BREAK .       ! прерывание по ошибке

! обработка ошибок в этом примере убрана
?cm_Ole{'PaymentItemSign'}    = 31      ! здесь 31 - маркируемый и безакцизный
?cm_Ole{'DivisionalQuantity'} = 0       ! признак реализации 
?cm_Ole{'MeasureUnit'} = 41             ! литр
?cm_Ole{'Password'} = S_O:PasswOper

! проверка КМ:
 ожидаем ответ сервиса проверки КМ:
          LOC:Counter = 1
     LOOP
!-  .  -  .  -  .  -  .  -  .  -  .  -  .  -  .  -  .  -  .  -  .  -  .  -  .  -  .  -  .  -  .  -  .  -  .  -!
         ?cm_Ole{'Password'} = S_O:PasswOper
         ?cm_Ole{'Barcode'}  = CLIP(LOC:mark_Barc)

! для проверки, вначале посылаем на сервер запрос на проверку марки методом FNCheckItemBarcode:
         ?cm_Ole{'TLVDataHEX'}         = ''
         ?cm_Ole{'CheckItemMode'}      = 0
         ?cm_Ole{'FNCheckItemBarcode'}
          sleep(400)                           ! задержка (нужна для завершения отработки команд)

! получаем ответ методом KMServerCheckingStatus:

               LOC:Long_1         = ?cm_Ole{'KMServerCheckingStatus'}
               LOC:CashReturnCode = ?cm_Ole{'ResultCode'}                ! код результата
            if LOC:CashReturnCode
!                   MESSAGE('ошибка:  ' & LOC:CashReturnCode & '  ->  ' & ?cm_Ole{'ResultCodeDescription'})
          end !if

          case LOC:Long_1
            of 15                              ! при успехе будет число 15
                   ok# = 1
          else
                if S_D:mark_Type <> 18 then LOC:ErrorsFound = TRUE .     ! если это не пиво
           end !case

       if LOC:ErrorsFound then BREAK .    ! прервать цикл при ошибке

         ?cm_Ole{'FNAcceptMarkingCode()'}      ! позиция с маркой будет продана

       if ok# = 1 then BREAK .            ! проверка пройдена

          LOC:Counter += 1

       if LOC:Counter > 20 then LOC:ErrorsFound = TRUE ;  BREAK .  ! если 8 сек. нет ответа сервиса, прервать проверку
!-  .  -  .  -  .  -  .  -  .  -  .  -  .  -  .  -  .  -  .  -  .  -  .  -  .  -  .  -  .  -  .  -  .  -  .  -!
      End !Loop


! тег 1260 может быть только один и формируется на стороне ФР, поэтому, просто посылаем теги 1262 1263 1264 1265
! по отдельности каждый через FNSendTagOperation, а не через FNAddTag() как бы было в ином случае:

?cm_Ole{'TagNumber'}   = 1262         ! 1262 - идентификатор федерального органа исп.власти
?cm_Ole{'TagType'}     = 7                  !   тип - "строка"
?cm_Ole{'TagValueStr'} = beerKeg:id_FedOrg  !   значение
?cm_Ole{'FNSendTagOperation()'}             !   добавить тег

?cm_Ole{'TagNumber'}   = 1263         ! 1263 - дата документа основания (передаю как строковая)
?cm_Ole{'TagType'}     = 7                  !   тип - "строка"
?cm_Ole{'TagValueStr'} = beerKeg:doc_Date   !   значение
?cm_Ole{'FNSendTagOperation()'}             !   добавить тег

?cm_Ole{'TagNumber'}   = 1264         ! 1264 - номер документа основания
?cm_Ole{'TagType'}     = 7                  !   тип - "строка"
?cm_Ole{'TagValueStr'} = beerKeg:doc_Num    !   значение
?cm_Ole{'FNSendTagOperation()'}             !   добавить тег

?cm_Ole{'TagNumber'}   = 1265         ! 1265 - значение отраслевого реквизита
?cm_Ole{'TagType'}     = 7                  !   тип - "строка"
?cm_Ole{'TagValueStr'} = beerKeg:value_InPr !   значение
?cm_Ole{'FNSendTagOperation()'}             !   добавить тег

?cm_Ole{'Barcode'}  = CLIP(LOC:mark_Barc)
?cm_Ole{'FNSendItemBarcode'}

Прошу помощи, что делаю не так? Как правильно, в этом случае, отключить передачу данных на сервер ИСМ при проверке КМ через ИСМ для GTIN ?

Спасибо

p.s. в ШТРИХ-ах, оказывается, тег 1260 передается не так, как описано в документации (перерыв интерент - нашел решение - выше к в коде привделено как это успешно работает)

[finsoftrz]

На всякий случай. С 01.04.2024 начинает действовать разрешительный режим продаж на кассах. Пока касается табачных и разливного пива. В сети методички есть. Если кратко, то для этих категорий товаров надо в кассовом ПО выполнить проверку набора реквизитов марки в ЧЗ через http запрос. В определенных случаях запретить продажу. При успешном прохождении проверки передать в ккм набор реквизитов (несколько тегов), включая id запроса на проверку и временной штамп этого запроса.