This may be a very long shot....especially given that we should be able to expect that the bug reported way back in 5.2 would not still be in 8.0....also slim in that it may not be relevent to your situation. But, just incase.....
IF your DMR reason codes and RMA reason codes are mostly the same BUT you have one or more DMR codes not the same and one of these is related to your inspection processing case.....then perhaps the following excerpts from a posting in 2003 will shed some light on it. The case below would appear to be opposite from yours but might still be related as cause in 8.x. And confirm an old bug lives on in a new form.
The heart of the issue as explained below is that in the reason codes table (as it was in 5.2 anyway, I can't check 8.x yet) is that there is a type code in the table...D for DMR and A for RMA....and this code was getting misapplied when reasons were stored. All workd well if all the reason codes are the same for both types but if your Crystal report is linking for type D and a specific DMR code it might not find it and then exclude the record. A left join might fix it. Or, join for type "A" and see if it works.
Again, a long shot, but if this proves to be the case let us (and Epicor) know by posting a reply. I would like to give Epicor the benefit of the doubt and assume it was fixed ages ago but if not this sort of thing would be inexcusable.
-Todd C,
Old message text from 2003 ----------------------------------------------------------
As seen in 5.20.313:
In RMA Disposition none of the RMA type reason codes (entered via QA mod Reason Code Maint) show up in the drop down list that is activated when failing returned parts. But when the same reasons are added under DMR type they do show up in the drop down list. Likewise when I add a reason via the drop down list (using the <add>) the reason gets added to the DMR types. So both ways it is using the DMR type reason codes. Apparently it does not use the codes entered for RMA type at all. There was a change related to linking RMAs amd DMR between 5.10 and 5.20 so maybe this was part of that.
What this says to me is that there is a bug in the code as relates to the type in the reason code table being used by the RMA Disposition screen. Those "types" are bolted into the system (can't add or delete types). In the Disposition screen I have a strong hunch that the type is hard coded in the link to the Reason table (A for RMA, D for DMR) and that "D" got used when it should have been "A". Then in the RMA Processing screens "A" was used so it looks up the description for the RMA reason. Should be easy enough for them to check the code and verify (and fix).
OK, my wild theory in this case, which might explain why some show up and not others:
If this bug still exists and your DMR reasons are similar to the RMA reasons then if you happen to have one you are using for DMR that is not also an RMA the tracker may not find it and might be losing the entire record. I've seen this behavior before in trackers. Check the reason codes on some of the missing transactions and you might want to also add it to RMA reasons and see if it suddenly appears. The tracker may be mixing up the type codes. A long shot but easy to try.
----end excerpts ------------------
________________________________
From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf Of Sean Toler
Sent: Thursday, August 23, 2007 8:15 AM
To: vantage@yahoogroups.com
Subject: [Vantage] Crystal DMR Report
Hello.
I have created a Crystal Report that lists all of the rejected DMR's
for a given time period (for example a week). It is currently being
used with Vantage 8.00. 99% of the time all of the nonconformances
that are created are from parts manufactured in-house. 1% of the time,
we end up failing parts that were manufactured by a vendor. We fail
them in the PO Receipts tab of the Inspection Processing Module. This
then carries the failed quantity to the DMR module to await approval or
rejection by management or our customer. I noticed yesterday, after
failing some parts in I.P. that were manufactured by one of our vendors
that the DMR associated with this record is not showing up in my
Crystal Report. All of the DMR's that are a result of parts being
scrapped in-house show up, but not the DMR's generated from failing a
PO Receipt in Inspection Processing. For the life of me, I can not
figure out why. Has anyone else come across this issue and figured out
what to do to correct it?
________________________________
The information contained in this E-mail message and any documents which may be attached are privileged and confidential, and may be protected from disclosure.
Please be aware that any use, printing, copying, disclosure or dissemination of this communication may be subject to legal restriction or sanction. If you think you have received this message in error, please reply to the sender.
For more information please visit www.harveyvogel.com
[Non-text portions of this message have been removed]
IF your DMR reason codes and RMA reason codes are mostly the same BUT you have one or more DMR codes not the same and one of these is related to your inspection processing case.....then perhaps the following excerpts from a posting in 2003 will shed some light on it. The case below would appear to be opposite from yours but might still be related as cause in 8.x. And confirm an old bug lives on in a new form.
The heart of the issue as explained below is that in the reason codes table (as it was in 5.2 anyway, I can't check 8.x yet) is that there is a type code in the table...D for DMR and A for RMA....and this code was getting misapplied when reasons were stored. All workd well if all the reason codes are the same for both types but if your Crystal report is linking for type D and a specific DMR code it might not find it and then exclude the record. A left join might fix it. Or, join for type "A" and see if it works.
Again, a long shot, but if this proves to be the case let us (and Epicor) know by posting a reply. I would like to give Epicor the benefit of the doubt and assume it was fixed ages ago but if not this sort of thing would be inexcusable.
-Todd C,
Old message text from 2003 ----------------------------------------------------------
As seen in 5.20.313:
In RMA Disposition none of the RMA type reason codes (entered via QA mod Reason Code Maint) show up in the drop down list that is activated when failing returned parts. But when the same reasons are added under DMR type they do show up in the drop down list. Likewise when I add a reason via the drop down list (using the <add>) the reason gets added to the DMR types. So both ways it is using the DMR type reason codes. Apparently it does not use the codes entered for RMA type at all. There was a change related to linking RMAs amd DMR between 5.10 and 5.20 so maybe this was part of that.
What this says to me is that there is a bug in the code as relates to the type in the reason code table being used by the RMA Disposition screen. Those "types" are bolted into the system (can't add or delete types). In the Disposition screen I have a strong hunch that the type is hard coded in the link to the Reason table (A for RMA, D for DMR) and that "D" got used when it should have been "A". Then in the RMA Processing screens "A" was used so it looks up the description for the RMA reason. Should be easy enough for them to check the code and verify (and fix).
OK, my wild theory in this case, which might explain why some show up and not others:
If this bug still exists and your DMR reasons are similar to the RMA reasons then if you happen to have one you are using for DMR that is not also an RMA the tracker may not find it and might be losing the entire record. I've seen this behavior before in trackers. Check the reason codes on some of the missing transactions and you might want to also add it to RMA reasons and see if it suddenly appears. The tracker may be mixing up the type codes. A long shot but easy to try.
----end excerpts ------------------
________________________________
From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf Of Sean Toler
Sent: Thursday, August 23, 2007 8:15 AM
To: vantage@yahoogroups.com
Subject: [Vantage] Crystal DMR Report
Hello.
I have created a Crystal Report that lists all of the rejected DMR's
for a given time period (for example a week). It is currently being
used with Vantage 8.00. 99% of the time all of the nonconformances
that are created are from parts manufactured in-house. 1% of the time,
we end up failing parts that were manufactured by a vendor. We fail
them in the PO Receipts tab of the Inspection Processing Module. This
then carries the failed quantity to the DMR module to await approval or
rejection by management or our customer. I noticed yesterday, after
failing some parts in I.P. that were manufactured by one of our vendors
that the DMR associated with this record is not showing up in my
Crystal Report. All of the DMR's that are a result of parts being
scrapped in-house show up, but not the DMR's generated from failing a
PO Receipt in Inspection Processing. For the life of me, I can not
figure out why. Has anyone else come across this issue and figured out
what to do to correct it?
________________________________
The information contained in this E-mail message and any documents which may be attached are privileged and confidential, and may be protected from disclosure.
Please be aware that any use, printing, copying, disclosure or dissemination of this communication may be subject to legal restriction or sanction. If you think you have received this message in error, please reply to the sender.
For more information please visit www.harveyvogel.com
[Non-text portions of this message have been removed]