В центральную базу некоторым способом перекачиваются документы поступления. Непроведенными.
    
    Затем по обмену они попадают в нужные периферийные базы.
    В периферийной базе оператор проводит документ поступления тем самым подтверждая факт приемки товара.

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

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

Убрать движения из обмена?

(1) Может быть.
    Я в обменах разбираюсь слабо.
    А пробовать не на чем

В центральной базе движений нету.
  Там документ не проведен.
  Движения в обмене не участвуют.

  ТоварыНаСкладах выставлено "Запретить"

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

Более продвинутый вариант - регистрировать в приемнике документы на узле отложенной обработки и потом уже их оттуда забирать и проводить или отменять проведение

Если результат проведения (движения) в центре и периферии может быть разным (разная логика проведения), то первый вариант с добавлением движений в обмен не прокатит

Сейчас там вот что прописано:

Процедура ПриПолученииДанныхОтГлавного(ЭлементДанных, ПолучениеЭлемента, ОтправкаНазад)
    
    ТипДанных = ТипЗнч(ЭлементДанных);
    
    Если Найти(СокрЛП(ТипДанных), "Документ объект:") <> 0 Тогда
        Если ЭлементДанных.Проведен Тогда
            ЭлементДанных.Записать(РежимЗаписиДокумента.Проведение, РежимПроведенияДокумента.Неоперативный);
        КонецЕсли;
    КонецЕсли;

КонецПроцедуры

(7) Не красиво это написано.
И не совсем понятно, что будет после завершения обмена...

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

Посмотри, на всякий случай, в модулях объектов есть процедура ПередЗаписью ? И каким условием эта процедура начинается тоже посмотри

Т.е. получается, кладовщик подтвердил в периферийной базе приемку товара, путем проведения документа, а потом бац - он опять не проведен?
По-моему вот здесь не правильно.

Нужно вот в этой процедуре смотреть на то проведен или не проведен документ в периферийной базе. Если проведен, то запрещать получение из центра.

(9)
    Если ОбменДанными.Загрузка Тогда
        Возврат;
    КонецЕсли;

(11) вот это нарочно сделано, чтоб получаемые в обмене значение реквизитов и свойств не влияли ни на что.

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

(11) я бы предложил с похожим условием сделать подписку для интересных тебе объектов ПриЗаписи. И чистить там набор движений.

РежимЗаписи.ОтменаПроведения

(0)Ждите у себя в офисе кладовщика с ружьем...

(0) > Но при этом у непроведенного документа сохраняются движения которые видны в отчетах. Это неправильно.
Давно знакомая ситуация: с базе Источник документ помечают на удаление, в базе приемника он тоже помечается на удаление, но движения остаются. Чтобы они убирались в правилах обмена в обработчике "После загрузки объекта" вставляю:

Если Не ОбъектНайден И (ИмяТипаОбъекта = "Справочник" Или ИмяТипаОбъекта = "Документ") Тогда
    Отказ = Объект.ПометкаУдаления;
КонецЕсли;

// Чтобы проводок не оставалось у не проведенных и/или помеченных на удаление документов
Если ОбъектНайден И ИмяТипаОбъекта = "Документ" И Объект.Метаданные().Проведение = Метаданные.СвойстваОбъектов.Проведение.Разрешить И РежимЗаписи = "Запись" И Объект.Ссылка.Проведен Тогда
    РежимЗаписи = "ОтменаПроведения";
    Если Параметры.Комментировать Тогда
        Сообщить("Записан с отменой проведения: " + СокрЛП(Объект), СтатусСообщения.Информация);
    КонецЕсли;
КонецЕсли;

> Конфигурация УТ 11.1, но сам обмен самописный.
Может это не РИБ?

Попутно спрошу, недавно создал РИБ с фильтром по подразделению в УТ11.2 в периферийных базах пользователь с такими же правами как в общей центральной базе (тот же пользователь) ничего не может делать с клиент-банком, якобы из-за отсутствия нужных прав!? Дали все права кроме полных - не помогло. Пока дали полные права. Может так в РИБ задумано, что клиент-банк может работать только в центральной базе?

(16)Это не в РИБ так задумано, а в Клиент-банке или в твоей конфе. РИБ тут нипричем.

(16) Как конкретно ругается. Не на центральный узел?

Давайте начнём с того, что я вам напомню: РИБ - механизм платформы, в котором документ и его движения - автономны и независимы друг от друга. Пожалуй, на этом и закончу. Ваш к.э.п

Решили, что ПроведенныйВПериферийнойБазе обновляться не должен.

(17) > РИБ тут нипричем
Точно? Конфигурация вроде не измененная!?
(18) Сам пока не смотрел, вроде как "Не достаточно прав доступа"
(19) > РИБ - механизм платформы
Полный возможно, а СОтборами? Вроде все правила фильтрации в конфигурации, и зачастую не соответствуют самой конфигурации. Ее функционал ускакал вперед добавлены новые типы операций в документах, а в правилах фильтрации они не прописаны, и выпадают из обмена.

