Преамбула. Данная статья рассчитана на начинающих коллег-разработчиков, знакомых с понятием "регистр сведений, проведение" и т.д, не претендует на полноту раскрываемого вопроса. Цель - поделиться идеями и пригласить к дальнейшему обсуждению. Спасибо за понимание!
Итак, перед нами (здесь и далее я отождествляю себя с программистом 1С 
) очень часто встает необходимость изменений в алгоритме проведения какого-либо документа. Как только такая задача появляется на горизонте, в голове рождается мысль "Могу ли я использовать подходящие для решения внешние данные?".
Давайте сначала определимся с термином "Устойчивость". Под ним будем понимать такое поведение алгоритма, при котором изменение внешних (по отношению к нему) тех же самых данных "задним числом" не влечет за собой изменение выходных данных. Т.е. если при проведении мы считали из таблицы БД значение СуммаЗатрат = 74 и наш алгоритм выдал цифру 35, то при изменении значение СуммаЗатрат на 83, наш алгоритм выдает значение 290, то будем считать алгоритм неустойчивым.
Итак, давайте рассмотрим на примере основных объектах метаданных, какие данные использовать :
1. Первый и самый напрашивающий класс данных - это данные самого документа. И правда, если в бухгалтерскую проводку идет запись комментария из соответствующего реквизита, то все понятно.
Однако рассмотрим такой пример - в документе поступления необходимо реализовать учет комплектов (набор нескольких позиций номенклатуры). Состав комплектов храниться в независимом регистре сведений. Можно ли читать данные о составе комплектов напрямую? Казалось бы, пуркуа па, как говорят французы. Но если мы подберем такой комплект, то наш сосед может изменить его и при перепроведении получится эпикфейл другой набор данных.
Поэтому разумным и корректным будет вариант хранение данных о составе таких комплектов внутри документа. Дополнительно нужно продумать вариант синхронизации этих данных между собой.
Рис. 1. Хранение данных о наборах
2. Данные, заблокированные от изменений. Как мы знаем, константы отлично подходят для хранения условно-постоянной информации. Но в отличие от математических констант, константы 1С редко, но меняют свое значение.
Так можно ли на них положиться? Таки да, но при одном условии - если мы их "заморозим", заблокируем от изменений.
Нужно ли хранить валюту регламентированного учета в реквизите каждого документа? Капитан очевидность Здравый смысл подсказывает нам, что нет - ведь есть такая константа. В типовых конфигурациях реализована проверка на возможность ее изменения.
Рис. 2. Валюта регл.учета. При проведении документов блокируется.
3. Данные из регистров, подчиненных регистратору. Тут может возникнуть вопрос - при отмене проведения набор записей станет пустым, все движения очистится (при соответствующих настройках документа). Можно ли полагаться на них? Ответ - да, ведь в системе будем зафиксирован момент, когда документ перестал быть актуальными, использую объект Последовательность. Такой объект хранит информацию о границе, начиная с которой документы нужно перепровести.
Рис. 3. Варианты последовательностей
Давайте обратим внимание и на другие объекты. Могут ли они быть источником данных при проведении?
1. Справочники. Если они не фиксируется в каком-либо одном состоянии после записи, то риск получить различный результат очень высок.
2. Независимые регистры сведений. Иногда возникают задачи, когда все-таки необходимо получить данные из независимых РС. Ранее мы вроде отбраковали отказались от них как ненадежного варианта. Но здесь можно предложить следующий прием. Предположим, есть регистр сведений, хранящий связь контрагентов с менеджерами компании, которые контрагентов курируют. Фиксация такой связи должна происходить документально. Как обеспечить возможность синхронизации данных при проведении и отмене проведения?
Как вариант - завести реквизит, ссылающийся на документ-регистратор.
Пример такой структуры на след.рисунке:
Рис.4. Структура регистра сведений.
Подводя итоги, можно сказать, что 3 типа данных можно использовать в алгоритмах проведения:
- Данные документа.
- Неизменяемые данные.
- Данные регистров, подчиненных регистратору.
