Lanham eShip Issues

joshplummer

I can't believe I'm the only one in the world that has encountered this problem with eShip, but I can't seem to find any other examples...

We use the Multi-Document feature of eShip extensivley. This is a great feature because it allows us to save a tremendous amount on freight by combining multiple shipments into one, single, larger shipment.

However, when we try to close the shipment, any kind of error on any one of the orders will cause the system to completely lose it's marbles.

For example, our shipping department, who we pay to ship, not troubleshoot systems issues, may pack 10 orders into one Multi-Order shipment. When they "push the button" to close the shipment, eShip will attempt to close each order, to completion, 1 by 1.

Then, an inventory error (or reservation error, or table lock error, or missing dimension error or whatever error you can dream of) occurs on the 5th order. The first 4 orders are now fully posted and committed to the system (invoiced, etc.). Our shippers then have to ask someone for help because eShip will not allow them to continue processing this multi-order shipment, because eShip totally forgot where it was and is apparently incapable of picking up where it left off.

The question is this:
1) Has anyone else encountered error resliency issues with eShip Multi Document shipments, and what did you do about it.
2) Is there a way to encapsulate multiple posting operations into a "Transaction" and "Rollback" on failure like you can do in SQL? If so, how?

We're running Navision 5.0 with a fairly recent version of eShip (52.19 or in the vicinity).

Any help would be appreciated as this is causing my shipping staff to be troubleshooters and not shippers.

Savatage

Never had such a problem, but my first call would be to the solution center to get someone over to you to see what's going on. You are on a new version, so I assume your maintainance contract is still in play.

Alex_Chow

Ask your solution partner for support. They should be able to get the people at Lanham to take a look at the problems for you.

DenSter

I would say, having seen quite a bit of the code, and having seen quite a few customizations of this product, that there are COMMIT statements at the end of each order posting. My strategy to solve this issue would probably be to program some kind of control variable into the system, and depending on its value not to execute those COMMIT statements. Kind of like a 'begin trans' and 'end trans', but with a twist, if you know what I mean.

Also knowing your particular system from a past life , I know that it is quite heavily customized, and it would be a total guess as to how much work this would be.

For sure though, I'd look for COMMIT statements and figure out a way around them in the middle of transactions.

Savatage

Also, there could be a check of problem fields or tablelock so the procedure can finish without interruption.

http://www.lanhamassoc.com/

They won't deal with you directly (usually) if you already have a partner.

joshplummer

I appreciate the responses, but I think I'm dealing with a more fundamental issue.

Denster's comments are correct, we are customized, but not in the areas I'm referring to here.

In the sequence of events things go like so:

1) Shipper Creates 10 Order Multi-Pack in Navision
2) Shipper Presses Button to close order
3) eShip begings processing orders 1 by 1.
4) Order 1 is processed successfully.
5) Invoice 1 is created. Stock is relieved. AR is created. Order 1 is deleted. All this is now fully committed to the database.
6) eShip moves on to Order 2
7) Order 2 encounters an inventory shortage
8) An error occurrs on screen, shippers get angry because eship blew up again
9) eShip retains the linkage between the 10 orders, even though order 1 is now completely gone.
10) Someone fixes the inventory error.
11) Shipper attempts to pick up where he left off
12) eShip produces an error the shippers don't understand
13) Shippers call the foreman, again frustrated
14) Foreman gives orders to Inside Sales
15) Inside Sales ships and invoices the remaining 9 orders by hand
16) Paperwork (Posted Shipments, etc...) is now in both inside sales and shipping...(parts in each place)
17) Later, rinse, repeat.....

As you can see, this is quite frustrating because eShip and/or Navision completely commits the first order rather than posting in a batch. I guess what I'm hearing is that there is no way to wrap a series of events into a transaction and rollback upon an error...

ara3n

As DenSter Mentioned you need to have the solution Center turn on codecoverage.

Filter on all the commits that happen.

Write a single instance codeunit.
Enable the CU before starting the posting of the document.

