BiTel

Форум BiTel
bgbilling.ru     docs.bitel.ru     wiki.bitel.ru     dbinfo.bitel.ru     bgcrm.ru     billing.bitel.ru     bitel.ru    
Текущее время: 28 ноя 2021, 19:58

Часовой пояс: UTC + 5 часов [ Летнее время ]




Начать новую тему Ответить на тему  [ Сообщений: 33 ]  На страницу 1, 2  След.
Автор Сообщение
СообщениеДобавлено: 21 июн 2019, 18:50 
Не в сети

Зарегистрирован: 20 окт 2016, 00:34
Сообщения: 82
Карма: 0
Добрый день.
К сожалению ни в документации, ни на форуме не нашёл решения (может плохо искал).
Некоторые платежи с режимом auto не ушли в atolonline по таймауту соединения,
пытаюсь напечатать из очереди получаю ошибку вида:

"Платёж #6983016 (тип 58) настроен на регистратор #15, но в авторежиме (режим: auto)"

Очевидно должен быть способ пропихнуть их, но вот как это сделать не найду.
Подскажите, как побороть проблему?

P.S.: режим печати auto, без delay если это существенно.

ru.bitel.bgbilling.plugins.cashcheck: вер. 7.1.133 / 03.06.2019 18:24:13

_________________
Клиент: вер. 7.1.206 / 15.08.2019 22:37:24
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_181
Сервер: вер. 7.1.1144 / 15.08.2019 22:39:22
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_181


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 22 июн 2019, 00:42 
Не в сети
Аватара пользователя

Зарегистрирован: 30 май 2008, 15:51
Сообщения: 6051
Карма: 244
штатно такого способа нет в данный момент
вы хотите по одному вручную печатать кнопокй? тогда можно просто проверку эту убрать .
по-хорошему надо задачу настраивать допечати ошибочных платежей, но с атолонлайном она не работает, в пн. напомните

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 24 июн 2019, 12:57 
Не в сети

Зарегистрирован: 20 окт 2016, 00:34
Сообщения: 82
Карма: 0
Конечно хотелось бы с помощью задачи, кто его знает сколько их по тому же таймауту может не уйти сразу.
Вопрос очень актуален особенно в виду приближающегося 1 июля :-)

_________________
Клиент: вер. 7.1.206 / 15.08.2019 22:37:24
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_181
Сервер: вер. 7.1.1144 / 15.08.2019 22:39:22
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_181


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 24 июн 2019, 13:36 
Не в сети
Аватара пользователя

Зарегистрирован: 30 май 2008, 15:51
Сообщения: 6051
Карма: 244
тут дело такое.... не очень давно сделано что для автоплатежей все такие ошибки регистрируются в логе (со статусом, текстом ошибки итд), то есть они не остаются в очереди в вашем случае.
и задача должна работать с логом.
в очереди наверно пока тогда кнопку надо сделать чтобы работала как положено для всех типов и ручных и авто итд.
у вас их сейчас много?

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 24 июн 2019, 14:40 
Не в сети

Зарегистрирован: 20 окт 2016, 00:34
Сообщения: 82
Карма: 0
В очереди то их много.
Тут дело такое что, как я понял, как только на тип платежа вешается auto, то в очереди отображаются все платежи данного типа,
даже за прошлые месяцы, когда и речь ещё не шла про atolonline.

Т.о. чтобы понять как это теперь с логом (регистрация ошибок), мне нужно срочно обновить хотя бы плагин cashcheck?
За июнь, как я понимаю, можно пока не переживать, санкции за неотправку данных будут только с июля.
Конечно проверку на auto можно было бы убрать (если это не грозит другими проблемами).

Вопросы получаются следующие:
1) если я из кода пробегусь по очереди и сделаю программную печать в атолонлайн, то по идее застрявшие должны уйти?
2) будет ли задача в итоге работать с логом для допечатки не прошедших платежей?

_________________
Клиент: вер. 7.1.206 / 15.08.2019 22:37:24
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_181
Сервер: вер. 7.1.1144 / 15.08.2019 22:39:22
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_181


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 24 июн 2019, 14:51 
Не в сети
Аватара пользователя

