Исходные данные:
Есть продажи на маркетплейсе, в 1с обработка читает из личного кабинета ВБ поступившие заказы и кидает их в резерв. У каждого заказа есть свой ID.
На текущий момент этот ID просто прописывается в табличной части резерва и резервы списываются.
Всё штатно и просто.

Проблема в том, что контролировать правильность резервов (соответствие всех заказов на ВБ с резервами в 1с) сложно. Заказы падают постоянно, например по 100 штук в день, товары находятся и списываются с разных складов, и вероятность какой-то ошибки (например дважды списать один заказ с двух складов) высока.

Было бы классно если бы СУБД могла бы этот ID заказа в счетах контролировать как уникальный индекс, но к сожалению 1с такой признак на реквизит поставить не может.

Вопрос: как правильно реализовать контроль уникальности реквизита (в данном случае ID заказа) в табличной части документа?

(35) > " я бы заказы группировал по дате отгрузки"

ну как бы мы так и делаем, вечером создаётся резерв, в ТЧ которого падают всю новые заказы. и Кладовщик его собирает

Кстати если вдруг комуто интересно, оказывается в 7й 1с можно использовать API ВБ. В гугле я искал но так и не нашёл каких-то следов использования API Вб в клюшках. Но она оказалась у знакомого программиста )

(38) ипать вы мастера...
Уменьшайте кол-во ручных рпераций. Тот де менеджер ТИПА решая с какого склада отражать сильно думает? Анализирует темп продаж по складу? Смотрит на каком складе меньше вип клиентов обслуживается итп? Да хрен там! Максимум 2-3 условия типа какой склад ближе, на каком складе больше количе тво проблемной позиции или типа на складе "Урюпинск" самый толковый нач.склада и там делают меньше всего косяков.
Загоняй разбиение пула в автомат по небольшому кол-ву условий и около птиц! Я бы вообще разбивал по принципу общее меньшее кол-во складов, чтобы если пул бился на 3 склада или на 2 - выбирать вариант где 2 склада, бо обычно доставка со склада на пункт сдачи ВБ - это транспортники и ресурса у них мало/дорого/проблемы...
.
Закачал заказы текущего дня ТИПА в один док-контейнер +типа как неподтверждённая заявка в ТИС) дальше прелучсмотреть кнопку для ручной разбивки по вкладам, но при загрузке сразу бить автоматом по вкладам и документы по складам ставить в статус "на согласовании" чтобы манагер мог осмотреть разбивку по скоалам и либо подтвердить поставив статус "к исполнению(манагер)" либо переразбить вручную (удобным армом, описывали ранее), а для всяких долбодятлов которые забывают вовремя подтвердить/обработать - роботом переводить в статус "к исполнению(авто)" по истечении часа/двух от момента появления "неподтвержденной заявки" Или если до датао грудки осталось 24 часа или менее, или ещё как - зависит от ваших процессов товарообработки и обслуживания заказов на складе. Зуб даю что спустя некоторое короткое время в 99.99 менеджеры будут подтверждать к исполнению не глядя или вообще не подтверждать и робот будет херачить автоматом.
.
Даже ещё проще и красившее можно сделать. "Неподтверждённка"(НЗ) с полным составом пула заказов загружается обменом в систему, в этой же НЗ автоматом бьётся по складам со статусом "на согласовании" и ставится в резерв по этим складам. Ясен пень что в работу по складу такие заявки не выдаются пока не станут "к исполнению" И произойдёт уже разбиение на реальные доки-заявки резервирования как у вас штатно сделано.

Ну я писатель...
Еду в прездатрм поезде, всё равно не спится

Надеюсь объяснять в описанной выше схеме как штатная заявка закрывает резерв по НЗ и переписывает резерв на себя - не надо...?

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

На клюшках описанную выше схему за два рабочих дня с перекурами и печеньками наваять можно

