Тюнинг
1с оперативное и неоперативное проведение. Особенности работы формы документа. Автоматические и управляемые блокировки

1с оперативное и неоперативное проведение. Особенности работы формы документа. Автоматические и управляемые блокировки

Установка даты документа при открытии формы

Если дата документа изначально не установлена, то при открытии формы нового документа происходит установка дате документа значения текущей даты сеанса.

Причем время документа будет установлено в зависимости от следующих настроек. Если свойство АвтоВремя расширения формы документа имеет значение НеИспользовать то время документа будет установлено по значению текущей даты сеанса. В остальных случаях дате документа присваивается время начала дня (00:00:00).

Установка даты нового документа при записи нового документа в форме

При записи документа в режиме оперативного проведения значение даты документа устанавливается согласно выданной оперативной отметке времени. Тут настройки свойств расширения формы не играют роли.

Но если время документа "нулевое" (0:00:00), то при неоперативном проведении документа оно будет изменено согласно настройкам свойства АвтоВремя. Исключение - когда АвтоВремя имеет значение НеИспользовать тогда время документа не меняется.

Запрет интерактивной записи проведенного документа без проведения (перепроведения)

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

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

Предотвращение подобных ситуаций достигается за счет установки свойства расширения формы документа ПриЗаписиПерепроводить значение Истина. Тогда отказ в обработке проведения приведет к откату транзации - документ не будет и перезаписан.

Установка режима проведения

При проведении документа из формы система проверяет наличие у пользователя соответствующих прав (Проведение, Интерактивное проведение, Интерактивное проведение неоперативное). Если их нет, то выдается сообщение о невозможности проведения документа, и запись с проведением документа из формы отменяется. Мы будем рассматривать только возможность отсутствия/наличия прав на неоперативное проведение, в зависимости от которого система может менять свое поведение, так как если нет первых двух прав, то документ не может быть проведен из формы в принципе.

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

При записи документа из формы расширение формы документа выполняет установку режима проведения документа.

Для реализации данного функционала система использует вариант (Автоматически, Оперативный, Неоперативный, Запрашивать ) указанный в качестве значения свойства ИспользоватьРежимПроведения расширения формы документа.

Вариант "Автоматически"

Вариант Автоматически Автоматически у свойства ИспользоватьРежимПроведения расширения формы документа. Платформа стандартно устанавливает это значение для новой формы.

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

Для проводимого документа происходит проверка положения даты документа относительно текущей даты сеанса.

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

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

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

Вариант "Оперативный"

Вариант Оперативный устанавливается посредством выбора значения Оперативный у свойства ИспользоватьРежимПроведения расширения формы документа.

В данном варианте, если дата документа (без учета времени) меньше текущей даты сеанса, выдается предупреждение: "Дата оперативно проводимого документа меньше текущей. Документ не может быть проведен оперативно!", и проведение документа отменяется.

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

Если дата документа (без учета времени) больше текущей даты сеанса, выдается предупреждение: "Дата оперативно проводимого документа больше текущей. Документ не может быть проведен оперативно!", и проведение документа отменяется.

Вариант "Неоперативный"

Вариант Неоперативный устанавливается посредством выбора значения Неоперативный у свойства ИспользоватьРежимПроведения расширения формы документа.

При испльзовании данного варианта проведение документа из формы всегда производится в неоперативном режиме, независимо от положения даты документа по отношению к текущей дате сеанса.

При этом еслу у пользователя нет права на неоперативное проведение, выдается предупреждение: "Недостаточно прав для неоперативного проведения", и проведение документа отменяется.

Вариант "Запрашивать"

Вариант Запрашивать устанавливается посредством выбора значения Запрашивать у свойства ИспользоватьРежимПроведения расширения формы документа.

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

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

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

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

Если дата документа (без учета времени) меньше текущей даты сеанса, поведение системы определяется опять же наличием права на неоперативное проведение у пользователя. Если пользователь таким правом не обладает, выдается предупреждение: "Дата оперативно проводимого документа меньше текущей. Документ не может быть проведен оперативно!", и проведение документа отменяется.

Если право на неоперативное проведение есть, пользователю выдается диалог с режимом выбора проведения. После выбора неоперативного режима проведения система проводит документ в неоперативном режиме. Если же пользователь выберет оперативный режим проведения, выдается предупреждение: "Дата оперативно проводимого документа меньше текущей. Документ не может быть проведен оперативно!", и проведение документа отменяется.

Если дата документа (без учета времени) больше текущей даты сеанса, система не позволяет проводить документ оперативно. Поэтому если права неоперативного проведения нет, сразу выдается предупреждение: "Дата оперативно проводимого документа больше текущей. Документ не может быть проведен оперативно!", и проведение документа отменяется.

Если право на неоперативное проведение есть, пользователю выдается диалог с режимом выбора проведения. После выбора неоперативного режима проведения система проводит документ в неоперативном режиме. Если же пользователь выберет оперативный режим проведения, будет выдано предупреждение: "Дата оперативно проводимого документа больше текущей. Документ не может быть проведен оперативно!", и проведение документа отменится.

Прочие функции

Кроме выбора режима проведения и установки даты документа, расширение формы документа реализует также следующий функционал:

