5 проблем при интеграции 1С с сайтом

Сначала давайте определимся что такое обмен. Клиенты как правило под обменом подразумевают две вещи: загрузка и актуализация каталога товаров на сайте и передача заказов клиентов в 1С. Назовем это «постановкой задачи от клиента».

Теперь определимся что такое сайт. Для простоты мы возьмем сайт на CMS “Битрикс”. Однако структура файлов обмена как правило на других CMS приближена к битриксовскому и серьезных отличий не бывает.

Теперь обозначим какая 1С. Как правило торговые фирмы уже имеют 1С:Управление торговлей с собственным модулем обмена, реже 1С:Комплексная автоматизация. В редких случаях может быть 1С:Розница или даже 1С:Бухгалтерия. У последнего решения нет типового модуля обмена — его придется писать программистам.

Общий порядок настройки достаточно простой. В минимальном формате нам нужно наполнить каталог товаров на сайте данными о товаре, изображениями, ценам. Дополнительно могут быть выгружены остатки товаров, скидки, склады. После этого, если сайт сделан хорошо, то у посетителей сайта появляется возможность формировать заказ на реальные товары.

Вернемся к постановке задачи от клиента. К такой формулировке клиенты приходят как правило когда уже реализован сайт и необходимо реализовать интеграцию с 1С. И тут возникает

Внешне это может особо не проявляться. Например, номенклатура есть, но разные позиции, которые было бы неплохо сгруппировать на сайте (например один костюм разных размеров и/или цветов) заведен разной номенклатурой:

Наименование / Цена

Костюм «Абибас», 46, красный / 500

Костюм «Абибас», 46, Синий / 500

Костюм «Абибас», 47, красный / 500

В чем проблема. С точки зрения учетной системы, это три разные позиции номенклатуры, которых ничего не объединяет. Вы — человек, конечно видите, что начало наименования совпадает, и похоже это одна и та же позиция, отличающаяся размером и цветом. Но для автоматизированной обработки это неочевидно. Ни один нормальный программист не будет писать программный код, который будет основываться на строковом наименовании для анализа каталога. В этом случае настройку обмена приходится начинать даже не с обмена, а с реструктуризации всего каталога номенклатуры. А если учет ведется давно? То работа может затянуться на долгое время и вылиться в серьезные суммы для заказчика. Потому что номенклатуру придется подменить в существующих документах, перезакрыть месяц и убедиться в корректности учета (есть и другие варианты, но о них потом).

В данном случае, было бы удобнее сделать следующим образом:

Наименование/Характеристика/Цена

Костюм «Абибас»/46, красный (46, синий; 47, красный) / 500

Это не единственно верный способ учета размеров это один из вариантов, приемлемый для ведения бизнеса.

Отсюда вывод. Настройку каталога номенклатуры нужно проводить в самом начале ведения учета с консультантами.

Вот мы убедились, что структура каталога у нас корректная, красивая. И может выгружаться на сайт. И тут может возникнуть

Что делать в таком случае? Если количество позиций до 1000, то этой проблемы не будет. В противном случае, выгрузку каталога придется разделять по времени и видам выгрузки. Как правило мы делаем такое расписание:

- Выгрузка товаров (изменения, цены, остатки). - Штатная периодичность обмена 60 минут

- Выгрузка товаров (полная, с изображениями). Штатная периодичность обмена 1 раз в сутки, ночью

В особо тяжелых случаях, полная выгрузка товаров разделяется по группам номенклатуры, и разносится по дням недели.

Кроме всего прочего, ваш сайт может содержать различные конфигураторы, компоновщики групп номенклатуры. А для этого должны быть реквизиты, обеспечивающие фильтрацию номенклатуры по различным свойствам. Пример. Вы торгуете кухонными мойками. Одна и та же мойка может быть установлена четырьмя различными вариантами. Такие свойства мы называем "множественными" и типовыми средствами 1С они не создаются вообще. Их можно создать с помощью программиста, изменив конфигурацию (и механизм выгрузки на сайт). Или пересмотреть способ внесения свойств. В частности в проекте с мойками мы решили сделать 5 различных свойств булевского типа:

Вид установки фронтальный да/нет

Вид установки впотай да/нет

и т.д.

Это не очень удобно с точки зрения визуального оформления, но идеально для реализации фильтров на сайте. И если таких вариантов немного (до 7) - это вполне выход.

Иногда бизнес-процессы клиента построены так, что операторы вносят данные и в 1С и в CMS. Это принципиально неверная позиция. Потому как операторы могут изменить один и тот же объект и в 1С и в CMS. А потом удивиться, что их изменения не сохраняются.

И битрикс и 1С обладают большим функционалом по учету. Кому-то удобно работать в одной, кому-то в другой. Необходимо выбрать ту систему, в которую будут вноситься данные и запретить вносить данные в другую.

После указания каталога номенклатуры, настройки расписания и перечня выгружаемых данных можем приступать к настройке обмена заказами.

Является частным случаем обмена документами.

При обмене заказами в целом проблем не возникает. Стандартная для наших клиентов частота обмена - 5 минут. И гораздо удобнее, если вся номенклатура уже внесена в 1С, а не "прилетает с заказом" (т.е. предварительно настроен и запущен обмен товарами)

Так сложилось, что наша страна очень большая и структура адреса - достаточно сложная. Сначала был КЛАДР (КЛассификатор АДРесов), потом ФИАС (Федеральная Информационная Адресная Система). Де-факто сейчас используются все возможные классификаторы + свободный ввод адреса. Все это фактически не дает со 100% уверенностью корректно выгрузить адрес, введенный клиентом. Выход: передача адреса в текстовом виде и ручная обработка адреса оператором на этапе модерации заказа.

Таким образом мы видим, что настройка обмена между 1С и торговым сайтом может пройти довольно быстро, а может повлечь за собой глобальные изменения структуры каталога, способов хранения адресной информации и даже видоизменения бизнес-процессов компании.