Many people don't understand what I do at work, so today I thought that I would explain in simple language some of the things which I did today.
At work, we used to have a thermal printer which printed sticky labels; we would place these underneath the seats of the chairs that we produce, so that we (and the customer) would always know what kind of chair s/he had and when it was produced. The printer came with software which could print labels, but we didn't use this much. The main reason was that the software couldn't connect to our ERP program and thus was useless in printing labels directly from work orders. The second reason was that every few months, the program would deliberately mix letters up when printing, causing us to renew the license (free, but still a chore).
I wrote several programs to counter these shortcomings. The most important was one which connected directly to the ERP program (via a documented but difficult interface); the user would key in a work order number, the program would query the database and would then produce labels with the chair's part number, customer details, etc. The program was also equipped with a numerator: as we put one label underneath the seat and one on the plastic bag in which the chair was shipped, we needed to print two labels per chair, but count them identically. As I had full control of what was printed, this wasn't a problem. On the other hand, we also supply chairs in cartons; these have a special, generic label giving the part name along with a barcode; for these, we only needed to print one label. With a little bit of ingenuity, the program was able to handle both double and single quantities, printing the correct numbers on each label.
The generic barcodes were printed from a simple database program which I wrote. Instead of designing different labels, I realised that each label has exactly the same constituent parts: a title (eg Realto chair with adjustable armrests), a descriptor (Tahiti 200 blue upholstery) and its barcode. Once I had this, the design of the label was simple. The user would choose a chair from a database ordered by family (eg Realto) and then would key in how many labels to print. These programs have been working for about four or five years.
Unfortunately, we had a fire in the factory and the thermal printer was destroyed (and of course, the morning of the fire was when we had a new printer head installed at a cost of $500). A few days ago we obtained a new printer; it's not the same model and not from the same company. The reason why we chose this company is that they market a program which is supported by our new ERP program; the latter can output data from work orders to the former, which will then cause the labels to be printed.
Well, yes, in theory. In practice, it took the installer and myself a few hours to design a label and get all the relevant fields printed in the correct position. The most complicated part was the numerator, and even then we didn't get it right. I had told the ERP company that we needed two labels per chair, so the procedure which outputs the data doubled the amount. Correct, but the label program numerator interpreted this as is, which is wrong.
If the order was for five chairs, then there should be two labels numbered 1/5, two labeled 2/5, two labeled 3/5, etc. We were getting one label 1/10, one labeled 2/10, etc. Not good. The temporary solution was to halve in the ERP program the number of labels being printed, and then do two print runs, but this obviously was only a stop gap solution.
The label program comes with virtually no documentation, so it wasn't a question of RTFM. Today I had enough time to play a little with the program, and found to my pleasure that it was possible to add a little code - event handling. The numerator is really two fields: one a real numerator, and one the total number of labels to be printed. The latter was easy to fix: the field received the code "value = value / 2", and thus printed half the number of labels to be printed, which is of course the correct number of chairs. Encouraged by this, I had to think a little before I came up with a function for the numerator - value = (value - 1) / 2 + 1. When value is 1 or 2, the result will be 1; when it's 3 or 4, the result will be 2. Just what the doctor ordered.
Just to be safe, I kept the original label which we designed with its 'pure' numerator; this will be used when printing labels for chairs which are supplied in cartons, or for stacks of chairs (where each chair needs its own label, but they are supplied in stacks of ten).
At the moment, we're using labels which were supplied with the printer and aren't the same size as our original ones. Whilst this doesn't matter too much with labels printed with the external program, it made labels printed with my database program look bad. Early on, I realised that this was because there was a height problem: my program thought that the labels were (say) 4 cm in height whereas in fact they are 4 inches high. Although the printer came with a fair amount of documentation (on cd), I couldn't see where the label height was defined - until I remembered that it was defined in the printer setup dialog. Sure enough, I found the definition there. I'll change the current value when we get some rolls of "our" labels delivered.
Other bits and pieces were explaining to users how to get correct data from the ERP program, and altering a few reports in order to add ordering fields. As I term it, this is easy stuff for man, but hard stuff for mankind. The mantra is business is "keep the customer happy", and I do my best to keep my customers (ie other users) as happy as possible by giving them solutions as quickly as possible.
No comments:
Post a Comment