Just Ahmed (Все сообщения пользователя)

Да, это решение написано для трёх блоков: bx-soa-auth|bx-soa-properties|bx-soa-basket. Обратите внимание на переопределённый метод editOrder. Может быть, если добавить нужные блоки, то получится и с оплатой и доставкой? Если получится, дайте знать, пожалуйста. Если нет, то тоже отпишитесь, я попробую.

Можно воспользоваться этой статьёй
https://www.olegpro.ru/post/1c_bitriks_kastomizaciya_novogo_shablona_komponenta_­saleorderajax.html

Дельную вещь советуют. Даже при следовании методологии разработки по "академическому" Битриксу, т.е. все автономные части через компоненты, то VueJS подходит как нельзя кстати со своей компонентной моделью. Хотя если дело доходит до смены настроений на frontend, то может к лучшему будет сменить и backend    

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

Это не риторический.

А что насчёт документации d7 интернет-магазина?
Мне понравились тенденции, например, в направлении описания создания собственных обработчиков доставки, платёжных систем, ограничений. Здесь приводится как пример встроенный обработчик службы СПСР. Там уже есть комментарии в коде в стиле phpDocumentor. Это хороший знак. И есть даже некоторый задел для документации. Но этого мало. Там не описывается механизм работы Bitrix\Sale\Delivery\Services\Manager, который вызывает кастомные обработчики. Нет описания основных наследуемых методов. И даже в имеющемся курсе, куда была приведена ссылка выше, описание было дано в разделе "Примеры". Нет описания профилей (isProfile()) службы доставки и для чего это. Не сказано, что такое совместимость (isCompatible()). Как можно использовать ExtraServices, если о них ни слова не сказано?

Конечно, пример есть. Обработчик СПСР. И есть имена методов, переменных. Но это не документация для комфортной разработки. Документация - это когда не тратишь на попытки понять, как же использовать инструмент, несколько суток.

P.S. Отсутствие документации - очень негативно сказывается на репутации фреймворка. Когда Тейлора Отуэлла, разработчика Laravel, спросили: «Стоило ли так много времени тратить на документирование?», он ответил, что лучше задержит релиз Laravel 5.1, чем выпустит его с плохой документацией.

Добрый день. Страшно слышать от руководителя отдела документации про отсутствие документации и неизвестные сроки.

Действительно.

"Это не баг, это фича" (С) Советы по эффективному маркетингу.

Версия 17.5.4 "main" и 17.0.32 "sale".

В дефолтном компоненте sale.order.ajax есть вот такая настройка. Для тех, кто не открывает левые ссылки при чтении основной статьи: настройка "Когда рассчитывать доставки с внешними системами расчёта". Настройка имеет селект-поле выбора с 3 вариантами выбора:

• Не рассчитывать (вариант "угадай сам")
  
• Учитывать настройки доставки
  
• Рассчитывать сразу
  

Вторая опция (Учитывать настройки доставки) работает с обработчиками доставок, сконструированными с применением высокотехнологичных методов d7. Это значит, что обработчик должен быть унаследован от базового класса Bitrix\Sale\Delivery\Services\Base и быть в пространстве имён Sale\Handlers\Delivery. Подробности в курсе. Больше подробностей в классной статье.

Модуль же ipol.sdek, который на скриншоте у Алексея, написан в соответствии с Ветхим Заветом старым положением вещей и ядра. Без использования неймспейсов вообще, что можно посмотреть в include.php модуля.

В новом варианте описания обработчиков есть метод isCalculatePriceImmediately():bool, который как раз и используется при отмеченной опции "Учитывать настройки доставки".

Ещё подробности для новой системы:
1) Если рассчитываемая внешними сервисами доставка стоит первой в списке, то в самом начале метод рассчёта (calculateConcrete()) будет вызван трижды: при initDelivery(), для recalculatePayment() и из calculateDeliveries(). Поэтому в дополнительных рекомендациях к курсу и есть непрозрачно-однозначный намёк на организацию кэширования. Также это повод переместить нерассчитываемые внешне службы, вроде самовывоза и статического рассчёта, в списке в самый верх.

2) Помимо написания непосредственно обработчика доставки можно написать к нему профили и дополнительные услуги. Как пример - СПСР. Комментариев в коде кот наплакал, но они уже есть!

3) Метод проверки совместимости isCompatible() вызывается до calculateConcrete(), что логично. Но если, например, нужно рассчитывать совместимость, исходя из полей ответа внешнего сервиса, то всегда можно вызвать в переопределяемом методе тот, что нужен. В некоторых случаях этим можно даже заменить ограничения служб доставки, связанные с внешними факторами.

Если есть возможность и время, то возможно Вам поможет кэширование.

Рад, что вам потребовалось времени всего день, чтобы найти это решение  

Да у вас там уже статистика по багу собрана, я погляжу.

Нужно смотреть применяемые условия и алгоритм их применения. В нашем случае задача была решена аналитически. Потому как скидок немного, следовательно меньше переменных в задаче.

Нашёл фичу в скидках.

Исходные данные:
0) Заказчик, пожелавший скидку, допустим в 20%
1) Условие скидки - стоимость заказа не меньше 1000 у.е.
2) Товар, к примеру бутылка пива, стоимостью 1150 у.е.