Every place where there is a commit write something like this.

//MOD10 start
If not SingleInstanceCU.SkipCommit then
//MOD10 end
COMMIT;


at the end of posting of statement issue the COMMIT and set the SingleInstanceCU variable to false.

If you don't use Single instance CU, You'll be passing the variable to a lot of places, and CU 80 has CLEARALL that will reset it.

So it's possible, you just need to contact your Solution Center.
Hopefully it's not mine

Alex_Chow

I wouldn't recommend asking your NSC modifying where COMMIT happens. They are there for a reason on why some commits are there in the first place. Without knowing the ins and outs of eShip, making such change may cause more problem down the road.

The best strategy is to ask your solution center to report the problem to Lanham and have them deal with it since they created the thing.

DenSter

joshplummer wrote:

I guess what I'm hearing is that there is no way to wrap a series of events into a transaction and rollback upon an error...

That's what we're trying to accomplish by bypassing the COMMIT. As you know, COMMIT is the NAV keyword that marks the end of a transaction, after which rollback is not possible anymore. Unfortunately, e-ship is full of COMMIT statements, and it is very difficult to determine which ones are absolutely necessary. To make sure that multiple postings are included in a rollback when an error occurs, you have to program around the COMMIT statements.

It will get tricky though because you only want to do that when you are actually posting one transaction rather than posting multiple orders as a batch. It's also tricky because sometimes you have to have a COMMIT to get certain things done, so I don't even know for sure if this suggestion will get the results you're looking for.

DenSter

Alex Chow wrote:

I wouldn't recommend asking your NSC modifying where COMMIT happens. They are there for a reason on why some commits are there in the first place. Without knowing the ins and outs of eShip, making such change may cause more problem down the road.

The best strategy is to ask your solution center to report the problem to Lanham and have them deal with it since they created the thing.

Of course the first step would be to get Lanham to look at this, but you will have to through a whole song and dance to prove that it also happens in standard e-ship, and with a heavily customized database it will be difficult to get support.

If you can reproduce the same error in a standard e-ship database, without any modifications, then you may have a case with them.

David_Singleton

joshplummer wrote:

I can't believe I'm the only one in the world that has encountered this problem with eShip, but I can't seem to find any other examples...

...

First of all this is a known issue I have discussed it with them and the solution they suggest is to switch off automatic posting of orders. Then someone goes through and reviews which orders shipped (well packed actually) and then posts them. Which is a full time job for one person at least.

This is a very common issue. Especially at the beginning of the month when someone forgets to roll forward the "Allow posting from dates" ](*,)

Generally I have one of two fixes.

1/ the safe one involved a report that goes through all packages for a day, and then locates the posted shipment. It then lists out all completed eShip transactions where the shipment did not post. Someone then reviews that report and manually fixes all the errors each night.

2/ Create a function that reviews what was successfully packed in a day, and then post those shipments. This is pretty simple if the client ships everything form the order, but if you part ship its very complex.

3/ I would not suggest modifying commits.

Sorry that in this case I must disagree with Daniel and Rashed, the option of removing the commits is really not an ideal solution, as there is more to the issue than just the commit. I did in fact once do that, and still we found more issues. So I am with Alex on this one. PS I am not speaking from what if theory, I have actually done all the 3 options, and 1 and 2 worked.

Oh there is a fourth option, not ideal but... . I didn't do this, I saw it at a client that had designed it for them selves. Where basically they have a list of all open orders, and a tick box where they can add that order to the Batch Post routine. Someone each evening goes through and ticks off the orders that successfully shipped and then batch posts. This is much faster than reviewing each order manually and posting.

Oh and in the eShip documentation you will read that it is not recommended to use auto posting of orders, so I doubt this will be a support issue, more like Time and Materials.

DenSter

Let me just say that I don't think turning off the COMMIT statements is a good practice at all, they are there for a reason, and I do agree with Alex and David that is should really not be done in general.

