I’ve created a customization to handle our unusual method of receiving some raw materials into inventory. The process begins by capturing all pertinent info into a UD table.
My customization (on ButtonClick) loads all that data into a packing slip against a previously selected PO. In cases where a UOM conversion is required, it is calculated in the customization and inserted into each new record - while setting the field “ConvOverride” to true.
I simply loop through the UD table (incoming inventory) and execute an oTrans.GetNewReceiptRcvDtl(), which provides me with a new record - then I copy everything from my UD record to the new detail record and it works great.
My issue is that I often have to override the UOM conversion factor when specifying quantities. We stock material in lbs but purchase in square yards for some items.
We have a formula for this so getting to the correct number is not a problem. The fact that Epicor wants me to confirm that its okay to use my number (instead of the UOMClass derived conversion) for each record, this is a painful half hour of pressing “Y” - there can be lots of records.
Can anyone fathom a way to suppress this confirmation message? Receipt Entry allows us to “Arrive” the material before “Receiving” it, so there’s plenty opportunity to verify the info before moving it into inventory.
Hmmm. I have to confess to be totally unfamiliar with Mass Receipt. I did not know such a creature existed. Perhaps I will review that before going further on this.
Regarding your second question, as material is “received” into our home-grown app (using an Epicor UD table), the appropriate Supplier quantity is calculated using a formula. That value is stored in the UD record.
So, when I create a new receipt record, I first check the box “Override”, insert the “Our Qty” value, along with the UOM of LBS, then I insert the “Supplier Qty” along with the UOM of Y2. I copy in all the other field info followed by an Update().
The update triggers the confirmation request which simply says that Epicor calculated ‘this’ value, but I’ve specified ‘that’ value. Is this okay.
I wouldve figured that, by having checked the Override box, Epicor would know that I mean to do what I’m doing. That’s why the checkbox is there.
The PO can be entered in either “Our Qty” (in the Inventoried UOM), or the “Supplier Qty” (in the Purch UOM). During receipt it assumes the UOM and Qty from the PO line. If your Suppliers pack slips use their UOMs, the qtys expressed will be in that UOM, and you should enter PO’s in the Supplier UOM.
I hear you Calvin, and that makes perfect sense. However, we need to specify both the Our Qty and the Supplier Qty. We cannot let Epicor figure it out as there are complex variables built into the conversion. The parts that fall into this scenario are all specified as Part Specific on the UOM conversions - even though we don’t want Epicor to do the conversions.
By entering both numbers (Our and Supplier), we end up with a properly costed material and PO that matches exactly what we are invoiced - based on those factors I mentioned.
So, the bottom line is that we have to, and we have for the last several years, entered both numbers. I’m just getting tired of pressing Yes all the time.
Now if this mass receipt thingy can accommodate this oddity, perhaps I can programmatically build that mass receipt (batch?) and receive that way? Is that sort of how it works ( I do plan to read up on it tonight).
Hey Calvin, thanks for that info. Unfortunately this is a routine procedure performed by a user at the Receipt Entry screen. I, as the system admin, use the DMT for specific table loading tasks and wouldn’t want to build that utility into daily processing for a user - Hence the customization of Receipt Entry.
Regarding the override field, it exists in record created by oTrans.GetNewReceiptRcvDtl().
// TEST: If the PO is square yds but the weighed lot is linear yds, perform the conversion
if (((string)loadRow[“ShortChar05”] == “LYD”) && ((string)PO_UOM == “Y2”))
{
arrivedRow[“ConvOverRide”] = true;
arrivedRow[“VendorQty”] = Math.Round(calcY2, 2 );
arrivedRow[“PUM”] = PO_UOM;
}
arrivedRow.EndEdit();
So… Just like in the DMT, I am telling Epicor that I intend to override the conversion. But the Update method kicks off that confirmation message for each new record.
Give the Mass Receipt functionality a look at. Like most things in E10, it’s not initially intuitive. So here’s a quick primer:
Launch Receipt Entry and enter the PO, and pack slip as you normally would.
Choose Mass Receipt from the Actions menu
a. The open lines for the PO are shown in the upper pane
Click “Select All”. This moves all the open lines from the upper pain to the lower pane
Click “Get All”.
a. This sets the Rcpt Qty’s (both Our Qty and Supplier Qty) to what was on the PO.
b. It also marks the line as Received complete. This is kind of misleading, as it refers to the PO and not actually being received.
Click “Receive All”. THIS IS VERY IMPORTANT, otherwise the parts appear as “Arrived”, which is different than “Received”. “Arrived” Parts don’t show in inventory until they go through inspection, or are received.
Ensure that the Bin To receive to is entered.
Click “Process”, then “Close”
All the open lines from the PO should now appear as Receipt Lines.
You can now go through each line and make adjustments as necessary.
Note: You could have made adj’s to qtys received, in the Mass Receipt window, after doing step 4 above. If you enter a supplier Qty, the “Our Qty” doesn’t change in the Mass Receipts window, but after you hit “Process”, the receipt line created will show the correct “Our Qty” based on the Supplier Qty and UOM conversion.
Interesting. This may be an option - I didn’t get to read up on it as of yet, but I will
A challenge is that we purchase “a line”, but we receive many lots of that 1 line.
For example, we may order 50,000 lbs of Part A (PO line 1) which will arrive as a bunch of individual lots - each of which has to be “received” into inventory - individually as a lot. Each lot can have varying characteristics, so the differentiation is important.
So when I talk about PO lines, there may be a single line (or more), but there may be 200 individual lots to receive against those lines.
So using the Mass Receipt, as you say, our 50K Lbs and the Supplier Y2 would be populated, but I would still have to override the supplier quantity with our calculation (which matches the supplier’s calculation).
The system MAY still need to respond to the confirmation warning, but I won’t know until I try it. So I will.
Just did a quick test, and during Mass Receipt, it assumes that the entire rcv’d Qty is of the same lot. It also requires you to enter the lot before you can process it
If you enter a qty less than the ordered qty (and specify the Lot), that qty is assigned that lot. The remaining qty is still open, so repeating the mass receipt would allow you to do this over and over. Which doesn’t seem practical. E10 would be better if when you received a portion of the ordered Qty, the upper PO line would reappear in the upper pane.
Anyway… Do you have any advance notice of what the Lot numbers and their respective qty’s are, prior to the arrival?
If you bought flour, and they always came in 1,000 LB sacks, and each sack has a lot number (even if not unique), I’d have PO entry create a separate release for each “container” (1,000 LB sack in this case). If you ordered 5,000 LBS, the PO would have 5 releases.
Then when you do Receipt Entry, you’d have 5 lines to assign lot numbers to. You can even “mix up” the qty’s, if they are not always exact amounts. Like:
You might have uncovered a possibility here, Calvin. I do have all the details ahead of time - our scale and ticketing/labeling system creates the lot numbers that are uploaded to Epicor as part of the receipt process).
It may be possible to pre-populate the PO, as you’ve done, then receive against the preloaded data.
I’m going to experiment with this for a bit Calvin. Stay tuned - I don’t know if I’ll have much time today, but I will definitely have some feedback after a few attempts. Thanks a lot for your assistance.
