Development & add-ons
When standard functionality genuinely runs out
Most requests for bespoke SAP Business One development should be refused, because standard configuration already does the job and nobody has looked hard enough. The rest are real — and when they are, the difference between a good build and a bad one is whether you can still upgrade afterwards.
- DI API, UI API and Service Layer
- SQL Server and SAP HANA
- Built to survive version upgrades
The situation
The two ways bespoke development goes wrong
We are usually called in after one of these has already happened, which is why we are blunt about both.
It was built when it did not need to be
A formatted search, an approval procedure or a properly configured document setting would have done it. Instead there is an add-on to maintain, licence and test forever.
It was built straight into the database
Triggers and direct table updates that bypass SAP business logic. It works until the first upgrade, at which point it either breaks or blocks the upgrade entirely.
Nobody wrote down what it does
No specification, no test plan, no handover. The knowledge left with the developer and the business is now afraid to touch it.
It solved the symptom
An add-on to correct data that a validation should have prevented from being entered in the first place.
It cannot be supported
Compiled with no source control, no build process and no deployment package, so even a small change means rebuilding it from scratch.
It multiplied
Six small add-ons from four developers over eight years, overlapping, undocumented, and collectively the reason you are still on an old version.
How we approach it
We try to talk you out of it first
The cheapest development work is the work that turns out to be unnecessary. That conversation costs you a day and can save a five-figure build.
Every development request starts with a look at whether SAP Business One already does it. A surprising amount of what gets specified as bespoke development is a document setting, a formatted search, a user-defined field with a validation, an approval procedure, or an alert. Those are configuration: no code, no licence implication, no upgrade risk, and you can change them yourself later. We will always propose that route first if it exists.
When it does not, we build — but only through supported interfaces. That means the DI API and UI API for add-ons that need to run inside the client, the Service Layer for anything service- or integration-shaped, and user-defined fields, tables and objects for extending the data model. It also means the documented transaction notification procedure for server-side validation, rather than triggers on SAP tables. This is the distinction that decides whether your next upgrade is a weekend or a project.
Everything we build comes with a written specification you sign off, a test plan, source control, a deployment package and documentation. If you later want somebody else to maintain it, you can hand them all of that. We would rather earn the support work than hold it hostage.
What we will not do
- Triggers or direct updates on SAP Business One tables
- Anything that bypasses the DI API business logic layer
- Undocumented builds with no source or deployment package
- Bespoke work that standard configuration already covers
What we build
The work that comes up most often
Data model extensions
User-defined fields, tables and objects with proper validation, so the extra data your business needs lives inside SAP Business One rather than in a side spreadsheet.
Approval workflows
Approval procedures on documents and master data — value thresholds, margin checks, credit limits, purchase authorisation — routed to the right people with an audit trail.
Validation and controls
Server-side validation through the documented transaction notification procedure, stopping bad data at the point of entry instead of correcting it at month-end.
Alerts and automation
Query-driven alerts and scheduled routines for the things people currently remember to check: stock below minimum, overdue accounts, orders stuck at a stage.
Add-ons and screen extensions
DI API and UI API add-ons where a process genuinely needs to live inside the client — new forms, extended screens and bespoke document behaviour.
Service Layer services
OData services over SAP Business One for integrations, portals and mobile use, with authentication, error handling and retry designed in rather than assumed.
Reports and layouts
Crystal Reports layouts and query-based reports written natively for your database, so document printing and management reporting come out of the system itself.
Remediation of existing work
Taking on somebody else’s undocumented add-on: working out what it does, documenting it, and rebuilding the parts that block your next upgrade.
Development lifecycle
How a build actually runs
Small changes compress this; nothing skips it. The specification and the test plan are what make the difference between a build you own and a build you are stuck with.
Discovery
We watch the process being done and establish what the requirement really is, which is often not what the request said.
- Process observation
- Standard-functionality check
- Requirement written back to you
Specification
A functional specification in business language: what it does, what it does not, how it behaves when things go wrong. You sign it off before any code exists.
- Functional specification
- Acceptance criteria
- Fixed quotation
Architecture
Which interface, which data model changes, what it means for licensing, performance and your next upgrade. Written down and explained rather than assumed.
- Interface selection
- Data model design
- Upgrade impact assessment
Development
Built in a separate environment under source control, demonstrated to you in progress rather than revealed at the end.
- Source control
- Development environment
- Progress demonstrations
Testing
Our own testing against the acceptance criteria, including the failure cases: bad data, interruptions, concurrent users, and what happens when the interface is unavailable.
- Functional testing
- Error and edge cases
- Performance under real volumes
User acceptance
Your people test it against the criteria you agreed, on a copy of your own data rather than a demonstration company.
- UAT scripts
- Test on production copy
- Written sign-off
Deployment
A proper deployment package and a planned release, with a rollback route agreed in advance and documentation handed over.
- Deployment package
- Release plan and rollback
- Technical documentation
Support
Ongoing support for what we built, and a re-test of it as part of every future upgrade so it does not quietly become the reason you cannot move.
- Defect support
- Change requests
- Upgrade regression testing
Technical detail
The interfaces we build against
Named specifically, because this is the section a technical reader wants and the one that separates a consultancy from a reseller.
SAP Business One SDK
- DI API for data operations through SAP business logic
- UI API for extending and adding client screens
- Screen Painter forms and form definitions
- Add-on packaging, registration and deployment
- Event handling and menu extension
- C# and .NET development
Service Layer and integration
- Service Layer OData endpoints
- Authentication, sessions and connection handling
- Integration framework (B1if) scenarios
- REST and SOAP interfaces to third-party systems
- Idempotency, retries and failure handling
- Reconciliation and exception reporting
Data model extension
- User-defined fields and user-defined tables
- User-defined objects with their own forms
- Formatted searches and default values
- Transaction notification validation procedures
- Approval procedures and authorisation
- Query-based alerts and scheduling
Database and reporting
- Microsoft SQL Server: T-SQL, stored procedures, views
- SAP HANA: SQLScript, calculation views, modelling
- Query Manager and query-based reports
- Crystal Reports layouts and report design
- Dashboards and management reporting
- Query performance tuning and indexing
Engineering practice
- Source control for every deliverable
- Separate development and test environments
- Written functional and technical specifications
- Documented test plans and UAT scripts
- Versioned, repeatable deployment packages
- Handover documentation you keep
Upgrade safety
- Supported interfaces only, never direct table writes
- Customisation register maintained per client
- Regression testing of bespoke work at each upgrade
- Deprecation review when SAP changes an interface
- Rollback plan for every release
What you get
What a properly engineered extension is worth
An upgrade path you can actually take
Bespoke work built on supported interfaces and re-tested at each upgrade, so your version is a decision rather than a trap.
Bad data stopped at entry
Validation at the point of entry instead of correction at month-end, which is where the real cost of bad data sits.
Process inside the system
Approvals, checks and exceptions handled in SAP Business One with an audit trail, rather than in email threads nobody can reconstruct later.
Work you own
Specification, source, deployment package and documentation handed over, so you are never locked to one developer.
Fewer moving parts
Configuration used wherever it will do the job, so there is less bespoke code to license, test and carry forward.
What to expect
The shape of a development engagement
Configuration change
Hours to a day. Formatted searches, alerts, approval procedures, user-defined fields with validation. Often the answer to what was specified as an add-on.
Small development
Two to ten days. A validation routine, a report, a user-defined object with its own form, a single-purpose automation.
Add-on build
Three to twelve weeks depending on scope, with its own specification, test plan, deployment package and support arrangement.
Integration build
Two to eight weeks per interface. How well the other system is documented matters more than the SAP Business One side.
Remediation
Starts with a fixed-price investigation of what the existing customisation does, because nobody can quote a rebuild honestly before that is known.
Ongoing
Support and change requests for what we built, including regression testing at each upgrade.
Every build is quoted against a signed specification, not an hourly estimate against a conversation. If the specification changes, the quotation changes, and you see that before the work happens.
Fit
Whether this is the right conversation
A good fit if
- Standard SAP Business One does not cover a process that genuinely matters to you
- You have inherited customisations nobody can explain
- An upgrade is blocked by bespoke work and you need to know what it would take
- You need an integration built properly rather than as a scheduled export
- You want validation and approvals inside the system rather than around it
Probably not us if
- You want a developer who will build whatever is asked without challenging it
- You need the work done directly in the database because it is quicker
- You are looking for the cheapest possible build with no specification
Common questions
Questions we are asked before a project starts
Will bespoke development break our next upgrade?
It depends entirely on how it is built. Work done through supported interfaces — the DI API, the UI API, the Service Layer, user-defined fields and tables, formatted searches and the documented transaction notification procedure — carries forward predictably and is re-tested as part of the upgrade. Triggers and direct writes to SAP tables do not, and they are the usual reason a business is stranded on an old version. We only build the former, and we will tell you if something you already have falls into the latter.
Can you take over an add-on somebody else wrote?
Usually, yes, but we start with a fixed-price investigation rather than a quotation. Until we know what the existing code actually does, any estimate to maintain or rebuild it would be a guess. The investigation gives you a written description of what it does, what condition it is in, and the realistic options — which sometimes includes retiring it because standard functionality now covers it.
Do we own the code you write?
Yes. Ownership is set out in the engagement terms, and on handover you receive the source, the deployment package, the specification and the technical documentation. We would rather keep your support work because we are good at it than because you have no alternative.
Should this be an add-on or an integration?
As a rule: if the process has to happen inside the SAP Business One client, in front of a user, at the moment they are working, it is an add-on. If it is about moving data between systems or exposing SAP Business One to something else, it is an integration built on the Service Layer. Getting this wrong is expensive, so it is one of the decisions we settle at the architecture stage and write down.
Do you work on SQL Server or SAP HANA?
Both, and it matters for development. Reporting, stored procedures and validation logic are written differently for each — T-SQL on SQL Server, SQLScript on HANA — and code written for one does not simply move to the other. We write natively for the platform you are on, and if you are planning a move between them we will tell you what would need rewriting.
How do you price development work?
Against a signed functional specification, as a fixed quotation. We do not quote from a conversation, because the estimate would be wrong and you would find out late. If the specification changes during the build, we re-quote the change and you approve it before it is done.
Related
Where to go next
Integration
Connecting SAP Business One to the other systems you run on, so data is entered once.
Read more
Reporting & Analytics
Crystal Reports, query-based reports and dashboards built natively for SQL Server or HANA.
Read more
Support
Ongoing support from the people who built it, including regression testing at upgrade.
Read more
Describe what the system will not do.
Send us the requirement and we will tell you whether it needs building at all. If configuration covers it, we will say so — that conversation has saved clients more than the development would have cost.
Or call +44 7493 619245 — Monday to Friday, 09:00–17:30.