dude

1.Модуль отображения дополнительных колонок на странице перечня товаров Идентификатор продукта; Дата обновления продукта (база должна «реагировать» на любые изменения — статус, цена, описание и прочее); Категория продукта; Производитель продукта Custom fields (произвольное количество таких колонок); Должна быть возможность фильтрации товара из списка по нескольким критериям (совпадения по нескольким колонкам; поиск по частичному совпадению в названии). Должна быть возможность сортировки (убывание/возрастание) по всем имеющимся колонкам и возможность установления порядка отображения самих колонок (и возможность скрывать колонки). Товар, которого нет в наличии — всегда должен быть в конце списка ( front & back ). Custom fields должны иметь возможность редактирования и на странице перечня товаров, и на странице конкретного продукта. Заголовки таких колонок должны быть редактируемыми. 2.Модуль отображения произвольных списков товара Принцип работы похож на стандартный модуль Featured. Необходима возможность задавать принудительный порядок отображения продуктов, сами продукты могут быть из любых категорий. Заголовок для каждого списка должен быть редактируемым и при необходимости быть ссылкой на категорию или произвольную страницу. Количество списков должно быть неограниченным. Должна быть опциональная привязка списка к категории. Например, отображать Список X и Список Y только с ноутбуками. Или отображать Список Z во всех категориях. Необходима возможность отображения похожего (относительно уже просмотренного покупателем) товара, имеющая опцию привязки к категории [необязательно]. Количество позиций списка должно ограничиваться в настройках модуля (глобальная настройка и зависящая от списка). У модуля должен регулироваться масштаб изображений в списке (глобальная настройка и зависящая от списка). Разметка модуля должна выводиться простым списком (ul/ol), контейнеру такого списка нужен свой класс (с возможностью ручного назначения). Работа оплачиваемая. Заинтересовавшихся разработчиков просьба назвать роялти и сроки. skype: eyelessprophet email: [email protected]

Версия - 1.5.1.3

Разработчик opencart явно страдает от биполярного расстройства, но узнать это довелось слишком поздно. Сделано было много, отступать некуда, и для нормального функционирования магазина осталось привести некоторые его элементы в более-менее дружелюбный вид. Для этого нужны модули, которые мне, к сожалению, найти не удалось. Возможно их и нет, но поинтересоваться у людей, которые явно знают больше моего - будет не лишним. Что за модули необходимы: #1 Модуль для создания произвольных списков товаров - принцип работы как у featured, только чтоб можно было создать много списков, и что совсем идеально - каждому задать свой размер изображений товаров. #2 Модуль, позволяющий выводить список featured в зависимости от категории, а не везде подряд (у магазина разные виды товаров, часто не связанных друг с другом). #3 Модуль, позволяющий на странице перечня товаров (backend) добавлять/убирать произвольные или заготовленные/произвольные поля. #4 Модуль, позволяющий там же искать товар по частичному совпадению в поле. #5 Модуль правки и ручного добавления заказов. Стандартно opencart не позволяет создавать заказ и редактировать его (изменение _всех_ данных, добавление/удаление товара; правка транзакций приветствуется). #6 Не совсем модуль, но тоже важно (товаров будет много) - Абсолютной победой было бы решение, позволяющее сохранять порядок атрибутов товара таким же, какой задан им в группе атрибутов (а не в том порядке, в котором они, атрибуты, были добавлены). Заранее благодарю.

Да.

1. Модуль отображения дополнительных колонок на странице перечня товара Наличие товара (in stock, out of stock); Дата обновления товара (база должна «реагировать» на любые изменения — статус, цена, описание и прочее); Поставщик; Цена поставщика (без множителя; с указанием наименования валюты); Расходы на доставку (сумма для клиента); Расходы на доставку (фактическая сумма); Категория товара; Custom fields; Модуль подразумевает возможность добавления/редактирования поставщиков и их привязки к товарам, а так же возможность указания множителя (курса) цены на отдельной странице. Привязка поставщика к товару должна происходить на странице перечня товаров, из выпадающего меню. Необходима возможность редактирования custom fields на странице товара (product backend) с опциональной возможностью вывода в магазин (product frontend). Должна быть возможность фильтрации товара из списка по нескольким критериям (совпадения по нескольким колонкам; поиск по частичному совпадению в названии). Должна быть возможность сортировки (убывание/возрастание) по всем имеющимся колонкам и возможность установления порядка отображения самих колонок. Товар, которого нет в наличии — всегда должен быть в конце списка (frontend & backend). Поскольку все заказы обрабатываются вручную, расходы («клиентские» и «фактические») будут указываться оператором в самом заказе. При этом, «клиентские» расходы должны опционально отображаться на странице отслеживания заказов. 2. Модуль персонализированных отчётов При создании заказа должна создаваться запись, в которой будет вынесен чистый приход (цена товара в магазине минус цена поставщика плюс расходы клиента минус фактический расход). На основе этих данных должны формироваться отчёты со следующими колонками: Дата создания заказа ID заказа ID (model) товара Наименование товара Цена товара в магазине + расход клиента (сумма) Цена поставщика (актуальная цена на момент создания заказа) Расходы (фактические) Прибыль Модуль подразумевает возможность выделения конкретного временного периода, конкретного товара, конкретного поставщика. Цена поставщика должна быть рассчитана исходя из установленного курса. Пример #1: товар iphone поставщик A отдаёт по цене 100. Поставщику А установлен курс — 8. Значит, цена поставщика равна 800. Пример #2: товар macbook поставщик B отдаёт по цене 2000. Поставщику B установлен курс — 1. Значит, цена поставщика равна 2000. Модуль должен учитывать любую произвольную (добавленную другим модулем) стоимость shipping fee/payment fee (первоначально эта функция использоваться не будет). Должна быть функция экспорта в эксель (xls, csv). 3. Модуль ручного добавления/правки заказа Должна быть функция редактирования существующего заказа — изменение, удаление, добавление товара. При этом должен происходить автоматический перерасчет его стоимости. Также необходима возможность изменения всех данных в заказе (кроме индентификаторов). Должна быть возможность ручного создания заказа с последующей его привязкой к клиенту (если клиент зарегистрирован). Правка/удаление транзакций. 4.Модуль отображения произвольного списка товаров Принцип работы примерно как у стандартного модуля featured, но количество списков должно быть неограниченным и списки должны иметь возможность отображения на любой странице. Необходима возможность задания порядка товаров, сами товары могут быть из любых категорий. Заголовок (bestseller, special offer) должен быть редактируемым и при необходимости быть ссылкой на категорию или произвольную страницу. Должна быть опциональная привязка списка к категории. Например, отображать список A только в категории с ноутбуками. Или отображать список B во всех категориях. Необходима возможность отображения похожего (относительно уже просмотренного покупателем) товара, имеющая опцию привязки к категории. Количество товара должно ограничиваться в настройках модуля. В самом модуле должен регулироваться масштаб изображений для каждого отдельного списка. Разметка модуля должна легко выводиться списком ul/ol, контейнеру такого списка нужен свой класс (с возможностью ручного назначения). 5.Порядок атрибутов Возможность сортировки атрибутов на странице товара. Не порядок их отображения на frontend странице товара, а порядок следования на backend странице товара (там, где он добавляется). Стандартно OpenCart отображает атрибуты в том порядке, в котором они были добавлены группе атрибутов. _________________________________________________________________________________ ДОПОЛНЕНИЯ Всё это не должно рухнуть после какого-нибудь обновления. Важна удобоваримость кода. Предпочтительно выполнее большинства операций через ajax. Первые три модуля зависят друг друга. Но, если это реально, можно обойтись одним, который бы включал в себя функционал всех трёх. Цена поставщика - это "финальная" цена, после применения множителя (после применения установленного поставщику курсу). Фактически это вторая цена, которая отображается только в админке. Первая цена - цена товара в магазине. Цена поставщика может меняться каждый день, а может меняться раз в месяц. Поэтому важно, чтобы в отчётах формировалась цена поставщика, актуальная на момент создания заказа Пример. Вася заказал iphone в 10 утра, по цене 700уе. Цена поставщика - 600уе. Значит, в отчёте будет 700 минус 600. В час дня поставщик прислал новый прайс. Петя заказал iphone в шесть вечера, по цене 700уе. Цена поставщика - 590уе. Значит, в отчёте будет 700 минус 590. Пример не учитывает расходов на доставку.

1. Модуль отображения дополнительных колонок на странице перечня товара Наличие товара (in stock, out of stock); Дата обновления товара (база должна «реагировать» на любые изменения — статус, цена, описание и прочее); Поставщик; Цена поставщика (без множителя и с множителем - на выбор; с указанием наименования валюты); Расходы на доставку (сумма для клиента); Расходы на доставку (фактическая сумма); Категория товара; Custom fields; Модуль подразумевает возможность добавления/редактирования поставщиков и их привязки к товарам, а так же возможность указания множителя (курса) цены на отдельной странице. Привязка поставщика к товару должна происходить на странице перечня товаров, из выпадающего меню. Необходима возможность отображения (и редактирования) custom fields на странице товара (product frontend/backend). Должна быть возможность фильтрации товара из списка по нескольким критериям (совпадения по нескольким колонкам; поиск по частичному совпадению в названии). Должна быть возможность сортировки (убывание/возрастание) по всем имеющимся колонкам и возможность установления порядка отображения самих колонок. Товар, которого нет в наличии — всегда должен быть в конце списка (frontend & backend). Поскольку все заказы обрабатываются вручную, расходы («клиентские» и «фактические») будут указываться оператором в самом заказе. При этом, «клиентские» расходы должны опционально отображаться на странице отслеживания заказов. 2. Модуль персонализированных отчётов При создании заказа должна создаваться запись, в которой будет вынесен чистый приход (цена товара в магазине минус цена поставщика плюс расходы клиента минус фактический расход). На основе этих данных должны формироваться отчёты со следующими колонками: Дата создания заказа ID заказа ID (model) товара Наименование товара Цена товара в магазине + расход клиента (сумма) Цена поставщика (актуальная цена на момент создания заказа, естественно с множителем) Расходы (фактические) Прибыль Модуль подразумевает возможность выделения для просмотра конкретного временного периода, конкретного товара, конкретного поставщика. Цена поставщика должна быть рассчитана исходя из установленного курса. Пример #1: товар iphone поставщик A отдаёт по цене 100. Поставщику А установлен курс — 8. Значит, цена поставщика равна 800. Пример #2: товар macbook поставщик B отдаёт по цене 2000. Поставщику B установлен курс — 1. Значит, цена поставщика равна 2000. Модуль должен учитывать любую произвольную (добавленную другим модулем) стоимость shipping fee/payment fee (первоначально эта функция использоваться не будет). Должна быть функция экспорта в эксель (xls, csv). 3. Модуль ручного добавления/правки заказа Должна быть функция редактирования существующего заказа — изменение, удаление, добавление товара. При этом должен происходить автоматический перерасчет его стоимости. Также необходима возможность изменения всех данных в заказе (кроме индентификаторов). Должна быть возможность ручного создания заказа с последующей его привязкой к клиенту (если клиент зарегистрирован). Правка/удаление транзакций. 4.Модуль отображения произвольного списка товаров Принцип работы примерно как у стандартного модуля featured, но количество списков должно быть неограниченным и должно иметь возможность отображения на любой странице. Необходима возможность задания порядка товаров, сами товары могут быть из любых категорий. Заголовок (bestseller, special offer) должен быть редактируемым и при необходимости быть ссылкой на категорию или произвольную страницу. Должна быть опциональная привязка списка к категории. Например, отображать список A только в категории с ноутбуками. Или отображать список B во всех категориях. Необходима возможность отображения похожего (относительно уже просмотренного покупателем) товара, имеющая опцию привязки к категории. Количество товара должно ограничиваться в настройках модуля. В самом модуле должен регулироваться масштаб изображений для каждого отдельного списка. Разметка модуля должна легко выводиться списком (ul/ol), контейнеру такого списка нужен свой класс (с возможностью ручного назначения). 5.Порядок атрибутов Возможность сортировки атрибутов на странице товара. Не порядок их отображения на frontend странице товара, а порядок следования на backend странице товара (там, где он добавляется). Стандартно OpenCart отображает атрибуты в том порядке, в котором они были добавлены группе атрибутов. _________________________________________________________________________________ - Всё это не должно рухнуть после какого-нибудь обновления. - Будет модуль на русском, английском, фарси или древнем индонезийском диалекте - неважно - У автора будущих модулей должна отсутствовать шапка-невидимка :) - ... И должно быть достаточное представление об OpenCart. - Важна удобоваримость кода. - Предпочтительно выполнее большинства операций через ajax. - Первые три модуля сильно зависят друг от друга. Будет это один модуль или три - неважно. Важны функционал и стабильность. ПОЯСНЕНИЯ Почему нельзя купить модули по отдельности? Потому что работают они тоже по отдельности. Не говоря о том, что написаны они людьми, которые далеки от перфекционизма или банального чувства прекрасного, дополненного капелькой ответственности и заинтересованности. Почему нельзя использовать встроенные курсы валют? Потому что поставщиков Nное количество, и это один из наиболее важных моментов функционирования магазина. Покупатели видят только одну, "главную" валюту. Что за адский ад с ценами? Цена поставщика - это "финальная" цена, после применения множителя (после применения установленного поставщику курсу). Фактически это вторая цена, которая отображается только в админке. Первая цена - цена товара в магазине. Цена поставщика может меняться каждый день, а может меняться раз в месяц. Поэтому важно, чтобы в отчётах формировалась цена поставщика, актуальная на момент создания заказа Пример. Вася заказал iphone в 10 утра, по цене 700уе. Цена поставщика - 600уе. Значит, в отчёте будет 700 минус 600. В час дня поставщик прислал новый прайс. Петя заказал iphone в шесть вечера, по цене 700уе. Цена поставщика - 590уе. Значит, в отчёте будет 700 минус 590. Предложения просьба оставлять либо в теме, либо в ЛС, либо в скайпе - eyelessprophet