Идеи пользователя 3089

Это о модуле form версии 20.100.0.
Нет там такого варианта. Да и вообще не все варианты из HTML5 там есть.
Непорядок! Приходится глубоко вмешиваться в "мозги" БУС.

Сейчас можно в этом триггере выбрать только количество дней, на которые забыта корзина.

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

Как превысил, можно слать серию писем, побуждающую к покупке.

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

В итоге требуется два новых параметра триггера по забытым корзинам:

1. Пороговая сумма.
   
2. Превышение/не достижение порога.
   

Актуальна также здесь идея по привязке триггера к группе пользователей. Идея по использованию настроенных сегментов для регулирования исключений зря считается реализованной. Это неправда.

Бывает нужно отличить одну скидку от другой программно и не по ИД.
Много на каких объектах системы есть символьный код, но не на правиле корзины.
Предлагаю исправить это.

В силу специфики настройки расписания рано или поздно возникает ситуация, когда одновременно работает два обмена. Это приводит к потере таблицы b_xml_tree и обрушению обмена.

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

Изоляция по файлам возможна, если воспользоваться параметром USE_TEMP_DIR компоненты bitrix:catalog.import.1c.

С изоляцией по БД ситуация запутана. С одной стороны есть API:

• \CIBlockXMLFile::StartSession
  
• \CIBlockXMLFile::EndSession
  
• \CIBlockXMLFile::GetSessionRoot
  

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

В поддержке (обращение 2380113 "Поддержка паралелльных выгрузок каталога на сайт") мне сообщили:
Предлагаю переработать логику так, чтобы это было возможно. Предложение касается классического XML обмена. Но может затронуть (надеюсь, что нет) и REST обмен.

Это о компоненте bitrix:sale.basket.basket.line и $arResult['TOTAL_PRICE'].

При заказе общей суммы корзины через параметр SHOW_TOTAL_PRICE получаем в этом поле результата отформатированное значение с учетом шаблона валюты (т.е. с добавлением р., руб. и прочего в этом духе).

Если на сайте в разных местах предусмотрен разный шаблон (где "р.", где "руб.", где "рублей", а где и выкрутасов с помощью ui.fonts.ruble), то использование форматированной суммы, вычисленной в этой компоненте зачастую невозможно. Приходится врубать SHOW_TOTAL_PRICE в значение N и делать теже вычисления в result_modifier.

Было бы очень удобно ввести новый параметр компоненты USE_CURRENCY_TEMPLATE и отключать с его помощью параметр $useTemplate метода \CCurrencyLang::CurrencyFormat.

Либо обеспечить наличие в результате (что хуже), как форматированной суммы, так и неформатированной.

По мотивам обращения в поддержку 2367085 "Компонента bitrix:sale.basket.basket.line не имеет в результате неформатированной стоимости корзины"

Сейчас обязательность свойства настраивается только на уровне свойства.

Если свойство обязательно на всех привязанных методах доставки и оплаты, то все работает прекрасно. Либо свойство вообще не показывается стандартной компонентой (и не мешает созданию заказа), либо показывается и требует ввода.

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

Расстраивают два метода из main 18.1.8:

• \Bitrix\Main\Diag\Debug::dumpToFile
  
• \Bitrix\Main\Diag\Debug::writeToFile
  

Они, как ни пляши, сделают лог доступным по HTTP. Если есть доступ по ssh, то это не нужно.

В настоящее время (iblock 18.6.2, модуль обмена с сайтом версии 7) при выгрузке остатков выгружаются только склады. В этой ситуации БУС суммирует остатки по выгруженным складам и записывает их (с учетом резервирования на сайте) в остаток по продукту.

Это подходит только в том случае, когда все выгружаемые склады работаю на продажу в Инет. Это может достигаться несколькими путями. Например, если сайт принимает заказы как с доставкой до покупателя, так и с последующим выкупом в оффлайн-магазине (ну, или выдачей на складе, любом из представленных). Или когда склад реально один, а остатки по выгружаемым складам представлены "для красоты". Можно придумать что-то еще. Достаточно понимать, что эта ситуация реальна и потому довольно долго жива (с модуля обмена версии 4 точно).

Реальная жизнь заметно сложнее описанной. Бывает и так, что торговля в Инет ведется только с одного склада. А остальные - это оффлайн магазины. И для них никаких заказов не принимается. Можно онлайн торговлю вести и нескольких складов (один на доставку курьером, почтой, ТК, а другой - самовывоз в ПВЗ). Но достаточно добавить один склад, представляющий магазин, которые не торгует через Инет и все, схема, поддерживаемая БУС более не работает.

Решение здесь напрашивается. Вероятно, это было ранее возможно, но целенаправленно убито (обращение в поддержку 2281313 "При получении остатка из 1С нет возможности отказаться от суммирования остатков по всем складам" от 08.03.2019). Достаточно обеспечить корректный прием тега Количество (со стороны 1С потребуются изменения, но с такой БУС они не имеют смысла).

Что интересно, этот тег может быть обработан как в файле цен (prices), так и в файле остатков (rests). В файле цен за тегом Количество приоритет. Т.е. если он есть (даже если есть данные по складам), в количество продукта (QUANTITY) будет записан именно он. Но в файле остатков другой приоритет. Что за причина для этого непонятно. Важно то, что наличие тега Количество при наличии тегов по складам, ничем не поможет, будет использована сумма по складам.

По наивности, я думал, что это ошибка, которая будет исправлена. Но служба поддержки послала меня отправила на сайт идей.

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

