BiTel

Доброе утро.
Как можно в чеке выставить признак безналичного платежа ?
И еще связанный с этим вопрос - как можно при оплате через модуль MPS Сбербанк и через модуль Альфабанк "вытащить" email и телефон плательщика ?

https://docs.bitel.ru/pages/viewpage.ac ... d=43386469

откуда вытащить?

_________________
I'm clever. I've got a computer.

email и телефон через MPS никак - сбер его не передаёт вроде. Альфа наверное тоже.

Из API как я понимаю, можно как то его найти если в lk передавался email ?
Номер телефона как я понимаю можно взять только из параметров договора ?

очень жаль...

Хотя, если там отдельный модуль Альфабанк, то надо смотреть

то что вы вводите в ЛК биллинга при оплате в модулях которые там работают - можно вытащить.
в mps нельзя, ничего сюда не передаётся (обычно).
брать только из договора соответствующего на своей стороне уже.

_________________
I'm clever. I've got a computer.

каким методом можно достать email при его вводе в ЛК не подскажете ?
и есть ли аналог для установки телефона в чеке, чтобы ОФД отправил чек по СМС наподобие check.setCustomerEmail() ?

Появился еще один вопрос.
Я пишу функцию для отложенных чеков таким образом

@Override
public void addPaymentAutoDelay(Payment payment, Check check, Printer printer)
throws BGException
{
check.addPayment( payment.getSumma(), "Услуги связи", 0 );

и получаю ошибку

method does not override or implement a method from a supertype /usr/local/BGBillingServer/dyn/ru/bitel/bgbilling/cashcheck/VgtCheck.java

Хелп плиз) Версия сервера 7.1.1087

телефон ставится этим же методом, ККТ их не различает и в ФФД тег один и тот же для них. офд шлёт дальше либо мыло либо смс как у них настроено и как договоритесь
на самом деле он называется CustomerAddress.

_________________
I'm clever. I've got a computer.

наверное у вас просто плагин слишком старый и там нет в базовом классе addPaymentAutoDelay просто напросто, потому предупреждает про @Override.
это было не очень давно реализовано.

_________________
I'm clever. I've got a computer.

import static ru.bitel.bgbilling.common.bean.BGBaseConstants.KEY_CUSTOMER_ADDRESS;
import ru.bitel.bgbilling.kernel.contract.config.server.bean.ContractModuleConfigDao;

ContractModuleConfigDao contractModuleConfigDao = new ContractModuleConfigDao( con, MID );
String customerEmail = contractModuleConfigDao.get( contract.getId(), KEY_CUSTOMER_ADDRESS );
contractModuleConfigDao.close();

_________________
I'm clever. I've got a computer.

Так и есть - после обновления плагина на оверрайд перестал ругаться. Функция заработала. Спасибо

Написали вот так

@Override
public void addPaymentAuto(Payment payment, Check check, Printer printer)
throws BGException
{
// обработка автопечатаемых платежей
int cid = payment.getContractId();
ContractManager cm = new ContractManager(con) ;
Contract ct = cm.getContractById(cid);
int fc = ct.getFc();
if(fc == 0) {
check.addString("fizik");
check.setCashierName("Администратор");
check.addPayment( payment.getSumma(), "Услуги связи", 0 );
check.addString( payment.getContractTitle() + " " + payment.getContractComment() );
check.setPaymentType(2); //установим тип платежа ККМ Безнал
check.setTax(1);
}

}

Задача печатать чек для физиков - и для них все нормально печатается. Для юриков же мы не хотим печатать чек для автоплатежа в принципе. Когда делаем платеж по юрику, касса подает сигнал, чек не выходит а кэшчек сервер выводит следующую ошибку:

