Интеграция со сторонним ПО...

[BigAndy]

Есть программа учета и работы в фотокиоске.
После ввода данных в нее кассиры переходят в денси:кассу и повторно вбивают все те же виды услуг что и в основной программе. Есть ли какой-то API для интеграции с Денси:Касса. Идеально было бы, если бы денси:касса слушала бы listen/notify postgresql. Но, судя по коду, все записи в Денси:касса формируются и вносятся в postgresql одной тразакцией.. Это так?
Куда можно покопать? Можно было бы "допилить" RMK, но, во -первых это не кашерно, во-вторых работа со сторонним ПО возможна (и, собственно осуществляется) с других хостов в той же сети.

[Alexander]

судя по коду, все записи в Денси:касса формируются и вносятся в postgresql одной тразакцией.. Это так?

Да, это сделано для того, чтобы точно знать, что, либо весь кассовый чек в базу записался, либо весь не записался.

Может быть можно рассмотреть вариант внешних заказов.
Т.е. при записи в БД сторонней программой формируется текстовый файл определённого формата, который по нажатию спец. клавиши загружается в ДЭНСИ: КАССу в виде готового чека, который остаётся пробить на ФР.

[BigAndy]

Да, это сделано для того, чтобы точно знать, что, либо весь кассовый чек в базу записался, либо весь не записался.

O_o.. Bigin transaction -> checkpoint->commit->| rollback не подходит?

Может быть можно рассмотреть вариант внешних заказов.
Т.е. при записи в БД сторонней программой формируется текстовый файл определённого формата, который по нажатию спец. клавиши загружается в ДЭНСИ: КАССу в виде готового чека, который остаётся пробить на ФР.

Хорошая мысль. Однако при варианте работы с сетецентричной архитектурой на сервер Денси придется выкладывать от каждого рабочего места свой файл. Может, имеет смысл через таблицу БД это сделать? Скажем, особый тип операции в Transactions, которые бы Денси:касса "подцепляла" бы из таблицы и вписывала бы в свою транзакцию? Скажем, по критерию номера рабочего места. И помечала бы их помеченными. Такой механизм легко реализуем, скажем при помощи правил do->instead. Собственно у нас, например, подобные операции так и реализуются.
Уж всяко из текстового файла при помощи copy можно подтянуть в RDBMS любую запись.

[Alexander]

O_o.. Bigin transaction -> checkpoint->commit->| rollback не подходит?

Но это же и даст запись всех строк в БД единым куском-транзакцией.

Может, имеет смысл через таблицу БД это сделать?

Разумный вариант. В конце-концов внешние текстовики можно демоном (или даже через cron) в PostgreSQL запихивать, а ДЭНСИ: КАССА будет проверять таблицу "внешних заказов". В таком случае в Вашей схеме можно писать напрямую в таблицу, и подгружать в ДЭНСИ: КАССу по кнопке [Внешние заказы]. А в общем случае - из текстового файла демоном - в таблицу, в ДЭНСИ: КАССе так же.
Кстати, в общем случае, внешний заказ с любого рабочего места может быть обработан на любом рабочем месте. Либо надо делать настройку "показывать в списке заказов только заказы с текущего РМК", либо просто в списке заказов в ДЭНСИ: КАССе выдавать номер РМК-источника заказа (для выбора кассиром).

[BigAndy]

Но это же и даст запись всех строк в БД единым куском-транзакцией.

Не совсем так. Например, поля с default currenttimestamp() дадут (могут дать) разные временные метки. В данном случае с вашей программой это не важно, но нам для наших случаев пришлось немного модифицировать таблицы, "нарастив" их при помощи наследования несколькими полями.

либо просто в списке заказов в ДЭНСИ: КАССе выдавать номер РМК-источника заказа (для выбора кассиром).

Ну, можно и отдельной таблицей сторонних заказов, хотя, на мой взгляд, transactions вполне хватит. А выбирать можно по номеру РМК. В общем, критерий
придумать можно.
Зы. Только сейчас сообразил, что данный подход удобно реализовать, и для случая, когда, например, на отдельном рабочем месте, допустим, в супермаркете, взвешивается, и тарифицируется товар и потом покупатель с этим товаром приходит на один из выходных РМК, при этом ни покупатель, ни кассир изначально не знают, на какую кассу он подойдет... Так, скажем, принцип покупательской тележки в интернет-магазине..

[BigAndy]

"Работа с отложенными чеками" , которая указана в roadmap - это не то, что в ТопикСтарте?

[Alexander]

В целом - очень похоже. Если закладывать такой функционал, что чек, отложенный на одной кассе, может быть восстановлен на любой кассе в магазине, тогда схема, похоже, идентична. (Фактически - только разные источники первичной информации).
Определённая разница может быть в том, что произвольное стороннее ПО сложно заставить писать информацию напрямую в БД - логичнее обрабатывать текстовый файл. Если же чек формируется изначально в ДЭНСИ: КАССе, а затем откладывается кассиром, то он, понятно, уже есть в БД.
Однако в Вашем случае, судя по всему, можно будет писать информацию напрямую в таблицу отложенных чеков.