3D Accounting

3D toys do, 3D movies do ... Hello, habravchane, no one thought to do 3D accounting, so that the registration of things become intuitive? Nobody had the idea to consider three-dimensional objects in accounting software?

What do you think accounting is doing? Takes into account the things of the real world, which - pay attention - are three-dimensional, hence, it is desirable to take them into account in a three-dimensional form. Do you consider a lathe? Let his image in the accounting software look like reality, so that the fool-less fool could understand that the lathe is for the thing so that no one confuses him with the grinding machine. Yes, someone will have to draw a spatial form, there is no way out of it, but the set of products manufactured by humanity is limited, so in practice it will be about the use of ready-made templates by accountants, no more.
')
No, the main difficulty is not in combining accounting software with AutoCAD, as you might think, but in the accounting methodology .

To create a 3D accounting, you need an object-by-object approach , according to which one real thing in the property complex corresponds to a single database object . The registration of accounting objects lies in the fact that an electronic image is created for the real thing, which can be saved for accounting purposes and manipulated. It is with a point-by-point approach to traditional accounting issues that are so large and long-standing that they cannot be settled, so traditional accounting can only be broken in order to build a new object-by-object system in the empty space.

I have been working on this issue for a long time, I published something on Habré, and in this post I want to draw reader's attention to solving the problem of objectism in my system. The solution is built for two-dimensional conditions, but it can be easy — I mean the accounting methodology, and not something else — applied to three-dimensional objects.

Each object of my system corresponds to the real thing used in the property complex, and is indicated by a square (two-dimensional image). Since each object has some properties that you need to know, and in this case we neglect the possibilities of tabular data display, we have to use the “card” view. The principle is known: the values ​​of the current object are viewed. The user stands on a small object and sees - we put, on the left side of the screen - a set of properties that characterize objects, and the corresponding values ​​of the current object.

At the beginning of the operation of the objects is not registered, the property complex is empty.



Property complex is empty, but you can add an object to it. Choose the command "Add" - the only possible for an empty database.



After specifying the properties, we obtain the object in a graphical (in this case two-dimensional) form.

When an object is selected, its properties are displayed in the left pane.



What can be done with such a graphic object in the system? Same as the real thing in reality:

• change its properties
• merge several objects into one
• split one object into several parts
• and finally delete the object from the system.

Any perturbations are displayed in the working area, for example, splitting a single object in two:



Thus, the working field represents the state of the property complex at the current moment.

Having added a timer to the interface, we are able to see the status of the property complex (the list of its constituent objects) at any time.



If the object is divided at 17:42, then setting the timer to a later time will show the divided objects, and to the earlier one - the single, not yet divided. But if you set the timer for the moment before the object is registered in the system, the working field will be empty, because at the moment no object in the system has yet been registered.

Add, merge, divide, change, delete - try to think of something that does not fit into the named menu items. Well, bold! Transfer material to production? You can change the location of the object, at the same time its name (as is customary in accounting, although it does not make any sense). Upgrading equipment with material counted? This is a combination of material with equipment. Splitting a unit of material into parts? Accordingly, the division. Even the transfer of material to the buyer fits into the above scheme; it is just a change of the subject: it is assumed that the subject takes into account those things in which his name is set by the “Subject” property, respectively, changing the value of this field means that the object is now taken into account by another subject.

I repeat: with the object-by-object approach of one real thing of the property complex, one database object corresponds, no other units are registered as objects .

Those familiar with traditional bookkeeping will ask: “What about commitments?”.

Indeed, the obligations seem to be immaterial: if any thing that constitutes the property complex can be felt, then the obligation is in any way. But this is only because obligations are in fact future things: those that the subject promised, or the subject promised to give in the future. Future things cannot be felt, although they are things that differ from real things only in their intended nature. But speculation (the possibility that a future event may or may not take place) is a general characteristic of the future in comparison with the present, which has already taken place. Therefore, future things - obligations - should also be taken into account as objects, only in a specific way.

Imagine that you promised to give the counterpart a stool. This is the real thing, only the future. Based on the object-by-object approach, you must register the stool's withdrawal: not by today's number, of course, but by the future.

Strictly speaking, there should be two dates:

• date of entry,
• date of the estimated retirement-receipt of the future object.

Otherwise, you will not be able to understand whether the current object or the future one is registered (a commitment).

Suppose now is 09/17/2013 5:42 PM, and you have pledged to pass the stool exactly one week later. You set the right time on the timer and register the change in the object properties by the method indicated above - its transfer to the counterparty. The object in the working window will disappear, then only on the one indicated on the timer and all subsequent moments.





And today's stool will continue to appear in the account, because at the moment it is not given.

When the future number comes, you will give the promised stool, no additional operations will be required. But if, contrary to promises, the stool will not be transferred, it will turn out that the previously made record is wrong: it will have to be corrected by moving the expected date of transfer away to the future.

As you can see, with the object-by-object approach, only things are registered, and for the entire time extent. This approach has been implemented by me - unfortunately, only at the level of methodology, and not of accounting software.

For the finishing touch - the achievement of the 3D effect - it is enough to take into account the spatial shape of the objects. How I don’t know: probably the same one that takes 3D into account in AutoCAD and similar design systems. But in any case we are talking about small things: the introduction of additional properties of the object into the system while preserving its principles and logic of work. The presence of the component parts in the system is monitored automatically in my system, at the level of the methodology, there will be no problems with this.

As a result, the user will receive an account of three-dimensional things, consisting of components, up to the elementary. Each such component, as well as the thing as a whole, can be viewed from all sides, and if you fully implement my concept, then you can trace the history of each part (in particular, by whom and when the part was produced), as a result of which the accounting will be complete and visual .



Is visibility, implemented with the help of 3D accounting, is it bad?

Unfortunately, the idea of ​​three-dimensionality is incompatible with the current traditional accounting department due to the lack of the object approach in the latter. One real thing in it does not correspond to a single image - the object of the accounting system. I do not want to repeat, anyone can see the post “Is the concept of an accounting object relevant?” . And imagine that in traditional accounting, each object will begin to be denoted by a square (flat picture), or a cube, or, God forbid, a spatial form. How would you like to designate depreciation, or retained earnings, or a reserve for doubtful debts, what spatial form of these false objects can you tell? Also, the infamous debits and credits that do not have strict conformity in the reality taken into account are incompatible with the point-by-point approach. And when item-by-item accounting, things are recorded in strict accordance with their actual existence: first arrival, then consumption — there are no such disgraces as liabilities coming in on a loan and leaving on debit in a normal accounting system, of course, cannot be. It is for this reason — due to the lack of object-based accounting — that the 3D approach will never be implemented in existing accounting software: objects will continue to be denoted by faceless table entries that everyone can endure.

Hey, habravchane! Which accounting do you think is better: tabular or spatial 3D, in which each of the objects to be counted can be rotated “in hands” and examined, even up to virtual disassembly into its component parts, and even spread out on virtual shelves (which may well imitate the shelves of real warehouse)?