На данный момент торговля осуществляется бытовой химией, ООО УСН на 15%, есть склад – там в основном оптовая  торговля, собираемся торговать на маркетплейсах, в связи с чем мнения разделились, что лучше выбрать для торговли на: Wildberries, , Озон, Яндекс и где уже интеграция лучше настроена с маркетплейсами, так как оптовую торговлю, (в будущем планируется  рабочее место кассира, с подключением ККТ, сканером штрих кода, эквайрингом), а вот где лучше интеграция реализована - в УТ или УНФ, что бы можно было так сказать с коробки без доделок (хотя бы на начальном этапе) нормально настроить и осуществлять обмен с маркетплейсами?

Сравнить чего нет в УНФ и чего нет в УТ, но есть в УНФ.
Вычеркнуть то, что не будет использоваться в учете при УСН.
Принять решение оптимально из отавшихся функций.
Рисовать есстественно табличку.

вроде кто плотно с маркетплейсами или сами дорабатывают или юзают расширения маркетплейсов или сторонние.

вилдбери с озоном дают АПИ с методами: Продажи, Комиссия, Доставка, Остатки, каталоги товаров и что там еще...
как это обрабатывать и где - тут конечно же от потребностей зависит.
Что бы выявить потребности - (1).

сейчас у клиента в УТ как раз внедряем от стороннего разработчика модуль интеграции с маркетплейсами. В целом мне более-менее. Очень близко к тому как я себе представлял.

(4) модули вроде под все конфы есть, знакомый в УНФ с модулем  внешним на все маркетплейсы сидит

У нас ут

(0) УТ 10.3 (best configuration ever)

Нет производства, оказания услуг и организация не ИП на УСН (можно обойтись без БП) - зачем УНФ?
По интеграции с маркетплейсами на уровне 1С - абсолютно одинакова, сторонние программы - однозначно сначала сделают для УТ, потом руки дойдут и до УНФ
Осваивать проще УНФ, причем значительно проще (что не исключает, читать и учить), но по функциональности именно торговли,УТ значительно превосходит

(8) УТ функционально перегружена,
если даже только торговля без производства и услуг, то УНФ во многих случаях удобнее, чем УТ,
но если заглядывать в код, то складывается впечатление, что разработчики УНФ сами не читали рекомендаций фирмы 1С для партнеров по разработке партнерских решений

(9) Так настрой по простому

открой функциональные опции, поотключай лишние галки

(11) и чем это поможет? Ну кроме того что половина нужного из того что останется перестанет работать

В УНФ есть свои заморочки (по которым видно что корни ее растут оттуда, где про торговлю вообще мало что понимали). Например, нет никакого вменяемого механизма закрыть заявку покупателя кроме как реализацией. Если не делать реализацию - единственный вариант - статус завершения с отменой и прощай все записи по регистрам... Если по заявке отгрузить частично реализацию - остаток заявки так и останется висеть даже если поставить заявке статус "завершена успешно" (разрабы обещали подумать над закрытием заявки в таком случае - но сделали это - думаю вряд ли пока...). Отчет "анализ заказа" (или состояние заказа, точно не помню) - показыает не полное состояние заказа, а состояние того что упомянуто в ТЧ заказа (могли уже починить, траблов в форум в свое время накидал достаточно, но приоритеты они раставляют сами и хз...). и еще всякого... Отсутствует единый подход у сложившимся "стандартам" - например, в карточке товара разные типы цен - отражались не единым образом, а типа
100
200.3
147.57
- на мое замечание что так никто не делает ибо бредятина реально - в табличных частях например в документах вы же всегда указываете с 2 знака после зпт - чуть ли не открытм слогом послали на..уй, настолько это было "выскомерно" - типа это вы тут один такой, всем остальным все заипись... правда через года полтора - отрисовали "как надо".. Каждое обновление обработки загрузки из внешних источников - ждешь как появление дебила с гранатой... Ну итд. Вроде все совсем некритичное, но  "бесит, бесит, бесит!" ;-)

При этом в УНФ - достаточно много приятственного/удобного для оптовой торговли. Про розницу - не скажу, ибо не сталкивался.

