В продолжение ликбеза по бухгалтерским информационным технологиям.
Бухгалтерия предназначена для того, чтобы регистрировать участвующие в хозяйственной деятельности вещи. Отсюда вытекает простейшее: одна регистрируемая вещь должна обозначаться некоей единицей, которую принято называть объектом бухгалтерского учета. Таким образом, одной вещи реального мира должен соответствовать один объект, зарегистрированный в базе данных, – для меня это сама очевидность.
Очевидность очевидностью, но действующая практика не такова. Ниже я намерен рассмотреть отступления бухгалтерской методологии от правила «одна вещь – один объект», с тем чтобы хабравчане – из тех, кто не знаком с бухгалтерией, – смогли составить о ней собственное впечатление. Мне же будет любопытно узнать, как бухгалтерские приемы соотносятся с программированием: допустимы ли они, по мнению программистов, или ни в коем случае.
Нормальной регистрацией вещи, то есть нормальным учетом является ситуация: одна вещь – один объект. Происходит изменение текущего состояния вещи (она поступает, или выбывает, или изменяет свои свойства) – данный факт соответствующим образом регистрируется: применительно к образу данной вещи в базе данных, то есть применительно к объекту бухгалтерского учета.
А на практике? О, бухгалтерская практика многообразна – рассмотрим ее отступления по порядку.
1. Много вещей – один объект.
Большинство вещей учитывается в бухгалтерии по количеству. Это означает: все однородные вещи (которые приняты за таковые при постановке бухгалтерского учета) учитываются в качестве единого объекта бухгалтерского учета. Данный объект обладает особой характеристикой – количеством, обозначающим число однородных вещей в этом объекте.
С практической стороны неразумно учитывать кучу одинаковых предметов в виде каждого предмета по отдельности. Это истинно, но иногда приводит к неприятному казусу, а именно к необходимости оценивать предметы по их выбытии (методы ФИФО, ЛИФО, средней и проч.). Когда в одну кучу попадают предметы с разной стоимостью, бухгалтерам приходится выкручиваться, чтобы определить, какой предмет они вытащили из кучи при продаже, а поскольку это невозможно – предметы в куче одинаковые, – приходится действовать от фонаря, что бухгалтерскую методологию не красит.
Вообще, с теоретической точки зрения куча из сотни кирпичей и сотня отдельных кирпичей в совокупности – совсем разные объекты. Грубо говоря, в кучу не должны попадать предметы с разными свойствами, хотя бы такими неощутимыми как стоимость, однако бухгалтерская методология данными возможностями не обладает.
Корректно – то есть пообъектно – в бухгалтерии учитываются лишь используемые орудия труда (здания, сооружения, оборудование, машины), ввиду нерациональности складывания их в кучу.
2. Объект есть – вещи нет.
Бухгалтерия учитывает – в качестве объектов – то, чего нет в действительности: об этом, а именно об учете обязательств и капитала, говорилось в предыдущем посте.
Не стану повторяться, но напомню:
действующая методология – вследствие того, что не может записывать в рамках одной бухгалтерской проводки две даты: текущую и будущую, – вынуждена регистрировать обязательства в качестве объектов бухгалтерского учета. Дата проводки должна быть одна, вместо будущего объекта регистрируется текущее обязательство;
капитал регистрируется для балансировки (многие не без основания считают, что в проверочных целях, но в данном случае важно другое – то, что объект регистрируется, а соответствующая ему в реальности вещь отсутствует).
Таким образом, обязательства являются как бы проекцией будущих объектов на текущий момент, тогда как капитал – расчетной величиной вроде рентабельности, оборачиваемости и проч. Регистрации обоих, по-хорошему, быть не должно.
3. Вещь есть – объекта нет.
Случается и наоборот: вещь на предприятии имеется, причем наглядная и юридически значимая, но – поди ж, в бухгалтерском учете не регистрируется.
Самый показательный и общераспространенный случай – это работники. Действительно, собственные работники в бухгалтерском учете не регистрируются, я имею в виду – в качестве объекта учета. Выплачиваемая им зарплата – это деньги, но никак не работники предприятия, которые, несмотря на свою одушевленность, принадлежат все-таки физическому миру, тем самым являются используемыми в хозяйственной деятельности вещами.
Причина нерегистрации работников – чисто методологическая: применяемая методология плохо приспособлена к регистрации предметов аренды (использование в хозяйстве работников подобно аренде орудия труда – не в юридическом смысле, конечно, но фактически: предприятие платит работнику оговоренную сумму и использует его в течение периода).
Можно возразить, что регистрировать работников в качестве объектов учета нерационально, но факт остается фактом: вещь есть – объекта нет.
Имеется и второй случай нерегистрации вещей в качестве объектов, не менее вопиющий: в бухгалтерском учете не регистрируются обязательства до момента исполнения условий сделки одной из сторон.
Представим, что заключен договор купли-продажи: продавец обязался переслать товар, покупатель – перечислить деньги, все одновременно. Имеем встречные обязательства продавца и покупателя. Вы полагаете, они регистрируются? Не обязательно: подписанный и вступивший в силу договор не получит в бухгалтерском учете отражения до тех пор, пока хотя бы одна из его сторон не выполнит свои обязанности – только тогда, но не ранее в бухгалтерии будут зарегистрированы соответствующие объекты.
Самое смешное, что бухгалтерское законодательство предписывает учитывать все обязательства, без исключений. Однако бухгалтерская практика придерживается мнения, отличного от законодательных предписаний, – предполагаю, что ради удобства составлять договоры задними числами.
4. Одна вещь – много объектов.
Последняя номинальная возможность ошибиться – неужели вы думали, что бухгалтерия ее не использует?! Использует, и весьма широко.
Чрезвычайно распространены ситуации, когда вещь одна, но для ее обозначения используется два объекта:
объект, обозначающий саму вещь,
и объект, обозначающий стоимостную разницу.
Предположим, какая-то вещь стоит 100 руб. Сколько стоит, по такой стоимости и учитывается. Однако проходит время и выясняется, что вещь подешевела на 15 руб. Необходимо сохранить и учетную стоимость, и одновременно зафиксировать рыночную. Как в таком случае должен поступить программист? По моему дилетантскому мнению, следующим образом: добавить в базу новое свойство объекта (поле), чтобы объект характеризовался не одним числовым полем, а двумя. Был объект со свойствами: [Учетная стоимость] = 100 руб. и [Рыночная стоимость] = 100 руб., стал тот же объект со свойствами [Учетная стоимость] = 100 руб. и [Рыночная стоимость] = 85 руб. Другими словами, объект изменил одну из своих характеристик.
Бухгалтерская методология не такова: она регистрирует изменение одного объекта бухгалтерского учета посредством регистрации другого (!) объекта бухгалтерского учета. В нашем примере имеет место уменьшение стоимости, поэтому объект должен быть зарегистрирован с противоположным знаком: по кредиту (расходу). Получаем первый объект, зарегистрированный по дебету (приходу), в сумме 100 руб. и второй объект, зарегистрированный по кредиту (расходу), в размере 15 руб. Если мы захотим вычислить рыночную стоимость вещи, от 100 руб. нужно отнять 15 руб., получим искомые 85 руб.
Таковы, в плане методологии, оценочные резервы, амортизация и некоторые другие объекты бухгалтерского учета.
Ввиду сказанного довольно сложно считать понятие объекта бухгалтерского учета релевантным, вы не находите?