Where is the "AR Account GL Control" set in Epicor?

So, back to the topic…

If my mystery GL really is related to the customer, what customer do I use? How is there a customer on a plant transfer (single company)?

I mean, I guess if I don’t use it, I don’t care. But I fear the day I get bit by it.

FYI, thanks to an old post from @hmwillett, I now know what the PE Log Viewer is and how to track the logic. Very cool.

So I never see the mystery account being checked, but I think if it’s not defined I won’t see it anyway.

1 Like

I should have directed you to the Posting Engine Tech Ref. It has pseudo code (an example below) showing (if you can decode it) the GLC’s and contexts used.

For the
PLT-ASM/PLT-MTL/PLT-STK: Post Extended Cost to AR Transfer and Contra AR Accounts
Executed for PLT-ASM, PLT-MTL, PLT-STK transactions. Posts Extended Cost amount to AR Transfer and Contra AR accounts. Debit and Credit accounts depend on sign of the Extended Cost amount.

Posting Rules
Modifiable items display in bold.

Select Amount From COSAndWIP--PartTran Where Name = Extended Cost AND CurrencyType = Transactional
If Transaction Amount is not Available Call = End Rule
If Transaction Amount.Value = 0 Call = End Rule
If Transaction Amount.Conversion Date is not Available COSAndWIP--Details--TranDate
Convert Transaction Amount To Book Currency Using Default Rate Type
 Comment = Comment: Determine AR and Contra AR Accounts
Get Account From COSAndWIP--PartTran--site Transfer--GL Control 
  For Current Book  AND AR (From site) Context
Get Account From COSAndWIP--PartTran--site Transfer--GL Control 
  For Current Book AND Contra AR Context
If AR Account = Contra AR Account Comment = Comment: When quiting rule before
setting up debit and credit accounts - rule does not produce GL Journal Details
  Call = End Rule

If Book Amount.Value > 0 AR Account
  Debit Context = Transfer AR (Ext Cost)
 Contra AR Account
  Credit Context = Contra AR (Ext Cost)
Else
  Invert Book Amount Sign
  Invert Transaction Amount Sign
  Contra AR Account
  Debit Context = Contra AR (Ext Cost)
AR Account
  Credit Context = Transfer AR (Ext Cost)

somehow my memory tells me the customer and customer AR come into play in situations where one site sells a product to a customer which is actually shipped by another site - and where the DLT/PLT components in your interdivisional accounting get all excited.

i haven’t been in that area of the system in a while, so i obviously need to check my math
i have some old implementation notes which may provide some better insight.
i will review and post them up asap

Al,

OK, so you’re thinking it’s a very obscure scenario that would involve the customer. Interesting.

On a tangent about another obscure scenario, I did learn by happenstance that I can make a job in site A and receive it to site B and it becomes a de facto make-to-transfer-order.

I point this out because #4, the product group, actually has two possibilities - first, the product group on the job if there is one, then, failing that, the product group on the part itself. That nugget was buried in the PE Log viewer.

image

Do you have more details on this?
We only mfg at site A, but often ship to site B to join other parts for the order. So we have to

  1. Make it at site A
  2. Receive to site A inventory (MFG-STK)
  3. Transfer shipment from site A (STK-PLT)
  4. Receive TO at site B (PLT-STK)
  5. Ship from site B (STK-CUS)

And this requires a qty bearing Part Num in plants A and B. Often this PartNum will never be used again.

Calvin,
I’ll do my best explaining this.

For my experiment, the gist is:

  • Site B has a SALES order; part IS quantity-bearing
  • Site A manufactures the part; it is NOT qty-bearing yet IS non-stock
  • Site B creates a Transfer Order
  • Site A gets no obvious demand to make it
  • Go ahead and make the thing anyway in Site A; make it TO STOCK (odd, right?); do not auto-receive
  • Job Receipt to Inventory TO THE OTHER SITE. This is like shipping it.
  • Still need to do a “Receive Transfer Order” in Site B.
  • Somehow the system magically links the job to the order needing it.

This is my stream-of-consciousness notes:

  • Part 5239A – gusset on a trailer
    • In Mfg it is non-stock and not qty-bearing
    • In PDC it is qty-bearing (and not non-stock)
    • In PDC part type is Transfer (from Mfg)
    • In Mfg, type is Manufactured
  • Sales order in PDC site to a customer for 20 pcs.
    • 3 on-hand in PDC; none in Mfg (obviously)
    • Therefore need is 17 from Mfg
    • Note: Initially the (only) release on the line was set to pull from Mfg, even though I was logged into PDC. This also flagged the order as make direct (as it’s non-stock in Mfg!) To avoid all this, define a product group and its selling site, then pick that group for the line before saving the line.
  • Ran MRP for 5239A only
    • Got a transfer order suggestion in PDC . Had to think about that. It’s a suggestion for PDC to order 17 pcs. from Mfg. But it’s still at the PDC’s discretion to order it from Mfg—MRP is not demanding this transfer
    • The suggestion does show on the Mfg side as well. But there is not yet anything there on how to fulfill the suggestion. (See Time Phase pic below.)
    • Firmed the suggestion in PDC. Ran MRP again (all sites, but only this part). Still no suggestions in Mfg on how to fulfill this demand.
    • Made a job to stock for these (yes it let me)
    • Job adj (or time entry) for 17 pcs.
      • DO NOT AUTO-RECEIVE!
    • Job receipt to inventory to the other site!
      • Creates a MFG-PLT transaction in Mfg site
      • Eliminates the transfer order suggestion in Mfg site
      • But no PLT-STK in PDC site until…
    • Receive Transfer Order in PDC site for the 17 pcs. against the same order?!
      • Yeah, that worked! No idea how.
      • Turns out I can do this without an order, too
      • And the original transfer order receipt in Time Phase is gone. So it’s as if I shipped the transfer order from the job (WIP) even though I did absolutely nothing to link them together.
      • Apparently if you date the receipt, you can save there (without “receive all”). But you still can’t change the quantity. Or delete a receipt.