в УНФ например, неудобно с корректировками реализаций. НЕ, сделано все "корректно" формально, по факту - неудобно.
.
Заявка(=100)-Реализация(=100)-КорректировкаРеализации(=90)-Оплачено(=90). Заявка будет висеть как отгруженная неполностью, опалченная неполностью. И с каждой такой заявкой надо "разбираться персонально", т.е. нет в возможности указать в корректировке некий "вариант корректировки", например, чтобы в описанном выше случае заявка получалась отгружена полностью, оплачена полностью. Может оно и правильно так как есть, но - неудобно...

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

(16) При всем уважении (без сарказма). Но где бы не появлялось упоминание выбора УНФ как учетную систему, тут же появляется камрад Злопчинский и вываливает кучу недостатков этой конфигурации. Наверное, это тоже надо. НО. Обсуждение темы сваливается в спор сторонников и противников УНФ, полностью игнорируя тему, что неприемлемо.
Ув. Злопчинский, напишите статью на инфостарт со всеми, на ваш взгляд, недостатками, недочетами и косяками УНФ. И в темах подобных этой просто скидывайте ссылку. Это и осведомит заинтересованных лиц и не засорит ветку.

(17) Замечание принял. Исправлюсь. Ненадолго.

(9) Так УНФ писали условные приходящие-уходящие прогеры или стажеры франча, а потом сами подтянулись в 1С до уровня совместно. Приставка "1С: <НазваниеВашейПрограммы>" про качество кода мало относится, больше про менеджмент, срок выпуска релизов, техническую поддержку. От 1С вам гарантия что если франч ливнет они передадут его дальнейшую поддержку, обновление, разработку другому франчу.
А всякие УТ, БП, ERP пишутся силами команды внутри 1С. ЗУП вроде отдавали крупному франчу со всеми вытекающими матюками со стороны пользователей/консультантов как все плохо.
Рекомендации - они такое, когда я впервые пришел во франч сказали прочитать ИТС " 1С:Предприятие 8. Система стандартов и методик разработки конфигураций" (он был скудный на 2010 год), мало кому другим сотрудникам это давали в качестве факультатива.
Сейчас уверен, что ситуация не лучше и мало кто читает, хотя автопроверки в EDT стараются это все автоматизировать.

(17) во первых там косяков столько что на несколько статей хватит.
Во вторых с выходом новой версии нужно будет новую статью писать по новым косякам.

Ну и большинство претензии в основном к тому что писатели УНФ в глаза не видели типовые от 1С, и у них на всё свое виденье.  И вот тут и начинает пригорает, потому что то что в типовых давно реализовано как бест практикс, в УНФ этого или нет, или работает не так как ты ожидаешь.
К примеру есть БСП стандарт который в типовых будет работать так же как описано на ИТС (включая название и расположение процедур). И есть УНФ, у которых свое казино и теже процедуры из БСП называются по другому и расположены в других местах. Хочешь добавить печатную форму - начни квест - "найди куда добавь вызов". Такое ощущение что писатели УНФ боялись получить иск за плагиат кода от 1С. Плюсом добавь сюда ошибки в коде и ты поймешь, почему некоторые так стремяться послать лучи добра в сторону УНФ при каждом удобном случае.

(13) потому что они начинали как Управление Нашей Фирмы и позиционировали себя для мелкой фирмы занимающейся услугами (ну типа фирма по установки кондиционеров). Продажи там практически не было. Услуги плюс движение материалов. Потом, когда они перешли под крыло 1С, они стали торговый модуль расширять плюс интеграция со сторонними сервисами (сайт, интернет заказы, телефония)

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

(22) Они зачетные )) Мозг юзерам ломается раз и навсегда

(21) Управление Небольшой Фирмой
?

(20) "и ты поймешь, почему некоторые так стремяться послать лучи добра в сторону УНФ"©
У меня есть это понимание. Речь не о том. Возьмем эту тему. Вопрос КАКАЯ конфа больше приспособлена к работе с маркет плейсами. С 9 по последний пост тема уже НЕ обсуждается. Вылилось все в обсуждение УНФ и ее косяков. Вот это не нравится

