Класс для API АТОЛ «Драйвер ККТ версии 10»

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

Привет всем !

Класс работы с драйвером ККТ АТОЛ 10 на основе JSON заданий.
(форк класса ADMIN'а 2019 г.)

Класс рабочий, в комплекте примеры использования. Любые замечания и дополнения - приветствуются.
В FTP разделе форума создана папка: /_Books/Atol.KKT со всей сопутствующей документацией.

ВНИМАНИЕ !
Для работы с КМ (кодами маркировки) через JSON задания требуется прошивка ККТ 5.12 и выше (двухлетней давности).
На старых прошивках будет ошибка: Объекту 0x05C1E828 присвоен код ошибки 148 [Ошибка программирования реквизита 1023]

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

Меня смутило то, что в MODULE применяется константа:

Стоп ! Всё верно, но здесь надо разделить две большие разницы.

1. Указание в виде константы имени DLL файла в котором находятся загружаемые функции: Module('fptr10.dll')
2. И из какого физического файла они собственно будут загружены: ATOL_LoadLibrary(CString 'C:\Program Files …\fptr10.dll')

Можно сделать классическую привязку функций fptr10.dll через LIB файл (в т.ч. с указанием его местоположения в MODULE),
но тогда программа без этого DLL вообще не запустится …

И кстати есть ещё один нюанс. Драйвер ДККТ 10 достаточно сырой и судя по всему ещё долго будет дорабатываться.
Появляются новые методы и константы. Поэтому нужно контролировать при загрузке наличие функций в DLL и выдавать
пользователю сообщение о необходимости обновить версию драйвера АТОЛ ДККТ 10 при отсутствии используемых
прикладной программой методов в загружаемой DLL драйвера … ну или загрузить из DLL функцию получения версии драйвера,
подключится и проверить версию, а потом уже загружать все остальные методы из этой DLL ...

[SergioRaguzini]

Игорь, Спасибо!
Извиняюсь за глупый вопрос (всегда особо не заморачивался с MODULE), но если можно, то прошу пояснить п.2:

из какого физического файла они собственно будут загружены: ATOL_LoadLibrary(CString 'C:\Program Files …\fptr10.dll')

в каком месте программы что необходимо добавить, чтобы это заработало

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

в каком месте программы что необходимо добавить, чтобы это заработало

Это же я умничаю по чужому коду … В оригинальном примере Админа усё есть.
Имя файла в ПЕРЕМЕННОЙ (не константе !) Dll_Name и Вы можете присвоить ей значение по настройке и т.д.:

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

Atol10.Construct           PROCEDURE
Dll_Name                   CSTRING('fptr10.dll')
  CODE
  IF NOT SELF.DllHandle
    SELF.DllHandle = ATOL_LoadLibrary(Dll_Name)
  ...

Я использую вот такую версию загрузки методов из DLL:

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

Atol10.Init        Procedure  !,LONG,PROC
Dll_Name1  CSTRING('fptr10.dll')
Dll_Name2  CSTRING('C:\Program Files\ATOL\Drivers10\KKT\bin\fptr10.dll')
Dll_Name3  CSTRING('C:\Program Files (x86)\ATOL\Drivers10\KKT\bin\fptr10.dll')
  Code

  If Not Self.DllHandle

     ! --- Загрузка библиотеки ATOL

     Self.DllHandle = ATOL_LoadLibrary(Dll_Name1)
     If ~Self.DllHandle and Exists(Dll_Name2) then Self.DllHandle = ATOL_LoadLibrary(Dll_Name2).
     If ~Self.DllHandle and Exists(Dll_Name3) then Self.DllHandle = ATOL_LoadLibrary(Dll_Name3).

     If Self.DllHandle
...

[SergioRaguzini]

Игорь, Спасибо!
Когда не было необходимости, вроде бы все в MODULE устраивало - а тут оказался неучем

[SergioRaguzini]

И кстати есть ещё один нюанс. Драйвер ДККТ 10 достаточно сырой и судя по всему ещё долго будет дорабатываться.

Да, хотелось бы, например, явная "сырость" - одна из заявленных, но не работающих(!) функций OLE уже вызывает вопросы...

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

но не работающих(!) функций OLE уже вызывает вопросы

Вопрос философский … Дело в том, что интерфейс OLE (ActivX) сам по себе является рудиментом и более не развивается.
Действительно, OLE удобно для интеграции, но медленно и проблемно. Что-то там постоянно грузится и переклинивает.
Запуск OLE драйвера под терминальным сервером - это высший пилотаж системного администрирования.
Чего только стоит зависимость разделителей дробной части в цифрах от региональных настроек Windows !

А АТОЛ смотрит в светлое будущее, где каждый предприниматель будет печатать чеки с гаджета …

[Admin]

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

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

Игорь Столяров, твое сообщение было?

Да. Там оказалось всё несколько сложнее, чем подсказывала здравая логика.
Если кратко, то: libfptr_reset_params - очищает ВСЕ установленные реквизиты.

Суть напряга с комплексными реквизитами в следующем.
На момент выполнения метода формирования комплексного реквизита libfptr_util_form_tlv() неизвестно
какой именно реквизит мы формируем, т.е. из скольких полей он состоит … поэтому в буфер пишутся ВСЕ
определённые на момент выполнения libfptr_util_form_tlv() параметры.

НЕЛЬЗЯ ВЫПОЛНЯТЬ ЗАПИСЬ КОМПЛЕКСНОГО АТРИБУТА, КОГДА ОПРЕДЕЛЕНЫ ПАРАМЕТРЫ В НЕГО НЕ ВХОДЯЩИЕ !!!

Обратите внимание, как формировался комплексный реквизит ранее в ДТО8 - были операторные скобки
BeginComplexAttribute() / WriteAttribute() в которые "заворачивались" нужные параметры для комплексного атрибута.

В ДККТ 10 "упростили", т.е. комплексный атрибут должен формироваться ВСЕГДА в начале (когда нет списка параметров),
а libfptr_util_form_tlv() - очищает список параметров при записи .... Отсюда и запись через буфер в примерах …

В этом случае libfptr_reset_params() по сути ничего не меняет. Всё равно, что после открытия процедуры выполнить
Clear() для очистки и так чистых данных. А принудительно очищать список параметров можно только когда они все
записаны … но при записи список и так очищается. Поэтому и удалил пост.

[Admin]

Ага. Понятно. Я примерно так и предполагал т.к. примере нигде эта процедура не использована.

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

т.к. примере нигде эта процедура не использована

Метод libfptr_reset_params() на самом деле полезный и нужный.
В справке показана идея, реальная жизнь намного интересней.

Если мы формируем чек или его содержание по условиям, то он позволяет реализовать технологию
принудительного возврата в точку ZERRO. Как в анекдоте: "а давайте все выйдем и снова зайдём" …

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

Извиняюсь, а можно спросить: кто-нибудь использует драйвер АТОЛ ДККТ10 под Windows x64 ?

Проблема в следующем.
- Если ставим драйвер АТОЛ ДККТ10 x64 на Windows x64 - DLL не проходит загрузку.
- Если ставим драйвер АТОЛ ДККТ10 x32 на Windows x64 - всё прекрасно работает.

Так и должно быть или я чего-то не понимаю ?
Заранее спасибо.

[Admin]

Windows x64

Вы научились компилировать на Clarion x64 приложения?
p.s. Ничего нового не увидел. Все так и должно быть. Если мы про загрузку драйвера из Clarion

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

Вы научились компилировать на Clarion x64 приложения?

Понял. Спасибо. Пошёл учить сисадминов.

[SergioRaguzini]

Привет Всем!

Столкнулся с необходимостью прочитать содержимое денежных регистров за смену (в ДТО-8 это так называлось). Из новой документации видимо это стало называться "Счетчики итогов операций".
Для реализации метода fnQueryData пришлось чуть расширить базовый функционал Админа (еще раз, хочу выразить ему благодарность за эту большую работу), для чего добавил используя аналогию с query_data (хотя, м.б. это не верно?) следующее:

в файл atol.inc :

! Счетчики итогов операций:
LIBFPTR_FNDT_TOTALS EQUATE
LIBFPTR_PARAM_FN_COUNTERS_TYPE EQUATE
LIBFPTR_FNCT_SHIFT EQUATE
LIBFPTR_PARAM_RECEIPTS_COUNT EQUATE
LIBFPTR_PARAM_PAYMENTS_SUM_CASH EQUATE

в файл procedure_eq.clw:
_libfptr_fn_query_data_ LONG,STATIC,NAME('libfptr_fn_query_data')
cstr_libfptr_fn_query_data CSTRING('libfptr_fn_query_data')

в файл load_procedures.clw:

_libfptr_fn_query_data_ = ATOL_GetProcAddress(SELF.DllHandle, cstr_libfptr_fn_query_data) ! 27/11/19
IF NOT _libfptr_fn_query_data_
SELF.FlagLoaded = FALSE
BREAK
END

в локальных процедурах:

Atol10.fnQueryData PROCEDURE()!,LONG,PROC ! Счетчики итогов операций 27/11/19

CODE

IF ~ SELF.FlagLoaded THEN RETURN LIBFPTR_ERROR END
RETURN libfptr_fn_query_data(SELF.fptr)


!. . . . . к о н е ц п р о ц е д у р ы . . . . . .!


Пытаюсь получить результат:


ATOL.SetParamInt(LIBFPTR_PARAM_FN_DATA_TYPE , LIBFPTR_FNDT_TOTALS)
ATOL.SetParamInt(LIBFPTR_PARAM_RECEIPT_TYPE , LIBFPTR_RT_SELL) ! по чекам прихода
ATOL.SetParamInt(LIBFPTR_PARAM_FN_COUNTERS_TYPE, LIBFPTR_FNCT_SHIFT) ! сменные счетчики

ATOL.fnQueryData()


LOC:uint_Receipts = ATOL.GetParamInt(LIBFPTR_PARAM_RECEIPTS_COUNT)
LOC:cashSum = ATOL.GetParamDouble(LIBFPTR_PARAM_PAYMENTS_SUM_CASH)


MESSAGE('Общее количество чеков (включая коррекции): ' & LOC:uint_Receipts & |
'|Сумма наличных оплат чеков прихода: ' & LOC:cashSum)


Компилируется все без ошибок но результаты по нулям (хотя чеки прихода пробивал)...

Тестирую на АТОЛ-11Ф, но видимо, либо я где-то здесь допустил ошибку, а может быть эта функция пока еще в ДТО-10 глючит...
Некоторые функции, например Гудок, Чтение и запись данных в ККТ (раньше это были "Таблицы") и т.д. все работает нормально, а вот тут не работает...
Если кто-то сталкивался, прошу совета

Спасибо

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

Если кому интересно, оставлю здесь ссылку на вебинар по планам АТОЛ на ФФД 1.1 и новый формат работы с маркировкой в 2020 г..
https://www.youtube.com/watch?v=6PknFMF ... e=youtu.be