Расчет времени готовности заказа
Расчет времени готовности заказа.
В этом релизе добавили новую настройку "Режим работы". Найти можно тут:
Настройки->Режим работы
Или тут:
Оформление заказа->Оформление заказа в корзине->Оформление->Индивидуальный для этой витрины режим работы
Сейчас расписание отвечает за единственную функцию - Расчет времени готовности заказа. Это время когда магазин когда готов отдать заказ курьеру, покупателю и.т.д.
Как происходит расчет времени:
1) Получаем время создания заказа в таймзоне сервера и переводим в таймзону офиса. Таймзону офиса указываем тут:
2) Полученная дата проверяется на тип дня по алгоритму: Дополнительный рабочий
- Дополнительный рабочий
- Дополнительный выходной
- Рабочий
- Выходной
Обратите внимание, что у дополнительного рабочего дня приоритет над другими типами дней.
3*) Проверяем день создания заказа. (выполняется один раз)
Если заказ создан до окончания времени приема заказа - обрабатываем сегодня. Если после - то с ближайшего рабочего дня.
4) Отнимаем время обработки.
Если указано время обработки
Берем рабочие часы каждого конкретного дня и отнимаем от времени обработки заказа.
5) Если заказ не обработается за один рабочий день.
Переходим на начало работы следующего дня и делаем пункты 2-4, до тех пор пока время обработки не будет равно 0.
Максимальное количество дней для проверки - 365.
6) Время обработки последнего дня прибавляем к дате когда обработка закончилась.
7) Конечное время переводим в таймзону сервера. На выходе получаем SQL Date (YYYY-MM-DD HH:MI:SS)
В плагинах доставки
Чтобы получить время готовности заказа в плагинах доставки вызываем
$this->getPackageProperty('departure_datetime');
После своей обработки, плагин так же должен вернуть SQL Date (YYYY-MM-DD HH:MI:SS) в серверной таймзоне.
Свою таймзону он тоже отдает. Подробнее смотрите тут Чекаут магазина: изменения плагинов доставки.
Вызываем в прикладном коде
shopDepartureDateTimeFacade::getDeparture($schedule = [], $storefront = '')
Загружаем в него свое расписание или попросить расписание конкретной витрины. А можно вообще ничего не передавать и тогда возьмется базовое расписание из настроек магазина.
Не хочу пользоваться предложенным интерфейсом!
Окей, вот хук @event departure_datetime.before. Он вызывается перед началом расчета даты и дает возможность подменить расписание.
15 ответов
Если вы так заботитесь о таймзоне, то зачем два поля с датой и таймзоной, а не дата в ISO8601 ?
Я уж не говорю о DateTimeImmutable и DateTimeZone, с ними понятно, первый PHP 5.5+
SQL Date
Ё-моё! Там еще и таймзона в виде 'Europe/Moscow'. oh, shit...
Любимые клиенты WA которые "до сих пор на PHP 5.2" будут считать, что "Europe/Volgograd" это +0300. А те, у кого обновления PHP и системы регулярны, будут считать, что "Europe/Volgograd" это +0200
А у кого PHP 5.4 будут считать, что в РФ всё еще есть зимнее/летнее время
Ну условно. Зависит от свежести установленных баз по таймзонам
Чтож ты делаешь, ВА, аха-ха, прекрати!
для магазина мин. версия PHP 5.6
Нет, пока ещё 5.2
Требование 5.6 будет в следующем году, с выходом нового фреймворка. Хотя надо уже min. 7.2 требовать по-хорошему
Сергей, мы готовим релиз под магазин с минимальной версией 5.6. Если посмотреть на код чекаута, то у там куча того, что в 5.2 упадет смертью храбрых. Версия повысится с выходом магазина 8.0
Это сама по себе отличная новость, но никак не отменяет проблемы актуальности баз с таймзонами.
Лишь только возвращает вопрос "почему там не DateTimeImmutable?"
Таймзоны логичнее всё-таки видеть как “+0300“, а не "Europe/Moscow"
Я вижу в этом наоборот преимущество. Если страна (регион) решит поменять свою таймзону, то код будет работать.
И как получать валидные часы таймзон? Вы сами написали, что все зависит от актуальности баз по таймзонам. Соответственно нам надо на себя переложить эту ответственность или что еще хуже, дать пользователям возможность самим вводить. Проще поддержание баз таймзон оставить на совести php.
Как быть с плагинами в которых реализован аналогичный механизм? Вернее как быть с их обновлениями? E
Eсли я обновлю плагин и добавлю этот функционал, то придется ограничить мин. версию магазина 8кой:
'app.shop'=>array( 'name' => 'Приложение "Магазин"', 'strict' => true, 'version' => '8.0.0.0', ),Соответственно клиенты оставшиеся на 7ке не смогут обновить плагин. А в обновлении могут быть исправлены ошибки которые есть и версиях выходивших под 7ку.
Отказать в исправлении ошибок клиентам с shop 7 я не могу, но и предоставить им обновление тоже.
Делай, как я. Требуй версию 'latest' :)
требовать ты можешь что угодно собственно как и клиенты, но так как для wa клиенты важнее, то твои продукты просто выпилят из магазина в случае жалоб на баги которые ты чисто технически не в состоянии исправить.
Это с ва обсуждалась. Их позиция -- у пользователей всегда должна быть самая свежая версия продуктов. Кто не обновляется -- сам себе злобный Буратино.
Первая же рекомендация самих ВА в случае ошибок -- "установите все обновления"
будем надеятся что они про это не забудут
В следующем обновлении для разработчиков добавим хелпер