Daynote ,Svenson

The good weather is drifting away. It was overcast and raining in the morning (11°C), with enough gaps to enjoy that big red neon sign rising. Throughout the day it was dry except for one short but furious shower but overcast. Enough blue spots so it wasn't a grey day.

The latest patch for TeleSales is being finished. V9 ready and shipped today and V8 scheduled for shipping tomorrow. Of course this is the best moment for Jan to report a problem and demand a fix to be included in the shipments.

On an order the user has to enter an invoice address (and an order address and a delivery address). Not all addresses in the database are invoice addresses. Nothing was checked originally which of course was wrong and a PR was made. And solved by adding a test on a status field in the address file. Now Jan reports that it still doesn't work, Ronny tests it here and it does work. Claim and counter claim, it works, it doesn't work, it does, it doesn't etc. etc. Finally we find that the test works as it should but somewhere else an invoice address can be logically deleted and that is registered in one file but the main address file isn't updated.
So IT works and IT is not a bug as Jan claims but interference from a real bug in a different function (originally 'tested' and accepted by Jan) is causing the problem.
A clear example for Aloha.Dan that not everything a user calls bug is an actual bug.

I leave the trigger problem for a moment and concentrate on a "bug" in America. According to Jan there is a problem with the processing of the Invoice Calculation Files. Records remain in the file long after they should be processed and removed.

Let us apply the Standard Procedure. :

• First check all the programs related (far and near) to the reported problem. This is a cursory check for recent changes and to establish the program and data flows.
  Nothing has changed in the last year or so, and all the documentation is up to date (exceptionally this function is well and fully documented (guess by who) )
• Next check the central database (on our machine) for the occurrence of the reported problem.
  Of course nothing is wrong here.
• Third step log on to the remote system and confirm that the reported situation exists as reported.
  The problem exists. There are over 800.000 extraneous invoices. Oeps
• Step four establish the incorrectness of the reported situation. Problems often get closed after this step. It is not uncommon that a user sees something unexpected and calls us in panic while we later notice that the situation is normal but that he looked for example on the wrong database or checked against a wrong date or ... .
  Checking against the trigger file (which is not messed up in the USA) shows there should be between one and two hundred record. Venlo, we have a problem. A real problem.
• In the fifth step we look for locally adapted programs. Often a local adaptation cause problems because it is not tested regressively.
  There are local programs but, checking the source (which we normally don't do, local programs are local responsibility) they aren't changed in a way that could possibly interfere with the handling of the Invoice Calculation Files.
• Sixth step check the usage, sequence and periodicy of the processes involved.
  Aha. America doesn't use our accountancy package. Therefore they don't run our Posting to General Ledger routine. And guess what, this routine is responsible for cleaning up (or flagging for cleanup) of the records in the Invoice Calculation Files.

Problem located.

The solution is that they change the calculation, pre flagging the records for cleanup so that immediately after invoicing they are removed. And to correctly remove the current records they should run the first step in the Posting interface.

Problem solved.

Adios