Is the concept of an accounting object relevant?

In continuation of educational program on accounting information technologies.
Accounting is intended to register things involved in economic activities. The simplest follows from this: one thing to be registered must be designated by a certain unit, which it is customary to call an object of accounting. Thus, one object of the real world must correspond to one object registered in the database - for me this is obvious.
The evidence is obvious, but the current practice is not that. Below, I intend to consider the deviations of the accounting methodology from the rule “one thing - one object”, so that habravchane - from those who are not familiar with accounting, - could make their own impression about it. I would also be curious to find out how accounting techniques relate to programming: whether they are permissible, according to programmers, or by no means.

The normal registration of a thing, that is, the normal consideration is the situation: one thing is 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 the thing in the database, that is, in relation to the object of accounting.
But in practice? Oh, accounting practice is diverse - let's consider its deviations in order.

1. Many things - one object.
Most things are counted in quantity accounting. This means: all homogeneous things (which are taken as such in the formulation of accounting) are taken into account as a single object of accounting. This object has a special characteristic - a quantity denoting the number of homogeneous things in this object.
On the practical side, it is unwise to take into account a bunch of identical items in the form of each item separately. This is true, but sometimes leads to an unpleasant incident, namely, the need to evaluate items by their retirement (methods FIFO, LIFO, average and so on.). When items with different costs fall into one heap, accountants have to wriggle out to determine which item they pulled out of the heap when selling, and since it is impossible — the items in the heap are the same — you have to act from the flashlight that the accounting methodology does not paint.
In general, from a theoretical point of view, a pile of hundreds of bricks and a hundred individual bricks in the aggregate are completely different objects. Roughly speaking, items with different properties, even such imperceptible as cost, should not fall into a heap, but the accounting methodology does not have these capabilities.
Correctly - that is, item-by-object - in accounting, only the used tools (buildings, structures, equipment, machines) are taken into account, due to the irrationality of their folding into a pile.
')
2. The object is - no things.
Accounting takes into account - as objects - what is not in reality: this, namely, the accounting of liabilities and capital, was mentioned in the previous post .
I will not repeat, but I will remind you:
The current methodology, due to the fact that it cannot record two dates within one accounting entry: current and future, is forced to register the obligations as objects of accounting. The posting date must be one; the current liability is recorded instead of the future object;
capital is registered for balancing (many believe, not without reason, for verification purposes, but in this case something else is important - that the object is registered, and the thing corresponding to it in reality is missing).
Thus, obligations are like projections of future objects at the current moment, while capital is a calculated value, such as profitability, turnover and so on. Registration of both, in an amicable way, should not be.

3. Thing is - there is no object.
It happens the other way around: there is a thing in the enterprise, and it is visual and legally significant, but - I suppose, it is not registered in accounting.
The most significant and common case is workers. Indeed, own employees in accounting are not registered, I mean - as an object of accounting. The salary paid to them is money, but not the employees of the enterprise, who, despite their animation, still belong to the physical world, and thus are things used in economic activity.
The reason for non-registration of workers is purely methodological: the applied methodology is poorly adapted for registering rental items (using workers in the household like leasing tools is not in the legal sense, of course, but in fact: the company pays the employee a specified amount and uses it during the period).
It can be argued that it is irrational to register workers as objects of accounting, but the fact remains: there is a thing — there is no object.
There is a second case of non-registration of things as objects, no less glaring: there are no liabilities registered in accounting until the moment the conditions of a transaction are fulfilled by one of the parties.
Imagine that a contract of sale has been concluded: the seller has undertaken to send the goods, the buyer has to transfer money, all at the same time. We have counter obligations of the seller and the buyer. Do you think they are registered? Not necessarily: the contract signed and entered into force will not be reflected in the accounting records until at least one of its parties fulfills their obligations - only then, but not before, the relevant objects will be registered in the accounting department.
The funny thing is that the accounting legislation prescribes to take into account all obligations, without exceptions. However, accounting practice is of the opinion that is different from the legislative prescriptions - I suppose that for the sake of convenience, to make contracts with back numbers.

4. One thing is a lot of objects.
The last nominal opportunity to make a mistake - did you really think that accounting does not use it ?! Uses, and quite widely.
Situations when there is one thing are extremely common, but two objects are used to designate it:
the object denoting the thing itself,
and an object denoting a cost difference.
Suppose some thing costs 100 rubles. How much is, at this cost, and is taken into account. However, time passes and it turns out that the thing has fallen in price by 15 rubles. It is necessary to preserve both the accounting 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 an object (field) to the base, so that the object is characterized not by one numerical field, but by two. There was an object with properties: [Book value] = 100 rub. and [Market value] = 100 rubles., became the same object with the properties [Accounting value] = 100 rubles. and [Market value] = 85 rub. In other words, the object has changed one of its characteristics.
Accounting methodology is not like this: it registers a change in one accounting object by registering another (!) Accounting object. In our example, there is a decrease in cost, so the object must be registered with the opposite sign: on the loan (expense). We receive the first object registered on the debit (arrival) in the amount of 100 rubles. and the second object registered on the loan (expense) in the amount of 15 rubles. If we want to calculate the market value of things, from 100 rubles. we need to take 15 rubles., we get the desired 85 rubles.
These, in terms of methodology, are estimated reserves, depreciation and some other accounting items.

In view of the above, it is rather difficult to consider the notion of an accounting object as relevant, do you not find?