Импорт товаров от поставщиков

[scorpion-ds]

Недавно возникала задача импортировать на сайт данные о ценах на товары от нескольких поставщиков.

Как выяснилось, каждый поставщик не считает нужным придерживаться какого-то формата экспорта своих данных.

Выглядит это примерно так, первый этап:
- экспорт в вормате YML, XML, это самые отличные решения ;
- экспорт в формате Excel с табличной структурой (то есть один товар, одна строка), тоже есть вполне вменяемые решения для импорта их к себе, разве что придется обучить систему понимать каждый из прайсов (последовательность колонок) ;
- экспорт в формате Excel, который сверстан в виде плитки или плашек, не знаю как точней описать, высота "карточек товаров" может меняться в зависимости от полноты данных о товаре. В таком прайсе не ясно к чему можно привязаться для автоматического импорта данных .

Второй этап:
При первом импорте от поставщика (и при добавлении новых позиций в прайсе), необходимо установить сопоставления "товар в каталоге" - "товар в прайсе", при последующих загрузках мы только визуально сверяем, все ли в порядке и если да, то делаем импорт.

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


Может, есть какие-то еще варианты или чем плоха моя идея?

 

[Фанат]

Два вопроса есть у меня
1. Непонятно, почему для YML, XML не делается "учить систему понимать каждый из прайсов (последовательность колонок)".
2. зачем визуально что-то сравнивать при последующих загрузках. Даные при загрузке очевидным образом валидируются, и цвет за цену не проканает. О пустых (после валидации) колонках система должна рапортовать сама. Только после сигнала надо привлекать визуала.

а в остальном - нормальная система. Не вижу причин искать что-то другое

 

[scorpion-ds]

Два вопроса есть у меня
1. Непонятно, почему для YML, XML не делается "учить систему понимать каждый из прайсов (последовательность колонок)".

Второй этап наступает в любой случае или я не правильно понял?

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

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

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

 

[Фанат]

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

О втором здесь речь вообще не идет. Только о первом.
Поэтому.
Второй этап не наступит, если на первом для YML, XML не делается "учить систему понимать каждый из прайсов (последовательность колонок)".
Названия товаров нипричем

 

[scorpion-ds]

Научу, чтение источников и приведение их к единому виду, будет первой задачей.

 

[Фанат]

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

 

[grigori]

Ой, "любимая" задача В том смысле, что одни из худших месяцев своей жизни я провел, занимаясь интеграцией интернет-магазинов.
Помню как техдиры, ты их знаешь, @Фанат, сначала говорили друг другу что-то вроде "да х$% там делать два месяца?", а потом чесали затылок и говорили что-то вроде "мда ..."

Любимый вопрос №1: вы храните товары разного цвета как отдельные товары, или как вариации одного?
В любом случае при импорте будете думать что делать с другим вариантом, который пришел от одного из партнеров.
Любимый вопрос №2: черный или чёрный?
Любимый вопрос №3: сколько раз в день ваши поставщики меняют цену?
Любимый вопрос №4: а скидки у вас обрабатываются?

 

[AnrDaemon]

Любимый вопрос №1: как хранить товары разного цвета? Можно хранить как отдельные товары, а можно как вариации одного. Например, у золотого iphone и белого обычно разная цена.

"Пошлите дюжину наших роскошных, длинногогих, как фотомодели, роз человеку, которого обожаете/ненавидите. Мы предлагаем два цвета на выбор: красные 'Я люблю тебя!' или чёрные 'Сдохни, сука!' (+$20 за чёрные)"

Любимый вопрос №2: черный цвет или чёрный?

Черный, темный, желтый… рюский язык - он такой рюский.

 

[grigori]

а, кстати, померяй память когда будешь парсить
помню, как после месяца согласований и тестирования форматов сервер магазина по имени Ютинет прилег когда ему попробовали скормить реальный фид на пару десятков тысяч тысяч позиций в формате YML

 

[fixxxer]

магазина по имени Ютинет

Мне из этой помойки товар везли неделю, каждый день было "завтра", так и не привезли (мне надоело). И это при том, что мне там было предложено заплатить дополнительно за доставку в конкретное время, на что я согласился.

Когда влепил кол на маркете, три дня названивали =)

 

[scorpion-ds]

Ой, "любимая" задача В том смысле, что одни из худших месяцев своей жизни я провел, занимаясь интеграцией интернет-магазинов.
Помню как техдиры, ты их знаешь, @Фанат, сначала говорили друг другу что-то вроде "да х$% там делать два месяца?", а потом чесали затылок и говорили что-то вроде "мда ..."

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

Любимый вопрос №1: вы храните товары разного цвета как отдельные товары, или как вариации одного?

Точно, это тоже мой самый любимый вопрос. Поднимался еще очень давно.
Я убежден, что каждый цвет это отдельный товар, свои своим артикулом, группировать товары уже можно на выводе.
К примеру, сейчас я для группы товаров по цвету указываю одного родителя, он и выводится в списке, но своя карточка есть у каждого товара.

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

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

