По какому принципу работает учёт заказов

[sasha181]

Подскажите пожалуйста, какой файл отвечает за учёт заказов и по какому принципу он работает.
У меня уже ни раз пользователи жалуются, что продлевают заказ хостинга, скажем на месяц. После продления получают дату окончания , например 8 сентября. 5-го сентября заходят в биллинг, а там дата окончания 7-е сентября.
Особенно это беспокоит любителей продлевать заказ на неделю.
Я как-то с год назад копался в коде. Вроде пришёл к выводу, что сам учёт работает правильно, а вот в юзерской части что-то не так с округлением дней. Но сейчас решил перепроверить и доработать всё же это, т.к .насторожило ещё вот что:
Два подряд счёта на оплату у юзера на продление хостинга (тариф не менялся)
В одном написано, что продление с 28.07.19 по 04.08.19
В следующем - с 03.08.19 по 10.08.19
Далее - с 10.08.19 по 17.08.19
И последний - с 16.08.19 по 23.08.19
Т.е. из трёх оплат биллинг два раза "съел" по одному лишнему дню. Один же раз всё прошло как надо.
Началась эта проблема довольно давно. Раньше биллинг вёл учёт один раз в сутки. Потом, после какого-то обновления, стал работать как-т иначе. Вот с тех пор такие фантомные списания периодически проявляются. Когда человек продлевает на год или даже месяц, не так критично. А вот с понедельными периодами - ощутимо.
Да, тут можно сказать, продлевайте на месяц. Но ведь суть ошибки не изменится. Биллинг ведь должен вести учёт точно как в аптеке.
Не исключаю, что это у меня только проблема, т.к. в своё время навносил разных правок и теперь сложно с каждым релизом обновляться. Делаю обновление через 3-4 релиза.
Буду очень благодарен за наводку, в каком месте стоит поискать.

[Alex Keda]

учёт происходит раз в сутки
задача так и называется: hosts/hosting/comp/Tasks/Consider.comp.php
ничего феерического там нет
--
что касается описанной ситуации - смотрим первую строку что я написал

учёт происходит раз в сутки

и клиент может оплатить ДО того как учёт произошёл, но уже в ЭТИ сутки.
получаем минус один день, прям в этот же день

собственно, фактическая блокировка заказов происходит на сутки позже, именно с целью нивелирования таких вот накладок...

Отправлено спустя 3 минуты 57 секунд:
а вообще, я за всё время немного припомню таких жалоб...
ну раз в год может кто пожалуется, даже раз в два...

все разы что разбирался - причина была именно описанная выше

Отправлено спустя 1 минуту 32 секунды:
и, да, что касается правок - вы чё нужное то выкладывайте, коммитьте =)

[sasha181]

Спасибо, большое.
Да там в основном своё, специфическое.
Но вот есть мысль выложить всё-таки vqmod интеграцию. Я всё-таки рискнул и оттестировал на себе её. По сути, меняется только один файл core/load.php
И после можно накладывать свои патчи.
Думаю, это может дать хороший толчёк в развитии биллинга, т.к. делиться своими правками станет гораздо легче. И правки эти будут обратно совместимы с обновлениями биллинга в большинстве случаев.
Да и до этого не выкладывал, т.к. с git почти не работал и только сейчас мелкими шагами прихожу к пониманию.
Ещё на очереди могу выложить свою реализацию онлайн кассы. У меня стоит умка-lite за 5 тыс руб прям в офисе и накакой абонплаты сторонним организациям не надо. Всё работает как часы.
Думаю посмотреть как Вы модуль запилили под онлайн провайдера и в таком же стиле запихнуть свою. Создам отдельно тему потом. Там наверняка возникнет пара вопросов.

[Alex Keda]

Спасибо, большое.
Да там в основном своё, специфическое.
Но вот есть мысль выложить всё-таки vqmod интеграцию. Я всё-таки рискнул и оттестировал на себе её. По сути, меняется только один файл core/load.php
И после можно накладывать свои патчи.

вообще не понял что это и зачем нужно =(

Ещё на очереди могу выложить свою реализацию онлайн кассы. У меня стоит умка-lite за 5 тыс руб прям в офисе и накакой абонплаты сторонним организациям не надо. Всё работает как часы.
Думаю посмотреть как Вы модуль запилили под онлайн провайдера и в таком же стиле запихнуть свою. Создам отдельно тему потом. Там наверняка возникнет пара вопросов.

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

почитал про умку, у вас оно к компу с виндой прицеплено чтоли?

[sasha181]

Пока да. Но в теории у них там был драйвер и под linux. По сути ведь умка pro работает скорее всего на андроид или каком-то другом arm linux. Но когда год назад ставил, их программист сказал, что пока под линукс драйвер не готов к продакшн.
Я изначально пробовал прокинуть usb устройство внутрь виртуалки с виндой, но оно не завелось. Видимо, особенности проброса в kvm не подошли для драйвера. Но у меня всегда включен комп, с которого цепляюсь по rdp к рабочему серверу. Кинул пока к нему и оставил писаться логи по каждой транзакции. Периодически проверяю. Если что-то не прошло, повторно отправку данных в умку. Но это очень редко бывает. За год 3-4 раза было.
В итоге, умка около 5 тыс, фискальный накопитель на 3 года + 3-х летний контракт с ОФД примерно за 17 тыс по какой-то акции. И всё.

[Alex Keda]

кстати, щас вот попалась - у них же есть с эзернетом ККМ
тоже 5 тысяч стоят.

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

[sasha181]

https://github.com/akunich/umka-api-php-example
Это по умке. Тут сам класс для работы с апи кассы. Ну а к биллингу я его немного костыльно прикрутил:
в API/StatusSet.comp.php в самом конце перед return Array('Status'=>'Ok');
добавил :

Код: Выделить всё

# мой допил под фз-54
if($ModeID == "Invoices" && ($StatusID == "Payed" || $StatusID == "Rejected")) {
  $Invoice = DB_Select('InvoicesOwners',Array('ID','Summ', 'PaymentSystemID', 'UserID'),Array('UNIQ','ID'=>$Row['ID']));
 
  if($Invoice['PaymentSystemID'] == 'YandexLiteAC' || $Invoice['PaymentSystemID'] == 'YandexLite' || $Invoice['PaymentSystemID'] == 'WebMoneyR' || $Invoice['PaymentSystemID'] == 'SberBank' || $Invoice['PaymentSystemID'] == 'InOffice' || $Invoice['PaymentSystemID'] == 'PayPal') {
      $User = DB_Select('Users',Array('ID','Email'),Array('UNIQ','ID'=>$Invoice['UserID']));
      $Invoice['Email'] = $User['Email'];
      $Positions = DB_Select('InvoicesItems','*',Array('Where'=>SPrintF('`InvoiceID` = %u',$Invoice['ID'])));
     
      foreach($Positions as $key=>$Position) {
          $Service = DB_Select('Services',Array('NameShort','Measure'),Array('UNIQ','ID'=>$Position['ServiceID']));
          $Positions[$key]['NameShort'] = $Service['NameShort'];
          $Positions[$key]['Measure'] = $Service['Measure'];
      }
     
$moneyType = 2;
     
      include_once '/home/user/web/domain.ru/public_html/umka-api-model.php';
      $umka = new umkaApiModel();
      $umka->init();
     
      if($StatusID == "Rejected") $umka->fiscalcheckCancel($Invoice, $Positions, $moneyType);
      else $umka->fiscalcheck($Invoice, $Positions, $moneyType);
  }
}


А вот по учёту заказов я кажется нашёл корень проблемы. И она похоже реально всё это время имела место быть.
В Consider.comp.php у нас условие выбора заказов для снятия дней вот такое: http://joxi.ru/Vm6kRM3C4MLVd2?d=1
Так вот на примере заказов хостинга заметил такую особенность. При установке статуса в Active значение ConsiderDay сбрасывается в 0. Причём, при продлении (даже если заказ не был заблокирован), биллинг выполняет установку статуса Active. В итоге, если сегодня у нас уже был учёт заказа и снялся день, а спустя несколько часов пользователь продлил заказ ещё на месяц, то при следующем запуске consider снимет с этого заказа ещё один день. За сутки получится, что снято 2 дня. Причём, по сути при любом продлении система снимет на 1 день больше. Вопрос лишь в том, насколько позже от прошлого выполнения consider будет произведено продление. Если почти через сутки, то ошибка в часах будет не значительной. А вот если продлить сразу после consider, то снимается ровно на 1 лишний день больше положенного.

Вот код в /hosts/hosting/comp/Triggers/Statuses/HostingOrders/Active.comp.php , который приводит к такому поведению: http://joxi.ru/KAxg7KMsZaxn52?d=1

Поправьте меня, если ошибаюсь.

[Alex Keda]

чё-то я влёт даже не смог понять зачем этот кусок нужен

Код: Выделить всё

$IsUpdate = DB_Update('HostingOrders',Array('ConsiderDay'=>0),Array('ID'=>$HostingOrder['ID']));
if(Is_Error($IsUpdate))
        return ERROR | @Trigger_Error(500);


изначально, значение ConsiderDay и есть нулевое
если только для переучёта при смене тарифа...

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

сразу телепатирую проблему для залоченных

Код: Выделить всё

$ConsiderDay = ($ConsiderDay?$ConsiderDay+1:$CurrentDay);

у них в первый же день после активации учтётся весь залоченный период =)

так что лучше не пробовать... или просто впилить исключение на активацию - во всех остальных случаях пусть обнуляет, типа

Код: Выделить всё

if($HostingOrder['StatusID'] != 'Active'){
 $IsUpdate = DB_Update('HostingOrders',Array('ConsiderDay'=>0),Array('ID'=>$HostingOrder['ID']));
    if(Is_Error($IsUpdate))
        return ERROR | @Trigger_Error(500);
}

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

Отправлено спустя 6 минут :
по поводу умки - а это вы класс писали?
просто если в биллинг буду интегрировать, придётся мне переписать чтобы от curl избавиться...

Отправлено спустя 1 час 7 минут 44 секунды:
внёс правку, JBS-1441

[sasha181]

За комментарии спасибо. Буду на этой неделе более глубоко разбираться в плане учёта.
Касательно умки, да, сам писал. Там если интегрировать, конечно только как пример класс можно использовать ,т.к. писалось на скорую руку под конкретную задачу (ИП 6%).

[Alex Keda]

да уже с полгода задача висит JBS-1373 - сделать либу фискализации более высокого уровня
щас вся фискализация захардкожена на komtet

зимой, может - купим ККМ да начну...

хотя у них вроде тестовый есть - можно на нём поколупать