Формирование нси что это
Про нормализацию НСИ простыми словами
В любой крупной производственной компании основные бизнес-процессы автоматизированы: бухгалтерский учет, складской учет, управление производством. Автоматизированные системы (АС) обращаются к единому информационному центру, где определен список классификаторов и хранятся номенклатурные карточки. Когда в базе нормативно-справочной информации (НСИ) беспорядок, АС выгружают отчеты с ошибками, на основании которых руководство может принять неверные управленческие решения.
Нормализация нормативно-справочной информации (НСИ) — «генеральная уборка» в информационном центре компании. Сюда входят выделение классов, структурирование, обогащение номенклатурной базы, создание шаблонов, инструкции по взаимодействию с НСИ пользователей и экспертов.
Если изначально базы НСИ не было или она была неполной, информационный центр захламляется. Сотрудники управлений с разными АС дополняют и редактируют карточки на свое усмотрение, интеграции между системами нет — все это усугубляет беспорядок и приводит к ошибкам:
— некорректным названиям и техническим характеристикам материалов;
— неправильному разнесению товаров по классам.
Простейший отчет по финансированию одного проекта сотрудники вынуждены формировать вручную, поскольку неструктурированная выгрузка из 1С, например, не годится для аналитики. Или на складе лежат годами товары, которые добавили в программу под другим наименованием или с ошибкой.
Итак, компания решила привести в порядок НСИ и сталкивается с муками выбора. Рынок предлагает 3 вида исполнителей:
— поставщики модульных систем для управления предприятием и взаимоотношениями с клиентами (1С, SAP);
— разработчики заказного программного обеспечения;
— провайдеры, предлагающие автоматизацию закупок на основе инструментов электронных торговых площадок.
Допустим, исполнителя выбрали. Следующая сложность заключается в том, что нормализация НСИ отнимает много времени у заказчика, в том числе руководителей.
Процесс начинается с анализа, переработки и добавления классификаторов и номенклатурных карточек. Ни один из 3 перечисленных видов подрядчиков не ориентируется в отрасли и специфике компании настолько, чтобы справиться с этим этапом самостоятельно и оправдать ожидания клиента. Поэтому часть работы ложится на экспертов заказчика под руководством нанятых консультантов.
Сама нормализация с помощью специальных платформенных решений – MDM систем (управление мастер-данными), при готовых классификаторах проходит быстро. Но остаются позиции, которые система не классифицировала. Если обращений к этим позициям не будет, они так и потонут в глубинах БД, если информация понадобилась — заинтересованный сотрудник определяет ее класс.
Нормализовать нормативно-справочную информацию мало, ей важно управлять. Можно держать постоянно действующую службу экспертов или давать права на редактирование сотрудникам, изучившим инструкции и детальные описания классов. Второе, впрочем, малоэффективно.
Исполнители, которые способны минимизировать участие заказчика в реструктуризации НСИ и оказывать услуги по поддержанию информационного центра в порядке, имеют конкурентное преимущество. Весь предыдущий опыт, текущие заказные разработки сделали нас экспертами и в этом направлении. Мы готовы помогать электросетевым компаниям проводить нормализацию НСИ без потери их времени.
НСИ в 1С
Создание информационных систем актуально для всех предприятий в век бурного технологического развития. В особенности таких, которые затрагивают самые разные направления деятельности, включая бухгалтерский, складской и управленческий учет, управление сотрудниками. Для построения единых систем нормативно-справочной информации доступно решение НСИ в 1С.
Ведь можно создать целый ряд независимых друг от друга систем, которые будут отвечать за каждое из направлений. Но в определенные моменты деятельности может возникнуть потребность увидеть происходящее целиком. А если на предприятии используются различные системы, сопоставить и сравнить данные невозможно. Это связано с тем, что наименования присваиваются в системах различными способами, что может привести к противоречивости и некорректности данных, а также их дублированию.
Основная причина несоответствий заключается в отсутствии единого подхода к созданию мастер-данных. Другими словами сведений, которые представляют основу структурных элементов компании.
Поэтому на предприятиях должна быть создана нормативно-справочная система, с помощью которой можно своевременно идентифицировать источник данных и корректно оперировать сведениями.
Сильные стороны НСИ, результаты внедрения
Нормативно-справочная информация – это ведение и поддержка различных справочников, которые обеспечивают ввод данных в информационном пространстве, в котором ведется работа. Такие системы можно назвать условно-постоянными.
Для эффективного управления предприятием должно быть создано общее информационное пространство. Таким образом, любое перемещение информации между различными участками будет организовано единообразно и будет опираться на единую базу. Для интеграции всех существующих систем понадобится централизованное управление нормативно-справочной информацией.
С помощью НСИ можно добиться следующих результатов:
Таким образом, осуществляется централизация ответственности за качество самой нормативно-справочной системы.
Собственники субъектов хозяйственной деятельности получают следующие преимущества:
Все это существенно упрощает подготовку отчетности – управленческой и бухгалтерской. В том числе система оптимизирует материальные затраты, повышает качество решений, улучшает качество консолидации учетных данных.
Справочники в 1С
В разделе нормативно-справочной информации в товароучетной программе 1С содержатся справочники, необходимые для работы в большинстве компаний. Эти справочники можно редактировать, вносить в них информацию для корректной работы по определенному виду деятельности.
Справочники можно разделить на основные и прочие. Первая категория включает справочники, необходимые для оформления документации по хозяйственной деятельности. К прочим относятся справочники, которые облегчают поиск и ввод данных.
В зависимости от вида деятельности, основные справочники содержат информацию о структуре компании и номенклатуре. К прочим относятся классификаторы, содержащие информацию общероссийских классификаторов, в их числе адресный классификатор, сведения о банках. Для предприятия, которое занимается торговлей, это могут быть склады, в которых хранится товар, торговые точки, кассы. Для сферы производства информационная структура будет более сложной.
Фирмы по оказанию услуг может иметь простую структуру в зависимости от количества видов услуг. Например, это может быть информация о самой организации, ее контрагентах. В одних решениях нормативно-справочная информация может быть вынесена в отдельный раздел меню, в других иметь вид Справочников в разделе «Компания», «Настройка» или меню «Справочники».
Описание НСИ
В любой информационной системе есть объекты и свойства. Каждый объект обладает определенными свойствами, по которым его можно идентифицировать. Все строится по определенным правилам и нормам, в качестве примера можно рассмотреть документ Спецификация, в котором отражены объекты, свойства и количество.
В 1С:ERP представлен отдельный раздел в меню «НСИ и администрирование», который включает два блока – «Настройка НСИ и разделов» и НСИ, содержащий справочники. В первом из них содержится нормативно-справочная информация для разных направлений, в том числе казначейство, заработная плата, кадры, налоги.
По отдельности НСИ размещена в некоторых разделах, включая «Закупки», «Производство», «Продажи». Любые нарушения при создании данных в системе могут вызвать проблемы, поэтому важно понимать архитектуру сведений, которые создают логистику. В системе содержится большое количество предустановленных реквизитов.
Вся корпоративная информационная система основана на архитектуре и полагается на эти сведения.
С мастер-данными происходят различные события. В результате этого производится запись в той или иной форме в базу данных. Отчеты строятся на основании той или иной формы различными способами.
Номенклатура – что это такое
Справочник «Номенклатура» присутствует во всех НСИ, которые связаны со сферой торговли, производства, оказания услуг, выполнения работ. В этом справочнике справа представлены виды номенклатуры, а в левой части – непосредственно объекты.
Следующие их виды установлены в 1С: Управление нашей фирмой – материалы, бытовая техника, розница, модули, работы и услуги, сантехника, мебельные детали. Внутри каждого из них представлены объекты, включенные в группу.
Отличаются виды объектов и их свойства в 1С: ERP. Они зависят от видов деятельности компании. Система позволяет задать фильтр по свойствам или видам.
По сути, виды номенклатуры представляют собой разрезы, которые содержат в себе определенные характеристики. Их объединяют по определенным признакам. Этих признаков может быть несколько, в частности, по отношению к производственным процессам.
Справочники в 1С:ERP
В основном справочнике содержатся сведения об Организации.
В них представлена следующая информация:
Есть и прочие сведения, такие как лицензии, кассы предприятия, лицевые счета предприятия. Впоследствии вся информация выводится в соответствующих документах.
Настройка выполняется в разделе «Настройка НСИ и разделов», в котором следует поставить галочку, если ведется учет нескольких организаций. Также можно задать валюту, настроить график, отметить подразделения в отдельном банке, разделить операции закупок и продаж для управленческого, регламентного учета.
В разрезе направлений отражены склады, отделы компании и службы в Справочнике «Структура предприятия». В справочниках «Кассы предприятия» и «Кассы ККМ» содержатся сведения о нумерации кассовых ордеров, принадлежности кассы к структурному подразделению, складах, регистрационном номере, типе касс для контрольно-кассовой машины.
Справочник «Физические лица» включает данные о любых физических лицах, связанных
С помощью справочника можно сгруппировать массивы по различным категориям. Предусмотрена возможность внесения сведений о гражданстве, контактных данных, дате и месте рождении, страховании и налогах, лицевых счетах.
Детальная информация о продукции производства и местах хранения товаров содержится в справочнике «Склады и хранение». Группировка производится по таким направлениям как виды цены, назначение склада, контактные данные.
Разновидности и состав номенклатуры
Данные о материалах, продукции, полуфабрикатах, предоставляемых услугах и покупных товарах хранятся в справочнике «Номенклатура».
Предусмотрена возможность настройки классификаторов номенклатуры, включая единицы измерения, виды, ценовые, складские и сезонные группы, по ТН ВЭД и по ОКВЭД.
Для производственных предприятий в группе комплектующих представлены такие номенклатуры как полуфабрикаты, изделия из дерева, основные материалы.
В любом виде номенклатуры можно увидеть основные данные о нем. Доступна функция корректировки.
На этапе создания нового вида необходимо указать группу доступа.
Что представляет собой номенклатура
В каждом объекте представлена табличная форма. На вкладке «Карточка» содержатся такие реквизиты как код, наименование, описание с изображением, артикул, параметры учета, данные о производстве, цены. Приведенные выше сведения можно ввести или изменить на вкладке «Реквизиты».
Единицы измерения могут отличаться для отражения единиц для отчетов и единиц хранения. Также здесь указываются группы учета (финансового и регламентированного), НДС. Если у объекта есть отличительные свойства, их можно увидеть при его выделении, непосредственно под видами.
Это значит, что можно выбрать материалы по определенным характеристикам. В этом же окне в строке поиска предусмотрен ввод необходимого объекта. С помощью перемещения курсора по видам номенклатуры можно гораздо быстрее найти элемент, что очень удобно при большом количестве наименований. Доступен поиск по штрих-коду, сортировка по товарам другого качества и номенклатуре с аналогичными характеристиками.
После материалов и комплектующих будет рассмотрена готовая продукция.
Спецификация
Например, предприятие занимается производством парников. Этот процесс включает изготовление деталей и их последующую сборку. Спецификация содержит данные о расходных материалах, всех этапах работы, трудовых затратах. Спецификацию можно посмотреть в разделе меню «Производство», и в категории «Нормативно-справочная информация» перейти к «Ресурсным спецификациям». Откроется список, в котором необходимо выбрать документ.
В форме «Спецификация» представлено несколько закладок. На основной размещена номенклатура, категория изделия, наименование, характеристики, единицы измерения, процент брака. На вкладке «Материалы и работы» указываются материалы, которые понадобятся при производстве.
В примере с парником это будет поликарбонат, саморезы, электродная проволока, профильная труба, каркас двери. Для всех наименований указываются единицы измерения, количество, способ получения, статья калькуляции. При «Установке дверей» способ получения материала производится по спецификации «Каркас дверей для парника». Отдельные характеристики для каждого из материалов не предусмотрены.
По спецификации «Каркас двери для парника» также выделены материалы для производства и этапы работы. На вкладке «Трудозатраты» размещены данные о количестве часов различных видов работ для изготовления парника, включая сварочные, слесарные, резку пластика, монтажные. Указывается, какой вид работ на каком этапе используется и статьи калькуляции.
Следующая закладка содержит сведения о процессе производства, в том числе очередность этапов и подразделения, в которых выполняется работа. Дополнительно приводится распределение затрат на изделия и указывается ответственное лицо.
Дерево спецификаций
Нюансы спецификации можно посмотреть с помощью «Дерева спецификаций».
Все данные спецификации можно найти в одном окне. Если спецификация основная, она будет подставляться во время организации работ по умолчанию. Эти документы выделяются шрифтом в общем списке.
К форме сравнения в списке спецификаций можно перейти с помощью клавиши «Сравнить спецификации». Нажатием кнопки «Добавить» выбираются необходимые спецификации, после чего нужно выбрать «Сформировать отчет». Появится таблица, в которой будут отражены сходства и различия при производстве выбранной продукции.
Можно оставить необходимые документы, для выбора этой опции нужно нажать «Показать только отличия».
Из всего вышеизложенного можно сделать вывод, что база данных строится на отдельных объектах с определенными свойствами. Эти объекты объединяются по определенным направлениям в списки и табличные формы. Они хранятся в товароучетной программе 1С и затем используются при заполнении документов, а также при последующем оформлении определенных процессов. Доступны списки клиентов, сотрудников, поставщиков.
Каждая позиция может хранить различную дополнительную информацию. В справочниках имеется иерархия, это значит, что данные объединяются в группы и подгруппы. Совмещение сведений, их взаимосвязи собираются в определенные нормативы. Все эти данные и составляют нормативно-справочную информацию, которая позволяет создать единую систему учета в компании.
Сервисы, помогающие в работе бухгалтера, вы можете приобрести здесь.
Создание единой системы управления НСИ
Создание единой системы управления нормативно-справочной информацией (НСИ) поможет решить целый комплекс проблем, вызванных множественностью точек ввода НСИ, отсутствием единых стандартов ведения НСИ и недостаточной квалификацией персонала.
Результат внедрения централизованной системы управления НСИ — приведение записей корпоративных справочников к стандартному, легко идентифицируемому виду, устранение неактуальной и дублирующейся информации, организация единой точки ввода, обработки и контроля содержимого справочников. Все это предоставляет возможности для улучшения качества консолидации учетных данных, упрощение задач подготовки бухгалтерской отчетности и отчетности по МСФО, оптимизации материальных запасов, повышения качества управленческих решений.
Централизованное управление нормативно-справочной информацией с DATAREON
Специалисты DATAREON имеют значительный опыт систематизации нормативно-справочной информации, разработки единых регламентов использования и ведения НСИ, внедрения специализированных автоматизированных систем управления НСИ на базе MDM-системы «1С:Предприятие 8. MDM Управление НСИ». В рамках выполненных проектов специалистами DATAREON проводилась экспертная обработка записей справочников МТР, услуг, контрагентов, справочников финансового блока, организационной структуры и управления персоналом.
Успешный опыт работы в области управления НСИ, апробированные на практике эффективные методики и собственная экспертиза позволяют DATAREON оптимизировать использование ресурсов предприятий-клиентов в результате автоматизации управления НСИ.
Для уточнения, каким образом автоматизация управления нормативно-справочной информацией может быть полезна и экономически целесообразна именно для вашего предприятия, пожалуйста, обращайтесь к нам.
Что такое нормативно-справочная информация (НСИ)?
Нормативно-справочная информация — условно-постоянная составляющая общей корпоративной информации. Она используется при регламентации деятельности компании, обеспечивая «сшивку» данных, сопровождающих бизнес-процессы компании. Другими словами, НСИ — это ядро единого информационного пространства организации, включающее в себя набор справочников, словарей, классификаторов, стандартов, регламентов, используемых в деятельности предприятия.
Предпосылки для организации централизованного управления нормативно-справочной информацией
Создание единого информационного пространства — необходимое условие эффективного управления современными крупными и средними предприятиями. Формирование единой среды предполагает интеграцию управленческих процессов, сопровождающуюся нормализацией информационных потоков. Часто перемещение информации на разных внутрикорпоративных технологических участках поддерживается различными информационными и учетными системами. Соответственно, возникает необходимость интеграции этих систем.
Задача интеграции информационных и учетных систем состоит из двух взаимосвязанных частей: интеграции данных и следующей за ней интеграции приложений. Выполняя интеграцию данных, предприятию следует провести унификацию и стандартизацию нормативно-справочной информации.
Для чего необходимо централизованное управление НСИ
Менеджеры DATAREON будут рады ответить на все вопросы по тел. +7(495)280-08-01. Также вы можете написать нам через форму
Анатомия системы НСИ
Данная статья основана на реальных событиях,
и все проблемы в ней не вымышленные. (С)
В начале хотелось бы отметить, что статья не призвана показать изобретение велосипеда, потому как многие приёмы уже давно существуют в культуре разработки баз данных. Однако обобщить, проанализировать проблемы, которые они могут решить и показать, как с ними можно работать. А проблем хватает несмотря на то, что нормативно-справочная информация (НСИ) не относится к бизнес-логике, а скорее находится в обслуживании у неё. Стандартный процесс по рисованию очередной таблички для хранения справочника очень скоро начинает обрастать костылями или трудоёмкими переделками.
Вот и в моём случае оказалась та же картина — система стоит на продуктиве более десяти лет, строилась по тому же принципу, если что нужно, рисуем и включаем в оборот. Таким образом были созданы несколько таблиц для хранения разного рода оборудования. Но вот пришёл час Х, когда стало необходимо добавить ещё пару таблиц для нового оборудования и при этом все (включая старые) должны входить в определённую группу. Это значит, что ссылки на разные таблицы должны быть включены в кросс-таблицу между группой и всеми пятью видами оборудования, то есть для каждого своё поля с констреинтом на соответствующую таблицу. А если ещё одно добавится, менять структуру. И обработку нужно делать в зависимости от того, какие поля заполнены. Вот и возникает первая проблема, как разные таблицы обобщить, что бы с ними одинаково можно было работать и не менять структуру, если добавляется ещё одна. Замечательная мысль, создаём отдельную табличку, которая призвана хранить абстрактное понятие оборудование с указанием типа, а тогда остальные таблички ссылаются по внешнему ключу на своего родителя. На этой радостной волне мы заливаем в созданную табличку записи из одной и пытаемся тоже сделать для другой. Но что-то пошло не так, сработало ограничение первичного ключа, к чему бы это? А к тому, что на заре бурной молодости системы для каждой табличке были свои сиквенсы. Конечно, со временем это безобразие поправили, но старые ключи всё равно остались. Более того, они корнями проросли по внешним ключам с другими таблицам. Фиксируем вторую проблему, связанную со сквозной нумерацией всех справочников.
На этом мучения с таблицами оборудования не закончились. Потому как по последним требованиям оборудование имеет различные характеристики, более того их число переменно, а одна характеристика может иметь несколько значений. А значит появляется третья проблема, а именно иметь возможность хранить переменное число характеристик какой-то записи.
Вроде как с этим справились, но заказчик не дремлет, у него всегда есть наготове что-нибудь новенькое. И вот приходит требование — все справочники историчные (например, название продукта было одним, а потом его переименовали, и по документам на разные даты нужно показывать актуальное название). Само по себе требование нормальное, ничего не скажешь. А если ещё в отделе разработки есть кто-то, кто проходит испытательный срок, так вообще всё в шоколаде, можно и не заметить, что это проблема. Однако проходит всё, как обычно — с полным авралом, а тут ещё этим нужно заниматься. Создаём таблички, дублирующие таблицы соответствующих справочников для того, чтобы там хранить хронологию изменений справочника. Но, создавая эти таблицы, мы заодно создаём себе четвёртую проблему, теперь в коде нужно в зависимости от даты обращаться то ли к основной таблице, то ли к исторической.
Ну мы же молодцы, мы и это победили))) Теперь, попивая чай из своей кружки, начинаешь дискутировать с другими коллегами на тему, что им приходилось решать, и понимаешь, что список проблем пополняется. В обсуждении стоит вопрос как хранить версии одной и той же записи. Хочу оговорится, что версия, это не то, что укладывается в таблицу историчности. В историчности понятно, до такого-то числа было одно название, а начиная с этой даты актуальным становится другое. А в версионности подразумевается, что запись была сначала сохранена с ошибкой, а через несколько часов это поняли и её изменили, и нужно знать все состояния этой записи. Во-первых, здесь должно быть дробление на время, не только сутки. А во-вторых, такие следы нужны в случае разборок. Например, заполняли прайс, ошиблись, успели товар продать по такой цене, а потом поправили, но в конце дня случился дебаланс. Однако решение для таких ситуаций меня лично напрягло, предлагалась все такие изменения хранить в самой таблице. Не буду устраивать холивар на сколько так правильно, но для меня точно обозначилась пятая проблема, а именно хранение изменений записей.
Итак, обобщая вышесказанное мы видим перед собой пять увесистых грабель. Теперь наша задача определить стратегию, позволяющую обойти и не наступить на них.
Сколько можно наступать на одни и те же грабли, давайте скинимся и купим новые
Начиная проектировать систему с нуля, никто не может предугадать путь её развития, а значит не сможет сказать на каком уровне придётся обобщать, как в описанном примере с оборудованием. Поэтому имеет смысл сразу задать абстрактную сущность, распространяемую на все таблицы НСИ. Таким образом все справочники будут иметь прообраз в едином справочнике с разделением на типы.
Таблица nsi_type системная, заполняется по мере добавления новых справочников. Таблица nsi хранит ключи и системные поля. Заодно создаём собственный сиквенс и тем самым закрываем вторую проблему.
Так же создадим пакет, содержащий основную функциональность по работе со справочниками и будем его постепенно заполнять.
Здесь пока представлены вспомогательные функции для обеспечения необходимой инфраструктуры.
Итак стоит задача создать справочник организаций, куда же без него, любое предприятие контактирует со сторонними организациями — это и поставщики, и клиенты, и партнёры. Сразу добавим соответствующий тип в таблицу nsi_type и определим таблицу nsi_organization.
Теперь, пока не поздно, нужно вспомнить про грабли с номером «пять». Если начнём добавлять записи в созданную таблицу организаций, то это событие нужно где-то фиксировать.
А так же в пакет добавлена функция логирования.
Таким образом разрешена пятая проблема, теперь для любой записи НСИ можно посмотреть, что с ней происходило.
Пытаемся добавить туда организацию.
Конечно мы нарвёмся на констраинт nsi_organization_nsi_fk. Поэтому все справочные таблицы должны быть снабжены необходимой доработкой триггеров.
А теперь добавление записи пройдёт без проблем (ключ уже указывать не надо). Заодно в таблице nsi появится первая запись, а так же в таблице логирования будет зафиксировано это событие.
Но пока можно заметить только дополнительные расходы на создание таблицы какого-то справочника, а никак не преимущество единого подхода. Тогда вспомним про четвёртую проблему — нам необходимо хранить историчность данных в таблицах справочника, а так же извлекать актуальное состояние на заданную дату.
В пакет pkg_nsi добавим функцию сохранения записи в историческую таблицу. Хранить запись будем в формате json, поэтому в пакете так же появится возможность получить json для переданного запроса.
Таким образом любой справочник может воспользоваться этой функцией, чтобы увести в историю текущее состояние. Уже хорошо, хоть что-то полезное появилось от такого обобщения))) Для извлечения актуального состояния справочника добавим в пакет соответствующую pipeline-функцию. Записи справочника будут возвращаться в тип, расширенный системными полями.
Применим к нашей таблице nsi_organization.
Функция nsi_organization_table очень полезна, потому как удовлетворяет нашим требованиям и окончательно уводит проблему номер четыре в прошлое.
Идём дальше. Раз у нас появилось такое преимущество с введением единого подхода для работы со всеми справочниками, то воспользуемся им и для хранения дополнительной информации, которой может быть наделена любая запись из любого справочника. Такое механизм уже давно существует, называется EAV-pattern, его и реализуем.
Очень часто в контексте документов имена собственные необходимо использовать в каком-то падеже, поэтому создадим новую таблицу с физическими лицами и по аналогии с организациями добавим обработку триггеров и тип для выборки.
Осталось дополнить пакет pkg_nsi обработкой этой таблицы.
И добавим кого-нибудь в эту таблицу.
Создадим атрибуты для самого востребованного родительного падежа.
В пакете pkg_nsi добавим функции для работы с атрибутами справочников.
Теперь присвоим соответствующие атрибуты.
Таким образом мы победим третью проблему.
Кроме таблиц справочников в системе НСИ также важны отношение между ними. Так, например крупные организации включают в себя различные подразделения, филиалы, отделы и т.п., которые можно выстроить в древовидную структуру. Для начала заведём в нашей системе ещё несколько организаций, которые будут в подчинении у уже существующей «Рога и копыта».
Теперь нужно показать в каком отношении эти организации находятся между собой. Для этого необходима таблица с древовидной структурой и указанием периода действия, потому как всё подвержено изменением во времени и нужно это учитывать.
Конечно, следует расширить возможности пакета pkg_nsi, чтобы можно было настраивать структуру для различных таблиц.
После появления такого инструмента можно смело выстраивать отношения между организациями.
Так как справочники отделены от структуры, то каждый раз обращаться к организациям с учётом их отношений становится грамозко, поэтому немного упростим себе жизнь.
То, что мы строим дерево это замечательно, но все узлы этого дерева относятся к одной сущности, а наша задача реализовать построение отношения между разными сущностями. Это тоже не проблема, потому как структура не завязывается на какой-то определённый справочник, а работает в целом на всей системе НСИ. Для примера построим классификатор для должностей государственной гражданской службы и классификатор для должностей муниципалитета.
Осталось только заполнить и собрать необходимые классификаторы.
Ой, как это не читабельно!
Следует не забывать, что кроме отношения включения (в том числе и древовидного), существует отношение пересечения, то есть кросс-таблиц. Здесь добавляется дополнительное условие проверки пересечения по времени.
Всё, теперь мы с уверенностью можем сказать, что закрыли первую проблему.
Конечно можно много чего пытаться прикрутить к этой системе, но я думаю, что поставленную задачу в начале статьи я выполнила, а остальное уже можно рассмотреть в процессе дискуссии.
Материал подготавливался на версии Oracle 18c, хотя нативное поддержание формата json уже присутствует в версии 12. Здесь ссылка с архивом скриптов.