Об этом и пойдет речь.
Предыстория
Почти на каждом IT-проекте, связанном с 1С, я сталкиваюсь с мастер-данными по товарам (а точнее, с их отсутствием). Для начала опишу наиболее запомнившиеся примеры.
Выгрузка каталога товаров из 1С в другую 1С
Компания занимается оптовой продажей автозапчастей. В основном отечественные запчасти, но и иномарки есть, а заодно и шины, ГСМ, аксессары и т.д. Учетная система — УТ 10.3, разумеется, сильно кастомизированная.
Однажды заходит в отдел ИТ руководитель отдела продаж и говорит: клиент установил у себя 1С:Управление Торговлей 11 и хочет загрузить к себе наш справочник “Номенклатура”. Целиком, как есть. Аргументы: клиенту надо с чего-то начать работать. Завести по-быстрому карточки товаров и провести инвентаризацию. А нам это надо, потому что клиент архиважный. И он даже приехал лично за пару сотен километров и привез с собой системный блок с чистой базой. Вот системник у входа уже стоит, а клиент вечером поедет обратно. Далее происходит краткая дискуссия с руководством на тему очередности выполнения задач, по результатам которой принято решение все-таки сделать. Смахнув пыль с КонвертацииДанных, собираем на коленке выгрузку-загрузку (или дорабатываем типовую, которая уже не взлетает из-за кастомизации), довольный клиент едет домой.
Спустя какое-то время я ушел фрилансить. А в той компании впоследствии еще несколько раз клиенты хотели получить каталог, но заниматься ими было уже некому и некогда. Один из таких клиентов, с которым недавно удалось пообщаться, в конце концов сделал угадайте что. Верно, написал свою загрузку товаров из Excel, поскольку прайс в Excel — единственное, что было в открытом доступе.
Загрузка прайс-листа ламината и линолеума
В годы фриланса попадается очередная задача по загрузке прайса одной компании из Excel. Создать карточки товаров в 1С, установить цены, все как обычно. Прайс содержит два раздела: ламинат и линолеум. Попотеть приходится из-за двух особенностей. Во-первых, в данном файле товары не имеют каких-либо однозначных идентификаторов (кодов, например). Во-вторых, там довольно много полей, каждое из которых важно для загрузки: класс, коллекция, размеры, вес и прочее. Загрузка написана, деньги получены, компания-заказчик спустя какое-то время пропадает из виду и, по моим предположениям, закрывается насовсем. Мысли о том, что, несмотря на полученные деньги, работа проведена впустую, расстраивают до сих пор.
В том же году, выполняя заказы для другой компании, я натыкаюсь в справочнике “Номенклатура” на знакомые позиции ламината. Из любопытства задаю вопросы отделу снабжения: как заносите эти позиции в справочник и как обновляете цены. Ответ — “разумеется, вручную”.
Спустя несколько лет в кулуарах Инфостарта-2024 удается немного пообщаться с 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 выдает цены только по запросу (если кто знает, напишите, мне просто любопытно количество нолей).
Известные мне попытки организовать каталог мастер-данных в большинстве случаев провалились по следующим причинам:
-
Построение хорошего, качественного, структурированного хостинга каталогов выливается в тысячи человекочасов. Возникает вопрос окупаемости данного сервиса. Разработчиков надо хотя бы кормить. Три пачки доширака в день — это примерно 40 000 рублей в год. Умножаем на несколько разработчиков и несколько лет, при условии, что кипяток бесплатный, а разработчики неприхотливые и отчаянно живучие.
-
Зачастую наполнение такого каталога требует предварительного приведения в порядок локального каталога организации, которая его предоставляет. Избавление от дублей, исправление орфографических ошибок, верификация штрихкодов и так далее. Исполнители на стороне заказчика не всегда заинтересованы в дополнительной работе.
-
Хорошо, нашлись 2-3 компании, которые исправили все ошибки в своих локальных каталогах, выложили их в облако. Мало кто в это облако будет ходить тех пор, пока там не будет размещено несколько сотен таких каталогов. И мало кто хочет размещать в том облаке свои каталоги до тех пор, пока туда никто не ходит.
Складываем все это и получаем, что дешевле заняться чем-то, что принесет денег прямо сейчас. Тем, что поможет навести какой-то порядок в каталогах нескольким тысячам компаний, но вряд ли когда-то окупится, заниматься не хочет никто.
Поэтому текущие решения на рынке можно условно поделить на 2 части:
-
Крупные решения для крупных компаний. Длительное и тяжелое внедрение, перестройка текущих бизнес-процессов, но конечный результат, наверное, стоит потраченных денег и усилий (очень больших денег и усилий, вспоминаем IBM и Axelot).
-
Решения попроще для средних и маленьких компаний, вроде Agorab2b. Основной функционал — витрина товаров с остатками и ценами, сопоставление товаров в разных каталогах, быстрый обмен заказами. Это ускоряет окупаемость сервиса, но пока не предполагает работы именно с мастер-данными.
Да, есть еще 1С-Сеть. Также платная (хотя ценник вроде гуманный), ориентирована в первую очередь на EDI. Каталог товаров не хостится, а передается клиенту напрямую по запросу.
При чем здесь 1С
Ради интереса за несколько вечеров на коленке собран простенький веб-сервис в виде конфигурации на 1С 8.3, который может:
-
Принимать в себя каталог товаров в виде XDTO-пакета;
-
Хранить в себе этот каталог;
-
Выдавать его наружу по запросу.
К сервису прилагается клиентская обработка, работающая в двух режимах:
-
Выгрузка каталога на сервер;
-
Загрузка его в произвольную базу и создание элементов в справочнике “Номенклатура” по полученным данным.
Этим уже можно решить задачу передачи каталога товаров между разными 1С “как есть”, описанную в начале. А отправлять пылиться на полке жалко. Сейчас я в тупике: непонятно, куда двигаться дальше, и стоит ли.
Список задач, которые можно не спеша решить в данном продукте, предварительно таков:
-
Хостинг каталога товаров со всеми значимыми реквизитами каждой группы и раздача его всем желающим. Цены, остатки — по желанию.
-
Полуавтоматическое сопоставление товаров между каталогами покупателя и поставщика.
-
Автоматическая загрузка прайсов разных поставщиков, сопоставление их собственным товарам. Выдача результатов загрузки по API в единой структуре. Мониторинг цен. Да, я говорю о загрузке из Excel, пока без нее никак.
-
Черт с ним, формирование прайс-листов в Excel и выгрузку их куда угодно по расписанию тоже можно сделать.
-
Формирование заказов поставщикам по разным правилам (наличие на складе поставщика, поставщик с минимальной ценой и т.д.).
-
Выгрузка каталога товаров в Яндекс.Маркет. Незачем писать ее под каждую конфигурацию 1С, если конфигурация будет одна. Также можно выгружать в популярные CMS, если не планируется вести обмен заявками.
-
Получение свойств товаров из других каталогов через связи. Например, в вашем каталоге товаров не указан вес каждой позиции. А у вашего поставщика — указан. Сопоставляете товары в каталогах, получаете доступ к атрибутам вашего поставщика, среди которых есть и вес. Загрузить их после этого в свою учетную систему уже несложно. Штрихкоды по той же схеме.
-
“Маленький EDI”. Для начала, например, обмен заказами. Покупатель отправляет документ “ЗаказПоставщику” в облако, сервис конвертирует товары из каталога покупателя в товары поставщика и поставщику отправляет. Самые распространенные варианты — e-mail и FTP, можно сделать и пассивную выдачу новых заказов по API.
-
Отсюда же вытекает сбор статистики. Сезонные коэффициенты по товарам, дефицитные позиции и т.д. Это если сервис будет молотить безостановочно хотя бы пару лет ))
-
Механизмы уведомлений. Например, банальная рассылка клиентам e-mail о снижении цен на свои товары. Как думаете, многие клиенты ищут эти красные строчки с пометкой “Распродажа” в Excel на 30 тысяч позиций?
-
Настройка валидации описания товаров. Например, в админке можно указать, что для товаров категории “Автошины” обязательно должны быть указаны свойства “Радиус”, “Высота профиля”, “Ширина профиля” и “Сезонность”, причем “Сезонность” имеет 3 возможных значения. Владельцу каталога приходит уведомление о товарах, в описании которых эти правила нарушены.
-
Исправление неточностей в характеристиках товаров. Например, у вас 5% артикулов содержат ошибки. При этом вы располагаете каталогом товаров производителя, у которого эти артикулы заведены корректно. Проводите сопоставление товаров, запускаете сравнение, выявляете неточности, исправляете.
-
Интеграция с прочими каталогами товаров. Например, Autodealer.
-
Поиск поставщиков/покупателей своего товара.
-
Васюки переименовываются в Нью-Москву Ваши идеи.
В действительности каждая из этих задач уже давно решена по отдельности. Я предлагаю собрать все воедино, упорядочить и выложить в открытый доступ, после чего постепенно наращивать функционал по схеме “дописал сам — поделись с другими”. В разработке ПО принципы коммунизма вполне оправданны.
Можно ли на этом заработать? Сложно сказать. Если такое решение будет по-настоящему востребовано, можно развернуть виртуалку в Амазоне, лицензировать ее и раздавать клиентские обработки для выгрузки/загрузки. Этот вариант явно будет в какой-то мере платным (как минимум надо оплачивать хостинг и лицензии 1С), но возможность бесплатно скачать CF и развернуть его в своей сети останется. Минус локальной установки очевидно будет заключаться в недоступности каталогов из общего репозитория. Хотя можно и о репликации подумать. Плюс — там же, где и минус: например, DDOS атака на общий репозиторий не помешает локальному.
Почему веб-сервис именно на 1С? “Просто потому, что могу”. Встроенная поддержка веб-сервисов, хранение данных, возможность сделать админку на управляемых формах через браузер — и все это в привычной среде разработки. Понятно, что реально большие объемы данных 1С может и не потянуть. Если проект вдруг станет настолько большим и востребованным, то его можно будет портировать на MongoDB + ElasticSearch + (что угодно), оставив прежний API.
Для гиков перечислю применяемые технологии/приемы:
-
Работа с XDTO. XSD-схемы. Никакого прямого парсинга XML.
-
Асинхронные обращения к серверу. При выгрузке каталога клиент передает ядру пакет данных и сразу получает ответ, а непосредственно запись пакета в таблицы происходит отдельным фоновым заданием.
-
Только управляемые формы в ядре.
-
Обычные и управляемые формы в клиентской обработке. Основная логика — в модуле объекта.
-
Максимальное отделение логики работы с конкретной конфигурацией от прочей логики (общение с сервером, отрисовка форм и т.д.).
-
Работа с СКД, само собой.
-
Веб-сервис на SOAP, планируется перевод на REST.
-
Сжатие крупных пакетов перед отправкой.
-
Минимальный набор RLS.
Планируется:
-
TDDBDD, автотесты.
-
Синхронизация с GIT — для начала только в одну сторону, возможно, удастся таки настроить полноценный merge и компиляцию из исходников хотя бы для ядра.
-
Поиск товаров через ElasticSearch.
-
Работа клиентской части как регламентного задания. Поставил, настроил, забыл.
-
Парсинг Excel — исключительно через ADODB. Предварительно возможно конвертировать колонки в нормальный текстовый формат — код имеется, осталось встроить.
-
Управляемые блокировки в некоторых потенциально узких местах.
-
Возможность кастомизации клиента и ядра без снятия с поддержки (“подключаемый модуль”, если кто знает).
-
Загрузка каталогов в формате CommerceML. Т.е. интеграция с более-менее типовыми конфигурациями за 5 минут силами одного товароведа.
-
COM-соединение как альтернатива HTTP при локальной установке.
-
Metadata.js как альтернативная админка ядра.
Признайтесь себе, вы когда-нибудь хотели поучаствовать в opensource проекте на 1С?
Ближе к сути
Резюме: я предлагаю поработать над решением, которое не претендует на гигантский структурированный каталог мастер-данных, сертифицированный ECRGS1. Решение состоит из 2 частей: конфигурация на 1С с веб-сервисом (“ядро”) и внешняя обработка для взаимодействия с ним (“клиент”). Оно может быть установлено локально и использоваться для решения каких-то отдельных задач, вроде той же загрузки прайсов или раздачи каталогов клиентам, может быть установлено в “облаке”.
Возможно, вы в своей компании собираетесь решать какую-то из перечисленных выше задач. Интересен ли вам такой продукт? Готовы ли вы поучаствовать в его развитии по описанной схеме? Хотя бы в качестве бета-тестировщиков?
Пример в файлах. Выгружать можно из УТ 10.3, загрузка пока реализована под Розница 2.1. Конфигурацию развернуть и опубликовать под Apache 2.2 (очень просто) или IIS (чуть сложнее).
грузаните туда прайс 1с — я подключусь.
(1) kwazi, Написал реквизиты доступа в ЛС.
Вообще судя по откликам, загрузка прайсов — самое животрепещущее. Видимо, с нее и начнем )
Это имеет смысл только если такой каталог будет бесплатен или стоить символических денег за подключение к сервису а не за каждую позицию в каталоге
В противном случае та же самая байда что и GS
(3) CheBurator, о том и речь )
(4) но нужна актуальность, ответственность и малая задержка при отсутствии информации или подозрении на ошибку.
А потом эту сверхбазу учёта всего заберёт яндекс или купит гугл…
(5) Зеленоград, но так как база будет поддерживаться сообщество Яша и Гугл будут лапу сосать
(5) Зеленоград, «малая задержка при отсутствии информации» — что вы имеете в виду? Можно поподробнее?
Ответственность за актуальность данных пока кажется логичным возложить на авторов каталогов. И дать возможность обратной связи от пользователей этих каталогов (запросы на уточнение некорректных данных). В форме «такая-то позиция в вашем каталоге, похоже, у вас неправильно указан вес, проверьте».
Начну с прайсозаливалки из экселей, посмотрим, что получится.
Приветствую!
Очень правильная идея, причём имеет множество прикладных проекций, кроме EDI.
Пробовал 2 года назад, но не осилил. Слишком много проблем с качеством информации.
Есть (были) несколько похожих проектов, которые перестали развиваться, а
вот такой ресурс гляньте, может пропустили.
с уважением,
IC>
(8) profche17, Добрый день!
IceCat и правда пропустил. Читаю описание, нравится их идеология. Не хватает какого-либо публичного API.
И они все-таки стараются стандартизировать описание товаров. До такого нашим производителям в большинстве случаев надо еще дорасти )) Мне пока кажется, что стратегия «давайте навыгружаем хотя бы что есть, и постепенно будем приводить в порядок» перспективнее.
А моей компании нужно как-то автоматизированно принимать заказы от клиентов, чтобы они сразу отражались в нашей базе)
О, я присоединяюсь!!!
Мне это очень важно, даже не представляете как важно до чёртиков!!!
—
Однако есть куча минусов — следующим сообщением, попробую обозначить тезисно.
—
И присоединюсь в следующем году — сейчас, извините, работа.
(10) Anesk, (11) Franco, жду подробностей в ЛС )) И с наступающим!
(11) Franco, послезавтра?))))
Пока мы не подсадим на единый каталог всех покупателей-бюджетников, работающих через тендерные заявки, света нам не видать. О чём я? О той самой глыбе, которая на самом деле портит всю картину по стандартизации работы. Вот ниже примеры.
—-
Добро пожаловать в мир тендерных закупок.
Вы думаете, как можно описать наименование требуемого товара так, чтобы на целой странице текста было много характеристик и не было понятно ничего? Тогда вам нужно тренироваться делать закупки в бюджетной организации.
-Вы указываете в заявке «Тарелки глубокие» с диаметром (или радиусом), цветом, оттенками цвета, возможным узором и каёмккою, глубиной и толщиной стенок и дна. И оформляете заявку для покупки в противотуберкулёзный диспансер. Для пациентов, больных туберкулёзом. Через пару недель после того как вам привозят тарелки со скандалом звоните продавцу и говорите «Мы имели ввиду миски!!! Заберите ваши грёбанные тарелки и срочно сёдня же привезите миски!!! Миски, не тарелки!». [Заберите тарелки, Карл, из противотуберкулёзного диспансера!!!].
И плевать нам, что у вас есть какой-то мастер-шмастер каталог…
-Мы желаем получить откат за то, что купили не то, что заказано, а то, что дешевле. Поэтому мы ставим в заявке болт и уже накрученная на болт гайка с резьбой 11,7 мм. (каковой не бывает, а продавец это проглядел среди десятка заказываемых позиций), причём поштучно. И нам всё равно, что болты продаются в килограммах и гайки к ним не прикручены и такого размера нету… У нас договрённость попилить деньги с конкретным продавцом. А, так выиграл тендер другой?! Ну, удачи ему, вот и пусть ищут непонятные гайки, это дело чести и выплаты издержек.
Мы не будем смотреть в каталог, иначе у нас не будет денег, и наши жёны не лягут с нами в постель (копирайт Эдди Мерфи «Поменяться местами»).
-Нам всё равно, что какой-то дурачёк внёс в ваш каталог краску в килограммах, нам серо-буро-малиновую посчитайте в литрах, а красно-голубую с продрес’ю — в банках.
—-
Это первый и самый важный шаг. Когда тендерные закупки пойдут через каталог, тогда и обычные покупатели по цепочке начнут его использовать.
PS. сразу предупреждаю ремарку: «В тендерном заказе нельзя указывать конкретную марку товара». Да, нельзя. Но характеристики можно же взять?
И ещё — «Вы собираетесь бороться с коррупцией?». Само собою, собираемся…
(13) Anesk, В ночь на послезавтра 🙂
Нет,конечно, я тоже человек и иногда нужно отключать мозг от работы. Но на праздниках — это точно.
(12)
И — самое главное — Вы задумали большое и хорошее дело.
Поздравляю с наступающими праздниками и желаю это дело продвинуть, а конкретно Вам — крепкого здоров’я и всяческих успехов. Вам и Вашим близким.
(9)
Приветствую!
>»давайте навыгружаем хотя бы что есть, и постепенно будем приводить в порядок»
найн, только не это, вы аккурат пойдёте по «моим» граблям.
Этот путь, только для тех, у кого ($$$) денег на контент_эдиторов.
Вот ещё один пример
и это печальный пример, когда идея хороша, но контент никакой.
Публичный API есть на IceCat и они готовы к любому сотрудничеству, вплоть до выгрузки подкаталогов
(во всяком случае так было 14 году).
IC>
и ещё, вот ссылочка на редакции 2014г. блок PRICAT вполне станадарт,
поддержать придётся.
(18) profche17, как раз оттуда поля и выдергиваю по мере необходимости. Поддержать придется обязательно, правда.
Первоначально конфигурация из статьи называлась «Прикатошная» )
(17) profche17, распишу поподробнее.
Есть несколько ситуаций, в которых подобный сервис может помочь.
1) Организация внедряет новую учетную систему (не обязательно 1С), переходит со старой или открывается с нуля. Надо быстро заполнить классификатор товаров. Практика показывает, что они будут рады хоть какой помощи в этом. Качество каталога, из которого они могли бы прогрузить данные, тоже не столь важно: ошибки они исправят уже в своей локальной базе, это все равно будет на порядок быстрее, чем ручной ввод. Тем более что при ручном вводе будет сделано еще больше ошибок, особенно при аврале (а обычно такие события происходят именно аврально). Отсюда следствие: хоть какой-то каталог лучше, чем вообще никакой. Если к нему прилагается еще и какой-то инструмент для массовой загрузки, товароведы будут просто счастливы. Принцип простой: находим какой-нибудь каталог в списке, открываем, жмем «загрузить вот отсюда и досюда», потом выправляем ошибки. Обычно для загрузки хватает минимума: название, единица измерения, штрихкод.
(17) profche17, ситуация 2.
У компании 30 тысяч наименований в справочнике и собственная доставка всего этого до клиентов. Им очень интересно видеть суммарный вес по каждой расходной накладной, чтобы понять, какую машину надо отправить на развоз: фуру, газельку или служебный форд фокус. Но вес в их классификаторе не заведен. Вес считают по простой формуле: общая сумма накладной в деньгах, деленная на 500 рублей. Это реальный факт. И формула работает при более-менее равномерном распределении отгружаемых позиций. Сложности начинаются, например, когда половина машины забита аккумуляторами (маленькие и тяжелые) или бамперами (легкие, но большие).
Итог — компания отправляет кладовщиков взвешивать имеющийся товар поштучно. Несколько месяцев кладовщики параллельно с основной работой занимаются взвешиванием этих 30 тысяч позиций.
Решение, которое видится мне: какой-то магией находим каталоги ПРОИЗВОДИТЕЛЕЙ всего этого товара и пытаемся вытащить этот вес из них. Производители часто располагают данными о весе и габаритах (хотя не всегда, и не всегда эти данные точны).
Вывод точно такой же: данные, точные хотя бы на 80%, лучше, чем вообще никаких данных. Плюс-минус 50 кг в машине особой роли не сыграют, а какие-то исключительные случаи можно обрабатывать по мере обнаружения. И желательно давать обратную связь об этом «хозяину» каталога: уважаемый, у вас в такой-то позиции указан вес 500кг, а я ее сейчас одной левой держу.
(17) profche17, ситуация 3.
У компании много клиентов (больше сотни, например). Каждый день поступают заявки на какой-то товар. Когда поток этих заявок зашкаливает за сотню, и в каждой из них не один десяток SKU, компания вынуждена содержать большой штат «менеджеров по продажам» (а де-факто обычных операторов). С другой стороны, каждый из клиентов данной компании закупается также и у ее конкурентов. Многие клиенты в этом случае пишут сопоставляют свой каталог товаров с каталогами всех своих поставщиков, пишут скрипты для загрузки прайсов, мониторят цены каждый день, заказывают там, где подешевле (и где есть в наличии). Им даже не так важны характеристики товаров их поставщиков: им главное видеть сравнение цены. Но отсюда неявно вытекает и возможность электронного обмена заявками: если они уже провели сопоставление товаров, то можно передавать поставщику заявки в электронном виде, непосредственно в его кодах. А отправлять удобнее как раз в своих. Т.е., я отправляю документ «Заказ поставщику» со своей номенклатурой, а мой поставщик получает «Заказ покупателя» уже с его номенклатурой. Примерно этим мы в Контур.EDI и занимаемся.
(17) profche17, и все эти ситуации вертятся вокруг одного и того же:
1) Нужен каталог товаров поставщика. Со всеми возможными характеристиками, свойствами товаров, со всеми ошибками.
2) Такой же каталог товаров покупателя.
3) Сопоставление этих каталогов.
После этого можно настраивать в каком-то виде EDI, мониторинг цен/остатков, поиск рынка сбыта (при достаточном количестве участников), быстрый слив неликвидных товаров (за счет публикации цен), заполнение логистических данных товара (хоть какие-то часто лучше, чем вообще никакие), можно устроить небольшой краудсорсинг в исправлении ошибок классификаторов, можно ускорять сопоставление товаров за счет уже существующих связок между разными участниками, можно попробовать добраться до каталогов производителей (и даже убедить их в необходимости сертификации по GS1), можно просто поиграть в Big Data.
Я пока вкрутил в текущую конфигурацию какую-то старую заливалку прайс-листов. Прайс-листы рассматриваю как источник все тех же каталогов. Если кому интересно, все лежит на гитхабе, скачивать можно будет оттуда.
(14) Franco, тендеры (особенно с бюджетниками) — отдельный мир. Там еще часто любят, например, в названии товара часть букв писать латиницей, чтоб нашли только избранные.
Буду рад видеть после НГ, все исходники есть на гитхабе, присоединяйтесь, буду постепенно обновлять.
Приём с латиницей, вроде, уже и всем известен, и технически заблокирован?
(25) Зеленоград, Давно не интересовался, хорошо, если заблокировали. Это просто еще один из индикаторов того, что происходит в этой сфере: очень часто отдельным личностям выгоднее информацию скрыть, чем показать.
на сопоставлении прайсов — сожрал три собаки. у меня глаза уже как у корейца. Обсосано это тыщу раз у мну. Так что если будет интерес — стучитесь… Делал все на 77 на компоненте нечеткого сравнения. Ничего более продвинутого не видел. Речь идет как раз о загрузках-сопоставлении «нелинеыных» прайсов. Когда прайс — аккуратная плоская табличка, в каждой колонке своя сущность — тут все проще…
(27) CheBurator, да,интересно. У меня пока простая загружалка прайсов, можете глянуть на github (ссылка выше), там в вики есть доступ на тестовый сервер. Следующим шагом хочу как раз за сопоставления взяться,тут ваша помощь будет очень кстати.
С наступающим всех! А потом, еще можно и обработку написать для ленивых считал ШК и если данной номенклатуры в базе нет создали новую автоматом по полям пробежались сохранили дальше пошли!) ну это так мысли в слух)
Закладывайтесь сразу на возможность задания прайсов по этому списку
(29) zetrox,
Утверждают, что у них около 10 млн товаров в базе. Попробовал пробить первый попавшийся (на столе лежала книжуа со штрихкодом) — нашлось.
API платное, 10 баксов за 5000 запросов, при большом количестве запросов могут подвинуться по цене.
Если наоборот, добавлять им в базу несуществующий товар, дают на каждый добавленный товар еще 3 запроса бесплатно.
Можно с ними заинтегрироваться. Вопрос только — как оплачивать ) Думаю, это решаемо.
(31) ну там далеко не все, например из нашей линейки (более 2000 артикулов) — всего 260
(29) zetrox, в продолжение темы с поиском по штрихкоду,
(23)
…..всё перечисленное
+ генератор (выгрузка) каталога на популярные Web торговые площадки будь то битрикс, шопифай или еквид, кончено с привязкой к учётной системе.
типа, а не хотите ли, готовый (!) инет-магазин, по торговле электроинструментом Bosh, с товарами ценами и выгрузкой загрузкой заказов.
+ эко_система по обмену блоками контента
+ конечно мониторинг цен
+ прогноз спроса мин-мах остатков (если кому надо)
…
А Вам не кажется, что 1с для такой задачи сильно ресурсоемко?
Можно из базы 1с через внешние источники данных дампить каталог во внешнюю SQL базу, и отдавать уже IIS или Apache приложением, с минимальным функционалом? (например реализованное на перле или ASP)
(36) akalji, разумеется, 1с не предназначена для таких задач. Более того, ms sql — не лучшая СУБД для такого. На 1с можно было бы начать и оценить востребованность. Но, похоже, она и так довольно низкая. Вот прайсозагружалки — это да.
прайсозагружалки — это к Мане, на сабсистемз.
одно время был sopostavlenie.ru — для привзяки списков, сейчас не работает.
каково состояние проекта сейчас?
почему — если решено делать — не делать в виде сайта, зачем здесь 1С?
(39) CheBurator, мегапрайс видел, радует, что они тоже пошли по пути создания отдельной базы. Я хочу все-таки опенсорс.
На проект пока дико не хватает времени. Как только жена автошколу закончит, время будет.
Сайт планируется как доп.опция к базе, посматриваю в сторону metadata.js. Тем более что там есть оффлайновый доступ, мне встречались клиенты, которые будут этому очень рады. С первого раза не взлетело, ковыряю потихоньку.
На 1С по простой причине: таким решением будет проще управлять. Т.е. гонять свои заказы через какой-то неизвестный веб сервис мало кто из клиентов согласится. А поставить этот сервис себе локально и заточить при необходимости под свои нужды — вполне. В этом сервисе должна быть возможность опубликовать свой каталог в каком-то облаке. Если публиковать цены готовы далеко не все, то просто каталог — запросто. Расчет таков.
А вот облако явно придется рано или поздно переводить с 1С на что-то более подходящее.
Текущее состояние:
Есть конфигурация с веб-сервисом и клиентская внешняя обработка, которая уже будет запускаться в типовых конфигурациях. Обработка делает простые вещи: может выгрузить свой каталог, может загрузить чужой. На этом с обработкой пока все.
Конфигурация:
1) Всякие базовые справочники
2) Загружалка каталогов/прайсов из excel. Интерфейс пока не шибко юзер-френдли, зато скорость очень приличная. На линуксовых серверах пока не заработает, будет такая необходимость — можно допилить. Грузить можно из локального каталога или по HTTP. С FTP код есть, но не тестил ) Хорошо бы добавить получение с e-mail.
3) Ради интереса добавил загрузку каталога/прайса из CommerceML. Соответственно, осталось допилить в конфе небольшой http-сервис и прикинуться Битриксом. Пока поддержаны 2 спецификации CommerceML из десятка существующих, будет необходимость — можно продолжить.
4) Сопоставлялка товаров: сделал дешево и сердито — через полнотекстовый поиск в 8.3. С сопоставлением есть 2 сценария: когда сопоставляем свой каталог с каталогом поставщика, или когда клиент сопоставляет с нашим каталогом. Во втором случае, возможно, придется писать в базу только ID справочников. В первоначальном варианте сделано именно так.
5) Разумеется, отчет по сравнению цен сопоставленных товаров. Черновик, что-то показывает, правдоподобно.
6) На RLS пока подзабил.
Демка в Амазоне крутится, еще 9-10 месяцев халявного периода, потом придется решать вопрос о продлении.
На гитхабе конфа в ветке demo актуальна на данный момент.
Я вам писал в ЛС где-то после новогодних праздников, вы сообщение получали?
(40) Очень интересна данная тема, как сейчас продвигается проект? на GIT, я смотрю, последнее обновление было год назад.
(41) Примерно тогда проект и заглох. В рамках него появилась читалка CommerceML и эмулятор Битрикса (в плане загрузки каталога товаров), лежат в соседних проектах.
Были попытки применить идею в ЕГАИС, но тоже заглохло.
Виртуалка в Амазоне стала платной, после чего я ее удалил.
Сейчас довольно бурно развивается на Мисте, там как раз Сергей Коцюра тестирует и подкидывает идеи. Но оно не на 1С, а на более подходящих инструментах ))
Со временем по семейным обстоятельствам стало совсем туго, но если у вас есть интерес, можно возобновить тему.