Transactions in NAV 4.03

Cem_Karaer

Hi everyone!
Is it possible to wrap two intrinsic transactions into one by any means? For example, posting output lines and then posting consumption lines consecutively must be regarded as one transaction because in the consumption process, intermediate products created in the output will be consumed. If consumption fails for any reason (because of inventory insufficiency or any error), posting of output lines must also be rolled back for the sake of consistency.

kine

Than you need to post that all in one transaction, question is, how you are posting it. If through Journal manually, it will be one transaction, if through c/al code, you need to not use commit somewhere during the transaction.

Cem_Karaer

Not using COMMIT in code is not possible because item post batch is used consecutively, which several COMMITs are used within.

kine

Tan you need to add condition before this commit and in this case set the condition to false to skip the commits. Common thing... (add function into the codeunit like SetNoCommit or something similar to set the flag and add condition before the commit).

Cem_Karaer

Unfortunately, disabling COMMITs will not work because open output ledger entries must be available so that consumption can be made by closing them. I think that without COMMIT in code, it is impossible to create ledger entries that can be used for another posting process. It's like the paradox of the egg and the hen I think..

kine

Do not be afraid. You can Post Output and consume this output in one journal without problem. Try it in the journal manually. It will be one transaction and all will work. It means, you need to enter the output first and then the consumption, but of course, the consumption MUST BE for ANOTHER production order. You cannot consume output of same production order else you will have never ending loop when calculating the cost of the output. But all can be solved in some way. If you describe more the problem, may be that somebody will show you the way.

Cem_Karaer

The scenario is a barcode automation. My customer creates a production order of multiple quantities of a finished good, namely an office armchair. Armchair has several unfinished goods in its BOM which are regarded as intermediary items. Those unfinished items have no inventory, they are only produced and consumed for the production order. For example, for 10 pieces of armchairs, 10 distinct barcode numbers are created and linked with the particular production order. When the barcode is read, Explode Routing function of the Output Journal is executed but rationing every output quantity by one and then Calc. Consumption function of the Consumption Journal is executed but rationing every quantity by one, all in the code. Then created output and consumption journals are posted by separately calling the item post batch. The intermediary items are created by the output journal and consumed by the consumption journal. As the scenario necessitates, output and consumption belongs to the same production order. Each read barcode represents a whole product with its finished item's open output entry, intermediary items' closed output entries, intermediary items' closed consumption entries and raw materials' closed consumption entries. When an error flashes at the consumption leg of this process, because all output is created and committed by the first item post batch, the barcode automation becomes inconsistent with created output but rolled back consumption. The experience shows that aggregating output and consumption item journal lines into temporary item journal lines, then posting the temporary item journal line fails because of the intermediary goods' inventory insufficiency. I assumed that without committing the post, NAV does not regard created output entries as real entries.

kine

You can be sure that it is not because that. Try to simulate this in one Item Journal:

add RAW material consumption lines, add Output lines for PO1, add consumption lines, add output lines for PO2 etc. Try to post the journal. It will be one transaction. You only need to be sure, that you are posting the lines in correct order (consumption on lowest level, output of first level, consumption on second level, output of second level etc.) and do not forget to have correct serial or lot nos. on the consumption and output lines if you are using tracking. Check the flushing method on the items etc.

In my opinion the problem is elsewhere than you are thinking now... COMMIT have no effect to visibility of data in same process, only for other NAV clients...

DenSter

COMMIT ends the transaction, that's just the way it works. If your transaction has 3 steps, and you have a COMMIT between each step, and something goes wrong in step 3, then steps 1 and 2 have already been committed to the database, and will not be included in the rollback, because you specifically told the system "this transaction is complete, I am done with it". Either you remove the COMMIT statements, or you keep track of everything and have some process to reverse the already committed steps back. I would say the easiest way to do this would be to just remove those COMMIT statements.