Глоссарий

1. Операционный день - сущность, объединяющая смены магазина за день. Создаётся только при появлении продаж за этот день. Операционный день – не то же, что календарный день, чеки могут находиться в одних календарных сутках, но в операционном дне с другой датой.

2. Номер кассы - это номер кассового компьютера, установленного в торговом зале и установленным кассовым модулем.

3. ККМ - это контрольно-кассовая машина, фискальный накопитель с уникальным заводским номером.

4. Кассовый документ - любой зафиксированный на кассе документ из списка ниже. Каждый документ на кассе и сервере в рамках одной смены имеет свой уникальный номер, последовательность номеров документов должна строго соблюдаться.

Список кассовых документов:

a. Чеки внесения и изъятия

b. Чеки продажи и возврата

c. Аннулированные чеки

d. X-отчет

e. Z-отчет

5. Фискальными документами являются тольке те, обработка которых ведет к изменению данных в фискальном накопитеоли.

a. Чеки продажи и возврата

b. Z-отчет

Дополнительная информация

• Все зарегистрированные документы на кассах группируются в смены, каждой из которых присваивается уникальный последовательный номер в рамках одной ККМ (ФН).
• Смена на кассе открывается чеком продажи или командой открытия смены на ФН.
• Смена закрывается Z-отчётом.
• По истечении 24 часов после открытия смены дальнейшая регистрация чеков в этой смене невозможна, допустимо лишь закрытие смены Z-отчетом.

Краткая схема транспорта

Транспорт

Касса → Сервер

Выполнение транспорта документов в модуль Операционный день на сервере происходит в два этапа:

1. Файлы с данными документов сохраняются в файловом хранилище сервера, используя http-сервер.
2. Сохраненные на сервере файлы с документами регистрируются на сервере для дальнейшей обработки.

Даннные о продажах базы данных кассового модуля

В кассовом модуле данные о продажах хранятся в следюущих базах:

• cash - все данные по чеку:
  • позиции в чеке
  • типы оплат
  • смены
  • и.т.п.
• discount - рекламные акции и скидки в чеке.
  • какие рекламные акции и скидки сработали, и на какую сумму
  • какие карты применялись
  • чековые купоны
  • и.т.п.

Основные таблицы

БД Cash

Таблица	Назначение	Привязка
ch_introduction	Внесение денег	К смене привязывается по полю id_shift
ch_payment	Чек - Оплаты
ch_position	Чек - Товарные позиции
ch_purchase	Чеки (заголовки чеков)	К смене привязывается по полю id_shift
ch_reportshift	Z/X-отчет	К смене привязывается по полю id_shift
ch_reportsshift_payments	Типы оплат для отчетов операционного дня
ch_shift	Смены
ch_withdrawal	Изъятия наличных	К смене привязывается по полю id_shift

Подробный список таблиц

БД Discount

Подробный список таблиц

Процесс транспорта

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

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

Статусы отправки документов

Статус отправки данных находится в 5 таблицах:

Пример

ch_purchase

Поля

Поле	Назначение
id	Уникальный идентификатор записи в таблице
datecommit	Время фискализации чека
datecreate	Время создания чека в БД (когда осуществили продажу первой позиции)
fiscaldocnum	Номер который получил документ в ФН
numberfield	Номер документа в смене
Senttoserverstatus	статус отправки документа на сервер
id_session	Идентификатор сессии (ch_session) пользователя в которой создали документ
id_shift	Идентификатор смены (ch_ shift), которой принадлежит этот документ
filename	Название файла, который был отправлен на сервер.

Основное поле, по которому можно проверить связь с сервером - это senttoserverstatus:

Статусы:

• 0 – документ не отправлялся. Если документ не уходит из этого статуса, это, как правило означает, что отсутствует связь с сервером или большая очередь (когда переотправляют данные за несколько смен) и, требуется время, так как файлы формируются по очереди до 100шт. (по умолчанию) документов в каждом.
• 1 – отправляется. Зависаний при этом статусе не фексируется, единственное из-за чего он может долго в нём находится - это медленная связь и работа кассового модуля.
• 2 – отправлено. Документ успешно отправлен и принят сервером в очередь входящих документов. При данном статусе документ можно производить его поиск на сервере, однако если в нем не хватает каких либо данных, он может быть отклонен сервером при обработке входящих файлов.
• 5 - любой другой  – отправка завершилась ошибкой, как правило случается, если часть полей не заполнена в документе.

Когда документом получен  senttoserverstatus=2, тогда можно произвести попытку его поиска на сервере.

Транспорт Retail - > Centrum

После того как файл уходит с кассы, он попадает на сервер. Физически его можно найти в \SetRetail10\nginx\html\documents\<Номер кассы>. Однако он хранится в зашифрованном виде, поэтому смысла его открывать нет. Все поступившие файлы регистрируются в БД, для их последующей обработки.

- Чеки, отчеты X и Z , внесения и изъятия регистрируются в базе set _ operday таблица od _ inbound _ files

- результаты отработанных скидок в базе set _ loyal таблица loy _ inbound _ files

Таблицы идентичны:

Id – уникальный идентификатор записи в таблице

Cash _ number – номер кассы с которой пришел документ