Зарегистрирован: 30 май 2008, 15:51
Сообщения: 6051
Карма: 244
как только тип платежа вешается на любой маппинг то они все появляются в "очереди", всё верно. чтобы отрезать очередь снизу есть параметр:

# начало фискализации, чтобы отсечь очередь чеков от старых платежей тех же типов
fiscal.start=01.09.2017

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 24 июн 2019, 15:45 
Не в сети

Зарегистрирован: 20 окт 2016, 00:34
Сообщения: 82
Карма: 0
Ясно. Спасибо.
Тогда сейчас обновлю плагин до самого актуального, посмотрю как это теперь с логом, и буду ждать нового обновления с задачей.

P.S.:
Задача проверки статусов настройки не требует (кроме той что в плагине)?

_________________
Клиент: вер. 7.1.206 / 15.08.2019 22:37:24
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_181
Сервер: вер. 7.1.1144 / 15.08.2019 22:39:22
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_181


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 24 июн 2019, 17:25 
Не в сети
Аватара пользователя

Зарегистрирован: 30 май 2008, 15:51
Сообщения: 6051
Карма: 244
лучше дождитесь кнопки, чтобы из очереди тоже можно было отправить на печать.

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 24 июн 2019, 19:08 
Не в сети
Аватара пользователя

Зарегистрирован: 30 май 2008, 15:51
Сообщения: 6051
Карма: 244
7.1 выложено
можете выделить из очереди и отпечатать, после этого они уже попадут в лог
учтите что сейчас оно синхронно печатается из сервера (потом скорее всего в задачу переместится), и клиент будет отвисать если кучу выберете, так что лучше партиями наверное

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 24 июн 2019, 21:35 
Не в сети

Зарегистрирован: 20 окт 2016, 00:34
Сообщения: 82
Карма: 0
Спасибо. Отпечатал. Правда 5 штук из них выдало после проверки статуса ошибку:

"Ошибка АТОЛ-Онлайн: Таймаут сообщения в очереди
Дополнительно: code: 1, type: timeout, http: -, id: [none]"

но это уже отдельно посмотрю.

Тут дополнительная проблема возникла - исторически уже n-лет как сложилось,
что некоторые платежи (безразлично online или нет при определённых условиях разбивались на 2 чтобы гасить долг на независимом субе (так требует логика)),
при этом оригинальный платёж соответственно удаляется... Соответственно, в модуле платёжных систем то он виден, но вот в логе cashcheck уже нет,
ну и проверка при этом естественно не возможна.
Возможно ли что-то придумать для хранения оригинальных платежей и по флагу подтягивания их в cashcheck.
Понимаю что это определённо в HD и за плату. Вопрос сейчас именно в реалистичности решения.

_________________
Клиент: вер. 7.1.206 / 15.08.2019 22:37:24
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_181
Сервер: вер. 7.1.1144 / 15.08.2019 22:39:22
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_181


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 24 июн 2019, 21:59 
Не в сети
Аватара пользователя

Зарегистрирован: 30 май 2008, 15:51
Сообщения: 6051
Карма: 244
таймаут сообщения - это вернулось из атола самого, т.е. ошибка на той стороне. предполагаю потому что кучей оно ушло и там столпились на ККТ. а после какого-то времени (настраивается там?) оно выкидывается из очереди.
с всем этим пока непонятно как быть, ну видимо перепечатывать из лога...

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 24 июн 2019, 22:03 
Не в сети
Аватара пользователя

Зарегистрирован: 30 май 2008, 15:51
Сообщения: 6051
Карма: 244
Цитата:
Тут дополнительная проблема возникла - исторически уже n-лет как сложилось,
что некоторые платежи (безразлично online или нет при определённых условиях разбивались на 2 чтобы гасить долг на независимом субе (так требует логика)),
при этом оригинальный платёж соответственно удаляется... Соответственно, в модуле платёжных систем то он виден, но вот в логе cashcheck уже нет,
ну и проверка при этом естественно не возможна.
Возможно ли что-то придумать для хранения оригинальных платежей и по флагу подтягивания их в cashcheck.
Понимаю что это определённо в HD и за плату. Вопрос сейчас именно в реалистичности решения.

