Учет видов и разрезов информации в базе данных

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

Текущее состояние вопроса

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

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

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

Текущие проблемы в части «видов» и «разрезов» учетной информации

С самого начала внедрения учетных программ (90-е гг. ХХ в.) существуют и постоянно нарастают проблемы следующего вида.

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

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

В-третьих, растет необходимость хранения нормативных данных в базе. Количество и объем кодовых классификаторов постоянно растет, и эта тенденция долгосрочная. Чтобы ей соответствовать, необходимо держать в базе образцы кодов и нормативные кодовые данные. Опять же, как хранить нормативные данные кодов и реальные данные кодов без разрастания количества таблиц?

В-четвертых, существует потребность хранения заказов и заявок (разных видов и для разных целей). Предварительные заказы являются мощным трендом и двигателем торговли, их важность неоспорима. Потенциальные заказы оформляются менеджерами как полупрогнозы-полупланы.

В-пятых, есть еще и другие проблемы.

И что же может предложить традиционная «классическая триада» для решения всех этих проблем? Ничего. Более того, застывшая «классическая триада» не предлагает также способов своего динамического расширения (без ресурсоемкой реструктуризации базы) и, таким образом, не имеет путей и планов дальнейшего развития и удовлетворения учетных нужд, не предлагает новых способов соответствия меняющимся требованиям времени, не имеет видения будущего и перспективы.

Предлагаемое разделение учетной информации на «виды» и «разрезы»

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

С точки зрения характера информации предлагается ввести новое понятие – «разрез».Приведем примеры «разрезов учетной информации» (ниже они будут все объяснены): факт (учет), бюджет, план, отчет, заявка, предварительный заказ, потенциальный заказ, норматив (нормативные данные), дополнение (поправка, уточнение), дубликат, прогноз.

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

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

Впрочем, предлагаемое деление довольно условно. Автор предлагает снабдить все таблицы учетной БД этими двумя новыми полями (вместо поля «классической триады») и выстроить логику манипулирования данными, опираясь на «виды» и «разрезы» информации.

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

Вид информации «факт (учет)»

«Факт» – это основной вид информации учетной БД, и он присутствует в каждой таблице и каждой строке, которая отражает фактическую учетную информацию. Практически все время бухгалтер имеет дело именно с «фактом», с фактической учетной информацией. Это выглядит примерно так (для краткости поля записей базы данных ограждены косыми чертами):

Для проводки:

Факт/дата = 23.03.2017/счет дебета = 1330/количество = 34/сумма = 67 564/…и т. д. Это означает фактическую проводку, то есть которая учтена реально.

Для заголовка документа:

Факт/дата = 23.03.2017/вид документа = пр">

...