Бухгалтерия 3D

Игрушки 3D делают, фильмы 3D делают… Алло, хабравчане, никто не думал сделать 3D бухгалтерию, чтобы регистрация вещей стала интуитивно понятной? Никому не приходила в голову мысль учитывать в бухгалтерском софте трехмерные объекты?

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

Нет, основная сложность не в совмещении бухгалтерского софта с AutoCAD, как вы могли подумать, а в учетной методологии.

Для создания 3D бухгалтерии необходим пообъектный подход, в соответствии с которым одна реальная вещь, находящаяся в имущественном комплексе, соответствует одному объекту базы данных. Регистрация объектов учета в том и заключается, что для реальной вещи создается электронный образ, который можно сохранять в учетных целях и которым манипулировать. Именно с пообъектным подходом у традиционной бухгалтерии нелады, настолько большие и давние, что никакому урегулированию не подлежат, поэтому традиционную бухгалтерию можно только поломать, чтобы на освободившемся месте построить новую пообъектную систему.

Я данным вопросом давно занимаюсь, кое-что публиковал на Хабре, а в настоящем посте хочу обратить читательское внимание на решение проблемы пообъектности в моей системе. Решение построено для условий двухмерности, но может быть легко – я имею в виду учетную методологию, а не что-то иное, – применено к трехмерным объектам.

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

В начале работы объектов не зарегистрировано, имущественный комплекс пуст.



Имущественный комплекс пуст, но в него можно добавить объект. Выбираем команду «Добавить» – единственно возможную для пустой базы.



После указания свойств получаем объект в графическом (в данном случае двухмерном) виде.

Когда объект выбран, его свойства отображаются на левой панели.



Что можно сделать с таким графическим объектом в системе? То же, что с реальной вещью в действительности:

• изменить его свойства,
• объединить несколько объектов в один,
• разделить один объект на несколько частей
• и, в завершение, удалить объект из системы.

Любые пертурбации отображаются в рабочем поле, например разделение одного объекта надвое:



Таким образом, рабочее поле представляет собой состояние имущественного комплекса на текущий момент.

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



Если объект разделен в 17:42, тогда установка таймера на более позднее время покажет разделившиеся объекты, а на более раннее – единый, еще не разделившийся. Но если установить таймер на момент до регистрации объекта в системе, рабочее поле окажется пустым, ведь на данный момент ни одного объекта в системе еще не зарегистрировано.

Добавить, объединить, разделить, изменить, удалить – попробуйте придумать что-нибудь, что не укладывается в названные пункты меню. Ну, смелей! Передать материал в производство? Можете изменить местоположение объекта, заодно его название (так принято в бухгалтерии, хотя не имеет никакого смысла). Модернизация оборудования при помощи учитываемого материала? Это объединение материала с оборудованием. Разделение единицы материала на части? Соответственно разделение. Даже передача материала покупателю укладывается в приведенную схему, это всего лишь изменение субъекта: предполагается, что субъект учитывает те вещи, в которых по свойству «Субъект» проставлено его имя, соответственно изменение значения по данному полю означает, что отныне объект учитывается другим субъектом.

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

Знакомые с традиционной бухгалтерией спросят: «А обязательства?».

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

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

Строго говоря, должно быть указано две даты:

• дата внесения записи,
• дата предполагаемого выбытия-поступления будущего объекта.

В противном случае вам не удастся понять, регистрируется текущий объект или будущий (обязательство).

Допустим, сейчас 17.09.2013 17:42, а вы обязались передать табуретку ровно через неделю. Устанавливаете на таймере нужное время и регистрируете указанным выше способом изменение свойств объекта – его передачу контрагенту. Объект в рабочем окне исчезнет, то только на указанный на таймере и все последующие моменты.





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

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

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

Для завершающего штриха – достижения 3D-эффекта – достаточно учитывать пространственную форму объектов. Каким образом, не знаю: вероятно, тем же самым, которым трехмерность учитывается в AutoCAD и аналогичных системах проектирования. Но в любом случае речь идет о малом: о введении в систему дополнительных свойств объекта при сохранении ее принципов и логики работы. Наличие у объекта составных частей отслеживается в моей системе автоматически, на уровне методологии, с этим проблем не возникнет.

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



Разве наглядность, реализуемая при помощи 3D бухгалтерии, – это плохо?

К сожалению, идея трехмерности несовместима с действующей традиционной бухгалтерией из-за отсутствия в последней пообъектного подхода. Одной реальной вещи в ней вовсе не соответствует единственный образ – объект учетной системы. Не хочу повторяться, желающие могут посмотреть пост «Релевантно ли понятие объекта бухгалтерского учета?». А представьте, что в традиционной бухгалтерии каждый объект начнет обозначаться квадратиком (плоской картинкой), или кубиком, или, не дай Бог, пространственной формой. Как прикажете обозначать амортизацию, или нераспределенную прибыль, или резерв по сомнительным долгам, какая у этих лже-объектов пространственная форма, не подскажете? Также несовместимы с пообъектным подходом печально известные дебет и кредит, не имеющие строгого соответствия в учитываемой реальности. А при пообъектном учете вещи регистрируются в строгом соответствии с их действительным существованием: сначала приход, затем расход, – такого безобразия, как пассивы, поступающие по кредиту и выбывающие по дебету, в нормальной учетной системе нет, разумеется, и быть не может. Именно по этой причине – из-за отсутствия пообъектного учета – 3D-подход никогда не будет реализован в существующем бухгалтерском софте: объекты продолжат обозначаться безликими табличными записями, которые все стерпят.

Эй, хабравчане! Какая бухгалтерия, по вашему мнению, лучше: табличная или пространственная 3D, в которой каждый из учитываемых объектов можно повертеть «в руках» и рассмотреть, вплоть до виртуальной разборки на составные части, и даже разложить по виртуальным полочкам (которые вполне могут имитировать полки реального склада)?