при открытии формы проведенного документа, если у пользователя нет права Интерактивное изменение данных форма переводится в режим ТолькоПросмотр;
при открытии формы документа, в которой находятся таблицы, отражающие движения основного реквизита (объекта документа), эти движения автоматически считываются из базы данных и отображаются;
при записи из формы (даже если и программной - посредством Записать() ) система выполняет проверку прав на интерактивное проведение или интерактивную отмену проведения.

Различают оперативное и неоперативное проведение документов; возможность неоперативного проведения регулируется соответствующей опцией в настройках документа:

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

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

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

Вопрос 01.50 экзамена 1С:Профессионал по платформе. При каких условиях необходима установка свойства "Оперативное проведение" документа в значение "Запретить"?

Когда документ ориентируется на проведение в реальном (настоящем) времени.
Когда документ ориентируется на проведение будущим временем

Правильный ответ четвертый. Если документ предполагается всегда проводить будущей датой, то оперативное проведение тут точно не нужно.

Вопрос 01.51 экзамена 1С:Профессионал по платформе. При каких условиях необходима установка свойства "Оперативное проведение" документа в значение "Разрешить"?

Когда документ ориентируется на проведение в реальном (настоящем) времени.
Когда проведение документа не зависит от времени его регистрации.
Когда документ ориентируется на проведение прошлым временем ("задним числом").
Когда документ ориентируется на проведение будущим временем.

Правильный ответ первый, см. выше.

Вопрос 12.10 экзамена 1С:Профессионал по платформе. Оперативный режим проведения документа используется:

Только при работе с регистрами сведений
Только при работе с регистрами накопления
Только при работе с регистрами бухгалтерии
Только при работе с регистрами расчета
Не зависит от вида регистра

Правильный ответ пятый. Безотносительно вида регистра, нужно либо учитывать, либо не учитывать его состояние в момент формирования записей.

Вопрос 12.54 экзамена 1С:Профессионал по платформе.

Правильный ответ первый, все очевидно из скриншота.

Вопрос 12.55 экзамена 1С:Профессионал по платформе. Опишите действия системы при попытке провести документ?

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

Правильный ответ первый. Оперативное проведение - это проведение текущими датой-временем.

Вопрос 12.56 экзамена 1С:Профессионал по платформе. Опишите действия системы при попытке провести документ?

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

Правильный ответ первый. Записи будут сделаны текущими датой-временем.

Вопрос 12.60 экзамена 1С:Профессионал по платформе. Опишите действия системы при попытке провести документ?

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

Правильный ответ первый - раз документ уже проведен, системе нужно понимать, каким временем проводить документ - текущим или временем документа.

Вопрос 12.63 экзамена 1С:Профессионал по платформе. Опишите действия системы при попытке провести документ?

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

Правильный ответ первый. Оперативно перепровести не получится, движения уже созданы.

Вопрос 12.66 экзамена 1С:Профессионал по платформе. Опишите действия системы при попытке провести документ?

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

Первый ответ.

Вопрос 12.57 экзамена 1С:Профессионал по платформе. Какие условия предметной области могут повлиять на установку свойства "Оперативное проведение" документа в значение "Разрешить"?

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

Правильный ответ первый, см.об оперативном режиме в посте.

Вопрос 12.58 экзамена 1С:Профессионал по платформе. В каких режимах может проводиться документ, если свойство "Оперативное проведение" установлено в значение "Запретить"?

Только в режиме "Неоперативный"
Только в режиме "Оперативный"
Как в режиме "Оперативный", так и "Неоперативный"

Правильный ответ очевидно первый.

Вопрос 12.59 экзамена 1С:Профессионал по платформе. В каких режимах может проводиться документ, если свойство "Оперативное проведение" установлено в значение "Разрешить"?

Как в режиме "Оперативный", так и в режиме "Неоперативный"
Только режиме "Оперативный"
Только в режиме "Неоперативный"

Первый вариант.

Вопрос 12.65 экзамена 1С:Профессионал по платформе. В каких режимах может проводиться документ, если свойство "Оперативное проведение" установлено в значение "Запретить"?

Можно проводить прошлым периодом
Можно проводить будущим периодом
Можно проводить текущим периодом
Верны варианты 1 и 2
Верны варианты 1 и 3
Верны варианты 1, 2 и 3

Правильный ответ шестой, неоперативное проведение подразумевает проведение в любой нужный момент.

Вопрос 12.67 экзамена 1С:Профессионал по платформе. При повторном проведении документа в регистре:

Старый набор записей всегда автоматически удаляется и на его место записывается новый
Набор записей в регистре остается без изменений
Поведение набора записей определяется разработчиком в конфигураторе через настройки и программный код
Поведение набора записей определяется пользователем в зависимости от выбранного режима проведения (оперативный или неоперативный)

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

Вопрос 12.68 экзамена 1С:Профессионал по платформе. При включенном в конфигураторе режиме "Оперативное проведение разрешить"?

Документ можно проводить с текущей датой и текущим временем
Документ можно проводить с любой произвольной датой
Документ можно проводить либо предыдущей датой, либо с текущей датой и текущим временем

