Нужен скрипт для автозаливки товаров

[rider76]

Спасибо за информацию. Есть еще небольшой вопросик, у меня уже установлен модуль экспорта, который с форумов бесплатный. CSV import Pro встанет без проблем с другими модулями экспорта, или надо будет удалять бесплатный модуль ?

[pmp]

CSV import Pro встанет без проблем с другими модулями экспорта

[rider76]

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

Вот прайс лист с большим количеством позиций (около 212 тысяч) для экспериментов ( заводской прайс завода MAN Германия ). Сделан в несколько колонок. PART NO. - артикул (модель), DISCRIPTION-наименование, GROSS PRICE - цена, DISCOUNT CODE - группа скидок (это не надо), WEIGHT KG - вес. Лист 2 ненадо загружать, там RABAT - расшифровка скидок.

MAN+2011-9+CLIENTS.zip

[Yesvik]

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

Заявление не имеющее ничего общего с действительностью.

Куча говнокода есть и в платных и в бесплатных движках...

Именно поэтому как правило такие модули работаю ненадежно с низкой производительностью, имеют весьма ограниченную функциональность и потому требуют допиливания или являются источником угроз для взлома (как тот же конвертер в PDF формат для которого есть пособие по взлому через него как раз движка OpenCart где автор рассказывает как ломал сервер opencart.com ).

Интересовался сколько движков было взломано через PDF? и платных в том числе...

[EVMedvedev]

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

Тогда у вас встанет еще одно проблема - поиск. Я ни в одном бесплатном движке не видел нормальной поисковой системы, рассчитанной на вашу номенклатуру. Большинство магазинных движков (OpenCart не исключение) рассчитаны на очень маленькую номенклатуру - примерно 200 товарных позиций, которую раскидав по категориям можно получить порядка 20 страниц со списком товара по 20-30 страниц на товар. Если на каждую группу товаров будет по 10 страниц где на каждой по 50 товаров, с такого сайта пользователи будут бежать как очумелые и при этом сильно раздраженные.

И еще одни вопрос сколько посетителей вы планируете обслуживать ежедневно. Дело в том что для крупных порталов как правило используется более серьезный движок - Magento и при этом магазин долго и упорно допиливается. Предусматривается возможность построения кластеров для базы данных (когда запросы на чтение и запись разделяются физически по разным железкам, работающим согласованно с одной базой) построения кластеров для WEB серверов когда пользователи могут разделяться по тематическим подмагазинам (торговым залам) раскиданным по разным доменам, сидящим физически на разных железках, да еще поисковые запросы для ознакомления с товаром обслуживаются одними доменами, а запросы на оформление заказов и проведения взаиморасчетов другими).

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

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

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

[EVMedvedev]

Заявление не имеющее ничего общего с действительностью.

Куча говнокода есть и в платных и в бесплатных движках...

Интересовался сколько движков было взломано через PDF? и платных в том числе...

Если бы я был не прав, то модуль, с которого началось данное обсуждение давно перевели бы на работу с файлами нового формата (с ними намного удобнее и скорость обработки скорее всего повыше). На это все таки было 5 лет (при том что объем работ на неделю). Но суть в том, что автор темы сразу сказал, что не знает как переделать, но ему это нужно, а я знаю как переделать, но поскольку я зарабатываю на разработке ПО, то мне мне заниматься такой переделкой бесплатно не интересно. Если кто-то и заказывал себе переделки за деньги, то это его конкурентное преимущество и он раздавать его не будет, а тот кто исполнял такие доработки за деньги тоже выкладывать бесплатно не будет, чтобы не портить отношения с достойным заказчиком. Вот и результат - модуль, который видимо изначально разрабатывался явно более 5 лет назад скорее, всего по заказу производителей opencart для привлечения пользователей или распространялся на тот момент на платной основе, теперь стал бесплатным и дорабатывается только при изменении структуры данных БД магазина по мелочам без кардинальных изменений. А вот для PrestaShop например правда для старой версии (1.3) была сделана даже специальная клиентская программа (полноценное Windows приложение, распространявшееся наплатной основе) которое позволяло выполнять множество групповых операций с базой данных удаленно, если есть соответственно доступ к БД).

Что касается множества косяков в платном ПО, то я об этом в курсе - сам пользователь продуктов от Microsoft :-).

[EVMedvedev]

Вот прайс лист с большим количеством позиций (около 212 тысяч) для экспериментов ( заводской прайс завода MAN Германия ). Сделан в несколько колонок. PART NO. - артикул (модель), DISCRIPTION-наименование, GROSS PRICE - цена, DISCOUNT CODE - группа скидок (это не надо), WEIGHT KG - вес. Лист 2 ненадо загружать, там RABAT - расшифровка скидок.

А почему в несколько колонок? Экселевский лист не позволяет все одну колонку разместить?

[rider76]

А почему в несколько колонок? Экселевский лист не позволяет все одну колонку разместить?

