Глоссарий

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

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

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

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

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

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

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

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

d. X-отчет

e. Z-отчет

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

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

b. Z-отчет

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

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

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

Транспорт

Касса → SetRetail

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

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, тогда можно произвести попытку его поиска на сервере.

SetRetail → SetCentrum

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

Все поступившие файлы регистрируются в базе данных, для их последующей обработки.

• set_operday → od_inbound_files
  • Чеки
  • X-отёты
  • Z-отчёты
  • Внесения
  • Изъятия
• set_loyal → loy_inbound_files
  • Результаты по отработанным скидкам (транзакция лояльности)

Поля

Статусы status:

• 0 – файл еще не обработан
• 1 – обработан успешно
• 2 – не обработан, произошла ошибка.

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

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

• set_operday
  • od_purchase
  • od_reportshift
  • od_withdrawal
  • od_introduction
• set_loyal
  
  • loy_transaction

После записи данных, создаются задания для выгрузки данных в ERP:

• set_operday → od_out_erp_documents
• set_loyal → loy_out_erp_documents

В этих таблицах должно быть не больше 2х записей, которые непосредственно сейчас должны выгрузиться. Если присутствует достаточно большое количество записей, тогда, возможно SetRetail не отправляет данные, либо SetCentrum их не принимает.

SetCentrum → ERP

Если магазины не виртуальные, тогда данные будут загружаться на сервер SetCentrum и регистрироваться в set → erpi_retail_inbound_files

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

• erpi_purchase – продажи
• erpi_loytransaction – транзакции лояльности
• erpi_zreport – Z отчеты
• erpi_cash_inout – внесения и изъятия
• Другие таблицы в которых содержится более подробная информация (оплаты, позиции и т.п.).

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

Статусы:

• true – данные были выгружены. Проверку наличия файлов можно осуществить в папке выгрузки или в ERP, если выгрузка осуществляется по web-сервису.
• false – данные еще не выгружались. Выгрузка, как правило, совершается по таймеру (файловый обмен) или по запросу через web-сервис из ERP.

Centrum → ERP (10.2.8.0 и выше)

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

Архитектура

• До версии 10.2.8.0 признаком отправки документа в ERP являлся флаг sendedToErp в таблицах чеков, внесений, изъятий, Z-отчетов и т.п. (true - отправлен, false - не отправлен).
• При выгрузке одного и того же документа в разные ERP с одним признаком недостаточно.

Таблица erp является справочником всех способов взаимодействия с ERP (файлы, веб сервис, SetRetail5 и т.п.) и имеет признак вкл./выкл. (registered = (true | false)) .

Каждый способ взаимодействия реализует обмен различных типов документов, перечисленных а справочнике таблицы erp_plugins.

Каждый тип документа имеет очередь на отправку, которая хранится таблицах 

• erpi_actions_queue
• erpi_cash_inout_queue
• erpi_export_table_queue
• erpi_loytransaction_queue
• erpi_payment_transaction_queue
• erpi_products_queue
• erpi_purchases_queue
• erpi_queue_size_cashier_answer_queue
• erpi_salesreports_queue
• erpi_turnovers_queue
• erpi_zreport_queue

Во всех таблицах данные храняться в двух полях:

Процесс

При сохранении нового документа в базе данных, для него создаются записи в таблице очереди в таблице erpi_[тип_документа]_queue со ссылкой на этот документ и на все включенные парметром erp_plugins.enabled=true плагины для данного типа документа в поле erp_plugins.type.

При осуществлении выгрузки документа в ERP запись из очереди для соответствующего документа и соответствующей ERP удаляется.

Схема со связями таблиц документов, очередей и справочниками ERP

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

• Начиная с версии 10.2.8.0 настройки экспорта в ERP хранятся в set → sales_management_properties.
  • Каждый параметр в таблице sales_management_properties, имеет свой ключ property_key, значение property_value) и описание description.

• Каждому плагину экспорта из set → erp_plugins соответствуют настройки, ключи которых начинаются с имени плагина erp_plugins.name.
  • Например: export.setv5.purchases.dbHost - адрес сервера для выгрузки чеков в SetRetail5 для плагина export.setv5.purchases.
• Настройки, которые имеют визуализацию, применяются автоматически без перезапуска службы сервера.
• При изменении настроек вручную в sales_management_propertiesнеобходимо перезапустить службу сервера.