(25) Так ТС и выбирает между УТ и УНФ, так что логично. Вот если бы скатилось бы к обсуждению ЗУПа, тогда я бы понял твои претензии.

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

Во вторых, почему то ТС не рассматривает БП в качестве программы учета?

Ну и в третих, а на чем сейчас УТ ведет учет?

Мне кажется что лучше выбрать КА (Комплексная Автоматизация).
Маркетплейсы это либо комиссия либо отгрузка без перехода права собственности.
И УТ и УНФ подразумевают обмен с БП 3
А это значит дополнительный контроль взаиморасчетов и в БП и в УТ/УНФ+ косяки с обменом платежами и корректировками долга по разным договорам
Типовой интеграции нет нигде (Вот если бы сами маркетплейсы вели свой учет в 1с, то жизнь была бы прекрасна)
Тем более что разные схемы ФБО и ФБС и т.п. у каждого маркетплейса реализованы по разному (+ всякие схемы с баллами, бонусами и скидками, до которых еще налоговая не добралась). И все это постоянно меняется. Как API так и отчеты в Excel

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

УТ 11 будет лучше все таки для учета чем УНФ

УНФ хороша тем, что там есть план счетов и можно собрать нормальный управленческий баланс и прочее.

(28) интересовался обработками/расширениями по обмену с маркеплейсами в 2021 году, было очень дорого, на уровне 100-200к разово у одних или 10-20к в месяц у других. Но тогда еще в УТ/УНФ не было встроенных механизмов.

вот в УНФ сегодня: https://t.me/small_biz/292

(27) Тогда давай уж сразу ERP, чего там мелочиться!

(26) Во вторых, почему то ТС не рассматривает БП в качестве программы учета?

Отличный вопрос. И у меня, кажется есть ответ. Полагаю, ТС пока просто не изучил как без всех интеграций, отдать кому-то что-то на комиссию, получить от него отчет комиссионера, внести его, получить свою выручку, закрыть взаиморасчеты.  Т.е. просто сначала сделать все это, как будто бы мы работаем с ООО Лютик, где нет никаких интеграций.

Исходя из этого, уже и строить дальнейшие выводы. Возможно, если там не сотня-штучные по составу номенклатуры продажи, там и интеграция то не нужна.

Если всерьёз и надолго, при желании автоматизировать не только заказы, остатки, цены, а именно интегрировать свои складские процессы под маркетплейсы, то надо разрабатывать самим. Брать стороннее решение и вписываться в процессы его - ну такое себе решение, плюс доработки всех готовых модулей выльется в боль, а что-то вообще архитектурно будет сделать невозможно. Поэтому брать УНС или УТ - разницы особой и нет

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

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

(32) сложилось впечатление, что УНФ самая передовая в плане интеграций и новых подходов в учете/производстве конфа, прям много что нового придумывают.
А в УТ интеграции как-то по остаточному принципу медленно при обновлении БСП попадают.

(37) "Сейчас маркетплейс хочет знать сколько мест по заказу и какой именно товар в каждой коробочке." - любая нормальная складская система по итогам сборки/упаковки выдаст это наружу в КИС.
.
"Далее учесть отгрузочные зоны, чтобы "чужое" отправление даже одного МП не попало случайно в не тот акт передачи."
- тут немного мутновато для меня по определениям (что такое "отгрузочные" зоны), но - что куда должно попасть - это формально определяется и соответственно подлежит нормальной "автоматизации" для недопущения смешивания, оформления первички итд. И первичку обычно тоже печатает КИС (ибо тянуть в складские системы цены, суммы, ставки НДС и прочую хрень - так себе идея), но тут как какой клиент захочет. Лишь бы платил ;-)

(38) да, в УНФ много интеграций разных сразу идет. и регулярно внедряются. насколько это адекватно и работоспособно - сказать не могу, не моя епархия ;-)

