Тринадцать лет назад я изобрел ЯОФ – язык отчетных форм, и даже включил его в качестве главы в свой бухгалтерский учебник.
Нет-нет, я не намерен смешить уважаемых хабравчан образцами «кода», благо сразу после своего рождения ЯОФ благополучно скончался, никому не интересный и не нужный, даже его изобретателю. Язык скончался, но проблема, которую он пытался решить, – в силу того, что ей мало кто занимался и сейчас не занимается, – осталась не решенной. Решение данной проблемы может представлять определенный интерес не только для бухгалтеров, но и для программистов.
Сейчас я попытаюсь объяснить, в чем дело.
Кто из вас не видел бухгалтерские отчеты – бесчисленные и неудобоваримые формы, которые бухгалтеры заполняют финансовыми показателями?! Мне с самого начала было понятно: раз формы строятся на основании базы данных, имеющей определенную структуру, должны существовать некие типовые алгоритмы их построения – не частные применительно к каждому случаю, а именно типовые. Речь шла о том, чтобы заменить текстово-табличное описание бухгалтерских отчетов, при котором каждый показатель подсчитывается отдельно, на описание формально-математическое, при котором любой отчет есть результат стандартных процедур, выполненных с исходной базой.
Приводить здесь изобретенный мной «код» не рискну по причине его полной беспомощности, однако от логики, которая двигала мной в тот далекий момент, я не отказался по сей день. Возможно, мои рассуждения натолкнут кого-нибудь из айтишников на дельные мысли. Короче, информация к размышлению.
Решив создать язык отчетных форм, я первым делом разделил отчеты на неструктурированные и структурированные:
- в неструктурированных отчетах показатели, каждый из которых рассчитывается отдельным образом, помещаются в таблицы или расставляются по листу произвольным образом, сопровождаемые текстовыми названиями и пояснениями;
- структурированные отчеты – напротив, отчеты с четкой структурой: в виде таблиц, полученных из исходной базы путем некоторых ее преобразований.
От формализации неструктурированных отчетов пришлось отказаться, ввиду их очевидной для меня «некомпьютерности».
«Только структурированные отчеты, только преобразованные таблицы», – сразу установил я для себя, однако преобразование уперлось в отсутствие исходного образца.
Легко преобразовать что-то во что-то, когда известна начальная структура, а если нет? Как поступить при наличии множества способов регистрации учетных данных и практически бесконечного числа возможных структур? Напоминаю, меня интересовали типовые способы преобразований, в результате которых можно было бы получать форму отчета не в виде формы с инструктивными пояснениями, а в виде программного – понятного не только программисту, но и бухгалтеру – кода. Выход был единственный: принять за образец какую-нибудь структуру и от нее отталкиваться. В этом случае учетные базы со стандартной, принятой за образец структурой могли быть использованы при генерации отчетов напрямую, а базы с нестандартной структурой требовалось первоначально свести к базе со стандартной структурой.
Базу со стандартной структурой я назвал нормализованной таблицей. Приведение любой учетной базы к нормализованной таблице было возможно, так как любая из интересовавших меня баз была учетной: в ней регистрировались некие объекты, что требовало определенной структуры данных, выражаемой перечнем свойств и измерителей.
В приводимой простейшей нормализованной таблице каждая строка обозначает один объект, S – это свойства объектов, а i – измерители:
Довольно очевидно, что, как ни изощряйся со структурой учетной базы данных, в конечном (простейшем) варианте все сводится к регистрации объекта, описанию его свойств и измерителей.
Строго говоря, измерители не являются обязательным элементом учетной базы данных: базовый для учета измеритель – количество – может быть получен путем преобразования таблицы как число записей-объектов после выборки.
Допустим, i1 и i2 обозначают что-то другое, не количество объектов, а нам необходимо оперировать количеством объектов по свойству S1. Откидывая ненужные нам свойства, получаем таблицу для преобразования.
Затем выполняем преобразование, подсчитывая количество объектов (i3) с каждым значением по полю S1.
Возникает новый, отсутствовавший в исходной таблице измеритель.
Аналогичным образом могут быть получены средние величины.
Но предположим, все необходимые измерители в исходной таблице на месте – спрашивается, какие типовые преобразования необходимы при генерации бухгалтерских отчетов? Таким вопросом я задался и долгое время пытался свести известные мне многообразные бухгалтерские отчеты и ведомости (по счастью, только структурированные) к типовым преобразованиям.
Некоторые необходимые преобразования – в первую очередь перестановку столбцов таблицы, транспонирование, выборку и сортировку – я по причине их очевидности сразу опускал: меня интересовали истинно бухгалтерские способы. В результате длительных размышлений таковых отыскалось всего два.
Первый – довольно известный: задание свойств по иерархии.
Берем исходные данные (используем только свойства S1 и S2 и измеритель i1 – то есть после некоторой выборки):
Задаем следующую иерархию:
Имеем в результате преобразования:
В бухгалтерском учете в таких случаях принято писать: в том числе…
Второй способ – вынесение свойства в заголовок (данному способу ни в бухгалтерском учете, ни в информатике не было названия, пришлось выдумывать самому).
Речь идет о следующем.
Берем нашу исходную нормализованную таблицу:
Затем одно из свойств объекта – допустим, S3 – выносим в заголовок, в область измерителей, со следующим результатом:
Данные идентичны, но вид таблицы совершенно другой. Почему нет, если так хочется пользователю отчетности – тому, для кого отчетные данные предназначены?
Очевидно, что выносить в заголовок можно согласно иерархии – задать такую иерархию, к примеру:
В этом случае возникнет следующий табличный вид (приводится фрагмент для первой ветви):
Насколько я понимаю, то же самое могло быть получено путем транспонирования таблицы и задания ее иерархии: значит, вынесение в заголовок – итоговый результат выполненных в определенной последовательности преобразований.
Остальные возможные преобразования нормализованной таблицы – например, итоговые строки – более дизайнерские.
В рассмотренных примерах использованы простейшие исходные данные: в реальной практике база данных усложнена датой и приходом-расходом (в искаженном бухгалтерском варианте дебетом и кредитом), причем приход и расход одного объекта регистрируются не одновременно. Тем самым объект оказывается зарегистрирован дважды: один раз по приходу, второй раз по расходу. Измерители, подсчитанные по поступившим, но не выбывшим объектам образуют сальдо (а в просторечии, остатки). Однако ничего принципиально нового к возможностям преобразования таблиц данный измеритель не добавляет.
Структурированные отчеты могут быть сведены к названным элементарным преобразованиям.
Думается мне, при возникновении необходимости в языке отчетных форм такой язык мог быть довольно быстро написан, и не абсолютным дилетантом в программировании навроде меня, а вполне себе квалифицированным товарищем. Если это когда-нибудь будет реализовано, формы бухгалтерских отчетов приобретут вид программных кодов, что в свете компьютеризации можно только приветствовать. Совсем другой вопрос, насколько это нужно людям, принимающим решения в области бухгалтерского учета. Конечно, кое-какие весьма скромные телодвижения в направлении компьютеризации бухгалтерской нормативки совершаются, но их вряд ли можно назвать достаточными и адекватными.
P.S. Уже закончив статью, я попытался сообразить, кто из бухгалтеров или программистов решал (хотя бы мог решить) ту же задачу.
Из бухгалтеров приходят на память двое, люди в бухгалтерии известные.
Первый – Николай Устинович Попов (1843 — ?). Хотя он жил давно и решал проблему не формализации отчетных форм, а математического обоснования отдельных систем учета. В те времена с программированием обстояло туго, но нет сомнений, будь Николай Устинович нашим современником, его математические способности нашли бы применение.
Под спойлером пара страниц из книги Н.У. Попова «Математический метод бухгалтерии» (1906 г.), чтобы читатели могли оценить, какими категориями мыслил этот человек.
Второй бухгалтер, решавший (и успешно решивший!) проблему формализации бухгалтерских отчетов – наш современник, профессор Олег Иванович Кольвах (род. 1946). Согласно его концепции бухгалтерские отчеты (исходные данные тоже) формализуются в рамках матричной алгебры, отсюда название системы – матричная бухгалтерия.
Под спойлером две страницы из труда О.И. Кольваха «Матричная модель бухгалтерского учета и формирования балансовых отчетов».
Матричная бухгалтерия О.И. Кольваха была создана ранее моего бухгалтерского учебника, я не был с ней тогда знаком, иначе воздержался бы от изобретения ЯОФ. К сожалению, матричная бухгалтерия при всей своей, насколько мне дано судить о математике, математической строгости не получила практического применения.
В бухгалтерской практике применяются языки, связанные с бухгалтерским софтом, в первую очередь с «1С: Предприятием». Насколько данные языки пригодны для использования в качестве универсального языка отчетных форм, не могу судить в силу слабого знакомства с ними. Попытки профессиональных программистов написать такой язык – не по заказу работодателей, а по собственной инициативе – мне неизвестны.
Автор: mikejum
