Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
В своей предыдущей статье я начала раскрывать тему того, как правильно настраивать обмен между крупными сайтами и B2B-системами на Битрикс с системами учета 1С:Предприятие.
Если еще не читали — посмотрите, будет полезно, типовой модуль обмена многое умеет, а то, что не умеет — можно обойти и доработать.
В этой статье коснемся кастомизации и отладки обмена, а также выгрузки оффлайн-заказов.
1. Кастомизация обмена
Практика – это не то, что вы делаете,
когда становитесь мастером.
Практика – это то, что делает вас мастером.
Малколм Гладуэлл
Кастомизация предполагает уникальное для конкретного проекта изменение типовой логики и конечного результата обмена — без модификации ядра 1С-Битрикс, с сохранением возможности обновления платформы (если, конечно, вы не хотите потом получить претензию от владельца сайта).
Если есть штатный вариант решения задач проекта без кастомизации — именно его и стоит выбрать. Например, воспользоваться событиями или выгрузить дополнительные данные справочником.
Кастомизация, так или иначе, может «выстрелить в ногу» при серьезных обновлениях модулей обмена 1С и/или сайта.
Если кастомизация все же требуется — постарайтесь ограничить степень своего вмешательства в логику обмена написанием обработчиков для типовых событий платформы 1С-Битрикс, к числу которых относятся, например:
события информационных блоков (при импорте номенклатуры на сайт):
событие добавления элемента инфоблока (onAfterIBlockElementAdd),
событие обновления элемента инфоблока (onAfterIBlockElementUpdate) и другие.
события highload-блоков (в ответ на импорт справочников), к примеру:
перед добавлением записи в highload-блок (OnBeforeAdd),
до изменения записи в highload-блоке (OnBeforeUpdate).
Работаем с highload-блоками мы как с таблицами, создавая ORM сущности в Битрикс D7 и используя встроенные события ORM.
события модуля "Интернет-магазин" (при работе с заказами) такие, как:
событие начала сохранения заказа (OnSaleOrderBeforeSaved),
событие завершения сохранения заказа и связанных сущностей (OnSaleOrderSaved),
событие отмены заказа (OnSaleBeforeOrderCanceled) и прочие.
события модуля "Торговый каталог" (для товаров, типов цен, цен, складов, остатков; включает события импорта каталога из 1С). Особенно интересными здесь являются:
события OnBeforeCatalogImport1C и OnSuccessCatalogImport1C компонента bitrix:catalog.import.1c, срабатывающие до и после успешной обработки xml-файла обмена при импорте каталога. Вызываются они несколько раз за один обмен (так как и файлов в обмене несколько - import_***.xml, offers_***.xml, prices_***.xml, rests_***.xml).
Недокументированное событие OnCompleteCatalogImport1C того же компонента bitrix:catalog.import.1c, сигнализирующее о полном завершении импорта каталога.
Примеры ситуаций, когда мы можем использовать обработчики событий:
Для товаров с торговыми предложениями (SKU) нужно рассчитать минимальную и максимальную цену (в свойствах товара) для вывода в публичной части сайта.
В зависимости от цены требуется изменить статус товара.
Необходимо установить значение поля "Коэффициент единицы измерения" товара каталога из свойства "Кратность", заполняемого в 1С (для продажи товаров на сайте только по числу, кратному импортированному значению, например, когда шурупы продаются не поштучно, а по 100 штук).
Нужно создать/изменить пользователя сайта и его профиль покупателя в ответ на импорт справочников контактных лиц и контрагентов из 1С.
Требуется заполнить служебное свойство вновь созданного онлайн-заказа для корректной связи этого заказа на стороне 1С с существующим там контрагентом (XML_ID контрагента).
Примеров может быть масса.
Раскрывая тему кастомизации обмена, расскажу о том, как можно и как правильно импортировать на сайт скидки каталога из 1С. Типовой обмен не предусматривает импорта скидок на товары каталога (кроме скидок, зависящих от количества товара в заказе), а скидки часто нужны. Кастомизация здесь рассматривается в контексте подхода к реализации задачи, а не в плане изменения кода типового модуля обмена с 1С Битрикс. Есть несколько решений:
Завести в 1С дополнительные типы цен, уже учитывающие величину скидки.
Здесь есть ограничения:
Если типов скидок в 1С очень много (например, это персональные скидки, и все скидки рассчитываются вручную), более 50 штук, то импорт номенклатуры с ними будет происходить оооооооооооооочень медленно, потому что будет выгружаться декартово произведение всех товаров на все типы цен. И это вариант не подойдет.
Редакция "Малый бизнес" 1С-Битрикс позволяет импортировать из 1С только один тип цены, поэтому придется либо расширить используемую редакцию сайта, либо найти другой способ выгрузки скидок номенклатуры из 1С.
Выгрузить одну базовую цену, общую для всех покупателей (в таком виде она будет отображаться в умном фильтре и списке товаров). А на детальной странице товара, в корзине и при оформлении заказа запрашивать из 1С реальную цену товара для текущего пользователя в real-time режиме.
Выгрузить скидки из 1С в виде справочника (в highload-блок).
На события создания/изменения элементов highload-блока скидок установить создание/редактирование кастомных битриксовых скидок через API "Товарного маркетинга" 1С-Битрикс.
Этот вариант подходит и для сложных персональных скидок, даже когда их очень много.
Если добавление обработчиков событий не позволяет решить задачи проекта (например, когда модуль обмена на стороне 1С-Битрикс в принципе не подразумевает распознавание и сохранение необходимых приходящих из 1С данных), приходится кастомизировать компонент обмена на стороне сайта. Делать это нужно следующим образом:
1. Скопируйте стандартную страницу обмена по адресу /bitrix/admin/1c_exchange.php и назовите ее, например, /bitrix/admin/1c_custom_exchange.php.
2. На скопированной странице в зависимости от переданных параметров запроса вызывается тот или иной битриксовый компонент обмена:
sale.export.1c (обмен заказами)
catalog.import.1c (импорт каталога товаров из 1С на сайт)
catalog.import.hl (импорт справочников)
catalog.export.1c (экспорт каталога товаров с сайта в 1С)
Определите, в логику какого компонента необходимо внести изменения.
Скопируйте этот компонент в свое пространство имен и подключите уже свой компонент на странице 1c_custom_exchange.php (типовая схема кастомизации компонентов, принятая в 1С-Битрикс).
Не забудьте сделать отдельный коммит в системе контроля версий сразу после копирования типового компонента, чтобы по истории git можно было потом понять, что именно вы изменили.
3. Внесите необходимые изменения в кастомизируемый компонент обмена.
Подобные компоненты используют системные битриксовые классы (например, классы модуля "Интернет-магазин", /bitrix/modules/sale/lib/exchange).
Вы можете создать собственные классы для задач кастомизации обмена с 1С, унаследовав их от системных классов обмена ядра Битрикс.
В своих классах можно переопределять методы родительских классов и дописывать свои.
Для того, чтобы минимально влиять на логику ядра в переопределяемом методе вызывайте аналогичный метод родительского класса.
Используйте ваши классы в кастомизированном компоненте обмена.
4. В настройках узла обмена в 1С измените адрес, по которому 1С отправляет запрос для старта
обмена с сайтом, на ваш (например, /bitrix/admin/1c_custom_exchange.php).
5. Проведите ревью и рефакторинг кода, тщательно опишите созданные методы и классы. Ваш код должен быть масштабируемым, понятным, обновляемым (должен позволять обновлять ядро 1С-Битрикс и работать корректно после обновлений).
6. Будьте людьми, составьте подробную и понятную хоть какую-нибудь документацию по проведенным работам для владельца сайта и специалистов, которые будут работать с проектом в будущем.
Описанный процесс разработки позволяет решать широкий спектр задач, поддерживая при этом философию разработки самого Битрикса и одновременно учитывая требования и потребности конкретного бизнеса.
2. Отладка обмена. Не бойтесь погрузиться глубоко в ядро.
Чтобы исправить ошибку, ее нужно уметь повторить.
Инженерная мудрость
В программировании — как в жизни: ваш успех в задаче зависит от ваших личных качеств и способности продолжать идти к намеченной цели, сМИРенно и достойно принимая все неудачи и непредвиденные трудности. Какая бы проблема ни встретилась на пути — примите ее с благодарностью, в итоге это сделает вас сильнее и повысит ваш профессиональный уровень.
Новички обычно теряются, когда сталкиваются с непонятными ситуациями, начинают гуглить, искать помощи у коллег. Это нормально и в типовых случаях может помочь.
Но в теме обмена, а особенно при его кастомизации, этот прием чаще всего окажется малоэффективен.
Нужно углубляться в код, а это означает, что потребуется отладка.
Отладку на бою не делают — нужна копия сайта. А еще лучше и копия 1С.
На момент написания статьи обмен — это X компонентов + Y классов на ZZZZZZZ тысяч строк кода, и слабонервным туда погружаться страшно.
Но все не так печально. Советую прийти к общему пониманию того, что происходит, когда вы запускаете обмен, что и в каком виде передается. И это уже всего лишь 4-7 файлов обмена и 1 типовой сценарий выгрузки.
Начинать отладку причины конкретной проблемы в существующем обмене нужно с анализа того, что на самом деле приходит на сайт из 1С в xml-файле обмена (или отправляется с сайта).
Для этого в 1С (вкладка "Настройка параметров обмена" / "Хранение логов" узла настройки обмена с сайтом) включите логирование и сохранение логов обмена на сайте.
В Битриксе объявите константу BX_CATALOG_IMPORT_1C_PRESERVE .
Запустите обмен, дождитесь его завершения и приступите к изучению файлов в папке /upload/1c_catalog/ сайта.
Сопоставьте данные по конкретным элементам на сайте и в xml-файлах обмена.
Возьмем такой кейс. В 1С меняется свойство товара каталога (например, “Сезонная распродажа”), а на сайте оно не обновляется. Обмен настроен на выгрузку изменений. Как будем отлаживать эту ситуацию:
Поскольку нас интересует свойство товара - находим import.xml в файлах прошлого обмена в папке /upload/1c_catalog/.
Уточняем конкретный товар, на котором наблюдаем проблему. Проверяем, что в 1С установлено новое значение свойства, а на сайте оно старое - ошибка точно есть.
Ищем данные по товару в файле import.xml. Скорее всего, нужное свойство будет находится в узле <ЗначенияРеквизитов>. Нам нужно проверить, что пришло из 1С на сайт по данному свойству для искомого товара. Предположим, что в файле мы вообще не находим нужного товара (напомню, что в нем изменилось только свойство) - он вообще не попал в выгрузку изменений 1С.
Проверяем, установлена ли опция "Использовать контрольные суммы элементов для оптимизации обновления каталога" в форме настройки интеграции с 1С. Включена.
Сверяем контрольные суммы тестируемого товара на сайте и в 1С. Они одинаковые, а значит 1С думает, что товар не был изменен, и не добавляет его в очередной обмен изменений.
Скорее всего, установка свойства на стороне 1С происходит кастомно. Ставим специалисту 1С задачу на пересчет контрольной суммы товара после кастомной установки свойства. Я уже писала о контрольных суммах в предыдущей статье.
В том случае, если проблема находится на стороне сайта (в xml-файле приходят данные, идентичные 1С) - может потребоваться отладка, логирование и анализ соответствующей части кода ядра на стороне Битрикс (компонентов и классов обмена).
Это не страшно, но требует времени и внимания, а еще важно потом откатить свой код отладки к первоначальному состоянию.
Мы отлаживаем обмен часто. Очень часто. И даже написали собственный модуль отладки обмена сайта с 1С. Он пошагово логирует весь процесс обмена номенклатурой, заказами и справочниками, предоставляет информацию о возникающих в процессе ошибках, позволяет построить диаграмму Ганта за интересующий временной промежуток, следит за размерами логов и сроками их хранения. С его помощью можно изучить копии xml-файлов выгрузки (ссылки на них есть в общей таблице логов) и список GET-параметров запросов из 1С. Доступен поиск по логам (нужен, например, для поиска данных конкретного товара в файлах обмена по его артикулу или названию). Логирование можно настраивать. Удобно.
Интерволга. Пример логов модуля отладки обмена с 1С
Интерволга. Логирование обмена с 1С. Диаграмма Ганта
Интерволга. Настройки логирования обмена с 1С
3. Оффлайн заказы из 1С
Но мед это очень уж хитрый предмет -
Всякая вещь или есть, или нет.
А мед - я никак не пойму в чем секрет -
Мед если есть - то его сразу нет.
Песенка про мед Винни Пуха
Оффлайн заказы обрабатываются и хранятся в той же системе учета 1С, обмен с которой настраивается для сайта.
Оффлайн заказ приходит в 1С из любого другого источника, кроме интегрируемого сайта, например, из оффлайн магазина или внешней системы, связанной с той же 1С (например, с другого сайта или учетных систем Axapta и SAP).
В нашей практике задача настройки обмена оффлайн заказами между 1С и сайтом встречается не часто, но запросы и реализованные проекты есть в достаточном количестве.
Импорт оффлайн заказов на сайт имеет смысл для бизнеса, имеющего долгую историю работы с клиентами, когда:
нужно предоставить возможность частого повторения предыдущих заказов;
на сайте реализована дисконтная программа, связанная с объемом выкупа;
нужно предоставить визуальный интерфейс для отслеживания движения оффлайн заказов клиентов.
Импорт оффлайн заказов всегда подразумевает предварительную выгрузку номенклатуры, пользователей и контрагентов из 1С. Это необходимо для корректной привязки заказа к пользователям сайта, а товаров в нем к каталогу. Вопрос импорта пользователей и номенклатуры мы поднимали в предыдущей части статьи.
Штатный модуль обмена систем 1С-Битрикс: Управление сайтом и 1С прежде всего решает задачи передачи онлайн заказов с сайта в 1С. А вот импорт оффлайн заказов на сайт, несмотря на заявленную коробочную поддержку, работает довольно ограниченно и в большинстве случаев требует кастомизации.
Рассмотрим некоторые проблемы штатного импорта оффлайн заказов из 1С на сайт, с которыми мы встречались на практике.
Реквизиты и свойства оффлайн заказов
Если вы успешно настроили экспорт онлайн заказов с нужными свойствами и дополнительными реквизитами с сайта в 1С (профили обмена формы "Интеграция с 1С:Предприятие") и затем в аналогичной структуре данных xml импортируете оффлайн заказы, то по умолчанию не все поля, свойства и реквизиты будут сохранены. Чувствуется некоторое разочарование :(
По оффлайн заказам 1С-Битрикс импортирует лишь фиксированный список полей и реквизитов. Список зашит в код и не учитывает всех настроек профилей обмена.
Для заказа импортируются : узлы "Номер1С", "НомерВерсии", "Время", "Налоги", "Товары"; реквизиты "Статуса заказа ИД" (да, да, именно “СтатусА”), "Дата оплаты по 1С", "Дата отгрузки по 1С", "Отменен".
Для контрагента импортируются узлы "Ид", "НомерВерсии", "ОфициальноеНаименование", "ПолноеНаименование", "Наименование", "ИНН", "КПП", "КодПоОКПО", "ЕГРПО", "ОКВЭД", "ОКДП", "ОКОПФ", "ОКФС", "АдресРегистрации", "ЮридическийАдрес", "Адрес", "Контакты", "Представители".
В процессе тестирования и отладки обмена оффлайн заказами по указанным полям бывает нужно дополнительно (к настройкам, произведенным по онлайн заказам) настроить профили обмена на стороне сайта, чтобы данные сохранялись в нужном месте.
Для импорта других данных нужно написать немного кода… . .
В нашей практике, например, не хватало данных по импортируемым свойствам (в т.ч. реквизитам) оффлайн заказов, а также по банковским сведениям ("Наименование банка", "БИК", "Расчетный счет", "Корреспондентский счет").
Правильно, если кастомизация импорта оффлайн заказов будет учитывать список существующих на сайте свойств заказов по типам плательщиков и настройки профилей обмена с 1С (на уровне кода это потребует работы с таблицей свойств b_sale_order_props и таблицами дополнительных реквизитов профилей обмена b_sale_bizval и b_sale_bizval_code_1c).
Количественный учет и резервирование товаров.
Перед тем, как я раскрою особенности импорта оффлайн заказов при включенном количественном учете, нужно объяснить механизм его действия. Это даст представление о том, что происходит с остатками товаров на сайте при обмене.
Для запрета реализации товаров, которых нет в наличии (с нулевым остатком), следует использовать количественный учет товаров (и, возможно, их резервирование).
Количественный учет активируется настройкой "Включить количественный учет" модуля "Торговый каталог".
Включенный количественный учет регулирует порядок уменьшения остатков товаров.
Событие, в связи с которым остаток уменьшается, определяется настройками поля "Товар резервируется" настроек модуля "Интернет-магазин" (возможные варианты: при оформлении заказа, при частичной оплате заказа, при полной оплате заказа, при разрешении доставки, при отгрузке).
Одновременно с количественным учетом может включаться резервирование товара (настройка "Включить резервирование" модуля "Торговый каталог"). Условия резервирования устанавливаются в настройках модуля "Интернет-магазин" (блок "Настройки резервирования товара"). Как это работает?
С заказом происходит событие инициализации резервирования (из настройки “Товар резервируется”).
Для каждого товара в этом заказе уменьшается его остаток (поле “Доступное количество”) согласно числу заказанных товаров. И пропорционально увеличивается зарезервированное количество.
Резервирование сохраняется в течение установленного настройками срока. Если никаких изменений по заказу за это время не происходит, резерв снимается (пропорционально уменьшается зарезервированное количество, увеличивается остаток).
Списание резерва (уменьшение зарезервированного количества без увеличения остатка) происходит в момент отгрузки товаров (в документе отгрузки заказа приходит статус "Отгружено").
Если в настройках модуля "Интернет-магазин" установлен чекбокс "Разрешать отгрузку при разрешении доставки", то списание зарезервированного товара произойдёт автоматически при разрешении доставки (статус "Доставка разрешена" в документе отгрузки).
Параллельно со списанием остатков товаров в системе 1С-Битрикс при включенном количественном учете, остатки на сайте могут (должны) обновляться и импортом номенклатуры из 1С.
Для онлайн заказов обычно не возникает расхождений в значениях остатков товаров, рассчитываемых сайтом и приходящих из 1С.
А вот по оффлайн заказам включение количественного учета может вызывать вопросы.
Например, в нашей практике в Интернет-магазине клиента был включен количественный учет без резервирования товаров, остатки Битрикс списывал на сайте при полной оплате заказа. Дополнительно остатки обновлялись импортом номенклатуры из 1С.
При штатном импорте оффлайн заказов с включенным количественным учетом наблюдались такие проблемы:
количественный учет сайта не различал источник заказа (оффлайн или онлайн), списывая остатки по оплаченным оффлайн заказам, что приводило к ненужному обнулению остатков товаров каталога (а оффлайн заказов было много);
оплаченные оффлайн заказы, количество товаров в которых было больше, чем остатков этих товаров в каталоге, не выгружались на сайт совсем.
Решение указанных проблем потребовало кастомизации импорта заказов на стороне 1С-Битрикс.
Каждый заказ со всеми сопутствующими документами (оплаты, доставки) обрабатывается обменом поочередно. Поэтому для оффлайн заказов в начале импорта на сайт мы отключаем количественный учет, а в конце — включаем снова (сбрасывая системный кеш). Таким образом онлайн заказы участвуют в обмене с количественным учетом, а оффлайн без него.
У этого решения есть нюанс: при наличии в одном пакете заказов, импортируемых из 1С, одновременно полностью оплаченного онлайн заказа и полностью оплаченного оффлайн заказа (т.е. при одновременной полной оплате этих заказов), отключение количественного учета для оффлайн заказа формально происходит (т.е. настройки меняются), но остатки по оффлайн заказу все же списываются (чтобы это понять, мы ставили отладку в коде импорта заказов в Битрикс).
Настройки узла обмена в 1С не позволяют разделить обмен онлайн и оффлайн заказами (можно только включить/отключить импорт оффлайн заказов на сайт), а еще более глубокое погружение в ядро продукта 1С-Битрикс для анализа и исправления ситуации может потребовать значительного объема времени.
Самым быстрым решением здесь служит установка параметра "Количество контейнеров в пакете", равным 1 (единице), в настройках узла обмена на стороне 1С.
Таким образом, в файле импорта всегда находится информация только по одному заказу, без пересечения онлайн и оффлайн заказов. Костыль? Костыль! Но в описываемом кейсе он сэкономил много времени.
Другие ошибки обмена
Для оффлайн заказов наблюдали еще такую ошибку: "Попытка увеличить количество товара в отгрузке до количества, которое превышает не отгруженное в заказе".
Причиной этой ошибки, если ваш каталог не содержит торговых предложений (SKU), может служить указание в xml-файле обмена в составе заказа некоторого товара несколько раз - с разным количеством заказанных товаров, а в отгрузке только один раз - с суммарным количеством. В этом случае следует на стороне 1С в xml-файле выгрузки для заказа объединить записи по идентичным товарным позициям в одну. Например, если раньше в составе заказа “товар А” был указан дважды с количеством 8 400 шт. и 1 600 шт., а в отгрузке только один раз - с количеством 10 000 шт., то теперь и в заказе, и в отгрузке "товар А" указывается только по одному разу с количеством в 10 000 шт.
Заключение.
Сложно подробно и при этом весело и задорно (чтобы вы не уснули на полпути) описать все тонкости обмена сайта с 1С, эта тема неисчерпаема и, прямо скажу, “на любителя”.
Надеюсь, что та информация, которой я поделилась, окажется вам полезной и приоткроет завесу тайны, висящей над затронутой темой для любого, кто впервые сталкивается с обменом.
