In an ideal business world, documents travel across the departments with ease and monotony. We say that they flow. Unfortunately, things are never this simple. External factors, which are seldom under our control, continuously influence our business. Our documents have to perform feats to reach their final destination, and sometimes they never do.
EXTREMELY SIMPLE SCENARIO
Consider a very small distribution business. The owner’s only concern is to be able to receive goods from his suppliers and to sell these goods to his customers. In terms of the programmes he needs to run his business we find that, in addition to the master files maintenance programmes, two types of transactions programmes are necessary:
1– A goods receipt programme, which will update the items quantities in the warehouse and their average cost
2– An invoicing programme which will also update the items quantities and print the invoice.
These programmes will interface with an accounting application. This will allow the management to chase customers for payments, to settle suppliers’ accounts, and to monitor their inventory value in the warehouse.
After a few weeks, our owner realises that some customer is not happy with the goods he has purchased, and that the customer would like to return the goods and obtain a refund. As the owner is very keen on keeping his good reputation intact, he agrees to return the goods and discovers that his application is not capable to produce a goods return voucher. A third transaction programme is now necessary to keep his business up to date, namely:
3– A sales return programme that will update the items quantities in the warehouse
This programme will also need to interface with the accounting application to update the sales, customers and inventory figures.
As the business grows, more dissatisfied customers return the items they purchased, because they have discovered that the manufacturer has recalled the faulty items. Our owner has now to produce a document that will allow him to return goods to his supplier, he needs:
4– A purchases return programme that will update the items quantities in the warehouse and their average cost.
Again, he requests a modification to the interface with the accounting application.
Once the purchase return programme out of the way, his business takes off and requests for supplies from all over the country converge on his small warehouse. He decides to set up two other points of sale with their warehouses in the north and south of the country. He needs to update his application to handle:
5– Transfers between warehouses. The programme will update the quantities in both issuing and receiving warehouses.
The programmes are ready, and goods are now travelling north and south for delivery to the new warehouses. Unfortunately, our friend has not realized that transport costs have increased and that the items are selling in the north at a lighter profit than those of the capital. He needs to calculate his new average cost to take the transport costs between warehouses into consideration. This will be can be done using a:
6– Cost and consolidation programme similar to the one he is using for his goods receipts.
Unfortunately for him, and fortunately for the application developer, this will be an expensive exercise as the accounting interface will have to be changed at its core to handle the new accounting entries necessary for the freight forwarders fees, transport, consolidation and the custom duties which he had entered manually to this day.
MEDIUM COMPLEXITY SCENARIO
The transfer between warehouses hurdle is now cleared. The business size has grown and large institutions are requesting proposals before committing to purchases. The owner now contacts the software house and the sales manager explains that:
7– Pro-forma invoices have to be prepared before generating the sales orders.
8– Sales orders? The analyst has to enter this new request in his logbook.
Programmes are written and tested, with the usual bugs appearing now and then. Eventually, the application runs and the secretaries are busy entering pro-forma invoices and sales orders, a tedious and repetitive task. Sometimes, customers complain that the sales orders are not complete; that they miss some of the items quoted in the pro-forma, or that the prices quoted have changed. The sales manager has to visually check the pro-formas and sales orders for consistency, and he does not like that. He prefers to be out and selling, earning his commission.
Management has decided to lower their prices to increase their turnover, but they notice that commissions are not considered as part of the cost of goods sold:
9– Another modification to the accounting interface is required.
10– Customers require now delivery notes as they wish to benefit from credit terms. They will take delivery of the goods and then will start negotiating payment terms when the invoice is issued.
11– Terms of payments are added to the invoicing module,
12– Terms of payments are also added to the purchase and sales orders modules.
This requires work on the part of the programmers but, as these modifications appear to be final, they perform their work with some enthusiasm.