Receipt Entry customization advice

We sell pre-lubricated bearings. Lube expiration depends on a variety of things, but we frequently send out lots of bearings to get re-lubed to meet customer requirements. They might not all come back at once, so we’re effectively splitting the lots into smaller ones with different lube dates. Receipt Entry suggests the JobNum for the lube OSS operation as the LotNum. We’d like to automate a LotNum suggestion consisting of the JobNum plus a serialized suffix (12345-0, 12345-1, and so on). Otherwise, if we let it re-use the same LotNum, the lube date (re-labeled cure date lot attribute) just gets overwritten, and then we have to untangle the mess later on.

I’m fairly inexperienced at authoring BPMs from scratch, and I’ve just taken my first stab at tracing objects/methods to identify my logical insertion point… I’m struggling a bit. Anyone like to give me some pointers or suggestions?

Justin, have you exhausted the ability to use the built in lot numbering generation properties within Epicor Part maintenance?

I haven’t used them to this extent on my own so I can’t say for sure if they would be able to do what you are asking, I am looking now though.

Seems to be 2 different things, because we do have standard LotNum generation logic for most/all parts that embeds the month and year, etc. In the workflow I’m working with, LotNum is just copied from the JobNum we created to send the parts out for lube. I’m assuming that’s a standard feature, but not sure.

If that is the case, is there any way you can append a serial number on it as well using the built in features?

The concern I have with going directly to a BPM is that it may not be needed. Can we do this using the built in lot numbering features? I will try to figure it out on my end. If we cannot, I would imagine we would have to start storing a serial number somewhere. I think there are many posts on here about incrementing a number.

It just doesn’t look to me like the LotNum generating rules are being leveraged here…

image

vs…

<tracePacket>
  <businessObject>Erp.Proxy.BO.ReceiptImpl</businessObject>
  <methodName>UpdateMaster</methodName>
  <appServerUri>https://gccdtpilot02.epicorsaas.com/SaaS1028Pilot/</appServerUri>
  <returnType>System.Void</returnType>
  <localTime>9/13/2021 10:51:27:4477743 AM</localTime>
  <threadID>1</threadID>
  <correlationId>d790cfaf-736e-4f89-b1c5-9c8baf034b43</correlationId>
  <executionTime total="2410" roundTrip="2388" channel="0" bpm="0" bpmDataForm="1" other="21" />
  <retries>0</retries>
  <parameters>
    <parameter name="RunChkLCAmtBeforeUpdate" type="System.Boolean"><![CDATA[True]]></parameter>
    <parameter name="RunChkHdrBeforeUpdate" type="System.Boolean"><![CDATA[True]]></parameter>
    <parameter name="ipVendorNum" type="System.Int32"><![CDATA[357]]></parameter>
    <parameter name="ipPurPoint" type="System.String"><![CDATA[]]></parameter>
    <parameter name="ipPackSlip" type="System.String"><![CDATA[567567]]></parameter>
    <parameter name="ipPackLine" type="System.Int32"><![CDATA[1]]></parameter>
    <parameter name="cLCAmtMessage" type="System.String"><![CDATA[]]></parameter>
    <parameter name="opUpliftWarnMsg" type="System.String"><![CDATA[]]></parameter>
    <parameter name="opReceiptWarnMsg" type="System.String"><![CDATA[]]></parameter>
    <parameter name="opArriveWarnMsg" type="System.String"><![CDATA[]]></parameter>
    <parameter name="lRunChkDtl" type="System.Boolean"><![CDATA[True]]></parameter>
    <parameter name="qMessageStr" type="System.String"><![CDATA[]]></parameter>
    <parameter name="sMessageStr" type="System.String"><![CDATA[]]></parameter>
    <parameter name="lcMessageStr" type="System.String"><![CDATA[]]></parameter>
    <parameter name="pcMessageStr" type="System.String"><![CDATA[]]></parameter>
    <parameter name="lRunChkDtlCompliance" type="System.Boolean"><![CDATA[True]]></parameter>
    <parameter name="qDtlComplianceMsgStr" type="System.String"><![CDATA[]]></parameter>
    <parameter name="lRunCheckCompliance" type="System.Boolean"><![CDATA[False]]></parameter>
    <parameter name="lCompliant" type="System.Boolean"><![CDATA[False]]></parameter>
    <parameter name="lRunPreUpdate" type="System.Boolean"><![CDATA[True]]></parameter>
    <parameter name="lRequiresUserInput" type="System.Boolean"><![CDATA[False]]></parameter>
    <parameter name="lRunCreatePartLot" type="System.Boolean"><![CDATA[False]]></parameter>
    <parameter name="partNum" type="System.String"><![CDATA[400-0180-003]]></parameter>
    <parameter name="lotNum" type="System.String"><![CDATA[010280]]></parameter>
    <parameter name="lOkToUpdate" type="System.Boolean"><![CDATA[True]]></parameter>
    <parameter name="lUpdateWasRun" type="System.Boolean"><![CDATA[False]]></parameter>
    <parameter name="wrnLines" type="System.String"><![CDATA[]]></parameter>
    <parameter name="ds" type="Erp.BO.ReceiptDataSet">
      <ReceiptDataSet xmlns="http://www.epicor.com/Ice/300/BO/Receipt/Receipt" />
    </parameter>
  </parameters>
  <paramDataSetChanges>
    <paramDataSet name="ds" useDataSetNbr="0">
      <changedValue tableName="RcvDtl" rowState="Modified" rowNum="0" colName="ReceiptDate"><![CDATA[9/13/2021 12:00:00 AM]]></changedValue>
      <changedValue tableName="RcvDtl" rowState="Modified" rowNum="0" colName="Received"><![CDATA[True]]></changedValue>
      <changedValue tableName="RcvDtl" rowState="Modified" rowNum="0" colName="RowMod"><![CDATA[U]]></changedValue>
      <changedValue tableName="RcvDtl" rowState="Modified" rowNum="0" colName="UD_SysRevID"><![CDATA[System.Byte[]]]></changedValue>
    </paramDataSet>
  </paramDataSetChanges>
