Хранение дополнительной информации в БД.

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

У большинства администраторов БД и программистов возникает потребность в хранении различной дополнительной информации напрямую не относящейся к учету.

Рассмотрим небольшой пример. Организация работает с валютами для упр. учета, но при загрузке валют необходимо увеличивать курс ЦБ на определенный процент. Можно залезть в обработку загрузки курсов валют и подставить нужную формулу. Но настал момент и процент надо изменить… Опять открываем конфигуратор и меняем формулу. Если это происходит раз в год, то конечно никаких проблем нет, но что если это происходит достаточно часто? Неудобо. А если штатного программиста на фирме нет или он в отпуске, а поменять надо срочно?

Еще пример. У многих администраторов БД существуют обработки по автоматическому формированию документов, справочников и пр. Если посмотреть, в таких обработках существуют «костыли» типа «НайтиПоНаименованию()» или «НайтиПоКоду()» и прочее. Это конечно имеет право на жизнь, но всетаки не красиво и что делать, когда с определенной даты правила формирования меняются и надо использовать другие параметры заполнения. И тут возникают конструкции:

Если Дата > КакаяТоДата Тогда

     НужныйСправочник = НайтиПоКоду(«ПервыйВариант»)

Иначе

     НужныйСправочник = НайтиПоКоду («ВторойВариант»)

КонецЕсли;

Удобсто на лицо 🙂

Мы тоже с этим мучились и наконец пришли к варианту с периодическим регистром сведений.

1. В конфигурации был создан регистр «_ПериодическиеОбъекты». «_» в наименовании наглядно показывает что это наш регистр и при обновлении название не пересечется с названиями регистров от 1С. Добавлено измерение «Наименование» тип строка (200) и ресурс «Объект» имеющий составной тип с нужным набором типов данных. Периодичность установили «В пределах секунды» (в принципе можно было установить и «В пределах дня», просто подстраховались).

2. Так как у нас уже был свой общий модуль, в него была добавлена экспортная функция получения данных из нового регистра «ПолучитьПериодическийОбъект(парНаименование, парДата) с параметрами «парНаименование» в который передается наименование объекта в регистре и «парДата» на которую нужно получить значение. В итоге конструкция поиска нужного значения справочника озвученная выше будет выглядеть:

НужныйСправочник = ПолучитьПериодическийОбъект(«НужныйСправочник», Дата);

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

Теперь вопросы. «Почему не константы?» При добавлении нового объекта надо добавлять константу и отрисовывать форму заполнения. Основной минус — нельзя хранить данные в периоде. «Почему не справочник?» Так же как и с константами нельзя хранить данные в периоде.

Дальше — больше. В БД появились несколько организаций и правила заполнения для них частично одинаковые, а частично различаются… Тут и возник второй регистр сведений «_ПериодическиеОбъектыОрганизаций», состав регистра я думаю понятен из его названия :).

Данная схема с регистрами используется у нас более 3 лет и хорошо себя зарекомендовала. На инфостарте опубликована моя обработка печати заявлений на карту в Сбербанк. В этой обработке у нас заполняются поля «Должность» и «ФИО» ответственного сотрудника организации, а так же печатается доверенность на сотрудника, который относит заявления в банк для оформления карты.  В доверенности указывается сотрудник, его адрес, паспортные данные, договор организации с банком. Часть этих данных внесена в регистр «_ПериодическиеОбъектыОрганизаций» и при печати берутся оттуда, что обеспечивает правильность и корректность данных.

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

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