Короче, все проводки док. материала проходят, потом выдается дамп пользователю, и проводка FI-документа уже не проходит.

The methods differ according to the time at which they are called up:

The method MB_DOCUMENT_BEFORE_UPDATE is called up before the FI document is created. This means that it is called up even if the program is terminated by an error during the subsequent processing. The update of data in separate tables should always be contained in function modules that are called up with the addition 'in update task'. This ensures that all the data is updated consistently.
The method MB_DOCUMENT_UPDATE is not carried out until update. This means that all updates are carried out immediately in their own tables and do not have to be contained in 'update task' in function modules. For performance reasons, you should not re-read the tables or carry out any time-consuming routines at this point.
You should always call up MB_DOCUMENT_BEFORE_UPDATE before MB_DOCUMENT_UPDATE, particularly if time is a critical factor when posting the material documents. The method MB_DOCUMENT_UPDATE is processed after the FI document numbers are called. As a result, no other FI documents can be posted until this document is completely updated.

Even if the two methods are in the same class, you cannot access the same global fields, as the methods are called up at different times and are therefore carried out in another roll area.

From the business add-in display, you can go to coding examples for both methods by choosing Goto -> Example coding -> Display

Note

The enhancement does not transfer any data to the material document, that is, you cannot change material document data before it is updated.

If this business add-in is not set up properly, it may result in an inconsistency between the documents and the stocks and between the material documents and the accounting documents. Inconsistencies like these may be caused by the following elements in the business add-in:
COMMIT WORK
Remote function call (CALL FUNCTION ... DESTINATION)
Own updates in document tables or stock tables (for example, update in tables MBEW, MARD, MSEG)
The unlocking of data (for example, via DEQUEUE_ALL)
Before the two business add-ins are called up, data is already flagged for the UPDATE. If a COMMIT WORK or a Remote Function Call is transmitted in the enhancement, these are written in the database. If another error occurs after the business add-ins are processed, you cannot carry out a complete ROLL BACK, as the data up to the COMMIT or Remote Function Call has already been written in the database. This can result in an inconsistent status (for example, material document without accounting document), which can only be repaired with considerable cost and effort.

The business add-ins are not suitable for customer-specific updates in the stock tables, as updates like these destroy the standard stock update.

Unlocking the data (for example, via DEQUEUE_ALL) is also critical, as the data that is to be updated is no longer protected from updates from external