Part on the Fly default GL acct ignores PartClass GL

Epicor ERP 10
,
1

When I create a PO Line for a “part on the fly” item and assign a Part Class to that part, Epicor ignores the GL Account set on the Part Class and proceeds to suggest the default Suspense account GL.

Users can manually change the suggested account on PO line/rel entry, but that is inefficient if the default on the Part Class is the correct GL Account in the first place.

Is this standard, or is this a bug in my version-10.1.500.45? It seems to me that the transaction would use the Part ClassID’s GL setting, whether the Part is on the fly or not…

Thanks!

2

Are you setting the part class prior to saving the PO line? (prior to the release being created)

If not, clicking the “get default” on the release should set the GL to the account specified by the part class.

1 Like
3

That’s exactly what I thought it should do. When I click “get default“, nothing happens. I am not sure if it is because it is a part on the fly or because I am creating a PO to “Other”. So it must be something with My version…

4

As per posting rule, it should pick from Part Class GL Control. Please check whether GL account is valid.

image
image874×445 125 KB

2 Likes
5

The Part Class I selected does have a GL account set for Inventory. What would make it not valid?

6

There’s a generic Expense account context in the “Inventory and COS” GLC Type, which should be applied in Company Config.

This is what would be used for a Pur for Other - assuming no other GLC applies.

Note that GL field on the PO Release sheet doesn’t automatically display a value. When it’s blank, the release will use the GLC derived acct. The Get Default button is really used to restore using the default, after manually entering some other account.

Just curious, can you manually select the acct specified on the Part Class GLC?

7

I can manually select accounts, which we are doing now. The vendors do not have GL’s set up, so it couldn’t be that either.

8

Running PO Entry at Base didn’t reveal any BPM’s out there.

9

This is even bigger: it turns out that none of the Part Classes drop their default Inv GL account in. Most Part Classes result in a greyed out GL section under the PO Rel sheet. You can’t set the GGL at all. Our buyers have just lived with this, and never questioned it. Yikes.

10

Auto filling in the GL Acct on the Release tab must be new (I don’t recall that happening in 10.1.400).

What you might be seeing is that the GL Acct fields become Read Only when the Part Class is changed on the PO Line, and the PO not yet saved.

In 10.2.300, I see the GL Acct field on the Release sheet is updated when I save the changed line.

11

Thanks Calvin.
-While digging deeper I see that the main company has GL settings in place. I look in the sites and only two entries in each site: Division and Tax. I wonder if for each site the Inventory COS and WIP GL settings and others need to be specified? Is that how you are set up?

12

You can use below BPM in Post-Processing of adding new PO line to populate the GL account.

var ttPODetailRow = (from ttPODetail_Row in ttPODetail
where string.Compare(ttPODetail_Row.Company, Session.CompanyID, true) == 0 orderby ttPODetail_Row.POLine descending
select ttPODetail_Row).FirstOrDefault();
if (ttPODetailRow != null)
{
var bo = Ice.Assemblies.ServiceRenderer.GetService<Erp.Contracts.POSvcContract>(this.Db);
if (bo == null)
{
throw new Ice.Common.EpicorServerException(“Can’t resolve instance of ‘Erp.PO’ service.”);
}

  using (bo)
  {
        System.Int32 arg01 = (ttPODetailRow.PONUM);
        System.Int32 arg02 = (ttPODetailRow.POLine);
        System.Int32 arg03 = 1;
        var dsTempVariable = this.ds;
         bo.GetDefaultGLAccount(
                arg01,
                arg02,
                arg03,
                ref dsTempVariable);
             bo.Update(ref dsTempVariable);
    
            this.dsHolder.Attach(dsTempVariable);
       
}

}

13

Thanks Arul; I might have to go that route if I can’t get the Part Class GL to default in. That is my plan B.

14

We have the following GLC’s:

Under Company Config:

image

Under Site Maintenance (we’re multi-site):

image

Nothing under any of the sites in Site Config

