заказ № 311 принят". Там очень сложная ценовая политика (когда рассчитывать по мелкооптовым ценам, а когда по оптовым - в частности). Но в письме в любом случае приходит общая стоимость товаров проставляется согласно мелкооптовым ценам в любом случае, а это не правильно. Соответствующего почтового шаблона я не нашёл. А как это можно исправить? Помогите, пожалуйста.
обработчики есть?
а в заказе все правильно проставляется?
Вот так вот в корзине. Сейчас пришлю как в заказе.
В принципе не правильно считается общая стоимость товаров. Она считается от мелкооптовой цены, а надо от оптовой цены.
там срабатывает пересчет корзины. В корзине надо когда ложится проставить CUSTOM_PRICE=Y или пересчитывать корзину постоянно с помощью callback функции provider (класс можно расшарить через CatalogProductProvider) первый вариант я думаю предпочтителен. так не будет заходить в функцию каждый раз, когда корзина изменяется. Для второго варианта: грузите класс через registerAutoLoadClasses например: в init.php \Bitrix\Main\Loader::registerAutoLoadClasses( null, [ "Класс\\CatalogProductProvider" => "путь до файла, расшаривающего класс", ] ); в файле: use \Bitrix\Main\Loader; Loader::includeModule('catalog'); Loader::includeModule('sale'); class CatalogProductProvider extends \CCatalogProductProvider { public static function GetProductData($params) { //Получение готового массива цен $result = parent::GetProductData($params); делаете цену какой хотите, тут обработчики для смены цены меняете цену типа $result['PRICE'] = 1000; $result['BASE_PRICE'] = 1000; return $result; }}
А функция onMyGetOptimalPrice проставляет оптимальную цену только мелкооптовую.
потому что этот метод выбирает самую наимешьную цену, по которой может купить пользователь.
Так я её переписал: она теперь выбирает только мелкооптовую цену. А есть функция onGetTotalPrice? Или что-то этого?
при оформлении заказа цены пересчитываются с актуальными. делайте через CUSTOM_PRICE=Y или через провайдера пересчитывайте каждый раз. Тут решать вам уже.
А CUSTOM_PRICE - это что такое? Что она даёт?
Этим параметром вы говорите, чтобы сумма товара в корзине не пересчитывалась. Т.е. можете уставить свою цену в корзине с этим параметром, и она не будет пересчитываться, даже если пользователь решил сделать заказ через 1 месяц после того, как положил в корзину (и цена уже у товара другая). !!!! Будьте аккуратнее с этим параметром. Потому что пользователь может купить товар по сниженной цене.
Да, но если его установить в Y (CUSTOM_PRICE=Y), то скидки перестают считаться.
А через провайдера - Вы что имели в виду?
да. Тут уже надо хитрить. Пока я вижу только вариант пересчитывать корзину в событии перед оформлением заказа, и там уже применять скидки. Ядро d7 это позволяет сделать с минимальными запросами. https://dev.1c-bitrix.ru/api_d7/bitrix/sale/events/order_saved.php В гугл поискать, то там есть "сделать применение правил корзины с корзиной" (это купоны, правила корзины).
провадер нужен только для особых случаев. Без необходимости я бы не стал его применять. Это метод нужен, когда необходимо перечитать конкретную позицию заказа в зависимости от различных условий. Например (можно его и через правила корзины наверное): заказали 3 штуки товара, надо чтобы цена товара была не 1000 руб, а 700 руб. То ставим 700, в корзину записывается 700. И каждый раз при пересчете корзины на каждой позиции корзины будет этот пересчет.
Ну насчёт событий по этой ссылке - это по-моему то что нужно. Только Вы не подскажете какое именно событие использовать? saleOrderBeforeSavedменить общую сумму товаров.
before !!! Но будьте внимательны: Но там по разному необходимо передавать данные. У before там описано. А события OnSaleOrderSaved надо делать $order-save() - только не зацикливаейте. При $order-save() сработает событие опять OnSaleOrderSaved там есть параметр IS_NEW - по нему ориентируйтесь, если используете его.
Обсуждают сегодня