Здарова, я работаю программистом 1С уже 1.5 года. В свободное время постоянно подрабатываю на разные компании которые находят меня через знакомых или знакомых знакомых. В основном задачи касаются автоматизации продаж на маркетплейсах, я решил поделиться своим опытом разработки интеграций с 0. Конечно, есть люди которые считают это бесполезным делом, дескать есть интеграционные модули на Инфостарте или всякие синхрозоны/модули от яндекса, однако все это рассчитано на типовые конфигурации в которых учет затронут минимально и компании частенько ищут кто бы смог сделать плотную автоматизацию документооборота по маркетплейсам. Итак поехали:

1. Самое главное при разработке интеграции это погрузиться в бизнес - процессы компании, обсудить как будет вестись обмен между маркетплейсом и 1с (какие документы когда формируются, триггеры на отправку запросов на сборку товара, остатка, цен). В классическом варианте модель всегда сходится к одному - формирование расходной накладной с типом передача на комиссию с последующим обновлением остатка на маркетплейс, затем в конце месяца формирование отчета комиссионера для отражения в учете продажи переданных комиссионеру товаров.(Модель актуальная как для ФБС так и для ФБО)

2. Разработка интеграции обязательно должна включать в себя - синхронизацию номенклатуры (сопоставление по общим полям товаров с Маркета с номенклатурой из 1с). Обычно делаю такие вещи в отдельном регистре сведений, внимательно нужно отнестись к набору измерений - обычно у меня это ID номенклатуры прилетающий из маркета.

3. Отправка цен и остатков - ну тут более менее понятно, по остаткам должно быть либо регламентное задание либо набор триггеров для отправки запроса. У нескольких клиентов решил ради интереса в подписке на событие после проведения каждого документа который делает движения на остатках отправлять новый остаток по товарам из табличной части для минимализации рассинхрона остатков 1с и маркетплейса (если система слишком высоконагружена и формирует много документов то лучше отказаться от это затеи в пользу рег задания). С ценами обычно так: у разных клиентов свои хотелки по просчету цен для отправки на сайт, а зачастую уже готовые алгоритмы которые они хотят встроить в 1с. Можно завести отдельный тип цены для маркета и программно формировать установку цен номенклатуры с таким типом цен. Частота формирования определяется клиентом - либо по кнопке либо рег задание, также и сама отправка цен на маркетплейс.

4. Обмен заказами - большинство решений продающихся на рынке обычно обладают возможностями только захватывать заказы и создавать по 1 документику на заказ. Особо упоротые делают отдельные АРМ в которых заставляют бедных пользователей связывать заказ из регистра с документом в 1с вручную. Делаю всегда просто - по согласованию с клиентом - либо все отправления в 1 заказе документе на определенную дату отгрузки (если это маркет который возвращает в одном из JSON даты сборки или доставки товара), либо по 1 заказу документу на 1 отправление. Далее с этого момента начинается более-менее интересное. Каждая компания ведет учет заказов в 1с по-своему. Самое часто встречающееся что я обычно делаю это моментальное резервирование товара (либо в заказе покупателя либо создаю документ резервирования). А в момент реализации товара (расходная накладная или расходный ордер на товары или даже кнопка печати стикера) происходит подтверждение сборки заказа на маркетплейсе и (если надо) формирование стикеров которые я прикрепляю к заказу либо в регистре либо в документе ( можно и не прикреплять а просто сделать кнопку на отправку запроса по получению стикера)

5. Каждый заказ покупателя я помечаю номером отправления чтобы в случае партионного учета можно было четко связать партию с позицией в отчете комиссионера.

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

Вот собственно и весь цикл построения архитектуры интеграции с маркетом на 1ске.