Сообщение sasha181 » 2020-08-29 2:50:04
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Поправьте меня, если ошибаюсь.
https://github.com/akunich/umka-api-php-example
Это по умке. Тут сам класс для работы с апи кассы. Ну а к биллингу я его немного костыльно прикрутил:
в API/StatusSet.comp.php в самом конце перед return Array('Status'=>'Ok');
добавил :
[code]
# мой допил под фз-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);
}
}
[/code]
А вот по учёту заказов я кажется нашёл корень проблемы. И она похоже реально всё это время имела место быть.
В 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
Поправьте меня, если ошибаюсь.
