In the UK, from 1st January the standard TAX rate is returning to 17.5%. This was reduced to 15% on 1st December 2008 to help the economy. With only a week’s notice, it also caused headaches for software developers and finance departments throughout the country.

For SEAS, our electronic invoice approval system, the one week’s notice of change to 15% did not give enough time for us to develop, QA and deliver an update to manage start and end dates in feeds of VAT Codes and processing according to the invoice date. Some customers use different VAT codes, so it was not an issue. For others we had to look at workarounds. But start and end dates for VAT Codes have been on the roadmap for the latest release, due out in the next couple of weeks.

Some customers will have feeds without start or end dates; some feeds may have an end date, but no start date; and some feeds may have a start date, but no end date. So to cover these scenarios, our import process is setting some default dates – 01/01/2000 for the start date and 31/12/2099 for the end date. For invoice line coding, we’re pulling only the VAT codes relevant for the invoice date, and this is where I banged my head against the desk for a little while.

Here is a snippet of the code I used:

VAT Rates Code

However, when I ran the code using VAT rates with my default dates and debugged the values, invDate.TimeDifference(startDate) returned 3128554400 and invDate.TimeDifference(endDate) returned 1452148096. Both were positive values and yet the invoice date was between the start and end date.

After a bit of head scratching and testing to confirm that the method did work, I noticed a similar method TimeDifferenceDouble. As soon as I replaced TimeDifference with TimeDifferenceDouble, it worked fine, and a print statement identified the cause – invDate.TimeDifference(endDate) returned 2842819200. TimeDifference returns a long, whose maximum negative value is -2147483648. Any maths experts among you will know why it was returning 1452148096 instead, but essentially the outcome of the computation was exceeding the limits for a long. Another example of the importance of using the right data type.

 

Leave a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Scroll to Top