</tracePacket>

image

Justin,

It looks like you can’t do it with the native lot numbering generation settings in epicor…

I am sure there has to be someone on here doing what you would like to do.

I have ideas, but would love to hear from someone else on here first.

I think you have to click the Next Lot Num button on receipt entry to get that lot number generated as it is set in your screen shot. Try clicking the next lot num button.

That makes sense to me. I doubt that they care if the LotNums are a different format when they get created with a receipt from OSS as opposed to other methods. I suspect, however, that we want to keep the mouseclicks to a minimum to reduce errors/complexity.

That’s not to say you couldn’t customize the form or create a BPM to set the value of the lot number to the next sequence as if the user clicked the button… thus minimizing clicks…

When you click the button you will see that the sequenced lot number for that part number increments, regardless of whether you saved the receipt.

I think you could add logic in the generatelotnum method to append the job number to the generated lot number, thus accomplishing your objective.

Alternatively, could you use the built in lot attributes and have them type in the job number?

It wouldn’t give you the lot number structure you are hoping for - job num + sequenced lot number, but it would give you a sequenced lot number with an attribute = to the job number… Just a thought.

@jfajen

Use Job Number as Lot Default

Select this check box to override the default lot number, if part’s sequential lot number is set to Non Part Specific with an assigned Global Lot Sequence.

If you select this check box and a part (assembly part) entered on a job includes the following Part Maintenance setup:

  • The Non Part Specific check box is selected.
  • The Global Lot Sequence is defined.

then, the job number automatically displays in the Job Receipt to Inventory > Lot field.

Note: You define both Part Maintenance settings on the Part Maintenance > Lots > Generate sheet.

Note: If you clear the Use Job Number as a Lot Default check box, the Job Receipt to Inventory > Lot field displays a global lot sequence value linked to the job assembly part.

Note: To link a global lot sequence value to a part, use the Part Maintenance > Lots > Generate > Global Lot Sequence field

1 Like

Thanks Prash! I was wondering where that was, totally blanked on the company configuration for lot tracking.

I had a hunch this was probably a setting somewhere. However, I think we’re actually relying on our re-lube Jobs being tied to lots of bearings in this manner. I’m probably going to have to come up with a custom suffix to differentiate the new sub-lots.

So now we’re unearthing a decision made years ago, when none of us worked here, and questioning its merits… good stuff. Thanks for the guidance!

1 Like

Attached are two BPMs that you could use after reviewing/reworking them. The first takes a UD field from the part and copies it to a UD field on the job header, when released. The same BPM increments the value on the part by adding 1. The second BPM takes the UD field from the job header and uses it as the new lot number during job receipt to inventory. You could easily change the second BPM to use a different field on the job header. You want to review the first BPM to understand how to increment the same field on the job header. The part is lot-tracked but has no lot generation sequence configuration.
21438.bpm (27.2 KB)

21439.bpm (17.2 KB)

1 Like