(21) А остальное в РИБ - это программная надстройка. Обмен "по организации", "по подразделениям", по прочим фильтрам - всё это программно цепляется на обработчики плана обмена, подписками конфигурации и т.д.

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

(20) кладовщики вам аплодируют

(20) А как сделать это решение программно уже нашли?

(24) см (10)

(25) это я понимаю,
только они могут не сразу найти, не сразу догадаться как прочитать состояние получаемого объекта ЭлементДанных в текущей базе (а не в пакете обмена) в той процедуре, что показана в (7)

(24) Еще нет.

подсказка "УИД"

(27)
1. получите ссылку из параметра ЭлементДанных
2. через точку прочитайте у ссылки свойство Проведен
:)

т.е. это будет существенное отличие от того кода что написан в (7)

ТипДанных = ТипЗнч(ЭлементДанных);
Если ТипДанных = Тип("ДокументОбъект.ПоступлениеТоваровУслуг") Тогда
    Ном = ЭлементДанных.Номер;
    Дат = ЭлементДанных.Дата;
    
    Док = Документы.ПоступлениеТоваровУслуг.найтиПоНомеру(Ном,Дат);
    Если НЕ Док.Пустая() и Док.Проведен Тогда
        ПолучениеЭлемента = ПолучениеЭлементаДанных.Игнорировать;
    КонецЕсли;
КонецЕсли;

А вот так (31) не получится ?

(0) так, как у вас сделано, делать нельзя было.
Вы одним документом в разных базах отражаете в учете разные события, которые еще и по времени разделены - отгрузку и приемку. Олимпийскому спокойствию склада вашего поражаюсь - у них фактически остатки при таком раскладе ни когда и ни при каких условиях не будут даже отдаленно напоминать остатки в учетной программе. Хотя, может у них на это и расчет?
Тут нужна ордерная схема или какая-то ее вариация. Отгрузка - один документ и обязательно проведенный, приемка - другой документ и тоже проведенный. Документы и ЦБ в ПФ (и наоборот) не должны ни как меняться, иначе при конкуррентных изменениях данные будете всегда менять.

(33) Может быть так оно и лучше, но я не уполномочен принимать такие ответственные решения.
     Мне бы разрулить сейчас, чтобы проведенный документ в периферийной базе не обновлялся.

фраза "Документы и ЦБ в ПФ (и наоборот) не должны ни как меняться, иначе при конкуррентных изменениях данные будете всегда менять."
в переводе на русский означает, что документы должны редактироваться только в тех узлах, в которых были созданы, иначе у вас всегда будет потеря данных, описанная в (0).

(34) в существующей схеме бизнес процесса это у тебя не получится

(36) Т.е. нельзя сделать так, чтобы проведенный документ не обновлялся из Центральной базы ?

Документы.ПоступлениеТоваровУслуг.найтиПоНомеру(Ном,Дат);

это конструкция вернет такую же Ссылку, как простое действие
ДокСсылка = ЭлементДанных.Ссылка

(37) можно. Сейчас скорректирую твой код

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

(39) т.е. в твоем коде в 31 уже будет работать, только ссылка в твоем объекте есть уже готовая, как в строке в 38 я написал

>> что документы должны редактироваться только в тех узлах, в которых были созданы

Интересная мысль конечно. Надо над этим подумать.

Процедура ПриПолученииДанныхОтГлавного(ЭлементДанных, ПолучениеЭлемента, ОтправкаНазад)


ТипДанных = ТипЗнч(ЭлементДанных);
Если ТипДанных = Тип("ДокументОбъект.ПоступлениеТоваровУслуг") Тогда
    
   Док = ЭлементДанных.Ссылка;

   Если НЕ Док.Пустая() и Док.Проведен Тогда
        ПолучениеЭлемента = ПолучениеЭлементаДанных.Игнорировать;
     КонецЕсли;
КонецЕсли;

КоецПроцедуры

Завтра опробую.
  Спасибо за подсказки :)

(43) и в результате после того, как документ попал проведенным в ЦБ, ни какие последующие изменения в нем, центральная база принимать не будет.
На это, как я уже сказал, нужен еще один костыль. Который тоже приведет к ситуации, на которую понадобится третий костыль

(45) не прав. В данном конкретном случае стоит вызов процедуры на конкретное событие ПриПолученииДанныхОтГлавного

Эта процедура сработает только в плане обмена с включенным РИБ в только на периферии

(46) тоже заэпись - в ЦБ внесут изменения и перепроведут. Что будет?

на складе отчаянные ребята работают

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

Кстати, надо бы Grekos2 предостеречь.
У него в коде нет еще вылавливания из обмена набора данных движений от этих документов. ПереПроведение документа в Центре может вернуть в периферию измененный набор движений регистра. ТЧ будет в периферии на одну сумму и количество, а из центра приедут другие движения.

// не должны заходить.
не должны заходить из центра повторно.

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

(51) есть у революции начало - нет у революции конца

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

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

А ИТ-рукля нет в конторе. Пичальбида...