Closed GoogleCodeExporter closed 9 years ago
Как раз таки работала над этим вопросом,
вот хотела сказать что по возврату не нужно
отправлять никакие суммы, сумма в теге <total>
должна быть 0 при возврате и аннулировании
чека(иначе у вас будет зависать чек, так как
для команды возврата нужны только цена и
количество).
Поддерживаю вас в добавлении нового
параметра type, а про секции в моей
реализации секция одна и имеет смысл
склада, которая она у нас одна.
Original comment by m.makazh...@gmail.com
on 21 Sep 2011 at 6:05
Уже нашёл у нас на складе Ауру, сам
протестировал, так-что исправил работу с
возвратом это в r578. До конца дня думаю и с
типом оплаты разобраться.
Original comment by svinin...@gmail.com
on 21 Sep 2011 at 6:26
Над секциями я ещё не думал, но как вариант
можно их привязать к складам Openbravo POS, но это
в отдельной теме.
Для Ауры(протокол Атола) типы платежей
делаем так:
cash и cashrefund тип оплаты НАЛИЧНЫМИ в формате BCD
01
debt тип оплаты КРЕДИТОМ в формате BCD 02
magcard и magcardrefund тип оплаты ПЛАТ.КАРТОЙ в
формате BCD 04
В ФР Остаётся ещё ТАРОЙ в формате BCD 03, но
это кому надо сам придумает куда отнести.
В POS остаются продажи по чековой книжке, по
выписке и без оплаты, я не знаю надо их
проводить через память ФР или можно
обойтись просто печатью текста на ленте.
Original comment by svinin...@gmail.com
on 21 Sep 2011 at 6:47
У меня возникли проблемы по оплате
смешанными типами оплаты, ФР регистрирует
все оплаты как наличными и другими, тем,
который из них первый стоит на paymentline.
А насчет продажи по чековой книжке, по
выписке и без оплаты, думаю что если все
товары прошли по ФП, то ФР регистрирует его
как наличные, и для этого кассир должен
дополнительные документы распечатать или
хотя бы прикрепить к отчетам бланки чека
или выписки.
Original comment by m.makazh...@gmail.com
on 21 Sep 2011 at 7:05
Всё сделал в r579 поддержку типа оплаты для
Ауры, обновляем, тестируем.
Проблема смешанного типа оплаты есть, но
это не проблема POS, а проблема алгоритма ФР.
Предлагаю поддержку типа платежа для
фискальных регистраторов оставить как
есть и подумать над Issue 178.
С фискальным регистратором не получится
всё подряд в наличку, так как именно эта
сумма будет отражена в фискальной памяти.
По этому пока предлагаю эти типы платежей
не проводить через ФР, к тому-же в рознице
они очень редки.
Original comment by svinin...@gmail.com
on 21 Sep 2011 at 9:02
Ещё проблемка с Аурой. Так как включён
контроль наличности в ФР, то возвратить
можно только по тому типу оплаты по
которому была произведена продажа.
Original comment by svinin...@gmail.com
on 21 Sep 2011 at 9:11
Более конкретно, если нет в регистре
наличности то возврат по карте не
производится. Как в Ауре отключить
контроль наличности?
Original comment by svinin...@gmail.com
on 21 Sep 2011 at 11:17
В r580 просто отключил контроль наличности. В
будущем, когда для протокола Атол сделаем
чтобы при ошибках на ФР чек на POS не
закрывался, надо будет вернутся к этому
вопросу и может как-то по другому
реализовать.
Original comment by svinin...@gmail.com
on 21 Sep 2011 at 11:44
Вот пример того что у меня получилось в
итоге с Z-отчётом и контрольной лентой.
Original comment by svinin...@gmail.com
on 21 Sep 2011 at 12:10
Attachments:
Original issue reported on code.google.com by
svinin...@gmail.com
on 21 Sep 2011 at 5:20