Evariste

In an ideal busi­ness world, doc­u­ments travel across the depart­ments with ease and mono­tony. We say that they flow. Unfortunately, things are nev­er this sim­ple. External factors, which are sel­dom under our con­trol, con­tinu­ously influ­ence our busi­ness. Our doc­u­ments have to per­form feats to reach their final des­tin­a­tion, and some­times they nev­er do.

EXTREMELY SIMPLE SCENARIO

Consider a very small dis­tri­bu­tion busi­ness. The owner’s only con­cern is to be able to receive goods from his sup­pli­ers and to sell these goods to his cus­tom­ers. In terms of the pro­grammes he needs to run his busi­ness we find that, in addi­tion to the mas­ter files main­ten­ance pro­grammes, two types of trans­ac­tions pro­grammes are neces­sary:

1– A goods receipt pro­gram­me, which will update the items quant­it­ies in the ware­house and their aver­age cost

2– An invoicing pro­gram­me which will also update the items quant­it­ies and print the invoice.

These pro­grammes will inter­face with an account­ing applic­a­tion. This will allow the man­age­ment to chase cus­tom­ers for pay­ments, to settle sup­pli­ers’ accounts, and to mon­it­or their invent­ory value in the ware­house.

SIMPLE SCENARIO

After a few weeks, our own­er real­ises that some cus­tom­er is not happy with the goods he has pur­chased, and that the cus­tom­er would like to return the goods and obtain a refund. As the own­er is very keen on keep­ing his good repu­ta­tion intact, he agrees to return the goods and dis­cov­ers that his applic­a­tion is not cap­able to pro­duce a goods return vouch­er. A third trans­ac­tion pro­gram­me is now neces­sary to keep his busi­ness up to date, namely:

3– A sales return pro­gram­me that will update the items quant­it­ies in the ware­house

This pro­gram­me will also need to inter­face with the account­ing applic­a­tion to update the sales, cus­tom­ers and invent­ory fig­ures.

As the busi­ness grows, more dis­sat­is­fied cus­tom­ers return the items they pur­chased, because they have dis­covered that the man­u­fac­turer has recalled the faulty items. Our own­er has now to pro­duce a doc­u­ment that will allow him to return goods to his sup­pli­er, he needs:

4– A pur­chases return pro­gram­me that will update the items quant­it­ies in the ware­house and their aver­age cost.

Again, he requests a modi­fic­a­tion to the inter­face with the account­ing applic­a­tion.

Once the pur­chase return pro­gram­me out of the way, his busi­ness takes off and requests for sup­plies from all over the coun­try con­verge on his small ware­house. He decides to set up two oth­er points of sale with their ware­houses in the north and south of the coun­try. He needs to update his applic­a­tion to handle:

5– Transfers between ware­houses. The pro­gram­me will update the quant­it­ies in both issu­ing and receiv­ing ware­houses.

The pro­grammes are ready, and goods are now trav­el­ling north and south for deliv­ery to the new ware­houses. Unfortunately, our friend has not real­ized that trans­port costs have increased and that the items are selling in the north at a lighter profit than those of the cap­it­al. He needs to cal­cu­late his new aver­age cost to take the trans­port costs between ware­houses into con­sid­er­a­tion. This will be can be done using a:

6– Cost and con­sol­id­a­tion pro­gram­me sim­il­ar to the one he is using for his goods receipts.

Unfortunately for him, and for­tu­nately for the applic­a­tion developer, this will be an expens­ive exer­cise as the account­ing inter­face will have to be changed at its core to handle the new account­ing entries neces­sary for the freight for­ward­ers fees, trans­port, con­sol­id­a­tion and the cus­tom duties which he had entered manu­ally to this day.

MEDIUM COMPLEXITY SCENARIO

The trans­fer between ware­houses hurdle is now cleared. The busi­ness size has grown and large insti­tu­tions are request­ing pro­pos­als before com­mit­ting to pur­chases. The own­er now con­tacts the soft­ware house and the sales man­ager explains that:

7– Pro-forma invoices have to be pre­pared before gen­er­at­ing the sales orders.

8– Sales orders? The ana­lyst has to enter this new request in his log­book.

Programmes are writ­ten and tested, with the usu­al bugs appear­ing now and then. Eventually, the applic­a­tion runs and the sec­ret­ar­ies are busy enter­ing pro-forma invoices and sales orders, a tedi­ous and repet­it­ive task. Sometimes, cus­tom­ers com­plain that the sales orders are not com­plete; that they miss some of the items quoted in the pro-forma, or that the prices quoted have changed. The sales man­ager has to visu­ally check the pro-formas and sales orders for con­sist­ency, and he does not like that. He prefers to be out and selling, earn­ing his com­mis­sion.

Management has decided to lower their prices to increase their turnover, but they notice that com­mis­sions are not con­sidered as part of the cost of goods sold:

9– Another modi­fic­a­tion to the account­ing inter­face is required.

10– Customers require now deliv­ery notes as they wish to bene­fit from cred­it terms. They will take deliv­ery of the goods and then will start nego­ti­at­ing pay­ment terms when the invoice is issued.

11– Terms of pay­ments are added to the invoicing mod­ule,

12– Terms of pay­ments are also added to the pur­chase and sales orders mod­ules.

This requires work on the part of the pro­gram­mers but, as these modi­fic­a­tions appear to be final, they per­form their work with some enthu­si­asm.

To be continued…