Another good idea

Just by chance, I had two very good ideas regarding Priority on Monday. It doesn't normally work like that so don't read too much into the coincidence of dates. Although on the other hand, my brain must have been highly activated that day which allowed me to see solutions which I had previously missed.

We have a business unit which is ... problematic, to say the least. Their method of working is unique and their workers aren't exactly the sort of people who take naturally to an ERP program. I know that I've mentioned this business unit before, but at the moment, I can't find any of those references (The second half of this post is about them).

This business unit derives most of its income from creating industrial floors. A building will have some kind of floor, but for industry (and also for basketball courts), a special floor covering is required. These coverings are created by mixing together various plastics, lacquers and similar products then layering them on the existing surface. I don't pretend to understand this and I don't really need to understand it. As far as I am concerned, they are taking raw materials and turning them into a finished product. The problems are that this process takes place at the customer's site and that there are no fixed quantities for a square metre of floor.

Several months ago, I overhauled their business processes as executed within Priority in an attempt to make things as simple as possible for them whilst at the same time allowing all the data to be recorded as if they were working in a more standard manner. As mentioned in the previous paragraph, 'production' takes place at the customer's site. This means that raw materials have to leave our warehouse and be transported; this fact has to be represented in the inventory table. The amount of raw material sent may not correspond to the amount needed for the current month; in other words, if a project is going to straddle months, there may not be a correspondence between the month in which the inventory is sent and the month in which the work is performed. The work can also be performed over several months.

Priority allows inventory to be marked with a status; the most normal status is 'goods', but there exists the possibility of marking the inventory with a status which is equivalent to the number of the customer. This way, we can tell how much inventory has been delivered to each customer's site. This seemed to be sufficient, but a few days ago, a request was made to differentiate between projects: apparently one customer has two separate but concurrent projects and it's not possible to differentiate what inventory belongs to which project.

This had me stumped for a while, but then I remembered that Priority allows one to define 'locations' or 'sub warehouses' within a warehouse. We don't use this capability which is probably why it didn't spring to mind. But once I considered 'locations', I realised that this was the answer. We have defined one (virtual) warehouse which holds all the inventory which has been delivered to customers' sites; the inventory is differentiated within this warehouse by its status. I added a little twist to this: each inventory movement will now be against not only this warehouse but also against a specific location (which naturally is the project's number). Thus we can always know how much inventory has been delivered for a specific project.

Actually implementing this was slightly more complicated than I expected, although a great deal of the implementation time was actually spent of fixing a bug which I had unwittingly introduced about a month ago.

[SO: 3663; 2, 15, 35
MPP: 574; 0, 1, 6]