с этим непонятно, а как он виден в модуле платёжных систем? если платёж физически удалён. что именно там видно?
ну тут идея такова, что отдельно не хранятся платежи в плагине, id в логе соответствует ид платежа как one-2-one.
если платёж физически удалён, то как быть то?

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 24 июн 2019, 22:08 
Не в сети
Аватара пользователя

Зарегистрирован: 30 май 2008, 15:51
Сообщения: 6051
Карма: 244
в принципе физически оно из лога так-то не удаляется как раз, почти нигде нет связности на уровне БД, так что скорее всего id там остаётся, ну в смысле запись сама.
просто не вытягивается для показа, т.к. половины информации нет и считается что платежа просто нету.
можете этот факт проверить для таких платежей?

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 24 июн 2019, 22:10 
Не в сети
Аватара пользователя

Зарегистрирован: 30 май 2008, 15:51
Сообщения: 6051
Карма: 244
но в принципе правильно будет чтобы они отображались, а то получается удаляется платёж а чеки тоже не увидишь уже, хотя чеки тут ни при чём вроде как, это просто лог чеков а не лог платежей. просто эти записи сильно неполноценные получаются... но часть инфы - дата, сумма, ответы, ошибки видно будет, да.
но вот чтобы статусы итд запрашивались - это намного сложнее

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 24 июн 2019, 23:35 
Не в сети

Зарегистрирован: 20 окт 2016, 00:34
Сообщения: 82
Карма: 0
С атолом разбираться буду, т.к. платежи не пачкой отправлял.

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

А вот в cashcheck уже разваливается. При чём платёж собственно отправляется в атолонлайн,
а потом уже получается отрабатывает скрипт на договоре, который разносит платёж и удаляет оригинал.
Да, чтобы сохранить инфу о платеже для проверки чека тут видится только с помощью какой-то избыточности.
Давайте я завтра в HD отпишусь.

_________________
Клиент: вер. 7.1.206 / 15.08.2019 22:37:24
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_181
Сервер: вер. 7.1.1144 / 15.08.2019 22:39:22
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_181


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 25 июн 2019, 01:51 
Не в сети
Аватара пользователя

Зарегистрирован: 30 май 2008, 15:51
Сообщения: 6051
Карма: 244
вряд ли ради этой специфической задачи с удалением платежей итд будет переписана текущая архитектура cashcheck, в лучшем случае для отображения можно сделать. либо нагородить костылей которые в любом случае не будут работать, например, с delay-платежами.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 27 июн 2019, 19:00 
Не в сети

Зарегистрирован: 20 окт 2016, 00:34
Сообщения: 82
Карма: 0
Апну тему. Т.к. задача печати из лога чеков с ошибками актуальна.
Пару дней назад произошла трабла с доступом к dns в результате unknow host exception,
а т.к. теперь они не остаются в очереди и из лога их напечатать нельзя.
Потому хочется задачу для повторной отправки.

Если я пройдусь программно по таблице логов с ошибками и попытаюсь их перепечатать
что произойдёт?
Т.е. собственно вопрос, можно ли делать для ошибочных
Check check = new Check() и далее печатать их из кода?
Не приведёт ли это к созданию ещё одной записи о печати чека в логе а не к обновлению текущей?

_________________
Клиент: вер. 7.1.206 / 15.08.2019 22:37:24
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_181
Сервер: вер. 7.1.1144 / 15.08.2019 22:39:22
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_181


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 27 июн 2019, 19:06 
Не в сети
Аватара пользователя

Зарегистрирован: 30 май 2008, 15:51
Сообщения: 6051
Карма: 244
там по идее ид платежа примари кей, потому дубля для одного платежа не должно быть, но текущий код скорее всего просто упадёт там, надо проверять...
хотя смотря на каком уровне вы хотите сделать это...
также там надо затереть старую ошибку итд, такого когда там просто нет пока. постараемся в ближайшее время доделать

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 27 июн 2019, 20:45 
Не в сети

