SmartView Internal has a built-in approximation of the GP RM & PM Aged Trial Balance reports. Just like the GP Aged Trial Balance Reports, you can enter in a “Cutoff Date” and it will then calculate the balances/aging data based on your RM/PM Setup and calculate the aging amounts.
This report is not, however, an exact copy of the GP version – there are a few differences. The ones that come up most often are as below.
Aging bucket amounts are off depending on the “Age as of Date”.
In GP then you enter in the cutoff date, any apply data that happens after a that date is not included in the report.
For example, If I have an Invoice for $100 for 11/30/2023 and I pay $80 on 12/1 – the Current Trx Amount on that document in the RM20101 table would be $20. If i run the aging report in GP and choose 11/30 as my cutoff, it would show $100 as the current balance because the apply record was over that cutoff. So even though the current amount in the database IS $20, the GP aging report “backs that out” and still shows the full amount in this case.
From SmartView, we only pull the data as-is, so that document WOULD show $20 as the Current Trx Amount since that is what the existing data has regardless of the cutoff date.
Some documents in the last aging bucket might not be evaluated.
The other thing that we see is using the last aging bucket, documents sometimes get “lost” and not counted in the SV version of the Aged Trial Balance reports. This could actually happen for the “current” bucket as well but that isn’t usually seen and typically the last aging bucket.
The reason why is SmartView properly bases the aging buckets on the report as how it is defined in your GP Company.
If we look at the GP RM Setup window, we can see the default Fabrikam Aging Buckets defined.
Notice that the last aging period is defined as 181 to 999 (days). While this appears to allow setting to any value, we cannot as GP limits this field to only 3 characters and therefore the largest value that can be entered in the UI is 999.
Looking in the RM Aging Period table – we can see that the RMPEREND (Period Ending Days) is indeed 999 as the window shows.
When SmartView runs the aging report, it pulls these values for the aging buckets. Since the “ending days” is 999, that is the value used in the SQL Query executed.
Looking at the SQL generated for the RM Aged Trial Balance, we can see that for the “Current” bucket – document days between -999 and 30 days are “current”. I believe that -999 is hard coded into SmartView since it isn’t defined in the table.
For the “last” aging bucket, it is defined per record 7 in the RM40201 table as 181 to 999.
This means that any document older than 999 days won’t be included in the results.
The “current” bucket of -999 to 30 days means that any document that is more than 999 days in the future will also be excluded from this query.
The PM version of this report does the same setup check and uses the same values in execution to show the data in the same way for both reports.