Спасибо за информацию, пока буду экспериментировать и искать выход из положения. Я и есть тот владелец интернет-магазина (точнее собираюсь им стать), имеющий небольшие знания по программированию. Такое количество позиций мне надо было именно для привлечения клиентов. Такой прайс на самом деле получить от завода сложно и он если есть, то совсем не в формате exel ( что-то типа программы , построенной с помощью access и возможностью поиска по номеру). Я думал о том, что если это все в магазин загнать, то либо затраты на хостинг будут невразумительные, либо сайт будет тормозить со страшной силой, а скорей всего и то и другое. Есть еще вариант для привлечения клиентов просто подвесить этот прайс в виде таблицы и с обычной отправкой запроса на почту, а в сам магазин добавить позиции в наличии или в шаговой доступности так сказать. За прайс извиняюсь, что в таком виде, делался для удобства визуального просмотра.

[EVMedvedev]

Спасибо за информацию, пока буду экспериментировать и искать выход из положения. Я и есть тот владелец интернет-магазина (точнее собираюсь им стать), имеющий небольшие знания по программированию. Такое количество позиций мне надо было именно для привлечения клиентов. Такой прайс на самом деле получить от завода сложно и он если есть, то совсем не в формате exel ( что-то типа программы , построенной с помощью access и возможностью поиска по номеру). Я думал о том, что если это все в магазин загнать, то либо затраты на хостинг будут невразумительные, либо сайт будет тормозить со страшной силой, а скорей всего и то и другое. Есть еще вариант для привлечения клиентов просто подвесить этот прайс в виде таблицы и с обычной отправкой запроса на почту, а в сам магазин добавить позиции в наличии или в шаговой доступности так сказать. За прайс извиняюсь, что в таком виде, делался для удобства визуального просмотра.

А, знакомая схема работы. У меня есть заказчик, так у него такая схема торговли. Есть очень крупный поставщик товаров, у которого есть мощная система взаимодействия с мелкооптовыми продавцами (ну я упоминал кажется про Фрегат) и они из этой системы получают информацию об остатках товара на складе главного оптовика ( в вашем случае завода) и размещают ее на хосте, где розничные клиенты делают заказы. Они соответственно отправляют данные о собранных заказах или отказах обратно главному поставщику, тот пересчитывает остатки после заказов всех мелких оптовиков и последние опять выбирают отчет о текущем состоянии остатков, снова выкладывают их на свои хосты и т.п. В результате к моменту прихода товара он весь уже фактически зарезервирован или продан по предоплате. В этом случае актуальна проблема очень частого обновления части данных о товаре как в вашем случае, но там я им делал специализированную системку, где ключевыми полями в БД являются именно артикулы, а не специальные ключевые целочисленные поля с автоувеличением (типа product_id). В этом случае целостность данных в БД сохраняется при перезаливке прайс-листов. В OpenCart (как в большинстве других не считая Magento) все программы заливки рассчитаны только на первоначальное одноразовое наполнение с последующей корректировкой через админку, а собственные внутренние индексы ведутся потому что в маленьких магазинах артикулы не используются. Так что на OpenCart ваша задача решается только большой переделкой ядра движка.

[rb2]

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

Теория и ля-ля. Ничего общего с действительностью.

[rider76]

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

По схеме работы вы угадали. Вот только основную часть данных не требуется обновлять часто (только раз в полгода, примерно так обновляются цены на заводе). Часто будет обновляться как раз небольшое количество позиций(от 5 до 15 тыс примерно), основная масса позиций будет под заказ. Наличие позиций под заказ обновлять не обязательно, так как 99% номенклатуры всегда доступно для единичных заказов (опт в расчет не беру, всегда отдельно обговаривается).

[EVMedvedev]

По схеме работы вы угадали. Вот только основную часть данных не требуется обновлять часто (только раз в полгода, примерно так обновляются цены на заводе). Часто будет обновляться как раз небольшое количество позиций(от 5 до 15 тыс примерно), основная масса позиций будет под заказ. Наличие позиций под заказ обновлять не обязательно, так как 99% номенклатуры всегда доступно для единичных заказов (опт в расчет не беру, всегда отдельно обговаривается).

Ну 15 тыс позиций админкой магазинного скрипта (причем любого) не накликаешь. В вашем случае лучше делать что-то простое, но специализированное. Скорее всего вам нужна не система формирования заказов, а чисто поисковая система для удобства работы пользователей. Заказы и по телефону можно принять, а сейчас надо клиентуру привлекать. Тогда лучше закачивать товар в таблицу в БД на хост и предоставить пользователям возможность поиска и подбора деталей по параметрам и по артикулу прежде всего. Ключевым полем в БД сделать атрикул, потому что потом вокруг него можно накручивать картинки, технические параметры и т.п. при \том будет гарантия что целостность данных в базе будет всегда, до мех пор, пока завод не надумает менять систему генерации артикулов. Постепенно сделаете свой собственный специализированный магазин, который будет максимально заточен под ваши задачи. Я думаю это самый оптимальный путь в вашем случае. Да и обойтись это на круг может существенно дешевле чем карежить типовой движок не предназначенный для ваших целей. В общем если надумаете пишите в почту на [email protected].

[Rosna]

Скажите пожалуйста, а обьявить локаль русскую - это вот это добавить?

setlocale(LC_ALL, 'ru_RU.CP1251', 'rus_RUS.CP1251', 'Russian_Russia.1251');

[spambot]

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