ATOL драйвер 10.x

[finsoftrz]

Кажется, я понял, в чем дело. Но проверить смогу только в понедельник.

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

Можете сами погуглить, если есть желание.

Ну если хорошо погуглить, то как говорится, можно и вакцину от короновируса купить.
Я просто могу сказать абсолютно точно: 10-ти и 12-ти значные ИНН прекрасно записываются в тег и передаются.
Никогда они ничем не дополнялись … Может там речь идёт о какой-то конкретной прошивке или модели КММ …

Ниже же есть мой пример чека из программы Админа - там и ИНН, и наименование покупателя.
Кажется проблема, та же, что и в прошлый раз … ?

[finsoftrz]

Если лень гуглить, ссылки ниже. Если у Вас прекрасно передаются, то это значит, что прошивка сама преобразует в нужный вид. У меня под ИНН объявлена строка с запасом на 20 символов вместо 12. Потом идут преобразования в utf8 и, как я понял, в драйвер и прошивку уходят все 20 символов, включая конечные пробелы. Прошивка видит, что длина превышена, тупо выдает ошибку и аннулирует чек. Это мое предположение, в понедельник проверю. Других вариантов не вижу.

http://forum.atol.ru/index.php?showtopic=37873

http://www.consultant.ru/cons/cgi/onlin ... b0ji2dgcoj

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

Прошивка видит, что длина превышена

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

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

Atol10.SetParamStr         PROCEDURE(LONG lParam, STRING sText)
R                          CStr
  CODE
  IF ~SELF.FlagLoaded THEN RETURN END
  R.Set(CLIP(sText))   ! ВОТ ЗДЕСЬ ХВОСТ ПРОБЕЛОВ БУДЕТ ОТРЕЗАН
  R.ASCIIToUnicode
  libfptr_set_param_str(SELF.fptr, lParam, ADDRESS(R.CStr()))

P/S: Можно я не буду читать интернет ? Я сам там часто много чего пишу …

[finsoftrz]

Таки да, у меня этот класс взят за образец, и clip() в аналогичном месте не стоит. Я понадеялся, видимо, что это дальше в классе работы с cstring учитывается. Класс чужой, у себя я на автомате подобные вещи учитываю в конечной точке преобразований, вот и сработал рефлекс.

Интернет можно не читать, но если плотно работаешь с кассами, базовые правила надо все же знать. Мне тоже лениво всякую чепуху читать от наших законодателей и их последователей. Пока что-то не потребуется конкретно.

[RaFaeL]

У меня под ИНН объявлена строка с запасом на 20 символов вместо 12. Потом идут преобразования в utf8

Цифры в UTF-8 можно не перекодировать, они так и останутся цифрами с той же длиной строки

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

Цифры в UTF-8 можно не перекодировать

Это да, цифра - она и в Африке цифра.
Но, как говорил Админ: самое сложное было подобрать, чего туда записывать …
В классе АТОЛ 10 используется не UTF-8, а расширение до Unicode ...

[finsoftrz]

В общем, подтвердилось насчет длины строки в инн.

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

В общем, подтвердилось насчет длины строки в инн.

И решилось путём возвращения Clip() в метод Atol10.SetParamStr() ?

[finsoftrz]

И это тоже.

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

Я заранее извиняюсь, но я всё-таки спрошу …
Только у меня метод открытия свойств окна драйвера:

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

     If MyAtol.OpenDialog() = LIBFPTR_ERROR.

работает через попу ? Причём с каждым обновлением драйвера ситуация ухудшается.
Окно открывается около минуты, при этом прикладную программу переклинивает намертво.
Это жутко бесит юзеров, а они - меня. Может быть это я что-то не то делаю ?

[SergioRaguzini]

Привет Всем!
Сталкивался ли кто уже с маркировкой обуви для АТОЛ ДТО-10?

Из интернета нашел:

MarkingType – равно 5408 для обуви
2. GTIN – равно 14-ти знаком после первых символов 01
3. SerialNumber – 13 символов после значения 21 (т.е. начиная с 19)

Из того что прочитал из разных источником, кажется что видимо такое уже не актуально на сегодняшний день при работе через ДТО-10...

Судя по документации по ДТО-10 10.7.0.0 вроде как и тег 5408 передавать уже не надо...

Обувная марка ведь длинная, например:
010290000078733921%lRRHWM+"1mlj918029920GEgJiDhTthbw8VtvhOSaSMtn1A7KHKrVPMSo503W5mCjopv75VR9H4RG33M68brXZxYmj6MCwpHNShPyImpVg==


