Changing F4101 LITM - good, bad, and/or ugly

Frosty the Coder

Legendary Poster
Due to "we've done this before, let's do it again", mgt instructed staff to change the long item#.
They were also instructed to do it "RFN".

I tried to reason that "being able to" and "should do" can be different things.

I don't believe that World 7.3.11 automagically changes LITM in ALL tables it exists.
Does it?

If not, is there a "all powerful DWV" that does it?

What would be the BEST PRACTICE for doing this (other than not to do it)?

Create a new item and have the old item in history?
This causes ANYTHING-to-date reports to show two diff items.

Just curious, as the damage has already happened (this time).
I'd like to try to avoid/improve this the next time.

Please AND Thanks
Gene
(feeling VERY dysfunctional today.....
tongue.gif
)
 
Two answers about changing part number. Yes, you can have the change to the part number populat to "all tables". Check processing option #7 on P4101, should be set to '2'.

Secondly, if this was NOT set this way and lots of part number changes have occurred, there is a batch version P40821 that you can run (set selections as you need), that will update the part number "globally". Be careful with this process. If you have lots of part numbers that are going to run through this batch process, it may take awhile to run. I have had to "programmatically" change the part # in F4101 and then use this batch process to update the entire rest of the system and 15,000 parts took just about a weekend to process. It can run while people are in the system but it is a CPU hog and can drag things down.

You next question was "SHOULD this be done or should they create another part number". That really depends on the business decision. If you use the above process, then obviously all the history for that part will also change to the new part number so "historically", it will appear you have been selling/using this part for a long time. If everyone is OK with that, go for it.

If instead, this is a case of "part number was superceded", then I would be creating a new part number and obsoleting the old one, setup a cross reference for replacement, and moving ahead with the new part number. In my case, we have done both. Maybe a person typed in the part # wrong and nobody noticed for a few months so indeed, just letting the system update the entire system with the new part number is just fine. Same goes for possibly some part numbers you maintain that are vendor part numbers in your system. They change their part numbering scheme so you update JDE with the new part number as if it was always that way.

Hope my rambling makes sense.
 
Shannon, the rambling makes PERFECT sense.

Thank you very, VERY much!
Gene
 
I'm so glad it's Friday,
I'll have two whole days to consider NOT coming back on Monday...

I was just asked whether I can change an item's GLPT "everywhere",
so sales histories will show it under the "new GLPT".

I'm NOT a fan of changing historical data.
I know that AUDITORS aren't fans of doing so, either.

It would seem to me that prior sales, under the old GLPT
will have already posted to F0902/F0911.

Further, unless the new GLPT posts to the same place,
I'd have to adjust the ledger to do this.

Can this be done, w/in existing JDE?
SHOULD this be done?
It's a family owned firm, so SOX isn't in the picture.

Please AND Thanks, some more.
Gene
 
Well, if you had a data warehouse, which I am guessing you don't, you could just change how the history is loaded to the data warehouse to reflect the new assignment.=C2=A0 Maybe something like this will convince your managem ent to consider looking at a data warehouse solution.=C2=A0 You don't want to change F0911 and F0902, at least not without the the approval of the acc ountants and the auditors.=C2=A0 Sales history could be changed, since that would not be doing any more posting to the general ledger (not that I am r ecommending that sales history be changed).=C2=A0 But if reporting is being done off sales history, changing sales history so that the reporting shows the new value would not be so bad, though I would not want to change histo ry.=C2=A0 You would be better off changing any reporting to maybe first bui ld a a work file with the new value and then report off the work file.=C2 =A0 Or consider a data warehouse solution to handle these kinds of things. =C2=A0 Something to
think about.
=C2=A0
John Dickey
 
I would think that would be extremely "bad form" and not a good idea. And what point would it really serve? I guess if the "new" GLPT pointed to the same account as the "old" one it would be no big deal.

All I know is that if it IS different, the problem is that (at least to my knowledge), if you change a GLPT on a part today and the part has Qty on hand, you have just screwed things up. And there is no way to find these problems once they occur. When the part came into inventory, $ went one direction, now you have changed the GLPT that points to new accounts and the $ now go a different direction. One account never gets $ relieved from it and the other is taking $ out of an account it never had the $ in in the first place.

Since users can do this themselves, there is no way to catch the problem unless they are told NOT to do this without adjusting the inventory to zero, change GLPT, then adjust the inventory back in.

I wish that JDE built in that "if you change the GLPT at the Location level on a part and that part has Qty in inventory, it would create a batch offsetting the accounts affected" (move $ from old account to new account according to the AAIs).

Am I asking too much!?
 
The shop is too "frugal" to consider IT improvements.
ANY IT improvements.....
frown.gif
mad.gif
 
Consider changing the description assigned to the currently used GLPT, instead of changing the GLPT.
 
Our policy is to not edit IMLITM except for a typo made while creating the item master.<font color="white">.</font> The point is that if you change the JDE database, any external records will reference an item number that is now effectively corrupted...and why should you even try?<font color="white">.</font> Just make a new item master and mark the stocking type of the bad item master 'U' or 'O'.<font color="white">.</font>

In B7333, IBLITM is not updated when IMLITM is edited, so the following query will tell which IBLITM have had their IMLITM edited.
<font class="small">Code:</font><hr /><pre>Select IMLITM, IBLITM, IBMCU
From PRODDTA.F4101 (NoLock)
Join PRODDTA.F4102 (NoLock)
On IBITM = IMITM
Where IBLITM <> IMLITM </pre><hr />FYI,
Robert Berkey
B7333 SP18.1 SQL Server 2000
 
Creating new LITMs was my original suggestion to them.
However, I don't make decisions, only suggestions.

Regarding the GLPT, they want to break future tracking of certain items away from the current setup.
I've been told that I don't have to worry about history (whew).

BUT, I'm not finding the link between IMGLPT and the g/l account where they want it.
I've looked at ACCT setup, the UDC behind GLPT, and at as many menus as I could find.

Where am I overlooking this?

Please AND Thanks
(still dysfunctional)

Gene
 
The link between GL Class Codes and GL accounts is established by the Automatic Accounting Instructions (AAIs). In our system there's a shortcut - DMAAI - to take you directly into the distribution AAI maintenance program.
You want the 4200 series. There's a separate one for each side of each journal entry associated with a sales transaction. 4220 is for Cost of Goods Sold, 4230 is for Revenue, and so on. By company, sales order document type and GL Class Code you can direct these journal entries where you want them to go in the GL.
The thing that could trip you up is that the Sales Update program uses the GL Class Code from the F4211 record (SDGLC) to look up the account number based on the AAI. This field is populated, as far as I know, from the Item / Location (F41021) record for the item / branch in question.
So if you change the IMGLPT, you also need to change it in the item/branch file, and then for every location that exists in that branch for that item. (Push F11 from the Item / Branch maintenance screen.)
Also, if you use advanced pricing, the GL Class Code for the price adjustment AAI's comes from the price adjustment header file.
There are some good knowledge documents on distribution / manufacturing AAIs. I'd be happy to answer any questions you may have if I can.
Regards,
 
I had glanced at AAIs but didn't understand what I was looking for.

My years of being a coder have kept me both ignorant and apathetic.
(That's right, "didn't know AND didn't care.")

Thanks much for your quick, and detailed reply.
Thanks ALL for past, present, and future assistance.

Gene
 
Back
Top