Зарегистрирован: 20 окт 2016, 00:34
Сообщения: 82
Карма: 0
Нарисовал что-то такое:
Код:
    private PreparedStatement ps;
    private final static ServerContext context = ServerContext.get();
    private final static String GET_CHECK_EMAIL_QUERY = "SELECT email FROM contract_parameter_type_3 WHERE 1=1 AND pid=183 AND email LIKE '%@%' AND cid=? LIMIT 1";
    private final static String DEF_EMAIL = "xxx@xxx.ru";
   
    private ContractDao cDao;
   
    private final static Logger logger = Logger.getLogger( RePrintErrors.class );
   
    @Override
    public void execute(Setup setup, ConnectionSet connectionSet) throws Exception {
        Connection con = connectionSet.getConnection();
        init( con );
        doWork( con );
        close();
    }
   
    private void doWork(Connection con) throws SQLException, BGException {
        Printer printer = null;
        ResultSet rs = ps.executeQuery();
        while( rs.next() ) {
            int paymentId = rs.getInt( "payment_id" );
            BigDecimal sum = rs.getBigDecimal( "summa" );
            if( sum == null ) {
                logger.error( "payment sum not found for payment.id: " + paymentId );
                continue;
            }
            //
            int contractId = rs.getInt( "cid" );
            Contract c = getContract( contractId );
            if( c == null ) {
                logger.error( "contract not found for contract.id: " + contractId );
                continue;
            }
            //
            int posId = rs.getInt( "pos_id" );
            printer = CashCheckUtils.getPrinter( posId );
            if( printer == null ) {
                logger.error( "printer not found for payment.id: " + paymentId + " printer.id: " + posId );
                continue;
            }

            String email = getEmail( contractId );
            //
            Check check = new Check( Check.Type.PAYMENT );
            check.setDocumentId( paymentId );
            check.setDocumentDate( rs.getDate( "dt" ) );
            check.addPayment( sum, "Оплата услуг по договору " + c.getTitle(), 0 );
            check.setTax( -1 );
            check.setPaymentType( 1 );
            check.setCustomerEmail( email );
            //
            CashCheckUtils.printCheck( check, printer, 0, con, paymentId, "auto" );
            //
            logger.info( "reprinted check, payment.id: " + paymentId + " pos: " + posId );
        }
        PsUtils.closeRS( rs );
    }
   
    private Contract getContract(int contractId) {
       // ...
    }
   
    private String getEmail(int contractId) {
     //...
    }   
   
    private void init(Connection con) throws SQLException, SQLException {
        StringBuilder sb = new StringBuilder();
        sb.append( "SELECT DISTINCT pl.payment_id, pl.pos_id, (CASE WHEN cp.summa IS NOT NULL THEN cp.summa ELSE cop.summa END) summa, \n" );
        sb.append( "       (CASE WHEN cp.cid IS NOT NULL THEN cp.cid ELSE cop.cid END) cid, \n" );
        sb.append( "       (CASE WHEN cp.dt IS NOT NULL THEN cp.dt ELSE cop.dt END) dt, \n" );
        sb.append( "       (CASE WHEN cp.lm IS NOT NULL THEN cp.lm ELSE cop.lm END) lm FROM cashcheck_payment_log pl \n " );       
        sb.append( "  LEFT JOIN contract_payment cp \n" );
        sb.append( "     ON pl.payment_id=cp.id \n" );
        sb.append( "  LEFT JOIN contract_original_payment cop \n" ); // for deleted payments
        sb.append( "     ON pl.payment_id=cop.id \n" );
        sb.append( " WHERE 1=1 \n" );
        sb.append( "   AND pl.pos_mapping LIKE '%auto%' \n" );
        sb.append( "   AND pl.check_type LIKE '%PAYMENT%' \n" );
        sb.append( "   AND pl.last_error IS NOT NULL \n" );
        sb.append( "   AND pl.fiscal_data IS NULL \n" );
        sb.append( "   AND pl.last_error LIKE '%error%' " ); // for test
        //
        logger.info( sb.toString() ); // dbg
        //
        ps = con.prepareStatement( sb.toString() );
        //
        cDao = cDao = new ContractDao( con, 0 );
    }
   
    private void close() throws SQLException, BGException {
        cDao.close();
        PsUtils.closePS( ps );
    }



Пока честно не запускал, вдруг вы скажете что такой подход всё развалит.
Вроде CashCheckUtils.printCheck() вызывает PaymentQueueManager(con).updatePaymentLog
который в свою очередь делает REPLACE INTO `cashcheck_payment_log` ...
по идее должна перетереться старая запись, но вдруг для корректности нужны дополнительные
манипуляции.

_________________
Клиент: вер. 7.1.206 / 15.08.2019 22:37:24
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_181
Сервер: вер. 7.1.1144 / 15.08.2019 22:39:22
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_181


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 27 июн 2019, 23:57 
Не в сети
Аватара пользователя

Зарегистрирован: 30 май 2008, 15:51
Сообщения: 6051
Карма: 244
Я помню что там специально REPLACE INTO но я не знаю как в реальности подобный код работать будет, потому и писал "проверять надо"

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 09 июл 2019, 14:04 
Не в сети

Зарегистрирован: 20 окт 2016, 00:34
Сообщения: 82
Карма: 0
Апну. Т.к. задача на переотправку ошибочных чеков из лога всё более актуальна.
Вчера с Атолом-онлайн были траблы и теперь в логе они висят с ошибками, а т.п. атола пишет

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

Нельзя ли сделать из задачи проверки статуса updatePaymentLastError не по payment.id, а по pendingId, а то ошибка для удалённого платежа не фиксируется в логе хотя статус его проверяется :-(
Ключ по полю pending_id вроде как есть. Другим же хуже от этого не будет.

_________________
Клиент: вер. 7.1.206 / 15.08.2019 22:37:24
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_181
Сервер: вер. 7.1.1144 / 15.08.2019 22:39:22
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_181


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 12 июл 2019, 14:30 
Не в сети
Аватара пользователя

Зарегистрирован: 30 май 2008, 15:51
Сообщения: 6051
Карма: 244
а это не с вами обсуждали в HD этот вопрос? видимо external_id правильнее брать не ид платежа, а просто сиквенс растущий.

Цитата:
Нельзя ли сделать из задачи проверки статуса updatePaymentLastError не по payment.id, а по pendingId, а то ошибка для удалённого платежа не фиксируется в логе хотя статус его проверяется :-(
Ключ по полю pending_id вроде как есть. Другим же хуже от этого не будет.

ну пока могу посоветовать
public Payment getPaymentFromPendingId(String pendingId) лежащий рядом и дальше уже Payment.id + updatePaymentLastError
скорее всего так и придётся делать всегда, т.к. updatePaymentLastError задуман в том числе и для синхронных фискализаторов для которых просто нету pendingId

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 12 июл 2019, 14:33 
Не в сети
Аватара пользователя

Зарегистрирован: 30 май 2008, 15:51
Сообщения: 6051
Карма: 244
хотя понял, имеете в виду вы скорее всего не это, а про работу с удалёнными платежами опять, но в принципе getPaymentFromPendingId вам тоже поможет (о выбирает только из лога) . и плюс updatePaymentLastError никак не использует contract_payment, payment_id там просто тоже айдишник из cashcheck_payment_log

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 15 июл 2019, 15:19 
Не в сети

Зарегистрирован: 20 окт 2016, 00:34
Сообщения: 82
Карма: 0
Да. Я имел в виду удалённые платежи.
Про pendingId понял, хотя собственно задача проверки статусов ведь только для асинхронных.
Я собственно уже сделал проверку статуса удалённых, просто хотелось чтоб это как говорится из коробки было,
да и мало ли api изменится с очередным обновлением.

Кстати, столкнулся с тем, что
check.status.timeout.ms=10 мс может оказаться мало,
начал ловить ошибку

error parse json from response: java.lang.String cannot be cast to org.json.JSONObject

на проверке статуса чеков, при чём моя задача на проверку статуса удалённых работала, но там таймаут был 50 мс,
поставил check.status.timeout.ms=30 - ошибки проверки статуса исчезли.

_________________
Клиент: вер. 7.1.206 / 15.08.2019 22:37:24
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_181
Сервер: вер. 7.1.1144 / 15.08.2019 22:39:22
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_181


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 15 июл 2019, 15:25 
Не в сети

Зарегистрирован: 20 окт 2016, 00:34
Сообщения: 82
Карма: 0
Да, со мной в ХД это обсуждали. Просто хотелось бы задачу на переотправку ошибочных,
а она нужна, Атол-онлайн чудит просто с завидной периодичностью :-(
То чеки не проходят, то другие чудеса:
Вот из перлов
11.07.2019 18:35:13
(payment #7001729 (type_id=57), on printer #14)
ru.bitel.bgbilling.common.BGMessageException: Ошибка АТОЛ-Онлайн: Ошибка сервера. Обратитесь к Администратору.
пачкой, что-то у них пошло не так.
Сегодня буквально:
15.07.2019 12:36:55
ru.bitel.bgbilling.common.BGException: protocol error: no "status" field in report-response - это уже в ответ на задачу проверки статуса.

_________________
Клиент: вер. 7.1.206 / 15.08.2019 22:37:24
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_181
Сервер: вер. 7.1.1144 / 15.08.2019 22:39:22
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_181


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 15 июл 2019, 15:34 
Не в сети

Зарегистрирован: 20 окт 2016, 00:34
Сообщения: 82
Карма: 0
Цитата:
и плюс updatePaymentLastError никак не использует contract_payment, payment_id там просто тоже айдишник

- это так, но там в задаче как-то так - updatePaymentLastError( payment.getId(), lastError ),
потому собственно удалённые стандартной задачей к сожалению не апдейтятся :-(

_________________
Клиент: вер. 7.1.206 / 15.08.2019 22:37:24
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_181
Сервер: вер. 7.1.1144 / 15.08.2019 22:39:22
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_181


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 15 июл 2019, 15:44 
Не в сети
Аватара пользователя

Зарегистрирован: 30 май 2008, 15:51
Сообщения: 6051
Карма: 244
Цитата:
Кстати, столкнулся с тем, что
check.status.timeout.ms=10 мс может оказаться мало,
начал ловить ошибку

error parse json from response: java.lang.String cannot be cast to org.json.JSONObject

на проверке статуса чеков, при чём моя задача на проверку статуса удалённых работала, но там таймаут был 50 мс,
поставил check.status.timeout.ms=30 - ошибки проверки статуса исчезли.
тут на всякий случай поясню, что это таймаут МЕЖДУ последовательными запросами. а атол-онлайн ограничивает чётко кол-во обращений в период времени, оно зависит от кол-ва ККТ - чем больше тем больше можно запросов делать.
по всей видимости просто пришёл ответ о таймауте, и он почему-то не в json (вероятно 504?), было бы неплохо посмотреть на этот ответ (из логов сервера , например) и сделать чтобы он нормально обрабатывался

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 15 июл 2019, 15:46 
Не в сети
Аватара пользователя

Зарегистрирован: 30 май 2008, 15:51
Сообщения: 6051
Карма: 244
Цитата:
Вот из перлов
11.07.2019 18:35:13
(payment #7001729 (type_id=57), on printer #14)
ru.bitel.bgbilling.common.BGMessageException: Ошибка АТОЛ-Онлайн: Ошибка сервера. Обратитесь к Администратору.
пачкой, что-то у них пошло не так.

такое кто-то ловил, они возвращали какое-то время 500 вроде.

Цитата:
Сегодня буквально:
15.07.2019 12:36:55
ru.bitel.bgbilling.common.BGException: protocol error: no "status" field in report-response - это уже в ответ на задачу проверки статуса.

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 15 июл 2019, 16:00 
Не в сети

Зарегистрирован: 20 окт 2016, 00:34
Сообщения: 82
Карма: 0
Боюсь в doJsonRequest в данном случае при ошибке парсинага ответ даже в дебаге не увижу, там просто бросается исключение.

_________________
Клиент: вер. 7.1.206 / 15.08.2019 22:37:24
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_181
Сервер: вер. 7.1.1144 / 15.08.2019 22:39:22
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_181


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 15 июл 2019, 16:03 
Не в сети

Зарегистрирован: 20 окт 2016, 00:34
Сообщения: 82
Карма: 0
Про то что это это интервал между последовательными запросами я понимаю, просто странно, т.к. в самые загруженные
по платежам дни типа 1-3 числа месяца, я такого не ловил, а тут бац - приехали. Возможно они настройки чуть поджали.

_________________
Клиент: вер. 7.1.206 / 15.08.2019 22:37:24
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_181
Сервер: вер. 7.1.1144 / 15.08.2019 22:39:22
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_181


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 33 ]  На страницу 1, 2  След.

Часовой пояс: UTC + 5 часов [ Летнее время ]


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron
POWERED_BY
Русская поддержка phpBB
[ Time : 0.092s | 78 Queries | GZIP : On ]