Прочитал все сообщения. Создалось стойкое убеждение, что никто из отметившихся, не имел дело с УНФ в части маркетплейсов...
Во первых, УНФ из коробки с ВБ не работает. С Озоном работает, но начиная с создания карточек товаров там и происходит первый затык...Поэтому напильник нужен или сторонняя разработка.

(41) ввыиду написанного мною в ветке про УНФ - не удивлюсь ;-) Но ввиду (17) - вынужден молчать, даже когда тигр голодает.

(41) УНФ это тупик

УнФ +Модуль озона - палет нормальный - встроенный не взлетел

(44) СинхрОзон самый понятный и простой модуль интеграции. При этом с вполне достаточной функциональностью. Легко взлетает и на УТ.

(45) а этикетки для заказов как печатаются? тянутся по апи в виде пдф?

(45) Synchrozon это "родной" модуль от самого озона.

(47) хрень все это.
должно быть как ЯндексТакси.
"АГРЕГАТОР-КОННЕКТОР API" маркетплейсов
который для клиента  - единый язык общения со всеми "такопарками"/маркетплейсами. Про это я писал ранее. И уже есть такие сервисы.
.
кто-то на этом реально поднимется.

(26)
>Во вторых, почему то ТС не рассматривает БП в качестве программы учета?
С БП не работаю, может управленческий учет нужен потому что отгрузка товара, продажа, выбытие в ЧЗ может произойти вчера, а оплата и все закрывающие документы, передергивание уже выбывших марок из оборота в УПД в течение полугода, а оплата вообще через год-полтора?
МаркетПлейсы, Гиперы так и работают.

(47) Синхронизон , это для УНФ 1.6.
В УНФ 3.0 все функции Синхронизона есть в типовой.

Если только на Озоне есть товар, который объединен в одну карточку, то у вас ничего не получится.
Разрабы УНФ ничего умнее не придумали, как сделать это одной номенклатурой, но с разными характеристиками.При выгрузке на Озон из УНФ, потом ручками все равно править в ЛК Озона.
Точно также, если у вас много товара в одной карточке, то отчет комиссионера вгрузится нелепый.
Короче, УФН отлично работает, только если товар не объединять в одну карточку, иначе или напильником или смириться и ждать когда УНФ допилят.

Вопрос немного не по теме.
В типовых конфигурациях типа УПП,КА,УТ,УНФ есть заказы покупателя.
В момент поступления по API заказ например на розничного покупателя. Отгрузка на Розничного покупателя. А через месяц маркетплейс говорит, что продал юр лицу. Как быть с исправлениями заказов

(34) Без интеграции по отчетам комиссионера иногда просто невозможно вести учет в своей базе. Просто нет достаточных аналитик в тех документах, что дает комиссионер. Скажем, если нет привязки возврата от покупателя к тому отчету, в котором этот товар был продан. Ищи-свищи по сопоставлению цен, а они и то не всегда сопоставляются, иногда комиссионер дает скидки по своей инициативе, в отчете может быть одна цена, а в возврате другая. Нахлебаешься полной ложкой..

(52) Почитайте на досуге, кто такой комиссионер.

(53) Не делает скидки по своей инициативе Озон. Скидку может только сделать продавец, по просьбе покупателя. Тогда просто цена товара, переданного на комиссию уменьшается.

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

(56) Баллы Озона в отчете комиссионера не участвуют. Там же сразу разделяет.

(54) Ни один из маркетплейсов не считает себя комиссионером. Договор комиссии это только в конфигурациях 1С.

(56) Сильно усложняет другое...
Это возвратный товар....
Стоимость товара обычно намного меньше, если товар вернуть к себе на склад.
На склад Озона то товар возвращается бесплатно для продавца, но если захотеть его вернуть себе...Это треш и пипец..
Мои клиенты почти каждый месяц дарят Озону товара на 700 тыс.
Потому как его вернуть на свой склад выйдет в пять раз дороже.

(58) ага...

Как и применение к примеру онлайн кассы.

(58) даже больше скажу, если ОЗОН продаёт юр.лицу, то они чётко пишут, чтобы ОЗОН не включали в графу посредник в книге продаж. И тут встаёт вопрос как правильно отразить в БП, если используется комиссионная торговля. Пока выход колхозить через возврат из комиссии, продажа на юр.лицо

