Альтернативная выгрузка (без CommerceML) в СS-Cart из 1С(7-ка, 8-ка), МойСклад, Class365

Хочу предложить внедрение альтернативного обмена данными складской учетной системы с и-магазином на Cs-Cart, не использующего штатные решения на базе CommerceML.

Кого может заинтересовать, кому адресовано?
Тем, кого CommerceML по каким-то причинам не устраивает или не подходит.

Это не модуль. Это решение, т.е. подкручивается под индивидуальные особенности исходных и итоговых данных. Изначально делалось для собственных нужд.
Работает на десятке и-магазинов несколько лет.

Причиной создания решения была необходимость минимизировать привлечение 1C-ников (в 1С мы не лезем).
Но 1С-ник понадобится… Что нужно со стороны 1С-ника?

  1. Выгрузить данные всего склада в csv
  2. Запаковать в zip-файл
  3. Настроить передачу файла по ftp.
  4. Настроить пользователю кнопку запуска выгрузки вручную и (или) запуска по таймеру.
    Это все.
    1С-ники попадаются разной квалификации, но с указанным списком справлялись все (от 2х дней до 2х месяцев ))

Остальные работы идут на серверной стороне:
1.
Контроль корректности пришедших данных (несколько уровней защиты, от искажения данных при передаче, до контроля форс-мажорной порчи данных, например, после неудачного апгрейда 1С)
2.
Доукомплектация пришедших данных (как банальное техническое SEO с метатегами, так и разнообразные перетасовки категорий, бывают и громоздкие обогащения характеристиками, описаниями и т.д.). Модификация “карточек товаров” на основе динамически меняющихся справочников.
Могут быть “игры” с ценами и с остатками…Объединение-разделение остатков между физическими и виртуальными складами и т.д.
3.
Определение разницы между пришедшим складом и текущим и-магазином. Решение отслеживает изменения в номенклатуре и корректирует только их.
4.
Изменения вносятся через штатный импорт, порциями, чтобы не тормозить и-магазин. Размер порции настраивается под “железо” и общее число товаров и-магазина.
5.
Предусмотрены извещения на эл.почту о начале и завершении выгрузки. Диагностика об ошибках(если таковые возникли), предложение повторить запуск вручную.

Время выгрузки.
Сейчас весь процесс разделен на 5 этапов с промежутком между ними 3 минуты, т.е. укладываемся в 15 минут. Если обновление объемно - система будет вести обновление дальше, т.е. время увеличится, хотя есть возможность поэкспериментировать при установке и настройке, с этапами, длительностями, порциями…
Т.е. возможна постоянная синхронизация складов и и-магазина.

Рабочий объем данных.
На сегодня максимальный объем идет со складом в 30 тыс.SKU

Для больших объемов.
Сделаем бесплатно один проект, у которого число SKU превышает 100тыс.единиц, в качестве стресс-теста с реальными данными в боевых условиях
UPD. В связи с высокой нагрузкой предложение снято

Нетребовательность к хостингу
Решение на сегодня работает на webhost1.ru (тарифы CsCart Lite, CsCart) и на firstvds.ru (тарифы Разгон и Отрыв, SSD, KVM). Понятно, что проц и память влияют на скорость…

Работает на
Cs-Cart версий: 4.3.5, 4.7.3, 4.8.2, 4.9.3, 4.10.4, 4.11.4, 4.11.5
На сегодня тянет данные из:

  • 1С: как семерки, так и восьмерки (конфигурации и версии любые, это не имеет значения),
  • МойСклад,
  • Бизнес.Ру (он же class365)
  • и из файлов csv, xls и xlsx (есть и такая экзотика)…

Обмен односторонний
Решение заточено под передачу данных о товарах ИЗ складской программы. По передаче данных о заказах в CRM был единственный запрос, реализовано для Бизнес.Ру (class365), т.е., в случае необходимости интеграция с CRM возможна, но это отдельная история…

Картинки
Решение НЕ работает с фотографиями товаров. Работа с фото - отдельная история…

Необходимо для работы
Доступ к хостингу для настройки крона и FTP-доступа + доступ в админку Cs-Cart для установки небольшого модуля, помогающего Решению в импорте.

Порядок работ
Начинаем с общения (эл.почта, телефон, скайп), смотрим данные, уточняем, как должно все работать,совместно пишем ТЗ, выходим на стоимость и сроки.

Стоимость.
Компании отличаются, сферы деятельности отличаются, данные отличаются. Ни разу не было идентичных внедрений. В индивидуальном случае всегда что-то подкручивается для эффективности. Благо Решение это позволяет. Стоимость начинается от $900 в рублях. Желательно - безнал, с наличием эл.документооборота через Диадок или Сбис.

Гарантии
Мониторим корректность работы в течении 3х месяцев после внедрения. Этого срока с лихвой достаточно для выявления и устранения возможных шероховатостей. Если посчитаете необходимым продолжение мониторинга, это возможно (абонентская плата).

Нужна доп. информация?
Связь через личные сообщения форума или
телеграмм или
голосом через скайп или
телефон (по запросу)

