Sage 100

For a client several years ago we implemented a Script that runs the A/R Aging out to Paperless, daily via Windows Task Scheduler on the server.  This worked fine until we realized it's just picking up the Aging Date as per the last time the Aging was run.  Therefore, we needed someone to run the Aging daily, ideally at least Mon - Fri.  Hadn't gotten back to trying to figure out if that's rectifiable.

Brett - what was the issue here - was it that the report date on the server wasn't changing?  What was the key difference between running it unattended on the server through scheduler and someone at their desk running the report (this is our current proposed workaround)?

For a client several years ago we implemented a Script that runs the A/R Aging out to Paperless, daily via Windows Task Scheduler on the server.  This worked fine until we realized it's just picking up the Aging Date as per the last time the Aging was run.  Therefore, we needed someone to run the Aging daily, ideally at least Mon - Fri.  Hadn't gotten back to trying to figure out if that's rectifiable.

I think the issue with scheduling the Aging report is that it uses the module date as the aging date... and the module date doesn't get updated by the task scheduler.

I seem to remember doing a SQL script many years ago to set the module date for a Premium client, to bypass that problem... but my memory of the details might be mixing this situation up with something else.

Brett - what was the issue here - was it that the report date on the server wasn't changing?  What was the key difference between running it unattended on the server through scheduler and someone at their desk running the report (this is our current proposed workaround)?

For a client several years ago we implemented a Script that runs the A/R Aging out to Paperless, daily via Windows Task Scheduler on the server.  This worked fine until we realized it's just picking up the Aging Date as per the last time the Aging was run.  Therefore, we needed someone to run the Aging daily, ideally at least Mon - Fri.  Hadn't gotten back to trying to figure out if that's rectifiable.

Seems like another "little" PITA issue that Sage could fix.  Is this on the Ideation for 2026?

I think the issue with scheduling the Aging report is that it uses the module date as the aging date... and the module date doesn't get updated by the task scheduler.

I seem to remember doing a SQL script many years ago to set the module date for a Premium client, to bypass that problem... but my memory of the details might be mixing this situation up with something else.

Brett - what was the issue here - was it that the report date on the server wasn't changing?  What was the key difference between running it unattended on the server through scheduler and someone at their desk running the report (this is our current proposed workaround)?

For a client several years ago we implemented a Script that runs the A/R Aging out to Paperless, daily via Windows Task Scheduler on the server.  This worked fine until we realized it's just picking up the Aging Date as per the last time the Aging was run.  Therefore, we needed someone to run the Aging daily, ideally at least Mon - Fri.  Hadn't gotten back to trying to figure out if that's rectifiable.

For a client several years ago we implemented a Script that runs the A/R Aging out to Paperless, daily via Windows Task Scheduler on the server.  This worked fine until we realized it's just picking up the Aging Date as per the last time the Aging was run.  Therefore, we needed someone to run the Aging daily, ideally at least Mon - Fri.  Hadn't gotten back to trying to figure out if that's rectifiable.

Recently had a customer ask for a modification to a job that toggles a customer's credit hold based on those aging fields so I used perform logic on the following events to do this.

• On Execution: Get the object handle to the AR_Customer_Svc object.
  • oAR_Customer_Svc = NEW("AR_Customer_Svc", %SYS_SS) ! '
• On Completion: Drop the AR_Customer_Svc object.
  • DROP OBJECT oAR_Customer_Svc; oAR_Customer_Svc = 0 ! '
• After Read: Age the customer by pointing the first argument to the column that holds the ARDivisionNo and the second argument to the column that holds the CustomerNo.
  • oAR_Customer_Svc'AgeCustomer(IMP$[1], IMP$[2])

The import job can be set up to use ODBC as the source with a specific DSN set up for the target company or you can select the SOTAMAS90 DSN and click the "key" button to enter credentials.  You will have to specify the company by entering the user name followed by the vertical pipe and the company code, i.e. odbc|ABC.  Select AR_Customer as the source table and then select at least the ARDivisionNo and CustomerNo field.  Add at least the ARDivisionNo and CustomerNo fields to the Data tab.  You could optionally create a UDF to populate with the current system date to identify the last date the job ran successfully but this will cause the customer record to be updated and will change the UserUpdatedKey.  If you don't want to update the customer record, you can just add something to the Select tab to make it where it is impossible for any records to meet the criteria, such as ARDivision being equal to ZZ or something similar.   

Once the job is set up and compiled, you can either schedule it using Task Scheduler in Sage 100 or use the old external shortcut approach to schedule the job.

------------------------------
David Speck II
Blytheco LLC
------------------------------