AP Automation - GL information not pulling in

Epicor ERP 10
1

Hello everyone!

My team is in the process of working through the last issues of AP Automation (ECM) where GL information for PNP invoices do not have GL information coming through from Epicor. The purchase order lines get the GL information from the Part Class where GL Codes are set up.

The non-PO invoices have no problem pulling in the GL information (they get it from the Supplier). Any ideas of things to check?

2

Not sure how the automation works, but the best way to track this is to enable logging for the “AP Invoice” GL Transaction Type.

When the invoice is created and GL accounts are supposed to be populated but failed to do so, you should be able to open PE Log Viewer and load the records related to “GL Control” and see the operations used to retrieve the GL Account to identify where it is looking.

3

Hi Jonathan,

Are you talking about tracking in Epicor when an Invoice is created?

What I’m trying to figure out is how ECM knows where to get the GL info from for to create the invoice? It knows where to get it for a non-PO invoice but not one that has a PO.

4

If my understanding of ECM is correct, and you can correct me if I’m not, the Invoice in Epicor is created from an actual physical invoice that is processed by ECM.

As far as I know ECM will use the same services as the ERP, so I don’t think ECM is the one deciding what GL account it should use, it is simply creating the invoice on Epicor’s side and Epicor is determining the GL based on the Posting Engine.

But then again, my knowledge on ECM is fairly limited.

5

@Jonathan is right - but you also need to take into consideration a lot of customization people do to that workflow.

The process can also include IDC as well - and that is another layer of where information comes from.

But yes - an ECM workflow will reach back into Epicor via the API and create Invoice Lines based on information that exists in ERP (For PO Based) and using information entered into ECM. Or neither actually. Some people just run the invoice skeleton into Epicor and edit the rest of the info inside Epicor. And some folks use an approval process in the ECM workflow and do all the editing there. And then there is 3 way matching validation, header and line misc. charges, taxes, and stuff like that.

It’s really based on how you built the workflow to interact with ERP, your AP person(s), and your users - for each type of invoice.

The API calls are not something we can see inside of, but I can tell you that it mirrors the same process of creating an AP invoice inside the UI. If the same situation works when manually creating an invoice, then the ECM process via the API should work as well.

I’m assuming it all works via the UI?

6

It works correctly in AP Invoice Entry (manually putting in the invoice) and it works using the non-PO type of invoice in ECM, just not the invoice that has a PO. That’s where I’m stuck. I didn’t build the workflows but I’m assuming it is something in there but can’t figure out what.

7

So I’m picturing these scenarios based on what you guys have said:

  1. ECM is determining the GL inside ECM itself, in this case I have no idea where you could look, I don’t even know what the UI for ECM looks like, much less how to configure it.
  2. ECM is using the Epicor REST API to get the GL info that it will use when creating the invoice, in this case you might see what calls it is doing by enabling and looking at the server logs.
  3. ECM is not deciding the GL, but Epicor is, in that scenario following the steps I mentioned before should give you more information.
8

The general outline in our ECM flow is this:

  • Index the invoice - set defaults, title, folder, etc…
  • Check for a valid PO number - Datalink is “E10_Read PO Header by PONum”
  • Check if this is a duplicate Invoice - Datalink is “E10_Validate_Invoice”
  • Create the invoice in the DS AP Group - Datalink is “E10_Create_AP_Invocie_From_PO”
  • Get Invoice Lines - Datalink is “E10_Read Receipt Lines to be Invoiced to LineItemsPO”
  • Ask the users/ap clerk if everything is OK and to edit anything that needs editing
  • Update Invoice - two Datalinks “E10_Update AP Invoice Header” and “E10_Update AP Invoice Line Items”
  • Then it reads back the PO Details with datalinks to make sure we’re working with the latest, updated, and Epicor-fixed data - uses datalinks
    • E10_Read Invoice
    • E10_Read Invoice Header GL Analysis to HeaderGLAnalysis
    • E10_Read Invoice Header Misc Charges
    • E10_Read Invoice Header Taxes
    • E10_Read Invoice Line Items to LineItemsPO
    • E10_Read Invoice Line GL Analysis to LineGLAnalysis
    • E10_Read Invoice Line Misc Charges
      (and it creates a Subgroup called LineGLAnalysis to deal with multi-line GL Analysis data))
  • The it validates GL info - it doesn’t get the GL data, it just makes sure that what it just read back from Epicor contains the GL info. It shows the user an ‘error’ if any are missing…
  • Then it allows for editing/fixing/etc. and then it finalizes the invoice with a datalink - “E10_Finalize AP Invoice”

Compare that to your flow and see if anything is missing.

9

It’s can’t really do this unless you create some sort of custom datalink that looks up information in ERP based on data in ECM (from user entry or OCR or IDC). ECM is unaware of the COA structure natively.

Absolutely - API datalinks are provided as part of the “E10 Integration” package.

And it’s doing this part - before the previous one. The workflow first tells Epicor to create an invoice - using the same stuff the UI uses, then reads it back to ECM so it can use it (But this too is optional and based on what you want the workflow to do.)

10

Our is Updating the Invoice in one step, then updating it again in the next step. I think one of these should be removed. I’m wondering if because there are two of them, one is conflicting with the other.

11

might be… All mine are ‘read’ except for Update Invoice and finalize Invoice…

I do know that if you run a datalink with fields that come back blank, it will set those metadata fields to blank. Perhaps the second iteration isn’t set up properly and is blanking those fields?

12

That’s what I’m looking at right now. I know it has to be in that step. One of those Actions is doing it. Now to figure out which one…