Задача создавать номенклатуру как на сайте Озон. А именно выбирать Тип в зависимости от выбранной Категории.
Я так понимаю это только через доработку...

Номенклатура будет создаваться в 1С, и потом выгружаться в Озон. Как решали данную задачу?

Собрать данные с Озон, создать номенклатуру, использовать в дальнейшем.

(1) как раз занимаюсь автоматизацией по маркетплейсам для клиента.
так и делали, собрали "фиды" по МП и с них грузили в базу 1С. Автосоздание карточек МП из базы 1С сразу в ЛК МП - не планируется, тут приедтся ручками "параллельно" делать пока что, благо ассортимент дополняется нечасто.

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

(2) Зачем ручками, например в Озон же есть расширение для работы с ним?

(4) + бесплатное )

Загрузить данные с фидов МП в базу - та еще задачка. Потому как если заранее в базе нет "ключаа связи" для загрузки данных из фидов - то все что  остается - сопоставлять ВРУЧНУЮ по наименованиям из МП с наименованиями в базе. При этом эти наимеенования в базе и в МП - вообще могут быть похожи отдаленно...

(4) "мы не умаляем ваших возможностей..."

(6) да, если уже велся паралллельный учет в 1С, и отдельно в Озон
а если 1С еще пустая, это упрощает

в моем случае для загрузки из фидов программистом была написана загрузка, облегченная с тем, что часть "ключей связи" в базе уже присутствовала - это и ШК для МП, и артикулы поставшщика и артикулы МП. Большая часть данных успешно подцепилась, но пришлось все равно каждую строчку выверять... а с учетом того что
- одна складская номенклатура может присутствовать (условно, на самых распространенных МП) от имени разных наших фирм
- под разными брендами, причем как и то что один и тот же бренд м.б. на разных МП, так и для каждого МП может быть свой бренд, причем даже от имени однйо фирмы на одном МП один и тот же товар может быть под несколктими отдельными карточками МП
.
то на одну складскую карточку может быть до 15 карточек МП...
.
при этом надо разруливать выставление складских остатков на каждую карточку МП и не допускать ситуации что заказ клиента может быть неотгружен - то все становится весьма неочевидным...

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

сейчас вот в базе картчока товара для МП состоит из ~25 реквизитов

(10) :0 жесть

(11) 25 обычных, или через доп реквизиты делали?

(12) а ты думал - пришел, увидел и пздц! ;-)

(13) это все для УТ11.4
понятно. что это не в самой Спр.Номенклатура.
запилили отдельный справочник НоменклатураМП, в котором через (условно) НоменклатураМП.Номенклатура - связь с спр.Номенклатура.
.
по идее это все можно привязать наверное типа в НоменклатураПокупателей (что-то ведь подобное в Ут11.4 есть), почему в отдельный справочник запилили - хз, не помню чем это было вызвано.
.
По идее - если припрет и правильнее перетащить будет в Спр.номенклатураПокупателей - то это достаточно просто будет сделать... понадобится это или нет - хз... Клиент только торговлей с МП занимается, и сколько это направление деятельности будет жить - хз...
.
там у меня основная фишка - авторасчет остатков на каждую карточкуМП