Пересчет цены сейчас происходит в двух трех случаях (из тех, что понятны посетителю):

• Добавление товара в корзину.
• Открытие страницы корзины (bitrix:sale.basket.basket)
• Открытие страницы заказа (bitrix:sale.order.ajax)
  

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

Примеры:

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

В обоих случаях требуется ИД самой позиции и знание ИД товара здесь точно недостаточно, требуется контекст (конкретная позиция корзины).

Что сейчас есть

• CSaleBasket::UpdateBasketPrices. Метод используется в коде компоненты для обновления цены.
• Аналогичный метод CSaleBasket::ReReadPrice делает тоже самое для одного товара, и тоже без сведений о позиции корзины (он используется пока только при добавлении в корзину, так что может и не страшно).
• Так или иначе, все сводится к вызову провайдера каталога CCatalogProductProvider::GetProductData. Этот метод провайдера в состоянии получить BASKET_ID, но его туда не передают (это недоразумение обещано исправить).
• Уже сам провайдер вызывает метод CCatalogProduct::GetOptimalPrice и здесь информация о позиции корзины теряется (и разработчик отказался это исправлять).
• Само собой обработчику события OnGetOptimalPrice не может быть передана информация о позиции корзины
• Нормально пересчитать цену товара, уже добавленному в корзину, нельзя.
  

Какие есть костыли

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

Но зачем так делать, если можно сделать нормальный API?

Идея рождена по предложению сотрудника поддержки (обращение 500340).

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

На своих сайтах мы вынуждены извращаться с событиями, чтобы email был необязательным.

Сделайте, чтобы логин генерировался из произвольного свойства заказа, например из телефона пользователя или ФИО.

Есть такой полезный функционал в модуле Интернет-магазин: на почту покупателя с определенной периодичностью высылаются напоминалки, что заказ надо оплатить.

Только вот неувязка: если пользователь выбрал оплату наличными, то ему все равно приходят напоминания, хотя заказ еще не доставлен. О_о как так?

Добавьте, пожалуйста, исключения - способы оплаты, по которым не надо напоминать.

Спасибо

Например если доставка почтой наложенным платежём я должен иметь возможность отметить например в множественном селекте что "Наличные курьеру" покупателю не предлагать. Ещё примеры?

"Самовывоз со склада в Москве" - "наличные курьеру"
почтой (как угодно) - "наличные курьеру"
электронная доставка  - "наличные курьеру", "сбербанк итп"
"бесплатная доставка для предварительного тестирования (ну или как то так)"  - "оплата вебманями идр мгновенные методы".

Соответствующие компоненты (sale.order.full итп) будет несложно подогнать под данные настройки даже на уровне шаблонов.

Почему лучше сделать поле несовместимых сособов оплаты в службах доставки а не наоборот несовместимых способов доставки в платёжных системах - потому что способов доставки в зависимости от веса размера стоимости итп можно наплодить миллион и они постоянно тусуются, а способы оплаты более менее стабильны. Значит меньше телодвижений при добавлении очередного способа доставки.
А лучше если это поле будет правиться и  из карточки службы доставки и из карточки системы оплаты.

Почему лучше явным образом указывать НЕсовместимые способы оплаты, а не с совместимые - чисто для удобства и наглядности. имхо гораздо сильнее бросаются в глаза вещи несочетающиеся чем гармоничные (эффект красной тряпки). кроме того несовместимых  вариантов теоретически должно быть меньше.
Хотя с другой стороны если в компоненте прописать что надо использовать ТОЛЬКО совместимые то меньше вероятность что покупатель воспользуется некой новой платёжной системой для которой забыли прописать несовместимые способы доставки.

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

Не помешала бы возможность добавления функционала по сабжу. Спасибо.

Доброго всем времени суток.
У меня есть предложение, которое, надеюсь, поддержит большинство:)

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

Поизучал форумы и пришел к выводу, что такое нужно многим....

По скидкам есть вариант использования групп пользователей. Но, согласитесь, что заводить 100 групп пользователей - это, по крайней мере, глупо.

Вот тут достаточно хорошо описывается механизм данного процесса, но это приводит к большому количеству переписываний в коде. Так почему бы не завести в модуле sale специальный параметр для таких случаев и в заказ не передавать индивидуальную скидку пользователя?

Не хватает истории заказа, кто и когда менял статус, добавлял позиции и т.д., не всегда ясно с кого спросить.

Страна у нас большая и время в разных городах отличается порой очень существенно. Поэтому хорошо бы сделать так, чтобы сразу было видно сколько сейчас времени в том городе откуда сделан заказ и какая разница во времени. Можно ли сейчас звонить клиенту в этот город или нет.
А то ведь придет неопытный ретивый менеджер интернет-магазина во Владивостоке на работу и ну обзванивать клиентов по всей России - доброе утро страна!

То же самое на странице со списком заказов

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

В битриксе реализованы скидочные купоны на товары/группы товаров. Но достаточно часто требуется осуществление купона на заказ. А скидка на заказ бывает только от стоимости заказа.