Уже думаем. Пока есть вариант при первом импорте устанавливать связь только для нужных товаров о конкретного поставщика.
Было бы интересней сделать так, что бы цена импортировалась от того товара где она выгодней. Но это все значительно усложняет, ведь нужно учесть последовательность загрузки прайсов, что бы прайс 2-х недельной давности с более вкусной ценой не заменил реальные цены от другого поставщика. В общем тут еще надо думать.

 

[scorpion-ds]

а, кстати, померяй память когда будешь парсить
помню, как после месяца согласований и тестирования форматов сервер магазина по имени Ютинет прилег когда ему попробовали скормить реальный фид на пару десятков тысяч тысяч позиций в формате YML

Угу, тоже сталкивался, только не товары были, а каталог услуг, там вообще печаль была, использовал API WP еще и с мультиязычностью и кастомными полями (поля были реализованы средствами стороннего плагина ...), тормоза были жуткие. Пришлось считать время и память, когда "ресурсы" на исходе, то за ~20% до их исхода импорт завершался, JS выводил прогресс и делал запрос на следующий этап.

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

 

[Тугай]

Рекомендую посмотреть как это сделано в 1C Управление торговлей.

Если коротко, то прайсы поставщиков не импортируются в прайс магазина.
Прайс магазина формируется динамически на основании документов "Установка цен номенклатуры".
Эти документы можно формировать автоматом из на основании прайсов поставщиков, в которых установлено соответствие с товарами магазина.

Т.о. имеем историю установки цен и легко можно откатится если напортачили после очередного изменения формата прайса у поставщика.

 

[grigori]

Я убежден, что каждый цвет это отдельный товар, свои своим артикулом, группировать товары уже можно на выводе.
К примеру, сейчас я для группы товаров по цвету указываю одного родителя, он и выводится в списке, но своя карточка есть у каждого товара.

хахаха http://www.amazon.com/New-Balance-Woven-Shorts-Medium/dp/B00DVMCJH6/
сделай такой выбор цвета, как тут справа
если у тебя товар в 20 цветах - у тебя 20 товаров?

 

[scorpion-ds]

хахаха http://www.amazon.com/New-Balance-Woven-Shorts-Medium/dp/B00DVMCJH6/
сделай такой выбор цвета, как тут справа

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

если у тебя товар в 20 цветах - у тебя 20 товаров?

Почему бы и нет?

 

[grigori]

входные данные: 300 заказов в день, стоимость разноцветных ковриков для мышки $5 за штуку без учета доставки, и наценка, соответственно, $1, или $300 за день.

Вариант а: администратор обработает 50 заказов в день по мылу. С учетом болезней, отпусков и т.п. нужно около 10 администраторов, их ФОТ условно $10k + офис + компьютеры.
Номенклатура становится убыточна, поэтому "нет".

Вариант б: покупатель самостоятельно выбирает цвет и оформляет заказ. Заказ подтверждается по смс или автодозвоном и уходит на склад. Стоимость решения +$5k, затраты -$15k в месяц. Магазин может продавать коврики.

 

[scorpion-ds]

Если речь о конструкторе кроссовок, то я с утром могу представить как можно обойтись просто складом, ведь там по сути конструктор, тут появляется как минимум "станок" который примет от сайта заказ и пошьет нужные кроссовки.

Никто же не будет шить, что-то вроде такого заранее:
http://store.nike.com/gb/en_gb/product/air-force-1-mid-id/?piid=39495&pbid=439738611&mid=755184647#?piid=39495&pbid=439738611&mid=755184647

 

[AnrDaemon]

@scorpion-ds, до тебя пытаются донести мысль, что ответ не "да" или "нет". Если маржа позволяет включить ручную обработку заказа без существенного изменения стоимости, можно хоть вообще ничего не заводить.

 

[scorpion-ds]

Я думаю мы друг друга не поняли grigori о максимальной автоматизации бизнеса в целом, а я конкретно о конструкторе кроссовок ...

В любом случае, это не связанно напрямую с "Любимый вопрос №1".

 

[grigori]

я вот о чем
сидишь ты, пилишь магазин, приходит к тебе директор и спрашивает: сделаем продажу ковриков?
ты говоришь: надо каждый коврик оформлять отдельным товаром. директор считает и говорит, не выгодно.
Через месяц твой директор на конфе встречает условного @Redjik и обсуждает жизнь тяжелую. Тут Redjik вспоминает как мы это делали, и говорит: не вопрос, 5 штук баксов, и через месяц выбор ковриков в магазине!
Директор считает, и соглашается.
Через месяц магазин начинает торговать ковриками, Redjik улетает в Тайланд, а ты продолжаешь пилить CRM-ку.

Мораль: алгоритмы надо знать.