Правильный ответ третий. Предыдущей датой документ будет проведен неоперативно.

Вопрос 12.73 экзамена 1С:Профессионал по платформе. В каких режимах может проводиться документ, если свойство "Оперативное проведение" установлено в значение "Запретить"?

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

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

Для тех, кто работал с конфигурациями 1С, в которых ведется оперативный учет, скорее всего, знакома форма, которая показана на рисунке. Документ проводится сегодняшним числом, и программа 1С предлагает 2 варианта проведения этого документа. Рассмотрим, что же означают эти режимы проведения документов...

Где применяется?

1С:Управление торговлей 10.3
1С:Управление производственным предприятием 1.3
1С: Комплексная автоматизация 1.1

Оперативное проведение документа 1С

Оперативно проводить можно только документы за сегодняшний день.
Оперативное проведение документа 1С выполняется в текущий момент времени. Даже если документ был создан сегодня, несколько часов назад, при оперативном проведении этого документа, время этого документа поменяется на текущее.
При оперативном проведении в большинстве конфигураций выполняется проверка на наличие остатков. Если к примеру, на складе нет остатка, то товарный документ не проведется.
Невозможно оперативно провести документ будущей датой.

Неоперативное проведение документа 1С

Неоперативно можно провести документ за любую дату, при этом дата и время документа не изменятся.
При неоперативном проведении остатки могут не контролироваться. Например, документ проводится, но при этом выдает сообщение об отсутствии товара на складе.

Для внедренцев, которые работают с типовыми или собственными конфигурациями – и тех, кто готовится к Аттестации на 1С:Специалист по платформе.

В статье мы разберем:

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

Время на прочтение – 20 минут.

Итак, две методики контроля остатков в 1С:Предприятии 8.3

Давайте начнем с того, что обозначения “старая методика” и “новая методика” достаточно условны. В самом деле, если “новая методика” используется с 2010 года – она уже не очень новая:)

Однако, мы еще раз вынуждены на этом остановиться, потому что различать эти подходы нужно и это имеет критическое значение .

“Старая методика” – это подход к контролю остатков, который использовался со времен «1С:Предприятие 8.0».

C 2010 года, с развитием платформы и добавлением новых возможностей с «1С:Предприятие 8.2» – применяется “новая методика” (однако – не везде ).

В чем разница?

Принципиальная разница – в моменте контроля остатков:

В “старой” методике остатки контролируются ДО записи движений в регистры.
Сначала проверяем остатки, если остатков “не хватает” (будут возникать отрицательные остатки) – проводить документ не будем
В “новой” методике – контроль происходит ПОСЛЕ записи движений, то есть постфактум.
Если после проведения образовались отрицательные остатки – нужно «откатить» транзакцию, то есть отменить проведение документа.

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

Ok, значит, старая методика ушла в прошлое и это удел УТ 10.3?

Нет, это не совсем так.

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

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

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

Например, вот так:

Однако встречаются конфигурации, где и количество, и стоимость учитываются на одном регистре. И вот здесь-то обоснованно остается работать старая методика контроля остатков !

Вот пример одного регистра и для количества, и для себестоимости:

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

Не всегда!

Вот, например, в «1C:Управление торговлей 11.3» есть 2 регистра:

При проведении документов отгрузки регистр «Себестоимость товаров» не заполняется вообще. Данные в этот регистр попадают только при выполнении регламентных операций по закрытию месяца.

В УТ 11 используется новая методика , так как все данные для проведения документов можно получить, не обращаясь к контролируемым регистрам.

Что касается «1C:Бухгалтерии», то там и количество, и себестоимость хранятся в одном регистре бухгалтерии, на соответствующих счетах БУ.

Поэтому в БП 3.0 используется старая методика .

Обратите внимание, что количественный и стоимостной учет в УТ 11 ведутся с разной аналитикой. Например, себестоимость дополнительно ведется в разрезе организации, подразделения, менеджера, виды деятельности НДС и так далее.

В рамках текущей статьи мы разберем блокировки и для старой, и для новой методики контроля остатков.

Про оперативное проведение документов

В этом простом вопросе часто встречаются заблуждения.

Иногда считают, что оперативное проведение – это контроль остатков по новой методике. Это не так, от слова «совсем».

Оперативное проведение можно анализировать при контроле остатков, но не обязательно.

Оперативное проведение – это возможность документа регистрировать возникающие события здесь и сейчас, то есть в реальном времени.

Настраивается оно с помощью специального свойства документа:

Что значит «регистрировать здесь и сейчас»? Платформа для оперативно проводимых документов выполняет ряд действий:

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

Но главное другое – система передает признак оперативности проведения документа в обработку проведения:

Для оперативно проводимых документов можно не указывать параметр в запросе, будут получаться актуальные остатки на 31.12.3999 год:

Актуальные остатки хранятся в системе и получаются максимально быстро (остатки на другие даты в большинстве случаев получаются расчетным путем).

Таким образом оперативное проведение можно принять и для старой, и для новой методики контроля остатков .

Интересный факт.

В УТ 11 документам, списывающим номенклатуру, запрещено проводиться оперативно. Например, это документы «Реализация товаров и услуг», «Сборка товаров», «Перемещение товаров», «Внутреннее потребление товаров» и другие.

