Для одних товарищей у которых оказалось полно почти одинаковых служб доставки пришлось изобрести такой вот велосайпод -
А как было бы прекрасно просто открыть список служб доставки, убедиться что такая контекстная менюшка в админке уже прописана и послать их с этой задачей (добавлять службы доставки пачками).
P.S. А вот за вкладочку в доставках "связанные платёжные системы" битриксам баальшое человеческое спасибо! (а то бы и это пришлось самому втыкать).
Например если доставка почтой наложенным платежём я должен иметь возможность отметить например в множественном селекте что "Наличные курьеру" покупателю не предлагать. Ещё примеры?
"Самовывоз со склада в Москве" - "наличные курьеру" почтой (как угодно) - "наличные курьеру" электронная доставка - "наличные курьеру", "сбербанк итп" "бесплатная доставка для предварительного тестирования (ну или как то так)" - "оплата вебманями идр мгновенные методы".
Соответствующие компоненты (sale.order.full итп) будет несложно подогнать под данные настройки даже на уровне шаблонов.
Почему лучше сделать поле несовместимых сособов оплаты в службах доставки а не наоборот несовместимых способов доставки в платёжных системах - потому что способов доставки в зависимости от веса размера стоимости итп можно наплодить миллион и они постоянно тусуются, а способы оплаты более менее стабильны. Значит меньше телодвижений при добавлении очередного способа доставки. А лучше если это поле будет правиться и из карточки службы доставки и из карточки системы оплаты.
Почему лучше явным образом указывать НЕсовместимые способы оплаты, а не с совместимые - чисто для удобства и наглядности. имхо гораздо сильнее бросаются в глаза вещи несочетающиеся чем гармоничные (эффект красной тряпки). кроме того несовместимых вариантов теоретически должно быть меньше. Хотя с другой стороны если в компоненте прописать что надо использовать ТОЛЬКО совместимые то меньше вероятность что покупатель воспользуется некой новой платёжной системой для которой забыли прописать несовместимые способы доставки.
Зачем вообще вся эта хрень нужна - затем что если вы не дадите юзеру при заказе воспользоваться каким нибудь способом оплаты юзер просто обломится и ничего страшного не случится, а вот если вы дадите юзеру воспользоваться несовместимым способом оплаты (особенно электронные платежи и особенно(!!!) кредитки) - то тогда больше обломитесь вы потому что рефунды штука неприятная обоим сторонам.
Когда будут приведены в порядок типовые решения, без слез смотреть невозможно например типовое решение интернет магазин и информационный портал решения сделанные на отвали вот пример более или менее стандартного магазина, которое уже можно купить как готовое решение http://demo.bexx.ru/ Такое впечатление, что в погоне за модернизацией корпортала совсем забыли о смертных. С развитием интерфейсной части операционных систем и пользовательского ПО на битрикс начинаешь смотреть как на устаревающую систему. Нет новизны особенно в давно существующих модулях, типа допиливайте сами. Начинайте работать над усавершенствованием уже имеющихся модулей, а не только добавлением новых выдавая их за сенсацию, ПР и не более. Система хорошая, но требуется конкретная обработка напильником при помощи программистов.
На данный момент такой компонент только один - выводит состояние текущих счетов пользователя в интернет-магазине.
Неплохо бы было иметь в штатной поставке продукта такие компоненты, как: - перевод средств с одного счета в другой (например, когда у пользователя есть несколько счетов в разной валюте) - История транзакций по личному счету (в личном кабинете пользователя, рядом с историей заказов)
Не хватает метода CSaleLocationGroup::AddLocation2Group. Есть CSaleLocationGroup::Update, но он обновляет группу, оперируя всеми привязками. Поэтому надо надо сначала получить все привязки, добавить одну новую, и обновить весь массив местоположений группы. Предлагаемый метод просто привяжет местоположение к группе.
Не хватает стандартного способа сделать зависимость автоматизированных способов доставки от местоположения или группы местоположений (по аналогии с настраиваемыми). Например, для Москвы не показывать автоматизированную доставку почтой России.
Внедряли в одном интернет-магазине подписку на изменение цен, увеличило продажи на 5%. Суть работы: в карточке товара есть кнопка "Подписаться на изменение цены". Посетитель вводит свой E-Mail, тем самым подписывается на изменение. Без дополнительного подтверждения и прочих осложняющих вещей.
Через 3 дня на указанный адрес приходит сообщение, о том что цена на товар упала на 5%, и предложение действует только сегодня (можно 2 дня, но тогда будет не так эффективно). В письме указывается новая и старая цена.
Посетитель переходит по ссылке на сайте, там цена уже с учетом скидки (меняется автоматически), если есть 1 подписка на изменение цены.
Тут описан довольно сложный алгоритм, и скорее это идея для модуля в Marketplace, нежели для основного функционала, но было бы отлично.