И пусть "менеджеры", которые продажами занимабтся - занимабтся продажами, продвижением товаров и карточек на мп и рубят бабло для фирмы, а не занимаются тупой технической работой вместо компа по разбиениб по складам.

Есть ещё вариант с резервированием без указания склада - при этом гарантируется наличие резерва под заказ в целом по компании (на каком-то из складов хз на каком) с последующим резервированием по складу когда к исполнению, но тут есть как плюсы (более гибк й подход) так и некоторые минусы (м.б. а м. и не б. этих минусов), надо смотреть/бумать внимательнее при выборе такой схемы, описать её особенности могу отдельно

(40) на ис смотрел?
Скиь мне если можно на мыло

Мыло в профиле.

(41) > "Зуб даю что спустя некоторое короткое время в 99.99 менеджеры будут подтверждать к исполнению не глядя или вообще не подтверждать и робот будет херачить автоматом."

Блин, ну так нельзя. Резерв ведь действительно могли не повезти по какимто причинам. Какже его роботу списывать автоматом ? )

Не - списывать должен человек. Минус 100 руб к примеии если не списал вовремя - думаю будетлучшим решением )

(44) Полностью авто разбиения у нас нет. Полуавтомат. Вот такой:
https://drive.google.com/file/d/1Cs4BD1HC1O1WqbfTtDVlo5dMLtn7pOad/view?usp=sharing

Манагер просто отмечает товары, которые есть на остатке на складе и кидает их в Резерв

(46) создание резерва занимает 30 секунд времени.
Ну и помимо создания далее ведь нужно как минимум распечатать QR коды заказов и т.д.
Думаю 3 минуты времени манагера на всё это не стоят того, чтобы этот процесс автоматизировать /учитывая что такая полная автоматизация принесёт свои новые проблемы/

(50) какое списание резерва, ты о чем? Робот только ставит в резерв, а списание либо документом о грузки либо закрытием заказа либо отменой щаказа

Почитай ещё раз внимательно что я написал. Всё что я написал - исключительно резервирование и разбиение по складам.что у тебя значит "списание резерва" - хрен знает, по моему разумению это отгрузка за пределы склада.
Е

(52) если создание резерва на 100 строк занимает 30 секунд разбить на несколько складов - это значит что манагер вообще нихрена не думает, а соглашается с вариантом системы.

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

И каким образом печать куеров относится к разбиению по резервам? Хз как у вас сделано, по моему разумению резервирование - это один процесс/этап обслуживания заказов, печать куеров для маркировки - что скорее всего означает выдачу заказа в работу на склад - второй этап

Да, эти два этапа могут идти без перерыва один за другим - всё делает менеджер сразу сам, но по сути жто остаётся двумя этапами, потоу как они в принципе различны по функциональность у назначению в процессе обработки заказов

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

Куеры это наверное ваша внутренняя маркировка

(54) верно. Списание резерва - это отгрузка товара за пределы склада. Если его не списать вовремя, новые заказы будут падать на этот остаток а товара на складе уже не будет. И далее манагеры руками пересоздают заказы и могут где-то ошибиться. Вот эти ручные заказы я и хочу контролировать на уникальность ВБ заказов в счетах.
П.с. уже и реализовал у себя через выгрузку всех ТЧ резервов в ТЗ и в ТЗ смотрю чтобы не было дублей

(59) да. По умолчанию все селлеры qr заказов печатают из ЛК вб. Но у меня ведь есть крутая обработка которая умеет это делать в 1с )

(33) теоретически несколько заказов 1 документ отгрузки. Или 1 заказ несколько документов отгрузки
Но это все нужно чтобы двинуть статус заказа на маркетплейсе (типа заказ отгружен)

(53) ну так у нас именно так и есть. Твоё "Робот ставит в резерв" это у нас реализовано через - манагер нажимает кнопку и 1с автоматом создаёт резерв на все заказы которые есть в наличии на выбранном складе.
Из ручного труда только - выбрать склад и нажать кнопку

