The code that starts where the standard stops.

Reports, screens and forms

The reports someone opens every morning, the data entry screens, the printed output, the background jobs that run overnight. We shape the development around how the person actually works, designing the screen as part of a workflow rather than as a technical necessity.

Whether an object-oriented or a classic approach fits better is a decision we make by looking at the existing code base and at what the client's team will be able to maintain.

Extending the standard

When you intervene in a standard flow, choosing the right point usually matters more than the code. An intervention made at the wrong point breaks at the first upgrade; one made at the right point goes unnoticed for years.

Any rule that might change goes into a maintainable table rather than into the code. Rules that differ by company, country or product group can then be managed without a developer.

Integration between SAP systems

Moving data between different SAP systems in the same group, between separate legal entities, or between the old and the new system during a transition. Master data synchronisation, document transfer and reconciliation reports are the standard parts of that work.

Every flow we build is traceable: which record went when, which one failed, and how a failure is reprocessed are designed in from the start. A record that disappears silently is the most expensive defect an interface can have.

Integration with non-SAP applications

This is where the centre of gravity sits. We make SAP talk to manufacturing execution systems, laboratory software, warehouse and logistics applications, e-invoicing providers, bank interfaces, e-commerce platforms, reporting tools and whatever the company has built for itself.

Before building the connection we write the contract: which event produces which record, how the fields map, what happens when the other side does not answer, and when a resend is safe. An interface built before those answers exist will stop the business at the first outage.

On the technical side, whether the right route is a service-based connection, a file or folder exchange, a database link or a message queue is decided by what the other system can actually do. Authentication, encryption and logging are always part of the scope.

Data loading and mass processing

Getting data into the system is an engineering problem of its own. In one-off migrations and in nightly loads alike we look for the same three things: validation, handling of partial success, and the ability to re-run from the start.

Rather than loading raw data as it comes, we put it through validation first. Keeping a bad record out is always cheaper than cleaning it up afterwards.

Performance tuning and handover

This is the most frequent request in systems that have run for years: jobs that no longer fit the night window, screens that take minutes to open, reports that slow down as the data grows. We measure before touching the code — tuning without measurement is guesswork.

Whether we wrote the code or inherited it, we leave it in a state another team can maintain. Code review, naming standards and documentation are not an extra service for us; they are the work.