Облачный каталог товаров на 1C

Предыстория

Почти на каждом IT-проекте, связанном с 1С, я сталкиваюсь с мастер-данными по товарам (а точнее, с их отсутствием). Для начала опишу наиболее запомнившиеся примеры.

Выгрузка каталога товаров из 1С в другую 1С

Компания занимается оптовой продажей автозапчастей. В основном отечественные запчасти, но и иномарки есть, а заодно и шины, ГСМ, аксессары и т.д. Учетная система - УТ 10.3, разумеется, сильно кастомизированная.

Однажды заходит в отдел ИТ руководитель отдела продаж и говорит: клиент установил у себя 1С:Управление Торговлей 11 и хочет загрузить к себе наш справочник “Номенклатура”. Целиком, как есть. Аргументы: клиенту надо с чего-то начать работать. Завести по-быстрому карточки товаров и провести инвентаризацию. А нам это надо, потому что клиент архиважный. И он даже приехал лично за пару сотен километров и привез с собой системный блок с чистой базой. Вот системник у входа уже стоит, а клиент вечером поедет обратно. Далее происходит краткая дискуссия с руководством на тему очередности выполнения задач, по результатам которой принято решение все-таки сделать. Смахнув пыль с КонвертацииДанных, собираем на коленке выгрузку-загрузку (или дорабатываем типовую, которая уже не взлетает из-за кастомизации), довольный клиент едет домой.

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

Загрузка прайс-листа ламината и линолеума

В годы фриланса попадается очередная задача по загрузке прайса одной компании из Excel. Создать карточки товаров в 1С, установить цены, все как обычно. Прайс содержит два раздела: ламинат и линолеум. Попотеть приходится из-за двух особенностей. Во-первых, в данном файле товары не имеют каких-либо однозначных идентификаторов (кодов, например). Во-вторых, там довольно много полей, каждое из которых важно для загрузки: класс, коллекция, размеры, вес и прочее. Загрузка написана, деньги получены, компания-заказчик спустя какое-то время пропадает из виду и, по моим предположениям, закрывается насовсем. Мысли о том, что, несмотря на полученные деньги, работа проведена впустую, расстраивают до сих пор.

В том же году, выполняя заказы для другой компании, я натыкаюсь в справочнике “Номенклатура” на знакомые позиции ламината. Из любопытства задаю вопросы отделу снабжения: как заносите эти позиции в справочник и как обновляете цены. Ответ - “разумеется, вручную”.

Спустя несколько лет в кулуарах Инфостарта-2015 удается немного пообщаться с 1С-разработчиком из компании - производителя этого самого ламината. На мой рассказ она с удивлением говорит: “Дак у нас же веб-сервис для этого есть, специально писали”. Жалею, что раньше этого не знал ни я, ни мои клиенты.

EDI

Как работает продуктовый ритейл: торговые сети заказывают какой-то товар у своих поставщиков через электронные сервисы. Заказ - это файл, в котором указан список желаемых товаров. В каждой строке этого списка содержатся идентификаторы данного товара, в общем случае их может быть три: код в учетной системе поставщика, код в учетной системе покупателя, GTIN (тот самый штрихкод, который наклеен на упаковке). И в подавляющем большинстве случаев код поставщика в сообщении отсутствует. Если на пальцах, то данный диалог выглядит так: “Поставщик, привези мне товар. Я не знаю, как он у тебя в базе обозначен, но у меня он заведен вот с таким названием и кодом, подбери что-нибудь”. Это порождает гигантское количество проблем с сопоставлением товаров между учетными системами покупателя и поставщика. Например, у покупателя товар учитывается в штуках, а у поставщика - в упаковках по 10 штук. И вот вместо коробки майонеза покупателю едет фура, загруженная майонезом под завязку.