(63) заказ от вб - это единичная покупка одной штуки товара покупателем. Поэтому логично все такие заказы за один день в 1с группировать в один резерв, собирать в коробки и отгружать (списывать резерв).

(61) трындец.. Как новые заказы могут падать на склад и товара будет не хватать?
Свободный остаток на складе 100, пришли заказы, в резерве по заказам 80, свободный остаток  20, отгружены эти заказы или нет похрен - при появлении новых заказов на этот склад больше 20 упасть не должно.
Это штатное понимание резерва. Если у вас не так - я в ахрененнии.И если манагер забыл "списать резерв" То по штатной схеме вышеописанной это никак не должно получиться что на складе будет оверсток. И манагера здесь можно штрафанули только за не оформление учётных доков по отгрузке.

Такое ощущение что резервирования как такового - исключения зарезервированных товаров из свободного остатка доступного для других заказов - у вас вообще нет...

(66) блин ну извиняй, да, в этой моей обработке я анализирую физический остаток а не свободный ).
Ну вот как-то так сделал)

(67) Да, на сегодня применительно к заказам на вб - нет. Потомучто заказы вб первичны и им плевать на остальные резервы, они будут списаны первыми всеравно

(64) выбрать склад и нажать кнопку - возвращаемся к баранам - робот мой сам выбирает склад по нескольким условиям. А у вас менеджер тупо соглашается с системой по остатку товаров 100 строк на несколько складов раскидать за 30 сек с анализом нескольких условий - нереально. Если условие одно - остаток на складе - манагер тут на хер не нужен, пусть система в вашем Арме сама раскидывает, манагеру кнопку печати нажать тобтко.., ;-)

(67) ну и в принципе резервирование - у нас тол ко информативное. Запрет не выставляется. У нас половина товара в базе по резервам в минус, потомучто только 20% резервов списывается, а остальные не уходят клиентам

(70) "Если условие одно - остаток на складе - манагер тут на хер не нужен, пусть система в вашем Арме сама раскидывает, манагеру кнопку печати нажать тобтко.., ;-)"

а в чём смысл такой автоматизации, которая уберёт у манагера работу по нажатию кнопки?
тут сразу первый вопрос, а в какое время суток робот будет её нажимать ? )
А манагер знает на это вопрос, например когда кладовщик готов начать собирать заказы тогда он её и жмёт /тем более что манагером этот кладовщик и является :)/

(69) это тоже реализовать можно штатным пониманием резервов и пофиг кто это ВБ озин или вип-клиент.
Это всего лишь перераспределение резерва с одних клиентов на другие что тоже можно сделать автоматом при резервировании щаказов ВБ и даже с авто уведомлением другого менеджера что его резерв накрылся медным тазиком

(71) да я так и понял по обсуждению Уде, представляю какой ад и Израиль у вас там творится. Всего-то что надо - написать резервирование товаров по заказам. И всё. Ладе нп обращая, внимания на схему работы с ВБ что я описал ранее. - она вообще ляжет ааа влитая если будет нормальное резервированиеа не информатмвное

(73) Согласен, можно но не нужно ). Потому-что у меня  в сутках только 24 часа, а свои хотелки в базе я уже 20 лет пишу и приходится выбирать что в приоритете, т.к. разорваться не получается. А нанимать сторонних программеров таких как ты - денег не хватит ).

п.с. Ну и в моём случае делать супер движок по резервам - действительно не нужно. Простейшее что есть сейчас - видеть свободный остаток - достаточно

(72) вообще ппц.
Робот обмена свалил заказ в систему. Этот же робот или другой зарезервировал сразу или с таймаутом. Заказть всё равно будет отгружен. Манагер только осматривает заказ и принимает решение пускать его в работу или нет. А так как заказы ВБ друг от друга независимы и объединяются только номером отправления когда Вася заказал два разных товара (каждый товара идёт у ВБ отдельным заказом вроде, про номер отправления тоже могу лажать) то даже если часть отправления неполная - остальные отправления будут отгружены.
.
И вообще вопрос который ты поднял в ответе - второстепенно. Реализация по разному может быть сделана.

