dimOn писал(а):
мапинга нет, планировалось как более упрощённая схема, чем печать чеков, т.к. эта функция скорее исключение, чем правило (например, "очереди" соответственно тоже нет) это реально нужно, да?
У нас всего один ККТ, и чек ВОЗВРАТ ПРИХОДА он будет печатать на принтер на котором печатается чек ПРИХОД, то можно оставлять как есть
dimOn писал(а):
Цитата:
client.gui.cashcheck.user.bov01.checkbox.mode=on Устанавливаем печатать чек безусловно, причем данная настройка влияет как на платеж так и на расход. Не все ведь расходы надо печатать.
это да, тут косяк, про эту галку помнилось, но для скорости пока оставили. надо убрать или сделать настройку для расходов отдельно? хотя там реально on никогда не нужно вроде как. ваши предложения?
Тут получается, всегда будет вызываться addPaymentRefund, а следовательно если будет выбран тип расхода, который не нужно печатать на ККТ (обработка в дин.коде), то на ККТ ни чего отправлено не будет. А значит тоже можно оставить как есть.
dimOn писал(а):
Да, всё так, в оба метода приходит Payment , но в рефунде там данные из расхода. В явадоке по клаассу прописано это.
Он просто исторически остался так называться,не хотелось пока делать полный клон объекта с теми же полями и другим названием. Наверное, его как-то переименовать надо в идеаде. Или отнаследовать просто с переименованием пары методов.
Ну это можно просто задокументировать, чтобы у других не было вопросов.
dimOn писал(а):
(Для электронных написано, что всегда.)
Да, сейчас нет пока такого в GUI, надо по идее добавить в приход куда-то рядом со вводом суммы от клиента итд. И тогда уже передавать это в скрипт, где вы что-то сможете сделать с ним, например сделать setCustomerEmail. Вероятно, вы не совсем поняли назначение setOnlyElCheck и понятия "электронный чек". Если вы печатаете чек по галочке при добавлении прихода - вам не надо указывать setOnlyElCheck, это указание не печатать чек на бумаге! Или так можно в магазине например? Типа не печатать на бумаге, а чтобы только ушло на мыло чек и всё? Подразумевалось что это для платежей через всякие платёжные системы будет использоваться.
setCustomerEmail будет использоваться в любом случае же, это просто добавление одного атрибута, чтобы ККМ отправил его в ОФД, а ОФД отправил на мыло чек. Возможно в дополнение к бумажному.
Вот, что мне по этому поводу ответила бухгалтер.
Цитата:
Расчеты с покупателями
При расчетах с каждым покупателем кассир-операционист обязан:
– определить итоговую сумму покупки по показаниям индикатора кассовой машины и назвать ее покупателю;
– получить деньги, четко назвать их сумму и положить эти деньги отдельно на виду у покупателя;
– провести операцию через онлайн-ККТ на полученную сумму;
– назвать сумму причитающейся сдачи и выдать ее покупателю вместе с чеком или бланком строгой отчетности.
Чек или бланк строгой отчетности выдайте:
на бумажном носителе. То есть документ распечатайте на ККТ;
и (или) в электронной форме. Документ на ККТ не печатайте, а перешлите его на абонентский номер или адрес электронной почты покупателя. Это возможно, если покупатель предоставил такую информацию до момента расчета.
Если покупатель до расчета не сообщил, что ему нужен электронный чек, вы не обязаны его оформлять.
Это следует из статьи 1.2, пункта 2 статьи 5 Закона от 22 мая 2003 г. № 54-ФЗ, пункта 4.1 Типовых правил, утвержденных письмом Минфина России от 30 августа 1993 г. № 104, пункта 5 протокола Минфина России от 24 ноября 2016 № 10.
Т.е получается печать электронного чека и|или. В принципе, если в карточке договора указан email для чеков, то можно дублировать его туда. А сейчас динкод это позволяет )
_________________
Код:
Клиент: вер. 6.2.874 / 05.02.2018 12:48:36
os: Windows 7; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_151
Сервер: вер. 6.2.1203 / 05.02.2018 12:50:34
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45