База данных акций spromo2.Txt.

Таблица 16. Структура файла.

Описание информативных файлов.

Сигнализирующие файлы.

Кроме вышеуказанных файлов программа создает два файла в коммуникационном каталоге:

online2file Этот файл создается программой каждый раз после начала или открытия в эксклюзивном режиме, описанном в начале этого раздела. Присутствие этого файла и невозможность его стереть, означает, что программа еще работает на этой POS-системе. Этот файл нулевой длины.

shift2file Этот файл создается программой каждый раз после начала смены или открытия в эксклюзивном режиме (во время полной смены), описанном в начале этого раздела. Наличие этого файла и невозможность его удаления, означает, что программа еще работает на этой POS-системе и что нефискальная смена открыта. Файл нулевой длины.

Экспорт данных.

EuroPOS™ SM предлагает много информации посредством текстовых файлов. Информация всегда доступна по запросу, отосланному BackOffice программой. Этот запрос состоит в создании (BackOffice программой, в коммуникационном каталоге) файла запроса с именем requestn.txt, где ‘n’ это число. Каждый вид запроса предлагает различные виды информации. В некоторых случаях дополнительная информация может быть (или должна быть) в файле запроса, который описывает данные, которые запрашиваются. Эта информация должна быть подана в виде текста. В других случаях содержимое файла запроса может быть пустым и файл будет нулевой длины.

Если запрос был реализован, файл запроса удаляется. Удаление этого файла однозначно информирует главную программу, что запрос был реализован. Реализация запроса может состоять только из удаления файла запроса. Запрос может быть нереализован, если были даны неверные данные, описывающие запрос.

Ниже Вы можете найти описание команд.

Описание request7.txt.

Отсылает информацию о редактированных документах (счетах, чеках) в файл register.txt. Файл создается в том же каталоге, что и файл запроса. Выполнение этой команды приводит к транслированию бинарного файла, register.dat в адекватный текстовый файл, сохраняя порядок записей. Трансляция представлена в таком виде, что одна запись из файла register.dat в точно такую же запись в текстовом файле.

После отсылки всех записей, дополнительная заключительная запись добавляется, которая однозначно определяет, что файл был корректно отослан. Дополнительно пишется номер этой записи, чтобы показать количество записей, которые были отосланы.

Дополнительная информация может быть в файле запроса, которая

определяет запрашиваемую информацию. Отсутствие специфицирующей информации приводит к тому, что вся информация отсылается (с начала файла до последней записи). Определяющая информация включает три первые стоки файла request7.txt. Каждая строка должна заканчиваться знаком окончания строки (как в стандартных текстовых файлах).

В первой строке дата, ограничивающая начало данных файла register.dat, которые будут отосланы. Отсутствие информации или неправильная дата приводят к отсылке пустого файла.

Во второй строке находится дата, которая определяет конец отсылаемых данных.

В третьей строке есть возможность ввести ключевое слово "TRANS". Это приводит к созданию дополнительного файла regtr2.txt, включающего информацию, которая позволяет ассоциировать номера транзакций с номерами документов (также и для общих счетов).

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

Параметры:

'1' – для привилегированного держателя/объекта; '2' – для владельца;

'21' – В случае двухпринтерной конфигурации, 2 регистратора («владельца»). В случае однопринтерной конфигурации и не 2 регистраторов (REG2\register.dat) 1 регистратор генерируется (только один в этой конфигурации).

Таблица 17.Структура register.txt

Структура и формат данных файла request7.txt:

YYYYMMDD - дата начала файла;YYYYMMDD - дата конца файла;

TRANS – запрос на генерацию дополнительного файла regtr2.txt. Этот запрос приводит к передаче всех записей из register.dat, от даты начала до даты конца включительно.

Примечание

В файле register.txt добавляется контрольная запись. Это всегда последняя запись.

В поле "transaction number" контрольная запись дает количество экспортированных записей (включая контрольную запись) и текущую дату в полях „date if issuing" и „date of giving". Поле „Time of issuing" показывает текущее время.

Номер POS-системы в диапазоне может появиться только в последней записи и обозначать заключительную запись; затем, если номер отправленных записей в поле 'transaction number' (вместе с заключительной записью) и текущая системная дата в поле "date of issue".