(74) Всё у нас нормально )

> "Всего-то что надо - написать резервирование товаров по заказам"
У нас есть резервирование. Только оно не выставляет запрет на резервы в минус. Потомучто по ТЗ это нам не нужно, невозможность поставить в минус нам будет мешать.
Согласись, не во всех учётных системах такое должно быть реализовано.

(75) я, вас понял. Как говорится хрен ли думать, трясти надо ;-) успехов!

(76) Всё верно, я не спорю, можно автоматизировать "нажатие одной кнопки", чтобы робот её сам нажимал. Только смысла большого нет, тк. повторюсь, мои ресуры не безграничны.
Мне проще так: кладовщик решил что он наотдыхался и тогда он подходит к компу, жмёт первую кнопку "прочитать все новые заказы", вторую кнопку "создать резерв на все новые заказы" и 3юю кнопку "распечатать на эти заказы из QR штрихкоды"

На это у него уходит 90 секунд.

п.с. блин, никак не могу привыкнуть к мисте, что сначала нужно 10 раз перечитать своё сообщение и пофиксить все ошибки а потом только его отправлять.  )

(77) в минус будет мешать
Ну это зависит для чего у вас резерв в минус, каков его смысл. Всяко может быть.
.
Вот есть у вас положительный резерв, отрицательный резерв. При резервировании могут быть ошибки. Остаток по складу 109, в резерве 120, отрицательный резерв = -20.
Как понять - это правильный отрицательный резерв или с ним какой-то косяк (программный или нарушение регламентов работы) и правил ный резер -15, а -5 - это косяк?

(79) у вас там ад и Израиль. И понятно почему тебе проще прилепить очередной костыль (пусть даже опупенно клёвую обработку) и почему ресурсы не ьезграничны ;-) всё проходили через ххп, ещё раз успехов!

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

(81) "Как понять - это правильный отрицательный резерв или с ним какой-то косяк"

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

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

(82) " у вас там ад и Израиль"
Блин, критику я люблю и принимаю, но всё-таки когда она предметная)

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

Всё просто. На складе у нас в наличии 2 принтера. Манагеры играются в тендера и выставляют его 10ти клиентам по 1й штуке каждому. Соответственно свободный остаток товара = -8штук.
И запретить этот принтер выставлять клиентам потомучто у нас их всего 2 - глупо.
Понятно что манагер должен зарезервировать у поставщика эту позицию т.е.  иметь возможность его докупить если его выставленный счёт покупатель акцептует

(84) резервы не надо считать. Их надо получать го овые. А счиабися они один раз по простой достаточно схеме и фиксируются. А дальше тупо чтаются. И даже если у вас куча резервов не грузится и поэтому в минус, то и это решаемо. Достаточно резервы фиксировать без заказов/клиентов, только по "направлениям*/видам. И тогда можно грузить любой заказ или брать в работу кладовщику самостоятельно (а выше у тебя хз то менеджеры резервируют, то кладовщики, ад и евреи) , гланое чтобы хватило свободного остатка+резерва по направлениям) вилас не выше направления/вида кл ента, чтобы Вася ге мог забрать резерв ВБ, а Петя спокойно заберёт резерв который мог бы взять впся - зависит от того чей щаказ первее в работу пойдёт ;-)
А дальше такая схема с один пинок превращается, в резервирование по заказам, когда к направлению добавляется сам заказ... Или пр орбиты/оччемелность заказа которые ставит менеджер, итд...

Схема 87 покрывает 86
И то что ты описал в 86 решено даде в типовой тис.
2 принтера ставятся в резерв по выиграным тендерам, а остал ные 8шт по выигранным тендерам ставятся в очередь к требуемых поставок/закупа. И документ заказа поставщику заполняется нажатием кнопки без доп обсчетов, и если вылез минусовой резерв - сразу понятно что косяк.
Я не говорю что тис идеал на, там и в этой схе е есть пит. Темы, но они дописыааются как развитие схемы а не ктстыль. Учтиво.
Пр   надо хорошо интуичить где достаточно костыль влепить, а где вопросы архитектуры которые имеют долговременное влияние/значение.понятно что приходит с опытом.

