EDI - What is possible without changing core NAV?

Michaellee

Hi all,

I have an issue where we will be receiving EDI orders from 1 customer and they need to be shipped to many locations. I have looked and there doesn;t seem be to any functionality in standard to be able to place ship-to codes on the lines and then create 1 bulk ship and pick list for it. Unfortunately, there could be over 1000 (home delivery) different ship-to codes for one order so to create and process 1000 orders would crazy...

Can you let me know if you have any suggestions? Of course, adding new code is fine but I don;t want to affect core tables if at all possible. (I know it;'s wishful thinking...)

Thanks,

Mike

ara3n

you can just add the ship-to code to the line. You have to modify the shipment document to print separate document based on ship-to code from lines.

If you are using warehouse management, you have to modify the shipment documents to create separate documents by ship-to code. Also any printed document from warehouse have to be update to print the correct ship-to address.

Alex_Chow

Michaellee wrote:

Hi all,

I have an issue where we will be receiving EDI orders from 1 customer and they need to be shipped to many locations. I have looked and there doesn;t seem be to any functionality in standard to be able to place ship-to codes on the lines and then create 1 bulk ship and pick list for it. Unfortunately, there could be over 1000 (home delivery) different ship-to codes for one order so to create and process 1000 orders would crazy...

Can you let me know if you have any suggestions? Of course, adding new code is fine but I don;t want to affect core tables if at all possible. (I know it;'s wishful thinking...)

Thanks,

Mike

Standard NAV does not have ship-to code on the sales lines.

If you do not wish to create 1000 different orders, the request will need to be customized. Without modifying core NAV, the user can do the following:
1. Modify the Qty to Ship for the items to be shipped to a particular ship-to address
2. Post Shipment
3. Change the ship-to code
4. Repeat steps 1-3.

Needless to say, this is a horrendous waste of time. Why don't you want to make changes to NAV?

Michaellee

The company policy is to make as little changes to core NAV as possible We can create new tables/forms etc but want to minimise the amount of changes on core tables due to rev-lock fears. This also provides us with a very simple upgrade path. (for example, a poster on this forum got quoted $40k+ to upgrade!)

Of course, if the benefits outweigh the costs etc it could be possible to ok the change and I think that I know how to do it but I would like to ask the question first.

Thanks for your help.

Mike

themave

Michaellee wrote:

The company policy is to make as little changes to core NAV as possible We can create new tables/forms etc but want to minimise the amount of changes on core tables due to rev-lock fears. This also provides us with a very simple upgrade path. (for example, a poster on this forum got quoted $40k+ to upgrade!)

Of course, if the benefits outweigh the costs etc it could be possible to ok the change and I think that I know how to do it but I would like to ask the question first.

Thanks for your help.

Mike

From the users with the 40K quote, there arn't a lot of ways around the problem, if you use new tables, forms etc, those are not really cheap either, 10 tables is $800
I beleive 10 codeunits also cost $800, 10 xml ports etc.

my company has a little over 1000 tables in Navision,

Say you need to modify 1/5th of them, that is around $16,000 for 200 tables, and probably and equal amount for the new code units, Plus you would need to modifiy standard navision so everything pointed to your new tables, forms, etc. since navision navigates so well between items that would be a big job to get everything to navigate to your customer forms.

I agree you are taking the right track, in looking at it from an upgrade standpoint, but you probably are just going to have to make sure your developer makes well documented changes, so the upgrade can go a little easier. That will likely mean using some new tables. but a lot of it with be changing standard code.

ara3n

just one correction. 100 forms/CU/Report cost $800.00

themave

ara3n wrote:

just one correction. 100 forms/CU/Report cost $800.00

themore I think about it, modifing 200 tables is probably way on the high side.

might be worth it to do with all new objects

DenSter

$16000 to upgrade 200 tables? Where do I sign up?

David_Singleton

Michaellee wrote:

Unfortunately, there could be over 1000 (home delivery) different ship-to codes for one order so to create and process 1000 orders would crazy...

Why would this be crazy?

In my experience when some one says "there could be 1,000 xyz" it generally means that in a theoretical situation it might happen, but the norm is that its not every order that has 1,000 delivery addresses I assume.

You say "one customer" does that mean that its just one order per day from this one customer? If you have say 200 customers sending you an order a day that has 1,000 ship to's then I agree that handling 200,000 orders a day will be an issue, especially if there are dimensions involved etc. But if say its only 20 customers a day, and the worst case is 1,000 ship to's and say the average order has 250 ship tos, then it becomes 5,000 orders per day, which is a pretty easy volume to handle.

On top of this, you need to consider WHY you don't want multiple orders, I can see a few possible reasons:

Possible issues
• You want to keep just one order no. (Can be solved simply with ONE new table).
• Issues with managing multiple orders (see above, its actually easier with multiple headers).
• Issues with posting performance. (This is a misnomer, since you are posting the same amount of data in any case, so no issue).
• Problems with Dimensions causing locking. (The biggest dimension issue is going to be line based, not header, and splitting the order into multiple headers will actually simplify the locking because of the way you will be able to better manage the individual lines.)

So basically I think you just threw the baby out with the bath water by not considering using multiple order headers. In your situation I would revisit that option, and basically eliminate all your problems in one hit.

DenSter

I will sign up for $16000 just for 200 tables any day of the week, it doesnt matter what system it is. I will upgrade ANY 200 tables for $16000 EVERY time.

David_Singleton

So Mike, what did you decide in the end?

Michaellee

I think that we will just have to bite the bullet and develop on core... Thinking about the other possibilities would just lead to a severe amount of manual process...

Of course, documentation is key we have done 1 implementation and 2 upgrades in a year (NAV 5, NAV5 SP1, NAV 2009) but not looking forward with NAV 2009 SP1 and our vertical add-on upgrade... just how many upgrades do we need?! :shock:

Anyway, thank you all for your feedback

Mike