Обработка ошибок при работе Фискального Регистратора

[GoogleCodeExporter]

Предлагаю обсудить правильное поведение 
системы при обнаружении ошибок печати 
фискального регистратора.

Как мне кажется, для начала надо определить 
степень критичности ошибки печати.

Если используется обычный принтер, то 
ошибка печати является не критичной. То 
есть такая ошибка не должна блокировать 
сохранение чека в базу данных. При 
возникновении ошибки, чек должен 
сохраниться, а на экран должно появиться 
сообщение об ошибке печати.

С другой стороны, ошибки при печати с 
фискальным регистратором должны 
блокировать сохранение чека. Иначе отчеты 
о продажах по данным ФР не будут совпадать 
с отчетами о продажах по данным кассы. При 
этом непонятно как поведет себя кассир, 
выдаст новый чек (дублеж чека в базе POS, 
неверное списание количества проданного 
товара), либо просто не выдаст бумажный чек, 
что добавляет другие риски.

Я нашел в исходниках специальную обработку 
TicketPrinterException. Я смотрел очень поверхностно, 
но как я понял сейчас при ошибках печати 
чех сохраняется.

Предлагаю ввести TicketFiscalPrinterException, и 
расширить логику так, чтобы при 
возникновении такого исключения, чех не 
сохранялся в базу.

Original issue reported on code.google.com by gennady....@gmail.com on 1 Apr 2011 at 4:00

[GoogleCodeExporter]

Сейчас проверю, как работает TicketPrinterException, 
если в чековом принтере нет бумаги.

Original comment by svinin...@gmail.com on 1 Apr 2011 at 4:13

[GoogleCodeExporter]

Ну я подтверждаю, это уже глядя в исходный 
код, что: 
1. Сохраняется чек в базу данных, ему 
присваивается номер
2. Транзакция БД закрывается commit'ом
3. Запускается event ticket.close
4. Запускается печать Ptinter.Ticket либо Printer.Ticket2

Таким образом ни событие ticket.close, ни печать 
чека на запись в БД не влияют. 

Дальше можно не читать, это я для истории, 
сохранить ход мыслей.

Что касается события ticket.close - оно и ладно. 
Единственное - надо нормально обработать 
ошибки при старте обработчика события. 
Сейчас их явным образом нет (может где-то 
глубже). Таким образом (я тут еще не 
проверял, могу ошибаться) ошибка в 
обработке события ticket.close может 
блокировать печать чека и поступление 
данных в ФР. Я тут еще покопаю, в крайнем 
случае сверху еще обработчик ошибок 
накину. Пусть будет два.

Что касается печати то очевидно, что если 
мы хотим целостности данных, то транзакция 
от БД должна закрываться только после 
самой печати чека. То есть дождаться 
окончания печати.

Теперь про сами функции. Файл JPanelTicket.java. Все 
театральное действие происходит в closeTicket().

Мы видим вызов dlSales.saveTicket() - само 
сохранение, затем  executeEvent(..."ticket.close"...), 
затем printTicket().

Метод printTicket обрабатывает ошибки печати 
внутри себя, и вызывающему никак не 
сообщает что произошел инцидент. Таким 
образом нормально обрабатывать транзакцию 
внутри метода closeTicket() без изменения API не 
удастся.

Конкретно надо менять метод printTicket, чтобы 
он после сообщения пользователю об ошибке 
печати возвращал вызывающему информацию о 
самой ошибке. Я предлагаю это сделать через 
exceptions, чтобы printTicket вызывал исключение 
TicketPrinterException или TicketFiscalPrinterException.

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

Ну а в самом closeTicket сделать обработку 
транзакции для сохранения.

Ну я, пожалуй, пока так делаю.

Original comment by gennady....@gmail.com on 2 Apr 2011 at 4:05

[GoogleCodeExporter]

Андрей, удалось подтвердить нарушение 
целостности? Ну если бумага кончилась в ФР, 
например?

Original comment by gennady....@gmail.com on 4 Apr 2011 at 2:15

[GoogleCodeExporter]

Сейчас по рукой не было фискальника, а 
принтеры все как назло с USB, завтра должен 
быть, обязательно попробую и скажу.

Original comment by svinin...@gmail.com on 4 Apr 2011 at 5:53

[GoogleCodeExporter]

Такс, r455.

Я ввел новый эксепшн TicketFiscalPrinterException. Он 
случается, когда возникает ошибка с ФР. 
Обработку эксепшена я сделал только когда 
печатается чек на продажу.

Надо теперь аккуратно проверить где ФР 
используется еще, например при возврате 
товара, оплате клиентом кредита и так 
далее, и сделать обработку ошибки там. 
Конечно вероятность возникновения ошибок 
в тех операциях сильно меньше, потому что 
самих операция обычно сильно меньше. 
Однако культурно все-таки закрыть вопрос и 
с теми операциями.

Original comment by gennady....@gmail.com on 4 Apr 2011 at 8:04

• Changed state: Work

[GoogleCodeExporter]

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

Original comment by gennady....@gmail.com on 4 Apr 2011 at 8:18

[GoogleCodeExporter]

Вот места, в которых используется ФР. В них 
надо аккуратно проверить поведение 
системы при ошибках ФР. Тут возможны 
нарушения целостности данных.

 * CustomersPayment.java
 * JRootApp.java
 * StockManagement.java
 * JPanelCloseMoney.java
 * DeviceFiscalPrinter.java
 * TicketParser.java
 * JPanelButtons.java
 * JPanelTicket.java
 * JTicketsBagTicket.java

Это я на будущее, чтобы не забыть.

Original comment by gennady....@gmail.com on 7 Apr 2011 at 3:45

[GoogleCodeExporter]

Original comment by svinin...@gmail.com on 18 Apr 2011 at 5:03

• Added labels: Type-Enhancement, Priority-High, Milestone-0.3.0, Component-SupportHardware, Maintainability

[GoogleCodeExporter]

В текущей версии это реализовано, 
проверено. Тикет закрываю.

Original comment by gennady....@gmail.com on 22 Apr 2011 at 7:28

• Changed state: Fixed