(57) в самом последнем отчете добавили как раз баллы в отчет о реализации, теперь там комиссия считается 1%, если сумма бонусов превысила сумму комиссии

(58) А кем они себя считают? Агентом?

УНФ

(63) Они говорят примерно так: мы придумали схемы торговли, которые нам нравятся. А что есть еще законодательство?

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

А уже в отчете комиссионера отражать что продажа была на юрлицо и сформировать счетфактуру.

Мое мнение брать УТ.
В УНФ очень много методологических косяков учета.


Последняя история.


В УНФ "Отчет комиссионера о списании" нет возможности поставить сумму претензии на комиссионера. И самое интересное при переносе в бухгалтерию документ медленно преращается.... в  "СписаниеТоваров" со склада.

(37) Еще про маркированный товар еще не забываем. Надо что бы на конкретный экземпляр товара наклеили конкретную этикетку.

(68)  Так это обязательное условие для любой отгрузки, не только с маркетплейсами.

Лучший способ работать с маркетплейсами - это через прокладку, ИП или ООО на упрощенке, которая занимается лишь этой деятельностью. Вести нормальный бухгалтерский учет комиссионной реализации в 1с с учетом всех нюансов и капризов маркетплейсов сложно до ужаса..

Возможно поможет, тут описано сравнение функционала https://1s-sklad.ru/

(70) Скажи это моим клиентам, которые работают только с маркетплейсами с ярдовыми оборотами.

(72) Ну у них и интеграция наверное налажена нормальная. Они не работают через личный кабинет с кривыми отчетами по продажам, пытаясь их как-то сопоставить с официальными УПД, присылаемыми через ЭДО. При том что форматы этих отчетов меняются раз в квартал.

(73) Кривость отчета это еще не беда. Вот когда WB берет и без оповещения меняет данные отчетов задним числом. Вот это весело. Мне новые клиенты не верят, что такое возможно. Потом через некоторое время понимают, что так оно и есть.

Здесь интегрируй не интегрируй.

(56) скидки за счет своего комиссионного вознаграждения. Что оооочень сильно усложняло бухгалтерию всего этого непотребства.

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

(50) Типовой в УНФ - у меня не заработал

Про унф и сайт добавлю - в унф есть 2 обмена - старый и новый - с новым возникла проблема с каталогами на сайте а старый не работает по расписанию - делаем руками

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

(79) так у тебя в отчете комиссионера есть две колонки сумма реализации и сумма комиссии...

(75) С комиссионным  вознаграждением другая веселость может, когда в продаже комиссионное вознаграждение отрицательное.

(79) Угу, и потом думай, как это всё связать с УПД по реализации и по услугам комиссии, чтобы до копейки сошлось.. И это я ещё корректировок реализации на основе возвратов от покупателей не касался. Там вообще кошмар.

(78)  должна отражаться по бухучету не за счет снижения выручки

Т.е. допустим вы продали за 100 рублей стул, ваша комиссия 10 рублей. Вы должны мне 90 рублей.

Но в результате доп.скидки, ваша комиссия составила 20 рублей. Вы должны мне перечислить 80 рублей, но вы перечисляете мне все те же 90? Я вам должен 10 рублей, которые вы приплюсуете к следующему комиссионому вознаграждению?

(66) читай (58)

(66) https://seller-edu.ozon.ru/finances-documents/sales-to-legal-entities/prodazhi-urlicam
...
графы 9 и 10 «Сведения о посреднике» заполнять не нужно;
в столбце 2 «Код вида операции» проставьте код 01 — это значит, что товары реализуете вы, а не посредник.


Если делать как вы говорите, то тут появляется инфа в книге продаж про посредника, чего быть не должно. Именно на это мы пока нелетели, тоже отражаем как комиссию на ОЗОН

+(83) Пока придумал так (чтоб не писать копирнул внутренне письмо описание доработки):

------

Добрый день!

Прошу всех обсудить между собой, внести коррективы и согласовать следующий механизм:

