Daynote ,Svenson |
-- Yesterday -- Week view -- Tomorrow |
MM-xviii Tuesday |
2000-01-18 |
The same watery stuff keeps descending from the same gay clouds. All the wile keeping the thermometer pegged at the same dull temperature. One TeleSales problem is found and solved. When adding a new address some fields are filled with default values (language, VAT code, etc.) which are maintained on the AS/400. The problem was that the language code, which is defined as a two character fields was filled with 'USA' (three characters). Using the standard maintenance programs that cannot happen, but of course there exist tools (SQL,DFU,...) to get behind the standard programs. In TeleSales putting three characters into a two character field sometimes is a problem (only if both fields are direct database fields), it produces a warning and truncates the value. Normally we trap these warnings where we expect them. In this case we didn't trap it because there is no regular way to get it wrong. Of course Americans never play by the rules. One problem found and solved doesn't however mean that there is one less problem remaining. I got a call from Belgium about a strange order. They had an order with two order lines, the order was in status Shipped. One of the lines had its invoice date already filled. This is strange because that date is only filled in the invoicing program and after invoicing (and filling the date) the order status changes to Closed. Digging a bit deeper we found that the order date of the one line was somewhere in October (99) while the order header and the other line were, as expected dated in January (00). They had run the conversion of the order from their old system to our database in October so our first suspicion was that some stray order lines had remained unnoticed and were now being picked up. While testing that here, in the OMSI-3 environment I found out that that was a distinct possibility. If for some obscure reason an order line, without header and with an order number greater than the highest actual order remains in the order lines file (OL) - this cannot be done with the regular programs - it will be picked up when a new order is created with that order number. This is dangerous and tricky. The user can see the unintended line but he doesn't know its origin, it shows up in exactly the same way that contract-defined lines appear. The result is that, once the order is released (and the user forgets the line) it is impossible to know if the line is a real line, to be shipped, or a stray line to be removed. After a few hours of searching and pondering we remembered that they don't use OMSI-3 but TeleSales. Ouch, tag about and sail another course. And here we noticed that a specific function, Copy From History, produces the same result. The order line is copied, exact, including the dates, from the historic order. The function is intended for, among others, a client who call and says "Do me the same as the last order for xxx" . "The same" of course should not mean the same creation date, or the same order date. A badly specified function, executed literally >!-- the head down and code like hell symptom --> and virtually untested. Well it was technically tested and found to conform with the design (copy from history), and no one checked it against the 'intended design'. Any error costs but an early error (design) costs more than a late one (implementation). And finding it after running half a year in a production environment is double trouble. The dates are used to build stock and sales statistics.
Who believes the data. Or trust the programs. This doesn't seem to be a good week for trafic. I just realized I created a small black hole by trying to put up a serial story on the tomorrow pages. It grows on a daily basis but for example as I write tomorrow's part ( to be posted now) I don't know what I will add after that. I have no story line, no plot. And I am not a writer. But I cannot stop now, can I? Adios |