Is the concept of an accounting object relevant?


    In continuation of the educational program on accounting information technologies.
    Bookkeeping is designed to register things involved in business activities. From this the simplest follows: one thing to be registered should be designated by a certain unit, which is usually called an accounting object. Thus, one thing in the real world must correspond to one object registered in the database - for me it is an obvious fact.
    Evidence is obvious, but current practice is not like that. Below I intend to consider the deviations of the accounting methodology from the rule “one thing - one object”, so that the Habrachians - those who are not familiar with accounting - can make their own impression about it. I will be curious to find out how accounting techniques relate to programming: are they permissible, according to programmers, or in any case.

    The normal registration of a thing, that is, a normal accounting is the situation: one thing - one object . There is a change in the current state of the thing (it arrives, or leaves, or changes its properties) - this fact is recorded accordingly: in relation to the image of this thing in the database, that is, in relation to the accounting object.
    But in practice? Oh, accounting practice is diverse - consider its digressions in order.

    1. Many things - one object.
    Most things are counted in accounting by quantity. This means: all homogeneous things (which are taken as such when setting up accounting) are taken into account as a single accounting object. This object has a special characteristic - the amount denoting the number of homogeneous things in this object.
    On the practical side, it is unreasonable to consider a bunch of identical objects in the form of each object separately. This is true, but sometimes leads to an unpleasant incident, namely to the need to evaluate objects upon their disposal (methods FIFO, LIFO, average, etc.). When objects with different values ​​fall into one pile, accountants have to get out to determine which item they pulled from the heap during the sale, and since it is impossible - the items in the heap are the same, you have to act from the flashlight, which does not paint the accounting methodology.
    In general, from a theoretical point of view, a bunch of hundreds of bricks and hundreds of individual bricks in the aggregate are completely different objects. Roughly speaking, objects with different properties, at least as imperceptible as cost, should not fall into the heap, but the accounting methodology does not have these capabilities.
    Correctly - that is, objectively - in accounting only used tools (buildings, structures, equipment, machines) are taken into account, due to the irrationality of stacking them in a heap.

    2. There is an object - there is no thing.
    Bookkeeping takes into account, as objects, what is not really there: this, namely the accounting for liabilities and capital, was discussed in a previous post .
    I will not repeat myself, but I remind you:
    the current methodology - due to the fact that it cannot record two dates within the framework of one accounting entry: current and future - is forced to register liabilities as objects of accounting. The posting date should be one, instead of the future object, the current obligation is recorded;
    capital is registered for balancing (many people not without reason believe that for verification purposes, but in this case another thing is important - that the object is registered, and the thing corresponding to it in reality is absent).
    Thus, liabilities are, as it were, a projection of future objects at the current moment, while capital is a calculated value such as profitability, turnover and so on. Registration of both, in a good way, should not be.

    3. There is a thing - there is no object.
    It happens the other way around: a thing exists at the enterprise, moreover visual and legally significant, but - well, it’s not registered in accounting.
    The most significant and common case is workers. Indeed, own employees are not registered in accounting, I mean - as an object of accounting. The salary paid to him is money, but not the employees of the enterprise, who, despite their animations, still belong to the physical world, and thus are things used in economic activities.
    The reason for the non-registration of workers is purely methodological: the methodology used is poorly adapted to the registration of rental items (using workers on the farm like renting a tool is not in the legal sense, of course, but in fact: the company pays the employee the agreed amount and uses it for the period).
    It can be argued that registering employees as accounting objects is irrational, but the fact remains: the thing is - the object is not.
    There is a second case of non-registration of things as objects, no less egregious: in accounting, obligations are not registered until the moment the terms of the transaction are fulfilled by one of the parties.
    Imagine that a contract of sale has been concluded: the seller undertook to send the goods, the buyer undertook to transfer the money, all at the same time. We have counter obligations of the seller and the buyer. Do you think they are registering? Not necessarily: a contract signed and entered into force will not be reflected in accounting until at least one of its parties fulfills its obligations - only then, but not earlier, the relevant objects will be registered in accounting.
    The funny thing is that accounting legislation requires that all obligations be considered, without exception. However, accounting practice is of a different opinion from the legal requirements - I suppose that for the sake of convenience, drafting contracts in hindsight.

    4. One thing is a lot of objects.
    The last nominal opportunity to make a mistake - did you really think that accounting did not use it ?! Uses, and very widely.
    Extremely common situations are when a thing is one, but two objects are used to indicate it:
    an object denoting the thing itself
    and an object denoting the cost difference.
    Suppose a thing costs 100 rubles. How much is at that cost and taken into account. However, time passes and it turns out that the thing has fallen in price by 15 rubles. It is necessary to maintain the book value, and at the same time fix the market value. What should a programmer do in this case? In my amateurish opinion, as follows: add a new property of the object (field) to the database so that the object is characterized not by one numerical field, but by two. There was an object with the properties: [Book value] = 100 rubles. and [Market value] = 100 rubles., The same object with the properties [Accounting value] = 100 rubles. and [Market value] = 85 rubles. In other words, an object has changed one of its characteristics.
    The accounting methodology is not this: it registers a change in one accounting object by registering another (!) Accounting object. In our example, there is a decrease in value, therefore, the object must be registered with the opposite sign: for credit (expense). We get the first object registered by debit (receipt) in the amount of 100 rubles. and the second object registered under the loan (expense) in the amount of 15 rubles. If we want to calculate the market value of a thing, from 100 rubles. need to take 15 rubles., we get the desired 85 rubles.
    Such, in terms of methodology, estimated reserves, depreciation and some other objects of accounting.

    In view of the foregoing, it is rather difficult to consider the concept of an accounting object relevant, do not you?

    Also popular now: