Миграция данных между различными E-commerce движками

[Sakura]

После «триальный стор» и «проверки возможностей карты» возникла мысль что это перевод, но в футере об этом ни слова.
Дальше читать уже не захотелось

[anthonyr]

Не оправдываю автора, но это вполне устоявшийся сленг в среде, как минимум, разработчиков eCommerce решений.

[Sakura]

Возможно сейчас такой сленг, но я 7 лет работал в ecommerce и у нас такого сленга не было.
хоть мы и работали в 99% с иностранцами

а в день написания коментария я «акцептировал» договр с банком на открытие карточки, как-то после этого слова я расхотел быть клиентом такого банка

[victor2832]

2,5 года проработал с ecommerce. Практически сразу пришлось привыкать к подобным словам, поэтому они и сейчас появились в статье.
Надеюсь все кто читал поняли о чем идет речь. Если нет — пишите в комменты, помогу с определениями.

[bloodyvlad]

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

[victor2832]

Какие из решений синхронизации вы использовали и почему они Вам не подошли?

[bloodyvlad]

Мы пока в процессе. Приходится писать свое потому что задача несложная для нас. Взять код товара, цену и наличие из xml-feed нетрудно. Приклеивать готовые решения будет сложнее. Как вариант можно подключиться к базе партнера с read-only правами на доступ только к определенным таблицам. C большими постоянными партнерами заключить договор на доступ с правами на запись, чтобы все вообще шикарно было. Просто даже если у нас будет свое API, его часто может не быть с другой стороны и уменьшить остаток товара ТАМ при продаже у нас мы не сможем.

[ommunist]

шкурный вопрос — 1С выгрузку товаров, загрузку заказов и клиентов в/из BigCommerce можно или это утопия?