Case studies

When the webshop and ERP try to own the same inventory

The starting point is familiar: products and orders live in the webshop, while partners, prices and stock movements have to be represented in the business system as well. Manual work may hide the problem while volumes are low. Growth exposes duplicate data, diverging stock states and errors that are difficult to trace.

The solution direction is a Shopify–Dolibarr integration with external identifiers, logging and retryable error handling. The connection alone does not define the process: first, the system of record for prices, tax and inventory must be agreed.

What makes it difficult: a failed synchronisation must not be silently replayed. The team needs to know what was transferred, what was not, who can resolve the discrepancy and how duplicate orders are prevented.

What we can substantiate: integration planning must include ownership, identifiers, logging and error handling. We do not claim a client-specific metric or saving here.

Project work that disappears into task lists

In a service company, projects, tasks, time and invoicing often live in separate spreadsheets or separate mental steps. Management can see that the team is busy, but it is harder to see which project is on plan, how much time is billable and where profitability is slipping.

The implementation direction is to align project, task, time-tracking and invoicing workflows. The goal is not to add administration to every working day, but to capture necessary data once and make it useful later.

The critical point: without process owners and milestones, the system becomes only a more detailed record of uncertainty. Planned and actual effort and billability need to be reviewed together.

What we do not claim: improved profitability does not happen automatically. It depends on process discipline, data quality and actual adoption.

When an ERP implementation starts with too much momentum

A project does not necessarily stall because the software is wrong. An oversized first scope, unclean master data, late integration decisions or users meeting the new system only at the end can each put the launch at risk.

Replanning does not begin with more features. It begins by reducing the first phase, naming process owners, cleaning and test-importing data, then rebuilding the launch with realistic test cases and training.

Why present this honestly? Because we should not call something a success if it was not measured. This is not a client story, but a lesson-based scenario derived from implementation risks. Its lesson is still real: Dolibarr implementation is business change, not just installation.

When everyone knows something different after the order is confirmed

A confirmed order is not enough for workshop or field work. Location, appointment, contact, notes and work stages often arrive in separate e-mails or on paper. The information exists, but not in one reliable place.

A work-order module can create a work order and PDF when the order is validated, with status, notes, appointment details and restricted workshop permissions. The aim is not more data entry, but preventing delivery-critical information from disappearing.

Lesson: ownership and permissions must be designed early. If everyone can change everything, the work order will be no more reliable than paper.

When documents wait for reconciliation in three places

In an accounting office, NAV Online Invoice data, RLB entries, submitted documents and e-mails do not always arrive on the same schedule. Finding missing or unmatched documents can require extensive manual comparison.

The DoliPractice direction uses read-only sources, missing and discrepancy checks, PDF processing and RLB import preparation after approval. It does not make final accounting decisions independently or directly modify external sources.

Lesson: in finance, automation is not valuable because it “books everything by itself”, but because it helps a person see earlier what needs review.

When sending an invoice is not the end of the process

With the NAV Online Invoice connection, a submit button is not enough. Successful, failed, amended and technically invalidated states need to be distinguished, with traceability for each invoice.

The DoliNavSzamla direction combines submission, amendment, technical invalidation, status tracking and transaction logging with the Dolibarr process.

Lesson: an integration is ready only when error states and verification are designed too, not just the first successful submission.

When the same vehicle has two different identities

With multiple vehicles, registration numbers, VINs, odometer readings, statuses and photographs often spread across separate registers. The problem may stay hidden until a service event, cost or responsible person has to be traced.

FleetManager brings vehicle data and related information into one register and prevents duplicate registration numbers and VINs.

Lesson: master-data quality is a feature. A new report cannot repair duplicate or conflicting identifiers; that must be handled at entry.

When every ticket matters but none has an owner

In customer service and operations, an incoming request can disappear among e-mails. Without state, priority, owner, deadline and a response commitment, it is hard to tell what is waiting and what is late.

Smart ticketing and SLA management makes the ticket lifecycle, owner and promised response or resolution time visible.

Lesson: an SLA is not just a deadline field. It works only when there is an owner, priority, notification and a process that makes delay visible.