We have 13 GLC’s of type Part Class. The only one we use for parts in the Part table is for finished goods. All the others are for use on PO’s

image

15

This is by design. The system won’t know the G/L account until the WIP/Recon report/capture runs the posting rules. Epicor is a multi-book system so one account number on the PORel doesn’t make sense because it could be as many account numbers to use as there are books in the system. The only exception would be Misc/Expense POs. Here you should be able to set the account number while the PO is not approved and no other activity like receipts have occurred.

Are you using Misc/Expense POs or Inventory/Job Matl/Subcontract?

16

FWIW - Here’s the a trace (changes only) what happens when I change a PO line (of type Pur to Other) from having no Part Class, to one with a GLC. And then saving that PO.

Trace Details 
<tracePacket> <!-- just getting list of part classes-->
  <businessObject>Ice.Proxy.Lib.BOReaderImpl</businessObject>
  <methodName>GetList</methodName>
  <appServerUri>net.tcp://usdcaaps00371/UAT_102300/</appServerUri>
  <returnType>System.Data.DataSet</returnType>
  <localTime>9/9/2020 09:51:31:2303012 AM</localTime>
  <threadID>1</threadID>
  <executionTime total="31" roundTrip="30" channel="0" bpm="0" other="1" />
  <retries>0</retries>
  <parameters>
    <parameter name="serviceNamespace" type="System.String"><![CDATA[Erp:BO:PartClass]]></parameter>
    <parameter name="whereClause" type="System.String"><![CDATA[]]></parameter>
    <parameter name="columnList" type="System.String"><![CDATA[ClassID,Description]]></parameter>
  </parameters>
</tracePacket>

<tracePacket> <!-- after selecting a different Part Class -->
  <businessObject>Erp.Proxy.BO.POImpl</businessObject>
  <methodName>ChangeDetailPartClass</methodName>
  <appServerUri>net.tcp://usdcaaps00371/UAT_102300/</appServerUri>
  <returnType>System.Void</returnType>
  <localTime>9/9/2020 09:51:34:2479527 AM</localTime>
  <threadID>1</threadID>
  <executionTime total="80" roundTrip="37" channel="0" bpm="0" other="43" />
  <retries>0</retries>
  <parameters>
    <parameter name="NewClassID" type="System.String"><![CDATA[6160]]></parameter>
    <parameter name="ds" type="Erp.BO.PODataSet">
      <PODataSet xmlns="http://www.epicor.com/Ice/300/BO/PO/PO" />
    </parameter>
  </parameters>
  <paramDataSetChanges>
    <paramDataSet name="ds" useDataSetNbr="0">
      <changedValue tableName="PODetail" rowState="Modified" rowNum="0" colName="RowMod"><![CDATA[U]]></changedValue>
    </paramDataSet>
  </paramDataSetChanges>
</tracePacket>

<tracePacket> <!-- I guess this is some basic checks that saving a PO performs first -->
  <businessObject>Erp.Proxy.BO.POImpl</businessObject>
  <methodName>CheckBeforeUpdate</methodName>
  <appServerUri>net.tcp://usdcaaps00371/UAT_102300/</appServerUri>
  <returnType>System.Void</returnType>
  <localTime>9/9/2020 09:51:37:6073940 AM</localTime>
  <threadID>1</threadID>
  <executionTime total="53" roundTrip="34" channel="0" bpm="0" other="19" />
  <retries>0</retries>
  <parameters>
    <parameter name="cOrderChangedMsgText" type="System.String"><![CDATA[]]></parameter>
    <parameter name="taxableChangedMsgText" type="System.String"><![CDATA[]]></parameter>
    <parameter name="vendorChangedMsgText" type="System.String"><![CDATA[]]></parameter>
    <parameter name="viewName" type="System.String"><![CDATA[PODetail]]></parameter>
    <parameter name="ds" type="Erp.BO.PODataSet">
      <PODataSet xmlns="http://www.epicor.com/Ice/300/BO/PO/PO" />
    </parameter>
  </parameters>
  <paramDataSetChanges>
    <paramDataSet name="ds" useDataSetNbr="0">
      <changedValue tableName="PODetail" rowState="Modified" rowNum="0" colName="ClassID"><![CDATA[6160]]></changedValue>
      <changedValue tableName="PODetail" rowState="Modified" rowNum="0" colName="ClassDescription"><![CDATA[Building Maint. Exp (6160)]]></changedValue>
      <changedValue tableName="PODetail" rowState="Modified" rowNum="0" colName="RowMod"><![CDATA[U]]></changedValue>
    </paramDataSet>
  </paramDataSetChanges>
