We need to explain the relationship between a Credit Note, which is generated against a Contract Invoice and the Contract itself. A clearer understanding of this relationship many indicate that, in many circumstances, a manual Credit Note should not be generated.

Why does the Charge-to-date not change when you credit a contract invoice?

It has been suggested that if you credit a contract invoice, the system should automatically re-evaluate the contracts Charge-to-date, possibly resetting it back to the end of the last charged period. Let's take a moment to consider this. The most common circumstance where this is an issue is in the crediting of an invoice, generated automatically by the program to cover a future charge period, as the customer has stated that they intend to vacate their Unit. Leaving aside the issue of whether a credit note of this type should be manually issued anyway, let's look at the various ways the program could address this action.

First, in the above case the credit note is being issued because the total invoiced charge is unjustified, the customer wont even be in their unit. The result of this might seem to be to considered that, in effect, the charge for this period never existed and thus the system should revert the Charge-to-date of the contract back to one day prior to the period covered by the credited invoice. So lets assume that this happens, the Charge-to-date has now reverted back, so the next day Space Manager restarts and during the start of day routines identifies that the same contract is now due (again) for the next period's invoice and so generates it in the normal way. Now the invoice you credited is back. Credit this one and the same happens again the following day, and so on.

Next, lets consider a situation where the period invoice is only part credited. What should happen to the Charge-to-date then? Should we move the Charge-to-date back part of the way through the originally charged period? If we did this and the Charge-to-date were sufficiently historic, we would be back to automatically creating the next period invoice, only this time the new period would be out of sync with the previous ones.

How should the system handle it if the period invoice of part paid not because a period was charged for when it should not have been, but because the period rate was originally too high. The system should not automatically move the Charge-to-date in this circumstance, but how does it know the difference? What happens if we are crediting an invoice which is not the last automatic invoice generated?

What about the Paid-to-date?

Ok, now lets consider the Paid-to-date. Using the above scenarios, you might argue that if a credit note were to be issued against a contract invoice, then, in addition to reverting the Charge-to-date, the Paid-to-date should also be set to the end of the last period. But we have a similar problem to the changing of the Charge-to-date. In essence we do not know whether the credit should be considered as a cancellation of the original invoice, or part of it, or a reduction in the amounts charged for the full period (perhaps even to zero). If we consider the credit to be a reduction in the original charge made against the contract, then if we credit the invoice so that it has no outstanding balance, should we then not consider that the requirement for the customer to pay for the charged period have been effectively fulfilled? Shouldn't we therefore move the Paid-to-date accordingly?

In essence there are just too many possibilities to be able to cover them correctly within the program.

So how does Space Manager handle these credit notes?

Space Manager does not make any assumptions as to the ultimate purpose of the credit note, simply because there is a very high probability that it will be wrong. Computer programs can only deal with situations that they have been specifically told about, they cannot build in additional flexibility 'on the fly'. So, quite simply, in order for users to be able to use the credit note facility in the broadest number of circumstances, the system make no changes to the contract's Charge-to-date at all - the probability is too high that any such automatic change would be wrong. So, the period has been charged and the invoice exists on the customer's account. Any requirements to charge the contract's Charge-to-date, due to the specific manual crediting of contract a invoice, must be made manually also - if required.

The paid-to-date is handled in much the same way, only from the opposite point of view. An invoice has been generated for a period. This invoice, originally, has an outstanding balance, which must be cleared before the contract Paid-to-date is moved forward. The outstanding amount can be 'cleared' by receiving payment(s) from the customer, by generating one or more credits against the invoice or by a combination of the two. Once cleared, Space Manager moves the Paid-to-date forward in the normal way. If this is not what is required, the user can manually return the Paid-to-date for the contract to the original date using the Edit Customer/Contract option on the Problem Functions Menu.

So what about the original scenario- crediting an invoice because the customer intends to move out?

If the invoice for a future period is credited manually as well, Space Manager has no idea as to the real purpose of this credit and so will issue other credit based upon the date to which it believes the customer has been charged i.e. the Charge-to-date.