I'm not sure when it started but I've noticed that my "0" O.H. DELAY PNC's are not converting to regular part number changes.
Anyone else having this problem? Anyone have a correction?
Delay PNC
11 posts
• Page 1 of 2 • 1, 2
Delay PNC
by drapp » Tue Aug 04, 2009 11:53 am
Let me guess, you are a GM dealer currently on RIM. If yes, read on. If no, ignore.
This is a known problem that I fought for months. It is still not fixed. I gave up trying to convince ADP how serious an issue this can be. I believe there is a defect written on this but there is no way I can be sure. I also can't speak to the timing of such a defect being or ever being addressed.
The only work around is to manually break the DELAY PNC apart and then manually create a "regular" PNC.
The problem is caused by ADP not dealing with the RIM software properly. As you know RIM software (state codes) change your ADP special status codes. For a DELAY to change to a PNC the SS must be DP (if I remember correctly) when month end runs. RIM will generally change a DP part number back to a blank status because RIM thinks it is managing the old number. When month end runs the ADP software will not process a DELAY to a MEMO if the old part number has a blank SS (or anything other than DP). Therefore your system sits there with all these DELAY PNCs and no on hands.
As you know this has the potential to allow a guy to special order a part you actually have in stock. The system will not prompt you if you enter the old part number. You have to look at the screen to see the DELAY then F4 out and manually enter the new part number to actually sell it. Of course then GM sometimes still has stock on the old number but that is a whole different story.
Rant over...for now
This is a known problem that I fought for months. It is still not fixed. I gave up trying to convince ADP how serious an issue this can be. I believe there is a defect written on this but there is no way I can be sure. I also can't speak to the timing of such a defect being or ever being addressed.
The only work around is to manually break the DELAY PNC apart and then manually create a "regular" PNC.
The problem is caused by ADP not dealing with the RIM software properly. As you know RIM software (state codes) change your ADP special status codes. For a DELAY to change to a PNC the SS must be DP (if I remember correctly) when month end runs. RIM will generally change a DP part number back to a blank status because RIM thinks it is managing the old number. When month end runs the ADP software will not process a DELAY to a MEMO if the old part number has a blank SS (or anything other than DP). Therefore your system sits there with all these DELAY PNCs and no on hands.
As you know this has the potential to allow a guy to special order a part you actually have in stock. The system will not prompt you if you enter the old part number. You have to look at the screen to see the DELAY then F4 out and manually enter the new part number to actually sell it. Of course then GM sometimes still has stock on the old number but that is a whole different story.
Rant over...for now
- drapp
Delay PNC
by drapp » Wed Aug 05, 2009 11:21 am
drapp .......Is this an ADP problem or a GM problem?????????
Interesting comment. Of course they 'want' to point the finger at each other. But this time I believe ADP understands that it is their problem. If I understand correctly the DMS providers signed a compatability agreement to provide RIM integration. GMSPO spelled out specific requirements that must be met. DMS companies were told exactly what data would be 'exchanged' between systems. How the DMS companies dealt with the changes this data exchange created was up to them, as long as they met the GMSPO requirements. Since this DELAY PNC problem wholly exists within the ADP system I personally believe the problem is soley ADP's at this point. Of course I have no other information other than my limited understanding of the problem. As always these issues are more complex than a user will ever understand. Besides I am only the CUSTOMER why should I be informed or considered in the big picture.
Interesting comment. Of course they 'want' to point the finger at each other. But this time I believe ADP understands that it is their problem. If I understand correctly the DMS providers signed a compatability agreement to provide RIM integration. GMSPO spelled out specific requirements that must be met. DMS companies were told exactly what data would be 'exchanged' between systems. How the DMS companies dealt with the changes this data exchange created was up to them, as long as they met the GMSPO requirements. Since this DELAY PNC problem wholly exists within the ADP system I personally believe the problem is soley ADP's at this point. Of course I have no other information other than my limited understanding of the problem. As always these issues are more complex than a user will ever understand. Besides I am only the CUSTOMER why should I be informed or considered in the big picture.
- drapp
Delay PNC
by Mike » Wed Aug 05, 2009 12:55 pm
Drapp - thanks for the info. Yes, I am a GM dealer on RIM and the scenario you've described is exactly what is going on here. There's no comfort in knowing I'm not alone with this problem. Have you, or does anyone else have an open case on this?
Short term solution is an ENG search and then breaking the chain manually, but manually fixing the DMS on a regular basis gets old!
Anyway, thanks for the reply and info.
Short term solution is an ENG search and then breaking the chain manually, but manually fixing the DMS on a regular basis gets old!
Anyway, thanks for the reply and info.
- Mike
Delay PNC
by drapp » Wed Aug 05, 2009 1:58 pm
I no longer have an open case. Previous case number was 107804524.
Here is the important portion of that previous case. This is one small section:
This is a software defect on our side.
When a part is put on DELAY, the SS on the old part should be DP. When the GM State Code file loads it changes the SS of the part (assuming the appropriate state code). This causes issues when MNE runs, and the DELAY's will not update properly.
Tagged Defect 222264 to this dealership.
Here is the important portion of that previous case. This is one small section:
This is a software defect on our side.
When a part is put on DELAY, the SS on the old part should be DP. When the GM State Code file loads it changes the SS of the part (assuming the appropriate state code). This causes issues when MNE runs, and the DELAY's will not update properly.
Tagged Defect 222264 to this dealership.
- drapp
Delay PNC
by gmcgrew » Wed Aug 05, 2009 3:02 pm
Drapp I am not sure this is ADP's fault. If I am following this correct RIM is updating a status on a part that is no longer active. I know I have had issues where RIM keeps tracking an old number that has superceded. I don't normally use the delay PNC's but I exclude the old number until RIM can get the correct number in the system. If the old number in the PNC is excluded in RIM is the status still changed at the end of the month?
- gmcgrew
Delay PNC
by drapp » Wed Aug 05, 2009 9:43 pm
gmc
Since ADP had created a defect file I can only assume ADP thinks this is an ADP issue.
As for excluding the part and letting it go through month end, I never tried it. I believe that would create a state code 03 or 07, but I don't know what SS that would create on the ADP system. Currently I have no excluded part numbers so I can not check it.
As for the no exclusions, don't ask. I am currently experimenting.
Since ADP had created a defect file I can only assume ADP thinks this is an ADP issue.
As for excluding the part and letting it go through month end, I never tried it. I believe that would create a state code 03 or 07, but I don't know what SS that would create on the ADP system. Currently I have no excluded part numbers so I can not check it.
As for the no exclusions, don't ask. I am currently experimenting.
[This message has been edited by drapp (edited 08-05-2009).]
- drapp
11 posts
• Page 1 of 2 • 1, 2
Who is online
Users browsing this forum: No registered users and 19 guests