Почему так сделано?

В системе контроль остатков всегда выполняется на актуальный момент времени (параметр Период в запросе не задается). А отсутствие оперативного проведения позволяет вводить документы будущим числом, такая задача часто требуется клиентам.

Контроль остатков по новой методике – без блокировок

Коротко рассмотрим алгоритм контроля остатков при проведении документа «Реализация товаров и услуг» на модельной конфигурации.

Есть два регистра:

Свободные остатки – для количественного учета
Себестоимость товаров – для учета себестоимости

Для контроля остатков товаров достаточно работы с регистром «Свободные остатки».

Код обработки проведения будет выглядеть таким образом:

Запрос = Новый Запрос;

#Область Область1
Запрос.МенеджерВременныхТаблиц = Новый МенеджерВременныхТаблиц;
#КонецОбласти

// 4. Запись движений в БД
#Область Область4
Движения.Записать();
#КонецОбласти

#Область Область6
МоментКонтроляОстатков =
?(Режим = РежимПроведенияДокумента.Оперативный,
Неопределено,
Новый Граница(МоментВремени(), ВидГраницы.Включая));
Запрос.УстановитьПараметр("МоментВремени", МоментКонтроляОстатков);
РезультатЗапроса = Запрос.Выполнить();
#КонецОбласти

#Область Область7
Если НЕ РезультатЗапроса.Пустой() Тогда
Отказ = Истина;
ВыборкаОшибки = РезультатЗапроса.Выбрать();
Пока ВыборкаОшибки.Следующий() Цикл
Сообщение.Текст = "Недостаточно товара в количестве: "+ВыборкаОшибки.Дефицит;
Сообщение.Поле = "Товары["+(ВыборкаОшибки.НомерСтроки-1)+"].Количество";
Сообщение.Сообщить();
КонецЦикла;
КонецЕсли;
#КонецОбласти

#Область Область8
Если Отказ Тогда
Возврат;
КонецЕсли;
#КонецОбласти

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

Рассмотрим ключевые точки алгоритма контроля остатков.

1. Инициализация менеджера временных таблиц

Менеджер будет необходим, чтобы созданная в запросе временная таблица была доступна и в следующих запросах.

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

2. Запрос, группирующий данные табличной части

В запросе выбираются сгруппированные данные табличной части.

Обратите внимание, что выбирается и номер строки документа – он потребуется для контекстной привязки сообщения об ошибке. Для номера строки используется агрегатная функция МИНИМУМ() – то есть сообщение будет привязано к первой строке, где встречается указанная номенклатура.

В первом запросе пакета создается временная таблица. Во втором запросе выбираются данные временной таблицы и добавляются 2 поля, необходимые для каждой записи регистра – Период и ВидДвижения.

Плюсы такого подхода:

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

Кстати, подобный подход используется в типовых конфигурациях, в частности, в УТ 11 и БП 3.0.

4. Запись движений в БД

Запись можно было бы выполнить одной командой (вместо двух) – Движения.СвободныеОстатки.Записать().

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

Но более универсальным является такой подход:

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

После выполнения команды «Движения.Записать()» флаг Записывать у всех наборов сбросится в Ложь.

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

В типовых решениях используется подобная схема для записи движений. Почему?

Метод Записать() коллекции Движения записывает наборы записей в одинаковой последовательности даже для разных документов.

Запись же движений вручную может привести к проблемам.

Приведем пример.

Если в документе «Реализация» выполнить запись так:

Движения.СвободныеОстатки.Записать();
...
Движения.СебестоимостьТоваров.Записать();

А в документе «Перемещение товаров» изменить порядок:

Движения. СебестоимостьТоваров.Записать();
...
Движения. СвободныеОстатки.Записать();

То это может привести к взаимоблокировке документов на пересекающихся наборах номенклатуры.

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

5. Запрос, получающий отрицательные остатки

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

Отрицательный остаток – это и есть нехватка (дефицит) товара.

Соединение с товарами из документа выполняется только для получения номера строки.

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

6. Определение момента времени для контроля остатков

Вот здесь нам пригодилось оперативное проведение.

Если документ проводится оперативно, то момент для получения остатков – Неопределено, что означает получение актуальных остатков.

Если это неоперативное проведение, то мы получаем момент времени «после» документа – чтобы учесть только что сделанные движения.

Напомним, что получение актуальных остатков – быстрая операция по сравнению с получением остатков на произвольным момент времени.

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

7. Если запрос не пустой, значит, образовались отрицательные остатки

В цикле обходим все отрицательные остатки и выводим сообщение привязанной к строкам табличной части.

Вот так будет выглядеть диагностическое сообщение:

8. Если есть ошибки, то возвращаемся из обработчика события

Если была хоть одна ошибка – выходим из процедуры.

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

Реализация списания себестоимости по партиям

После того, как проверка остатков прошла успешно, можно приступать к списанию партий.

Код для списания по FIFO будет таким:

// I. Анализ смещения даты документа вперед

И НЕ ЭтотОбъект.ЭтоНовый()
И ЭтотОбъект.Проведен Тогда

Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| Документ.Дата КАК Дата
|ИЗ
|ГДЕ