22.03.2019 09:35:30,346 DEBUG [main] CmdTcpServer:197 - server: connection accepted #6: Socket[addr=/89.19.193.10,port=52163,localport=9876]
22.03.2019 09:35:30,346 TRACE [thread#6] CmdTcpServer:329 - thread#6: <- COMMAND
22.03.2019 09:35:30,405 TRACE [thread#6] CmdTcpServer:329 - thread#6: <- 39384204717666554600061837182819
22.03.2019 09:35:30,405 TRACE [thread#6] CmdTcpServer:329 - thread#6: <- check
22.03.2019 09:35:30,405 DEBUG [thread#6] CmdTcpServer:401 - thread#6: try 'check' command…
22.03.2019 09:35:30,405 TRACE [thread#6] CmdTcpServer:329 - thread#6: <- 30
22.03.2019 09:35:30,405 TRACE [thread#6] CmdTcpServer:329 - thread#6: <- 0
22.03.2019 09:35:30,405 TRACE [thread#6] CmdTcpServer:329 - thread#6: <- CHECKTYPE
22.03.2019 09:35:30,405 TRACE [thread#6] CmdTcpServer:329 - thread#6: <- PAYMENT
22.03.2019 09:35:30,405 TRACE [thread#6] CmdTcpServer:329 - thread#6: <-
22.03.2019 09:35:30,405 TRACE [thread#6] CmdTcpServer:329 - thread#6: <- ENDCOMMAND
22.03.2019 09:35:30,405 TRACE [thread#6] CmdTcpServer:342 - thread#6: -> ECHO
22.03.2019 09:35:30,405 TRACE [thread#6] CmdTcpServer:342 - thread#6: -> 39384204717666554600061837182819
22.03.2019 09:35:30,405 DEBUG [thread#6] Driver:470 - Driver: CHECK TYPE: PAYMENT
22.03.2019 09:35:30,405 DEBUG [thread#6] Driver:429 - Driver: check/checkreturn(clientsumma=0,type=1):
22.03.2019 09:35:30,407 TRACE [thread#6] Driver:1652 - shtrih2-driver: _transferPacket: send ENQ
22.03.2019 09:35:30,407 TRACE [thread#6] Driver:1652 - shtrih2-driver: _transferPacket: set timeout 10000
22.03.2019 09:35:30,415 TRACE [thread#6] Driver:1652 - shtrih2-driver: _transferPacket: getted NAK
22.03.2019 09:35:30,415 TRACE [thread#6] Driver:1652 - shtrih2-driver: try getStatusShort()
22.03.2019 09:35:30,415 TRACE [thread#6] Driver:1652 - shtrih2-driver: SEND (full packet): 02 05 10 1E 00 00 00 0B
22.03.2019 09:35:30,415 TRACE [thread#6] Driver:1652 - shtrih2-driver: _transferPacket: send ENQ
22.03.2019 09:35:30,415 TRACE [thread#6] Driver:1652 - shtrih2-driver: _transferPacket: set timeout 10000
22.03.2019 09:35:30,424 TRACE [thread#6] Driver:1652 - shtrih2-driver: _transferPacket: getted NAK
22.03.2019 09:35:30,424 TRACE [thread#6] Driver:1652 - shtrih2-driver: _transferPacket: send packet
22.03.2019 09:35:30,424 TRACE [thread#6] Driver:1652 - shtrih2-driver: _transferPacket: set timeout 1000
22.03.2019 09:35:30,487 TRACE [thread#6] Driver:1652 - shtrih2-driver: _transferPacket: getted ACK, ok!
22.03.2019 09:35:30,487 TRACE [thread#6] Driver:1652 - shtrih2-driver: _readSTX: set timeout 120000
22.03.2019 09:35:30,487 TRACE [thread#6] Driver:1652 - shtrih2-driver: _readSTX: ok read STX-byte
22.03.2019 09:35:30,487 TRACE [thread#6] Driver:1652 - shtrih2-driver: _readSTX: ok read len=16
22.03.2019 09:35:30,487 TRACE [thread#6] Driver:1652 - shtrih2-driver: _readSTX: set timeout 1000
22.03.2019 09:35:30,487 TRACE [thread#6] Driver:1652 - shtrih2-driver: _readSTX: ok read body 10 00 1E 92 02 02 00 00 A0 47 19 01 00 61 08 00
22.03.2019 09:35:30,487 TRACE [thread#6] Driver:1652 - shtrih2-driver: _readSTX: ok read lrc
22.03.2019 09:35:30,487 TRACE [thread#6] Driver:1652 - shtrih2-driver: _readSTX: RECV (full): 02|10|10 00 1E 92 02 02 00 00 A0 47 19 01 00 61 08 00|1A
22.03.2019 09:35:30,487 TRACE [thread#6] Driver:1652 - shtrih2-driver: _transferPacket: ok, send ACK
22.03.2019 09:35:30,488 TRACE [thread#6] Driver:1652 - shtrih2-driver: RECV (packet body): 10 00 1E 92 02 02 00 00 A0 47 19 01 00 61 08 00
22.03.2019 09:35:30,488 TRACE [thread#6] Driver:1652 - shtrih2-driver: try closeCheck(0,0,0,0,0,"",0,0,0,0)
22.03.2019 09:35:30,488 TRACE [thread#6] Driver:1652 - shtrih2-driver: SEND (full packet): 02 47 85 1E 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 DC
22.03.2019 09:35:30,488 TRACE [thread#6] Driver:1652 - shtrih2-driver: _transferPacket: send ENQ
22.03.2019 09:35:30,488 TRACE [thread#6] Driver:1652 - shtrih2-driver: _transferPacket: set timeout 10000
22.03.2019 09:35:30,498 TRACE [thread#6] Driver:1652 - shtrih2-driver: _transferPacket: getted NAK
22.03.2019 09:35:30,498 TRACE [thread#6] Driver:1652 - shtrih2-driver: _transferPacket: send packet
22.03.2019 09:35:30,630 TRACE [thread#6] Driver:1652 - shtrih2-driver: _transferPacket: set timeout 1000
22.03.2019 09:35:30,669 TRACE [thread#6] Driver:1652 - shtrih2-driver: _transferPacket: getted ACK, ok!
22.03.2019 09:35:30,669 TRACE [thread#6] Driver:1652 - shtrih2-driver: _readSTX: set timeout 120000
22.03.2019 09:35:30,669 TRACE [thread#6] Driver:1652 - shtrih2-driver: _readSTX: ok read STX-byte
22.03.2019 09:35:30,670 TRACE [thread#6] Driver:1652 - shtrih2-driver: _readSTX: ok read len=2
22.03.2019 09:35:30,670 TRACE [thread#6] Driver:1652 - shtrih2-driver: _readSTX: set timeout 1000
22.03.2019 09:35:30,670 TRACE [thread#6] Driver:1652 - shtrih2-driver: _readSTX: ok read body 85 73
22.03.2019 09:35:30,671 TRACE [thread#6] Driver:1652 - shtrih2-driver: _readSTX: ok read lrc
22.03.2019 09:35:30,671 TRACE [thread#6] Driver:1652 - shtrih2-driver: _readSTX: RECV (full): 02|02|85 73|F4
22.03.2019 09:35:30,671 TRACE [thread#6] Driver:1652 - shtrih2-driver: _transferPacket: ok, send ACK
22.03.2019 09:35:30,672 TRACE [thread#6] Driver:1652 - shtrih2-driver: RECV (packet body): 85 73
22.03.2019 09:35:30,675 TRACE [thread#6] CmdTcpServer:342 - thread#6: -> ERROR
22.03.2019 09:35:30,677 DEBUG [thread#6] CmdTcpServer:482 - thread#6: frk error
ru.bitel.frk.driver.shtrih2.PrinterShtrihErrorException: #115: Команда не поддерживается в данном режиме (ФР)
at ru.bitel.frk.driver.shtrih2.ShtrihFRKPrinter.a(SourceFile:286)
at ru.bitel.frk.driver.shtrih2.ShtrihFRKPrinter.closeCheck(SourceFile:1213)
at ru.bitel.frk.driver.shtrih2.Driver._check(SourceFile:515)
at ru.bitel.frk.driver.shtrih2.Driver.check(SourceFile:535)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at ru.bitel.frk.server.CmdTcpServer.run(SourceFile:453)
22.03.2019 09:35:30,683 WARN [thread#6] CmdTcpServer:492 - thread#6: send error driver: #115: Команда не поддерживается в данном режиме (ФР)
22.03.2019 09:35:30,683 TRACE [thread#6] CmdTcpServer:342 - thread#6: -> #115: Команда не поддерживается в данном режиме (ФР)
22.03.2019 09:35:30,684 TRACE [thread#6] CmdTcpServer:342 - thread#6: -> ENDECHO
22.03.2019 09:35:30,684 DEBUG [thread#6] CmdTcpServer:502 - thread#6: command 'check' processing sucessfull
22.03.2019 09:35:30,686 TRACE [thread#6] CmdTcpServer:329 - thread#6: <- <EOF>
22.03.2019 09:35:30,686 DEBUG [thread#6] CmdTcpServer:504 - thread#6: end all commands
22.03.2019 09:35:30,686 DEBUG [thread#6] CmdTcpServer:530 - thread#6: close socket


Хоть чек и не печатается как мы и хотим, но ошибка это неправильно. Что лучше написать для условия fc==1 ?

ну если замаплено на тип, то уйдёт на печать. а в скрипте ничего не сделано было потому ККТ ругнулся на попытку закрыть чек.
штатно ничего такого нет на этот счёт - взять и отменить печать среди скрипта, предусматривалось что рулится разными типами платежей, тут надо подумать, это не так просто как кажется.
если бросить в скрипте BGException то на сервер печати не уйдёт , это предусмотрено, но будет ошибка в логе на стороне сервера биллинга типа скрипт ругнулся.

_________________
I'm clever. I've got a computer.

обратите внимание, что основная сложность то тут не в том, чтобы на печать не отправить (это как-то можно придумать как прервать и логи не загадить), а в том что эти платежи не попадут в лог печати => навечно останутся в "очереди", потому что "очередь" определяется типами платежей. что не есть хорошо кагбэ. плюс и delay-платежи и задачи допечати ошибочных auto-платежей будут считать их готовыми для печати и печатать заново.

потому надо костылить какой-то механизм, типа "не напечатано но и не собирались" уже вне типов платежей. это дурацкая схема на первый взгляд.

либо делать костыль который сломает всю эту схему и сделает вид что чек реально был напечатан, но тогда он будет светиться в логах что чек как будто напечатан на таком-то ККТ на такую-то сумму, хотя он там не был напечатан. что нелогично, потому тоже не штатно это делать надо.

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

либо сделать в сервере печати чтобы молча пустые чеки не печатал и всё. тогда в биллинге будет отмечено что он напечатан, в а логах сервера печати что проигнорировано. но это тоже очень плохо, т.к. допускает до работы сильно потенциально ошибочные скрипты которые формируют чеки без позиций.

_________________
I'm clever. I've got a computer.

У нас платежи Сбербанк Онлайн кидают как на физиков так и на юриков. Как можно развести их на разные типы платежей ?
Ошибка на стороне биллинга тоже не выход конечно.
Может вы доработаете API для таких случаев ?
Условий для формирования или не формирования отчетности может быть много, нормы меняются в процессе времени...

договоры на физиков и на юриков у вас никак не различаются шаблонами итд?
можно же два поиска настроить просто в mps, или вас устраивает что типы платежей у них одинаковые?

это уже в любом случае через HD, и это версия 7.1+ или 7.2+, и на данный момент неизвестно как это сделать вообще правильнее.
либо серьёзно переделывать архитектуру плагина и понятие очереди (что вообще не хочется трогать), либо у вас они будут светиться в логе как напечатанные среди всех других чеков уже реально напечатанных, а с учётом что у них даже тип платежей точно такой же.... вам это точно удобно будет?
разделять в очереди/логе их как? я выше предложил через отправку их на фейковый ККТ. тогда и в логе вы их будете видеть - какие-то ушли на реальный, а какие-то на фейковый.
сейчас для этого придётся второй сервер печати поднять с драйвером-эмулятором.

_________________
I'm clever. I've got a computer.

ещё теоретически можно сделать понятие фейкового ККТ на стороне самого плагина. вместо ип+порта пишете fake и плагин как бы никуда не шлёт и всё.
в скрипте можно выбрать (т.е. "перетереть дефолтный маппинг") на какой ККТ печатать.
тогда и в логе будет нормально всё видно - какие чеки куда попали и всё законно будет работать везде. в общем это в HD

_________________
I'm clever. I've got a computer.

"договоры на физиков и на юриков у вас никак не различаются шаблонами итд?
можно же два поиска настроить просто в mps, или вас устраивает что типы платежей у них одинаковые?" - конечно шаблоны для юриков и физиков разные, до настоящего момента устраивало, что тип платежей для юриков и физиков один. Но если возможно настроить в модуле mps для одной платежной системы два разных поиска, то думаю это будет лучшее решение.
У нас сейчас такой конфиг модуля mps:
mps.1.mode=1
mps.1.title=Сбербанк
mps.1.protocol=sbrf
mps.1.login=ХХХ
mps.1.passw=ХХХ
mps.1.pid=14
#Поиск по номеру договора
mps.1.search.mode=parameter
mps.1.search.pid=56
mps.1.protocol.ext=addBalanceInfo
mps.1.param.keys=fio,address
mps.1.fio=27
mps.1.address=16
mps.1.response.encoding=utf8
Если добавить в поиск параметр mps.1.search.allow.contract.groups= и указать ID групп физ. договоров, то поиск будет осуществлять только в группах физ.договоров.
А как настроить поиск для юр. лиц? ведь для них должен быть другой код типа платежа? (mps.1.pid=20)

другой тип платежа можно настроить только на другую ПС т.е. настроить клон того что есть у вас mps.2.* итд. но в таком случае будет немного другой url и сбер не будет вам их делить же на два урла

_________________
I'm clever. I've got a computer.

в общем мы тут посоветовались и придумали такой вариант: в дин.коде обработки платежа и формирования чека проверяете физик или юрик. если это (например) юрик то меняете тип платежа и пересохраняете и игнорируте этот чек (отмену печати молча можно сделать что-нибудь придумаем). в итоге и чек не напечатан и в очереди он мелькать не будет, т.к. тип платежа сменился и на него никакого маппинга не настроено.

либо второй допустимый вариант: делаем всё же возможность фейкового сервера печати и в логи будут попадать как отпечатанные на фейковом "нигде". а в скрипте будете проверять юрик/физик и менять ККТ.
этот вариант как-то чище выглядит. но в первом варианте разные типы платежей в итоге, если это реально нужно (но как-то костыльно , имхо).

_________________
I'm clever. I've got a computer.

только взялся такой вопрос: а как у вас юрики попадают в MPS то тогда? и почему на них не надо печатать чек, если это сбер.онлайн какой-нибудь , они налом чтоли платят?
или там отдельная система и тогда отдельный url можно указать?

_________________
I'm clever. I've got a computer.

"только взялся такой вопрос: а как у вас юрики попадают в MPS то тогда? и почему на них не надо печатать чек, если это сбер.онлайн какой-нибудь , они налом чтоли платят?
или там отдельная система и тогда отдельный url можно указать?"
Есть порядка пяти юриков которые почему то платят с карты физ.лица со сбер.онлайн. Не знаю почему им так удобнее.
Если в конфиге модуля mps использовать mps.1.search.allow.contract.groups= с ID физических групп договоров, то биллинг не даст оплатить на юридические договора. попробую поговорить с бухгалтерией, возможно это выход.
у нас 15 групп договоров для физиков, сколько можно указать в позиции mps.1.search.allow.contract.groups?

отдельной системы нет

Варианты с костылями не особенно вдохновляют)) плагин CashCheck и так достаточно сложный, пока трудно предугадать где эти костыли могут аукнуться в будущем)

ну то что я предложил второй вариант как раз не очень костыль.
и логи будут попыток печати, как следствие в очереди не будут, и ошибок не будет, и напечатано не будет. но это просто упрощение варианта предложенного ещё выше (т.е. вы можете уже сейчас просто второй экземпляр сервера печати пустой настроить и туда отправлять ненужные чеки - это на данный момент самое некостыльное решение)

_________________
I'm clever. I've got a computer.

ну я думаю хоть сколько можно указать в mps.1.search.allow.contract.groups...

_________________
I'm clever. I've got a computer.

в рамках разработки настройки альтернативных фискализаторов помимо "сервера печати" (типа атол-онлайн итд) заодно получились и фейковые фискализаторы.
вскоре будет доступно в 7.0+, т.е. можно будет настроить пустой и просто туда сливать ненужные платежи. при этом оно нормально отметится везде и залогируется.

_________________
I'm clever. I've got a computer.