Импорт данных в интернет-магазины

    image


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


    Данные поставщика — это:

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

    Именно про эти данные будет идти речь. Возможны два варианта работы с этими данными:
    1) интернет-магазин пустой, и нам не нужно учитывать, что в нем находится;
    2) интернет-магазин уже наполнен.

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

    Требования



    Что обычно хочет владелец интернет-магазина? Требования с его стороны к автоматизации импорта данных такие:

    — если появилась новая категория на поставщике, необходимо, чтобы она тоже была создана у него в магазине;
    — чтобы товары, которые отсутствуют в его магазине и присутствуют у поставщика, появились (имеется ввиду с описаниями, характеристиками, картинками, вариантами цвета и т.д.) в нужной категории и (или) категории “Новинки”;
    — если товар присутствует в магазине заказчика, но отсутствует на складе поставщика, то нужно этот товар отключить (деактивировать) либо изменить статус на “нет на складе” (это нужно, чтобы товар стал недоступным для заказа);
    — если товар присутствует и в магазине и у поставщика, то нужно обновить цены и количество (если такие данные есть).

    Скрытые требования



    На самом деле менеджер интернет-магазина хочет большего от импорта. Это так называемые скрытые требования, про которые никто не говорит вслух, но как бы все подразумевают уже при приемке проекта или эксплуатации в первый месяц.
    Такими скрытыми требованиями для импорта данных в интернет-магазин являются следующие пункты:
    — чтобы товары, которые пользователь вносит самостоятельно в интернет-магазин, процесс автоматического импорта не “менял” (не удалял, не деактивировал);
    — чтобы правка описаний товаров, которые обновляются из склада поставщика, которые он делает с помощью копирайтеров, не пропадала (это важно для SEO);
    — чтобы у новых категорий и товаров формировались правильные и красивые ЧПУ-“URL rewrite”;
    — менять цену с учетом своей маржи, которая зависит от категории и популярности товара;
    — получать отчеты о том, какие новые товары появились, а которых уже нет в продаже;
    — чтобы процесс обновления данных в интернет-магазине был простой и занимал мало времени (несколько или 1 клик);
    — если товар присутствует в системе поставщика в более чем в одной категории, то нужно привязать этот товар в соответствующие категории на стороне интернет-магазина;
    — если товары, которые мы импортируем в интернет-магазин, это комбинационные товары (например, ботинок “красный цвет, 42 размер, 2300 рублей” и “черный цвет, 43 размер, 3100 рублей” и т.д.), надо, чтобы они обрабатывались корректно.

    Решения



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

    Как выполнить эти требования, какие инструменты могут быть использованы?
    — пользоваться стандартным импортом CMS (обычно из файлов из csv / xls / xml / yml и др.);
    — импортировать через механизм обмена 1С-Битрикс (1С-Битрикс, UMI, HostCMS, и др., где есть обмен с 1С);
    — программировать свой собственный механизм импорта.

    Анализ каждого из предложенных вариантов будет представлен ниже.

    Импорт данных через csv — вещь сама по себе очень простая и должна работать надежно. Правда, как показывает практика, это не всегда так. Возникают вопросы, если надо импортировать что-то более сложное чем набор “имя, описание, картинка, артикул, цена”. Что делать с характеристиками, опциями и т.д.? Сегодня этот вариант импорта данных в CMS запрограммирован не всегда хорошо в большинстве реализаций и всегда требует доработок. Плюс ко всему — это промежуточные файлы (их же надо сформировать), требования к хостингу (ограничения). И самый главный минус — ручная работа, а точнее, много скучной и однотипной ручной работы, которую мало кто любит делать.

    Импорт данных через механизм обмена 1С-Битрикс. Сама по себе идея очень хорошая. 1С есть у всех, а если ее нет, то сам протокол можно эмулировать. Но вот реализация на стороне интернет-магазинов заставляет задавать много вопросов. Если смотреть в сторону эталонного для всех Битрикса, то можно просто сказать, что на объемах более 10 тысяч товаров этот механизм уже дает сбой. Сбои бывают разные. Например, может отсутствовать поддержка ZIP. Могут быть проблемы с объемом доступной памяти для php-процесса. Скорость — это самая больная тема для импорта в Битрикс через 1С. Почему так медленно сложно сказать, но на сегодня это так. Например, битрикс по умолчанию импортирует не в стандартный инфоблок товаров, а в инфоблок, который специально создается для 1С. Плюс при работе через 1С мы имеем проигрыш во времени, т.е данные загружаются два раза — первый раз в 1С, второй раз в Битрикс. Если смотреть на другие CMS, то там реализации этого протокола находятся в состоянии, когда пользоваться им простым людьми без помощи программистов невозможно. Подробнее про импорт товаров в Битрикс мы писали в этой статье: habrahabr.ru/post/133993.

    Программирование собственного механизма. Импортировать этим путем сложно и дорого, однако реализация дарит массу преимуществ, недоступных сегодня из коробки в предлагаемых решениях. На наш взгляд, если стоит задача выполнять пункты, обозначенные в требованиях к импорту данных в полном объеме, то только этот вариант способен удовлетворить требования.

    Следующие факторы являются ключевыми при выборе инструмента для импорта:
    — частота обновления данных,
    — объем передаваемых данных,
    — скорость обновления данных,
    — детализации информации,
    — бюджет,
    — компетенции и загруженность команды.

    Т.е. получается вот такой график для выбора.



    По поводу бюджетов ситуация неоднозначная и зависит в первую очередь от стоимости команды интегратора. На графике показана расстановка бюджетов и предложений на российском рынке. Завышенная стоимость интеграции 1С-Bitrix обусловлена нехваткой специалистов требуемого уровня 1С и Битрикс на рынке, что и вызывает соответственно удорожание цены разработки и поддержки решения. CSV-интеграция возможна и приемлема при малых объемах данных или при отсутствии бюджета, или при малой детализации импорта данных.

    О том, как реализовать поддержку “прямого импорта в базу данных” более 10 популярных CMS интернет-магазинов, будет рассказано в следующих статьях.

    Николай Кекиш,
    директор CatalogLoader.com
    Поделиться публикацией

    Комментарии 20

      +1
      Oracle ATG стоит ожидать в этой десятке?
        0
        Нет.
          0
          Разработал свою ERP, SCM, CMS, CRM, полная автоматизация для ритейла сделана и вначале построена для обычных магазинов и интернет магазины построены как часть системы, то есть заполняя данными обычные магазины, также товары и их категоризация попадает в интернет каталог / магазин. То есть решение, которое позволяет управлять обычными и интернет магазинами из одной консоли управления, одними и теми же методами.
          +6
          Вы не учли несколько вариантов, которые встречаются очень часто — магазин работает с несколькими поставщиками, у каждого поставщика свой прайс(xml, csv, xls), у каждого из файлов своя структура, часто даже не совпадают артикулы. Один и тот же товар может быть в наличии у нескольких поставщиков, и нужно выбирать наименьшую стоимость.
            0
            Да, отличная задача. :)))
            При этом структура прайсов тоже периодически меняется у многих поставщиков. А цены бывают не только в рублях. ;-)
              +1
              Столкнулся именно с этим 4 года назад, своя система управления торговлей, интеграцией магазинов, поставщиков и т.д. На то время было 11 или 12 магазинов, везде базы разные, разные цены выхода и даже цены входа могут отличаться, названия, Ш/К некоторые совпадают, некоторые нет. Первая часть интеграции данных просто собирала все это изо всех магазинов, вторая часть позволяла оператору определить некоторые ключевые детали, слова, порядок цен, Ш/К и системы выплевывала экран, где для каждого магазина были представлены наиболее подходящие по критериям товары. Система дает выбор, если в магазине есть несколько вариантов. Автоматом проставляются галочки на наиболее похожие товары и оператор должен подтвердить если действительно это один и тот же реальный товар. Когда оператор подтверждает, система генерирует 'мастер-продукт', который обьеденяет в себя эти раздельные товары. Третий шаг перехода уже требует установки в каждом магазине части самой платформы и выгрузки в нее данных из общей базы.
                0
                Кстати, я еще забыл добавить, что все это добро должно работать на любом PHP шаред хостинге и успевать обрабатывать XLS файлы over 60 тысяч строчек за стандартные 30 секунд при любой нагрузке на сервер со стороны соседей :)
                –1
                Тут: www.agorab2b.ru/ интернет-магазины могут брать данные сразу от нескольких поставщиков из одного места
                Данные от поставщиков вытягиваются прямо из их 1С. Идеальная интеграция пока только с Insales — там в интернет-магазине автоматически остатки даже обновляются в зависимости от наличия на складе поставщика.
                Для остальных — выгрузка CSV.
                  +2
                  Пост какой-то...водный вводный.
                    –2
                    Непонятно написано («импорт данных в...»). Так всё-таки:

                    «Импорт данных ИЗ интернет-магазина»
                    или
                    «Экспорт данных В интернет-магазин»?
                      +1
                      В общем случаи задача не решается из коробки я думаю не одним бесплатным и многими платныими системами.
                      В лучшем случаи вам будет предоставлен метафреймворк который упростит задачу (что то типа Microsoft BizTalk), и вам прейдется заплатить за настройка под конкретного поставщика.
                      Пока на ринке не устаканится ни один формат импорта/експорта данных, ничего не поделаеш будем жить так
                        0
                        Формат то есть, CommerceML ни кто не отменял. Культуры и массовости использования нет. Каждый поставщик городит свой внутренний формат (зачастую в виде банального экселя) и ему глубоко по**й наплевать как эти данные будут интегрироваться в системы его клиентов (магазинов). Проблемы индейцев шерифа не касаются.
                          0
                          CommerceML есть, но он безумно избыточный. Иногда бывает выгружается куча пустых XML секций (килобайты мусора), который можно было бы вообще не выгружать.
                          Так же не очень понятно зачем перешли на два файла import.xml и offers.xml, усиливая и без того громадную избыточность.
                            0
                            XML сам по себе язык довольно многословный. Но поэтому он такой и гибкий. Избыточность словаря не повод не использовать готовое отраслевое стандартное решение. В конечно итоге мы его не руками разбираем.
                        +1
                        Ууу. Перегон из 1Са это такая морока.
                        В свое время для еще семерки писал на Qt прикладуху — за 6 секунд дергала 20к позиций из M$SQL монструозным запросом, в несколько потоков обрабатывало, сопоставляло с имеющимися данными из БД интернет-магизина и апдейтила цены/добавляла товары. Причем ~5.5 секунд уходило на выполнение запроса.

                        А по поводу данных от поставщиков с разными артикулами — эта проблема решается часто через написание обучаемого морфологического анализатора. Имеет смысл при тысячах позициях, когда человек (менеджер) просто не в силах все сопоставить руками.
                          0
                          А приходилось что-то морфологическое использовать? Уж не АОТ ли? Или что-то в Qt есть? Просто любопытно, на сколько точно удавалось делать автоматическое сопоставление.
                            0
                            я использовал регэкспы и словари, иногда левенштейн приходил на помощь.
                          +3
                          Ещё есть такой момент: нужно учитывать структуру URL страницы описания товара в интернет-магазине и импортировать свежую версию прайса таким образом чтобы тот же товар оказывался на той же странице. Если же банально в интернет-магазине не реализован ЧПУ (а он у многих не реализован) и URL страницы товара выглядит как www.domain.com/productid/17434, то при загрузке свежего прайса — если поле "№ наименования" программист привязал к productID в БД магазина — вся ваша поисковая оптимизация с индексацией пойдут прахом. При этом не следует сильно уповать на «артикул»: прайсы поставщиков как правило формируются людьми и одной человеческой ошибки достаточно для того чтобы на сайте интернет-магазина появились «кривые» страницы. Т.е. нужно ещё писать и процедуру валидации каждой записи с проверкой формата полей. На практике в прайсе данные могут быть засунуты не в ту колонку, вместо запятых могут быть точки и наоборот. А воспитывать сотрудников поставщика на тему умения работы с Excel — неблагодарное дело.

                          Конечно, проще с теми поставщиками кто готовит прайсы в XML для Яндекса, но у большинства прайс банально в Excel. Причём и версии Excel могут быть разные: напишешь процедуру импорта на PHP, а она с половиной файлов не работает или работает криво.

                          На Западе крупные компании делают так: они заводят учётки на своём складе для своих поставщиков и говорят: ребята, карты в руки: как импортируете, так и будем торговать вашими товарами. )) Но это могут себе позволить только очень крупные предприятия.
                            +1
                            Поддержу. Насчет крупных предприятий да, кто больше заинтересован, тот и отгребает. К сожалению у нас больше заинтересован магазин, а не поставщик. Что меня удивляет, ведь по сути это наплевательское отношение к клиенту (ибо для него магазин это клиент). Хотя учитывая, что у нас наплевательское отношение к клиенту норма, то в принципе не удивительно.
                            0
                            В ImageCMS Shop такое сделанно через модуль modul exchange и import/export csv.

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

                            Самое читаемое