Рано или поздно встает вопрос обмена данными сайта интернет-магазина с 1С. Например, это сверка остатков и цен, или даже синхронизация по заказам и документам. Но не все до конца понимают, как она происходит. В большинстве случаев обмен идет через стандарт xml-файлов CommerceML. О нем и пойдет сегодня речь, а также расскажу о своем опыте нестандартной синхронизации 1С с сайтом или любыми другими системами.
Сегодня поговорим, вкратце, про обмен данными сайта и 1С-ки. Очень часто вопросы возникают у меня на консультациях по поводу вот этих синхронизаций, очень многие предприниматели очень поверхностно понимают, как это работает. Я постараюсь вкратце все это дело объяснить.
Статья создана на основе субтитров видео
Когда вы работаете в одной системе – это гораздо лучше, чем когда в разрозненных. И эти системы нужно как-то и синхронизовать между собой, по заказам, по документам, по складам, по наличию, по ценам и так далее. Это для современных интернет-магазинов достаточно важно, потому что данные должны быть актуальными и там, и там. Т.е. их нужно между собой синхронизовать. И для этого есть определенный обмен данными, про который большинство людей знает, но некоторых вводят в заблуждение, например, какие-то движки, в названии которых есть «1С», например, это 1С-Битрикс.
Некоторые думают, что у Битрикса система как-то синхронизируется с сайтом гораздо лучше, чем у других. На самом деле тут ничего подобного нет. Ну, по крайней мере, если мы говорим о каких-то популярных CMS-системах. И штука здесь в том, что есть некий определенный стандарт, который разработан 1С-кой, называется он CommerceML. Это такой xml-файлик с определенной структурой. Также как мы делаем выгрузку на Яндекс.Маркет или куда-то в прайс-агрегаторные площадки, то обычно формируется какой xml-файлик со своими тегами. В теги прописываются какие-то определенные переменные.
CommerceML – это xml-стандарт от 1С
В принципе, тут формат приблизительно такой же, только чуть более сложный, чуть больше тегов всевозможных погружается. Вы здесь может можете видеть на примере, что есть некий «Ид» – это уникальный идентификатор, это некий код, который не повторяется в системе больше нигде.
Дальше у нас есть штрих-код, есть наименование товара, есть какие-то характеристики (если вы хотите вести в 1С-ке какие-то товары и чтобы они уже падали на сайт. Чтобы не работать какому-то пользователю в 1С, каком-то на сайте, чтобы это все делалось в единой системе, это достаточно удобно). Это можно здесь сделать, этот стандарт единый, и его все разработчики CMS-систем используют. Сложностей здесь особых возникать не должно! Что в Битриксе будет работать, что в любой другой системе.
Если вы упираетесь именно в плохую синхронизацию с чем-то, то, скорее всего, вы уперлись именно в стандарты самого CommerceML, где, возможно, что-то не предусмотрено, потому что там реально не предусмотрено очень много, что может сегодня пригодиться. И иногда возникает потребность в том, чтобы написать свой некий стандарт, это тоже достаточно несложно, и по такому пути в свое время пошел я. Мы посидели, подумали, «поковыряли» этот CommerceML и поняли, что нам (т.к. у меня было несколько систем, помимо сайта и 1С-ки, которые нужно было вместе синхронизовать) CommerceML немножко не подходил, потому что нужно было передавать определенные другие данные, которые не предусмотрены этим стандартом.
И мы просто решили написать свой собственный стандарт под свою компанию. Как уже говорил, ничего сложного нет, разрабатывается некое ТЗ, мы задаем теги и прописываем что в эти теги должно записываться из базы данных 1С или сайта. И дальше мы берем двух программистов, одного 1С-ника, другого веб-программиста, который может для сайта написать. Он пишет скрипт выгрузки и парсинга этого xml-файла и все! И дальше 1C-ка выгружает этот xml-файлик и кладет на хостинг. Сайт приходит и ответственно забирает его с хостинга, парсит, получает все эти данные из файлика, и записывает в базу данных. И наоборот, если нам нужно по заказам сделать синхронизацию, то мы с сайта выгружаем в какой-то момент (допустим, раз в пять минут или раз в час, в зависимости от того на сколько вам быстро нужно синхронизировать все это дело). Т.е. вы выгрузили это в xml-файлик, положили на хостинг, пришла 1С-ка, взяла этот файлик с хостинга, распарсила и записала в нужные свои регистры все данные.
Таким вот методом, достаточно простым и топорным происходит вся эта синхронизация. Конечно синхронизаций существует разных много, можно с десяток разных придумать, минуя эти файлики по старинке. Сейчас мы на них останавливаться не будем, если какие-то вопросы у вас есть, можете задать в комментариях. Может быть описать какие-то ситуации, что у вас не получается. Если я знаю ответ на этот вопрос, я вам постараюсь более-менее развернуто в комментариях ответить.
Предусматривайте обратную связь
Плюс я ещё рекомендую предусматривать «обратную связь». С чем я тоже столкнулся, и что мы не учли на начальном этапе и потом дописывали. Это когда, например, у вас может упасть сайт на какое-то время (DDOS-атака, например, происходит на сервер), и у вас какое-то время (две – пять минут, или может быть даже больше) сайт недоступен. Если 1С-ка попытается записать на хостинг этот файлик, то у нее ничего не получится, потому хостинг этот самый не недоступен. И получится то, что у вас какая-то синхронизации может не пройти. Например, вы синхронизацию делайте раз в сутки, у вас эта синхронизации в какой-то момент не прошла, и вы уверены, что у вас на сайте и в 1С актуальная информация, а оказывается, что на сайте у вас вчерашняя информация.
И тоже самое по заказам, если по какой-то причине что-то там не прошло с сайта в 1С-ку, то у вас какие-то заказы могут просто в процессе потеряться. Менеджеры их не обработают, естественно клиенты начнут звонить через какое-то время по тем заказам, которые потерялись – «Где мой заказ? Мне в корзине было написано, что привезете сегодня, уже два дня прошло, еще никто ничего мне не привез!». И напишет какой-то там гневный отзыв. Чтобы этого не происходило, нужна «обратная связь», когда 1С-ка передает этот файлик, она должна записать, что все окей, файлик передан, все отлично! И сайт, когда он взял этот файлик, обработал, все эти данные должен в лог записать, что все отлично обработано, все окей.
И потом, случае чего, желательно предусмотреть чтобы какая-то уведомлялка в какой-то системе появлялась, что если в лог записано, что произошла ошибка, чтобы это было видно каким-то ответственным лицам. Чтобы они могли предпринять какое-то ручное решение и сделать вручную эту самую синхронизацию.
Ну и минусом CommerceML является то, что, например, нет обратной связи по заказам. У вас с сайта данные пришли по заказам, но в заказе (на электронике приведу пример) клиент заказал ноутбук, он один в заказе – номер заказа такой-то, ноутбук такой-то. Мы это посмотрели, увидели в 1С-ке, у нас все синхронизовалось и дальше. И дальше мы звоним клиенту, с ним общаемся, и выясняется, что клиент хочет дозаказать что-то. Он хочет дозаказать сумку, он хочет дозаказать мышку, он хочет дозаказать внешний жесткий диск. В общем мы состав заказа в 1С поменяли. А на сайте этот номер заказа числится с одним ноутбуком.
Даже может случиться ситуация, что у нас не оказалось этого ноутбука или клиент в процессе разговора передумал, и мы поменяли на какой-то другой ноутбук. И дальше, когда заказ закрыли (изменили заказ и сохранили) у нас эти данные не уйдут на сайт. У нас на сайте если и придет синхронизация, то она придёт что заказ такой-то отгружен и оплачен. Но в личном кабинете на сайте у вашего клиента будет числиться тот первый заказ, который и был им сделан. И соответственно будет косяк с начислением каких-нибудь бонусов (если у вас это предусмотрено) и так далее.
Это не очень хорошо для каких-то более-менее крупно-средних магазинов. Для мелкого это еще бы куда ни шло, но для каких-то серьезных магазинов все-таки должна быть настроена обратная связь. И 1С должна будет возвратить данные по заказу, что данный заказ был изменен, состав этого заказа и т.д. Чтобы в личном кабинете клиент уже увидел эту информацию.
