Scope: managed applications, mobile applications, and ordinary applications.
1. You can use documents to store primary information related to registration of events affecting the application indicators. For example, if financial and economic activities of a company are automated, it means recording of various business transactions. In production management systems, it means recording of production operations, and so on.
2.1. An event is registered (it means, recorded) in the application using document posting. Most documents are to be posted (the Posting property is set to Allow).
Logically, a non-posted document differs from the posted one as it is a not recorded draft document. Such documents can be saved in the application even if they are not filled in partially or fully. No checks and business logic restrictions are applied to these documents (checks of filling, period-end closing dates, and so on). Data of such documents is not recorded. This means it is not displayed in reports, and so on.
At the same time, a posted document is a final document whose generation and processing are completed and for which a decision is taken to record it.
2.2. If the document life cycle consists of several stages matching stages of a particular process, you can use additional statuses to describe these stages for a document. For example, the Sales order document can have the following statuses: Not approved, To supply, and Closed. The Cash voucher document is first registered in the cash voucher register (CVR-3), then signed by the chief accountant or manager, delivered to the cash account, registered in the cash book, and signed by the chief accountant or manager.
In such cases, document posting corresponds to initial recording of an event, and statuses of a document being posted clarify the way the event is recorded.
When a user changes a status of the posted document, the application might suggest that the user fills in particular document data. Certain checks and business logic restrictions specific for each stage can be applied to this data. Until a draft document is posted, its status changes are not controlled by the application.
Examples of document posting with multi-stage recording:
- For the posted Sales order document:
- If the status changes to Not approved, only main order parameters are controlled by the application.
- If the status changes to To supply, the Shipment date field is required as logistics people need to know the date of order delivery.
- For the posted Cash voucher document, change to the final status Registered in the cash book and signed by the chief accountant or manager means that the application will create bookkeeping records and the cashier report will be registered in a note journal or another accounting register. For example, in a state-funded company, the report will be registered in a transaction journal.
2.3. There are the following exceptions to the rule "most documents are to be posted":
- Documents that are not used for recording of events. Such documents are used only to register time-referenced events: for example, incoming emails, calls, meetings, and so on.
- Separate documents whose posting technology significantly differs from technological platform capabilities. However, these documents are to be displayed to a user as if they are posted. For example, these are the Transaction (bookkeeping and tax accounting) document used to enter operations manually and the Period-end closing operation document used to perform month-end closing operation with manual corrections available, and so on.
Such documents are not posted.
2.4. If a user needs to register an event in the application and record it in a single operation, write a new document in the posting mode.
It is unacceptable to accomplish this task using other methods, specifically, by disabling document posting.
3. When recording an event, you might need to generate secondary data with complex references to points in time, periods, and other application objects. In that case, save this data to registers. Register records are to be generated upon document posting automatically or manually.
If records are generated automatically, a user enters event information in the document data. When posting the document based on the entered information, records in various registers are generated. For example, postings are generated for bookkeeping operations.
If records are generated manually, a user enters information directly in registers. Such documents are usually called manual operations. They might be used to enter the opening balance or business transactions, which are not provided by a configuration developer.
4. Sometimes, records are generated by a separate document. It is useful if different document kinds are processed similarly or if complex business processes that require explicit separation of performer functions are processed or implemented in group. In that case, different stages of event recording are implemented not by changing statuses of one document but using different documents that are entered based on each other. In this chain, only particular documents generate records when being posted.
Let's have a look at an example when a payment order is generated in the financial department and the accountant must not change the primary document upon posting. In this case, the Payment order document does not generate any records. The records for the payment order are generated by the Bank payment document that is used to automate generation of records.
5. Non-posted documents and documents marked for deletion cannot have active records.
6. Even if a document does not generate records, it is to be posted to logically differ from a draft document.
7.1.1. If no data relevant for posting is changed in the document (for example, only a value of the Comment attribute is changed), posting of the previously posted document must not lead to the change of its records.
An exception to this rule might be cases when register records are partially or fully generated by algorithms that are external in relation to the document (see cl. 4).
7.1.2. When developing record generation algorithms, avoid solutions when record generation results depend on the state of accounting registers, for example, on the balance, as in that case, posting results will depend on the document input sequence.
An exception to this rule might be particular reasonable cases when the algorithm is designed to analyze the sequence, as for example, batch accounting algorithms.
7.2. To implement the behavior described in cl. 7.1, make sure that documents are based on data stored in these documents upon generating records. The data that is not saved to the document must be locked from changing. To do this, implement the set of measures described below.
7.2.1. If users are allowed to change data that is external in relation to the document (for example, reference information attributes) and affects generation of records, values of these attributes are to be saved to the document.
Otherwise, this data is to be locked from changing. In configurations based on Standard Subsystems Library, we recommend that you use Object attribute lock features.
Exceptions to this rule are described in cl. 7.1.2.
7.2.2. Try to ensure that application settings, for example, values of functional options, have the minimal impact on record generation. In that case, users will be able to easily change these settings.
Some techniques to achieve such behavior are listed below:
- Specify a date, starting from which a setting is applied (validity period), and consider this date in record generation algorithms.
- Fill in required fields that are disabled in settings with default values. In this case, users will be able to easily enable the setting. Only disabling of the setting is restricted.
- Generate records without considering the setting and take additional measures in objects that display information from accounting registers. For example, a value of an accumulation register dimension is always written in the same way, but reports for this register hide the dimension if it is disabled.
7.2.3. If all the measures to prevent record generation from being dependent on application settings are exhausted, use one of the following:
- Automatic data processor, which is started in the background after a user changes a setting. The user is to be notified of the data processor start when changing the setting.
- Data processor that is started manually by the user. Before changing the setting, the user is to be notified that it is necessary to start the data processor. You also need to notify the user that it is necessary to start the data processor in interfaces that operate with data to be processed (for example, in reports).
- If the data processor cannot be used, when changing the setting, the user is to be notified that it is not recommended to do that after the accounting start.
However, the application behavior when a setting is enabled or disabled can vary. For example, the setting is enabled without a warning, and we do not recommend that you disable it.
7.3. When changing the record generation logic, to ensure compliance with cl. 7.1, you need to provide infobase update handlers or support previous record generation algorithms for documents existing at the update time.
8. For most events, recording is reversible. For this purpose, use the feature of canceling document posting.
- Metadata object names in configurations
- Writing document register records
- Self-sustainability of registers