Есть полтора сценария:
0) Общая стоимость товаров
1) Общая исходная стоимость товаров

Это те условия, по которым должна применяться скидка в корзине. В корзине скидка применяется по обоим. Но!

Сценарий первый:
0) В корзину падает бутылка пива стоимостью 1150 у.е.->
1) Корзина применяет скидку 20%->
2) Общая стоимость товаров становится (1150 у.е. вычесть 20%) = 920 у.е.->
3) А это уже меньше нужной по условию 1000 у.е.

Сценарий номер полтора:
Ну тут всё просто. Тупо подходим, берём бутылку пива и уходим. Общая исходная стоимость товаров - без скидок и наценок. То есть при применении правила этот параметр статичен.

Сама фича:
В первом сценарии при оформлении заказа скидка ещё видна. А вот в админке,а следовательно и в 1С улетает, заказ без намёка на скидку.
Есть подозрение, что правила проверяются минимум дважды.

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

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

Есть такая профессия - в компонентах Битрикса ковыряться...

В обучающих курсах есть про функционал подарков.

Там среди компонентов, где можно настроить и вывести подарки, числится sale.gift.basket. То есть непосредственно подарок к товарам в корзине. Он же вызывается в sale.basket.basket в шаблоне.

Но! Просто визуально его добавить, потыкать настройки компонента, жмакнуть "Сохранить" маловато будет. Маловато! Видимо компонент не одним пальцем деланный. А может и вовсе не пальцем.

Для работы компоненту нужны параметры "APPLIED_DISCOUNT_LIST" и "FULL_DISCOUNT_LIST". В шаблоне компонента sale.basket.basket эти параметры инициализируются из $arResult. А вот при вызове sale.gift.basket из визуального редактора таких переменных нет. Зато можно выбрать SHOW_FROM_SECTION и поиграть с огнём настройками раздела вывода.

В моём случае был кастомизированный красивый шаблон корзины, который трогать запретили. Компонент подарков был вызван под красивой корзиной. А в class.php компонента sale.gift.basket, благоразумно заранее перенесённого в свою папку разработчика, был усовершенствован метод onPrepareComponentParams.
Усовершенствован вызовом
А чтобы этот вызов сработал, в сааамом верху, где располагаются всякие инструкции вроде use, но пониже проверки B_PROLOG_INCLUDED, вызывается
Очень полезная конструкция, за что большой респект разработчикам, иначе пришлось бы метод getBasketItems() копировать себе вручную, а это два лишних нажатия на сочетания Ctrl+C и Ctrl+V и дублирование кода, а это фу.

Метод getBasketItems() вызывается без параметров и возвращает массив. В числе элементов которого есть заветные "APPLIED_DISCOUNT_LIST" и "FULL_DISCOUNT_LIST".

И ещё. Не кормите яо-гаев! В классе CSaleGiftBasketComponent, который является основой компонента sale.gift.basket, есть метод buildIblockDependedParameters(). О проблеме с методом я плакался здесь.

Ладно, не буду томить себя ожиданием ответа. Предложу себе такое решение:

В методе buildIblockDependedParameters() инструкцию
заменить наХотя дальше по ходу компонента значение элемента массива(Y) не важно, важен только индекс.

Вопрос к разработчикам: нативный компонент работает правильно? Может чего-то не увидел при настройке. Нужно было подарки из другого инфоблока подавать.

Компонент sale.gift.basket классовый.
Есть "документация".
В "документации" параметр SHOW_PRODUCTS_<ID_каталога>.
В методе CSaleGiftBasketComponent::onPrepareComponentParams() этот параметр разбивается вызовом родительского метода в массив $arParams["SHOW_PRODUCTS"].

Если указывается, к примеру, параметр SHOW_PRODUCTS_13 = 'Y', это означает, что подарки нужно будет извлекать из инфоблока с ID 13. Параметров SHOW_PRODUCTS_<ID_каталога> может быть несколько.

Зачем в методе buildIblockDependedParameters() переопределяется $this->arParams['SHOW_PRODUCTS']? Притом в параметре остаётся только один идентификатор инфоблока.

А, так вот в чём проблема...
Всё, теперь я понял, где дорабатывать нужно.
Не подскажите, как в типовом обмене реализована функция поиска товара? Через GUID?

Был случай, когда клиенту нужно было выводить из одного инфоблока товары с похожим составом. Выводились через доработанный catalog.top.
Назвали это аналогами. Эти товары лежали рядом со своими аналогами в каталогах.

Есть и такой метод.
На сайте, где-нибудь в каталоге /upload, создаёте свой каталог, например, 1c_files. Туда по FTP помещаете результат выгрузки(xml и папка с картинками). Лучше с предварительной архивацией. На месте деархивируете. Затем переходите в панели управления БУС Контент\Инфоблоки\Импорт\XML. В поле "Файл для загрузки" ваш .xml.

Если всё же проблема не в скорости соединения сервера 1С с хостинг-сервером БУС, прироста в скорости точно не будет.

У вас при загрузке картинок не стоит какая-либо своя предобработка?

Может вам больше подойдут торговые предложения?

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

И всё же, такую схему реализовать можно? Про какие остатки речь - в программе или на сайте?

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

Александр, это решение для сценария с интеграцией с 1С? (Ссылка)