Ship multiple Sales Headers without individual COMMITs

chime

Environment: Nav 4.0 running Native DB (not SQL). Lot tracking enabled, no manual reservations. Warehouse Receipt enabled, Warehouse Shipment disabled.

Short version: Is it safe to disable 'COMMIT's in CU 80 (Sales-Post) and CU 90 (Purch.-Post) if I am shipping 10 different Sales Header or Purchase Returns/Credit Memos in a row? If I do, I would modify a copy of CU80/90 and not the originals.

Long version: I am writing a custom module that groups multiple Sales Lines from multiple Sales Headers as one Bill-of-Lading (BOL). Due to our business rules, the entire BOL must be posted as one transaction (i.e. no partially posted BOLs). I post each unique Sales Header using Code Unit 80. When every Sales Header is successful, I mark the BOL as Posted and ready to print. Everything works fine except when there is an error in CU80 for one of the Sales Headers. CU80 has already COMMIT-ted the previous Sales Headers and there's no easy way to undo that. The same scenario takes places when shipping back material to a vendor using Purchase Return/Credit Memos and CU90 errors in the middle of batch posting.

Normally I would read through the appropriate code and figure out the ramifications but the OnRun() for CU80/90 is over 2000 Lines each and I don't know what other CUs they call (and what other CUs they call and so on). I've also read many of the forum posts on COMMIT and Code Unit 80 but still cannot figure out the side-effects of removing COMMITs.

viewtopic.php?f=23&t=25734
viewtopic.php?f=23&t=26151
viewtopic.php?f=32&t=33816

1) Will disabling the 4 COMMITs in CU80/90 ensure all the Sales/Purch. Headers are posted as one big transactions? Is it safe?
2) Does it affect the No. Series? That is, will the next Sales Header shipment get the next No. Series number even if the previous Sales Header shipment was not committed?
3) Are there any major pitfalls to going this route, especially if CU80/90 can call other CUs that can also COMMIT?
4) If disabling COMMITs in these CUs isn't possible or recommended, any other way for me to ensure that the entire BOL can be posted successfully beforehand?

If there's no other way to ensure atomic shipment of a bunch of orders, I guess I can try to get the business rule on complete-BOL-posting changed and just post them line-by-line like a Sales Order.

David_Singleton

I think this is a much bigger job than you are thinking. The commit in CU80/90 is a major issue, and it would be much better if they used wrappers with the commits separate.

I assume you realize that you can't just remove the commits, you are going to have to create a single instance code unit to store a flag and then use:

if Not NoCommits then
commit;

I have done similar things to this with bols, and just done it by having a new BOL header, and using this to combine posted sales shipment headers after they were posted.

chime

David Singleton wrote:

I think this is a much bigger job than you are thinking... I assume you realize that you can't just remove the commits, you are going to have to create a single instance code unit to store a flag and then use:

I agree that this is a big deal and hence I am so apprehensive about changing anything. And I wouldn't even touch the existing CUs and would have used variables/single-instance like you recommended instead of removing the COMMITs outright.

I have done similar things to this with bols, and just done it by having a new BOL header, and using this to combine posted sales shipment headers after they were posted.

One of the goals for a combined BOL is to eliminate the individual posting of shipments as it is a very time consuming process.

If there is no way to posting shipments in one batch, I guess I can mark each BOL line when the appropriate Sales Header is posted and if all BOL lines are posted, then I can mark the BOL header as posted. It would 'work' in technical terms but it still doesn't help protect against the real life scenario where due to failure in shipping order #4, we decide to not ship order #2 either even though it is able to post successfully. I don't know how common/rare such a situation would be but I would have to find out beforehand before I deploy the new module.