afwollis

поиск фразы по файлам ничего не дал, что ли?

эээ... а кто говорит об "урезании способов оплаты до одного"?

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

есть решение по тканям для магазинов мебели.

дорого.

подробности в ЛС.

Склад используется 1. есть URL на этот склад.

ок

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

рисуйте, как вы это себе визуально представляете.

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

эээ... какие ошибки?

пишете четкое ТЗ, по нему разрабатывается решение для вас.

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

любые изменения/ошибки, найденные ПОСЛЕ приема работы, - разбираются/делаются/исправляются за дополнительную плату.

вот ссылка на URL: и что она открывыет в браузере.

посмотрел.

мдэ... формат дикий, но обработать можно.

оставляешь только

$_['text_new_subject']          = 'заказ %s';

... = sprintf($language->get('text_new_subject'), $order_id);

тема оформления, конечно, дичь, но дело даже не в ней.

на приведенном в пример сайте функционал специфический и показанная "примерочная" тесно связана с другими данными/разделами/функционалом.

ТЗ есть или обои будем на окно примерять?..

99% запросов подобных моему подразумевают одно и то же.

не согласен.

у каждого свое видение механизмов своего бизнеса, наценок, скидок, бонусов, направлений (объемов данных, не всем нужны ВСЕ запчасти).

и еще много чего...

Например, вот один даже с этого форума. И даже с моим поставщиком (кстати, там даже есть описание API).

https://opencartforum.com/topic/38189-подключение-веб-сервиса-поставщика/

опять же - там пытались выудить из "заказчика" необходимую инфу.

с горем пополам более менее определились с общей картиной...

и "заказчик" пропал!

вменяемого ТЗ нет, "заказчика" нет.

Потому и жду когда кто-нить скажет: "скажи подробно чего надоть и дай описание АПИ", - а не кучу "глубокомысленных" предположений о моей платежеспособности.

а зачем "ждать непонятно чего", вместо того, чтобы "сразу предоставить подробное ТЗ" ?.. О_о

- - -

Ясен пень, что не хлеб))

Постараюсь завтра подготовить ТЗ.

мы все очень ждем.

ответил в ЛС с некоторыми дополнительными вопросами.

Freon3000, еще, собственно, совершенно не ясна ситуация по складам и стоимости.

в приведенном выше коде есть 4 склада с разным кол-вом и разной стоимостью.

в общем, вам надо сначала продумать и сформировать подробное ТЗ.

если затрудняетесь сделать это самостоятельно - можете привлечь разработчика и составить ТЗ вместе (разумеется затраченное время тоже должно быть оплачено).

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

о стоимости разработки говорить еще рано.

могу реализовать.

Все данные которые предостовляет поставщик в файле XML через URL.

Производитель, модель, цена, колличество, размер, вес.

в доках по товару столько данных

так все или не все?

какие куда?

учитывая

          <GroupBy GroupID="VendorID" Value="80000573"/>
          <GroupBy GroupID="ClassID" Value="L03002001"/>

так что обрабатывать надо будет не "только товары", а полный feed.

с конкретным ТЗ решаемо.

дорого.

нафига?

заучи и больше не разводи сопли: google -> rel=canonical

Правильно ли я понимаю, что такая схема рабочая? Может быть я что-то упустил?

все упускают.

именно факт округления.

Цена в российских рублях будет пересчитываться по установленному внутреннему курсу и округляться до 100 рублей.

в зависимости от стоимости товаров и методов/мест округления суммы могут получаться разные (стоимость одного товара, двух, пяти, десяти, ИТОГО всего заказа).

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

именно переписываем price если цена поменялась. Товаров более 500 тыс, оперативно по крону все не обновишь.

в смысле?

всегда можно разбить на группы по N товаров и запускать одновременно несколько задач (даже 10-20).

upd:

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

ааа... понятно.

только, оказывается, что k500 товаров тут ни при чем :-)

ПРОБЕЛ ТАМ ПОСТАВЬ.

КЭП.

что именно надо и в каком виде?

товары товарам - рознь.

ТЗ где?

А достаточно ли в конфигах пути менять?

в чистом движке - достаточно.

с изменениями - зависит от внесенных изменений/модулей.

есть такое для 15х. разрабатывалось именно по образу приведенного в пример магазина.

в связи с появлением интереса к такому решению сейчас планируется разработка оного для 2хх.

за подробностями в ЛС.

Если надо ТЗ, могу оформить конечно.

разумеется надо.

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

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

"поиск по базе на стороне" не даст возможности КУПИТЬ НАЙДЕННОЕ в твоем магазине.

в процессе ознакомления с таким ТЗ могут возникнуть дополнительные вопросы.

Поставщики, которых планирую подключить, Апи предоставят, только подключить.

это не хлеб, который кинул в корзину и на кассе оплатил.

это РАЗРАБОТКА разной степени сложности умноженная на кол-во API (поставщиков) и усложненная необходимостью ПОДРУЖИТЬ результаты ответов магазина-и-всех-API.

= = =

ТЗ, как не было, так и нет, а время мы уже свое потратили.

заказав разработку модуля-импорта именно под свой магазин и прайс.

шонеясновконсоли?

открывай файл-метод и дебаж.

Может нужно было думать в сторону доработки seo_url.php/seo_pro.php  ?

Чем такие извращения....

не надо.

для того и есть возможность указать в конфигах другие пути, чтобы не париться с механизмом формирования ЧПУ.

все правильно сделано.

"В итоге" никто не называет цену (на форумах).

потому что в итоге никто не готов оплачивать время на составление конкретного конечного ТехЗадания, без которого приходят абсолютно все.

Мне же нужен просто модуль, который после введения артикула запчасти в строку поиска, соединится с API поставщика, получит данные и выведет их на страницу клиенту магазина на Опенкарт 2.х. В чем сложность ? Не кажется что "Порш" лажовый какой-то получается ?

налицо полное непонимание процессов, объемов данных и работы.

с таким же успехом можешь встроить себе просто пользовательский поиск от google. результат будет примерно одинаковый.

tjga, porsche по стоимости лады-калины?

по авто-тематике в итоге оказывается, что никто не готов вкладываться в свои хотелки.

заказывай разработку под себя.

то ли тема оформления уг,

то ли проблемы с языковыми файлами,

то ли так сложились звезды и без тренированного звездочета не справиться.