Любое внедрение информационной системы на 1С, содержащей блок учета товаров, принято начинать с определения структуры справочника “Номенклатура”. Будут ли использоваться характеристики? Будет ли фасованный товар новым элементом справочника или новой единицей измерения? Необходимо ли штрихкодирование? Информация о весе/габаритах единиц товара? Ошибки на этом этапе способны погубить проект чуть позже, особенно если речь идет о производстве.

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

Загрузка прайсов поставщиков, поиск соответствий

У компании несколько поставщиков. Многие из них предоставляют прайсы в Excel. Кто-то по почте присылает, кто-то держит в открытом доступе. Порядок и состав колонок нигде не повторяется. Задача - автоматизировать загрузку и обновление данных прайсов в 1С, полуавтоматическое сопоставление своей номенклатуры с номенклатурой поставщика. Задача решена (в том числе на основе предыдущих работ в этой области), деньги получены в полном объеме, в голове вертится вопрос “доколе?”.

Текущая ситуация

Думаю, каждый из вас сталкивался с тем или иным проявлением одной и той же проблемы, которая описана в самом начале: отсутствие внятного каталога товаров каждой компании с однозначной идентификацией элементов в нем. Чтобы заказать что-то у поставщика, хорошо бы дать ему полную информацию о том, что именно мы заказываем. Хотя бы внутренний код товара и единицы измерения (характеристику - при использовании). Чтобы мониторить изменение цен поставщиков, необходимо иметь связки между своими товарами и товарами поставщиков, а для этого нужны идентификаторы. Для расчета суммарного веса товаров при доставке автотранспортом нужны веса по каждой позиции. Эти веса обычно есть в учетной системе производителя, но кто их выкладывает в открытый доступ?

Простой поиск слов “Загрузка из excel” по Инфостарту выдает 670 публикаций. Попробуйте интерпретировать эту цифру.

Что уже взлетело и не взлетело