РезультатЗапроса = Запрос.Выполнить();
ВыборкаДокумент.Следующий();

Иначе
Ложь);
КонецЕсли;

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

Процедура ПриЗаписи(Отказ)

ЭтотОбъект.ДополнительныеСвойства.Вставить("ДатаДокументаСдвинутаВперед",
ЭтотОбъект.Дата>

КонецЕсли;

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

Процедура ОбработкаПроведения(Отказ, Режим)

Запрос = Новый Запрос;

// 1. Инициализация менеджера временных таблиц
#Область Область1
...
#КонецОбласти

// 2. Запрос, группирующий данные табличной части
#Область Область2
...
#КонецОбласти

// 4. Запись движений в БД
#Область Область4
...
#КонецОбласти

// 5. Запрос, получающий отрицательные остатки
#Область Область5
...
#КонецОбласти

// 6. Определение момента времени для контроля остатков
#Область Область6
...
#КонецОбласти

// 7. Если запрос не пустой, значит образовались отрицательные остатки
#Область Область7
...
#КонецОбласти

// 8. Если есть ошибки, то возвращаемся из обработчика события
#Область Область8
...
#КонецОбласти

// II. Подготовка наборов записей регистра "Себестоимость товаров"
#Область ОбластьII

Движения.Записать();
КонецЕсли;
Движения.СебестоимостьТоваров.Записывать = Истина;
#КонецОбласти

// IV. Цикл по номенклатуре документа
#Область ОбластьIV

// V. Получим количество для списания
// VI. Цикл по партиям по FIFO
Пока ВыборкаПартии.Следующий() И ОсталосьСписать>0 Цикл
// VII. Проверка на нулевой остаток
Если ВыборкаПартии.КоличествоОстаток=0 Тогда
Продолжить;
КонецЕсли;
Движение.Период = Дата;

// VIII. Расчет количества и суммы для списания

// IX. Уменьшим количество для списания
КонецЦикла;
КонецЦикла;
#КонецОбласти

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

Разберем ключевые точки алгоритма списания партий по FIFO.

I. Анализ смещения даты документа вперед

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

Для анализа сдвига даты документа потребуется 2 события:

Перед записью – для получения старой даты документа и проверки режима проведения документа
При записи – для получения новой даты документа

Данные между событиями передаем через специальную коллекцию объекта – «ДополнительныеСвойства». Она существует пока текущая версия объекта находится в памяти, то есть доступна для всех событий при проведении.

Похожий прием используется в типовой «1С:Бухгалтерии 8». Но там используется одно событие «Перед записью».

Почему в БП не нужно задействовать «При записи»?

Всё просто – документы отгрузки в бухгалтерии не могут проводиться оперативно. А это значит, что время документа не будет принимать оперативную отметку (если документ перепроводится текущим днем), поэтому и старую и новую дату документа можно получить в событии «Перед записью».

II. Подготовка наборов записей регистра «Себестоимость товаров»

Для документа установлен режим удаления движений – “При отмене проведения”:

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

Приведем пример:

Остаток мониторов LG на момент проведения документов – 10 шт.
Проводится документ, который списывает 8 шт.
В этом же документе время увеличивается на 1 минуту, перепроводим

Если не будет удаления старых движений, то система сообщит о нехватке 6 мониторов, поскольку текущие движения документа уже списали 8 из 10 имеющихся мониторов.

Примечание. Иногда встречается совет – удалять движения только при оперативном проведении.

Но это неправильно: ситуации изменения «неоперативных» документов (вчерашних и более ранних) они не учтут.

То есть проблема «нехватки 6 мониторов» (см. выше) будет в этом случае решена только для документов изменяемых сегодняшним числом.

III. Запрос, получающий остатки партий для списания по FIFO

В запросе обращаемся к остаткам по партиям, при этом накладываем итоги по номенклатуре.

На уровне итогов получается количество из документа – МАКСИМУМ(Количество) и остаток партии – СУММА(КоличествоОстаток).

Как Вы думаете, может ли количество из документа превышать суммарный остаток номенклатуры по всем партиям?

Если движения по регистрам “СвободныеОстатки” и “СебестоимостьТоваров” по количеству делаются синхронно (и приход, и расход), то такой ситуации возникнуть не может. На это мы и будем закладываться при списании партий.

IV. Цикл по номенклатуре документа

Благодаря итогам в запросе во внешнем цикле обходим номенклатуру из документа.

V. Получим количество для списания

Запомним, какое количество нужно списать. Далее это количество будет уменьшаться.

VI. Цикл по партиям по FIFO

Вложенный цикл будет содержать партии по текущей номенклатуре.

VII. Проверка на нулевой остаток

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

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

VIII. Расчет количества и суммы для списания

Количество для списания - это минимальное значение между остатком партии и тем, что осталось списать.

Сумма рассчитывается элементарной пропорцией.

Если списывается весь остаток партии, то будет списана и вся сумма этой партии. Это математика 3-го класса церковно-приходской школы: Х*Y/X = Y:)

