Did you receive a-mail? .. Accounting mail

According to the plan, a-mail (accounting mail, that is, accounting mail) is the closest relative to an e-mail e-mail. The difference is that by e-mail the data is transmitted in a free text form, and by accounting mail - in a formalized form, intended for automatic placement in the user account database. In fact, it is a standard of data exchange between accounting programs.

The standard was implemented in the course of the project "Accounting Logic". This story unfolded on Habré for three years and now seems to be close to completion.
')
Under the cat there is a brief description of the a-Mail standard and the network capabilities of the "Accounting Logic" version 3.0 (in previous versions this function was not available).

First of all, what is it for? In order for information from one account database to fall directly into another account database.

Imagine an ordinary purchase and sale transaction. There is a seller, there is also a buyer. The seller keeps records in one accounting program, the buyer - in another. It is obvious that it is more profitable for the buyer to receive information - both about the money paid and the product purchased - not in text form, but in the form of records in the accounting database. As a result of the automated transaction, the user should receive a non-text message such as “You have charged such a sum for such goods”, which requires additional processing by entering the corresponding records into your personal accounting database, no, the accounting base should change accordingly without participation user What else is involved when all the necessary information is available?

Yes, the architecture of accounting programs is different, but sorry, the domain they automate is one! For this simple reason, the development of a standard is not a matter of combining various software architectures, as it may be mistaken to someone, but a question of standardization of the subject domain itself.

Consider the topic in more detail.

One of the most common relations in civil law is the sale and purchase agreement mentioned above. When a transaction of this type of relationship between the parties fall into two parts:

• transfer of goods from the seller to the buyer,
• transfer of money from the buyer to the seller.

Parts of the transaction are opposite in direction, but identical in meaning, so any part can be taken as a testing ground for an idea, let's say the first one.

The seller gave the goods to the buyer. There is one operation - the transfer of the goods, affecting both parties, and the goods passing from hand to hand. If you switch to an accounting language, the operation is an accounting entry, and the goods are objects of accounting. Each of these entities can be described by some properties, for example, to establish that:

• the operation is characterized by the time of its performance, a commentary (these are practically mandatory accounting details), also the name of the contract and, the income or expenses,
• goods are characterized by the name, weight, cost (again) compulsory accounting details), also grade, country of manufacture, manufacturing company, etc.

This is done in any accounting program, with no exceptions. The sets of properties used in each of the accounting programs are also different for different users - of course, of course! - but what prevents the use of intersection properties?

Suppose the seller takes into account the goods for the properties "Name", "Price", "Mass", "Warehouse", "Grade", "Responsible person", while the buyer considers his personal property for the properties "Name", "Cost", " Mass "," Type of property "," Location ". Properties that are intersections of both sets: “Name”, “Mass”. Thus, if the seller sends the information about the goods sold to the buyer, as it appears in the seller’s database, the buyer, or rather the software he uses, can, by filtering the received content by matching fields, enter the necessary data into his database. : values ​​in the fields "Name", "Mass". And any other, whose names coincide in the accounting bases of the seller and the buyer.

The difficulty arises when the field names are different and the content is identical: for example, the seller has a field called “Price”, and the buyer called this field “Cost”. Especially, if the seller and the buyer are generally multilingual: in this case the names of the fields in their databases are guaranteed not to coincide.

The solution is traditional: the use of a language considered international for business communication - English. The database fields are proposed to be called in English, while taking the standard names from the list, which in case of popularity, a-Mail will certainly be compiled. Within the framework of the user interface, so that users feel themselves in the familiar language environment, nothing prevents us from assigning pseudonyms to the fields. The store can use the pseudonym “Price”, and the buyer - the pseudonym “Cost”, but if the true field names in both cases are “Cost”, there will be no problems: the price data of the goods will be safely copied from the seller’s base to the buyer’s base.

It remains to be decided whether it makes sense to send the properties of not only the accounting objects - the goods - but also the operation itself, in the form in which it is registered in the seller’s account base. In my opinion, not worth it. Take the same sale and purchase: for the seller this transaction is a sale, and for the buyer - buy, there is no reason to try to combine them into one whole. Strictly speaking, when buying and selling it is not difficult at all (buying and selling is the general name of the transaction for all parties), but what about, say, the trade between two legal entities, when the seller took into account the goods released in warehouse No. 1, and the buyer accepted the purchased goods at warehouse number 2? Obviously, some properties of operations on both sides of the transaction may be the same, but may not be the same. This feature is not software, and not database architecture, but the most automated entity. Therefore, the operation in a-Mail is described by a finite set of traditional accounting properties.

After a theoretical excursion proceed to the consideration of the standard itself.

So, from the seller (Sender) to the buyer (Recipient) - through the developer server - the data is sent:

• about the operation,
• about accounting objects transferred in the framework of this operation.

For transfer the json format is used.