Для суммарных документов флаг устанавливается только, если все транзакции, которые включены в данный документ, имеют фискальные чеки.

Поля имеют значение только когда поле „Forced payment" установлено в единицу или истина.

Описание regtr2.txt.

Таблица 18.Структура файла.

Это файл текстовый файл с постоянной длиной записи, в котором каждая запись заканчивается CRLF.

Примечание.

Для каждой записи в файле register.txt генерируется такое же количество записей в файле regtr2.txt, сколько транзакций включено в документе.

Описание request5.txt.

Возвращает наименования привилегий определенных в программе, в текстовый файл privil.txt. После создания, этот файл содержит константу: величина записей эквивалентна 32 и длина эквивалентна 1088 байтам.

Таблица 19. Структура файла.

Описание request4.txt.

Возвращает транзакцию с номером, который указан в файле запроса. Номер требуемой транзакции должен быть в текстовом виде, с номером в диапазоне 1..99999. Неправильный формат номера, его отсутствие или номер выходящим за пределы приводит к игнорированию запроса и удалению файла запроса. Транзакция возвращается в текстовом файле с именем trxxxxx.txt, где ххххх номер транзакции, заполненный нулями, если номер короче пяти знаков. Файл создается в том же каталоге, что и файл запроса. Отсутствие транзакции с требуемым номером приводит к тому, что создается файл нулевой длины.

Во второй строке Вы можете поставить опциональные параметры, которые определяют максимальную дату и опционально время транзакции, которая должна быть найдена.

Формат строки: "YYYYMMDD" или "YYYYMMDD HHMM".

Формат "YYYYMMDD" эквивалентен "YYYYMMDD 2359".

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

Таблица 20. Структура файла.

Файл содержит столько записей, сколько продано товаров в данной транзакции, плюс дополнительные записи для отмененных позиций и позиций, которые являются элементами множества.

Описание request3.txt.

Возвращает информацию о справочниках. Программа возвращает полную базу данных непустых товаров и все справочные базы данных в текстовых файлах. Структура файлов идентична структуре файлов, которые считываются во время импорта данных. Имена файлов также идентичны, но с подчеркиванием. Таким образом, генерируются такие файлы:

_item2.txt, _waiter2.txt, _tax2.txt, _payout2.txt, _payin2.txt,

_group2.txt, _paym2.txt, _unit2.txt, _modif2.txt, _note2.txt, _keydef2.txt,

_disc2.txt, _limit2.txt, _spromo2.txt, _coll2.txt.

Файлы создаются в том же каталоге, что и файл запроса.Исключением является файл _coll2.txt, который не содержит эквивалентного файла, который импортируется.

Файл с наборами coll2.txt

В ответ на запрос request3.txt, _coll2.txt генерируется файл, который отображает данные базы v2coll.cfg.

Примечание.

coll2.txt файл не может быть импортирован по причине того, что наборы определяются с помощью команд в файле item2.txt.

Таблица 21. Структура файла.

Описание request2.txt.

Возвращает информацию о текущем состоянии наличности по всем 100 методам платежей для определенного оператора или для всей POS-системы. Номер требуемого оператора дается в текстовом формате, в пределах 0..99. Неправильный формат номера, его отсутствие или выход за пределы возвращает информацию о состоянии платежей для всей POS-системы, а не для одного оператора. Транзакция возвращает текстовый файл с именем money2.txt. Файл создается в том же каталоге, что и файл запроса.

Таблица 22.Структура файла.

Описание request1.txt.

Возвращает информацию о покупателях в файл customer.txt. Этот файл создается в том же каталоге, что и файл запроса. Результатом выполнения команды является трансляция одной записи или целой базы данных бинарного файла с базой данных покупателей customer.dat в эквивалентный текстовый файл. Трансляция происходит путем перевода записи из customer.dat в точно такую же в customer.txt.

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

В первой строке также можно задать диапазон номеров для экспорта, например 100-199. Вторая и третья линии определяют диапазон записей с датой модификации. Вторая линия с датой начала YYYYMMDD и третья линия с датой окончания в формате YYYYMMDD. Например:

Отсутствие дат означает выборку от начала до конца. Если вы зададите диапазон покупателей в первой строке, то даты во второй и третей строке будут игнорироваться.

Таблица 23. Структура файла.

