Hey all, I have an interesting issue that I was hoping to get some help with. Refer to my image below:
Has anyone been able to do this? It seems when material is issued, the PONumber gets lost and changed to “0” in the Part Trans. History (which is originally where this form tries to pull from “PartTran”).
Id really appreciate any input! Thanks!
Did you check the RDD to make sure those fields aren’t excluded?
If they are, you’ll need to duplicate the RDD, un-exclude those fields, update the Report Style for the new RDD, and update the RDL to include those fields in the query expression.
Hey Calvin, Thanks for the reply.
Yeah I have made sure they weren’t excluded and everything like that, as well as making sure they are in the query expression. It’s almost like somewhere along the line the part doesn’t link up with the receiving info when issued.
My knowledge outside of editing these forms/data definitions is unfortunately kinda slim
Yeah, I just checked and the Epicor supplied RDD and RDL do include the fields.
If you preview the label using the Epicore supplied Report Style, does the PO info show as above?
And just looked at the base RDL, and there is a field that displays a combination of PO Num, Line and Release. It’s expression is
=iif(Fields!PONum.Value <> 0,CStr(Fields!PONum.Value) + " / " + CStr(Fields!POLine.Value) + " / " + CStr(Fields!PORelNum.Value),chr(160))
Your expression anything like that?
Well here’s the issue, on the default report style, it would just pull “0” for our PO number. It looks like when we are issuing material, the PO number gets lost and just gets set at 0…?
Refer to my image, it seems very odd.
When (and from where) are you printing the labels?
This normally happens in the Receipt Entry. And those transactions would be
STK-MTL transaction should ever have a value other than 0 in the PO field.
We print the issue material label when issuing material. Sorry I didn’t mean to mix up Receipt entry and Issue Material.
I mentioned Receipt Entry earlier because we wanted to pull the PO number and Entry date from there, BECAUSE we were having this issue of the PO coming up as “0”, if that makes sense.
My fault actually. I thought it was the Receipt label when I saw your fields for RcvDtl.
Just curious, If QOH was from multiple PO’s, how would you know the qty’s for the particular PO’s?
The lot number is what identifies our quantity on hand. The lot number gets generated for that material when we receive in our PO (Receipt Entry).
Does the PUR-STK parttran record show the Lot number?
If it does, than you can get the PO num from the PartTran record for the receipt of the Part & Lot you’re issuing.
Alright, how would we go about that? It does show when doing PUR-STK
We don’t use lot control, so I can’t really test it.
The RDD for the Inv Movement Report already has the parttran table in it so it it can’t be done like I was thinking.
You might need to add a UD column to the table that holds the lot info, and add the PO num to that when it is received. Then use that value in the Inv Movement Report’s RDD & RDL
Haven’t had to win this specific requirement myself, but in this situation my gut tells me to go write a BAQ just to confirm the tables, columns, and maybe most importantly the robustness or validity of the data that is involved. Then take that as input into the whole RDD, Report Style, and RDL design process.
@keatonskills This is how I handle this. I add the PO, Vendor ID and Packslip to PartLot in the description and in UD fields. Make is very easy for anyone to know where the material came from especially when doing a DMR and I don’t have to read PartTran. It looks like from your label you already have the PartLot table in the RDD. If you decide to go this route I have queries to build DMT files for backfilling data on PartLot as I just added expiration date to this process last month.
Sorry for the late reply everyone, THIS is what we are doing as well! @Michael_Ramsey @ckrusen
Basically when something is Received in Receipt Entry, a window will pop up with 4 UD fields asking for Heat, Exp Date, PO and PO Date,(We set these as tracked in Part Maintenance > Lots > Attributes) which gets populated in PartLot, which the label ends up pulling from. So it ends up working!
Is this similar to what you do Greg?
@keatonskills Same basic process. We don’t use the formal quality attributes popup, I added UDs to the receiving screen that are saved in RcvDtl and then update PartLot if the part is lot tracked.