EVMedvedev

Уточните задачу в почту [email protected]. Если я правильно понимаю, то нужен не совсем импорт а именно синхронизация данных в базах данных разных магазинов. И если будете писать, то вышилите пожалуйста образцы XML файлов. Подобная задача здесь уже обсуждалась.

Если в течение 10 дней не найдете исполнителя пишите на [email protected].

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

Можно модернизировать бесплатный модуль оформления заказа в одну страницу. Но только я пока недели 2 в запаре. Поспрошайте здесь, может еще кто сможет сделать. Если не найдете - пишите на [email protected].

Если в течение 10 дней не найдете исполнителя на данную работу пишите на [email protected] Сейчас пока завал.

Написать такое можно, но повозиться придется. По сути вы хотите реализовать интернет-комиссионку, но типовые магазинные движки (включая openCart) под это не приспособлены, так что допиливать любой из них нужно много и долго, а значит будет очень дорого. То есть фактически надо по меньшей мере часть админки, связанную с редактированием товаров продублировать в личном кабинете. Но скорее всего этим не ограничится. Понадобятся дополнительны механизмы взаиморасчетов между продавцами и покупателями делать и многое другое, так что прежде чем начинать писать надо фактически бизнес-план и проект ПО сделать. Или вы хотите просто продублировать идею всяких avito и slando?

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

Хороший вопрос :-).

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

Классный материал. Спасибо!

Покупают много, но вопрос почему магазин не приносит прибыль не простой. В одних случаях не нравится поиск, в других - процедура оформления заказа (в некоторых движках это легко отслеживается когда корзин формируется много а заказов по ним мало), в третьих - цена и т.п. Кстати поиск и оформление заказа это базовые эдементы обслуживания в интернет магазине и если они построены плохо, то я лично воспринимаю это как неуважение и в такой магазин больше не приду. Покупают в основном в интернет-магазинах а не на сайтах, внешне похожих на интернет магазины (то есть там где покупателя любят и уважают). Электронные платежи используются для недорогих товаров и как правило нематериальных (ПО, доступ к каналам передачи данных, к источника информации или информационных услуг и т.п.) для материальных товаров предоплата проходит только для очень дешевых товаров (когда не очень обидно потерять деньги если магазин оказался лохотроном). Я сам не продаю через интернет магазин но покупаю так же как и другие члены семьи (косметику, книги и учебные пособия, купоны на скидки и т.п.). Хотя нет, несколько раз продавали ненужные вещи. Один раз был курьезный случай - от скуки выставили на продажу за копейки не использованную электрическую сковородку и у нас ее купили. Отправили наложным платежом из Москвы в Петропавловс-Камчатский. Мне бы такое кто рассказал - я бы не поверил. И человек купил сковородку за 500 рублей не смотря на то что доставка обошлась рублей в 200-300. Не знаю зачем. Может быть для коллекции? Сковородка была еще с советских времен. В общем сделать в интернет-магазин, то есть бизнес - приносящий прибыль, не проще чем создать реальный магазин, хотя затраты и меньше. Нужно рассматривать это именно как бизнес-процесс с особенностями средств производства а не как сайт с картинками и текстом. При неграмотном подходе даже самые низкие цены могут не дать желаемого эффекта.

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

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

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

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

Полмиллиона записей это весело. Я неделю назад делал скрипты для выгрузки данных из системы складского учета Фрегат и размещения ее на хосте для доступа региональным партнерам магазина при формировании заказов на товары, планируемые к поставке. При загрузке 10 000 записей из файла Excell хост вываливается по таймауту (при типовых настройках). И это при том, что там фактически всего 4 колонки в таблице было. Хост сидит на персональном сервере и неслабом и хостов на нем раз-два и обчелся. Время конвертации примерно 5 минут и ни какими методами сократить это время больше не удалось. Под полмиллиона записей это надо выделенный сервер арендовать и настраивать соответственно. Можно еще грузить с клиента по одному специальным скриптом например через curl, либо дробить массив данных на части и вешать на таск-шедулер загрузку (по крайней мере можно обойти проблемы таймаута с WEB-сервером nginx. В общем не думаю, что это так просто как вам кажется. Причем если делать именно обновления а не перезапись, то это будет дольше хотя бы уже потому, что тогда надо выполнять 2 SQL запроса вместо одного (сначала проверять наличие записи, а потом либо обновлять либо добавлять, иначе SQL запрос отвалится по ошибке). Да есть еще вариант конвертировать в оффлайне на локальной машине, а потом грузить таблицы бэкапом в виде SQL скриптов. Так быстрее всего поскольку именно на конвертацию уходит 99% времени. Преобразование файлов формата Excell 2003 в разы более ресурсоемкое чем более поздних, но те конвертеры, которые мне попадались ориентированы именно на этот формат. Это относится и к тому конвертеру, с которого началось обсуждение. А разработками бесплатных модулей как правило занимаются не профессиональные программисты, а владельцы интернет магазинов, имеющие небольшие знания по программированию (такая картина не только с OpenCart, но с любыми бесплатными движками). Именно поэтому как правило такие модули работаю ненадежно с низкой производительностью, имеют весьма ограниченную функциональность и потому требуют допиливания или являются источником угроз для взлома (как тот же конвертер в PDF формат для которого есть пособие по взлому через него как раз движка OpenCart где автор рассказывает как ломал сервер opencart.com ).

Пытался связаться с вами почтой, но вернулось сообщение об ошибочности почтового адреса получателя. Напишите мне на [email protected] с действующего адреса. Есть вопросы по ТЗ.

То-то и оно что за 35 долларов его писать ни у кого нет ни малейшего желания. Вот модуля и нет :-). Длительность такой работы примерно рабочая неделя (5 человекодней) +/1 день, а значит при средней цене рабочего дня нормального спеца в 3000 - 3500 руб получается что общая стоимость разработки грубо в районе 15000 р, то есть соответственно 500$ а не 35$. И то еще многое зависит от подробностей.

Написать подобный модуль можно, но вопрос в том, сколько вы готовы заплатить за его разработку (то есть не за модуль, а за работу по его созданию). Стоит ли игра свеч. Причем я бы делал модуль с расчетом на файлы формата Excell 2007-2010, а не 2003 как предлагаемые бесплатно модули конвертации. С ним и работать легче и с вопросами вместо букв бороться проще есть и другие преимущества.