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

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

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

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

Во всей базе, или "в табличной части документа" - ?
Пока не понял вопроса, что мешает сдедать по принципу как в типовой торговле уникальность ШтрихКода контролируется?
Вот функция:

//******************************************************************************
// ПроверкаУникальностиШтрихкода()
//
// Параметры:
//  Ед - Единица измерения товара
//
// Возвращаемое значение:
//  Число:
//  0 - штрих-код не уникален
//  1 - штрих-код уникален
//
// Описание:
//  Просматриваются все единицы измерения всех ТМЦ. Если находится точно
//  такой же штрих-код, то функция возвращает 0, если нет, то функция
//  возвращает 1.
//
Функция ПроверкаУникальностиШтрихкода(Ед, Штрихкод, Описание="") Экспорт
    Перем ЕдиницаДляПоиска;
    Перем Результат;
    
    Результат = 1;    // изначально уникален
    
    Если ПустоеЗначение(Штрихкод) = 0 Тогда
        ЕдиницаДляПоиска = СоздатьОбъект("Справочник.Единицы");
        
        ЕдиницаДляПоиска.ВыбратьЭлементыПореквизиту("Штрихкод",Штрихкод,0,0);
        Пока ЕдиницаДляПоиска.ПолучитьЭлемент() = 1 Цикл
            
            ТекЕдиница = ЕдиницаДляПоиска.ТекущийЭлемент();
            
            // нашли штрихкод
            Если Ед.Выбран() = 1 Тогда
                // сохраненый элемент
                // проверим, а не является найденный текущим
                Если Ед <> ТекЕдиница Тогда
                    Результат = 0;
                КонецЕсли;
            Иначе
                // новый элемент
                Результат = 0;
            КонецЕсли;
            Если Результат = 0 Тогда
                Прервать;
            КонецЕсли;
        КонецЦикла;
    КонецЕсли;
    
    Если Результат = 0 Тогда
        ПометкаУд = "";
        Если ТекЕдиница.ПометкаУдаления() = 1 Тогда
            ПометкаУд = " (помечена на удаление) ";
        КонецЕсли;
        Описание = "Уже имеется единица измерения """ + ТекЕдиница + """ " + ПометкаУд + " со шрихкодом " + Штрихкод + " у номенклатуры """ + ТекЕдиница.Владелец + """!";
    КонецЕсли;
    
    Возврат Результат;
    
КонецФункции // ПроверкаУникальностиШтрихкода()

(0) как уникальный индекс, но к сожалению 1с такой признак на реквизит поставить не может.

Признак "Сортировка" у реквизита, это уже индекс. А уникальность сами контролируйте в функции, точно так-же, как для ШК выше..

(1) > "Признак "Сортировка" у реквизита, это уже индекс"

Это относится к справочнику.
А у меня реквизит (текстовое поле 10 знаков) табличной части документа.

(2) (текстовое поле 10 знаков) - а, вот теперь понятно, в чем сложность...

Как вариант, выгружать все табличные части доков в одну большую ТЗ, и сворачивать, по этому полю, плюс дополнительная колонка "Сверт", типа число. Сортировать потом по ней по убыванию, и контролировать, что число в первой строке не больше 1. Ну, это первое, что в голову пришло. А так, можно еще подумать.
Периодичность всего этого безобразия какая? Месяц, квартал, год, или все-всегда? Что-бы оценить примерное количество строк ТЗ.

Ну, или справочник под это дело добавить и контролировать как в (1). Даже можно без ссылки, просто код или наименование, а в доках строка и поиск этой строки в справочнике по коду или наименованию. Проще удалять будет не нужное, контроль ссылочной целостности не будет мешать. У меня примерно так акцизные марки алкашки хранятся, типа "внешняя база внутри базы".

мешанина сплошная.
вопрос из двух состоит
1. как контролировать уникальность заказа
а вы там кто - погромист или программист? у заказов с ВБ есть свой номер заказа (его уникальность - обеспечивается самим ВБ), который доступен что при загрузке заказов из файла (выгружаемого из ЛК), что при обмене с ВБ по API. Как вы этот ВБ-номер заказа при обмене пристегнете в свою базу, к каким объектам - мы же хз как там у вас в вашей нетленной самописке устроено. Пристегивайте так, чтобы (условно) - создавался новый если не найден или "пристегивался" к уже существующему если найден. Вопрос сугубо технический аккуратности программирования. Хотелка автора по типа "хреново напрограммлено, есть косяки поэтому давайте для хренового программирования придумаем нехреновую няшку" - мне не нравится. Это еще один костыл к кривым ранее созданным костылям..?

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

Не очень понял, что автор хотел. Если проверять некий Id заказа на уникальность, то значит в конфигурацию надо добавить сущность - справочник, имеющий реквизитом этот Id. Как уже выше написал коллега - что то подобное проверке штрихкода

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

Ответ: Никак. Вынести в шапку документа.

(7)Ответ-никак является неверным. При добавлении новой строки или (и) при записи можно проверить Id на существование в справочнике, который автор добавит. Можно и без справочника, например прямым запросом к табличным частям обсуждаемого документа

(6) Это не поможет. Грубо - есть резерв в котором в табличной части один заказ с уникальным ID. через копирование этого резерва мы создаём такойже новый документ, в котором будет этот-же ID заказ

(5) :)
> " Как вы этот ВБ-номер заказа при обмене пристегнете в свою базу, к каким объектам - мы же хз как там у вас в вашей нетленной самописке устроено"

Вроде написал, ID заказа /текстовое поле в 10 знаков/ - есть реквизит в табличной части резерва в 1с.
Не вижу в этом реализации ничего неправильного

(6) Не совсем это хотел. Завести справочник и в нём хранить ID заказов, которые будут уникальными - проблемы нет.
Проблема что во всех резервах любой Заказ должен использоваться только один раз.
А учитывая что манагеры могут руками создавать резервы, в т.ч. и через копирование то хотелось бы иметь быстрый способ контролировать эту уникальность.
Да - прямой запрос к табличной части, но не очень с ними дружу )

(5) > "запрет пользователеям "админских" функций управления заказами."

Конечно можно позапрещать всякие админские и полуадминские функции. В идеале - "не сделал с первого раза правильно - пошёл нафик" )
Пиши письмо админу чтобы он сам за тебя исправил твой косяк )

Поэтому я и написал про существующие СБД, которые умеют это контролить на низкой уровне. И понимаю, что в 1с такого нет, но может быть есть относительно не сложный метод его реализовать /прямые запросы к ТЗ к таким не отношу/

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

(3) > "Как вариант, выгружать все табличные части доков в одну большую ТЗ, и сворачивать"

Да, какбы вариант, но слишком много резервов в базе и наверное будет тормозить данная реализация, если штатными методами делать.
Но попробую реализовать и посмотрю

(13) > "ну вот обнаружил, что уникальность нарушена, и что? полегчало?"
Тогда 1с не должна:
-при создании такой ситуации сообщать юзеру и он станет искать ошибку
- не давать списать этот резерв.

конечно полегчает

(15) ну вот это "1с не должна..." уже более похоже на ТЗ.
Ну и прежде всего, нужно запрещать ставить в резерв.

Сейчас вот поразмыслил и понял, что наверное правильно сделать контроль при списании резерва, в этот момент выгружать все табличные части всех резервов в ТЗ и там смотреть уникальность.
Для ускорения этого процесса ограничиться определённым периодом /например месяц/ ну и другие фильтры придумать, т.е. выгружать только нужные резервы  с определённым признаком а не все

(16) >"Ну и прежде всего, нужно запрещать ставить в резерв."
Да так красивее, но сложнее реализовать и в разных местах придётся втыкать эту медленную функцию проверки (проведение резерва, копирование резерва, копирование строки внутри резерва, изменение самого ID заказа)

(18) только при проведении.

(19) верно, не подумал

Надо знать и понимать всю задачу. Но по ощущениям, ничего сложного тут нет.
Автор пишет "штатно и просто". Что за конфигурация и что это за штатность?) Общая идея дана. Прилетает новый Id, проверяй его в новом справочнике "Заказы", ничего в этом особо медленного нет. И при проведении. Вдруг за время обработки документа кто-то в свой документ включил такой же заказ.

(20) если сделать графу отбора по иду заказа в документе резерва - то поиск будет по 1scrdoc по индексу, т.е. даже черный запрос должен быть достаточно быстрый.

(21) Справочник Заказы - создавать смысла нет. само по себе ID - всегда уникальный. Его уникальность контролирует маркетплейс.

Поэтому этот ID реализован только как реквизит табличной части документа Резерв.
А вот при проведении резерва - да, придётся /насколько я понимаю другого более быстрого способа нет/
выгрузить табличную часть всех резервов (отфильтровав их по какимто признаком чтобы уменьшить их количество) в ТЗ и там проверять момент, чтобы каждый ID заказ встречался только один раз.
Думаю что эта проверка будет не быстрой, вот и подумал, а может есть другой хитрый способ.

(23)
1.маркетплейсов внезапно может стать больше одного...
2.ссылку через графу легче искать.

(12) не надо "админу" исправлять косяки которые может делать пользователь. Поеб..ся один раз над исправлением косяков вместес админом, который сиддит за спиной пьет чай и говорит что делать - потратит рабочий день - следующий раз херню не будет делать. Иногда достаточно на один раз поставить фирму раком, чтобы дальше все нормально летало. Дело "админа" позатыкать в коде тучу защит от дураков - если у админа есть время и делать больше нечего

(24) 1. Верно их и есть больше одного. и это контролируется через Реквизит уже в шапке резерва
2. Вот и не зря завёл тему. Про графу был не в курсе, буду знакомитися и пробовать

(14) Что значит "очень много резервов в базе"..? заказы от ВБ по ФБС живут 2-3 дня, по 100 заказов - ну пусть 1000 резервов в день будет. Да и хрен с ним. В ТиС резервов и заявок вагон и телега было, в день порядка 16000 строк - нихрена не тормозило.
Маетесь хренью...

(24) у меня в конторе - 4 ИП на каждом по 4 МП...
у каждого МП+ИП на товар свой артикул МП

(25) > "Дело "админа" позатыкать в коде тучу защит от дураков - если у админа есть время и делать больше нечего"

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

(27) "заказы от ВБ по ФБС живут 2-3 дня, по 100 заказов - ну пусть 1000 резервов в день будет."

Верно, по факту их не так много, как изначально казалось. Прсото хотелось бы реализацию сделать красиво через индекс, а не через выгрукзу всех ТЧ резервов в ТЗ.

(28) > "у каждого МП+ИП на товар свой артикул МП"

Это уже другая задача. Артикул МП - да, это подчинённый справочник номенклатуре.

(23) Заказы - создавать смысла нет. само по себе ID - всегда уникальный. Его уникальность контролирует маркетплейс.
Поэтому этот ID реализован только как реквизит табличной части документа Резерв."
..
не факт. надо смотреть чуть ширшее.
Возможно будут интересны статусы заказов.
Опять же есть возвраты заказов клиентом через почту не на МП, а сразу на поставщика.
..
и может быть удобнее иметь справочник типа ИД-ДокументЗаказав1С-Статус-Состояние и ряд операций делать через этот справочник как стартовая точка.
..
Пишите ТЗ.
Тогда программить намного легче.

А в чем тайный смысл нахождения ID заказа в табличной части? То есть - в табличной части может присутствовать несколько разных заказов?

Вангую, что это заказы от одного покупателя скорее всего. А в чем тайный смысл?? Некая "экономия" что-ли??

Как может быть в одном документе заказа 1С несколько разных заказов из ВБ??  ИМХО не вижу логики.

Или, получается так, что в РАЗНЫХ заказах 1С будет одинаковый заказ с ВБ. А как такое может быть?

ИМХО может быть как-то пересмотреть изначальный принцип работы? ;)

(33) Изначально не может. И если бы был один склад, то скорее всего и проблем бы не возникло. Но заказы формируются из остатков на 4х разных складах, иногда заказа падает на один склад, но затем руками нужно перекидывать на другой и вот в процессе такой работы из-за невнимательности ID заказ Вб может повториться в новом /созданном руками/ счёте а из исходного не удалится

(33) у меня в УТ сделает что каждый заказ мп жто отдельный документ заказ в УТ.
Но лично я чаще встречал что заказы одного дня - лежат в одном заказе в базе в ТЧ. У меня возможно это было связано с тем что это достаточно активные склады с большим количеством заказов в день были на проектах.
Навскидку если контейнером является ТЧ документа для заказа мп - я бы заказы группировал по дате отгрузки, а не по дате собственно щаказа мп, чисто что так удобнее для складской обработки, но это я подходу из концепци простой архитектуры заказов конфигурации. А так-то как я себе представляю дата о грудки и в ТЧ может быть и ордера бить по дате отгрузки в ТЧ, надо смотреть как выгоднее чисто с точки зрения уже сложившихся процессов итд

(34) а зачем руками? Кнопкой анализировать никак?

(36) Потомучто только манагер решает, с какого склада лучше продать этот заказ, если вдруг на исходном товаре не оказалось

Например манагер вчера закосячил и не списал вчерашние отгрузки на ФБС. И сегодня куча заказов упало на нулевой остаток на складе. Приходится их руками переносить на верные склады, только в ручном режиме. Вроде и простая операция, но можно и в ней ошибиться.
А учитывая что на ВБ при закрытии поставки в личном кабинете она падает в архив и восстановиться всё поставку целиком (и сколько и каких в ней было ID заказов) нельзя, то и сверятся в этом плане с ВБ уже не получается (т.е. проверить исходный дневной заказ  на 100 заказов уже нет возможности)

(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) я сейчас по семейным обстоятельствам большую часть времени в Беларуси