Перейти до вмісту
Пошук в
  • Детальніше...
Шукати результати, які ...
Шукати результати в ...

multimerch

Новачок
  • Публікації

    11
  • З нами

  • Відвідування

Повідомлення, опубліковані користувачем multimerch

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

     

    Для базовой интеграции со сторонними шаблонами обычно требуются три основных вещи – изменения в файле vqmod/xml/multimerch_c_hooks.xml для правильного размещения HTML-хуков в темплейтах шаблона, все необходимые изменения тплок и контроллеров для конкретного шаблона в файле multimerch_названиешаблона.xml и дополнительный набор стилей - мы его обычно храним в catalog/view/theme/(шаблон)/stylesheet/mm.css.

     

    В зависимости от шаблона, может понадобиться оверрайд одного или нескольких Мультимерчевских темплейтов, чаще всего это catalog-seller-profile.tpl и catalog-seller-products.tpl. В этом случае они берутся из папки catalog/view/theme/default/template/multiseller/ и оверрайдятся в папке catalog/view/theme/(шаблон)/template/multiseller/.

  2. 8 hours ago, Polcovnikvvp said:

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

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

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

     

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

    Магазин для каждого клиента - как будет правильней на поддомене или домен для каждого магазина свой (тут нужно смотреть как выгоду для меня).

    Вот теперь вопрос:

    1) Как объединить базу всех магазинов, что бы в общем магазине были видны все товары, а на отдельных магазинах только их товары.

    2) У каждого товара в магазине будут указаны остатки на складе, как их вычитать при продажах

    Пример: в магазине 1 - на складе 2 яблоки, при продаже с общего сайта, в магазине 1 должно минусоваться количество, так же при продаже с самого магазина 1, с базы общего сайта должно минусоваться. А если вообще нет товара в остатках, то удаляем товар с главной страницы сайта. То есть товары со статусом "Нет в наличии" не видны покупателям.

    Все сайты будут на одном сервере. 

     

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

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

     

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

     

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

    • публикация и редактирование товаров
    • обработка заказов
    • обрабока платежей

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

     

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

    • +1 1
  3. Мультимерч за основу тоже сгодится, но, возможно, придется допиливать. Когда-то был похожий запрос.

     

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

     

    Проще, конечно, начать с обычного Мультимерча. По сути, мы продавцам уже даем их личный раздел ("магазин") на площадке с их собственной структурой категорий, а их товары можно отображать как в их магазинах, так и в основных категориях сайта. Импорты товаров продавцами через ЦСВ тоже есть, правда без прямой интеграции с 1с.

  4. В рамках плана Professional предоставляем наборы совместимости MultiMerch для всех шаблонов от ThemeBurn, чтобы использовать их с Мультимерчем из коробки. В этом случае "собирать вместе" ничего не надо - все отлично ставится друг на друга согласно нашему гайду, именно так для всех наших бизнес-клиентов магазины настраиваем. Если ваш программист - Опенкартщик, но при этом не может в три шага поставить Опенкарт, шаблон и Мультимерч -  рекомендую найти другого программиста :) А вообще, пишите нам в сапорт - поможем.

     

    По поводу качества шаблонов от ThemeBurn - дело вкуса, мы с ними проблем практически не имели. Если что-то появляется - парни из их команды всегда готовы на пальцах объяснить, что к чему. Рекомендовать вместо них Журнал с их корявым квикчекаутом (кто ковырял - тот знает) и самодельным фреймворком вместо Бутстрапа точно бы не стал (наш набор совместимости для Журнала состоит из трех тысяч строк дополнительных стилей, скриптов и хмлок). Рекомендовать дефолтный Опенкартовский шаблон для полноценного лайв магазина - тем более.

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

  6. 1&3: А статус заказа Completed? ММ по дефолту не учитывает незавершенные заказы и не отображает их в разделах продавцов. Немного по этой теме тут: http://multimerch.com/docs/transactions-seller-balance/. Удалить строку, кстати, легко - надо в multimerch_core_productpage.xml найти $ms_catalog_seller_profile_totalsales и удалить ее целиком.

     

    2. Эта галочка разовая, т.е. "Известить ли продавца о данном изменении профиля". 

     

    4: Ошибка пофикшена в последнем коммите. По поводу статусов заказов у нас на форуме дискуссия: http://community.multimerch.com/t/orders-suborders-and-order-statuses/55/2. Сейчас реализация хромает, да.

     

    Ну и в дальнейшем вопросы лучше на наш форум тоже постить. Думаю, создадим русскоязычный раздел для таких случаев )

×
×
  • Створити...

Important Information

На нашому сайті використовуються файли cookie і відбувається обробка деяких персональних даних користувачів, щоб поліпшити користувальницький інтерфейс. Щоб дізнатися для чого і які персональні дані ми обробляємо перейдіть за посиланням . Якщо Ви натиснете «Я даю згоду», це означає, що Ви розумієте і приймаєте всі умови, зазначені в цьому Повідомленні про конфіденційність.