I posted my reply having some inside information, maybe I should have replied by PM. The person who started this thread works for a company that was a customer of the solution center I used to work for, and I was the lead developer on their project in the early days. From this personal experience I assumed that it would not be an option to not automatically post, or to introduce any new time consuming processes. Assuming that they would insist on the automatic process, I jumped to the option that is generally speaking not optimal.

David_Singleton

DenSter wrote:

... I posted my reply having some inside information, ...

yes that makes a difference

joshplummer

Thanks for all the replies. You've stirred some thought....

As Denster said, he was involved in this project very early on. A lot has changed since that time, and many decisions that were made early on are being question now. That said, it may not be a bad idea to start a batch invoicing process. We have the tools to automate, so that wouldn't be too bad.

My only question is, how many locking issues would this eliminate? If we still ship, just not invoice, what does that really save? The shipping process still has GL impact (through inventory) since we do automatic cost posting....

We're also going to place controlls at the start fo the process to check for the most common error conditions prior to posting. That won't eliminate the locking issues, but it will eliminate just about everything else.

I fully expect a response from Lanham would be "that's how Navision works...." along with a fee. Hence my post here first.

Thanks again...

Alex_Chow

G/L is not affected when you post shipment even when you have automatic cost posting checked on. It will only be affected if Expected Cost posting is checked on.

You have to make sure the error is caused by G/L, NOT inventory. Or else just ship without invoicing will not net you any benefits.

David_Singleton

joshplummer wrote:

...

My only question is, how many locking issues would this eliminate? If we still ship, just not invoice, what does that really save? The shipping process still has GL impact (through inventory) since we do automatic cost posting....

...

Very few.

The key is shipping, you need to turn off auto shipment posting, and batch that to really resolve this issue.

By the way at first glance this looks like a very easy fix, but it is actually quite extensive.

joshplummer

The deadlocks I've seen are in fact on the G/L Entry table.

We do have Expected Cost Posting turned on.

GoatMan47

Finally! Someone else who has encountered this same exact issue!!

We’ve been fighting this problem for years where I work, even before I came, and even after multiple upgrades have taken place. This issue has messed up our inventory on the system too, causing the “Quantity” on some of our item cards to not match with our “Bin contents” (due to the orders invoicing but not posting through the Warehouse entries..)

It’s a major headache, but I’ve figured out a way to fix this/post the affected order(s) after numerous amounts of hours of frustration and just plain digging.

First thing, leave the affected order open in pack line (if you close out of it, or hit the ‘x’ at the window to close it, chances are you won’t be able to get back into the order and will be stuck in a mess like we were). Next, open a new window in the system and go to your sales order list to type the affected order in, and you’ll want to open the card up for it.

Now depending on if it is an “insufficient quantity” error or “quantity to ship does not match item tracking (normally what my workplace sees most of the time) you’ll need to reopen the order, go down to your line items, and either unreserve a lot number or two to match up with your quantity to ship, or go to item tracking (if you have to add more to the reservation under 1 lot number) and change the quantity for your lot number to match the amount in the “quantity to ship” column. You should be able to re-release the order then, open a NEW pack-line window (leaving the other one open still), scan back into the order that gave the issue and proceed to ship it.


Note: if there are other items on the order that are shipping at a later date, you may want to make sure you remove any reservations and quantity to ship values for those items. The system will try to ship all of the items associated with that order when doing this.

(Of course, this would be a lot simpler to explain if I was able to screen record the process used other than typing it out..)


Now we experience it on single orders too where we get a certain error message but the order invoices anyway… unfortunately, we don’t have the capability to just adjust the bin content values. (In order to be able to do that, the location code used to invoice and sell from has to be set up a certain way in order to access “Warehouse Item Journals.” If we had a location set up for that in our system, we could easily fix the inventory issues with our bin contents that we’ve had on a lot of our items for years…

All things aside, (granted I’m way late to the conversation) I hope this helps somebody out there who experiences this same issue.