1 лайк

У нас мы реализовали примерно такое же решение, и это гораздо лучше стандартного в коробке. Единственно что я в итоге видоизменил, так как сначала было как у вас, отдельно выгрузка файла, отдельно его обработка. Но объединение этого в один процесс выглядит гораздо лучше и дает более точный результат. Например у нас нередко было, когда в результате временных накладок (тот же 1С при запуске например каждые 15 минут - отсчитывает время до следующего запуска по расписанию не от момента предыдущего старта, а от момента ЗАВЕРШЕНИЯ предыдущего задания… в результате чего может возникнуть ситуация, что 1С только начинает передавать файл, а скрипт уже пытается его открыть, а файл пока еще пустой):
1С-ник:

  1. написал обработку, которую встроил в конфигурацию, благодаря чему ее можно запускать как задание по расписанию - автоматически.
  2. обработка собирает данные в csv файл со строкой заголовков
  3. после удачного сохранения локально этого файла - обработка обращается через POST запрос к скрипту на сервере и передает скрипту файл
  4. Скрипт на сервере принимает файл, и построчно обрабатывает его. Возвращает (echo в скрипте) результаты обработки, статистику.
  5. 1С получает ответ скрипта о удаче/неудаче и выводит полученный ответ (статистику обработки)

При автозапуске вывода конечно нет, но при ручном запуске - все результаты обработки - 2-3 тысячи строк за 2-3 минуты от запуска обработки до завершения - весь процесс на лицо.
Кстати, в итоге я так и оставил только периодический ручной запуск: магазин сам прекрасно отнимает единицы товара, запускаю только для новых товаров, когда меняются цены или на складе изменилось количество каким либо иным способом.

1 лайк

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

Ваше решение сделано на стороне 1С. Для этого требуется сильный 1С-ник.
И,скорее всего, решение не тиражируемо.

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

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

Не, у нас как и вас - на стороне 1с просто собирается csv файл, отправить его POST или подключиться к ftp и закачать - равносильные задачи (вроде как вызов http скрипта и передача данных - даже проще :slight_smile: )

Приходится, так как спасение утопающих… ))

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

У нас все это делается на стороне сервера. Вычисляются изменения сравниваясь с текущим состоянием и-магазина, производятся корректировки статусов, характеристик, категорий и т.д, в соответствии с оговоренной логикой… Импорт ограничивается только изменениями…

1 лайк


тоже умеет с файлами 1с работать и довольно быстро )

Да, в курсе наличия этого модуля. Рад, что Вам он подошел. Не конкурируем с ним…

Кому - поп, кому - попадья, а кому - попова дочка ))

UPD.
Там - модуль, а здесь - Решение…
Там - общий случай, а здесь - индивидуальная подстройка…
Разные продукты для разных применений…

Я на одном сайте использовал этот модуль

На другом проекте настраиваю настройку Мой склад с cs-cart с помощью этих ребят
https://ciframe.ru/products/moysklad/

Всем доволен )))

Рад за Вас. Каждому овощу - свое время ))
В первом посте указал

похоже, прозвучало невнятно. Попробую по другому.

Для кого написана эта тема и кому направлено предлагаемое Решение?
Для тех, кто:

  1. С грузом прошлого или
  2. С навесом будущего или
  3. На распутье роста

Груз прошлого
Для компаний, у которых уже построена экосистема десяток-другой лет назад на базе 1C семерки, или Парус, или БЭСТ, или десятков иных складских программ, без встроенного CommerceML.
Пусть у маркетологов таких компаний исчезнет оправдание: “не запускаем и-магазин, т.к. система устарела, не приспособлена”. Еще как приспособлена! Работают и-магазинчики… И песня в подарок! ))

Навес будущего
Было время, когда CommerceML казался прорывом. Я.Маркет пытаясь приспособить его, сделал надстройку… и что? Получился отдельный протокол YML…
На базе Решения сейчас сочиняем интеграцию для Wildberries FSI. ВилдБерриз проигнорили CommerceML напрочь… Другие маркетплейсы, SAAS-сервисы, CRM-ки так же идут мимо этого протокола.
Будущее не замыкается экосистемой на базе 1С… И это будущее нависает снежным козырьком…
Надо признать прямо, CommerceML был создан для мелких интернет-компаний. По мере роста фирмы сталкиваются с его ограничениями, делают заплатки… потом заплатки на заплатки и т.д… Тоже вариант, но есть и другой - отказаться от него совсем. Как это сделал тот же Wildberries и тысячи других…

На распутье роста?
Фирмы создаются по разному, но если растут, то по одной схеме…

  1. Герой одиночка
  2. Мастер с подмастерьями
  3. Мануфактура
  4. Фабрика
  5. Корпорация


Схема отсюда.

Немногие могут расти, переходя от этапа к этапу. Между этапами - пропасть.

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

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

Наше Решение НЕ ориентировано на героев-одиночек, живущих по принципу СДЕЛАЙ САМ, при всем к Вам уважении…

