Для формирование формирования вида чеков, задания фискальных атрибутов и прочих параметров используется динамический код. Чтобы использовать динамический код для формирования вида чека, в В конфигурацию плагина прописывается следующий (или любой другой подходящий) нужный класс:
| Блок кода | ||||
|---|---|---|---|---|
| ||||
# динамический класс для формирования вида чека checkbuilder=ru.bitel.bgbilling.cashcheck.SimpleCheck |
Есть возможность задать отдельный класс для отдельного ККТ или для отдельного маппинга по типу. Это может потребоваться для теста нового шаблона. Или для удобства, если фискализаторы совсем разные (например, локальный и онлайн-служба) - вместо проверки по ККТ внутри шаблона просто используются разные шаблоны.
| Блок кода | ||||
|---|---|---|---|---|
| ||||
# динамический класс для отдельного ККТ
fr.1.checkbuilder=ru.bitel.bgbilling.cashcheck.CheckKKT1
# динамический класс для отдельного типа платежа
pt.666.checkbuilder=ru.bitel.bgbilling.cashcheck.CheckTestType666 |
В таком случае порядок выбора класса следующий: ищется для маппинга, потом для ККТ, потом общий. Про случай настройки для маппинга есть оговорка: не работает для возвратов (в данный момент там нет маппинга), при ручном чеке проверяется что все платежи в чеке (если их несколько - например при распределении или просто при печати кучи платежей одного договора в один чек) нашли один и тот же настроенный дин.код.
Несколько примеров реализации класса идёт в комплекте с плагином. Подразумевается, что какой-либо класс обязательно должен быть найден и должен сработать. О работе с динамическим кодом можно прочитать в соответствующем разделе справки. Внутри можно проверить любые условия и сформировать чек любой формы для каждой позиции/платежа, добавляемой в чек. Класс должен расширять абстрактный класс ru.bitel.bgbilling.cashcheck.CheckMaker.
...
| Примечание |
|---|
Обратите особое внимание, что в каждом скрипте формирования внешнего вида чека (а именно происходит формирование каждой отдельной позиции чека) обязательно должна присутствовать (как правило*) ровно одна команда addPayment для всех устройств, являющихся ККМ. Дополнительно может быть любое количество addString. Для устройств, представляющих обычный принтер, для FOP-устройств (см. ниже) и т.п. команда addPayment не нужна, так как там не происходит добавление продажи во внутреннюю память. Но сумма платежа будет считаться только для позиций, добавленных через addPayment. * Исключение может быть для случаев, если вы специально хотите разбить один платёж на две позиции в чеке (например, с разными названиями или атрибутами), в этом случае нужно самостоятельно разбить сумму на части и добавить несколько addPayment, в логе платежей будет одна запись с итоговой суммой. |
Далее приведём пример кода "добавление позиции" для формирования FO-документа, для FOP-драйвера. Эти строки соответствуют шаблону cashcheck_pko.xsl, находящемуся в стандартной поставке сервера печати.
...
| Блок кода | ||||
|---|---|---|---|---|
| ||||
int printerId = printer.getId(); |
В этом объекте есть метод switchPrinter, который позволяет переключить на нужный принтер внутри дин.кода, это может понадобиться в случаях, когда выбор принтера сложнее привязки "по типам". Весь конфиг принтера доступен через метод getConfig.
Последовательность вызова дин.кода:
...