Сейчас у нас так:
1 Мы получаем заказ по API Яндекс маркет и фиксируем его в базе УПП документом "Заказ покупателя"
2 Мы делаем отгрузку контрагенту "Частное лицо Яндекс маркет" документом "Реализация товаров и услуг (Отгрузка без перехода права собственности)"
3 Мы подтверждаем факт доставки конечному клиенту документом "Реализация отгруженных товаров"
4 По факту загрузки отчетов Excel раз в месяц нам приходится вносить корректировки в ранее созданные документы (например менять конечного покупателя)


Будет так
На шаге 4 будет разработан документ "Уточнение информации о конечной продаже Яндекс маркет"
Реквизиты документа:
1 "Номер"
2 "Дата"
3 "Организация"
4 "Первичный заказ покупателя" тип значения "Документ Заказ покупателя"
5 "Первичная реализация товаров и услуг" тип значения "Документ Реализация товаров и услуг"
6 "Первичный реализация отгруженных товаров" тип значения "Документ Реализация отгруженных товаров"
7 "Конечный контрагент покупатель" тип значения "Справочник контрагенты"
8 "Договор конечного покупателя" тип значения "Справочник договоры контрагентов"

Далее будет группа реквизитов для корректировочных документов
9 "Документ корректировки записей регистров заказа покупателя" тип значения "Документ корректировка записей регистров накопления"
10 "Документ корректировки записей регистров реализации товаров и услуг" тип значения "Документ корректировка записей регистров накопления"
11 "Документ корректировки записей регистров Реализация отгруженных товаров" тип значения "Документ корректировка записей регистров накопления"
12....и далее реквизиты, которые получены из отчета маркетплейса Excel (баллы и т.п.)


Суть доработки:
Для того, чтобы выйти на работу в реальном времени и не править постоянно документы задним числом (они могут попасть в прошлый уже закрытый месяц, квартал или год) в структуру подчиненности (цепочку документов) мы добавим этот документ. Мы сможем либо вручную либо по факту загрузки отчета Excel внести такой документ в базу. и Уже сам документ, на основании полученных в нем реквизитов создаст дополнительные документы "Корректировка записей регистров накопления", которые сторнируют созданные ранее записи Заказа, реализации или реализации отгруженных товаров.


Наша цель:
Добиться такого же эффекта как в документе "Универсальная складская операция". Напомню. Когда нам надо перепаковать товар в зависимости от того что надо менять серию или качество система создает типовые документы "Корректировка серий товаров" и "Корректировка качества товаров"

Так и сейчас. Например нам надо указать, что конченый покупателем было на частное лицо, а юридическое.
В момент получения такой информации вводим на основании реализации товаров и услуг наш документ "Уточнение информации о конечной продаже Яндекс маркет"
Подчиненные документы "Корректировка записей регистров" сторнируют выборочно (по прописанному нами алгоритму) движения регистров связанных с продажами и отчетами в ФНС и поменяют там контрагента покупателя

В форме данного документа можно предусмотреть печатные формы для случаев когда их надо предоставить.
Так же на основании этого документа предусмотрим возможность формирования документов корректировки долга, платежек и т.п.
Так как документ будет порождать типовые документы "Корректировка записей регистров накопления", то система УПП не выступит против такого усовершенствования. Онга будет считать что мы руками создаем много корректировок.

В дальнейшем по аналогии планируется создание документов для всех маркетплейсов и конфигурации КА

"Уточнение информации о конечной продаже Яндекс маркет"
"Уточнение информации о конечной продаже Озон"
"Уточнение информации о конечной продаже Сбермегамаркет"
"Уточнение информации о конечной продаже Wildberise"

Главная цель : выйти на режим работы в реальном времени. Как есть по жизни. Раз мы получили уточненную информацию о конечной продаже, а этой информации у нас ранее не было, то нам надо эту информацию внести откорректировать информацию в базе исходя из новых жизненных реалий, а не переписывать прошлое каждый раз

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

следует различать корректировки по БУ и по НУ.
могут ждать неприятные сюопрайзы...