Upgrade - Import GL Transactions Required?

When upgrading or creating a new Epicor environment, is it mandatory to import the GL Transactions?

What is this actually doing?

Is best practice to select each transaction type, and go one at a time? Or check ‘import all’ and let it rip?

For what it’s worth, we usually upgrade annually, and this time are going from 2023.2 to 2024.2…

The 2024.2 Kinetic Upgrade Release Guide, Kinetic 2024.2.7 Update Guide, and 2024.2 Kinetic On-Premise Installation Guide didn’t get into it (or I missed it!)

I’ve inherited creating the server-side of things recently, and trying to get up to speed on the upgrade process. We have this listed as a step in our internal upgrade guide, but I’m not clear on why.

Related to this?

This side of Epicor is new to me - lots to learn. Thanks for the advice!

From our internal upgrade notes:
image

1 Like

Hello, Sometimes when upgrading, the gl transactions type are automatically upgraded, but sometime it doenst (not sure why). But, If you dont have customized posting rules, you can use the import all option or run the conversion to import the gl transaction types.

1 Like

Thanks, Dora! We do have a customized posting rule. It was to add detail back to AP Invoice (taken away on 10.2.600), based on KB0099806.

If I do ‘Import All’, will this be overwritten, and I’ll need to re-create it?

Odd that the upgrade guide doesn’t cover this in detail.

My understanding is it’s mandatory and will be upgraded on the way through. IF you have custom gl transaction types/posting rules and the code is in the custom tab then they should survive if there have been any vbd version changes, I suspect therewod not be.

The best way to check is to do a comparison between your old demo environment and the new, or even better do the comparison between your Test upgrade and Live.

Here’s a BAQ that might help.
GLTransTypeRevisions.baq (8.4 KB)

Another thing on uppdgrading the Upgrade Analyser is a useful tool to helpp you along the way. So if your not using it, then I suggest you do.

2 Likes

For the “Book” error above look at your book conversions

Financial management > General Ledger > Setup
Book
Go to the Posting/conversions tab
Update your target segment from unknown to what you have in your chart of accounts setup.

image

Some progress and more questions.

I just created a 2024.2.8 Upgrade environment (from a 2023.2.x LIVE snapshot). Every year, the AP Invoice GL Transaction Type comes in blocked, and errors the 540 conversion (probably since it’s a very small change that makes it a custom posting ruler per KB0099806).

Why? If I look in Book Maintenance, the default package is set to Extended, so segments are not set, so they couldn’t be missing. Yet GL Trans Type for AP Invoice (grid view) shows Standard, but not any place to set the segments.

We re-import the AP Invoice rule to replace the blocked one, and make it the active revision. This fixes the issue (the 540 conversion then does not error if I re-run it). I’d like to fix this so our upgrades go smoothly and don’t require imports every time.

We did change the posting rule based on KB0099806 last year. It seems like Epicor kept the change during the upgrade.

I’m still at a loss what Importing the posting rules does, why it’s needed, when I don’t do any other changes afterward to make it work.

Thanks for helping clarify this mystery!

EpiCare response:

Thank you for bringing this to our attention. We want to assure you that we are fully aware of the issue and that our Development Department is actively working on a solution to address it.

This particular issue is commonly related to the AP Invoices Posting Rule, and we’ve observed similar cases with a few other customers following recent upgrades. Rest assured, this is being treated with priority, and we are committed to resolving it promptly.

As part of the resolution process, one effective solution has been re-importing the posting rule, which has worked successfully for other customers facing the same issue.

image

KB0099806
image

You are probably going to find the answer in the Posting Engine Tech references,

I suspect that there is some customisation that the conversion is overwriting and using the standard rule, then it breaks because you are not using the standard segments.

The guide mentions this in the examples:

"Impact on Posting Codes:

  • If the conversion application finds a custom user-defined posting code in the VBD structure, it leaves it as is unless it has the same name as a new standard posting code that is present in the imported XML and needs to be added to the VBD structure of the installed transaction type. In this case, the conversion application marks the custom posting code as Standard, and it is used as standard from this point on."

Might find it useful to put the guide into notebook LM to help you summarize it…

1 Like