Но ты не ссы ;-(
У меня всяких костылей тоже накопилось. И хорошо что подавляющая часть их всего надстройка над архитектурой, и малая часть как зубная боль...

(69) а если 2 клиента закажут одну и туже хрень которая у вас в единственном экземпляре. Я не понимаю как в этом случае схема отработает?

(90) жто щависит сугубо от тайм-аута обновления свободных остатков по данным базы в ЛК МП.

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

У моего клиента таковое нечасто но регулярно случается, ьо менеджеры на предупреждения системы не смотрят и не переводят номенклатуру мп в базе 1с на ручное управление или =0 (нет в наличии для МП), бо "им некогда" ;-) или не хотят или хз...
По уму там клиенту надо дописать малость по подсистеме МП, я на снеговика не кодю, а удалённый прог с ресурсом тоже проблемы

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

Есть у меня подозрение что нужное мне для соединения со штатными разработками для МП можно в УТ реализовать правильной настройкой учёта в части резервирования, но УТ мне копать влом (это как про сову и йожиков) и перерезервирование на лету без участия юзверя там вряд ли есть (?)

(84) насколько я себе представляю, резервы - как совокупность всех живых заказов - ты насчитывсншт каждый раз когда эта цифра требуется? Или это все-таки у тебя в регистре хранится потребность для, всех живых щаказов?

(90) > "а если 2 клиента закажут одну и туже хрень которая у вас в единственном экземпляре. Я не понимаю как в этом случае схема отработает?"

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

(96) Остаток по Резерву у меня в регистре хранится. Счётфактуры этот остаток увеличивают, а отгрузки со склада на основании этого счёта уменьшают

(91) если у тебя N площадок то никакой таймаут не спасёт.

(99) Да, поэтому лучше торговать на ФБО ). А оп ФБС только на одной площадке если риски ухода в ноль велики

(98) Система ниппель

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

(98) не счет-фактура, а просто счет

(92) ну да, одно из грубых решений не выгружать на площадки остатки < 10 шт

(102) Принцип работы с маркетплейсами у селлеров следующий: один раз селлер выгружает свой остаток, а далее МП уже сам уменьшает у себя этот загруженный остаток и контролирует чтобы он не ушёл в минус.
Если же селлер этот товар продаёт ещё и в других местах (или МП) тогда да, ему приходится этот остаток перезаливать постоянно на площадки

(100) торговать на ФБР или ФБ-с зависит от того насколько прибыльно там или там. А стоимость за логистику мп регулярно меняет. То было по ФБР прибыльно, по ом мп поднял логистику, стало плохо итд. Так-то конечно по ФБР проще намного

(104) Решение как поступать в данном случае уже зависит непосредственно от предметной области. т.е что селлер продаёт, оборачиваемость товара, его стоимость, возможность быстро докупить и т.д.
Если например он продаёт мерседесы 600ые, то меньше 10ти штук не продавать - не совсем себе выход )

(106) Да конечно априори продавать лучше там где выгодней ). Но что касается МП, логистика - это не основной показатель, который влияет на прибыльность. И если продавец уже вырос из штанишек, то практически всегда ФБО 9продажа со склада МП) будет для него выгодней чем ФБС (продажа со своего склада)

(101) А в чём проблема?
Обычные физические остатки разве не так считаются?

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

(103) Я до сего момента не знал а в чём отличие и вот гул первым запросом выдаёт:
"Отличие счета от счета-фактуры в том, что счет выписывается на оплату услуг, а счет-фактура выписывается на оплату товара"
:)