Operation data is a Dictionary <string, string> structure translated into json with a finite set of values, the main ones being a-Mail data from the Sender and Recipient (login and sublogin; sublogin is the name of the user's local database, since the user can maintain simultaneous records in several databases), also the date of registration of the transaction and a comment. Everything is clear here: these are either address or standard details for accounting entries.

In the comment, the Sender can specify the details missing in the list, for example, the contract number, the date of the contract, etc., so that upon receipt of a-Mail, the Recipient translates this information into the fields of his database. Yes, transferred manually, but the alternative is difficult - manual! - determination of the list of allowed or prohibited to transfer fields, while there is no guarantee that manual adjustment will not be required. And the date of registration and commentary are present in any accounting entry; no problems will arise with them.

Since a-Mail was developed directly for “Accounting Logic”, the transaction data contains useful innovations. In particular, in addition to the date of registration, the date of commission is also indicated. In this way it becomes possible to register not only current business transactions, but also obligations.

Suppose payment is registered on May 10, but the transfer of goods must take place on June 25: there is a trivial delay in payment. In this case, if the date of registration of the transaction is less than the date of its execution, there is an obligation. "Accounting Logic" uses this original method, but this is not a mandatory requirement. In general, the date of registration of the operation coincides with the date of the transaction, which means: the operation is registered and completed at the specified time.

Data on accounting objects sent within an operation have a more complex structure. List <Dictionary <string, string >> - due to the fact that there can be many objects in one operation. In the internal part of the structure (in the dictionary), the field name is specified (that is, the name of the object property), the value for this field and the format. Thus, not only the number of transferred objects, but also the number of properties by which such objects can be characterized has no theoretical limitations.

The data on the operations-objects are sent through the developer's server, from the Sender to the Recipient, but the matter does not end with one transfer. The meaning of a-Mail is the correlation between the accounting bases (subject to the approval of the correlation by both parties to the transaction), so the Recipient must inform the Sender if he agrees to accept the objects sent to him. In ordinary electronic correspondence, there is no need to return the letter back to the Recipient — an unnecessary letter just trash to be disposed of — however, the need for this appears in the accounting mail. When sending by a-Mail, the Sender observes in his account base the departure of the corresponding object, which ... may be played back in case of a refusal of acceptance. The recipient refused the transaction, therefore, the thing remained with the previous owner. In case when the Recipient refuses because of an empty whim - I bought the item, but I don’t want to register it in my database, that's all! - in “Accounting Logic” there is an option to delete an object instead of a restoration. The Recipient has refused the object, but the Sender ignores the Receiver's refusal, and the object continues to be considered as dropped.

The consent or refusal of the Recipient to accept things (that is, to register their receipt in their account database) is sent to the server to notify the Sender - in the same manner, using the json format as the object is sent. Only the direction of movement of information occurs in reverse order: from the Recipient to the Sender.

Thus, there are four types of server access to the client, in which information is exchanged in one direction or another.

1. Data transfer from the Sender to the server.
2. Their shipment to the recipient.
3. Transfer to the server of the consent or refusal of the Recipient to accept the data.
4. Reporting a denial or consent to the Sender.

It remains to be seen how a-Mail is implemented in the "Accounting Logic" interface.

1. First you need to register in the system - get an a-mail address.



2. After registration, you need to add, that is, take into account some thing. As long as the system does not take into account any thing, there is nothing to transfer to the counterparty.

3. After the thing has appeared, it can be transferred to someone. In principle, you can transfer to yourself (for this you have to register under the second login), but it is better to agree with a friend.

To transfer, you must select the menu item “Operations / Transfer Items ...”, then in the opened dialog box specify a-Mail Recipient.



The first part of a-Mail is the login (under which the user is registered), the second part is the sublogin (the name of the user base is in the initial window “Login as a name”). Ok, and a-mail is gone.

4. Mentally transferred to the database of the Recipient.

The menu item "Operations / Get things ...". In the opened dialog box, the Recipient will see the received a-Mail. You can refuse to accept or agree. In the second case, the data on the incoming object will be added to the user database.



Please note: the time set on the computers of the sender and the Recipient must be synchronized, otherwise surprises are possible. For example, if the sender’s time is set on the Sender’s computer with a 5-minute delay, the Recipient will see the receipt after 5 minutes - at the time specified as the date of the action (for which you will need to restart the workspace, approximately as it does in the browser). This is due to the fact that the "Accounting Logic" displays things registered at the time specified on the timer. If you pass things with a future moment, the Recipient will see them not earlier than the specified period.

This standard was developed for “Accounting Logic”, but it is applicable to other accounting programs, because the essence of transferring things from the Sender to the Recipient is always identical. It is absolutely clear that - if there is an account on both sides - information should be recorded at a time in both bases (or in one common), correlating among themselves. You do not think otherwise?

If there are those who wish to insert a-Mail module into a ready-made accounting software, contact the PM, the project authors will do everything in their power to make the event a success. Purpose: data exchange between accounting programs of different manufacturers.

Download "Logic Logic" 3.0 WWW at this link .


Currently, accounting mail is being tested. From what interest will be shown to a-Mail by the knowledgeable public, the future of the project depends.