Страница 1 из 1
По какому принципу работает учёт заказов
Добавлено: 2019-08-15 20:47:49
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 релиза.
Буду очень благодарен за наводку, в каком месте стоит поискать.
По какому принципу работает учёт заказов
Добавлено: 2019-08-16 7:34:44
Alex Keda
учёт происходит раз в сутки
задача так и называется: hosts/hosting/comp/Tasks/Consider.comp.php
ничего феерического там нет
--
что касается описанной ситуации - смотрим первую строку что я написал
учёт происходит раз в сутки
и клиент может оплатить ДО того как учёт произошёл, но уже в ЭТИ сутки.
получаем минус один день, прям в этот же день
собственно, фактическая блокировка заказов происходит на сутки позже, именно с целью нивелирования таких вот накладок...
Отправлено спустя 3 минуты 57 секунд:а вообще, я за всё время немного припомню таких жалоб...
ну раз в год может кто пожалуется, даже раз в два...
все разы что разбирался - причина была именно описанная выше
Отправлено спустя 1 минуту 32 секунды:и, да, что касается правок - вы чё нужное то выкладывайте, коммитьте =)
По какому принципу работает учёт заказов
Добавлено: 2019-08-16 11:59:34
sasha181
Спасибо, большое.
Да там в основном своё, специфическое.
Но вот есть мысль выложить всё-таки vqmod интеграцию. Я всё-таки рискнул и оттестировал на себе её. По сути, меняется только один файл core/load.php
И после можно накладывать свои патчи.
Думаю, это может дать хороший толчёк в развитии биллинга, т.к. делиться своими правками станет гораздо легче. И правки эти будут обратно совместимы с обновлениями биллинга в большинстве случаев.
Да и до этого не выкладывал, т.к. с git почти не работал и только сейчас мелкими шагами прихожу к пониманию.
Ещё на очереди могу выложить свою реализацию онлайн кассы. У меня стоит умка-lite за 5 тыс руб прям в офисе и накакой абонплаты сторонним организациям не надо. Всё работает как часы.
Думаю посмотреть как Вы модуль запилили под онлайн провайдера и в таком же стиле запихнуть свою. Создам отдельно тему потом. Там наверняка возникнет пара вопросов.
По какому принципу работает учёт заказов
Добавлено: 2019-08-16 15:35:10
Alex Keda
sasha181 писал(а):Спасибо, большое.
Да там в основном своё, специфическое.
Но вот есть мысль выложить всё-таки vqmod интеграцию. Я всё-таки рискнул и оттестировал на себе её. По сути, меняется только один файл core/load.php
И после можно накладывать свои патчи.
вообще не понял что это и зачем нужно =(
sasha181 писал(а):Ещё на очереди могу выложить свою реализацию онлайн кассы. У меня стоит умка-lite за 5 тыс руб прям в офисе и накакой абонплаты сторонним организациям не надо. Всё работает как часы.
Думаю посмотреть как Вы модуль запилили под онлайн провайдера и в таком же стиле запихнуть свою. Создам отдельно тему потом. Там наверняка возникнет пара вопросов.
это нужно. через год закончится договор аренды, так и так придётся пилить что-то своё, дорого всё же сторонние конторы
почитал про умку, у вас оно к компу с виндой прицеплено чтоли?
По какому принципу работает учёт заказов
Добавлено: 2019-08-19 15:45:15
sasha181
Пока да. Но в теории у них там был драйвер и под linux. По сути ведь умка pro работает скорее всего на андроид или каком-то другом arm linux. Но когда год назад ставил, их программист сказал, что пока под линукс драйвер не готов к продакшн.
Я изначально пробовал прокинуть usb устройство внутрь виртуалки с виндой, но оно не завелось. Видимо, особенности проброса в kvm не подошли для драйвера. Но у меня всегда включен комп, с которого цепляюсь по rdp к рабочему серверу. Кинул пока к нему и оставил писаться логи по каждой транзакции. Периодически проверяю. Если что-то не прошло, повторно отправку данных в умку. Но это очень редко бывает. За год 3-4 раза было.
В итоге, умка около 5 тыс, фискальный накопитель на 3 года + 3-х летний контракт с ОФД примерно за 17 тыс по какой-то акции. И всё.
По какому принципу работает учёт заказов
Добавлено: 2020-02-24 1:05:00
Alex Keda
кстати, щас вот попалась - у них же есть с эзернетом ККМ
тоже 5 тысяч стоят.
вы кстати, образец либы так и не сбросили
у меня через год с копейками кончится проплаченный период у komtet, а вообще, с учётом цен - может имеет смысл раньше отказаться, надо посчитать что дешевле будет
По какому принципу работает учёт заказов
Добавлено: 2020-08-29 2:50:04
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Поправьте меня, если ошибаюсь.
По какому принципу работает учёт заказов
Добавлено: 2020-08-29 11:38:25
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
По какому принципу работает учёт заказов
Добавлено: 2020-08-31 17:49:09
sasha181
За комментарии спасибо. Буду на этой неделе более глубоко разбираться в плане учёта.
Касательно умки, да, сам писал. Там если интегрировать, конечно только как пример класс можно использовать ,т.к. писалось на скорую руку под конкретную задачу (ИП 6%).
По какому принципу работает учёт заказов
Добавлено: 2020-08-31 19:33:48
Alex Keda
да уже с полгода задача висит JBS-1373 - сделать либу фискализации более высокого уровня
щас вся фискализация захардкожена на komtet
зимой, может - купим ККМ да начну...
хотя у них вроде тестовый есть - можно на нём поколупать