Тема отнюдь не нова, ей больше лет, чем мне. Есть две великолепные статьи по теме управления мастер-данными: практика в Мастер-данные на перекрестке торговых путей и теория в Mom and Dad`s Misery. Решения MDM выпускают множество компаний. Из зарубежных - например, IBM, из наших - Axelot (как раз на 1С). Стоимость таких решений: Axelot MDM - 450 000 р, IBM выдает цены только по запросу (если кто знает, напишите, мне просто любопытно количество нолей).

Известные мне попытки организовать каталог мастер-данных в большинстве случаев провалились по следующим причинам:

1. Построение хорошего, качественного, структурированного хостинга каталогов выливается в тысячи человекочасов. Возникает вопрос окупаемости данного сервиса. Разработчиков надо хотя бы кормить. Три пачки доширака в день - это примерно 40 000 рублей в год. Умножаем на несколько разработчиков и несколько лет, при условии, что кипяток бесплатный, а разработчики неприхотливые и отчаянно живучие.

2. Зачастую наполнение такого каталога требует предварительного приведения в порядок локального каталога организации, которая его предоставляет. Избавление от дублей, исправление орфографических ошибок, верификация штрихкодов и так далее. Исполнители на стороне заказчика не всегда заинтересованы в дополнительной работе.

3. Хорошо, нашлись 2-3 компании, которые исправили все ошибки в своих локальных каталогах, выложили их в облако. Мало кто в это облако будет ходить тех пор, пока там не будет размещено несколько сотен таких каталогов. И мало кто хочет размещать в том облаке свои каталоги до тех пор, пока туда никто не ходит.

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

Поэтому текущие решения на рынке можно условно поделить на 2 части:

1. Крупные решения для крупных компаний. Длительное и тяжелое внедрение, перестройка текущих бизнес-процессов, но конечный результат, наверное, стоит потраченных денег и усилий (очень больших денег и усилий, вспоминаем IBM и Axelot).

2. Решения попроще для средних и маленьких компаний, вроде Agorab2b. Основной функционал - витрина товаров с остатками и ценами, сопоставление товаров в разных каталогах, быстрый обмен заказами. Это ускоряет окупаемость сервиса, но пока не предполагает работы именно с мастер-данными.

Да, есть еще 1С-Сеть. Также платная (хотя ценник вроде гуманный), ориентирована в первую очередь на EDI. Каталог товаров не хостится, а передается клиенту напрямую по запросу.

При чем здесь 1С

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

1. Принимать в себя каталог товаров в виде XDTO-пакета;

2. Хранить в себе этот каталог;

3. Выдавать его наружу по запросу.

К сервису прилагается клиентская обработка, работающая в двух режимах:

1. Выгрузка каталога на сервер;

2. Загрузка его в произвольную базу и создание элементов в справочнике “Номенклатура” по полученным данным.

Этим уже можно решить задачу передачи каталога товаров между разными 1С “как есть”, описанную в начале. А отправлять пылиться на полке жалко. Сейчас я в тупике: непонятно, куда двигаться дальше, и стоит ли.

Список задач, которые можно не спеша решить в данном продукте, предварительно таков:

1. Хостинг каталога товаров со всеми значимыми реквизитами каждой группы и раздача его всем желающим. Цены, остатки - по желанию.

2. Полуавтоматическое сопоставление товаров между каталогами покупателя и поставщика.

3. Автоматическая загрузка прайсов разных поставщиков, сопоставление их собственным товарам. Выдача результатов загрузки по API в единой структуре. Мониторинг цен. Да, я говорю о загрузке из Excel, пока без нее никак.

4. Черт с ним, формирование прайс-листов в Excel и выгрузку их куда угодно по расписанию тоже можно сделать.

5. Формирование заказов поставщикам по разным правилам (наличие на складе поставщика, поставщик с минимальной ценой и т.д.).

6. Выгрузка каталога товаров в Яндекс.Маркет. Незачем писать ее под каждую конфигурацию 1С, если конфигурация будет одна. Также можно выгружать в популярные CMS, если не планируется вести обмен заявками.

7. Получение свойств товаров из других каталогов через связи. Например, в вашем каталоге товаров не указан вес каждой позиции. А у вашего поставщика - указан. Сопоставляете товары в каталогах, получаете доступ к атрибутам вашего поставщика, среди которых есть и вес. Загрузить их после этого в свою учетную систему уже несложно. Штрихкоды по той же схеме.

8. “Маленький EDI”. Для начала, например, обмен заказами. Покупатель отправляет документ “ЗаказПоставщику” в облако, сервис конвертирует товары из каталога покупателя в товары поставщика и поставщику отправляет. Самые распространенные варианты - e-mail и FTP, можно сделать и пассивную выдачу новых заказов по API.

9. Отсюда же вытекает сбор статистики. Сезонные коэффициенты по товарам, дефицитные позиции и т.д. Это если сервис будет молотить безостановочно хотя бы пару лет ))

10. Механизмы уведомлений. Например, банальная рассылка клиентам e-mail о снижении цен на свои товары. Как думаете, многие клиенты ищут эти красные строчки с пометкой “Распродажа” в Excel на 30 тысяч позиций?

11. Настройка валидации описания товаров. Например, в админке можно указать, что для товаров категории “Автошины” обязательно должны быть указаны свойства “Радиус”, “Высота профиля”, “Ширина профиля” и “Сезонность”, причем “Сезонность” имеет 3 возможных значения. Владельцу каталога приходит уведомление о товарах, в описании которых эти правила нарушены.

12. Исправление неточностей в характеристиках товаров. Например, у вас 5% артикулов содержат ошибки. При этом вы располагаете каталогом товаров производителя, у которого эти артикулы заведены корректно. Проводите сопоставление товаров, запускаете сравнение, выявляете неточности, исправляете.

13. Интеграция с прочими каталогами товаров. Например, Autodealer.

14. Поиск поставщиков/покупателей своего товара.

15. Васюки переименовываются в Нью-Москву Ваши идеи.

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

Можно ли на этом заработать? Сложно сказать. Если такое решение будет по-настоящему востребовано, можно развернуть виртуалку в Амазоне, лицензировать ее и раздавать клиентские обработки для выгрузки/загрузки. Этот вариант явно будет в какой-то мере платным (как минимум надо оплачивать хостинг и лицензии 1С), но возможность бесплатно скачать CF и развернуть его в своей сети останется. Минус локальной установки очевидно будет заключаться в недоступности каталогов из общего репозитория. Хотя можно и о репликации подумать. Плюс - там же, где и минус: например, DDOS атака на общий репозиторий не помешает локальному.

Почему веб-сервис именно на 1С? “Просто потому, что могу”. Встроенная поддержка веб-сервисов, хранение данных, возможность сделать админку на управляемых формах через браузер - и все это в привычной среде разработки. Понятно, что реально большие объемы данных 1С может и не потянуть. Если проект вдруг станет настолько большим и востребованным, то его можно будет портировать на MongoDB + ElasticSearch + (что угодно), оставив прежний API.

Для гиков перечислю применяемые технологии/приемы:

1. Работа с XDTO. XSD-схемы. Никакого прямого парсинга XML.

2. Асинхронные обращения к серверу. При выгрузке каталога клиент передает ядру пакет данных и сразу получает ответ, а непосредственно запись пакета в таблицы происходит отдельным фоновым заданием.

3. Только управляемые формы в ядре.

4. Обычные и управляемые формы в клиентской обработке. Основная логика - в модуле объекта.

5. Максимальное отделение логики работы с конкретной конфигурацией от прочей логики (общение с сервером, отрисовка форм и т.д.).

6. Работа с СКД, само собой.

7. Веб-сервис на SOAP, планируется перевод на REST.

8. Сжатие крупных пакетов перед отправкой.

9. Минимальный набор RLS.

Планируется:

1. TDD\BDD, автотесты.

2. Синхронизация с GIT - для начала только в одну сторону, возможно, удастся таки настроить полноценный merge и компиляцию из исходников хотя бы для ядра.

3. Поиск товаров через ElasticSearch.

4. Работа клиентской части как регламентного задания. Поставил, настроил, забыл.

5. Парсинг Excel - исключительно через ADODB. Предварительно возможно конвертировать колонки в нормальный текстовый формат - код имеется, осталось встроить.

6. Управляемые блокировки в некоторых потенциально узких местах.

7. Возможность кастомизации клиента и ядра без снятия с поддержки (“подключаемый модуль”, если кто знает).

8. Загрузка каталогов в формате CommerceML. Т.е. интеграция с более-менее типовыми конфигурациями за 5 минут силами одного товароведа.

9. COM-соединение как альтернатива HTTP при локальной установке.

10. Metadata.js как альтернативная админка ядра.

Признайтесь себе, вы когда-нибудь хотели поучаствовать в opensource проекте на 1С?

Ближе к сути

Резюме: я предлагаю поработать над решением, которое не претендует на гигантский структурированный каталог мастер-данных, сертифицированный ECR\GS1. Решение состоит из 2 частей: конфигурация на 1С с веб-сервисом (“ядро”) и внешняя обработка для взаимодействия с ним (“клиент”). Оно может быть установлено локально и использоваться для решения каких-то отдельных задач, вроде той же загрузки прайсов или раздачи каталогов клиентам, может быть установлено в “облаке”.

Возможно, вы в своей компании собираетесь решать какую-то из перечисленных выше задач. Интересен ли вам такой продукт? Готовы ли вы поучаствовать в его развитии по описанной схеме? Хотя бы в качестве бета-тестировщиков?

Пример в файлах. Выгружать можно из УТ 10.3, загрузка пока реализована под Розница 2.1. Конфигурацию развернуть и опубликовать под Apache 2.2 (очень просто) или IIS (чуть сложнее).