G/L By Territory Change

New in 2025.1, we have added a new option for G/L Mapping by Territory. This should only be set up in conjunction with assistance from Naviga Personnel. The System Parameter settings described below are not something you will want to be fussing with on a live system, because it can affect G/L mapping on running orders.

G/L Override by Territory

In Product Setup, recall that in previous versions there was a G/L Override by G/L Type or by Industry Code. Now, the G/L Code can be overwritten based on who sold the order (Territory). So the exact same order, can potentially get applied to a different Revenue G/L if it was sold by a different Rep.

Click Add an override in the Territory Code Section and a popup will appear allowing for selection of territories:

By setting this up on the product, the full G/L string is defined on the product - just like with G/L Type and Industry Code. There is also now an option, instead of defining a full G/L code on the Product, a particular segment can be swapped out from the default G/L can be used.

To use this option, see System Parameter Setup for G/L Override Rules.

G/L Override Settings

Item #10 in Invoice settings is G/L Override Settings. (To get here Navigate to Setup -> Admin -> System Parameters)

Previously this section was just a flag. It asked if we were first looking at the G/L Type to get a match, and if no match was found, it would look at the Industry Codes first, and then the Product Default.

If the above was answered No, then it would look at industry code first, followed by G/L Type, followed by default Product G/L.

With the addition of the Territory option, a simple flag was not sufficient. This is the new setting for #10:

Upon Upgrading, a conversion will run and set the following:

• If you are using G/L Type overrides on any product, the first will be set to “yes” (this will likely be yes for everyone)

• If you are using Industry Code Overrides on any of your products, industry code will be “yes”

• The Sales Territory will be set to no because that is new, so nobody is using it yet.

The priority column will be set based on what the old System Parameter flag used to be. If the flag was set to “YES” then G/L type will get priority 1 and Industry code will be priority 2 (if it is in use). If it was set to “NO” then the priorities will be reversed and G/L Type will get a priority 2.

IF the setting at the top of the page for Revenue Recognition are set to use settings on the Product, then this section becomes relevant to determine which product related setting to use.

Here is a more detailed explanation of the new G/L Settings:

• Field Column - There are three options for how to determine the G/L to use for Revenue:

  • G/L Type - if the G/L is determined by WHAT IS BEING SOLD - then the G/L Type is used

  • Industry Code - If the G/L is determined by WHO WE ARE SELLING TO - then the Industry Code is used

  • Sales Territory - if the G/L is determined by WHO IS DOING THE SELLING - then the Sales Territory is used.

• Use Product Rules - If we are looking to the product to retrieve the entire override G/L String, then Use Product Rules for that Override type should be set to "Yes" - for example in the screenshot above, the G/L Type is in use on the product, so use product rules is set to yes. The Priority is set to 1, which means that the system will look at the G/L Type Override on the product first before looking at any of the other overrides.

• Revenue Code Segment to Change - This is a new concept for us starting in 2025.1. In some cases is it a lot of maintenance to be adding full G/L strings to product setup when most of the G/L is the same, but just one segment differs among the different overrides. If this is used, indicate which of the segments is to be replaced with a different code. (Important note - this G/L must still exist as a full string in G/L Maintenance - but this alleviates the burden of setting it up again and again on the various products.)

  • Suppose for example, the Default G/L Code on the product is 01*02*2000*50*3640 and the "2000" code represents the G/L Type. If Classified is 3000, Retail is 2000 and Preprints are 4000 - and the rest is the same, then the system can look to G/L Type Setup to pull in these replacement codes. To do this, the user would set "use product rules" to NO and enter a "3" in the segment to change since in this example 2000 is the 3rd segment in the G/L String.

  • Then on the G/L Types, when there is a segment number in this field, that segment number will be turned into a dropdown of the codes available in that segment:

  • If there isn't a number in the Revenue code Segment to change column, then the column above will not be displayed. If there is a number in the Revenue Code Segment to Change column, but the user forgot to uncheck the box to Use Product Rules, then there will be a column there, but it will be blank.

  • Exception to the dropdown rule is if the segment that you are replacing is the last segment in the G/L String. The last segment is not stored in the database separately from the entire G/L String, so if the last segment is what is getting replaced there will be a blank and the user will need to type in the segment code.

  • I mentioned it before but it is IMPORTANT so I will say it again - the full G/L Code string must still exist in G/L Maintenance. So, back to the original example where the default G/L is 01*02*2000*50*3640. We will also expect to find 01*02*1000*50*3640, 01*02*3000*50*3640, and 01*02*4000*50*3640 in G/L maintenance.

• Priority - This is important to set up because there might be multiple possible matches. This tells the system where to look first. For example, if I have the above set up:

  • Then the system will first look at the G/L Type Override on the Product. If it finds a G/L String there for the G/L Type on the product, then it will look no further and will use that full string (b/c I have Use Product set to Yes)

  • If there is no match between the G/L Type on the order and the G/L Type Override defined on the product, it will go next to Priority 2. Which in this example is Industry Code. If the Industry Code belonging to the customer is set up with a segment override for Segment #4, then the system will take the default G/L on the product, and will replace segment #4 with that segment.

  • If there is no segment set up on the customer's Industry Code, then the system will look to Priority #3, which in this case is the Sales Territory. If there is a segment override on Sales Territory setup for the ORIGINAL sales rep on the campaign - then the system will get the default G/L for the Product and will substitute the Sales Territory Override for Segment #3 in the G/L string. (If a split territory, it will get the Territory code from the first Original Rep on the Campaign)

    • If Segment swapping is done in Industry Code and/or Sales Territory, then there will be a G/L Override Value column on PIB Setup and/or Territory setup (similar to above description on G/L Type Setup

  • If no matches are found for any of the above, then the Default G/L from the product will be what is used.

• Exclude Product Formats - This is here because one of our clients told us that these segment overrides are important for Print Products, but Digital Products is more straightforward. So the dropdown will allow you to exclude one or more product formats for each of the Override Settings.

Troubleshooting

Looking at the campaign, what Revenue G/L is to be used is visible on the order:

We can see above that the first line got the G/L code from the Product Setup.

The second line got the G/L code from the Territory setting. It took the Default G/L from the product setup, and then switched segment 2 for the sales rep's territory setting. This one is highlighted in red though b/c this G/L does not yet exist in G/L Maintenance, so it is a reminder to go properly set up that G/L code.

If this order is a quote or reserved order, then the user would be prevented from confirming the order:

If the campaign was already confirmed, and a line is added which doesn't have a valid G/L code, then the line could potentially get saved with a bad G/L (as shown above with the red highlight) - which is why I mentioned (twice...or maybe three times) above that if you are using the segment swapping option in setup, then it is imperative that the G/L's actually exist in G/L Maintenance.

The best way to see if a batch of orders has any issues prior to attempting billing is to run the billing report for the intended billing date range and download the report to excel. The downloaded report has columns showing the G/L. If any of the G/L's are Invalid, they will be displayed in the last column. User can easily filter on campaigns with one or more invalid G/L's and ensure that they get resolved prior to billing. (this piece was a later addition and requires a build version dated 2/26 or later)