То есть НЕ нужно делать дополнительных проверок (иногда дают такой совет) на то, что списывается все количество. Этот совет даже имеет своё название – «проблема копеек ».

А тем, кто дает вредные советы имеет смысл заглянуть в конфигурацию «1С:Бухгалтерия 8». Там (о, ужас!) нет проверки на то, что списывается партия целиком:)

Вот скрин общего модуля «Учет товаров», метод «СписатьОстаткиТоваров»:

IX. Уменьшим количество для списания

Нужно понять, сколько еще осталось списать. Для этого вычтем количество из движения регистра.

Зачем нужны управляемые блокировки?

Вот мы и дошли до управляемых блокировок.

Казалось бы, представленные выше алгоритмы работают, как часы. Можете сами их потестировать (ссылки на выгрузки баз в конце статьи).

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

Приведем пример наиболее типичной проблемы при списании товара, когда 2 пользователя практически одновременно пытаются списать товар (оформить продажу):

В этом примере два пользователя почти одновременно проводят продажу товаров – документ №2 начал проводиться чуть позже документа 1.

При получении остатка система сообщает, что остаток 10 шт., и оба документа успешно проводятся. Печальный итог – на складе минус 5 мониторов LG.

Но при этом контроль остатков работает! То есть, если документ №2 будет проводиться после окончания проведения документа №1, система не проведет документ №2:

Иногда встречается заблуждение – «У меня в базе одновременно работают только 3-4 пользователя, вероятность параллельного проведения документов равна нулю, поэтому на блокировки можно не отвлекаться».

Это очень опасное рассуждение .

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

Кроме этого, нельзя быть застрахованным от увеличения количества пользователей. Если бизнес пойдет «в гору», то нужны будут новые продажники, кладовщики, логисты и так далее. Поэтому нужно сразу создавать решения, которые будут устойчиво работать в многопользовательской среде.

Как решить проблему при параллельном проведении документов?

Решение простое – заблокировать мониторы LG в момент времени Т1, так чтобы другие транзакции не могли обратиться к остаткам по этому товару.

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

Буквально пару слов о классификации блокировок.

Существует 2 типа блокировок:

Объектные
Транзакционные .

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

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

В этой статье нас будут интересовать именно транзакционные блокировки, далее просто блокировки.

Когда нужно накладывать блокировки?

Задача установки блокировок становится актуальной, как только в базе начинает работать более одного пользователя .

Блокировки нужно устанавливать в транзакциях, а когда возникают транзакции? Правильно, самый частый случай – проведение документов.

То есть блокировки нужно накладывать при проведении всех документов?

Ни в коем случае. Устанавливать блокировки «на всякий случай» точно не стоит . Ведь сами по себе блокировки снижают параллельность работы пользователей (масштабируемость системы).

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

В примере выше таким ресурсом является остаток по товару. Система должна была заблокировать остаток с момента получения данных об остатке (Т1) до окончания транзакции (Т3).

Примечание. Транзакция при проведении документа №1 начинается раньше, чем момент получения остатков. Но для простоты считаем, что Т1 – и время начала проведения документа, и момент получения остатков.

Пример, когда не нужно накладывать блокировку – проведение документа «Поступление товаров». В этом случае нет никакой конкуренции за ресурсы (остатки, …), поэтому блокировка будет вредна: она уменьшит масштабируемость системы.

Автоматические и управляемые блокировки

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

Вместо теории можем привести пруф – все современные типовые конфигурации работают на управляемых блокировках.

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

Управляемые блокировки в новой технологии контроля остатков

Блокировку будем накладывать на регистр “Свободные остатки” и только на номенклатурные позиции, встречающиеся в документе.

Причем правильный вариант наложения блокировки – как можно позднее.

В новой методике контроля остатков это нужно сделать перед записью (или в момент записи) движений в регистр “Свободные остатки”, чтобы другие транзакции не смогли изменить этот разделяемый ресурс.

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

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

Нужно просто установить свойство БлокироватьДляИзменения у набора записей регистра:

// 3.1. Блокировка остатков регистра
#Область Область3_1
Движения.СвободныеОстатки.БлокироватьДляИзменения = Истина;
#КонецОбласти

// 4. Запись движений в БД
#Область Область4
Движения.СвободныеОстатки.Записывать = Истина;
Движения.Записать();
#КонецОбласти
...

В результате 2 транзакции не смогут изменять свободные остатки по одной номенклатуре.

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

Но для нашей статье принципиально следующее – система установит блокировку на комбинацию записываемых в регистр данных. А детально работу свойства БлокироватьДляИзменения мы рассмотрим в отдельной статье.

Кстати, в типовой УТ 11 не так-то просто найти установку свойства БлокироватьДляИзменения для регистра “Свободные остатки”. Дело в том, что это выполняется в модуле набора записей регистра, в событии “Перед записью”.

Вот и всё, одной строкой кода была обеспечена корректная работа системы!

Важно . Мы не накладываем блокировку на регистр “Себестоимость товаров”.

Почему? Такая блокировка являлась бы излишней (а это определенная нагрузка на сервер 1С), поскольку движения в регистры “Свободные остатки” и “Себестоимость товаров” выполняются всегда синхронно, то есть последовательно друг за другом.

