BiTel

так с JRE точно всё нормально?

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

да, jre-норм. нигде больше проблемы со временем не встречал. только с ОСМП. У меня таких платежей попадается штуки 5 в месяц.
Кстати, а логи обращений с платежной системы где-то хранятся. по ним 100% можно увидеть - верна ли моя догадка.

покажите about из клиента биллинга.

Да понятно тут всё, предлагается сверять по локальному (!) времени, о котором ОСМП знать ничего не может, что делает предложение чуть более, чем абсурдным.

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

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

Предлагаю еще раз прочитать что пишет сапорт ОСМП:



Т.е. в pay-запросе из ОСМП в поле txn_date приходит дата, которая была на момент, когда пользователь положил деньги в аппарат, и вы ее записываете в поле time.

В сверке ОСМП использует дату, когда был сделан pay-запрос в биллинг. Вы эту дату записываете в поле localtime.

Я и предлагаю добавить возможность фильтровать по полю localtime.

Что здесь абсурдного?

Да что значит "когда был сделан pay-запрос в биллинг"? Где и в каком виде, в каком поле присылается эта дата? Абсурдность тут, во-первых, в том, что (как я понимаю) ответ: ни в каком.
Во-вторых, выше ведь сказали, что check-запрос вообще не учитывается.

Поле localtime вообще никак к протоколу не относится и не предполагалось, что будет относиться. Откуда ОСМП вообще о нём узнать могла и почему всё работает не по описанному ими протоколу? Или по протоколу?Разбирательство надо начинать именно отсюда, а не выдумывать костыли.

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

Согласен.
Опять задал вопрос в ОСМП. Подожду что они скажут....

Просто localtime неожиданно подошло для обходного решения...

А для чего вообще задумывалось поле localtime? Оно вроде нигде не светится на морде?

Светится в поле Дата/время оплаты по ссылке Платежные системы. Ну и плюс это время реального занесения платежа.

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

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

Возвращаясь к ответу сапорта ОСМП:



В поле localtime записывается текущее время когда прошел запрос.
Для операторов, находящихся в тамзоне ОСМП-сервера - это как раз и будет время проведения платежа.
Конечно же ОСМП об этом ничего не знает. Просто так случайно получилось, что это поле можно заиспользовать...

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

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

В процессе общения с ОСМП - всплыл другой момент.

ОСМП присылает платеж 01.03.12 с полем txn_date=29.02.12
BGB его записывает в модуле MPS 29.02.12, а в ядро BGB платеж попадает с датой 01.03.12

ОСМП 02.03.12 присылает сверку за 01.03.12, в которой этот платеж идет 29.02.12.
Загружаю эту сверку в "Сверку платежей" модуля MPS с периодом от 01.03.12-01.03.12. И, этот платеж (с txn_date 29.02.12) высвечивается как недостающий. Т.е. сверка происходит по ядру?

Ну вроде правильно. Платеж то 29.02, а сверку выбираешь только 01.03. Он и не может туда попасть, ибо как уже было сказано - сверка ведется по времени ПС и неважно когда он в ядро попал. Не пробовал с 29.02 по 01.03 выбрать ?

Сверка происходит по модулю, по txn_date платежа.
По их же документации следует, что платеж с txn_date 29.02.12 должен быть в реестре от 29.02.12:
А если это правило не учитывается - то расхождения будут в любом случае, просто в разных местах:
- если сравнивать по локальному времени - будет разница из-за сети и какие-нибудь платежи попадут не в тот день,
- если проверять реестр за 29-ое число - то непонятно, откуда платеж в биллинге (т.к. в реестре за 29 его нет)
- если проверять реестр за 1-ое число - непонятно, откуда недостающий платеж
- если проверять реестр за 1-ое, в биллинге выставив 29-01, то не понятно, откуда другие платежи в биллинге за 29
- если проверять реестр и дополнительно искать платежи в прошлых днях - тогда опять-таки при сверке за 29-ое непонятно, откуда платеж в биллинге, а при сверке за 1-ое никогда нет уверенности, что платеж за 29-ое есть в биллинге, но в платежной системе его нет - может быть он в каком-то реестре за 1-ое, 2-ое или 10-ое.

Проблема, как я понимаю, на стороне ОСМП и их неправильного протокола, а у нас всё работает©

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

К разработчикам:

Давайте пока отбросим все то, что до этого обсуждали.
Меня сейчас интересует следующее:

1.03.12 пришел платеж с txn_date=29.02.12
В модуле MPS этот платеж стоит 29.02.12
В Ядре - 1.03.12

на скринах из таблиц это видно.

Так и задумывалось?


А по ОСМП - в принципе - они делают так, как у них получается... хоть платеж от 29.02.12 и не попал в сверку которая пришла мне 01.03.12, но этот платеж пришел в сверке от 02.03.12 - и дата платежа была правильная - 29.02.12

Так что пока давайте вернемся к вопросу который в этом сообщении выше.

Да. В ядре учет по вашему времени, когда платеж реально пришел в биллинг. В модуле - по времени платежной системы, чтобы можно было проводить сверку, т.е. в случае ОСМП - по полю txn_date.

Мда.... ситуация...
И ОСМП правы со своей стороны
И Вы правы со своей

А платежи сверять надо, и в ручную - ох как не хочется.

Неужели я единственный кто с этой ситуацией столкнулся? Кто как решает? или забили и надеетесь на то, что ОСМП не ошибается?

у меня сравнивают бухи платежи, хз как. но при проблемах я не могу сравнить по биллингу платежи, не раз такое было

_________________

Код:

  Клиент: вер. 6.2.714 / 25.05.2015 17:27:15
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45
  Сервер: вер. 6.2.881 / 22.05.2015 17:56:55
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45

Помощь по администрированию bgbilling в jabber конференции или Группа в telegram
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений