SAP Business One · Customization
SAP Business One® customization that survives every upgrade.
User-defined fields, approvals, workflows, forms, print layouts, queries and reports that make SAP Business One® fit the way your company works, without breaking upgrades.
The ladder
Five rungs, and we start at the bottom
Each rung costs more to build and more to carry through every future upgrade. A partner who starts at the top is selling development, not solving a problem.
Before anything is configured, ask whether the requirement exists because of how the business genuinely works, or because the old system forced it.
Typically
- A workaround that survived a system it was built for
- A report that exists because nobody trusted the last one
- A step that only a departed employee understood
At upgrade time
Nothing to carry. Free forever.
Standard SAP Business One settings: document numbering, approval procedures, authorisations, default values, alerts and queries.
Typically
- Approval on a discount over a threshold
- An alert when a batch nears expiry
- A query that answers a recurring question
At upgrade time
Configuration carries across. Nothing to retest beyond the usual.
User-defined fields and tables, formatted searches and validations. The record gains what your business needs it to hold.
Typically
- A field for a customer's own product code
- A table for contract terms SAP Business One does not model
- A search that fills a field from another record
At upgrade time
Carries across, but each addition is another thing to verify after a version change.
Print layouts, SAP Crystal Reports and the screens people spend their day in, so the output matches how you actually trade.
Typically
- An invoice that matches your terms and branding
- A pick list ordered by the route rather than the SKU
- A statement your customers can reconcile
At upgrade time
Layouts usually survive. Reports touching changed tables need checking.
Software that runs alongside SAP Business One, built on the SDK and the supported interfaces, for a process the standard product genuinely does not model.
Typically
- A pricing rule no price list can express
- An industry process with no standard equivalent
- A screen for a role the client was never designed for
At upgrade time
Real work at every upgrade. Worth it only when the rungs above genuinely do not reach.
How we build it
Four rules that decide whether you can upgrade
Heavily customised systems that cannot be upgraded are the most common reason a company ends up trapped on an old version, paying for support on software that stopped improving years ago.
- 01
Nothing writes to tables directly
Every extension uses the supported interfaces, which is what makes an upgrade a scheduled task instead of a crisis.
- 02
Documented as it is built
What it does, why it exists, and who asked for it. In three years the person who knows will have left.
- 03
Tested against a new version first
Before your environment moves, your customisations are run against the new version in a test company.
- 04
Removable
If a customisation stops earning its place, taking it out should not require an archaeology project.
Questions
About customization
Next step
Describe the requirement, not the solution.
Tell us what has to be true for the business. Which rung of the ladder that lands on is our problem, and the answer is often lower than expected.