Shop _ number – номер магазина с которого пришел документ

Documents _ count – кол-во документов в файле

File _ path – папка и название файла

Status – статус обработки входящего файла

Receive _ date – дата и время получение файла

Для нас самым интересным полем является status :

0 – файл еще не обработан

1 – обработан успешно

2 и др. –не обработан, произошла ошибка.

Исправив статус на «0», можно заставить сервер заново обработать файл. Самая частая причина, по которой файл не может быть обработан, это когда различаются версии сервера и кассы после обновлений, в таблицах появляются новые поля, которые есть на сервере, но например нет на кассе, в итоге пришедший файл не может быть обработан, так как не хватает данных. Поэтому рекомендуется иметь кассы и сервер одной версии.

После обработки данные записываются в таблицы, которые по большому счету совпадают с кассовыми таблицами:

БД set_operday:

od_purchase - чеки

od_reportshift – отчеты X и Z

od_withdrawal - изъятия

od_introduction – внесения

БД set_loyal:

loy_transaction

После записи данных , создаются задания для выгрузки данных в ERP, в БД set_operday это od_out_erp_documents, в БД set_loyal это loy_out_erp_documents. В идеале в этих таблицах должно быть не больше пары записей, которые непосредственно сейчас должны выгрузиться. Если в ней очень много записей, значит либо Retail не отправляет данные, либо Centrum их не принимает.

Транспорт Centrum -> ERP

Если магазины не виртуальные, то данные будут приходить на сервер Centrum -а и регистрируются в БД set таблица erpi _ retail _ inbound _ files :

После обработки этих заданий чеки и транзакции раскидываются по таблицам:

Erpi _ purchase – продажи

Erpi _ loytransaction – транзакции лояльности

Erpi _ zreport – Z отчеты

Erpi _ cash _ inout – внесения и изъятия

И др. таблицы в которых содержится более подробная информация(оплаты, позиции и т.п.)

В данных 4х таблицах есть поле, которое определяет были ли выгружены данные в ERP – sendedtoerp :

True – данные были выгружены и их можно искать в папке выгрузки или в ERP если выгрузка совершается по Web -сервису.

False – данные еще не выгружались. Выгрузка как правило совершается по таймеру(файловый обмен) или по запросу Web -сервиса из ERP .

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

Транспорт Centrum->ERP В версии 10.2.8.0 и выше

Начиная с версии 10.2.8.0 документы могут выгружаться в несколько ERP.

Архитектура

До версии 10.2.8.0 признаком отправки документа в ERP являлся флаг sendedToErp в таблицах чеков, внесений, изъятий, Z-отчетов и т.п. (true - отправлен, false - не отправлен).
Поскольку появилось требование выгружать один и тот же документ в разные ERP - одного признака стало недостаточно.
Таблица erp является справочником всех способов взаимодействия с ERP (файлы, веб сервис, 585, Кеско, Set5 и т.п.) и имеет признак вкл./выкл. (registered = (true | false)) .
Каждый способ взаимодействия реализует обмен различных типов документов, перечисленных а справочнике erp_plugins .
Теперь каждый тип документа имеет очередь на отправку, которая из себя представляет таблицу ( erpi_ документ _queue ) с двумя полями ( id_документа, id_плагина_ERP ) .

Как это работает?
При сохранении нового документа в БД, для него создаются записи в таблице очереди ( erpi_документ_queue ) со ссылкой на этот документ и на все включенные ( erp_plugins.enabled = true ) плагины для данного типа документа ( erp_plugins.type ).
При осуществлении выгрузки документа в ERP запись из очереди для соответствующего документа и соответствующей ERP удаляется.

ВАЖНО!
Единственным способом взаимодействия с ERP для которого не создаются записи в таблицах очередей является веб сервис на стороне Set10 (0.0.0.0:8090/SET-ERPIntegration/FiscalInfoExport?wsdl),
т.к. Set10 выполняет пассивную роль во взаимодействии и отдаёт данные по внешнему запросу.
Методы getNewPurchasesByOperDay, getNewZReportsByOperDay возвращают не запрашиваемые ранее документы и Z-отчёты.
Поле accepted_by_ws (true - принят, false - не принят) используется для статуса получения документа от ERP (если в настройках Внешние системы - ERP - Протокол Set Retail 10: выгрузка данных в веб-сервис на стороне ERP - включен параметр Веб-сервис с обратной связью

На следующем рисунке представлена схема БД со связями таблиц документов, очередей и справочниками ERP:

Настройки

Начиная с версии 10.2.8.0 настройки экспорта в ERP хранятся не файлах, как ранее, а в таблице sales_management_properties.
Каждый параметр в таблице имеет свои ключ (property_key) , значение (property_value) и описание (description) .
Каждому плагину экспорта из таблицы erp_plugins соответствуют настройки, ключи которых начинаются с имени плагина ( erp_plugins.name ).
Например export.setv5.purchases .dbHost - адрес сервера для выгрузки чеков в Set5 для плагина export.setv5.purchases .
Настройки, которые имеют визуализацию, применяются автоматически без рестарта сервера.
При изменении настроек вручную в БД потребуется перезагрузка сервера.