Уже давно модуль pull входит в дистрибутив БУС. Но документации по нему нет. Предполагается что кому надо будут копаться в коде и разберутся. Да, это возможно. Но все равно придется делать то, что и так должно уже быть в продукте - рассылки, триггерные рассылки, уведомления сайта (о регистрации, восстановлении пароля, новом заказе, изменении его статуса и прочее).

Предлагаю включить эту возможность в продукт штатно. И не вынуждать разработчиков копаться в коде, а владельцев заниматься глупостями.

По мотивам обращения в поддержку 2254459 "Пригоден ли модуль pull для использования вне Битрикс24 для работы с рассылками и другими уведомлениями?".

С выходом sender 18.0.1 (возможно и раньше, но не ранее 17.1.4) модуль сильно перестроили.

Изменилась терминология, изменился и функционал. Пропала связь между рассылкой (ныне "кампания") и группой (ныне "сегмент"). Теперь при создании выпуска (ныне "рассылка") нужно с нуля настраивать сегменты (кто получит письмо, а кто нет). Это неоправданно увеличивает сложность создания рассылки и повышает ответственность в случае ошибки.

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

Без возвращения старого функционала в этом новом обличье работа по созданию рассылок уйдет в руки админов, т.к. они "программисты".

По мотивам обращения в поддержку 1987483 "В кампании нет преднастроенных связей (умолчаний) с сегментами"

За все эти годы ничего не изменилось. Смотрел в последний раз в components/bitrix/catalog/templates/.default/bitrix/catalog.search/.default/template.php от iblock 17.5.4.

Выполняется поиск в два шага:

1. bitrix:search.page
   
2. bitrix:catalog.section
   

Это ненормально. Причины всего-то две:

1. Техническая: странно собирать ИД-шки элементов, чтобы потом использовать их для второй выборки уже не из поискового индекса, а из инфоблока.
   
2. Функционал: пользователи давно ждут подсветки поисковых фраз в результатах поиска, но при таком подходе ее не будет в принципе.
   

То, что сейчас можно видеть в каталожном поиске - это последствия определенного разделения функционала между двумя модулями.

Давно уже пора научить Битрикс делать один запрос (поиск и фильтрация одновременно, учитывая фасетный индекс, если ищем по инфоблокам). Также давно пора (1С УТ такое умеет, к примеру) делать подсветку того, что искал пользователь. Так интуитивно проще оценивать релевантность.

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

Но бывает так, что покупатель может что-то изменить, совсем чуть-чуть, и будут добавлены другие способы доставки, которые более удобны и покупателю и продавцу. К примеру, нужно увеличить сумму заказа на 100 р. Или убрать из корзины какой-то товар (да, пока публичка на уровне компоненты не может создать две-три отдельных доставки, только так).

В общем, владелец магазина хочет "рекламировать" методы доставки, но сейчас ни компонента, ни API этого не позволяют.

\Bitrix\Sale\Delivery\Services\Manager::getRestrictedObjectsList - выдает только подходящие службы
\Bitrix\Sale\Delivery\Services\Base::isCompatible - только "да" (подходит для данной отгрузки) или нет, без комментариев

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

Добавлено: По ситуации я подал обращение в поддержку 1796491 "Как предполагалось получать данные о том, почему именно служба доставки не совместима с отгрузкой?". По нему была создана заявка в разработку 71592 "дать возможность проталкивать свое описание в компонент оформления заказа".

Чем это кончиться и когда предположить не берусь. Будет ли сделано проталкивание только из isCompatible или также будут показаны описания сработавших стандартных и пользовательских ограничений - вопрос.

Сейчас (sale 17.6.6) из каталожных настроек есть только "по категории товара" (это раздел инфоблока). Не хватает возможности указать свойство и его значение (равно, не равно, отсутствует).

Как пример - не все службы доставки принимают опасные грузы. Это можно было бы оформить в виде удобно настраиваемого ограничения. А сейчас приходится делать свою службу доставки и использовать \Bitrix\Sale\Delivery\Services\Base::isCompatible.

Сейчас (main 17.5.4) можно управлять выбором дат. Для этого нужно воспользоваться параметром callback и указать в нем функцию, возвращающую false для дат, которые выбирать нельзя.

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

Дата этой библиотекой показывается ссылкой. Вся верстка создается в BX.JCCalendar._create_layer.
Стиля bx-calendar-weekend, используемого для традиционных выходных, недостаточно, т.к. есть еще и производственный календарь, даты в прошлом.

BX.calendar используется в стандартной компоненте bitrix:main.calendar.

Моя идея расширяет опубликованную в 2015 году идею о возможности выбора диапазона дат.

Добавлено:

Задача существенно шире стилизации. Из нее органично следует вторая - возможность перестройки календаря, если условия стилизации изменились. В моей ситуации это нужно для календаря с выбором желаемой клиентом даты доставки. Условия доставки могут измениться при выборе другого адреса доставки. Простая стилизация будет недостаточна, т.к. календарь "из коробки" строится один раз за все время жизни страницы.

Сейчас (контейнерная выгрузка, sale 17.0.32 - проверял это) доставка не выгружается в XML, если ее стоимость равна нулю.
Нулевая стоимость актуальна для сайтов, где на самом сайте покупатель просто указывает способ доставки (и он должен дойти до 1С), а стоимость считается не автоматически, а утверждается в ходе подтверждения заказа с менеджером по телефону.
Для того, чтобы обойти проблему, приходится ставить на сайте ненулевую стоимость и вводить покупателя в заблуждение (0 таких проблем не создает).

В модуле версии 17.5.2 есть следующие настройки:

• Выходные дни недели,
  
• рабочие дни года,
  
• выходные дни года.
  

Эти настройки используются внутри модуля в процедурах вывода календаря. Отдельного API для проверки не является ли определенный день выходным/праздничным даже в текущем году нет.

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

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