Friday, October 08, 2010

Misinformation

I've written before about the ERP program with which I work. I think that this program is comparatively easy for the average user, but it comes into its own when talking about development. This program allows the developer to add tables, screens, reports and procedures, all with a standard format. This capability to extend the program's capabilities is what enables the companies using the program to customise it according to their needs. In my humble opinion, one of the companies in the group exaggerated in the amount of customisation that they demanded and created a program in which the non-standard seems at times to be larger than the standard.

In the past year and three quarters, I think that I've managed to encourage the use of standard procedures, whilst ignoring some of the more outlandish developments. The passage of time and changes in the working population have allowed some of the customisations to be forgotten. At the same time, I've added some customisations of my own, primarily designed to increase the use of the ERP and decrease the use of Excel.

The other day I was asked to develop a screen in which would be stored reservations of raw materials (a certain raw material will be ordered for a specific customer order and no other customer order should be allowed to use that raw material). Every company seems to implement this in a different matter (if at all) which may be why there is no coverage of this subject in the standard program. My development is not much more than two data tables and two screens; the data does not affect anything else in the program.

In the course of writing a database trigger, I needed to refresh automatically the data screen, specifically a line different from the current line. I remembered that there was such a function listed in the documentation, so I hauled out the manual, found the relevant section and added the necessary command to the trigger. Instant syntax error.

I contacted the company who supports us about this; normally they answer my programming questions quickly (for example, how do I display data on the screen in a different colour), but this time I was given the bum's rush. I was sent a copy of the documentation (which I already have) and told that if I don't solve the problem, the company will be willing to do so for a fee. I checked the documentation to see whether it had been updated from the version which I have, but the relevant section showed no changes.

Somewhat annoyed, I decided to scan all the existing triggers in the program; this idea caused information overload as there are a lot of triggers. So I scaled down my request and asked for the code to all the triggers in screens beginning with A; once this was displayed, I searched for the word 'refresh' (the necessary command) and found it quickly. It turns out that the command has to be called with a parameter, presumably the number of seconds to wait before refreshing. I added 'refresh 1' to my trigger's code - and it worked perfectly.

In order to close the service call which I had opened, I wrote that I had found a solution without giving any details, although I did write that there was a mistake in the documentation. I was sorely tempted to write that I would reveal the correct syntax for a fee but decided to cut down on the sarcasm.

From the very first time that I saw the documentation, I saw that one could only understand it after one understood what was necessary to do. The documentation is sometimes hard to understand, lacks examples and in this case, totally wrong; instead of writing 'use the refresh command', they could have given an example.

Such problems are very annoying; very often, solutions come via favours from other developers or via hard personal graft. It shouldn't be like this.

No comments: