Есть 5 филиалов. Во всех филиалах одни и теже товары, могут отличаться только остаток и цены. Базы 1С у каждого филиала свои, но ID товаров одинаковые.
Как идеологически правильно организовать такой интернет-магазин? Для каждого филиала сделать по инфоблоку или же для каждого товара сделать дополнительные свойства в виде цен и остатка в разных филиалах?
Сергей Ковалев пишет: Не очень понятно, что такое ID товара в 1С. Артикул?
Да, артикул.
По производительности и потреблению ресурсов какое решение оптимально? Товаров довольно много... В районе 20 000. Причем для некоторых есть картинки. Картинки ведь битрикс в базу пихает? На первый взгяд, вариант с 5 инфоблоками увеличит объем базы примерно в 5 раз...
ID товара в 1С это не артикул. 5 инфоблоков - оптимальный вариант. Опишите событие OnBeforeIBlockElementAdd для хранения картинки в единственном экземпляре. Не понятно, что показывать пользователю: информацию из какого из 5-ти филиалов?
Alexey Andreev пишет: Не понятно, что показывать пользователю: информацию из какого из 5-ти филиалов?
При заходе на сайт пользователю будет предлагаться выбрать филиал. После выбора - кажем цены из этого филиала. Если не выбран филиал - берутся цены из филиала "по умолчанию".
Вот только неясно, что делать, если пользователь насоберет товаров из одного филиала, а при оформлении заказа окажется, что ему нужно из другого собирать... (филиалы по районам доставки отличаются)....
А, по-моему, классический магазин получается, с общей карточкой товара и товарными предложениями по нему из каждого филиала. Т.е. создать иблок в котором храниться товар с нужными полями (картинки, описания, свойства и т.д.), и иблок на каждый филиал, в котором храниться товар с ценой, остаток и т.д.
И лучше бы выделить "главную" 1С в которой описание, картинка и т.д. считается верной.
За размер базы при 20 000 позиций я бы не переживал.
Иван пишет: Т.е. создать иблок в котором храниться товар с нужными полями (картинки, описания, свойства и т.д.), и иблок на каждый филиал, в котором храниться товар с ценой, остаток и т.д.
То есть, при загрузке из 1с нужно будет грузить только стоимость и остаток из каждого филиала?
pashilyaev пишет: То есть, при загрузке из 1с нужно будет грузить только стоимость и остаток из каждого филиала?
Все зависит от общей задачи по интеграции, где собираются администрировать каталог, на сайте?
Наиболее простой вариант, когда основной каталог с описаниями и картинками ведется в ручную на сайте, а позиции выгружаемые из 1С программно (по вашему ID) связываются с такой карточкой товара. Если развернуть тему, нужно продумать что именно хранить в карточке товара, можно цену и "остаток из основной 1С", или среднюю цену и общий остаток, для отборов и сортировок. Все зависит от конкретных требований проекта.
Цитата
Alexey Andreev пишет: да. только при этом придется допиливать процедуры обмена в обоих системах.
В 1С можно ничего не менять, со стороны сайта может нечего особо серьезного и не придется делать, событий должно хватить.
И еще напомню, что одновременный обмен 2х и более 1С с сайтом - это не штатная ситуация которая приводит к ошибке обмена, так как обмен использует только одну временную таблицу.
Я бы рекомендовал еще обратить внимание на разделение прав. Права системно делятся на уровне инфоблоков - даете отдельные права на инфоблок каждому филиалу и они могут работать с ними даже через стандартную админку и работать под этой филиальной учеткой с 1С.
Общий инфоблок с иерархией и описанием товаров... Кто его будет админить?
Выборки...
Сразу продумайте логику выборки и фильтрации в каталоге. Если нужна сквозная фильтрация по всем филиалам (вывести товары с ценой ниже 10 руб...), то она наиболее эффективно работает либо с одним супер-инфоблоком хранящим цены/остатки всех филиалов, либо с одним базовым + одним расширяющим его по свойствам. Возможности соединения инфоблоков в системе - пока ограничены.
Если сначала выбирается филиал, а потом пользователь гуляет по ценам филиала - то смело можно один инфоблок, как предлагает Иван, отдать под иерархию и общее описание товаров, а отдельные инфоблоки с ценовыми предложениями отдать филиалам. И соединять эти два инфоблока в выборках и фильтрации - одним запросом.
Если планируется хранить много товаров и ценовых предложений (больше 100 тыс.) - подумайте сразу о инфоблоках 2.0 и индексах на фильтрующиеся поля.
Типы цен, вилки цен, валюты
Если планируете их использовать то одним супер-инфоблоком не обойтись. Нужен минимум один (либо для каждого филиала свой) инфоблок типа торгового каталога для работы с типами цен и вилками цен.
По поводу множественных обменов из разных баз: Можно написать типа менеджера закачек из 1С ( наподобие семофоров для многопоточного программирования или защёлок для базы данных ) чтобы 1С обращалась перед загрузкой к этому объекту с целью залочить выгрузку ( нужно придумать как в случае отмены выгрузки по каким-то причинам снимать блокировку на ресурса ) ну и разлочивать когда выгрузка с успехом завершена. Разумеется, выгрузку должен делать автомат...
вот с выборками интересней. Сначала предполагалось, что пользователь ищет товар и уже при добавлении в корзину показывается остаток и цена в каждом филиале.
А вот если филиал явно указан пользователем, то поиск идет только по нему.
Александр Сербул пишет: Если планируется хранить много товаров и ценовых предложений (больше 100 тыс.) - подумайте сразу о инфоблоках 2.0 и индексах на фильтрующиеся поля.
Товаров суммарно в районе 20 000. То есть каждом филиале не больше 20 000.
Разъясните пожалуйста следующие пункты: У вас в каждом филиале своя база 1С? В разных филиалах могут быть разные элементы справочника Номенклатура? Базы 1С не имеют синхронизации между собой?
Если это действительно так, то не встает ли вопрос, о неправильных бизнес-процессах в компании? И не проще ли начинать сейчас ломать выстраивать процессы учета в компании? Опыт подсказывает, что если отсутствует единый классификатор при таком обмене, то неизбежно появляется мусор и нестыковки из разных источников данных. Если убедить руководство в выстраивании процессов компании невозможно, то в дополнение к посту Ивана хотел бы добавить, что необходимо дополнить механизмом модерации товаров, в котором ответственное лицо вручную модерирует(утверждает) такие товары как новые товары или товары, имеющиеся в наличии только в одном филиале.
По моему мнению весь процесс должен выглядеть так: Есть основная БД с каталогом товаров. Новые товары могут появляться только в ней, а потом реплицироваться в остальные базы 1С. Магазин синхронизирует список товаров с основной БД а остатки, может быть с ценой, из филиалов. Правда таким образом все механизмы обмена придется создавать руками. P.S. К выравниванию бизнес процессов рано или поздно компания должна прийти, но стоимость исправления всего, что к этому моменту будет создано, будет выше.
Вы описываете идеальную картину, мой опыт подсказывает что никто ломать/строить бизнес процессы для сайта не будет, даже если это важный проект. Важный - не основной, а поломать основной некому не захочется.
Все будет нормально, если определить основной каталога товаров как один из выгружаемых, либо вести его в ручную на сайте.
Иван пишет: Вы описываете идеальную картину, мой опыт подсказывает что никто ломать/строить бизнес процессы для сайта не будет, даже если это важный проект. Важный - не основной, а поломать основной некому не захочется.
Все будет нормально, если определить основной каталога товаров как один из выгружаемых, либо вести его в ручную на сайте.
Холивар. Разное понятие идеальной картины. Способов организации сто тыщь мильёнов. Выбирать наверное приходиться исходя из денег.
agapit пишет: У вас в каждом филиале своя база 1С? В разных филиалах могут быть разные элементы справочника Номенклатура? Базы 1С не имеют синхронизации между собой?
Уточнил - базы синхронизированы, номенклатура одинаковая.
Ситуация аналогичная, есть 5 филиалов, 1С 8.2 + УТ ред 11, базы филиалов синхронизируются, вопрос - как показать в интернет-магазине остатки по филиалам.
Добрый день. Понравилась идея хранить информацию в разных инфоблоках, для разных складов (филиалов) попробовал создать инфоблок со складскими остатками:
создал пользователя sklad_1c, в группе Интеграция с 1С
инфоблоки: Каталог товаров (права на добавление у пользователя integration_1c) Каталог товаров на складе (права на добавление у пользователя sklad_1c) оба инфоблока в типе Каталоги
оба пользователя в группе Интеграция с 1С в настройках модуля Торговый каталог оба инфоблока отмечены, что являются торговыми каталогами для группы Интеграция с 1С разрешено управление импортом/экспортом
дал расширенные права инфоблоку для добавления данных соответствующим пользователем, запретил добавлять данные другим
создал в 1С 2 варианта обмена с сайтом - в одном Остатки по складам указал склад, в другом - магазин, соответствующие пользователи (логин / пароль) в результате в инфоблок Каталог товаров на складе так ничего и не выгружается, а выгружается по прежнему в Каталог товаров (хотя там прав на добавление этот пользователь не имеет)
Ситуация очень похожая - есть одна база 1С, в которой есть 13 складов, 7 складов в городе1 и 6 - в городе2.
На сайте надо отображать кол-во по каждому складу в зависимости от выбранного города.
То есть если выбран город1, то надо отображать общее количество товара на всех складах города1, а если выбран город2, то надо отображать общее кол-во товаров в городе2.
Причем ID товара на сайте надо чтобы был одинаковые у обоих городов.
Кто-то предлагал выгружать в разные инфоблоки товары по каждому городу - для нас это неприемлимо.