Document posting requirements





This article describes the standards that apply to document posting. All of the listed recommendations are mandatory unless noted otherwise.

1. Documents are intended for entering source data related to events that affect accounting records. For example, in business activity automation this includes business activity accounting records, while in manufacturing activity automation this includes manufacturing records.

2.1. Registering an event (adding its data to accounting records) is performed by posting a document. Most of the documents should be posted (their Posting property should be set to Enable).

From the logical point of view, an unposted document is a "draft" that does not affect accounting records. Such documents can be saved even if they are not fully filled or not filled at all, they are not subject to any checks or business logic restrictions (such as fill checks or date change restrictions). Their data is not included in reports.

And a posted document is an approved one, it is fully filled, processed, and included in the accounting records.

2.2. If a document lifecycle includes several processing stages, you can create additional document statuses to reflect these stages. For example, a Customer Order document can have the following statuses: "open", "backordered", and "closed". An Invoice document can have the following statuses: "open", "invoiced", and "paid".

In such scenarios the first posting creates an initial accounting record, while the document statuses affect the record details. 

If a document is posted, changing its status might require filling specific document data, and status-specific fill checks and business logic restrictions might apply. If a document is not yet posted, the system does not perform any status-specific checks and does not apply any restrictions.

Examples of status-specific document behavior:

  • A posted Customer Order in the "open" status does not create additional register records.
  • A posted Customer Order in the "backordered" status writes register records that store the quantity of goods yet to be delivered.
  • A draft Invoice in the "open" status does not require filling the "Due date" field.
  • A posted Invoice in the "invoiced" status requires filling the "Due date" field.

2.3. The following documents are exceptions to the "Most of the documents should be posted" rule:

  • Documents that are not intended for generating accounting records. These are documents that record events with time stamps: incoming messages, calls, meetings, and so on. 
  • Documents whose posting procedure is very different from the standard 1C:Enterprise posting procedure, but from the user perspective this should look like standard posting. Examples of such documents are General Ledger Entry (this document is intended for manual adding of general ledger entries) and Manual Adjustment (this document is intended for manual corrections of accounting records and is only available during applied solution testing).

Such documents are never posted.

2.4. When a user needs to record an event and generate the corresponding accounting records in a single operation, they have to create a document and save it in the posting mode.

Implementing this in a different way is not allowed. In particular, disabling the posting is not allowed.

3.1. To reflect an event in accounting records, you might need to generate "secondary" data that has complex relations with points in time, periods, or other system objects. Such data should be stored in registers. The register records should be generated during posting (automatically or manually).

If you select automatic generation of register records, users record the event data to the document and the register records are generated during the document posting. For example, bookkeeping transactions generate register records automatically.

If you select manual generation of register records, users can record data directly to registers using documents referred to as manual operations. They can use them for entering initial balances or for registering business activities that cannot be described by standard business activity documents available in the configuration.

3.2. In rare cases you can use a separate document for generating register records. This makes sense in scenarios where several document types require similar processing, bulk document processing is involved, or parts of complex business processes require different user rights. In such scenarios a series of events can be implemented as a document chain, one document based on another, rather than a single document that changes statuses. Some parts of the document chain might not require posting.

For example, a Customer Order is created in the Sales department and it cannot be changed during the posting. In this scenario the Customer Order is created by a salesperson and never posted, while a logistics specialist checks that the requested quantity of goods is available and creates the Shipment document, which is intended for generating register records and is based on the Customer Order document.

3.3. Unposted documents and documents marked for deletion must not have active records.

3.4. Even if a document does not generate register records, its posting should still be enabled. This is required to make a visual difference between draft and approved documents.

4. In most scenarios recording accounting data can be undone (use the undo posting feature provided by the platform).

See also:


Comments
0
Add comment