Ограничить оповещение клиентов о неоплаченных заказах для наложенного платежа, каким образом настроить уведомления об оплате, чтобы уведомлять только тех клиентов, которые должны предварительно оплатить заказ до отправки
Сергей Запольский написал: CSaleOrder::GetByID($ID); $paySystem = array('2'); // Это массив с ID платёжных систем кому слать письма с напоминанием if(!in_array($arOrder['PAY_SYSTEM_ID'] ,$paySystem)) { return false; }
Сергей, привет! Рад что ты еще жив-здоров, и даже способен работать с кодом. Подскажи, что с моим заказом по парсеру? Если не будешь доделывать верни предоплату.
Каталог товаров представляет собой набор инфоблоков, где каждый инфоблок определённая группа товаров со своим набором свойств. Каталог автомобилей - один инфоблок с элементами "автомобили". У каждого автомобиля есть множественное свойство "товары", но оно позволяет выбрать товар только из одного конкретного инфоблока. Как настроить это свойство, чтобы была возможность выбирать товары из разных инфоблоков (можно ограничиться только типом инфоблока)?
Необходимо настроить систему так, чтобы при создании или редактировании нового инфоблока символьный код генерировался автоматически, например транслитом из названия, как у разделов и элементов. Есть настройки для этого?
Suntechnic пишет: Вы упускаете главный вопрос и смотрите не в ту сторону, мне кажется. Правильно ставить вопрос так - В каких случаях НЕ нужно создавать новый тип инфоблока?
Вот пример, у меня пара сайтов сейчас на обслуживании... Первый уровень разделов каталога товаров - ВНЕЗАПНО типы ифоблоков. Второй уровень - инфоблоки. Нет слов. Ну ребята - вообще нет слов. Двенадцать типов только под каталог. В них около сотни ИБ... На одном из сайтов используется фильтр по товаром. Из-за того, что в каждом инфоблоке есть свойство CANTRY (страна происхождения), то этих свойств в таблице свойств 120 кажется или что-то рядом. И вот в фильтре, они фильтруются по значению этого свойства, которое указано по коду. Конец немного предсказуем - 15 секунд на генерацию если фильтруем только по стране, если еще и по цвету то около сорока, ну а если добавить еще какое-нибудь подобное свойство, страница вылетает по таймауту, база становится колом на 20 минут, сайт все это время лежит... Понятно, что быстренько заменил коды свойств на их ID в фильтре и клиент прыгал от радости видя как страница генерится за пару секунд при даже очень сложно фильтре, но это же не выход. Ошибка в архитектуре!
Спасибо за подробный ответ, описаны "грабли", на которые не хочется наступать! Было подозрение что они там лежат)))
Пришёл к выводу что первый уровень каталога товаров лучше всего делать Инфоблоком, т.е. для каждой группы товаров свой инфоблок, НО наткнулся на такой пример создания архитектуры (источник http://www.bexx.ru/module/arch.htm):
Цитата
Архитектура каталога товаров В стандартном интернет-магазине на "1С-Битрикс" у вас есть два основных варианта организации каталога товаров на основе инфоблоков. У обоих вариантов есть свои преимущества и недостатки. Рассмотрим сначала оба. В качестве условного интернет-магазина будет рассматривать относительно большой сайт с разнородными товарами, которые обладают различными характеристиками. Например, в нашем условном интернет-магазине продается электроника всего лишь трех видов: ноутбуки, телевизоры, мобильные телефоны. Допустим, каждый тип товара имеет по 10 характеристик, например, для ноутбуков этими характеристиками будет: частота процессора, тип процессора, диагональ экрана, разрешение экрана, объем жесткого диска и т.д. 10 наверное даже мало, в реальных условиях таких характеристик могут быть десятки. Итак,
1. Все товары в одном инфоблоке Имеется один единственный инфоблок "Каталог товаров", в нем хранятся товары всех типов вместе. Типы товаров разделяются только группами в инфоблоке (разделы инфоблока). А вот все характеристики придется хранить вместе. В итоге получаем 10 х 3 дополнительных свойств инфоблока и все они будут видны при редактировании товара. Редактировать партянку в несколько экранов не очень удобно. А если свойств десятки и типов товаров десяток? Такое редактировать нормально уже невозможно. Плюсы: простая архитектура в базе данных, простая логика для вывода товаров. Минусы: неудобное управление товаром, неудобство подбора и сравнения товаров, проблемы при расширении функционала, экспотенциальный рост нагрузки при увеличении типов товаров.
2. Все типы товаров в отдельных инфоблоках Разные типы товаров хранятся в различных инфоблоках. Этот способ организации каталога товаров более продвинутый, чем первый, но также не совершенен. Обычно отдельный инфоблок требует отдельной страницы для вывода. Таким образом вам необходимо будет создавать для каждого типа товаров отдельную страницу для вывода каталога товаров, устанавливать на ней компонент каталога товаров и настраивать его. Также появляются сложности управления товаров. К примеру, если контент-менеджер не знает какой товар где находится, ему придется перебрать все инфоблоки, потому что в 1С-Битрикс нет фильтра по всем инфоблокам в админке, есть только фильтр внутри одного инфоблока. Другая сложность заключается в дублировании свойств. Например, если у всех товаров надо добавить новое свойство, которое присуще всем товарам, то придется это свойство заводить в каждом инфоблоке отдельно, с парой инфоблоков еще можно справиться, но учитывать свойства десятка-другого инфоблоков уже слишком сложно. Плюсы: удобство редактирования товаров. Минусы: усложнение логики, неудобство управления раздельными инфоблоками, сложности при расширении ассортимента.
3. Предлагаемая архитектура В собственной реализации каталога товаров мы решили объединить плюсы обоих способов, исключив их минусы. Предлагаемая архитектура выглядит следующим образом:
Имеется один общий инфоблок с каталогом товаров - в нем хранятся основные данные товаров и общие свойства. Именно записи этого инфоблока являются товарами (имеют цены, описание, фотки, связи).
Характеристики товаров хранятся в отдельных инфоблоках. Каждый инфоблок отвечает за отдельный тип товара, например, ноутбуки. Свойства этого инфоблока - это характеристики для данного типа товаров. Они здесь описываются и хранятся.
Каждый товар связан со своими характеристиками значением специального свойства, в котором хранится ID записи с характеристиками. И каждая запись с характеристиками связана со своим товаром.
В инфоблоке "Каталог товаров" есть свойство "Тип товара" - это список инфоблоков заданного типа, которые и являются допустимыми типами товаров. При выборе значения из предложенного списка, на вкладке "Характеристики" подгружаются свойства выбранного инфоблока с характеристиками, т.е. характеристики, присущие данному типу товаров.
Тип товара также можно задать на раздел каталога товаров, при этом на любом уровне вложенности. Товары внутри такого раздела будут по умолчанию считаться с указанным типом.
Несмотря на кажущуюся сложность данной архитектуры, для пользователя всё выглядит просто и привычно. Основная сложность возникает для разработчиков - усложняется логика. Хотя старые компоненты можно использовать, но они будут полностью игнорировать привязанные характеристики товаров. Плюсы: удобство управления товарами и характеристиками, удобство развития ассортимента, удобство организации представления на сайте. Минусы: усложнение логики, необходимость использования новых компонентов Ниже приведено видео (0.98 Мб), демонстрирующее работу формы редактирования товара. При выборе типа товаров подгружается вкладка "Характеристики". Обратите внимание, что содержимое этой вкладки меняется в зависимости от выбранного товара.
Кто использовал такую архитектуру? Есть преимущества? Подскажите это реализовано штатными средствами Bitrix, можете описать как сделать подобное?
Алексей Коваленко пишет: нужно: в первую очередь для удобства в эксплуатации во вторую - у типа инфоблока можно задать ряд параметров, которые будут наследоваться инфоблоками, в него входящими (например использовать древовидный класс. групп)
Благодарю, Алексей! Если удобство опустить (в чём оно проявляется?) и предположить что ряд параметров у всех инфоблоков будет одинаков, есть практические рекомендации по созданию для каждого инфоблока своего типа?
Приветствую! Подскажите начинающему разработчику, в каких случаях нужно создавать новый тип инфоблока, и для чего это нужно?
Конкретный пример: В установленном Битриксе есть тип инфоблоков "Каталоги" в котором находится инфоблок "Продукция". Для каждого элемента продукции нужно задать конкретного производителя. Для создания инфоблока "Производители" нужно создавать свой тип инфоблоков или можно использовать тип "Каталоги"?