Например, поля: info 1..4 может использоваться для запоминания телефона. Значение этих полей определяется в конфигурационном файле europos2.ini.

Описание request0.txt, request6.txt

Возвращает информацию о продаже в файл sales2.txt (или sales6.txt как ответ на файл request6.txt). Этот файл создается в том же каталоге, что и файл запроса. Выполнение этой команды приводит к транслированию бинарного файла saleslog.dat в текстовый файл, сохраняя порядок событий (т.е. порядок транзакций). Трансляция выполняется таким образом, что одна запись из saleslog.dat точно транслируется в запись saleslog.txt в таком же порядке. Транзакция никогда не включает поврежденных или пустых записей.

После отправки всех записей, дополнительно заключительная запись добавляется, которая однозначно определяет, что файл был корректно отослан. В этой записи присутствует количество отосланных записей.

Отличия между request0.txt и request6.txt таковы:

1. requesto.txt обрабатывается сразу же после его появления в коммуникационном каталоге, тогда как request6.txt в конце работы программы EUROPOS и выходе в операционную систему.

2. requesto.txt создает файл sales2.txt. Файл, созданный на базе request6.txt называется sales6.txt. Структура обоих файлов идентична.

В файл запроса можно включить дополнительную информацию, описывающую получаемую информацию. Отсутствие специфицирующей информации приводит к отсылке всей информации, от начала продаж до конца. Специфицирующая информация включает три первых строки в файле requesto.txt. Каждая строка должна заканчиваться концом строки, как в стандартных текстовых файлах.

В первой строке содержится информация по дате начала выборки из файла saleslog.dat. Отсутствие информации или неправильная дата приводит к тому, что появляется пустой файл.

Вторая строка ограничивает конечную дату отсылки данных. Отсутствие информации (пустая строка) или неправильная дата приводит к тому, что отсылаются данные до конца с некоторыми ограничениями.

Третья линия определяет тип информации. Определение состоит из одного ключевого слова FIELD и буквы (или букв) описывающих типы записей для трансляции (величина букв не имеет значения). Отсутствие информации (пустая строка) или неправильное ключевое слово приводит к тому, что отсылаются все типы записей. То же самое происходит, если нет никакой буквы после ключевого слова FIELD.

В пятой строке вы можете указать опциональный параметр CUSTOMER. Если Вы укажете номер после ключевого слова, то файл sales2.txt, будет содержать все транзакции (или только транзакции, без записей открытия смены и т.п.) относящиеся к определенному покупателю (с записями типа INFO).

Операции продажи в целом, не имеет значения вид и значение определенной информации. Это означает, что ситуация когда часть информации определенной транзакции может быть отослана в файл sales2.txt невозможна. Таким образом, все записи, включенные в одну транзакцию, имеют одну и ту же дату и время.

Структура и формат данных файлов requesto.txt и request6.txt:

YYYYMMDD HHMM – дата и время, ограничивающие начало файла

YYYYMMDD HHMM – дата и время, ограничивающие конец файла

FIELD sssss – ключевое слово

INFO – информационные записи

Этот запрос приводит к передаче всех типов записей (заданных параметром 'sssss') из файла saleslog.dat, начиная с даты начала и заканчивая датой конца включительно.

Если дата конца не была указана, то передача будет осуществлена по следующему алгоритму:

Считывается дата последней непустой (d_ost) записи из файла saleslog.dat.

Считывается текущая дата (d_akt).

requesto.txt: если d_akt > dost тогда d_akt = d_ost + 1 minute.

request6.txt: d_akt=d_ost + 1 minute. Если d_akt > d_ost, тогда пустая запись (с d_akt датой) добавляется в конец файла saleslog.dat, пока условие, что непустая запись последняя не выполнится. Добавление приводит к обновлению d_ost.

Передается d_ost дата, увеличенная на минуту.

По причине возможной десинхронизации часов POS-системы и BackOffice сервера, этот путь передачи (без ограничения даты конца) единственно верный путь получения полной информации о продаже. Любой другой привел бы к потере информации или ее дублированию. Дата начала должна быть равна дате последней записи из предыдущего запроса и увеличена на одну минуту. Вышеуказанный алгоритм гарантирует, что дата (+час+минута) последней записи из последней передачи никогда не повторится в следующей.