SD_VBRK, VBFA orphans, ARCHVBFA: permanent solution?

[joergbychelberg]

Hello,

to get rid of certain orphans in table VBFA, we implemented report ARCHVBFA (HW131051).

Even when this report works properly, we face the situation of being forced to run it manually even in the future, because the step of selecting the desired archive-file is not suitable to be processed in appropriate variants for running in background.

Did anyone experience the same situation (to have to run this report permanent manually)?

Is there another solution conceivable, which is suitable to avoid manual intervention?

[former_member201157]

have you looked at other options like data avoidance in the DMG?

ex:

Avoidance

We recommend that you make the appropriate customizing settings for the copy control for sales documents

via transaction VTAA to avoid the document flow and, as a result, keep table VBFA from growing too much.

For more detailed information on how to do this, see SAP Note 105512 (release-independent). Although this

note was written for contracts, the solution it presents can be used for all sales document types whose direct

follow-on document is neither a billing document nor a delivery.

Archiving

Entries from table VBFA are archived via archiving objects SD_VBAK, SD_VBKA, RV_LIKP, and SD_VBRK.

A sales document does not only have a links record to its immediate follow-on document, but to all follow-on

documents in the document chain. Because document flow records are archived together with their preceding

documents, the archiving of orders has the biggest effect on the document flow.

See also SAP Notes:

· 131051 (release-independent): VBFA records remain in the system after archiving

· 647775 (SAP_APPL 46C 603): Missing test flag for report ARCHVBFA

· 74513 (SAP_APPL 300 - 500): Correction program: document flow for non-existent delivery

[joergbychelberg]

Hello Mr Veeramachaneni,

thank you for your answer.

The reason for creating our orphans is, that the preceding document comes from another system.

Our business department told me, that's up to them to look for a solution.

So I will leave this discussion at the moment.

Thanks again

Jörg