Partially posted warehouse shipment (development)

Belias

hi everyone, i tried to search the forum for this but i probably didn't search the right keywords.
Here's my problem:
In nav, we can create a warehouse shipment that cumulates 2 orders (for example). Let's say that the first one posts correctly, while the second one gets an error.
Unfortunately, the first transaction has been already committed, so we will have a partially posted warehouse shipment. Is there a way to avoid this?Will we have to replicate all the checks that are done during posting routines? :shock: [-X
Thanks in advance for any suggestion

FDickschat

This is standard behaviour in NAV and is definitely no bug.

In fact posting a warehouse shipment posts source documents per source document with CU80, 90 or 5704. After every source document there is a commit. As CUs 80, 90 and 5704 also contain commits it is the safest way to post.
In this case NAV has created a PostedWhseShpt with the lines from the first source doc. and has already deleted the lines from that source doc from the WhseShpt.

Actually it could become weirder: If for example already the first source document creates an error then nothing is posted. BUT, in the source document the field Qty. to ship has been updated already and is committed. The user could now go into the source document and post it from there. This will leave the WhseShpt as unposted although the source document is posted.

Whatever you are doing with the posted warehouse shipment: Don't take it for granted that 1 WhseShpt creates exactly 1 PostedWhseShpt. There could be more than 1.

Belias

FDickschat wrote:

This is standard behaviour in NAV and is definitely no bug.

this is exactly what i think...i didn't say it is a bug, i said that i (or better said, the analyst) want to avoid the standard behaviour, and post the whse. as "all or nothing".

crisnicolas

Then you'll have to try to avoid the COMMITs.

As already said, Warehouse posting finally posts through CU80, CU90 or CU5704.
Do not just get all the COMMITs out if this CUs, since they are there for some reason, and those CU can be run from other places.
Instead, you can do something like:

IF NOT DoNotCommit THEN
COMMIT;

Where DoNotCommit is a global boolean var on those codeunits.
Place a SetDoNotCommit function on those codeunits, to set the var to TRUE when you call them.

If you do not call that function, the posting will act standard and will do all COMMITs needed. In the places where you don't want the COMMITs to take place, call the function.
You'll have to trace the posting, see how many CU are called before you actually reach CU80, 90 or 5704, since you may have to pass the DoNotCommit value through different codeunits (so, have the var and the function on all those prior codeunits)

There are even some COMMITs out of those codeunits. So first thing, post something with CodeCoverage on, and find all COMMITs. You'll have a list of places where you need to do all of this to avoid commiting.

---

It may exist a better way of doing this, don't know.
What I explained is what I did to avoid commiting in Transfer Orders, since in an implementation I've made, the user posts once, and both the shipment and the reception are posted.
I encountered the COMMIT problem when Shipment posted ok, but Reception had some sort of error.
I didn't want the Shipment to be posted either, but since it was commited, it was already posted, and I didn't want that to happen.

Belias

i thought about avoiding the commits' too, but there's going to be a drastic performance drawback in my process: i should post once, and if correct, post another time...execution time will nearly double!!
moreover, there can possibly be problems if commits are not executed, for example the big error that tell you that "you can't do if codeunit.run in the middle of a transaction...."
anyway, i think that your solution is one of the few possible... :-k

crisnicolas

Actually, it's not just a problem of getting an error on the second or further posting.
When I was dealing with that, I also found that even if both postings were ok, when you COMMIT, you unlock all tables the process had locked.
A certain amount of time passes since the tables for first posting are unlocked and they are locked again for the second posting. In the middle, some other user, posting something else, may have locked the tables you need, so... second posting cannot go through.
I had a lot of trouble because of locking. Not commiting solved everything.

crisnicolas

You will also have to avoid any CONFIRMs on the second or further posting, if there are any.

Belias

thanks for the suggestion. IF i'll go for this solution, i will run the fake post with an action, give an error at the end of the process ("you can post safely") and then the user will push another action (or the same, but with a parameter) to do the real post...

FDickschat

The main question is why the analyst/customer want to change standard NAV behaviour. I would go back to the analyst asking why it is necessary to post in one step. The analyst should know about the standard behaviour of NAV (if he does not get another analyst ). Work together with the customer to find another way of processing.

From my experience the customer/analyst wants a 1:1 relation because there is a process after posting the WhseShpt which relies on this 1:1 relation (usually because it was like that in the old system where the customer migrates from). But that process could be adjusted so that it works even if it is a 1:many relation.

We had the same request here and in the end convinced people that it is better to stay with the standard behaviour of NAV then to invest a lot of money not knowing exactly what the outcome is and risking performance issues.

Belias

you're perfectly right, this is my thought too...this is how the system should work, it's correct in my opinion...but believe me, i tried to explain why we shouldn't do it...without success, unfortunately!
now the only thing i can do is just do it and hope for the best (if it will be a failure, i think i'll be even more happy) :twisted:

Belias

Belias wrote:

i thought about avoiding the commits' too, but there's going to be a drastic performance drawback in my process: i should post once, and if correct, post another time...execution time will nearly double!!
moreover, there can possibly be problems if commits are not executed, for example the big error that tell you that "you can't do if codeunit.run in the middle of a transaction...."
anyway, i think that your solution is one of the few possible... :-k

I was wrong here, it's not true that i have to post twice, because the first posting routine without commmits is enough for my needs (i realized it at the toilet this weekend ). It's not a bad idea, and probably the best option possible. Thanks crisnicolas :thumbsup:

crisnicolas

Belias wrote:

I was wrong here, it's not true that i have to post twice, because the first posting routine without commmits is enough for my needs (i realized it at the toilet this weekend ). It's not a bad idea, and probably the best option possible. Thanks crisnicolas :thumbsup:

:shock: thinking about Nav while in the toilet... uhm... weird!

Belias

Update: i solved it through this function in the cu80 (to avoid commits):

FNTSetCommitAndFirstTime(pTFSetNoCommit : Boolean;pTFSetFirstTime : Boolean)
//This function sets 2 parameters to determine if the commits have to be executed and if it's the first time that a document
//is processed in then same transaction.
//A temporary Integer variable is used because clearall is called at the beginning of the codeunit (clearall doesn't clear recs).

IF pTFSetNoCommit THEN BEGIN
  TBIntegerTemp.Number := 1;
  IF TBIntegerTemp.INSERT THEN;
END ELSE BEGIN
  IF TBIntegerTemp.GET(1) THEN
    TBIntegerTemp.DELETE;
END;

IF pTFSetFirstTime THEN BEGIN
  TBIntegerTemp.Number := 2;
  IF TBIntegerTemp.INSERT THEN;
END ELSE BEGIN
  IF TBIntegerTemp.GET(2) THEN
    TBIntegerTemp.DELETE;
END;

and then, when commit occurs:

//-@MHC1.MM 27.05.10
    IF NOT(TBIntegerTemp.GET(1)) THEN
      COMMIT
    ELSE
      IF TBIntegerTemp.GET(2) THEN
        COMMIT;
    //+@MHC1.MM 27.05.10

or

//-@MHC1.MM 27.05.10
    IF NOT(TBIntegerTemp.GET(1)) THEN
      COMMIT;
    //+@MHC1.MM 27.05.10

The two options are based on some other requests, the plain one, to just avoid commits, is the second option

kriki

I am a little late (all because of my [still] dead portable), but here are my 2 cents:
I don't think it is a good idea to TRY to avoid the COMMITS:
-Even with codecoverage, you are not sure to find them all. Depending on a lot of things, different streets in the code can be used where other COMMIT's are.
-Even if you can find them all, another programmer can later add some code and a COMMIT....
-The possibility of creating the dreaded :evil: deadlocks :twisted: auments a lot because your transactions become bigger and longer and locking in a non-consistent manner. Because of these, the rollbacks will also be longer and performance will take a hit.

How to fix it?
-I have a lot of times procedures that have to do a lot of different things (e.g. create a sales order header, creating the lines, releasing them and posting the shipment). I know I will have different COMMIT's in it (e.g. after the header has been created, I should do a COMMIT to release the numberseries). So it is better to program in such a way that you use smaller transactions, reducing the locking-time and reducing deadlocks.
Of course, you need to program it in such a way that if something goes wrong at ANY point in the code, the user should be able to post it again and the program should know at which point it came before the last error.

This kind of programming takes somewhat longer, specially with the PROGRAMMER'S tests (and not the functional testing afterwards)! But at least you have a very robust program.

Belias

thanks kriki to add some of the risks of doing this "dirty" work, for future readers...anyway, about my process, i've found that (CU 80):
-first commit: it saves the update of the no. series table, in this way, if the transaction rolls back, the no. is still reserved and saved on the document to be posted. -> i do this commit only the first time, because i need one number only
-second commit: it saves the discounts, but this is already executed during the document release -> i skip this one
-third commit: it is executed only if the document is not released, but this is not possible because during whse shipments, all documents must be released -> i don't even conditioned this commit to my parameter
-fourth commit: it's done just a little before the end of the posting process, and we don't use the code following the commit -> skipped
-fifth commit: creates the archived order -> not a huge piece of code, i skip this one

in CU 5763:
-first commit: i execute it
-second commit: i do this commit only the first time

up to now it seems to be stable, but stress tests are not easy to perform...

Also, i'm not the first one to do it
http://www.mibuso.com/forum/viewtopic.php?f=23&t=18319&hilit=comment+commit

kriki

I know you are not the first one to do it (and neither will you be the last one).
But I just wanted to point out the risks one is taken doing it this way.
And also showing how it should be done.

Belias

kriki wrote:

I know you are not the first one to do it (and neither will you be the last one).
But I just wanted to point out the risks one is taken doing it this way.
And also showing how it should be done.

Sure, you're right!i only wanted to point out that i didn't blindly commented the commits, and i also wanted to link some related topics :thumbsup:

Alex_Chow

Are you guys using ADCS? If so, you might want to test your barcode scanners with the new code as well.

Belias

Alex Chow wrote:

Are you guys using ADCS? If so, you might want to test your barcode scanners with the new code as well.

no, we don't...honestly, i only know that adcs probably means "Advanced directory comparison and synchronization" (from google), but i don't know what it is :oops:
edit: or maybe "analog-to-digital converterS"?

Alex_Chow

Advance Data Capture S

Forgot what the S is...

Basically radio frequency handle barcode scanners to allow you to register picks and putaways without someone sitting at a NAV terminal.

Belias

I don't know...this the 0,1% part of a project, we will test the functionality when we'll go further with the development...if it'll fail, there'll no problem, as i spent 1h development, and 2h testing only...
We still have plan "B"

Andwian

Belias wrote:

ADCS

Automated Data Capture System