Уважаемые разработчики CS-Cart, функция fn_order_placement_routines Эта функция находится в цепочке функций оформления заказа. В теле функции есть проверка if (in_array($status, fn_get_order_paid_statuses())) Если условие не выполняется тогда оформление заказа не происходит и покупателя система возвращает на страницу оформления заказа. В свою очередь функция fn_get_order_paid_statuses() возвращает список статусов заказов означающих оплату заказа. Вы это серьезно?
Во-первых, странно определять статус оплаты по значению поля статуса заказа “Расчет количества товара в наличии” (если уменьшение тогда оплачен, если увеличение тогда не оплачен).
Во-вторых, для способов оплаты, использующих процессоры оплаты (онлайн-платежи), разработчик в настройке способа оплаты определяет статусы заказа в зависимости от ответа платежной системы, также администратор может перенастроить сопоставление статусов заказов со статусами ответа платежной системы.
Таким образом мы имеем с одной стороны однозначно определенные в ядре системы статусы оплаты (по действию с остатком товара), с другой стороны определение статуса оплаты заказа платежным процессором (настраиваемое администратором, по ответу от платежной системы).
Нужно что-то решать с этой неоднозначностью.
Возможная проблема.
Для статуса заказа “Оплачен” установить поле “Расчет количества товара в наличии” в значение “Увеличение”. В настройке процессора оплаты указать для ответа платежной системы “Успешная оплата” статус заказа “Оплачен”. После оплаты покупатель попадает на страницу оформления заказа с той же наполненной корзиной. При этом заказ оформляется с номером №111 (т.е. переводится из статуса “Незавершенный” в статус “Оплачен”), но только для администратора, не для покупателя! Покупатель может изменить товары в корзине и снова перейти на оплату заказа и оплатить тот же заказ №111! При этом в заказе перезапишутся товары и прочее из новой корзины, т.е. в заказе №111 уже не будет тех товаров которые были оплачены покупателем. И вся проблема в том, что для статуса “Оплачен” настройка “Расчет количества товара в наличии” в значении “Увеличение” и он соответственно не считается статусом оплаты!
Сюда же - прошу, сделайте ОТДЕЛЬНЫЕ статусы оплаты(а чтобы два раза не вставать можно и статусы доставки добавить), которые бы использовались универсально для всех модулей оплаты! И остальные реквизиты оплаты тоже универсальности требуют. Чтобы этим было возможно пользоваться. Иначе сейчас любая интеграция со сторонними системами полна абсурда, и привязывается к конкретному способу оплаты, потому как там полный разброд и шатание. Сделать то надо всего-лишь десяток универсальных полей, которые бы использовались по мере необходимости всеми способами оплаты, в зависимости от того какие данные они отдают. Но уж статус оплаты и id операции то точно все отдают. Одно из полей должно быть названием платежной системы, чтобы именно его и отдавать в те же CommerceML, а то полный абсурд что технический обмен зависит от названия способа оплаты которое написали для покупателей(и временами переименовывается, когда приходит понимание что название можно сделать понятнее).
Ну вот так нужно, например чтобы уменьшение по складу происходило другим статусом после проверки оплаты бухгалтером или при отгрузке (кейсы могут быть разные). Здравомыслящему человеку не понять как уменьшение кол-ва товара на складе влияет на процесс оплаты и на правильное завершение оформление заказа в целом.
В принципе достаточно поля с множественным выбором - Предыдущие статусы, и при смене статуса проверка, что текущий статус присутствует в списке предшествующих для выбранного
Заказ не считается оплаченным (оформленным) если не уменьшать кол-во товара в остатке
Поставьте для статуса ОТКРЫТ (или другой который присваивается у Вас в магазине при оформлении заказа) поле “Расчет кол-ва товара в наличии” в значение “Увеличение” - и не сможете оформить заказ!
Но в таком случае возможны заказы на товары, отсутствующие в наличии. Например, два покупателя закажут и оплатят одну и ту же последнюю единицу товара. Поэтому и нужно уменьшением резервировать товар под оформленный заказ.
Если у вас какая-то другая логика и есть алгоритмы выхода из подобных ситуаций, то ОК. Но вряд ли это нужно большинству и будет быстро реализовано. Вам быстрее будет доработкой подстроить под свои бизнес-процессы.
Не пробовали отключить настройку “Включить отслеживание количества товаров на складе” в общих? Как это влияет на вашу ситуацию?
Я программист. В первом посте написал, что в функции оформления заказа есть проверка функцией fn_get_order_paid_statuses() является ли статус заказа с параметром уменьшения кол-ва, если нет то возникает проблема (ошибка оформления заказа). Настройки отслеживания кол-ва никак не влияют на это, только настройка статуса заказа. Проблема в том, что администрирование должно быть понятным и исключать настройку которая вызывает ошибки в работе системы.
Если по описанию, демонстрации или при демо-тестировании Вас все устраивает так оно все гуд. Какие тогда вопросы?
Не думайте, не надейтесь, что установив коробочное решение (любого движка) Вы получите идеальное решение для своего бизнеса. Каждый бизнес должен дорабатывать сайт для себя.
вот видите и вы наступили.
Большое обновление CS-Cart уже здесь
Попробуйте новую панель администратора с темной темой
Т.к. проблема в другом: