MTD2Prio

I wrote a few weeks ago about our attempts to take the output from an external program and feed it into our ERP program. The external program is known as MTD (although I think that this is the name of the company and not the program itself) and the ERP program is called Priority; hence my program is called (with great imagination) MTD2Prio.

The previous installment of this saga had the team realising that the glue program needed to more than simply parse one of MTD's output files. I developed a simple quasi-database program (utilising a clientdatabaseset) which would display lines read from the file as well as lines added by the user. With no small amount of effort, I wrote code which would output five different files for import into Priority, one file for each table in Priority. Not all lines (parts) displayed on the screen are in each of the different files, so this part was more than tricky.

Once I had the five files (and originally I thought that I would need only three), I started on the work of importing those files into Priority and substituting parts in the given order with the parts in the files. Most of this work was achieved without difficulty, although it became apparent that I needed more data than I had originally planned (which is why the number of files increased). In a moment of inspiration, I also figured out how the program could use standard parts - a problem which had occupied us in a previous meeting and had been ignored since.

After displaying this new, improved version, some bright spark asked what would happen if the same part designed in the external program appeared more than once in the user's order. This could happen if the order was split up into sections, each section representing a different room in the customer's office; the same special table could be in each room. Obviously, the part would have to be designed only once, but the problem became mine: how could the user show that the part would have to be inserted into lines 1, 5 and 7 (for example) in the customer's order without defining three parts?

I figured out how to do most of the work as a mental exercise whilst driving back from Tel Aviv after the final economics lecture on Friday, but hadn't wanted to devote any time to implementing this new feature until after the exam. Today I had the time and space to devote to solving the problem, so solve it I did. I probably spent more time on parsing the input file than I did on the mechanics of the substitution in Priority. I wouldn't necessarily say that the work was overly complicated, but it demanded a certain finesse.

Anyway, that problem has been solved, leaving only one more problem of which I am aware, which is concerned with raw materials handling. As this is solely a Priority issue, I'm not expecting too much difficulty, but I'm leaving it for the moment in order to allow the solution to mature in my brain.

Of course, the users will probably have several issues which haven't been considered yet. These will probably be interface problems which won't necessitate any changes in the Priority code.