But it sounds like you are thinking of a part-on-the-fly on the sales order.

If you are wanting like MFG-PLT and PLT-CUS, I’d say you are out of luck there, since the only PLT-x transacions are PLT-ASM, PLT-MTL, and PLT-STK.

So even though the part could never be received to Stock (because non-Qty Bearing), it lets you make a Demand to stock on the job?

And that whole part about using a Job Receipt in site B (for a job in site A) AND the receive TO, is mind boggling. I’d have thought that the Job Receipt and the TO receipt would both increase the QOH at B.

And I thought you had to specify a TO Packnum in order to receive it? How you doing that when one was never created from site A?

What I’d like is a MGF-STK, with Plant=A, Plant2=B

Ideally, we’d have a MFG-CUS, with Plant=A, Plant2=B. I.E.- built in A, shipped from B

Correction

Ideally, we’d have a MFG-MFG, with Plant=A, Plant2=B. then do a MFG-CUS
I.E.- built in A, transferred to from Plant A WIP to Plant B WIP, then shipped from B’s WIP.

This is the classic “This doesn’t make any sense, but I’ll try it anyway because I want this to work.” Et voila.

The job receipt (which is really the shipment) appears to have created transfer pack #7 and tied it to TO # PDC-MFG-000004 *

And then I must have received against pack 7. (This was a month ago, so I’m a little fuzzy.)

Again, it’s best to think of the job receipt as a transfer shipment. That’s why quantities do not double.

As to your idea, the only thing I could see is two jobs, one in each plant. I.e. MFG-PLT, then PLT-MTL, and then MFG-CUS, and the second job has one line of material, itself again. Sounds like a lot of work, though.

*(EDIT) FYI, I regret the transfer order prefixes I chose. They wound up being the opposite of what I expected.

When you create the Job Demand as “To Stock”, do you have to specify the site?

What Trans do the “Job Recpt to Inv” create?
The normal flow (with the GL’s hit) would be:

Business Process            TranType   GL Debited   GL Credited
Issue Mtl to Job At Site A  STK-MTL    WIP-A        INV-A
Receive Job to Stock A      MFG-STK    FG-A         WIP-A
TO Shipment from A to B     STK-PLT    In-Tran      FG-A
TO Receipt at B             PLT-STK    FG-B         In-Tran
Shipment to Cust from B     STK-CUS    AR Accrual   FG-B

Does your method combine some of those? Since your part isn’t QtyBearing at A, it can’t have any ‘STK’ tran types (for plant A).

So MFG-STK combines with STK-PLT, for a single MFG-PLT transaction? Which also automatically creates a TO shipment (and magically matches up with the prior Transfer Order)?

Well, we are getting close to the end of my accounting knowledge. I ran this experiment again, since the original was on a busy day, transactionally.

Here is the inv-wip report, with no interdivisional accounting, for simplicity. (I didn’t ship to customer yet.)

I may not have all the accounts flexed properly on the PDC side (site B), so this is probably confusing.

And I did not specify the correct site on the job; I just received it where I wanted it.

1 Like

And yes to all of that. Just verified it again with this experiment.

EDIT - FYI, the reference “4 parts to PDC” was my comment on the job receipt to “inventory,” so it carries through all of those transactions, apparently, even though the transfer receipt was a separate transaction that I manually did.

1 Like

That’s interesting.
I wouldn’t expect the system to allow creation/receipt of orders for a non-qty bearing part; nonetheless, complete a receipt automatically. but if it is happening the accounting must be there.

I’ve checked all my previous notes and most always they refer to multiCOMPANY setups.
So they’re not much help. im going to try to reproduce this in a test
:thinking:

Al,

Just to be clear, the original question in the post was a generic one - not necessarily related to the magic transfer I was talking about.

Also, I was on the phone with Support this morning about this. It took forever to get him on the same page that you all jumped on immediately. But anyway, after 35 minutes, he had no useful answer except to promise to forward my ticket to someone else on his team.

He says, well I guess it doesn’t matter. I said, then change the manual. And this went in a circle a few times.

No sweat. I don’t expect a quick turnaround.
It’s an interesting item; I would like us all understand it accurately.

1 Like

From Epicor Support last night:

Development confirm that 4a) Sales Account from AR Account GL control in the hierarchies is incorrect and should be removed
I will notify the documentation team to update the hierarchies

“Sorry for all your troubles” would be asking too much, I guess.

1 Like