(97) а вот разрисуй подробнее схему обмена остатками и заказами с МП, что за чем идёт с какими таймингами и/или по каким событиям и от скольки фирм и на сколько площадок выставляется товар и я тебе скажу будет оверсток или нет.
Предварительно так: в общем случае оверсток будет всегда и если он не случается то просто вам везет. Даже без рассмотрения схемы обмена. Алексей подтвердит скорее всего мой вывод.

Возможность оверстока минимизируется лишь в случае когда мп при заказе покупателя сам стучится к вам в базу для получения актуального остатка как это у Яндекса или Сбера, точно не помню у кого

(105) по такой схеме хватит у селлера и одной площадки.

(105) проигрывай сценарии тщательне ;-)

(105) у меня например товар одновременно может быть выставлен на 16 площадках и при такой схеме жопа будет сразу. Решение которое у меня уменьшает вероятность такой жопы существенно, но не сводит её к нулю

(111) >"а вот разрисуй подробнее схему обмена остатками и заказами с МП"

1) Конкретно в нашем случае у нас только один МП - это ВБ.
2) 95% продаж тех товарных групп которые идут на ВБ - продажи только на ВБ, и только 5% продаётся в розницу.

поэтому схема обмена остатками простая - если товар продан (или зарезервирован) Не на ВБ, тогда выгружаем на ВБ новый остаток.

А заказы с ВБ - обработка просто стучится через API в кабинет ВБ и читает их

(115) Понятное дело что 16 площадок - совсем другой случай. Но:
маркетплейсов нормальных всего 4, грубо: ВБ - это 50% всего рынка, озон ещё 35% и два оставшихся 15%.

Половина всех селлеров ВБ работает только с ВБ

(110) Это тебе ИИ таую чушь написал?

(118) Очень похоже! :-)
Поржал...

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

(118) Я же написал кто - гугл (правда да, написал с ошибкой). Ну и погуглив больше, вижу что в РФ у данного понятия может быть и иной смысл (иметь возможность НДС брать к зачёту). В РБ - по другому

(116) это не схема обмена. это просто описание общего.
схема обмена которая минимизирует оверстоки выглядит так примерно, основа: минимизация таймаута между изменением свободного остатка в базе и его появлением на витрине МП.
поэтому примерно так:
1. ПЕРЕД ЛЮБОЙ выгрузкой остатков на МП (по событию, регламентным заданием  по расписанию) - в обязательном порядке прочитать (время=Т1) и загрузить в базу заказы МП, обсчитать, провести (зарезервировать товар) - ИЗМЕНЯЕТСЯ СВОБОДНЫЙ ОСТАТОК в результате проведения заказов МП в базе, и тут же свободный остаток выгружается на МП и обновляется в МП (время = Т2). Таймаут = Т2-Т1 - чем он меньше - тем лучше.
2. При любом изменении свободного остатка в базе (время = Т3) (обнаружен брак, который не может быть продан, недостача итд, зарезервирован товар любым действием, изменение и перепроведенияе документа с изменившимяс количеством - изменившиеся свободные остатки тут же должны быть выгружены на МП - см.далее п.1
.
если выгрузка остатков выполняется одним регламентынм заданием, а загрузка заказов другим регламентным заданием - растут таймауты между изменением свободного остатка в базе и его обновлением в ЛК МП. и будет жпс.
.
я, конечно, могу нести ахинею, пусть тогда те кто плотно работают по МП - меня поправят.
.
пример:
остаток по базе = 20, выставлено на витрину ЛК = 20.
пришли три заказа, забрали их утром из ЛК в БАЗУ. Остаток на витрине = 17, остаток в базе = 17.
.
по расписанию раз в час остаток выгружается из базы в ЛК.
выгрузили 17 - в ЛК = 17. свалилось 10 заказов. остаток в ЛК = 7. Регламентом выгрузили остаток по базе = 17. Остаток в ЛК = 17, заказали 15, общий итог заказов = 10+15 = 25, в свободном остатке по базе = 17. 8 заказов получат внезапный отказ.
.
я так подробно пишу - размышляю просто, может кто еще поделиться мыслями...

(117) ВБ = это адская мусорка (не по ассортименту, а по автоматизации)

(118) автор из РБ, в РБ может все по другому...? ;-)
Хотя я сейчас в РБ - но в тоноксоти законодательства не смотрел ;-)
.
"Берестейские сани" будут в этом году в Пинске! или даже уже идут как раз в эти праздники.

