Юлия, спасибо! Поддержка также подтвердила невозможность влиять настройками на этот "обратный порядок". Очевидно, что код проще при таком порядке, но увы здравому смыслу это противоречит. Надеюсь, кому-то пригодится, кто озадачится таким же вопросом, я аналогичного обсуждения не нашел.
Обратил внимание, что по умолчанию заказы выгружаются (и проводятся) в 1С в порядке ОБРАТНОМ порядку из оформления на сайте. То есть, например, если в 1С выгружаются в одном пакете 2 таких заказа:
Заказ №1, сделанный в 10:05 Заказ №2, сделанный в 10:10
То первым будет выгружен и проведен заказ №2, а после - №1. Это абсолютная глупость с точки зрения бизнес-логики. Заказ, сделанный раньше, должен выгружаться и проводиться первым. А не наоборот. Вопрос, сталкивался ли кто-нибудь и можно ли влиять на этот порядок настройками?
Как показывает обширный гугл-поиск, тема муссируется многие годы и трудности возникают часто. Предлагаю к рассмотрению чёткий случай проблемы.
Имеется "коробочный" УС 15.5.10, нетронутый и некастомизированный. Почта настроена через gmail с авторизацией - все работает четко: все события, которые попадают в b_event, успешны, письма достигают адресатов. А именно сообщения о новых заказах (SALE_NEW_ORDER), отменах заказов покупателями (SALE_ORDER_CANCEL), сообщения формы обратной связи (FEEDBACK_FORM).
НО никакие манипуляции с заказами, проведенные из админки, никакими почтовыми событиями не сопровождаются!!! Например, события смены статусов заказов - SALE_STATUS_CHANGED_N и аналогичные. Даже в b_event не попадают вообще, как будто ничего и не делалось. Более того, даже отмена заказа, сделанная из админки, не приводит к почтовому событию. А из личного кабинета покупателя - приводит.
Поиск показывает, что все обширно используют init.php, в котором в ручную привязываются к событиям работы над заказами, и оттуда уже инициируют отправку писем. Так как явно нигде не указано, у меня даже закралось сомнение, а должны ли дефолтные события почтовые работать. Может, они там для примера висят только, а запускать их самому предполагается через init.php. Ан, нет, должны и еще как, оказывается!
Подсказка пришла из неожиданного источника. Из мобильного приложения iOS для аминистрирования Битрикса! Стоит поменять статус заказ через него, а не админку, как все дефолтные события начинают работать: и по смене статуса заказа, и по оплате - все исправно приходит.
То есть почтовые события все эти есть и успешно работают, но в админке есть какой-то трабл, из-за которого этого не происходит.
Есть такая версия, почему так происходит:
Но это 2012 год!!! Неужели такая примитивная проблема не решена за годы? Какие мнения?
Пробовал это, разумеется, но считал, что недостаточно возможностей. Изучил плотнее, а возможностей-то, и правда, немало. Особенно здорово, что можно структуру для сайта сохранить в файл и загрузить в случае необходимости.
Еще бы немного гибкости в редактировании структуры сайта в этом модуле добавить: скажем, чтобы можно было перемещать уже созданные подгруппы не только вверх/вниз, но и между родительскими группами. Пока это делать нельзя. Скажем в группе А две подгруппы А1 и А2. Далее идет группа Б. И нужно А1 перенести из А в Б. Сейчас этого сделать нельзя. А было бы здорово!
Тема муссировалась много раз, но по-прежнему не теряет актуальности. Частенько стоит задача реализовать в интернет-магазине структуру, существенно отличную от 1С. При этом возможностей БУС, очевидно, недостаточно в большом кол-ве случаев. Поэтому хороший путь, который и рекомендуется в документации Битрикс, - это 2 инфоблока: ПЕРВЫЙ, с товарами, полностью повторяет структуру 1С, а ВТОРОЙ - содержит только необходимую структуру для сайта. Первый дополняется удобным свойством привязки к элементам второго инфоблока, что и дает далее возможность выводить элементы на сайт с желаемой структурой. Но это лишь общие слова. На деле требуется кастомизация многих компонент, чтобы все это правильно работало.
Многие конкретные шаги описаны здесь:
На примере еще старого Битрикса, но все успешно работает и на свежем. Автору респект. Аналогичным образом можно кастомизировать и компоненты bigdata, bestsellers и проч.
Но вот со smart.filter никак не удается справиться. Необходимо заставить фильтр учитывать привязку элементов к разделу ВТОРОГО инфоблока. То есть, скажем, к разделу ВТОРОГО инфоблока привязано 5 элементов ПЕРВОГО. Открываем этот раздел, и да, кастомизированный (указанным выше способом) компонент catalog.section выдает нам только эти 5 элементов - все ок. Но при этом смартфильтр показывает диапазон цен всех товаров ПЕРВОГО инфоблока, не учитывая, что мы уже выбрали раздел, к которому привязано только 5.
Если кто-то уже работал над этим, прошу поделиться рецептом.
