Every distributor that runs SAP Business One for long enough asks for something the standard screens do not do. A field for the customer's own part number. A rule that stops an order going out over the credit limit. A pick list sorted by bin. The good news is that SAP Business One was designed to be extended, and most of these requests can be met without writing a line of code. The bad news is that the wrong kind of change is the most common reason an upgrade turns into a project.
This guide walks through the customization tools in the order we reach for them, and what each one is for.
Start with configuration
Before anything is customized, it is worth checking that the standard product cannot already do it. SAP Business One has a long list of settings that are easy to miss: document settings, general settings, pricing rules, user defaults, alerts and authorizations. A surprising share of "we need a customization" conversations end with a setting that was never switched on.
Configuration is the cheapest change you can make, and it carries across every upgrade with no effort at all.
User-defined fields and tables
User-defined fields (UDFs) add your own data to standard objects: business partners, items, marketing documents, document lines and more. Typical examples in distribution are a customer's own item number, a delivery instruction, a rep assignment, a lot attribute or a route code.
User-defined tables (UDTs) hold data that has no home in the standard objects, such as a list of delivery zones or a rebate schedule. User-defined objects (UDOs) go one step further and give a table its own form, with find, add and update behaviour.
These are created through the product's own tools and are part of the supported data model, so they survive upgrades and can be read by reports, queries and integrations.
Formatted searches
Formatted searches attach behaviour to a field. When a user tabs into the field or changes another one, a query runs and fills it in, offers a list, or validates what was typed. They are the workhorse of practical customization: defaulting a warehouse from the customer, pulling a price from a special table, or refusing a value that breaks a rule.
Because they are built on saved queries, they are visible, documented in the system and easy to change. They do need care when a company moves from Microsoft SQL Server to SAP HANA, since the query syntax differs.
Approval procedures and alerts
Approval procedures stop a document until the right person has looked at it. Common rules for distributors include sales orders over a customer's credit limit, orders with a gross margin below a threshold, discounts beyond a rep's authority and purchase orders above a value.
Alerts send a message when a condition is met, either when a document is created or on a schedule: stock below a minimum, a key account that has not ordered in a month, a delivery that is late.
Both are configured rather than coded. The skill is in the query behind them: a credit check that ignores unposted deliveries, for instance, will approve orders it should stop.
Print layouts and Crystal Reports
The documents your customers and warehouse see are often the most visible part of the system. Invoices, quotes, pick lists, packing slips and statements can all be redesigned, with your branding, your terms and the data people actually need on them.
SAP Business One supports Crystal Reports for both print layouts and reporting. Operational and financial reports built on the real data model are one of the highest-value customizations available, because the numbers are already in the system and only need presenting.
Queries and dashboards
Saved queries give users lists they check every day without exporting to a spreadsheet: open orders by warehouse, overdue accounts by amount, items with no movement in ninety days. Dashboards put the important ones on screen as soon as someone logs in.
When to move to an add-on or a connected app
Some requirements need more than the tools above: their own screens, heavy logic, mobile access, or a process that involves people who never log into SAP Business One. That is when the work moves to an add-on built on the SAP Business One SDK, or to a separate application that talks to SAP Business One through the Service Layer or DI API.
The rule that keeps these upgradeable is simple: use only the supported interfaces. Code that writes directly to the database bypasses SAP Business One's own validation and posting logic, is unsupported, and is the classic cause of corrupted data after an upgrade.
A practical order of operations
When a request comes in, we work down this ladder and stop at the first rung that meets the need:
- A setting in the standard product
- A user-defined field, table or object
- A formatted search, approval procedure or alert
- A print layout, query, report or dashboard
- An add-on or a connected application on supported interfaces
Each rung costs more to build and more to carry through the next upgrade than the one above it. Choosing the lowest one that works is most of the craft.
Will customizations survive an upgrade?
Customizations built with the product's own tools and supported interfaces carry across upgrades. The usual exceptions are queries and reports that use database-specific syntax, and third-party add-ons that need a compatible version. That is why an upgrade should always be rehearsed on a copy of the company first, and why every customization should be documented: what it does, who asked for it and whether it is still used.
If you have inherited customizations nobody can explain, an audit is the right first step. It usually finds a few that matter a great deal, several that nobody uses, and at least one that is quietly causing a problem.
Talk to us about a customization or read more about SAP Business One customization.