</tracePacket>

<tracePacket>  <!-- the actual update.  Note  ClassID and ClassDesc are the items changing -->
  <businessObject>Erp.Proxy.BO.POImpl</businessObject>
  <methodName>Update</methodName>
  <appServerUri>net.tcp://usdcaaps00371/UAT_102300/</appServerUri>
  <returnType>System.Void</returnType>
  <localTime>9/9/2020 09:51:37:6698978 AM</localTime>
  <threadID>1</threadID>
  <executionTime total="288" roundTrip="263" channel="0" bpm="0" other="25" />
  <retries>0</retries>
  <parameters>
    <parameter name="ds" type="Erp.BO.PODataSet">
      <PODataSet xmlns="http://www.epicor.com/Ice/300/BO/PO/PO" />
    </parameter>
  </parameters>
  <paramDataSetChanges>
    <paramDataSet name="ds" useDataSetNbr="0">
      <changedValue tableName="PODetail" rowState="Modified" rowNum="0" colName="ClassID"><![CDATA[6160]]></changedValue>
      <changedValue tableName="PODetail" rowState="Modified" rowNum="0" colName="ClassDescription"><![CDATA[Building Maint. Exp (6160)]]></changedValue>
      <changedValue tableName="PODetail" rowState="Modified" rowNum="0" colName="RowMod"><![CDATA[U]]></changedValue>
    </paramDataSet>
  </paramDataSetChanges>
</tracePacket>

Just for testing, show a message in an in-tran DD on table TranGLC, when RelatedToFile = PORel and Key1 = the PONum your using to test.

17

Not entirely true. The TranGLC table holds the GL account to be used for the transaction. At least for PO Receipts. The TranGLC entry is created when the PO Rel is saved.

  1. I made a PO with an OTF Part using a Part Class that specifies Acct 6160-00-01 for Inv/Exp. This created the Tran GLC entry:
    image

  2. Did a PO Receipt for the above

  3. Ran Inv/WIP Recon, and see:

    image
    image884×256 37.8 KB

  4. Changed the GLC for that Part Class to use Acct 6130-00-01

  5. Re-ran Inv/WIP Recon. Still shows original Acct

    image
    image884×256 40.1 KB

  6. Looking at the PO Release and the original GL Acct (6160-00-01) is still shown.

So the Post Engine isn’t recalculating the Acct to use.

1 Like
18

How would Epicor post to a different account in a another Book? Would it create a second, third, etc. TranGLC record at receipt? :thinking:

Even with the Receipt, wouldn’t Epicor need to do a “mini-posting rule” run to get the account number?

It’s doesn’t seem safe to set the account number on the PORel except for Other/Misc/Expense POs. It’s as a bad as people abusing the Write-Off command. :face_vomiting:

19

I assume this is what happens when the Release is saved, updating TranGLC.

The PartTran table no longer holds the GL Accts that the transaction uses. So the Posting engine must read the TranGLC table as part of its processing.

edit

Also, I don’t think the GLAcct is stored with the PORelease. It’s only on TranGLC. The only field related to the GL Acct is the bit field PORel.ExpOverride. Which is only set when a GL acct is manually entered.

1 Like
20

We use all three types of PO. The Misc PO allows me to set the GL, but it doesn’t use the Part CLassID default GL as its initial suggestion. (Which is what I want)