Роман Забродин (Все сообщения пользователя)

Я был в отпуске. Приобрести данный модуль очень просто. В действии отлично себя зарекомендовал Ответил в личке.

Реализовали тупо стандартными средствами -- каждый склад есть отдельный инфоблок. Мне не нравится -- высокая избыточность данных. См. постановка задачи 1


По нагрузке при выгрузке, удалось ее уменьшить в два раза. Но это как слону дробина. ТП говорит что в настройках нашего сервера мешает что-то очень специфичное. Если найдем что -- отпишусь и возможно включат в проверку bitrix_server_test.php

Можем:
http://dev.1c-bitrix.ru/api_help/main/general/component20/index.php

http://dev.1c-bitrix.ru/api_help/subscribe/index.php

По данному вопросу, в Битрикс, нет разумных решений -- только компромиссные.

У нас медленнее в 100 раз. Я был уверен что такое время загрузки ненормально, хотя ТП меня почти убедила в обратном. Будем копать.

Можно еще попросить 1с-никак формировать XML только с индефикаторами товаров. Затем сравнивать два массива (если 100 000 то так просто их не сравнишь). Кого в файле нет -- того на удаление.
Успешно решали недавно такую задачу.

Сделать можно все. Потребуется программированию.

На сколько вижу из кода photogallery.section.list

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

Кастомизируйте компонент bitrix:subscribe.news чтобы фильтрация в Getlist осуществлялась не по полю "дата", а по вашему свойству типа "дата".

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

Почтовые события срабатывают в компонентах. В результате генерируются сообщения по числу почтовых шаблонов привязанных к данному почтовому событию. К рассылке это не имеет никакого отношения.
Если хотите одновременно делать почтовую рассылку -- найдите в соответствующих компонентах где вызываются почтовые события и вставьте там свой код для работы с рассылками.

Кстати, было бы полезно иметь в этом списке:
http://dev.1c-bitrix.ru/api_help/main/events/index.php
событие "сработало почтовое событие"

Не будет. Товар может состоять в разных разделах одного инфоблока, но в разных инфоблоках он быть не может.

Задача ясна: вы можете привязать элемент к нескольким разделам, но вам хотелось бы закрепить элемент за одним главным разделом потому что из его кода строится URL до элемента. И этот главный раздел не всегда с меньшим ID (т.е. не всегда попадает в IBLOCK_SECTION_ID элемента.)

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

Может попробовать по событию при сохранении элемента IBLOCK_SECTION_ID перезаписывать. Значение для него как раз брать из свойства пользовательского типа привязки к родным разделам. Т.е. в этом свойстве вы будите как раз выставлять основной раздел. Как БУС поведет себя при этом не знаю.

Стандартно нет такого функционала. Для статических папок и страниц можно либо включать ссылку в путь, либо не включать.
В шаблоне bradcrumbs может быть CMain::GetDirPropertyList поможет:
"Возвращает массив свойств раздела, собранных рекурсивно до корня сайта."
http://dev.1c-bitrix.ru/api_help/main/reference/cmain/getdirpropertylist.php

Данный компонент выводит сообщения блога с возможностью фильтрации по тегам и дате. Никакого отношения к модулю инфоблоков он не имеет.

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

Добавить множественное поле типа файл. Туда прикреплять превьюшки.  В компоненте их вытаскивать и использовать.

Другой вариант создать инфоблок с видео. У элементов завести все необходимые свойства. Эти элементы-видео привязывать в ваших элементах.

1. Стандартно нет. Можно дописать ~1 час.
2. Стандартная возможность для свойств типа число.

В одном инфоблоке хранить клоны товара с разными значениями набора свойств и разными ценами.

Импорт товаров (import.xml) на первый склад завершен:


Производительность веб-сервера выше эталонной: 34.22 (локальный ПК разработчика)
Итого 18 часов выгружали ~20000 товаров на первый склад, сейчас, видимо, еще столько же потребуется для выгрузки товарных предложений.
А еще 5 складов.

Итого заказчику потребуется 180 часов (7,5 суток) на то чтобы выгрузить 20т. товаров на сайт.

Тех. поддержка:

10820 минут!
Это по 30 секунд на каждый товар чтобы вбить ему вручную по набору цен для каждого из 5 складов.
То есть автоматизация выгрузки цен от 1С-Битрикс сопоставима по времени с набиванием цен вручную. А если процесс запаралелить подключив несколько набивальщиков то и значительно уступает ручной работе.

По мнению ТП это нормально.

Мое мнение -- это явно не нормально.

Совершенно точно что это мы с ТП где-то тупим -- не может быть выгрузка от 1С-Битрикс на столько убогой!

Подскажите, пожалуйста, где мы прокололись?

Можно завести в инфоблоке у товаров отдельное свойство "Поставщик" и выгружать туда значения из 1С. Затем фильтровать.

Этот формат вообще еще актуален, на него можно ориентироваться?

Смотрю полученные из 1C XML -- структура не соответствует формату.

Записей типа  <AttributeType name="Товар" dt:type="string" required="yes">
вообще нигде нет.


В каком формате сейчас генерируются XML, где можно посмотреть описание этого формата?

Написал в личку.

http://habrahabr.ru/blogs/studiobusiness/96594/

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

По посту-то видно, но учитывая контекст:
http://dev.1c-bitrix.ru/community/forums/messages/forum14/topic14608/message81451­/#message81451
...