Взяв за основу приведенную выше дискуссию в этой теме Вячеслава и Игоря, пытаюсь понять - достаточно ли будет просто передать обувную марку (и вроде теперь сам драйвер поймет от чего эта марка от обуви или сигарет,духов и т.д.):

SELF.SetParamInt(LIBFPTR_PARAM_MARKING_CODE_TYPE, LIBFPTR_MCT_OTHER)
SELF.SetParamByteArray(LIBFPTR_PARAM_MARKING_CODE,clip(SELF.AtolStrToByte('010290000078733921%lRRHWM+"1mlj918029920GEgJiDhTthbw8VtvhOSaSMtn1A7KHKrVPMSo503W5mCjopv75VR9H4RG33M68brXZxYmj6MCwpHNShPyImpVg==')))
if libfptr_registration(SELF.fptr) = LIBFPTR_ERROR
SELF.GetError
end

Прошу прокомментировать (м.б. есть какой-то нюанс), и если не затруднит поделиться несколькими строчками примера кода

Спасибо

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

(м.б. есть какой-то нюанс)

Нюанс действительно есть.
Если посмотреть описание формата строки с кодом маркировки GS1 (Yandex покажи !) - то в нём поля переменной длины должны
завершаться символом Chr(29), которые в Вашем примере отсутствует (например для поля после "21") … потому что его сожрал сканер.

[SergioRaguzini]

Привет Всем!

"Обувное" направление для меня редкость, поэтому прошу извинить за тугодумие:

Нюанс действительно есть.
Если посмотреть описание формата строки с кодом маркировки GS1 (Yandex покажи !) - то в нём поля переменной длины должны
завершаться символом Chr(29), которые в Вашем примере отсутствует (например для поля после "21") … потому что его сожрал сканер.

Игорь, спасибо за совет!
Но что смущает - судя по инф-и найденной через поиск Yandex и приведенной на
https://infostart.ru/journal/news/uchet ... i_1209448/

и имеющемуся там изображению (картинка, не текст) примера формирования кода

есть непонятные моменты

я решил проверить разрядность и здесь привожу, уже разобранный по-символьно пример этой марки, сдвинув разряды чтобы удобнее было посчитать кол-во символов,
вижу противоречие(!), там на сайте написано, что исходя из спецификации GS в штриховой код DataMatrix включается:

<FNC1> + 01 + GTIN (14 знаков) + 21 + серийный номер (13 знаков) + <GS> + 91 + ключ проверки (14 знаков) + <GS> + 92 + криптоподпись (88 знаков)

но после 91, на картинке, ключ проверки явно не "14 знаков", а только 4

похоже, что на сайте https://infostart.ru/journal/news/uchet ... i_1209448/
опечатка !!! - ключ проверки 4-знака !!! а не 14-ть как у них написано (блин,столько времени потерял пока не увидел в на другом сайте)

далее, вроде бы все понятно - для наглядности, можно значение сканированной обувной марки поместить в LOC:str_Scan и сформировать LOC:Mark для дальнейшего использования в качестве содержимого кода маркировки в чеке

LOC:str_Scan = '010290000078733921%lRRHWM+"1mlj918029920GEgJiDhTthbw8VtvhOSaSMtn1A7KHKrVPMSo503W5mCjopv75VR9H4RG33M68brXZxYmj6MCwpHNShPyImpVg=='

(правда, видимо, пример имеющегося у меня сканированного обувного кода, был сформирован без лидирующего признака FNC1)

! в первый SUB включаем 31 символ с учетом '01' и '21'
! во второй SUB включаем 31 символ с учетом '91'
! в третий SUB включаем 90 символов с учетом '92'
LOC:Mark = SUB(LOC:str_Scan, 1, 31) & CHR(29) & SUB(LOC:str_Scan, 32, 6) & CHR(29) & SUB(LOC:str_Scan, 38, 90)


тут идут ранее разные аттрибуты чека (название, кол-во и т.п.), а потом собственно код маркировки

SELF.SetParamInt(LIBFPTR_PARAM_MARKING_CODE_TYPE, LIBFPTR_MCT_OTHER)
SELF.SetParamByteArray(LIBFPTR_PARAM_MARKING_CODE, CLIP(SELF.AtolStrToByte(LOC:Mark)))
if libfptr_registration(SELF.fptr) = LIBFPTR_ERROR
SELF.GetError
end

Прошу прокомментировать - это правильный вариант передачи маркировки обуви?


Спасибо

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

но после 91, на картинке, ключ проверки явно не "14 знаков", а только 4

Зачем Вы тратите своё время на чтение кто чего написал на заборе ?
Посмотрите первоисточник: https://честныйзнак.рф/business/projects/footwear/marking_code/