E9.2 Switching Subledger Type mid financial year

JohnDanter2

JohnDanter2

VIP Member
Hi all

We go live in a few weeks with 9.2 after previosuly being on 9.0
In 9.0 we setup a subledger of P for Polish accounting or something or other, but now in 9.2 P is linked to Job Costing and so formats the subledger field to ' NTAX'
(this is due to SAR 22613878 on B0000021 - Format Sublegder)

Accounting want the Subledger to remain as 'NTAX ' with no leading spcaes for reporting purposes.

My solution was to stop using P and switch to S. Can this cause any issues at month end year end etc? Or is it a perfectly normal thing to do?

As for now the temp solution until year end is to edit the code in B0000021 not to add spaces for P SBLTs

Thanks

John
 
Hi John

A few of things to think about

The left right justification is controlled by the 2nd description in the 00/ST - Subledger Type for Non hard coded subledger types.
1666882065180.png

If you are happy to change the subledger type - S Subledger Type can be very useful for validating against specific UDC table(s) (P0907) therefore if the user is typing it in then this could work but if it's automated then go with X or another value with A in the second description.

P - Are you saying this is hardcoded now in 9.2 - Maybe worth trying with an A in the second description to see if that works. Doubt it but worth a go!!

If you are using P currently then there may be reports that are built based upon that selection !! BSFN change would obviously rectify this.

As long as you get this fixed up before Go Live you are good - If any transactions go in with multiple formats it will create additional F0902 records which can be confusing to the finance team. <-- Updated - If this is a simple upgrade then your data will be in the old format. It really would be good to have a consistent format and type when you go Live. So, if the future format is different, you will need to do some data cleansing. Ping me if it gets to this and I will walk you through it.

Kind Regards

Lawrie
 
Last edited:
Hi John,

I agree with you: since "P" subledger type has now a specific meaning ("Revenue Performance Obligation" from E1 9.1) it would be wise to switch to a user defined / custom subledger type as "S - Structured" or "X-Y-Z" (see UDC 00|ST DL02 field for formatting purposes).

"S" subledger type allows you validation through one ore more UDCs while X-Y-X have no validation at all.

In order to safely switch between P and the new subledger type you can enter journal entries debiting and crediting accounts with different subledgers.

If you go for the "SQL solution" (update SBLT field within F0911 and F0902) you need to keep care about balance forward field (APYC), thus it's not suggested to update just current year when using subledger for balance sheet accounts.

Hope this helps,

Carlo
 
Hi John

A few of things to think about

The left right justification is controlled by the 2nd description in the 00/ST - Subledger Type for Non hard coded subledger types.
View attachment 19455

If you are happy to change the subledger type - S Subledger Type can be very useful for validating against specific UDC table(s) (P0907) therefore if the user is typing it in then this could work but if it's automated then go with X or another value with A in the second description.

P - Are you saying this is hardcoded now in 9.2 - Maybe worth trying with an A in the second description to see if that works. Doubt it but worth a go!!

If you are using P currently then there may be reports that are built based upon that selection !! BSFN change would obviously rectify this.

As long as you get this fixed up before Go Live you are good - If any transactions go in with multiple formats it will create additional F0902 records which can be confusing to the finance team. <-- Updated - If this is a simple upgrade then your data will be in the old format. It really would be good to have a consistent format and type when you go Live. So, if the future format is different, you will need to do some data cleansing. Ping me if it gets to this and I will walk you through it.

Kind Regards

Lawrie

HI Lawrence,

Yes mate, I had to mod B0000021 to be only if SBLT = C do the padding (it used to be like that in 9.2 but now the hardcoded IF is C or P)

I just wanted to know if they can 'stop' using P going forward. What harm would happen financially and reconcillation wise if they just topped using P on go live day 1
 
Hi John

So if the historic record is NTAX P and future records will be NTAX S for instance then for each accout you will end up having 2 F0902 balances instead of one. One for each subledger type. When added together the results will be correct.

Whilst this is untidy it may not be a problem for you depending on your reporting and other processes but if you want to tidy this up there are a few options as Carlos has mentioned above.

1) Journal from old to new - that would correct from the current period only, but all history will be in the old subledger.
2) SQL during upgrade all the relevant F0911 and F0902 records to the new structure which will mean one record in the F0902 per account moving forward. This would need to be done prior to new transactions being processed.
3) If you can't do this at the time of upgrade ie transactions have been processed. you would need to delete the F0902 records and repost the accounts using R099102. A little more tricky but doable. You would need to run the annual close for previous years which again is OK assuming there are not historical integrity issues.

Kind Regards
 
Back
Top