COMMIT WORK in copying requirements

[rafael_zaragatzky]

Dear community,

Do you know if it is allowed to have COMMIT WORK in copying requirements in VOFM? We want to update a custom table there and it's not always updated. I suspect that our updates get rolled back when the standard program after this routine decides not to fulfill the update. We want our updates in the custom table to be preserved no matter what happens after that.

TIA

Raf

[VeselinaPeykova]

I am not a developer, but copy requirement in VTAA/VTLA/VTFA/VTFL etc. seems a rather odd choice for updating custom tables. From the little that I know (I happen to debug VOFM routines fairly often) copy requirement code is executed before you save a document or an item (depends on where you use the VOFM routine - header or item) to the database.

Why would one use such point in time to update custom tables when there are probably more efficient ways to do that? And custom VOFM routines in ECC require SSCR... Is there a valid reason to prefer a copy requirement to badis, user exits, events or outputs with special function 8 for custom table or custom field update?

Speaking from my fairly limited experience - I have used VOFM routines to read data from custom tables, not to populate information in custom tables. Pricing and output determination (NACE) are very mature (e.g. leave the transaction without saving, perform pricing simulation) and the chances that I might break something by mistake are waaay lower compared to updating some z* table.

I may be wrong (being a functional consultant and all) but for z* table update options I would look elsewhere.

[Jelena_Perfiljeva]

Am a developer, can confirm. 🙂

Don't do any updates in VOFM routines, find another place.

[Dominik_Tylczynski]

Don't put COMMIT WORK in VOFM routines be it copy routines, requirements, scales etc, unless you really know what you are doing. COMMIT WORK in VOFM will most surely break data integrity.

Dominik Tylczyński