Для более менее прозрачного учета не хватает номера накладной в документе на приход товара.

Для одних товарищей у которых оказалось полно почти  одинаковых служб доставки пришлось изобрести такой вот велосайпод -




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

P.S. А вот за вкладочку в доставках "связанные платёжные системы" битриксам баальшое человеческое спасибо! (а то бы и это пришлось самому втыкать).

Добавить возможность фильтрации списка заказов по скидке в виде списка всех активных скидок с множественным выбором.

У поля "Купон на скидку каталога" в фильтре заказов добавить возможность использования запросов.

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

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

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

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

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

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

Сделать в базовых настройках возможность для товаров с остатком "0" ( нет в наличии )

• не выводить в каталоге
  
• выводить после товаров в наличии т.е сортировка по наличию
  

базовые вещи в любом магазине, которые приходится доделывать

Когда будут приведены в порядок типовые решения, без слез смотреть невозможно
например типовое решение интернет магазин  и информационный портал решения сделанные на отвали вот пример более или менее стандартного магазина, которое уже можно купить как готовое решение http://demo.bexx.ru/
Такое впечатление, что в погоне за модернизацией корпортала совсем забыли о смертных.
С развитием интерфейсной части операционных систем и пользовательского ПО на битрикс начинаешь смотреть как на устаревающую систему. Нет новизны особенно в давно существующих модулях, типа допиливайте сами.
Начинайте работать над усавершенствованием уже имеющихся модулей, а не только добавлением новых выдавая их за сенсацию, ПР и не более.
Система хорошая, но требуется конкретная обработка напильником при помощи программистов.

На данный момент такой компонент только один - выводит состояние текущих счетов пользователя в интернет-магазине.

 Неплохо бы было иметь в штатной поставке продукта такие компоненты, как:
- перевод средств с одного счета в другой (например, когда у пользователя есть несколько счетов в разной валюте)
- История транзакций по личному счету (в личном кабинете пользователя, рядом с историей заказов)

Не хватает метода CSaleLocationGroup::AddLocation2Group. Есть CSaleLocationGroup::Update, но он обновляет группу, оперируя всеми привязками. Поэтому надо надо сначала получить все привязки, добавить одну новую, и обновить весь массив местоположений группы. Предлагаемый метод просто привяжет местоположение к группе.

Не хватает стандартного способа сделать зависимость автоматизированных способов доставки от местоположения или группы местоположений (по аналогии с настраиваемыми). Например, для Москвы не показывать автоматизированную доставку почтой России.

Внедряли в одном интернет-магазине подписку на изменение цен, увеличило продажи на 5%.
Суть работы: в карточке товара есть кнопка "Подписаться на изменение цены". Посетитель вводит свой E-Mail, тем самым подписывается на изменение. Без дополнительного подтверждения и прочих осложняющих вещей.

Через 3 дня на указанный адрес приходит сообщение, о том что цена на товар упала на 5%, и предложение действует только сегодня (можно 2 дня, но тогда будет не так эффективно). В письме указывается новая и старая цена.

Посетитель переходит по ссылке на сайте, там цена уже с учетом скидки (меняется автоматически), если есть 1 подписка на изменение цены.

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