Поэтому, заблокировав товары из “Свободных остатков”, мы не допустим другие транзакции до этих товаров и в регистре “Себестоимость товаров”.

Но для старой методики контроля остатков блокировка будет накладываться по-другому. Для начала разберем алгоритм партионного списания для этого случая.

Старая методика контроля остатков

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

Пусть это будет регистр “Себестоимость товаров”:

Тогда алгоритм проведения документа “Реализация товаров” будет выглядеть вот так:

// 1. Обработчик события "Перед записью"
Процедура ПередЗаписью(Отказ, РежимЗаписи, РежимПроведения)

Если РежимЗаписи = РежимЗаписиДокумента.Проведение
И НЕ ЭтотОбъект.ЭтоНовый()
И ЭтотОбъект.Проведен Тогда

Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| Документ.Дата КАК Дата
|ИЗ
| Документ.РеализацияТоваровУслуг КАК Документ
|ГДЕ
| Документ.Ссылка = &Ссылка";
Запрос.УстановитьПараметр("Ссылка", ЭтотОбъект.Ссылка);
РезультатЗапроса = Запрос.Выполнить();
ВыборкаДокумент = РезультатЗапроса.Выбрать();
ВыборкаДокумент.Следующий();

ЭтотОбъект.ДополнительныеСвойства.Вставить("СтараяДатаДокумента", ВыборкаДокумент.Дата);

Иначе
КонецЕсли;

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

Процедура ПриЗаписи(Отказ)

Если НЕ ЭтотОбъект.ДополнительныеСвойства.Свойство("ДатаДокументаСдвинутаВперед") Тогда

ЭтотОбъект.ДополнительныеСвойства.Вставить("ДатаДокументаСдвинутаВперед",
ЭтотОбъект.Дата>ЭтотОбъект.ДополнительныеСвойства.СтараяДатаДокумента);

Сообщить(ЭтотОбъект.ДополнительныеСвойства.ДатаДокументаСдвинутаВперед);
КонецЕсли;

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

Процедура ОбработкаПроведения(Отказ, Режим)

// 2. Удаление "старых" движений документа
Если ДополнительныеСвойства.ДатаДокументаСдвинутаВперед Тогда
Движения.СебестоимостьТоваров.Записывать = Истина;
Движения.СебестоимостьТоваров.Очистить();
Движения.Записать();
КонецЕсли;

// 3. Установка флага для записи движений в конце транзакции
Движения.СебестоимостьТоваров.Записывать = Истина;

Запрос.УстановитьПараметр("МоментВремени", МоментВремени());
Запрос.УстановитьПараметр("Ссылка", Ссылка);

РезультатЗапроса = Запрос.Выполнить();

ВыборкаНоменклатура = РезультатЗапроса.Выбрать(ОбходРезультатаЗапроса.ПоГруппировкам);

// 5. Цикл по номенклатуре - проверяем достаточность количества для списания
Пока ВыборкаНоменклатура.Следующий() Цикл

ДефицитНоменклатуры = ВыборкаНоменклатура.Количество - ВыборкаНоменклатура.КоличествоОстаток;

Если ДефицитНоменклатуры>0 Тогда
Сообщение = Новый СообщениеПользователю;
Сообщение.Текст = "Недостаточно товара в количестве: "+ДефицитНоменклатуры;
Сообщение.Поле = "Товары["+(ВыборкаНоменклатура.НомерСтроки-1)+"].Количество";
Сообщение.УстановитьДанные(ЭтотОбъект);
Сообщение.Сообщить();
Отказ = Истина;
КонецЕсли;

Если Отказ Тогда
Продолжить;
КонецЕсли;

// 6. Получим количество для списания
ОсталосьСписать = ВыборкаНоменклатура.Количество;
ВыборкаПартии = ВыборкаНоменклатура.Выбрать();

// 7. Цикл по партиям
Пока ВыборкаПартии.Следующий() И ОсталосьСписать>0 Цикл

Движение = Движения.СебестоимостьТоваров.ДобавитьРасход();
Движение.Период = Дата;
Движение.Номенклатура = ВыборкаПартии.Номенклатура;
Движение.Партия = ВыборкаПартии.Партия;
// 9. Расчет количества для списания
Движение.Количество = Мин(ОсталосьСписать, ВыборкаПартии.КоличествоОстаток);
// 10. Расчет суммы списания
Движение.Сумма = Движение.Количество*
ВыборкаПартии.СуммаОстаток/ВыборкаПартии.КоличествоОстаток;

// 11. Уменьшим количество для списания
ОсталосьСписать = ОсталосьСписать - Движение.Количество;

КонецЦикла;
КонецЦикла;

