Мы готовимся к выпуску нового модуля Интернет-магазина. Физически это - тот же самый модуль sale, но существенно переработанный. В новом магазине у одного заказа может быть множество отгрузок и оплат/счетов, систематизирована оплата с внутреннего счета, переработаны платежные системы и службы доставки с целью их универсализации и поддержки новых возможностей, переработан жизненный цикл заказа, доработаны публичные компоненты и добавлено множество других улучшений и функциональных возможностей.
При разработке мы старались максимально обеспечить совместимость нового магазина со старыми версиями, но обеспечить 100% совместимость при такой масштабной переработке невозможно. Ниже в статье я опишу места, на которые надо обратить особое внимание при переходе на новый магазин. Если у вас есть вопросы, предложения, пожелания или требуется консультация - обращайтесь к нам через службу техподдержки.
Существенно изменилась структура таблиц в базе данных.
Мы всегда говорили, что прямой доступ к таблицам - это не правильный вариант работы с обновляемым продуктом. Но если вы все же по тем или иным причинам напрямую запрашиваете базу данных, то велика вероятность, что вам придется внести изменения в свои алгоритмы. Правильный доступ к данным должен производиться через АПИ модуля.
Заказ, оплаты, доставки – связь «один-ко-многим».
Раньше в магазине была одна сущность - заказ, который представлял собой одну запись в таблице заказов. В этой таблице было поле, в котором хранился код платежной системы, поле со статусом оплаты и т.д. В новом магазине у каждого заказа может быть неограниченное число (частичных) оплат/счетов, а так же неограниченное число отгрузок. У каждой оплаты свой статус оплаченности, своя дата оплаты и т.п.
Другими словами появляется связь «один-ко-многим» между заказом и оплатами/отгрузками. Соответственно если выбрать из базы пару значений "заказ - оплата", то либо оплата там будет какая-то одна из имеющихся (не все), либо один и тот же заказ будет в нескольких парах (по числу оплат).
Мы постарались обеспечить максимально возможную совместимость. Если у вас не используется разделение на несколько оплат для одного заказа, то через старый АПИ можно выбрать сразу и заказ и его одну оплату. Но как только у вас появится разделение - результат выборки может оказаться не такой, на который вы рассчитываете.
Все, что сказано про оплаты, верно и для отгрузок.
Рекомендовать тут можно только либо постепенно переходить на новый АПИ в ваших решениях (рекомендуется), либо всегда для одного заказа иметь только одну оплату и только одну отгрузку.
Оплата с внутреннего счета.
Раньше при оплате с внутреннего счета просто в таблице заказа проставлялась соответствующая сумма. В новом магазине внутренний счет - такая же платежная система, как и все остальные. Соответственно оплата с внутреннего счета - такая же запись (частичной) оплаты, как и для любой другой платежной системы. Таким образом облегчается отслеживание оплат, а кроме того на внутренний счет можно наложить условия и ограничения (как на любую другую платежную систему).
Полностью переработан жизненный цикл заказа.
Так как изменилась структура и работа заказа, то соответственно изменился и жизненный цикл заказа. Мы восстановили основные события того жизненного цикла, который был раньше. Они включаются и выключаются в настройках модуля. Но места вызова старых событий в новом магазине не соответствуют старым местам вызова (потому что старых мест уже нет). В большинстве случаев это не должно повлиять на успешное выполнение вашего обработчика события, но лучше после перехода на новый магазин перепроверить, что все работает правильно. Еще лучше, конечно, перейти на новые события.
Новый АПИ автоматически всегда поддерживает арифметическую целостность заказа.
Раньше программно можно было записать в любые поля заказа любые значения, и это успешно сохранялось, даже если логически данные не соответствовали друг другу. Например, при использовании старого АПИ можно было создать заказ стоимостью 1 руб., в котором было товаров на 500 руб. В новом магазине стоимость такого заказа будет 500 руб. (плюс возможно стоимость доставки).
Меняются реальные ID платежных систем и служб доставок.
В связи с изменением структуры и работы платежных систем и служб доставок, меняются их реальные ID. У служб доставок теперь нет архитектурного разделения на настраиваемые и автоматизированные, соответственно нет и строковых идентификаторов, они теперь числовые. Все внутренние данные и сущности сами переходят на новые ID при конвертации. Если вы где-то используете связывание внешних по отношению к модулю данных с платежными системами или службами доставок, то вам необходимо убедиться в корректном сохранении связей. А вообще правильнее такие связи делать через внешние ключи или мнемонические коды.
Ограничения платежных систем и служб доставок.
Раньше ограничения платежных систем и служб доставок (например, по сайтам, типам плательщика и т.п.) – были поля в таблицах соответственно платежных систем и служб доставок. Как следствие схема была не множественной и не расширяемой. Сейчас ограничения задаются с помощью новой сущности - ограничений. Они стали набираемыми для каждой службы доставки и платежной системы. Соответственно они могут быть множественными, можно расширять набор ограничений и т.д. Но следует учитывать, что это - больше не поля в таблице.
Пользовательские платежные системы.
Обратите внимание, что пользовательские обработчики платежных систем должны лежать в папке /bitrix/php_interface/include/sale_payment/. Они не могут лежать внутри /bitrix/modules/sale/. Внутри ядра продукта вы не должны ничего менять самостоятельно. Это прямо указано в документации.
Так же обратите внимание на то, что в общем случае нельзя напрямую (через include) подключать файлы из ядра продукта в свои скрипты. Если вы копировали какие-то обработчики в пользовательскую папку для изменения, то вы должны скопировать все файлы обработчика, а не подключать часть из них из ядра.
Если у вас есть вопросы, предложения, пожелания или требуется консультация - обращайтесь к нам через службу техподдержки.
, не только переменную, параметр или поле документа (например, {=Variable:myVar}), но и вычисляемое выражение