Наше Решение для других… когда нужно чтобы КТО-ТО сделал и чтобы работало “само” и без авралов, без траты времени собственника…

4 лайка

Есть ли возможность адаптировать решение под multivendor? Реализовать для каждого продавца возможность подключения к своей системе учета?

“каждого к своей” - нереально.
складских систем десятки. Плюс большинство из них претендует на конструктор, т.е. пользователи делают удивительные настройки для себя как бог на душу положит - это про малый и средний бизнес.
а мелкий и мизерный бизнес работает или на память (держит склад в голове), или Excel-таблицы.

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

Мысли про стандартизацию прайсов не на пустом месте.
Мы сделали pet-проект, где прайсы от 2х десятков поставщиков качаются (с их сайтов) в мультивендор, т.е. разбираются, преобразуются и отображаются с наличием, ценами и указанием координат поставщика. Вижу, что регулярно структура прайсов меняется, т.е. со стороны мультивендора требуется отдельный контроль входных данных.

Все это проекты с серьезными намерениями, надолго…
Если готовы к ним, то стоит перейти в личную переписку

Кстати, не согласен. Без особых проблем небольшими доработками привязали склады и цены для различных магазинов в мультивендоре. Не вижу ничего экстраординарного в том чтобы external_id в товарах привязать к товарам конкретных вендоров. Карточки то выгружать не получится, а вот цены и остатки выгружать - не вижу проблем, вполне реализуемо.

Предположу, что Вы рассматриваете только 1С? Поставщики пользуются не только 1С (большинство - Excel)
2.
Предположу, что число число поставщиков невелико (десяток-два), ведь по КАЖДОМУ нужно делать индивидуальные доработки, пусть и небольшие).
Я рассматриваю мультивендор, ориентирующийся если не на тысячи, то на сотни вендоров). Для того, чтобы делать “небольшие доработки” у них - нужна отдельная служба. Да и то, если вендоры согласятся…
3.
Конечно реализуемо. Вопрос амбиций-ресурсов-сроков.

Ну, вообще для меня это сейчас вполне актуальная задача, которую я еще не понял как реализовать. И проблема даже не в великом разнообразии систем, а в том что вообще не понятно как все эти люди работают… если что-то и есть, то с их стороны толком некому настроить. В общем, пока вопрос исследовательски-организационный. Частично пока задача решена с помощью модуля RetailFactory импорта прайсов поставщиков, благо, экселем хоть как-то многие пользоваться умеют. Про 1С мысли пока исключительно умозрительные на основании того что делалось для своих вендоров и со своей 1С. Что там у остальных за зоопарк - вопрос пока в процессе изучения. Сейчас число работающих вендоров больше 100, но механизм их обновления преимущественно специфический, централизованный.

А что вы думаете по поводу нового модуля ComerceML? Чем не устроил?

Я его не видел, обновление пока не целесообразно, в магазине много доработок которые слетят при обновлении…

а ниже

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

Ниже - не о предложении, вынесенном в тему топика, а про
Массовую загрузку прайсов вендоров в мультивендор

Упомянул выше, что подобная задача знакома и понятна. Более того - есть рабочий прототип, который умеет делать:

  • ручную загрузку прайсов с компьютера;
  • загрузки по расписанию с сайтов, Яндекс.Диска, Гугл.Диска;
  • форматы прайсов: .xls, .xlsx, .csv;
  • решены жизненные реалии: склейка артикулов, несколько прайсов у вендора, прайсы разной структуры, деактивации устаревших прайсов и т.д.

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

В результате - это отдельная надстройка (не привязанная к cs-cart), не скажу, что гигантская, но объемная:

Прототип делался для внутренних нужд, как исследовательский проект для отработки технологий.
Это не Решение, внедренное 3-5-10 раз, о продаже которого можно было бы говорить, это Прототип решения. Но прототип работающий

Сейчас он работает в полуавтомате - пару раз в неделю жму кнопку, идет загрузка-обработка-обновление по всем вендорам, смотрю диагностику системы, появилось ли что-то новое, непредусмотренное ))
Данные (с помощью Решения, вынесенного в заголовок этой темы) передаются в мультивендор, который и демонстрирует их счастливым посетителям…

Почему не развиваю? Развиваю, но урывками, когда в основной деятельности бывает недозагруз… Сотрудники хотят получать зарплату два раза в месяц, приоритеты - не на исследованиях…

И есть еще один момент - организационная сторона.
Автоматизация мультивендора - это человеко-машинная система. И если машинная часть в наличии, то человеческая часть непонятно как организована, а к ней нужно адаптировать машинную часть… Иначе не заработает.

И начинать такие работы придется с проекта всей человеко-машинной системы. Как устроена организация? Все ли процессы подстроятся под машину или нужно машину подстраивать, а если подстраивать, то как? Кто будет поддерживать систему? Какая квалификация? Что можно добавить, чтобы поддержка была проще?
И еще десятки вопросов, без обсуждения которых вся эта история будет нежизнеспособной…

А история серьезная, тут весь подход - по взрослому…