(117) сорри неверно выразился, не 16 площадок, а 16 карточек товара, мп - несколько, на каждом - по несколько ип

(122) >"пришли три заказа, забрали их утром из ЛК в БАЗУ. Остаток на витрине = 17, остаток в базе = 17.
по расписанию раз в час остаток выгружается из базы в ЛК."

Вот здесь ошибка. Повторюсь, когда в ЛК ВБ появляется новый Заказ - ВБ сам уменьшает в кабинете остаток товара.
ПОэтому из 1с в ЛК ВБ не нужно выгружать при любом изменении остатка в 1с Новый остаток на площадку.
Новый остаток на площадку необходимо выгружать только если произошло списание (или резервирование) на складе НЕ маркетплейсу.

И когда у селлера один МП /как у нас только ВБ/ вероятность оверстока маленькая.
Если же несколько МП - тогда да /либо продажи в не МП велики и товарный ассортимент пересекается с МП/, сложность возрастает

(124) Через 12 дней )

(123) В чём сложность? Вроде как обычный сторонний покупатель, который в т.ч. и предлагает свою API для автоматизации процессов

(126) Неверно.
Остаток в базе = 20. остаток в ЛК = 20.
В ЛК заказали 8 шт., в ЛК висит остаток 12шт.
На складе обнаружили брак/недостачу 1шт, остаток НА СКЛАДЕ = 19шт. "Новый остаток на площадку необходимо выгружать только если произошло списание (или резервирование) на складе НЕ маркетплейсу." -  Согласно вашему регламенту выгружаем в ЛК остаток склада. Остаток в ЛК стал 19 шт. В ЛК заказали 14шт., остаток в ЛК = 5 шт. Итого: заказов с ВБ 8+14 = 22шт, остаток  по складу 19 шт. По 3 заказам клиент получит отлуп, карточки блокиру.тся, штрафы, блокируется ЛК полностью ну и прочие какие там штрафные санкции.
.
так что читайте внимательно 122 не вчасти как считает ВБ, а в части взвимодействия 1С и ЛК.

(128) по их АПИ и построению всяких обменных файлов.
но работает ну и хорошо...

(129) Естественно, что
"Выгружаемый остаток из 1с в ЛК" определяется как:
"остаток в 1с на текущий момент" Минус "не обработанный заказ в ЛК ВБ"

Поэтому проще перед выгрузкой остатков обработать все свежие заказы, а затем выгружать остатки.
п.с
Конечно если заказы падают каждую минуту - это сложнее ).
Но если "заказы падают каждую минуту" -тогда товар продавать по ФБС - преступление )

(131) когда товара "много" - проблемы не будет. а вот когда товара "мало" - то и 2-3 заказа в день на товар могут привести к проблеме. По моему опыту - например у меня таковые проблемы возникают исклбчительно из-за недоработок менеджеров (не делают что дОлжно) и недостаточной автоматизации (мало ресурса программиста)

(132) Да ну ), как-раз наоборот, я завидую 90% селлеров, которые держат на МП максимум пару десятков SKU. И тогда проще за ними следить.
А вот когда как у нас - их несколько сотен, уже заметно проблемней без автоматизации .

п.с. На почту получил мою обработку?

(132) "когда товара "много" - проблемы не будет. а вот когда товара "мало"

понял, ты про количество штук на остатке

(124) У ТС ник как-бы намекает, что он из Пинска :)

(135) А я то думал, что это за совпадения такие, что Злопчинский про Пинск начал писать )

(133) да, спсб

(136) я сейчас по семейным обстоятельствам большую часть времени в Беларуси