Station 9 of 10
Customisation and extension in SAP Business One
What you leave this station with
Placing any client request on the customisation ladder, choosing the lowest rung that suffices, and estimating each rung's upgrade cost before committing to it.
At station eight you saw an essential function arriving from outside the product. This station generalises the rule: when something is built outside the product at all, and when it is not.
The question answered here is not “can it be done?” — it always can. The question is: at what price, and how much do you pay at every upgrade afterwards?
The ladder — with its upgrade cost
Every client request goes on a rung, and the rule is: choose the lowest rung that suffices.
| Rung | What it is | Its cost | At an upgrade |
|---|---|---|---|
| 1. Standard configuration | A setting that already exists | Hours | Always survives |
| 2. A user-defined field | A field you add to a document or a record | Hours | Survives |
| 3. A formatted search and default values | Fills a field or constrains it with simple logic | Days | Usually survives, and is tested |
| 4. An approval procedure and an alert | Stops a document or notifies a person | Days | Usually survives, and is tested |
| 5. A designed report or document | A query or a print layout | Days | Tested at every upgrade |
| 6. A programmed add-on | Code outside the product | Weeks and upward | Tested and maintained for ever |
Read the last two columns together. The difference between rung two and rung six is not only in the first cost; it is that the first is paid once and the second is paid at every upgrade, indefinitely.
A consultant who jumps to rung six because it is faster to build sells today’s speed at the price of every upgrade after it.
The first four rungs — where more is solved than people expect
User-defined fields add what does not exist as standard — a contract number, a representative, an internal classification — to the document or the record, and they appear in reports like any other field.
A formatted search fills a field or constrains its values with logic you write, and it is the most powerful tool on the ladder relative to its cost: it turns a whole business rule into a short query, with no code outside the product.
Approval procedures hold a document until somebody approves it — a discount above a percentage, a purchase order above an amount. They are where company policy gets written without programming.
The working rule: more than half of what is requested under the name “customisation” is delivered on these four rungs. Anybody fluent in them looks faster than a programmer, and is in truth cheaper rather than faster.
Their limit has to be known: these tools add fields, logic and constraints — they do not change the product’s core behaviour. Anyone trying to build a whole module out of them builds something fragile that is maintained worse than code.
Rung six — and where station two already decided it
Programming on top of this product runs through one of two routes:
The development kit — the traditional route, allowing integration with the data and control of the interface, and it works on both databases.
The service layer with its modern interface — what most modern integration work depends on, and available on the analytical database alone, exactly as set out in the table at station two.
The conclusion to state to a client before signature: the database decision is not an infrastructure decision; it is a decision about what can be connected to this system later. Anyone who chose the lighter database and then asked for modern integration faces a migration project rather than a setting.
A fact that has to be stated: the desktop client
The operational core of this product is still a desktop client running on Windows.
A web client exists, is improving and takes its share of the investment, but the full function set is still in the desktop client as at the date this station was written.
The effect on you as a learner is direct: your training runs on the desktop client, and any promise of full work from a browser or a phone is verified by trial rather than by a brochure.
Its effect on a project is clearer still: a company with half its staff working outside the office asks about this before it asks about the price.
The rule that governs this station
Every customisation is a debt. The debt is not forbidden; it is a price paid knowingly against value that is measured.
Two questions precede any rung above the fourth:
1. What value does this customisation produce? In a sentence the owner of the business would say, not a programmer.
2. Who maintains it in two years? And if the answer is “the partner”, their name and their response time go in the contract — the same logic that governed compliance at station eight.
A request with no clear answer to both is not implemented, and it is documented as not implemented and why. That sheet protects you a year later when somebody asks why the system does not do such a thing.
What you actually do at this station
- Add three fields to a document and a record, and surface them in a report.
- Write a formatted search that fills a field automatically with real logic, not a fixed value.
- Build an approval procedure that stops a document at a threshold, and try to breach it.
- Configure an alert that notifies a person of an event, and confirm it arrived.
- Take five real requests — from your work or from a forum — and place each on a rung with a written reason. That exercise alone separates you from most trainees.
The three commonest errors
One: programming before exhausting the standard tools. The request is delivered in two days and maintained for ten years.
Two: customisation with no documentation. It works, and nobody knows why it exists — so it outlives its reason and is maintained to no purpose.
Three: promising modern integration on a database that does not support it. It is committed in good faith, and discovered in the first technical meeting with the other side.
The limits of customisation and their effect on total cost are set out in the SAP Business One guide.
The acceptance test for this station
- Write the ladder from memory with its six rungs and each rung’s cost at an upgrade.
- Classify five requests onto its rungs with a written reason for each.
- Actually build a field, a formatted search and an approval procedure, and surface them in a report.
- Explain the difference between the two development routes, and which is constrained by the database.
- Write the answer to both questions — the value, and who maintains it — for one customisation request, as you would write it in a scope document.
What comes next
The technical path is finished. The last station turns it into work: certification, a portfolio and a first job — the exam by name, code, duration and pass mark, and the reason a certification alone opens no door on this product in particular.