Привет, расскажите, кто делал крупные интернет-магазины, как там все вертится после того, как заказ упал? Как, где заказ обрабатывается? Какие у вас были самые сложные интеграции, с чем (если компания ведет документооборот или базу в своей программе, а не в вебе)?
к чему я вообще это спрашиваю

Linux Nix Web Development - http://linuxoids.org/ image

Tagged with →  

26 Responses to Привет, расскажите, кто делал крупные интернет-магазины, как там все вертится после того, как заказ упал?

  1. 5auam:

    тут всё сильно зависит. кому-то проще нанять штат программеров и работать в вебе, а кто-то покупает какой-нибудь Oracle и консалтинг с внедрением.

  2. AmtEkb:

    У меня был опыт интеграции сайта с крупной базой. Там всё было ужасно, и работало так:

    При заказе на сайте в базу данных поступала запись, а продавцам рассылалось письмо. Кто-нибудь из них заходил в админку (или прост обновлял страницу с ней) и брал этот заказ себе. Звонил человеку и т.д. Потом периодически менял статус заказа в админке. Больше этот заказ сайта никак абсолютно не касался. Вся работа велась в 1С и Аксапте. Регулярно начальник интернет-магазина сравнивала статистику из админки (просматривал количество заказов с тем или иным статусом) и из 1С.

    Остатки и цены обновлялись раз в сутки (да, один раз в 24 часа) при помощи консольных скриптов, которые запускались по кронтабу.
    Остатки брались напрямую с главного сервера аксапты, через пхп-библиотеку работы с ораклом. Всё пихалось в мускул, в отдельную базу.
    Цены брались напрямую с главного сервера 1С через пхп-библиотеку работы с MS SQL. Всё пихалось в мускул, в ту же базу.
    После отработки этих двух скриптов запускался третий скрипт, который соединял новые даные разным образом и запихивал их прямо внутрь базы битрикса, минуя все его официальные инструменты. Прямо через mysql_query.

    Всё. Битрикс работал и не жужжал.
    Сайт не предоставлял для электронной коммерции компании НИЧЕГО, кроме отображения товара и записи заказов пользователей. По сути, был витриной.
    Потому что нужно быть совсем трудолюбивым человеком с богатыми учредителями, чтобы реализовывать бухгалтерию, финансы, логистику и т.д. в двух местах одновременно — в 1С и на сайте.

  3. Ylfer:

    ты хотел сказать, с богатыми и глупыми учредителями?

  4. UpaFcuk:

    Сначала заказ падает в БД интернет-магазина. Потом, когда оператор подтверждает, что заказ не спамовый, он перемещается в бухгалтерию. При необходимости обратно из бухгалтерии отправляем данные о состоянии заказа.

  5. LspMsk:

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

    Полный документооборот никто не внедрял, т.к. проще нанять 10 туземцев.

  6. AxoaTa:

    Всё очень просто. Покупатель нажимает кнопку ProcessOrder и заказ через веб-сервис создается в AX, ну и там уже всё просто.

  7. KinBlank:

    Работал в sotmarket.ru аналитиком/программистом 1ц перевел складской учет c экселя/оскоммерсе на 1с

    в СМ три системы
    — веб морда
    — срм
    — 1с

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

    в 1с ведется закупка, планы закупки, остатки, инвентаризация, ценообразование
    выгрузка из 1с на сайт — цен и товара
    из срм в 1с — заказов

    Готов ответить на более сложные вопросы, поделится опытом/

  8. Nirer:

    вебморда и срм на одной базе данных крутятся?
    срм — самописная?
    выгрузки 1с -> сайт и срм -> 1с как часто происходят? и как реализованы?

  9. SbVelo:

    А сервер оракла имел свой внешний ip? Или в датацентре рядышком стоял?

  10. AmtEkb:

    в серверной рядом.

  11. RatFcuk:

    есть пример магазина, в котором 3 типа товара с разными цепочками оформления документов
    Yii (php) — 1C (склад) — 1С-crm (корп отдел+ колцентр)
    все через xml -работает как часы.

  12. KinBlank:

    возможно базы разные, срм самописная.

    выгрузки проходят событийно, то есть меняется статус заказа выгружается пакет, наличие обновлений проверяется каждые 5-15 минут. принцип УРБД из 1с (управление распределенной БД)

    Формат обмена XML, для быстрого старта взят за основы CommerceML, поддерживаемый 1ц.

  13. EvoRain:

    Сейчас расскажу.

    Мой пример — большой интернет-магазин с доставкой нэйшн-вайд, у которого, к тому же, есть еще большой офлайн.

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

    Еще на фронте, пользователю рассчитываются РЕАЛЬНЫЕ сроки и стоимость доставки. Когда он сможет сделать пикап в ближайшем офлайне, когда сможем принести ему домой курьером и когда сможем отдать на доставку почте, если он живет совсем уж в ебенях.

    Кол-центр работает в админке магазина. Там есть несколько кейзов.
    1. Чувак купил в магазине сам и все хорошо заполнил. Ему надо позвонить и уточнить основные моменты.
    2. Чувак сделал заказ, но потом обнаружил, что что-то неправильно. Не тот цвет, не тот товар, не туда или не в этот день везти.
    3. Не смог или испугался заполнять форму чекаута и решил сделать заказ по телефону — соответственно позвонил сам. Оператор делает ему заказ.
    4. Все хорошо, но мы не можем что-то продать (не смотря на постоянную актуализацию стоков такое случается). Надо сделать замену.

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

    Так или иначе, на этом этапе мы имеем заказ который точно сможем выполнить в срок. Только после этого он отправляется на бронирование в учетную систему.
    Что там происходит для меня магия и загадка. Я делаю интернет-магазины, но процессы внутри ERP знаю не полностью, тут уж простите. Наверное, происходят проводки и перемещения со складов, что-то там еще, логистам отдается какая-то инфа, опять же. Мне же в систему, в 99,99% заказ приезжает назад из ERP с подтверждением бронирования. Тогда покупашке можно рассказать, что заказ подтвержден и мы уже бросились его выполнять. Если же ERP не смогла заблокировать товар, об этом сразу узнает кол-центр и звонит извиняться.

    Что касается интеграции, я делал много и разных. Часто 1C, Dynamics, Oracle E. SUP вот скоро будем делать наверное. Чаще всего обмениваемся:
    1. Покупашки: туда-сюда. Без контрагента нельзя сделать продажу в ERP, а в обратную сторону часто хотят затягивать покупателей из офлайновой CRM. Зачем — не знаю.
    2. Товары: из ERP в ИМ. В ERP редко есть что-то кроме названия, цены и SKU. Собственно, больше ничего нам не надо. Нам главное чтобы было четкое соответствие по SKU, поэтому его нельзя менять, а товары нельзя создавать в ИМ. Товары создаются только в ERP, а потом затягиваются на сайт для набивки описаний и картинок.
    3. Цены и стоки: из ERP в ИМ. Надо актуализировать часто, поэтому отдельным пунктом. Цена базовая. Поставленные руками или правилами в ИМ цены приоритетное.
    4. Заказы: из ИМ в ERP. Я бы советовал каждую товарную позицию отдавать отдельной строчкой. Даже если заказали два одинаковых товара. Так потом проще жить, поверьте. Важно чтобы ИМ мог продать товар по той цене, по которой он хочет, и отдать эту продажу в учетную систему. Пусть дальше с проводками эсеры ебутся как хотят.
    5. Статусы заказов: из ERP и ИМ. Думаю, тут понятно.

    Про техническую реализацию, рассказывать долго не буду. Пробовали много разных. API там всякие и так далее. Остановились на простой системе с промежуточными таблицами в MySQL. Это требует, конечно, доработки со стороны ERP, но она понадобится в любом случае. Кроме того все прозрачно и четко, можно в любой момент посмотреть где какой статус, где что отвалилось и у какой стороны руки из жопы. Только проектировать надо грамотно, чтобы дедлоки жить не мешали.

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

    Ох, простыня какая получилась. Надеюсь хоть кому-то полезно будет. Я думаю, что неплохо в этом понимаю, поэтому можете спрашивать.

  14. Cnaam:

    Ты говоришь про интернет-магазин с офлайновой розницей или просто про большой интернет-магазина, типа ozon, sapato и т.д.?

  15. Alomo:

    расскажи, пожалуйста, подробней о технической реализации как раз. webdev блог ж)

  16. AmtEkb:

    то есть мозг никто не съедал насчёт «а если хакеры сломают сайт, доберутся до админки и назаказывают херни всякой»? 🙂
    Кстати, как у вас насчёт безопасности ИМ?

  17. RatFcuk:

    кстати, на нескольких магазинах отказались от регистрации при заказе — левых заказов никогда не было

  18. EvoRain:

    ну если хакеры доберутся до админки, то это караул конечно. Там можно выгрузить всю товарную базу, всю базу покупателей. Цены заапдейтить. Так что назаказывают херни всякой, это так, фигня. Все заказы прозванивают.

    С безопасностью у нас не так уж и плохо. У нас платформа сама по себе PCI DSS compliant. А когда https и хороший сервер, то все хорошо. По стандартам.

  19. EvoRain:

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

  20. RatFcuk:

    нахера регать, если по мылу/телефону можно принудительно зарегать и выслать пароль/пинкод на мыло/телефон
    из обязательных полей только мыло и телефон делать и все. хотя народ САМ заполняет все данные

  21. EvoRain:

    сложно рассказать. Тут нет типового решения. Все очень зависит от задач. Да и не расписывать же структуру таблиц.
    Но делаем именно так, через промежуточные таблицы в БД. Иначе не выходит. Например, остатки в разрезе складов. Это например 8К товаров и 40 складов. И данные всегда нужны актуальные. Поэтому ERP туда записывает прямо в риал-тайме, и мы работаем с этой таблице напрямую при просчетах. Заводить через API не вышло бы — это очень медленно. К сожалению, я не знаю, как эска или там SAP эти данные генерят и записывают. Я только со стороны ИМ вижу процесс. Там много всяких технических деталей. Ну, например, для цен нужен отдельный индекс, чтобы быстро обновить все цены разом (происходит раз в час). Всего не рассказать. Спрашивай что интересно.

  22. EvoRain:

    не-не. На телефон не надо. Был такой опыт, это привозит огромный бонс-рэйт.

  23. RatFcuk:

    а как связаться, если в почте опечатка?

  24. EvoRain:

    телефон спрашивать надо. При оформлении заказа. Но вот регать на него принудительно, не очень.

  25. RatFcuk:

    в принципе в качестве логина пофиг что использовать, кто ссыт данные указывать — звонят сами

  26. AmtEkb:

    ну, хорошо, когда по безопасности у начальства нет заморочек и магазин с нуля строится как ИМ 🙂

Добавить комментарий