CC BY
16
Дзенгелевский А.Е. ©
К.т.н., доцент кафедры системного анализа, Национальный исследовательский ядерный университет МИФИ; начальник управления НСИ, ООО «ЕАЕ-Консалт»
ПОДДЕРЖКА ТЕМПОРАЛЬНОСТИ НОРМАТИВНО-СПРАВОЧНОЙ ИНФОРМАЦИИ
Аннотация
В статье рассмотрены варианты поддержки темпоральности нормативно-справочной информации на примере справочника контрагентов.
Ключевые слова: нормативно-справочная информация, корпоративные информационные системы, темпоральные данные, EAE.MDM.
Keywords: MDM, ERP, time-depended-information, EAE.MDM.
Введение
Основные вопросы создания системы управления нормативно-справочной информации (НСИ) в крупной организации рассмотрены в [1], [2], [3], [4], [5], [6]. В статье [7] были рассмотрены подходы к формированию справочника товарно-материальных ценностей. В данной статье рассмотрены варианты поддержки темпоральности нормативно-справочной информации.
Постановка задачи
Под нормативно-справочной информацией (НСИ) предприятия понимается условно-постоянная (то есть используемая как в течение, так и вне отчетного периода) часть всей хранящейся информации. Однако и справочные данные могут меняться со временем. При этом важно хранить всю историю изменений. Для обозначения таких данных используется термин «темпоральные данные» или "Time-depended information".
Например, у организации может измениться название, адрес, организационно-правовая форма. Может даже смениться генеральный директор, но это будет та же самая организация с точки зрения места на рынке.
С точки зрения налогового учета ситуация несколько отличается. Организация считается другой, если она сменила регистрационный код в налоговой инспекции.
Смена ОПФ в России, как правило, тоже приводит к смене кода ИНН и соответственно к регистрации новой организации. Исключением являются положения федерального закона [8], в соответствии c которым орагнизационно-правовая форма может быть изменена взамен устаревшей (например, ОАО на ПАО) в связи с выходом нового варианта устава.
В бухгалтерском учете для новой организации также требуется создавать новую запись, переносить задолженность, перерегистрировать договоры и т.п. Сложнее случай, когда у организации изменился только юридический адрес. Или только название. В европейских странах изменение названия и смена ОПФ не требует перерегистрации, код регистрации может остаться тем же.
Встает вопрос, как наиболее эффективно учитывать такие изменения в учетных системах?
Рассмотрим следующий пример.
1) Организация была зарегистрирована 01.06.2011 и до 01.01.2012 имела следующие реквизиты:
ОПФ: «ООО»; Название: «Рога»; Город юридического адреса: «Санкт-Петербург».
© Дзенгелевский А.Е., 2016 г.
2) Начиная с 01.01.2012, организация изменила название:
ОПФ: «ООО»; Название: «Рога и копыта»; Город юридического адреса: «Санкт-Петербург».
3) Начиная с 01.01.2013, организация изменила город юридического адреса:
ОПФ: «ООО»; Название: «Рога и копыта»; Город юридического адреса: «Москва»
4) 01.06.2013 организация была ликвидирована.
Допустим, 11.10.11 запись об организации была добавлена в справочник с названием «Рога». 15.01.13 поступила информация о том, что с 01.01.12 у организации уже другое название - «Рога и копыта». Если это изменение будет внесено путем простого исправления записи в справочнике, то после такого изменения в экранных и печатных формах системы в документах увидим новое название: «Рога и копыта». Для новых документов, созданных после 01.01.12 - это то, что нам нужно.
Если же мы попытаемся напечатать документ, созданный ранее этой даты, то в нём мы также увидим название «Рога и копыта» вместо прежнего «Рога».
Объясняется это тем, что в стандартных реализациях транзакционных систем в документах в качестве ссылок на записи справочников, как правило, используются коды записей справочника, а не значения конкретных атрибутов. Поэтому после стандартного изменения записи справочника при обращении к старому документу используются актуальные данные, хранящиеся в справочнике.
Вместе с тем, по законодательным требованиям учёта, в системах, в которых формируются и печатаются первичные документы, ведутся учётные регистры, должна сохраняться информация со ссылкой на старые названия. Предприятие отвечает о правдивости данных как в первичных документах, так и в своей системе учёта.
Получается, что документы по этой организации должны до дня смены названия включать прежнее название, а начиная с этого дня - новое.
Важно отметить, что критичными являются не любые изменения, а только изменения атрибутов, используемых в важной внутренней или внешней отчетности. К ним относятся следующие:
1) Организационно-правовая форма;
2) Краткое название контрагента по уставу;
3) Полное название контрагента по уставу;
4) Юридический адрес;
5) Код регистрации;
6) Код учета налогов (для стран, где отличаются эти коды).
Здесь перечислены внешние данные о контрагентах. Еще более часто в организациях требуется отражать историю изменения других, внутренних данных. Например, в свете закона [9] таким является вхождение в консолидированную группу налогоплательщиков, либо принадлежность к дочерним и зависимым предприятиям для холдинга.
Как данная проблема может быть решена?
Варианты решения
Вариант 1. Создание новых записей при изменении критичных полей
Стоит отметить, что это наиболее логичный вариант для систем бухгалтерского учета, если меняется системный Код контрагента. При таких изменениях может быть постепенный перенос взаимных долгов, и в учете какое-то время могут существовать обе организации.
Данные в системе будут выглядеть так, как показано в Таблице 1.
Таблица 1
Пример хранения исторических данных с разным системным кодом
№ Код ОПФ Название Город Код действу- Дата
контра- юридического ющей записи изменения
гента адреса оператором
1 1234 ООО Рога С анкт-Петер бур г 2345 11.10.2011
2 2345 ООО Рога и копыта С анкт-Петер бур г 3456 15.01.2012
3 3456 ООО Рога и копыта Москва 16.01.2013
Что касается остальных полей, то следует отметить основное достоинство этого варианта:
1) Можно обойтись без существенных доработок справочников и печатных форм.
Однако есть у этого варианта и недостатки:
1) После создания новой записи необходимо перенести на нее все действующие документы, которые относились к старой записи: договора, проекты накладных, заявки и др.
2) Необходимо выполнить перенос задолженности со старого контрагента на нового: как бухгалтерской (денежные обязательства), так и логистической (материальные остатки).
3) Вероятно, потребуется доработка правил проверки уникальности. Если, например, настроена проверка уникальности записи по Коду регистрации, а он остается прежним у новой записи, то такая проверка должна быть снята при наличии связей между записями.
4) Желательно поддерживать связь между старой и новой записью. Например, путем хранения ссылки из устаревшей записи на действующую. Не наоборот, поскольку действующая запись всегда одна, а устаревших может быть несколько. Эта ссылка может потребоваться, например, в отчетных формах для подведения общего итога по одной организации, изменявшей свои реквизиты.
Вариант 2. Временное изменение справочных данных в системе
Требование предоставить отчет по историческим данным бывает довольно редко. Поэтому в ряде случаев можно временно изменить запись, сформировать исторический отчет и вернуть данные обратно.
Достоинства:
1) Полное отсутствие необходимости доработок в системе учета;
Недостатки:
1) К сожалению, этот вариант не работает, если данные изменились внутри отчетного периода, в котором задействованы и старая, и новая организации. Хотя такое изменение бывает тоже довольно редко и «все неприятности обычно наступают с 1-го числа», однажды такой тупик может произойти.
2) Ручное исправление данных, чреватое ошибками;
3) Нарушение буквы закона, предписывающего хранить данные в системах в историческом виде. Насколько это нарушение серьезное, будет устанавливать уже налоговая инспекция в случае проведения проверки системы учёта.
Вариант 3. Хранение образов документов
В ряде случаев выходом является хранение данных не в базе данных в системе, а в виде электронных образов документов. Например, в файлах
Достоинства:
1) Полное отсутствие доработок в системе;
2) Не требуется ручное исправление данных;
Недостатки:
1) Необходимость поддержки хранилища документов;
2) К сожалению, этот вариант также не работает, если данные изменились внутри отчетного периода, а в отчетной форме фигурируют и старая и новая организации.
Есть и более надежные варианты решения. К сожалению, они требуют либо доработок системы, либо перехода к более развитой системе ведения НСИ.
Вариант 4. Хранение значений вместо ссылок
Если в системе возможны дополнительные настройки и доработки, возможно использование дополнительных атрибутов документа для хранения важных исторических данных. При сохранении нового документа в эти поля могут копироваться данные из справочников на дату создания документа. Программисты называют такой прием
«денормализация», что означает повторное хранение в системе данных, которые уже хранятся в других таблицах. Места для хранения данных в этом случае требуется больше, но при этом могут упрощаться другие операции.
Достоинства:
1) Запись справочника может меняться при необходимости, документ будет сохранен в том же виде, как выдавался на печать;
Недостатки:
2) при обнаружении ошибки в написании справочника, придется менять (пересохранять) все созданные ранее документы);
3) требуются доработки:
- структуры документов (добавление полей);
- процедуры сохранения документов;
- процедуры использования документов.
Вариант 5. Дополнительное хранение исторической информации
Данный вариант подразумевает хранение данных о контрагенте в виде одной записи, под одним кодом, но с возможностью хранения истории юридических изменений. При этом нужно отличать историческую информацию о контрагенте от истории системных изменений, которая поддерживается большинством крупных систем. Причиной системных изменений могут быть как юридические изменения, так и ошибки операторов. Датой такого изменения считается дата сохранения оператором данных в системе. К сожалению, для построения исторически корректных отчетов этого недостаточно. Для наших целей мы сможем воспользоваться данным журналом только в случае, если оператор вносит изменения «день в день» и не допускает ошибок ввода. И то, и другое практически невозможно.
Отдельное хранение юридических изменений позволяет явно задавать период действия атрибутов контрагента. Обычно достаточно хранить одну дату. Например, дату, по которую действуют исторические данные. Таких дат может быть несколько и, соответственно, будет несколько записей в таблице исторических данных.
Пример юридических исторических данных приведен в Таблице 2.
Таблица 2
Хранение исторических данных с тем же системным кодом
№ Код ОПФ Название Город Дата Дата, по
контра- юридического изменения которую
гента адреса оператором действует запись
Исто рические данные:
1 1234 ООО Рога Санкт-Петербург 11.05.2011 31.12.2011
2 1234 ООО Рога и копыта Санкт-Петербург 15.01.2012 31.12.2012
Действующая запись:
3 1234 ООО Рога и копыта Москва 16.01.2013
После прекращения действия контрагента запись о нём может быть заблокирована в системе, но история его изменений сохранится (Таблица 3).
Таблица 3
Блокирование записи о контрагенте с историей
№ Код ОПФ Название Город Дата Дата, по
контра- юридического изменения которую
гента адреса оператором действует запись
Исто рические данные:
1 1234 ООО Рога С анкт-Петер бур г 11.05.2011 31.12.2011
2 1234 ООО Рога и копыта С анкт-Петер бур г 15.01.2012 31.12.2012
3 1234 ООО Рога и копыта Москва 16.01.2013 01.06.2013
Действующая запись:
4 1234 ООО Рога и копыта Москва 16.06.2013 (блокирована)
Достоинства:
1) Системы, которым не важна история изменений, продолжают использовать тот же код записи.
2) На любую дату можно увидеть запись в том же виде. Запись справочника может меняться при необходимости, документ будет сохранен в том же виде, как выдавался на печать;
3) Сохраняется история хозяйственных операций по контрагенту на одном коде, следовательно поддерживается более прозрачный учёт операций.
4) Исключается трудоемкость у пользователя по переносу бухгалтерских документов по контрагенту в связи с созданием нового контрагента.
Недостатки:
1) При формировании исторических экранных и печатных форм при обращении к справочнику всегда требуется указывать дату, на которую нужны данные.
Вариант 6. Хранение только исторической информации
Есть и еще более кардинальный вариант - хранить все записи как исторические. В этом случае у всех записей будет указана дата действия и не будет отдельной таблицы для хранения истории. Значения для отражения рассмотренного примера до блокирования записи и после представлены в Таблицах 4 и 5.
Таблица 4
Действующие записи с учетом даты, до блокирования:
№ Код ОПФ Название Город Дата Дата, по
контра- юридического изменения которую
гента адреса оператором действует запись
1 1234 ООО Рога С анкт-Петер бур г 11.05.2011 31.12.2011
2 1234 ООО Рога и копыта С анкт-Петер бур г 15.01.2012 31.12.2012
3 1234 ООО Рога и копыта Москва 16.01.2013
Таблица 5
Действующие записи с учетом даты, после блокирования:
№ Код ОПФ Название Город Дата Дата, по
контра- юридического изменения которую
гента адреса оператором действует запись
1 1234 ООО Рога Санкт-Петербург 11.05.2011 31.12.2011
2 1234 ООО Рога и копыта Санкт-Петербург 15.01.2012 31.12.2012
3 1234 ООО Рога и копыта Москва 16.01.2013 01.06.2013
Достоинства:
1) На любую дату можно увидеть запись в том же виде. Запись справочника может меняться при необходимости, документ будет сохранен в том же виде, как выдавался на печать;
2) При таком подходе легко поддержать не только исторические, но и будущие данные об организации. Это может быть полезно, например, при формировании бюджетов, для которых важно учитывать внутренний статус организации (например, вхождение организации в планово-бюджетную группу).
Недостатки:
1) При обращении к справочнику за актуальными данными необходимо учитывать текущую дату.
2) При формировании исторических экранных и печатных форм при обращении к справочнику требуется учитывать дату, на которую нужны данные.
Заключение
Вариант, выбранный для конкретного предприятия, очень сильно зависит от условий: количество контрагентов и их изменений, частота проверок, схема интеграции систем, требования к учету исторических и планируемых изменений.
Наибольшее внимание предлагается уделить вариантам 5 и 6, которые позволяют системно решить описываемую проблему. Достоинство этих вариантов также в том, что они реализованы и прошли апробацию в ряде систем, поддерживаемых компанией ООО «ЕАЕ-Консалт»: ИСУ ЛУКОЙЛ (вариант 5), КССС [4], [5], (варианты 5 и 6 для разных справочников), Petronics (вариант 6).
Литература
1. В.В.Трейер, «Как формировать корпоративные электронные справочники продукции,» № 40, 2005.
2. Г.Г.Кашлева, «Какой должна быть система НСИ: опыт её внедрения в ОАО "НК "Роснефть",» № № 5, pp. 86-91, 2004.
3. А.Е.Дзенгелевский, Ш.Р.Халилов, «Опыт создания и развития корпоративной системы управления нормативно-справочной информацией,» Научно-методический журнал "Межотраслевая информационная служба», т. 1, pp. 22-26, 2012.
4. А.Е.Дзенгелевский, А.А.Смирнов, «История КССС: Единая корпоративная система словарей и справочников,» ЛУКОЙЛ-ИНФОРМ, ITime - Информационные технологии в ТЭК, Москва, 2007.
5. А.Е.Дзенгелевский, А.С.Могилат, «Классификаторы КССС: теперь и готовая продукция,» № 2(12), pp. 26-29, 2010.
6. А.В.Токарева, «Системы ведения НСИ и их место в корпоративных информационных системах (КИС)» 14 07 2008. [В Интернете]. Available: http://www.arkus-it.ru/articles/index.php? ELEMENT_ID=2923.
7. А.Е.Дзенгелевский, «Уровни обобщения при учете товарно-материальных ценностей,» Актуальные проблемы гуманитарных и естественных наук» №12(59) 2013 Ч.1, , стр.82-90, т. 12 ч.1, № 59, pp. 82-90, 2013.
8. Федеральный закон № 99-ФЗ от 05.05.2014 «О внесении изменений в главу 4 части первой Гражданского кодекса Российской Федерации и о признании утратившими силу отдельных положений законодательных актов Российской Федерации», 2014.
9. Федеральный закон от 18.07.2011 №227-ФЗ "О внесении изменений в отдельные законодательные акты Российской Федерации в связи с совершенствованием принципов определения цен для целей налогообложения", Москва, 2011.
