Взять кассу
Правила форума
При написании вопроса или обсуждении проблемы, не забывайте указывать версию Clarion который Вы используете.
А так же пользуйтесь спец. тегами при вставке исходников!!!
При написании вопроса или обсуждении проблемы, не забывайте указывать версию Clarion который Вы используете.
А так же пользуйтесь спец. тегами при вставке исходников!!!
- RaFaeL
- ✯ Ветеран ✯
- Сообщения: 1397
- Зарегистрирован: 24 Март 2009, 17:59
- Откуда: НН
- Благодарил (а): 9 раз
- Поблагодарили: 2 раза
- Контактная информация:
Взять кассу
Кто знает, с МГМ должна ли работать маркировка? Я на метод write_sales_notice получаю ошибку 12 "не поддерживается в данном режиме" а у строки товара в тестовом кабинете стоит значок "КМ?". Хотелось бы понять, это я накосячил в коде или нужно менять настройки, прошивки и вот это все?
- Игорь Столяров
- Ветеран движения
- Сообщения: 7691
- Зарегистрирован: 07 Июль 2005, 10:19
- Откуда: г. Ростов-на-ДоМу
- Благодарил (а): 26 раз
- Поблагодарили: 69 раз
Взять кассу
Маркировка с МГМ работает однозначно. Но нужно обратить внимание на детали.
1. Драйвер АТОЛ версии 10.9.0.0 и выше;
2. Фискализация МГМ под ФФД 1.2 и поддержкой работы с маркировкой (см. рисунок)
3. Прошивка минимум АТОЛ 5, но если проходит п.2. - то по идее здесь всё OK!
4. И главное - корректное составление комплексного атрибута 1261 - см. логи АТОЛ.
Make Clarion Great Again !
- RaFaeL
- ✯ Ветеран ✯
- Сообщения: 1397
- Зарегистрирован: 24 Март 2009, 17:59
- Откуда: НН
- Благодарил (а): 9 раз
- Поблагодарили: 2 раза
- Контактная информация:
Взять кассу
Драйвер 10.9.4.5, галочка маркировки стоит, атрибут 1261 составляется, по крайней мере в логах есть большое значение и затем оно же судя по логам отправляется в base64, и ниже ошибка 12 про "данный режим".... Что хоть за режим то...
- Игорь Столяров
- Ветеран движения
- Сообщения: 7691
- Зарегистрирован: 07 Июль 2005, 10:19
- Откуда: г. Ростов-на-ДоМу
- Благодарил (а): 26 раз
- Поблагодарили: 69 раз
Взять кассу
Здесь не нужно пытаться понять буквально ... У АТОЛа своя логика ошибок. Интернет говорит следующее:
Ошибка "Не поддерживается в данном режиме (12)" означают, что в дККТ не указан важный параметр (UIN). Для решения возникшей ошибки необходимо обратиться в компанию - разработчик, для ввода данного параметра в дККТ.
Я бы проверил, что там составляется ... потому, что очень может быть что команда не может распарсить реквизит.
Вы очищали буфер перед формированием комплексного реквизита ?
Make Clarion Great Again !
- RaFaeL
- ✯ Ветеран ✯
- Сообщения: 1397
- Зарегистрирован: 24 Март 2009, 17:59
- Откуда: НН
- Благодарил (а): 9 раз
- Поблагодарили: 2 раза
- Контактная информация:
Взять кассу
Буфер очищается при формировании, по крайней мере я формирую комплексный точно так же, как и другие комплексные методом UtilFormTlv в котором очистка идёт первой строкой, ничего своего я тут не придумывал. Ну ладно, буду дальше копать, может что и накопаюИгорь Столяров писал(а): ↑28 Сентябрь 2023, 10:28 Вы очищали буфер перед формированием комплексного реквизита ?
- Игорь Столяров
- Ветеран движения
- Сообщения: 7691
- Зарегистрирован: 07 Июль 2005, 10:19
- Откуда: г. Ростов-на-ДоМу
- Благодарил (а): 26 раз
- Поблагодарили: 69 раз
Взять кассу
Здесь может быть как в старой сказке, где в одной деревне всех звали Буратино ...
Если Вы говорите о моём форке класса АТОЛ - то в начале метода UtilFormTlv() очищается текстовый
буфер принятия значения комплексного реквизита для записи, а я предыдущем сообщении говорил
об очистке буфера самого комплексного реквизита - см. метод: ResetParams().
И обратите внимание, что
libfptr_write_sales_notice() необходимо вызывать после регистрации всех позиций в чеке, причём среди позиций обязательно должны быть позиции с КМ.
Make Clarion Great Again !
- RaFaeL
- ✯ Ветеран ✯
- Сообщения: 1397
- Зарегистрирован: 24 Март 2009, 17:59
- Откуда: НН
- Благодарил (а): 9 раз
- Поблагодарили: 2 раза
- Контактная информация:
Взять кассу
Он же у вас ни разу нигде не вызывается...Игорь Столяров писал(а): ↑28 Сентябрь 2023, 11:54 Если Вы говорите о моём форке класса АТОЛ - то в начале метода UtilFormTlv() очищается текстовый
буфер принятия значения комплексного реквизита для записи, а я предыдущем сообщении говорил
об очистке буфера самого комплексного реквизита - см. метод: ResetParams().
- Игорь Столяров
- Ветеран движения
- Сообщения: 7691
- Зарегистрирован: 07 Июль 2005, 10:19
- Откуда: г. Ростов-на-ДоМу
- Благодарил (а): 26 раз
- Поблагодарили: 69 раз
Взять кассу
Правильно ! Потому, что комплексные реквизиты формируются в начале чека и запись реквизита очищает буфер.
Я об этом написал в комментариях ...
А с 1261 немного другая история ... И не зря же есть метод libfptr_reset_params() в самом драйвере ?
Make Clarion Great Again !
- RaFaeL
- ✯ Ветеран ✯
- Сообщения: 1397
- Зарегистрирован: 24 Март 2009, 17:59
- Откуда: НН
- Благодарил (а): 9 раз
- Поблагодарили: 2 раза
- Контактная информация:
Взять кассу
Что передается проверил по логам, ничего лишнего там нет, только те параметры что нужны
UIN прописан
Ошибка так и осталась
UIN прописан
Ошибка так и осталась
- Игорь Столяров
- Ветеран движения
- Сообщения: 7691
- Зарегистрирован: 07 Июль 2005, 10:19
- Откуда: г. Ростов-на-ДоМу
- Благодарил (а): 26 раз
- Поблагодарили: 69 раз
Взять кассу
Ну тогда попробуйте задать вопрос на форуме АТОЛ. Сразу всё расписывайте - они только по сделанному логу будут смотреть.
Make Clarion Great Again !
- RaFaeL
- ✯ Ветеран ✯
- Сообщения: 1397
- Зарегистрирован: 24 Март 2009, 17:59
- Откуда: НН
- Благодарил (а): 9 раз
- Поблагодарили: 2 раза
- Контактная информация:
Взять кассу
В общем вроде разобрался
libfptr_write_sales_notice не нужен
Тег 1261 не нужен
Вместо него тег 1260 (аналог 1261 по составу) но на каждую позицию. Этого в классе Игоря не было в принципе, вот и пошёл неверным путём
libfptr_write_sales_notice не нужен
Тег 1261 не нужен
Вместо него тег 1260 (аналог 1261 по составу) но на каждую позицию. Этого в классе Игоря не было в принципе, вот и пошёл неверным путём
- Игорь Столяров
- Ветеран движения
- Сообщения: 7691
- Зарегистрирован: 07 Июль 2005, 10:19
- Откуда: г. Ростов-на-ДоМу
- Благодарил (а): 26 раз
- Поблагодарили: 69 раз
Взять кассу
Однозначно ! Поэтому я всегда настоятельно рекомендую понять, что Вам нужно сделать,
а не искать упорно победную последовательность нажатия клавиш.
То о чём Вы пишите - это вообще разное и, естественно, реализуется по разному:
Тег 1260 - Отраслевой реквизит предмета расчета;
Тег 1261 - Отраслевой реквизит чека.
Если Вам нужен комплексный тег 1260 - формируете его и передаёте с каждой строкой чека,
что подробно расписано в документации к драйверу, а методы для реализации уже есть в классе.
Make Clarion Great Again !
- SergioRaguzini
- Старожил
- Сообщения: 243
- Зарегистрирован: 08 Декабрь 2009, 19:16
- Откуда: Краснодарский край
- Благодарил (а): 9 раз
Взять кассу
Привет Всем!
Вопрос по передаче маркировки "разливного пива" в общепите для ШТРИХ-М. При продаже разливного пива, при оказании услуг общественного питания в ФР передаётся GTIN, а не марка. Также, коды в виде GTIN не подлежат проверки через ИСМ, поэтому для проверки КМ через ИСМ для GTIN необходимо отключаить передачу данных на сервер ИСМ.
Для АТОЛ, в этом случае, перед вызовом метода beginMarkingCodeValidation необходимо установить свойство LIBFPTR_PARAM_MARKING_NOT_SEND_TO_SERVER в значение TRUE и тогда все работает нормально (чеки уходят и в ОФД и в ЧЗ).
Однако, при работе с ШТРИХ, столкнулся с трудностями - если передаю (вместо полноценной марки) только GTIN (тут это в переменной LOC:mark_Barc), то в ОФД пропадает признак маркированной продукции, а вот при передаче полной марки, признак маркировки появляется (но ведь для общепита нужен только GTIN...). Возможно, это связано с неверной (в моем случае) проверкой КМ, признаюсь, не нашел в интернете похожих тем с примером для ШТРИХ-а
Прошу помощи, что делаю не так? Как правильно, в этом случае, отключить передачу данных на сервер ИСМ при проверке КМ через ИСМ для GTIN ?
Спасибо
p.s. в ШТРИХ-ах, оказывается, тег 1260 передается не так, как описано в документации (перерыв интерент - нашел решение - выше к в коде привделено как это успешно работает)
Вопрос по передаче маркировки "разливного пива" в общепите для ШТРИХ-М. При продаже разливного пива, при оказании услуг общественного питания в ФР передаётся 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'}
Спасибо
p.s. в ШТРИХ-ах, оказывается, тег 1260 передается не так, как описано в документации (перерыв интерент - нашел решение - выше к в коде привделено как это успешно работает)
- finsoftrz
- ✯ Ветеран ✯
- Сообщения: 4898
- Зарегистрирован: 06 Ноябрь 2014, 12:48
- Благодарил (а): 10 раз
- Поблагодарили: 43 раза
Взять кассу
На всякий случай. С 01.04.2024 начинает действовать разрешительный режим продаж на кассах. Пока касается табачных и разливного пива. В сети методички есть. Если кратко, то для этих категорий товаров надо в кассовом ПО выполнить проверку набора реквизитов марки в ЧЗ через http запрос. В определенных случаях запретить продажу. При успешном прохождении проверки передать в ккм набор реквизитов (несколько тегов), включая id запроса на проверку и временной штамп этого запроса.
C6/C11, ШВС, tps/btrieve.