Если честно не помню, это было 3 года назад..
Точно помню, что были проблемы с каким-то из видов данных и что победил корзиной Simple и X-Shipping Pro. Вроде как адрес доставки грузились в 1С в контрагента, а вид оплаты и перевозчик нет. По итогу настроил корзину и виды доставки/оплаты на сайте, чтоб исходить из того что мне нужно, а не что может модуль или 1С)
Затем отлавливали через конфигуратор в 1С, грузили заказ и смотрели, что передается в заказе и как это видит 1С, и это сопоставляли с полями в 1С в модуле Битрикса. Параллельно дорабатывали в 1С фиксацию источников заказа и подобные плюшки.. У меня так сложилось, что проггеры на стороне 1С сильные и оперативные, и мне на тот момент было проще с ними на стороне 1С реализовать что нужно принимать от сайта, чем на стороне сайта исправлять что и как выгружать в 1С)) При том не отходя от типовых решений 1С, чтоб не городить огород..
Это уже потом дорабатывал, где-то год назад подключил api для создания ТТН в 1С, изначально просто с сайта грузились адрес доставки, вид перевозчика и виды оплаты + комментарий к заказу..
Глобальный вопрос, постараюсь объяснить) На протяжении нескольких лет тестировал разные варианты резервирования.
Изначально был резерв при загрузке заказа в 1С с момента создания, затем только при проведении заказа, затем при создании документа РТиУ, затем вообще без резерва)
В результате пришел к выводу, что зависит от группы товара (есть ли замена в случае не хватки и дорогой ли товар), обьема входящих заказов, оперативности и логики их обработки.
Суммы недопродажи, по причине отсутствия товара на остатке из-за резерва, были выше, чем сумма отказов по причине не резерва (примерно пять новых заказов к одному отмененному в моем случае).
Когда убрал резервирование всех входящих заказов, то продажи увеличились, а нехватку товара решил путем оперативной закупки под заказ клиента и оптимизацией формирования товарных остатков.
Сейчас товар автоматически резервируется только на обработанные заказы в момент создания РТиУ и списывается из резерва в момент перевода РТиУ в статусы последующие за статусом Комплектации. Т.е. списываются из резерва когда товар укомплектовали физически (взяли с полки). До этого момента товар числится в резерве и мы знаем сколько товара по факту и сколько "почти продано", т.к. в случае предоплаты товар не отгружается без денег и должен быть в резерве, плюс есть еще очередь комплектации. Что по итогу дает возможность переучитывать товар на полке в реальном времени не останавливая комплектацию и отгрузки.
Документ заказа покупателя, по сути, это намерение клиента купить, но не покупка, и есть вероятность, что заказ будет отменен.
Документ РТиУ (реализация товаров и услуг) это уже непосредственно документ продажи, при его проведении задействуются остатки и взаиморасчеты с контрагентом, т.е. товар списывается с остатка под документ продажи и у контрагента образуется долг.