Есть большой косяк со сменой статусов заказов. Причем, усугубляется он тем что формирование чеков коробочным модулем Атол Онлайн не предполагает никаких проверок. И изредка происходят вот такие сюрпризы:
Что было? Заказ оплачен с помощью эквайринга Сбербанк Онлайн. На этапе после оплаты там бывает всякое - распространенная проблема - пользователь закрывает страницу эквайринга не дожидаясь и оплаченный заказ остается в статусе Незавершенный(и как следствие не формируются кассовые чеки, не отрабатывают автоматически другие процессы для оплаченных заказов - нет никакой проверки на оплаты, не смотря на то что у Сбербанка есть весьма достойный API с документацией и примерами). А бывает вот ситуация как тут. Благо, я знаю что произошло т.к. знаком с этим покупателем. В этот момент сайт тормозил(это тема для отдельного баг-трекера, операция приведшая к тормозам была рядовой). Клиент вернувшийся со страницы Сбербанка видел пустую страницу и несколько раз её обновил. Как следствие - ему отправлена куча писем, а в онлайн-кассу ушли лишние 4 чека.
Баг первый - во-первых, не должны статусы меняться два раза - это просто не должно быть возможно(на статусы много что завязано в движке).
Баг второй - модуль эквайринга Сбербанка реализован криво, в следствии чего действия пользователей(всякие блокировщики скриптов и рекламы установленные в браузере, закрытие вкладки оплаты и т.д.) приводят к не корректной обработке/не обработке заказов, в следствии чего часто не пробиваются кассовые чеки обязательные по закону.
Баг третий - модуль Атол Онлайн вообще не стесняется отправлять 5 чеков идентичных друг за другом и его ничего вообще в этом не смущает.
Уверен, что проблема не только в этих модулях - такие логические ошибки надо и в других модулях оплаты-чеков проверить и устранить. Это ведь довольно очевидные логические ошибки. Тут же вопрос про деньги и отчетность. Да и не сказать что это какая-то удивительно редкая проблема - возникает периодически, хоть и не каждый день.
Теперь особенно важно лишний раз не привлекать внимание контролирующих органов, т.к. они активизировались в надежде восполнить уменьшившиеся из-за известной болячки налоговые поступления.
ну раз поднимать этот вопрос, прицеплюсь Сбербанк (SberPay, Apple Pay и все остальные Pay) так как по факту это и есть api
Ну и там осталось 2,5 недели до момента когда надо будет многим в Сбер передавать товары.
Ошибка продолжается, а меня уже откровенно задолбали бухгалтера. Это же в налоговую уходит… Подскажите, возможно ли как-то по-простому заблокировать двойную одинаковую смену статуса заказа?
Благодарю, а могли бы пояснить, в чем идея? Не очень понимаю, почему такое изменение должно препятствовать повторной смене статуса. Специально воспроизвести чтобы проверить крайне затруднительно.
$status_from это статус с которого нужно произвести замену , и он передается в функцию 3 параметром, но он не обязателен , и если его не передать то выполниться код
if (empty($status_from)) {
$status_from = $order_info['status'];
}
и если текущий статус совпадает со статусом который пытаются присвоить заказу, то происходит выход из функции
видимо скрип платежного модуля при каждом выполнении в $status_from пишет один и тот же статус не проверяя изменился ли он, и если убрать проверку на пустоту, то при любом изменении статуса в $status_from всегда будет актуальный статус.
НО есть вероятность ,что где-то в системе заложена логика повторения действий при смене статуса без изменения статуса и такая правка ее убьет
Кстати, заметил что в модуле Атол Онлайн исправить косяк наоформляв чеков возврата переводами статусов туда-обратно нельзя - повторно не создается чек. Т.е. в одном месте проверку встроили(срабатывает в админке), а там где пользователи могут просто несколько раз F5 нажать - нет.
В качестве временного решения, чтобы бухгалтерия спала спокойно, можно перевести оплаты на платежный сервис с фискализацией. Например, Робокасса. Чтобы платежный сервис сам выбивал чек после успешной оплаты, а не CS-Cart. Да, это дороже по комиссиям. Но зато снимает риск получить штраф от налоговой.
Это замена одной периодически возникающей известной проблемы на набор неизвестных. Во-первых, дороже, во-вторых, процесс перехода займет время-деньги, в-третьих - на стороне 1С есть написанная интеграция со Сбером для минимизации ручного труда. И при этом сама проблема то останется, просто в менее критичном виде.
Проблема исчезнет, так как CS-Cart вообще не будет принимать участия в процессе формирования чека. Чек формирует не модуль Робокассы из CS-Cart, а сама Робокасса у себя на сервере на своей кассе. И не важно, закрыл вкладку покупатель или нет, нажал “Вернуться в магазин” или нет, медленное у него соединение или быстрое. Прошла оплата - есть один чек, не прошла оплата - нет чека. Это временно избавит вас от головной боли с формированием нескольких чеков, с множественным изменением статусов заказов. Перед налоговой вы будете чисты. Я и не писал, что это будет вам дешевле и не потребует никаких усилий.
У Сбера обнаружился свой собственный модуль для CS-Cart(не тот что в коробке), который умеет передавать список товаров в эквайринг. А онлайн-кассу Атол.Онлайн получилось интегрировать на стороне эквайринга. И проблема решилась - ни одной проблемы. В общем, не используйте коробочный модуль Сбербанка и не используйте отправку чеков на стороне сайта - лучше интеграцию настроить на стороне эквайринга, там проблем нет. Результат - товары в чеке есть, чеки формируются автоматически. Из дополнительных плюшек после интеграции онлайн-кассы с эквайрингом в случае возврата денег клиенту через эквайринг чек возврата формируется автоматически.
