Archive for the ‘Reporting’ Category

Sage 200 aged debtors.

August 22, 2009

While Sage 200 includes aged debtor reports as standard, we prefer to work with the aged debtor reports in Excel though, and we prefer to grab the data directly, so that we can manipulate it at will

This poss includes a series of ‘SQL Server views’ that together give an aged debt, grab the most recent memo (which we use for recording credit control conversations) from the customer account, and show basic contact information.

Provided you or a colleague have basis SQL Server skills, it is straight-forward to create the necessary views in your Sage 200 SQL Server database.  You can choose your own name for the first view, and this is the one that you should link to from Excel, but the other views will need to use the names indicated.

This version doesn’t support foreign currency accounts, and it also can’t be used to produce retrospective aged debtors.  There are other ways of achieving much the same end, including the use of pivot tables which has the advantage of letting you drill down to transactions. 

The views don’t format particularly well as created via our blog software I’m afraid, but you should be able to cut and paste directly.  Also the views were put together by someone relatively inexperienced, so we know they’re not as tidy as they might be!

If you need help implementing this or similar Sage 200 aged debt reports please contact our Sage 200 support service.

Sage 200 retro reports don’t work!.

June 27, 2009

The problem is that the allocation date, which is set within the top right section of Sage 200’s allocation screens, defaults to the current date.   This is really easy to overlook, and calls to our Sage 200 support team suggest most users are, quite reasonably, unaware of the implications of that date. However, this can cause a few hiccoughs if left unchanged, affecting retrospective debtors/creditors reports, retrospective statements, and any view of average times to pay by customers (visible in the account details report).

With this in mind, it is generally a good idea to change the allocation date from the default of the current system date to that of the latest transaction in the batch being allocated, to keep analyses based on transaction and allocation dates consistent.   Sage 50 does this automatically, so perhaps this is something the software developers need to talk to each other about!

There is a fix, however, if you forget to do this when allocating.  You can always go into the Amend Allocation option under the Adjust Transactions menu on the sales or purchase ledgers and either undo or amend the date on the problem allocations.