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