Period 13 and 14 in GL to Track Audit Adjustments

Rauf

Rauf

VIP Member
We are using 'period end' as follows

Period 12 end date - 31/12/YYYY
Period 13 end date - 31/12/YYYY
Period 14 end date - 31/12/YYYY

If we follow like this, we will not be able to identify what are the audit adjustments the users entered.
Now, how we can track the audit adjustment.
1. Is it possible to change the period as follows ?

Period 12 end date - 29/12/YYYY
Period 13 end date - 30/12/YYYY
Period 14 end date - 31/12/YYYY

2. If the period change is not possible, can I use GL Date updated field (F0911.UPMJ)to check the audit adjustments ?
 
You can change the period dates you have specified. If you decide to do this you must be sure there have not been any posted entries already made with the Julian dates in those last two days. If so you may end up having integritiy issues. Clients of mine have chosen to track audit adjustments using a particular doc type(s) rather than using two extra periods. You need to weigh the pros and cons.
 
Alex,

Thank you very much for your reply.

  • We have entries for 2018 Dec. But we will implement this in 2019 Dec.
    But what happens if the user enter transaction in future period. For example, if we are in March 2019, the user can enter to period 14 ( Dec 31, 2019). Am I right ?
  • I was also thinking for doc type. But I guess lot of doc types are hard coded. So how this will effect the processing?
  • Is there any document available on both set up ?
 
Rauf Muhammed,

Yes, it is possible and common to create future transactions although unlikely that far in advance. If you are certain of making the change in the fiscal date patterns you will need to void (or delete) and post the voids any transactions in period 12 with GL dates of the last two days of the year (if there are any) BEFORE the change. It is extremely important that making this type of change can have a massive impact on your system including all other modules. Remember, they look at the date pattern as well. I would not do this without testing every module especially with the date pattern set to 12, 13, and 14. There are so many other things to consider so you should work closely with knowledgable JDE super users.

Custom doc types are very common. There is a set in the UDC table reserved for this purpose: U1, U2, etc. By using this method, you have far less to worry about in your testing. There is no impact on any modules except obviously General Ledger and it is treated like the typical "JE" doc type. So if accomplishing what the Financial department needs using this method, this is definately the way to go. You can easily create custom reports showing columns with the "audit" doc type.

I see your location "Kerala, India" under your profile name. I once drove 10 hours from Bangaluru to Kerala. I won't ever do that again! :)
 
Hello.
I missed to reply for this post but accidentally came across the subject again and search JDEList.
From this year on-wards, we are planning to use 13 periods instead of 12 periods.
Is there any documents available as a checklist before doing this change ?

:D Welcome to Kerala again, ( but don't drive that much distance :ROFLMAO: )
 
Last edited:
My query is that, until 2023 we used 12 periods, from 2024, can we use 13 periods? If I change it, is there any issues ?
 
Hi Rauf,
in my opinion you can add period 13 for FY 2024 in order to manage for example GL date 31/12/2024.
This should not conflict with any well written software as far as you did not use given gl date so far.

It's also important to know there are some localizations which are not correcly handling period 13-14 in general (regardless you are changing your current setup or you are starting with a new company).
For example: I'm working with Italian localizations and R09404 GL Legal Report is not able to correctly update F70404 table (it uses 12 buckets based onto F0911.GLPN field, thus period 13-14 are not supported).

Kind regards,

Carlo
 
Back
Top