Изучаю сабж. Ситуация такая, что нюансы по сабжу скорей ясны, а вот общая картина - не до конца. Прошу прокомментировать два пункта, которые я вывел для себя из изученного, но далеко не уверен в их корректности.
1. Техника и концепция "Оперативное проведение" весьма условна и абстрактна, в том смысле что ни к чему не обязывает платформу как таковую. Т.е. изначально документы "оперативные" и "неоперативные" совершенно равноправны и никак не отличимы.
2. Разница между теми и этими возникает только в момент, когда прогер ваяющий собственную конфигурацию анализирует второй параметр обработчика события ОбработкаПроведения(имя параметра - Режим). Он вставляет в месте анализа ветвление ЕСЛИ...ТОГДА и вот тут, и только тут , разница между тем и этим проявляется. И даже тут разница будет не между документами, а между процессами=алгоритмами их проведения. Т.е. платформа максимум что делает - это сообщает тот самый Режим проведения. Что делать с этим знанием, как на него реагировать и реагировать ли вообще - это все к конкретному автору конкретной конфигурации.
Правильно написано?
Если честно, то ход Ваших мыслей лично мне не понятен вообще уже вот как вторую тему. Все просто. Документ - это объект метаданных конфигурации. Он предназначен для отражения факта какого-либо события на предприятии. Документ делает, так называемые, движения (а может и не делать кстати) в регистры различные. (думаю следующая Ваша тема будет посвящена регистрам ). Самый банальный пример - это поступление товара на склад. В 1С есть такое понятие как последовательность документов, т.е. документы четко привязаны ко времени. Так вот мы подошли к самому главному. Документы можно проводить оперативно и неоперативно. Оперативно значит в текущий момент времени. А неоперативно значит датой отличной от текущего времени. Отличной причем только в меньшую сторону, т.е. провести документ будущей датой в нельзя. Сколько я занимаюсь программированием, то ни разу не встречал, чтобы в коде обработки проведения была привязка к режиму проведения.
1. Техника и концепция "Оперативное проведение" весьма условна и абстрактна, в том смысле что ни к чему не обязывает платформу как таковую. Т.е. изначально документы "оперативные" и "неоперативные" совершенно равноправны и никак не отличимы
Нажмите, чтобы раскрыть...

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

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

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

Ну а есть код/пример конфига показывающий/доказывающий что платформа(сама !) конкретно
Качай книгу "Решение прикладных задач"
Нажмите, чтобы раскрыть...

За этот хинт спасибо, попробую разобраться по ней. Но вопросы пускай покамест полежат тут, может ответит кто.
Платформа реагирует тем, что при оперативном проведении дата документа устанавливается реальным временем проведения автоматически.
Вы слишком "плаваете по поверхности" - ныряйте глубже. Когда факт [не]совпадения дат установлен - платформа-то как реагирует в том или ином случае?
А это, извините, вообще на толстый троллинг смахивает. Ну Радченко, первое упоминание обсуждаемого и простой пример к этому упоминанию - сразу же обработка ветвится в зависимости от режима. Второй параметр в ОбработкаПроведения платформа зачем передает, по вашему? Что вы вообще предлагаете делать с этими двумя режимами кроме их анализа в Обработке?
Ну а есть код/пример конфига показывающий/доказывающий что платформа(сама !) конкретно по разному реагирует на один и тот же документ в зависимости от режима?
За этот хинт спасибо, попробую разобраться по ней. Но вопросы пускай покамест полежат тут, может ответит кто.
Нажмите, чтобы раскрыть...

Я лучше буду молчать...
возможно я не до конца понял, что вы хотите сказать.

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

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

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

Это не совсем так.
Вы не увидите различий как разработчик или как конечный пользователь на прикладном уровне работы конфигурации. На физическом уровне, т.е. на уровне записей в базу данных - некоторые различия будут. Но и тут даже наверно не столько "оперативный" - "не оперативный" режимы влияют, а именно дата проведения документа.
А если мне вообще не надо никакие остатки в моем документе при проведении читать?
Нажмите, чтобы раскрыть...

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

Читайте хоть на начало прошлого года. Я говорил о том что если в параметры виртуальной таблицы регистра накопления передать МоментВремени(то есть дата+ссылка) то платформа определит оперативно или нет проводится документ. И если он проводится оперативно то данные будут прочитаны из виртуальной таблицы остатков на 3999 год(или 5999 год... не помню точно).

А то что вы там алгоритмами сделаете это уже дело исключительно ваше. Платформа в любом случае отработает так как я описал выше.. И если вам нужны данные за прошлый период то получайте их это уже как вы сами решите.
Я говорил о том что если в параметры виртуальной таблицы регистра накопления передать МоментВремени(то есть дата+ссылка) то платформа определит оперативно или нет проводится документ. И если он проводится оперативно то данные будут прочитаны из виртуальной таблицы остатков на 3999 год(или 5999 год... не помню точно).
То есть если мы захотим исключить например движения самого документа из результата запроса и передадим например "границу" исключающую движения самого документа то это не сработает. И нужно предварительно очистить движения этого документа.
Понимание этого механизма проверятся на спеце по платформе и разбирается подробно при подготовке.
Нажмите, чтобы раскрыть...

Понятно. Той статье Чистова в которой это разбирается (он же кажется писал?) наверно года два уже.
Баг 1С выдается за фичу. Ну по факту баг это или фича не важно, но да, такой момент есть.
Да, принимаю.
Но, опять таки чтение остатков при проведении - это алгоритм или нет?
Я думаю что алгоритм. Более того это конкретный алгоритм контроля остатков.
И? Если мы уберем контроль остатков как алгоритм, то
?