1C:Enterprise 8 documents support the posting feature, which is implemented at the system methodology level. It reflects business events described in the document in the accounting records of the system. The posting mechanism minimizes the effort required by the developer in standard scenarios and at the same time provides the flexibility to change the standard methodology.
This feature provides a special document attribute showing that it is posted, and there are also posting and unposting processes.
The attribute is the Posted system field. The main purpose of this field is to distinguish documents that are already reflected in the accounting system from the documents that have been saved but should not yet affect any accounting records. These documents are a sort of "drafts". For instance, an operator has not yet entered all the required data but needs to quit the program for some reason. He or she can write the document without posting it and get back to it later. Documents that are posted and not posted are shown in the list of documents with different icons.
Posting and unposting in 1C:Enterprise 8 are particular instances of a document writing scenario. The attribute that shows whether posting or unposting should be applied when writing a document is set in the Write() method call parameters. Therefore, the document can be written in the usual manner, posted, or unposted. If a document is posted, True is set in the Posted field, and the Posting() handler is called in addition to the regular actions performed during writing. If a document is unposted, the UndoPosting() handler is called and the Posted field is set to False.
Using the Posted field and the posting process is just a methodology proposed by the system.
You can change the value in the Posted field without posting or unposting the document. All you have to do is change the field value and write a document. This can result in an unposted document with records. Note that if the Posted field is changed this way, the Posting() and UndoPosting() handlers are not called. These handlers accompany explicitly initiated posting and unposting processes, and not the fact that the Posted field was changed.
Document records can be created outside the document posting. Moreover, they can be created by an object other that the document. To this end, all you have to do is write a set of register records with a filter by this document.
This default methodology is the simplest way to manage a document and its records in the scenario when a document contains information on a certain event that took place at the enterprise, and the records reflect these events in various accounting records. If the RegisterRecordsDeletion property is set to AutoDelete in the document's metadata, the existing records are deleted automatically before posting or during unposting. Therefore, if a standard methodology is used, the developer only needs to implement creation of new records in the Posting() handler.
On the other hand, flexibility of the Posted field and the posting process allows to implement more complex posting scenarios if necessary. For instance, you can create a document in which some records are created in the posting process and some are entered manually by the user.
The Posted field and the posting process only make sense for documents that can be posted (those that have the Post property in the metadata set to Enable). Some documents should never be posted. They have the Post property set to Disable in the metadata. These are, for instance, documents that do not affect accounting records in any way. In addition, documents that are meant for manual entering of records should never be posted either. These documents will have records, but you do not have to divide such documents into posted and unposted ones. This is due to the fact that all information (attributes and records) is entered when the document is entered, without distinguishing between the initial information and that obtained during posting.
Note that documents that should not be posted have an icon similar to that of a posted document in the list of documents. This is because the user should first notice the documents that should be posted but have not been posted yet. It is less important to differentiate documents that do not have to be posted and those that have already been posted.