Собственно вопрос связан с кассовым аппаратом.
БД на MS SQL.
Есть необходимость сохранить платеж в БД и напечатать в чек.
Все это должно быть в одной транзакции.
Не вижу варианта кроме с клиента послать на сервер BEGIN TRANSACTION
Сохранить платеж.
Печать чека
После чего по результатам
COMMIT TRANSACTION или ROLLBACK TRANSACTION

Что смущает - С клиента. Долго. Чек печатается вполне реальное время.

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

Была мысль, сначала чек.
Пугает вариант "отвалился сервер"
Вариант нереальный, но...

Насчет

ssa
вытаскиваешь его из фискальной памяти и сохраняешь на сервер

Не совсем ясно.
Ну допустим разберусь как вынуть (пока не знаю)
А что вынимать?

Как сейчас, без ККМ.
Есть доки, в том числе с суммой.
Их юзер открывает, принимает деньги, сохраняет.
Все попадает в платеж.
Теперь в этот БП надо воткнуть печать чека. И хотелось бы обеспечить транзакционость.
Когда все работает, напечатал чек, потом платеж в БД. И нет проблем.
Пугает, что БД отвалилась (что то случилось) и нет возможности сохранить.

Как вариант, разобрать эту небывалую ситуацию отдельно?





Исправлено 1 раз(а). Последнее : Аспид, 09.06.17 12:59

Аспид
Была мысль, сначала чек.
Пугает вариант "отвалился сервер"

И что? Чек в фискальнике все равно есть, его на сервер всегда можно и потом запихать.

Цитата:

Вариант нереальный, но...

Насчет

ssa
вытаскиваешь его из фискальной памяти и сохраняешь на сервер

Не совсем ясно.
Ну допустим разберусь как вынуть (пока не знаю)

У фискальника есть команда получения фискального документа по его фискальному номеру.

Цитата:

А что вынимать?

Содержимое чека со всеми реквизитами в текстовом виде. Думаешь, в ОФД они из астрала попадают? Или из твоей программы?

Не... это все ясно.
Есть ТТН. Она не оплачена.
Юзер принимает деньги, печатает чек, отдает юзеру)))
А БД отвалилась. ТТН в ней не оплачена.
Дело допустим в ночь, с суб. на воскр.)))
Мы появимся тока в понедельник)))

Кассиру оставить у себя копию чека. Со всеми пояснениями, и № ТТН.
Пожалуй так можно.
Тем более что нереальный вариант.

И кстати, описанный мной в начале вариант тоже не катит, в той ситуации.
BEGIN TRANSACTION
Сохранить платеж.
Печать чека
И ТУТ ТО ОТВАЛИЛСЯ СЕРВЕР БД!
После чего по результатам
COMMIT TRANSACTION или ROLLBACK TRANSACTION
Так что по любому, Сергей спасибо)

Аспид
Долго. Чек печатается вполне реальное время.

Надо было брать не самый дешевый Атолл, а что-то вроде Штрих-М01Ф. 100 строк менее чем за полсекунды. Но в нем нет переносов строк, пришлось самому лепить.
Кстати, в фискальнике лежат все фискальные документы (открытие смены, чеки, закрытие смены/Zотчеты). А еще у Штриха в последних версиях драйвера появилась база чеков в формате sqllite. Но я еще с ней не разбирался

Аспид
Кассиру оставить у себя копию чека. Со всеми пояснениями, и № ТТН.
Пожалуй так можно.

Зачем? Просто периодически (ну или по потребности - "вручную") забирать из кассы ВСЕ чеки и сверять - есть они в БД или нет. И не надо тогда "на бумажке" ничего писать.

У нас Атол FPrint-22ПТК
Да нормальная у него скорость)
Но реал-тайм конечно заметное.

В общем так решил.
1. Сохраняем платеж
2. Печатаем чек.
3. Если чек не напечатан, удаляем платеж, можно начинать с начала.

Ежели по пути что-то случится... бум разбираться)
Причем это не сложно. БД больше 10 мин. простоя не допускает.
Платеж в состоянии удалить сам юзер.
В общем, под нашу специфику годится.

Igor Korolyov
Зачем? Просто периодически (ну или по потребности - "вручную") забирать из кассы ВСЕ чеки и сверять - есть они в БД или нет. И не надо тогда "на бумажке" ничего писать.

Блин. Спасибо. Я же в БД фиксирую все чеки (можа просто для отладки, сравниваю с z-отчетом), где прописываю id платежа
А в платеж, пишу id чека.
То бишь, в случае коллизии все несложно разруливается

Аспид
У нас Атол FPrint-22ПТК
Да нормальная у него скорость)
Но реал-тайм конечно заметное.

В общем так решил.
1. Сохраняем платеж
2. Печатаем чек.
3. Если чек не напечатан, удаляем платеж, можно начинать с начала.

Я бы порекомендовал в 3-ем пункте просто прописывать в отдельное поле ID чека.
После Z-отчета, если касса сошлась, платежи без ID можно удалять, если не сошлась, сразу видно где чего не хватает.

Sawradym
Я бы порекомендовал в 3-ем пункте просто прописывать в отдельное поле ID чека.
После Z-отчета, если касса сошлась, платежи без ID можно удалять, если не сошлась, сразу видно где чего не хватает.

Разумно, но...
Коли чек не напечатан, то он не сохранится в БД, и никакого ID у него нет.
У всех платежей за нал, будет ID чека.
Можно было бы разруливать так.
Но уже с бухами решили.
Нет чека - нет платежа.

Транзакция как поможет, если идёт печать на физическом оборудовании? Чек в кассу обратно не втянешь и надписи не сотрешь при откате.
Надо сторнировать в базе, если произошел сбой оборудования и не производить печать, если сохранение в базе произошло с ошибкой.