Item Setup - Same part in multiple locations

Fisherman · 2006-06-29

I have a setup question...

We service the same customers from multiple locations. Many of our part numbers are the same, but they may be carried differently. For example, in Location A, we may carry part "ABC" as a purchase item for Customer 1. In Location B, we may also carry part "ABC" as an assembly with an attached build plan. Not only this, but overhead rates, costs, prices, dimension codes, etc... may be different. In our old system, the users set up the parts that were being sold to the customer by the customer's part number, parts that were only being purchased (used in assembly) by the vendor's part number, and sub-assemblies were just given a number.

We had considered using SKUs for this situation, but discovered that there was not enough flexibility at that level to meet all of our needs (can't define some dimensions, BOM, etc...).

My thought now is to have all parts with an independent numbering system, and cross-references to our Barcodes, Vendors, and Customers, so that our part number is invisible to anyone except those doing setup (BOMs, Item setup, etc...). This eliminates item sharing.

Others don't agree with me. Is there any other mechanism in Navision that allows segregation of items?

Thanks

johnson_alonso · 2006-06-29

There is no other choice except creating 2 item card for the same item numbers but you must set subdivision of the item. Or another choice is making a customisation, you could ask local NSC developer to do that.

Rgds,
Johnson

http://sea-navision-community.blogspot.com

Fisherman · 2006-06-29

I'd rather not get into that... the primary key of the items table is just the [No_] field. Any modifications would require a compound primary key, and I don't know what that would do to the system as a whole

johnson_alonso · 2006-06-29

If one of your items consists of two replenishment system in different locations or multiple locations, you can use SKU card, but the weakness of SKU, there is no sales or purchases button or complete item button like in the item card. That's why I suggest you to make some customisation for that.

Rgds,
Johnson Alonso

"In God we trust"

http://sea-navision-community.blogspot.com

ara3n · 2006-06-29

For one of our customer we implemented SKU and moved BOM, costing, Dimensions based on SKU. The modifications aren't that big and it fits them perfectly.
The client has mulitple plants and they purchase and manufacture goods from each other.

DenSter · 2006-06-29

Fisherman wrote:

I'd rather not get into that... the primary key of the items table is just the [No_] field. Any modifications would require a compound primary key, and I don't know what that would do to the system as a whole

You don't have to modify the primary key of the Item table to accomplish things that you describe. You could add a table that stores different BOM numbers for different customers for instance, and you modify the BOM logic where needed to look in there instead of at the Item's BOM number. Of course I don't know the whole requirement, but it sounds to me like you could use a visit from the senior consultant on your account from your solution center to determine the requirement and let them propose a solution.

Fisherman · 2006-06-29

Den -

BOMs are only part of the problem (although they do make up a good part of it). We would need more than a few lookups tables to get the job done. We have talked to our Senior consultant from our NSC...

ara3n -

Are you saying that you were able to move these fields/functionality to the SKU card? We were told that this couldn't be done. Please advise...

DenSter · 2006-06-29

Fisherman wrote:

BOMs are only part of the problem (although they do make up a good part of it). We would need more than a few lookups tables to get the job done. We have talked to our Senior consultant from our NSC...

You're focusing on my solution, not my point

, which I said was limited by havig no knowledge of your requirements. My point is that I have never seen the need to make the Item table's primary key compound, and I sincerely doubt (99.99% certain) that that would be necessary.

It sounds to me that you should be using SKUs and maybe add some logic to costing and assembly lists/BOM. Depending on whether you use the automatic replenishment system or MRP this could turn into more significant work.

Fisherman · 2006-06-29

OK.

I appreciate the reply. We had been told that moving the fields that we would require to the SKU level would be impossible. Production BOM is one of them, there is a dimension value and a few other fields that would be necessary.

You're saying that it is possible to move Navision-native fields from the item card to the sku card? Right now we would be using MRP for most of our operations (probably all of them). Hopefully, automatic replenishment could be a goal in the future, but baby steps.... baby steps

DenSter · 2006-06-29

You'd have to set up SKUs anyway to run MRP, so that's where I would look for a solution. It's not so much "moving fields" as it is replicating fields with the same or similar functionality. Again, I am not familiar with the details, but I do get the feeling that your solution center is not very familiar with this area if they told you 'impossible'. The modification might be extensive (and possibly because your solution center knows your budget situation they knew it would be too expensive maybe), but I have yet to see any real life business logic that is actually impossible to implement in NAV.

ara3n · 2006-06-29

I agree with DenSter. SKU is allready used for MRP and manufacturing and costing. Basically Navision creates a dummy temp SKU if the Item doesn't have SKU and it uses it in Manufacturing, Costing, MRP. Yes the modification will touch a lot of objects and it will be straight forward.
So the answer on whether it was impossible to do was based maybe on other reason, budget, mitigating risks, time.

Miklos_Hollender · 2006-06-29

Maybe the cleanest solution would be to treat them as individual Items and put the old part no. in the No. 2 field as a reference and as a reminder.

Fisherman · 2006-06-29

No 2 Field? I didn't even know that existed until you said that. It's not on our forms, and our NSC never mentioned it.

Does Navision just treat this like a reference? If I put in the value from the No 2 Field, will Navision be able to look it up?

[edit] Nevermind that last part. I've tested it. I didn't think I would be able to reference it from other forms (PO's, Sales orders, etc...)

That would be one of the requirements. Whatever field we used for this, the users would need to be able to easily select the item by it. That's why I thought about cross-references.

Miklos_Hollender · 2006-07-01

Get used to using Zoom (Ctrl+F8) because there are a lot of hidden fields. Just zoom Item Journal Template or General Posting Setup and you will go WOW

I think if you just put this field on the Item List form, users can filter and search for it and press Enter to pull the record into the document. Of course the document would still show the new No. but it's 3 lines of code to show the No. 2 as well (GET the Item, if successful, put into a variable and show the var in a textbox writing the var name in the sourceexpression).

ara3n · 2006-07-01

I don't think you can create separate Items for every location. What happens when You transfer items from one location to another location?

Miklos_Hollender · 2006-07-02

There is a magical property which I forgot - but will look up Monday if you are interested - either on the table or on the form, that makes f.e. you key in the Description of the item in the Order in the No. field and it finds the Item. You could use it with No 2. too.

ara3n · 2006-07-02

The property is called AltSearchField and it's on the table field property.

Fisherman · 2006-07-03

Oddly enough - that's not a requirement of the business. We do it occasionally (every year or two) if a line of business is moving from a distributed design to a centralized one (all business for that line occuring from one location). In that instance, in the old system, they have created PO's and sold the parts between locations.

Fisherman · 2006-08-29

Sorry to ressurect one of my old threads, but I've been asked to investigate this further.

In IT, we recognize the problem and understand that the data cannot exist as it does in our current systems. Our existing system uses a compound primary key, which makes it possible for the same item number to exist more than once (if it's in a different division).

Plant managers accept that there is a problem, but are still resistant to change. Because of that, we have to implement a system that solves the issue (redundant item numbers) AND keeps operations happy (by being transparent that we've solved the issue). They want to see the item numbers that they've always seen...

Now - I've made some modifications in my test environment. I changed the AltSearchField on Item."No." as suggested, to point to Item."No. 2". This works beautifully from forms like the Item form and Purchasing/Sales Orders. I've also changed the Item List to use "No. 2" as the source field for the first column, instead of "No.".

I know that I will have to change reports so that the SourceExpr property points to "No. 2". What I'm wondering is this - what about Navision standard CodeUnits, Dataports, XMLPorts. My instinct tells me that, since my front-end transactions will be pulling Item."No." based on what the user enters in Item."No. 2", then these shouldn't have to change. I would think that we would have to change only those areas that we have revised or created as new... am I off-base here?

Savatage · 2006-08-29

I had to make a change for item journals a while ago

http://www.mibuso.com/forum/viewtopic.php?t=5863

Fisherman · 2006-08-29

I had noticed that using Item No. 2 & AltSearchField seemed to work well in Sales and Purchasing - I assumed that it would work equally well in Production/Manufacturing and Shipping and Receiving. I need to test that, though.

By changing my "Item List" form, I also have given the users the ability to search by Item No. 2.

If I'm reading your post correctly (and I may not be between the flu and my lack of sleep), you found that even after changing the AltSearchField, certain areas of the system (Item Journal) didn't allow you to search by that "No. 2"?

Savatage · 2006-08-29

I'm trying to emember myself but by reading that post it seems the Item Journal used code instead of AltSearchField.

But It looks like if I used the items "Search Description" instead of "No. 2" I don't think that many changes would be needed. In fact Who really uses "Search Description" anyway it's the same as "Description" if you don't manually alter it.

The reason we used No.2 is in our old system we had a 3 letter-3 digit item # ex/ABC123.
When we switched to Navision we decided to re-do the whole thing and change it to a 5 digit code [00001 to 99999] But we didn't want to have to Re-label the entire warehouse. So we have our Old item # in "No.2" which shows on our Picking tickets and a few other places. It works great and it allows us to slowly change the labels a few at a time instead all at once.

at least that was the plan 3-4 years ago. But since it causes no trouble at all to use No.2 field that we have practically made no label changes.

Savatage · 2006-08-29

..In addition

Fisherman wrote:

you found that even after changing the AltSearchField, certain areas of the system (Item Journal) didn't allow you to search by that "No. 2"?

You can always add a field and search - what I wanted was to be able to enter EITHER "No." or "No. 2" into the field and get the correct results. Many people were used to the old number and were resistant to change.

You can add that "No. 2" field to anything.

Fisherman · 2006-08-29

Thanks.

I've gone to Warehouse -> Goods Handling Multiple Orders -> Whse. Item Journals and created a new line by entering a value from "No. 2". When I did, it pulled the correct item...

but - here's the kicker. If I add a second item with that "No. 2" value, and a different "Dimension 1 Code", which is our company division number, then it just pulls the first item in sequence...

Savatage · 2006-08-29

One choice could be as suggested below in "No .2"

BlackTiger wrote:

Just create two different items for "Item A" and "Item A+something".

Field "No." is just internal item number. Store "Product Number" is any other field ("No. 2", "Search Description", custom field).

This will help you avoid A LOT of problems in the future. And just more logical. Otherwise you have to rewrite a lot of code.

JohnCon · 2006-08-31

The correct direction to this issue is to use SKU's and modify. Your NSC is wrong that it cannot be one.
The description 2 field is in all tables that the main description is in so you can see it everywhere.

some main points ... NEVER NEVER change the primary key of a standard Navision table, especially not the item table.

The old rule always applies to all systems - Form,Function,Fit - only if one of these changes should you have a different item no.

Use the SKU to do what you are asking.

Fisherman · 2006-08-31

Thanks John..

We have already ruled out changing the primary key of the table.

We had discussed using SKUs, but the plant managers are averse to it.

let me paint you a picture -

We have three systems:

1. A WMS that is based on SCO and Informix. It's been running since 1995. It is extremely basic and only functions for WMS for some of our non-owned, distribution operations.

2. An MRP/WMS that is based in SQL 6.5 and has been running since 1996. Also very basic. This handles most of our owned-inventory and sales transactions.

3. An Accounting package. Based in SQL 6.5. The last update was in 1998.

My point is this - while I support the heavy use of SKUs and Cross-References, this is the first new system in 10 years. No system that we have supports multi-way referencing like that, and the plant managers can't afford to disrupt operations (we have some very large customers to please). That's why when Miklos said this...

Maybe the cleanest solution would be to treat them as individual Items and put the old part no. in the No. 2 field as a reference and as a reminder.

...it got my gears spinning... that's why I'm investigating the idea of having the No. 2 field show on screen/forms/reports/etc..., and hiding the actual item number - relegating it to a function of the DBMS to maintain integrity.

To be honest. I wanted to use SKUs. But then - I think that two items held in two different places with different costs are different items, no matter what their names are

.

DenSter · 2006-08-31

SKU's are combinations of Item number, Location number and Variant code. Whatever the reference is in any table, the Item number references the same Item no matter where from it was shipped. The power for having this drive replenishment is so you can determine demand for an Item in a certain location, for a certain Variant. If you don't need the Variant specification, you leave the Variant blank on the SKU. If you don't need the location specification, you leave the location code blank.

Stockkeeping Unit is a calculation unit really, but still the same Item.

DenSter · 2006-08-31

Fisherman wrote:

We have three systems:

1. A WMS that is based on SCO and Informix. It's been running since 1995. It is extremely basic and only functions for WMS for some of our non-owned, distribution operations.

2. An MRP/WMS that is based in SQL 6.5 and has been running since 1996. Also very basic. This handles most of our owned-inventory and sales transactions.

3. An Accounting package. Based in SQL 6.5. The last update was in 1998.

So what do you use Navision for? Has it been discussed that you can use NAV for all of those functions?

Fisherman · 2006-08-31

We're trying to replace all three systems. We have approx. 8 locations across 4 states, and each of them runs some combination of the above systems. The goal is to have one system when all is said and done.

The data migration has been the hardest part. I've had to write some pretty extensive openrowset queries to combine the data from all systems. Some of the things that have been done were under the radar of IT, and long before I came to this company, so there's been an massive amount of data cleanup/massaging involved in the exports.

Howdy, Stranger!

Quick Links

Categories

Item Setup - Same part in multiple locations

Comments