AccountLogic 1.0

    I want to share with a reputable audience.

    A year and a half ago, I spoke on Habré with proposals for the creation of a new type of network accounting. Find a man who embodied the idea in code failed (who would doubt it?), And after a while I got to the point savagery of despair that he decided to write the code yourself.

    No sooner said than done: I studied the programming language, as far as it turned out in my weak accounting powers, and wrote.

    The following is a synopsis of what happened as a result of this intellectual epic - in any case, of how it was conceived. I hope that specialists in the field of accounting software will be able to appreciate the novelty of the methodology implemented in the program - although I understand that this is certainly more difficult than to cajole over the efforts of a new programmer.

    "Accountant Logic" is a constructor for accounting things (not only according to accounting rules, but according to natural ones borrowed from nature).

    The interface is ordinary:
    • either a standard table,
    • or more visual icons (with displaying the properties of the current icon in the inverted plate on the left).

    Each thing either arrives or drops out (it is registered according to income or expense , respectively ).

    This is a conceptual moment: any change in a thing is recorded as an expenditure of one thing and the arrival of another thing — at least from the point of view of an external observer, a thing only changes its properties from one to another.

    The traffic light has changed color - for example, from yellow to red - is it the same traffic light or two different traffic lights? Philosophical question: at what moment does a thing change so much that it turns into another thing? You can solve it this way, or you can do it differently: accordingly, transfer the selected method to the program code. “Accountant Logic” decides in such a way that for it the yellow traffic light is one object, and the red traffic light is another: thus, when another light comes on at the traffic light, there is a consumption of the “yellow” traffic light with the simultaneous arrival of the “red” traffic light. Therefore, one action (in this example, lighting another lamp at a traffic light) is performed simultaneously with several things, with one thing in terms of consumption, and with other things in arrival.

    Act- An analogue of what is called posting in accounting: a separate label is provided for its reflection.

    The list of actions carried out in “Accountlogic” does not coincide with that adopted in traditional accounting: not obscure “debit” and “credit”, but meaningful operations with things of the surrounding reality:

    add (that is, add to the accounting system, register in it),
    connect (several things into one),
    change (certain properties of a thing),
    transfer (to another person),
    divide (one thing into several),
    delete (delete a thing from the accounting system).

    Actions are performed from a typical dialog box. The income and expense are present in it, however, they do not protrude, but exist "insofar as".

    Registration of primary data is the first of two obligatory sides of the accounting program, but how did the second task - reporting generation, be solved in “Accountlogic”? Using the so-called reporting folders .

    Each thing and action has properties defined by the user in another dialog box.

    The value here has not only a list of properties, but also their sequence, as well as the depth of the hierarchy, according to which report folders are organized (which are generated automatically based on the properties added by the user and entered values).

    In accordance with our settings, at the top level there will be folders with names.

    Once inside a folder, at the second level of the hierarchy we find folders with storage locations, etc.

    At each of the levels there are reporting columns with the traditional accounting and accounting turnover and balance .
    Although traditionality refers to past periods, it is more complicated with future periods. Future periods are intended to take into account obligations (there are no analogues to this methodological solution, I declare as the author of dozens of textbooks on this world's most tedious specialty).

    What is a commitment- I do not mean a legal definition, but the essence of the matter? The same things of reality surrounding us that someone commits themselves in favor of another. These things do not exist in the present, in the future:
    • accounts receivable - things that someone has committed to our benefit (thus, the thing should come to us);
    • accounting lender - on the contrary, things that we pledged in favor of another (for which reason the thing should retire from us).

    In other words, liabilities are not a special accounting object, as is mistakenly considered in traditional accounting, but things recorded by a future date: they are taken into account in “AccountingLogic”.

    Suppose a thing is registered on November 25 with a date of completion of November 27.

    What does this mean? Just what she should do on November 27: the ordinary thing is no obligation.

    Pay attention to the organization of time accounting:
    • we’ll see nothing in the reports for November 24 (and what can we see if the registration was carried out on November 25?),

    • in the reports for November 25 we will see the future thing - accounts receivable. An indication for a probability action allows you to reflect a given object that has not yet taken place with a coefficient (the thing will come to us with a probability of 90%),

    • after the date of commission, we will see the same thing as the cash actually received (and in this case there can be no probability coefficient: the thing either arrived or not, the third is not given).

    With the coming date of the future transaction, the corresponding object is considered cash (that is, actually received), no special actions (which in accounting are called repayment of the obligation) need not be performed. If, in spite of expectations, the thing has not been received, the user can postpone its alleged receipt or completely delete the action as failed - thus, the deadlines for registering obligations must be monitored.

    Of course, it is necessary to register not only the accounts receivable, but also the creditor (from the point of view of accountology, the future retirement of things), and here some unusual complexity for the accountant is outlined. It is in bookkeeping that you can register a lender regardless of what you currently have, but not in AccountoLogic, which takes an example from reality. Is it possible in real life a thing can retire before it arrived? It can’t, it’s unthinkable, that’s why it is unthinkable in “Account Logic”: to register the future disposal of a thing, you must first register its receipt, current or future (assumed).

    If you really, really want, you can specify a probability of 0% for the future arrival, and 100% for the future consumption, then the line will show the potential excess of the expense over the arrival (only until the arrival date, of course).

    If desired, reporting folders are formed not only for things, but also for actions. The indicators in the action folders are not turnovers and balances, as in the things folders, but income with expenses.

    What income and expenses are, it is not very clear in the accounting records - the truth is, disgusting. But in “AccountingLogic” the definition is formal: income and expenses are the numerical characteristics of the action.
    Both representable calculation methods are implemented.

    Suppose that there was a shrinkage, the mass of the item decreased from 3 kg to 2 kg. According to the accountological approach, two objects are involved in the change operation:
    • the first object weighing 3 kg (recorded by flow rate),
    • the second object weighing 2 kg (registered upon arrival).

    In accordance with the first method of calculating income-expenses, expenses are 3 kg, and income 2 kg. According to the second method, expenses are 1 kg (3 kg - 2 kg), for obvious reasons there are no incomes. Let no one be embarrassed by the mass measurement of income and expenses: when using another meter, income and expenses will be measured in a different numerical characteristic (quantity, rubles, dollars, euros, tugriks, bitcoins) - in whatever you wish.

    Within the framework of revenue-expenses, accounting can be organized in the context of ... say, counterparties: in this case, income is received from the counterparty for the period, while expenses are transferred to the counterparty for the period. The same - in the context of contracts, costing items, etc.

    Anticipating reproaches for the poverty of the reporting forms of "Account Logic", I will explain. The program is not intended for designing reports: the report form is the only one, nevertheless, which allows to receive, within the framework of the implemented methodology, turnover-balances and income-expenses for any user data section. Further processing of the report is done by exporting to Excel.

    To me as a developer (well, who won’t say a good word about themselves ?!) the technique seems to be:
    • flexible (accounting constructor - that says it all);
    • well thought out and formalized;
    • progressive (lack of what accounting refers to as “closing the reporting period.” In Account Logic, balances are calculated based on a simple sample, without sequential summing up of transactions);
    • ensuring the compatibility of users maintaining independent accounting from each other.

    The latter is the most important quality of the program for which it was designed.

    Alas, full compatibility is not implemented due to the need to exchange data through the site (like email), which I can’t handle today. Therefore, version 1.0 is desktop: the user can register under different names and transfer things to himself, while databases with different structures are consistent with each other. This communicative features of the program are exhausted ... however, they can be expanded in future versions. No, well, imagine: a program by installing it on a computer, you can get information on goods purchased in the store directly to your personal base! An additional type of services provided by outlets!

    If someone has a desire to try out "Accountogo Logic" live, you can download it from here .

    System requirements: 32-bit Microsoft Office and 32-bit Windows. If you have 64-bit Windows, you will most likely need to install the Microsoft Access Database Engine 2010 (32-bit) utility . But with 64-bit Microsoft Office it still doesn’t work: the Microsoft.ACE.OLEDB.12.0 provider does not allow it. If someone tells me whether it is possible to solve the problem without changing the provider, I will be grateful.

    No, what do you want from an accountant! I’ve never programmed before ... a training program (in every sense of the word), raw and, by the way, quite voluminous (I was told that 30 thousand lines of code is a lot) ... Therefore, do not blame me,“Accountant Logic” is proposed for familiarization with the original accounting methodology - in accordance with the principle of “as is” (which, translated into Russian, means: the wealthier, the happier ).

    Also popular now: