DEV Community: Sanya Mittal

Making Salesforce API Integrations Safe to Retry

Sanya Mittal — Mon, 02 Nov 2026 14:38:03 +0000

An API request times out, but Salesforce may have already processed it. Your integration retries the request, and suddenly the same business transaction appears twice.

This is a common integration-design problem. It becomes harder when multiple workers process the same event or external systems resend requests.

It provides External ID fields and upsert operations to simplify record synchronization. However, upsert alone does not guarantee safe processing under concurrent requests.

In this article, we examine how to design Salesforce integration solutions that handle retries, duplicate events, and concurrent updates. We will use REST API examples and discuss the trade-offs between synchronous requests, queues, and asynchronous processing.

Context and Setup

A typical Crm integration connects an external application with Accounts, Contacts, Orders, or custom objects.

Consider an order-management application sending order updates to it.

Three conditions can create duplicate-write problems:

The external application retries after a network timeout.
Two workers process the same event simultaneously.
A message broker redelivers an event after an acknowledgment failure. It supports External ID-based upsert operations. According to its developer documentation, Bulk API 2.0 is a suitable candidate for operations involving more than 2,000 records.

This provides a useful architectural distinction: small transactional updates and large data synchronization jobs should not necessarily follow the same processing strategy.
Solution: Build Retry-Safe Integrations
The objective is to make repeated delivery of the same business event safe without silently overwriting unrelated updates.

Step 1: Assign a Stable External ID

Every synchronized business record should have a stable identifier originating from the source system.

For example, create an External_Order_Id__c field on the Salesforce Order object.

Configure it as:

External ID: Enabled
Unique: Enabled
Required: Where business rules permit This gives the integration a consistent identifier instead of relying on Salesforce-generated record IDs.

REST API supports PATCH-based upsert using an External ID field. It creates a record when no match exists and updates an existing record when one match exists.

Step 2: Use Upsert Instead of Blind Inserts

The following Node.js example sends an order through the REST API.
async function syncOrder(order, accessToken, instanceUrl) {
// Use the source-system ID to identify the record.
const externalId = encodeURIComponent(order.externalOrderId);

const url =
${instanceUrl}/services/data/vXX.X/sobjects/ +
Order__c/External_Order_Id__c/${externalId};

const response = await fetch(url, {
method: "PATCH",
headers: {
Authorization: Bearer ${accessToken},
"Content-Type": "application/json"
},
body: JSON.stringify({
Status_c: order.status,
Amount_c: order.amount
})
});

// Surface failures instead of silently accepting unsuccessful writes.
if (!response.ok) {
throw new Error(Salesforce sync failed: ${response.status});
}

return response.status;
}

The example assumes authentication and token refresh happen outside the function.

A repeated request with the same External ID targets the same record. However, concurrent requests can still create race conditions or overwrite newer values.

Therefore, record identity and event ordering require separate controls.
Step 3: Control Concurrent Requests
Serialize updates for the same external record when multiple workers can process overlapping events.

A practical architecture uses a queue partitioned by the source-system record ID.
const queues = new Map();

async function processOrderEvent(order, token, instanceUrl) {
const key = order.externalOrderId;

// Keep updates for the same order in sequence.
const previous = queues.get(key) || Promise.resolve();

const current = previous
.catch(() => {}) // Allow later events after a failed request.
.then(() => syncOrder(order, token, instanceUrl));

queues.set(key, current);

try {
return await current;
} finally {
// Remove only the completed queue entry.
if (queues.get(key) === current) {
queues.delete(key);
}
}
}

This example provides in-process serialization, not distributed locking. Multiple application instances need a shared queue or partitioning mechanism.

For higher-volume workloads, consider a durable message queue, retry policies, dead-letter handling, and event-version checks.

The trade-off is operational complexity. Synchronous processing is simpler for low-volume updates. Queues provide better control when event volume and concurrency increase.

Real-World Application

The same integration considerations matter when it supports multiple business processes and external reporting systems.

In our Rise and Shine / ASUAire Salesforce engagement at Oodles, the documented scope included multi-region CRM customization, custom objects, automated sales workflows, and external reporting integrations.

The architecture required consideration of how CRM data would move between operational workflows and connected reporting systems.

Our implementation scope covered CRM customization and integration requirements. The available project documentation does not establish a specific duplicate-request incident or measured API performance improvement. We therefore do not attribute an invented response-time reduction to this project.

For similar integration requirements, Oodles approaches data synchronization by defining record identity, ownership, update behavior, and failure handling before implementation.
Conclusion: Design for Repeated Delivery
Retry handling should be part of the integration architecture, not an afterthought added after production failures.

For integrations, focus on these five engineering decisions:

Use unique External ID fields to identify records across systems.
Prefer upsert over blind inserts for synchronization workflows.
Serialize updates when multiple workers can modify the same record.
Track event versions to prevent older events from overwriting newer data.
Use Bulk API 2.0 for suitable large-volume operations and monitor failed records. A successful API response is not the only measure of integration correctness. The system must also handle retries, concurrency, and partial failures predictably.

Have questions about API integration, retry handling, or synchronization architecture? Contact our Salesforce experts to discuss your implementation requirements. Share your technical questions in the comments as well.

What is an External ID in Salesforce?
An External ID is a field that stores a record identifier from another system. Integrations use it to locate it's records without requiring Salesforce-generated IDs. External IDs support synchronization, upsert operations, and matching records across connected applications.
How does upsert work in Salesforce REST API?
REST API upsert uses an External ID to determine whether a record already exists. It creates a record when no matching record exists and updates the matching record otherwise. Multiple matching records produce an error instead of an update.
How can developers prevent duplicate records in Salesforce integrations?
Developers should use unique External ID fields, upsert operations, and stable source-system identifiers. They should also control concurrent requests for identical records. Distributed integrations need durable event tracking and appropriate retry handling.
When should developers use Salesforce Bulk API 2.0?
Bulk API 2.0 suits large data operations involving thousands of records. It identifies operations exceeding 2,000 records as good candidates. It supports asynchronous insert, update, upsert, query, and delete operations, making it useful for large synchronization workloads.
Does Salesforce upsert guarantee idempotency?
Upsert helps make repeated requests target the same record, but it does not guarantee complete application-level idempotency. Concurrent requests, duplicate external identifiers, and out-of-order updates still require additional controls, such as event versioning and request serialization.

How to Stop Overselling in Inventory Management Software Development (Node.js and PostgreSQL) published: false

Sanya Mittal — Fri, 30 Oct 2026 12:02:18 +0000

Two checkout requests arrive 4 ms apart for the last unit of a SKU. Both read on_hand = 1, both pass the check in application code, and both write. Stock ends at -1 and one customer gets an apology email. This race appears wherever a web store, a marketplace sync, and a warehouse scanner write to the same row, and it grows worse with every added channel or worker process. It is the first bug we design against in inventory management software development for concurrent, multi-writer systems. The fix is small: let PostgreSQL decide the outcome, not your Node.js process.

Context and Setup

The scenario is a Node.js 20 API with pg talking to PostgreSQL 15, serving several channels that reserve stock before payment clears. PostgreSQL is a safe base for this: the 2025 Stack Overflow Developer Survey reports it as the most-used database among professional developers (55.6%).

You need two tables. stock_levels holds sku, location, on_hand, and reserved. reservations holds a unique idempotency_key, qty, status, and expires_at. Available stock is on_hand - reserved, and it must never go below zero.

Reserving Stock Atomically in Inventory Management Software Development

The short answer is one conditional UPDATE guarded by a constraint. Three steps get you there.

Step 1: Make the database refuse negative stock

In Inventory Management Software Development a constraint protects the invariant from every writer, including services that do not exist yet.

Fix any existing rows that violate the rule.
Add the constraint in a migration with a short lock timeout.

-- Why: even buggy code or a manual script cannot oversell past this line
ALTER TABLE stock_levels
  ADD CONSTRAINT available_not_negative CHECK (on_hand - reserved >= 0);

Step 2: Reserve with One Conditional UPDATE in Inventory Management Software Development

Check and write must be one statement. PostgreSQL locks the row during UPDATE, and under READ COMMITTED a waiting transaction re-evaluates the WHERE clause after the lock clears (see the PostgreSQL transaction isolation docs). The second request then matches zero rows.

import pg from "pg";
const pool = new pg.Pool({ connectionString: process.env.DATABASE_URL });

export async function reserve({ key, sku, location, qty, ttlSeconds = 900 }) {
  const db = await pool.connect();
  try {
    await db.query("BEGIN");
    // Why: the unique key turns a client retry into a no-op instead of a double hold
    const hold = await db.query(
      `INSERT INTO reservations (idempotency_key, sku, location, qty, status, expires_at)
       VALUES ($1, $2, $3, $4, 'held', now() + make_interval(secs => $5))
       ON CONFLICT (idempotency_key) DO NOTHING RETURNING id`,
      [key, sku, location, qty, ttlSeconds]
    );
    if (hold.rowCount === 0) { await db.query("ROLLBACK"); return { status: "duplicate" }; }

    // Why: check and write in one statement avoids the read-then-write race
    const upd = await db.query(
      `UPDATE stock_levels SET reserved = reserved + $3
       WHERE sku = $1 AND location = $2 AND on_hand - reserved >= $3`,
      [sku, location, qty]
    );
    if (upd.rowCount === 0) { await db.query("ROLLBACK"); return { status: "insufficient" }; }

    await db.query("COMMIT");
    return { status: "reserved", id: hold.rows[0].id };
  } catch (err) {
    await db.query("ROLLBACK");
    throw err;
  } finally {
    db.release();
  }
}

Step 3: Expire holds and weigh the alternatives

Inventory Management Software Development Abandoned carts must release stock, or reserved drifts upward. Run this worker query every minute.

-- Why: SKIP LOCKED lets several workers run without blocking each other
WITH expired AS (
  SELECT id, sku, location, qty FROM reservations
  WHERE status = 'held' AND expires_at < now()
  FOR UPDATE SKIP LOCKED LIMIT 100
), flipped AS (
  UPDATE reservations r SET status = 'expired'
  FROM expired e WHERE r.id = e.id
  RETURNING e.sku, e.location, e.qty
), totals AS (
  -- Why: UPDATE ... FROM applies only one source row per target row, so sum first
  SELECT sku, location, sum(qty) AS qty FROM flipped GROUP BY sku, location
)
UPDATE stock_levels s SET reserved = s.reserved - t.qty
FROM totals t WHERE s.sku = t.sku AND s.location = t.location;

The trade-offs against other designs:

SELECT ... FOR UPDATE first: correct, but it adds a round trip and holds the lock longer.
Optimistic version column: cheap for cold SKUs, yet hot SKUs burn retries.
Redis counters: fast, but they create a second source of truth that needs reconciliation.

The conditional update serializes writers per row. For a flash-sale SKU, split stock into bucket rows.

Real-World Application

In one of our inventory management software development projects at Oodles

Key Takeaways

In inventory Management Software Development put the invariant in the database with a CHECK constraint, because application checks cannot see concurrent writers.
Collapse check and write into one conditional UPDATE; READ COMMITTED re-evaluates the WHERE clause after a lock wait.
Use an idempotency key so client and queue retries never double-reserve.
Expire holds with FOR UPDATE SKIP LOCKED workers, and sum quantities before updating the parent rows.
Choose Redis or optimistic locking only after measuring contention on hot SKUs.

Questions about reservation design or hot-SKU contention? Drop them in the comments, or reach us about inventory management software development.

What is inventory management software development?
It is the engineering of systems that track stock across locations and channels, reserve units for orders, and keep counts consistent under concurrent writes. Core work covers data models, reservation logic, integrations, and audit trails.

How do you prevent overselling in inventory software?
Combine a database CHECK constraint with a single conditional UPDATE that tests available stock in its WHERE clause. The database serializes competing writers per row, so only requests that fit the remaining quantity succeed.

Should I use Redis or PostgreSQL for stock counts?
In Inventory Management Software Development Use PostgreSQL as the source of truth because it gives transactions, constraints, and audit history. Add Redis only as a read cache or rate limiter, and reconcile it against the database to avoid drift.

Which isolation level do stock updates need?
READ COMMITTED is enough for a conditional UPDATE, because PostgreSQL re-checks the WHERE clause after a lock wait. Use SERIALIZABLE only for multi-row invariants, and be ready to retry on serialization failures.

Why do reservations need idempotency keys?
Clients, queues, and gateways retry failed calls. A unique idempotency key lets the second attempt hit ON CONFLICT DO NOTHING, so one order can never hold stock twice.

How to Make ERP Integration Services Retry-Safe in Node.js

Sanya Mittal — Thu, 29 Oct 2026 08:28:37 +0000

A webhook times out after 30 seconds, so the sender retries. Your handler had already created the sales order in the ERP, so the retry creates a second one. The warehouse then picks the same items twice. This is the most common failure we see when ERP integration services meet unreliable networks: at-least-once delivery on one side, a non-idempotent create endpoint on the other. Here is how ERP integration services handle retries safely in production. We build a small Node.js and PostgreSQL write path that survives duplicate deliveries, process crashes, and ERP outages, then look at how the pattern applies on a live project.

Context and Setup

Idempotency means that applying the same operation twice leaves the system in the same state as applying it once.

Our scenario is a Node.js 20 service that turns storefront webhooks into ERP sales orders. You need PostgreSQL 14 or newer and an ERP endpoint with an external reference field. Postman’s State of the API Report (2025) found that 50.8% of developers cite unauthorized or excessive API calls as their top security concern. The finding centers on AI agents, but an unguarded retry loop creates the same traffic internally.

Fixing Duplicate Writes in ERP Integration Services

The fix has three parts: a deterministic key, an atomic claim, and bounded retries.

Step 1: Build a Deterministic Key for Each ERP Write

A deterministic key comes from the business event, so every retry produces the same value. A random ID per attempt makes each retry look like new work. Combine source system, event ID, and entity version.

ts
import { createHash } from "node:crypto";

export function idempotencyKey(source: string, eventId: string, version: number): string {
// Why: same event, same key, even after a restart
return createHash("sha256").update(${source}:${eventId}:${version}).digest("hex");
}

Step 2: Claim the Key in Postgres Before the ERP Integration Services Call

Claim the key atomically before any ERP write:

Insert the key with ON CONFLICT DO NOTHING.
Read the row status. Return early if it is done.
Call the ERP, passing the key as external_ref.
Mark the row done and store the ERP-assigned ID.
sql
CREATE TABLE erp_write_log (
idem_key text PRIMARY KEY, -- Why: rejects duplicate claims atomically
status text NOT NULL DEFAULT 'pending',
erp_id text
);
ts
export async function handleEvent(evt: OrderEvent) {
const key = idempotencyKey("storefront", evt.id, evt.version);
// Why: avoids a check-then-insert race under concurrent webhooks
await pool.query("INSERT INTO erp_write_log (idem_key) VALUES ($1) ON CONFLICT DO NOTHING", [key]);
const { rows } = await pool.query("SELECT status FROM erp_write_log WHERE idem_key = $1", [key]);
if (rows[0].status === "done") return; // Why: finished writes never rerun
// Why: a crash after the ERP write leaves 'pending'; a unique external_ref makes the retry safe
const created = await postOrder(evt.order, key);
await pool.query("UPDATE erp_write_log SET status = 'done', erp_id = $2 WHERE idem_key = $1", [key, created.id]);
}

Step 3: Retry With Jitter and Know the Trade-Offs

Bounded retries repeat only failures that can succeed later: 5xx and 429. Other 4xx responses mean bad input, so retrying only adds load.

ts
async function postOrder(order: Order, key: string) {
for (let attempt = 0; attempt < 5; attempt++) {
const res = await fetch(${process.env.ERP_URL}/sales-orders, {
method: "POST",
headers: { "content-type": "application/json", "Idempotency-Key": key },
body: JSON.stringify({ ...order, external_ref: key }),
});
if (res.ok) return res.json();
if (res.status < 500 && res.status !== 429) throw new Error(ERP rejected: ${res.status}); // Why: bad input never heals
// Why: full jitter stops workers retrying in lockstep
await new Promise((r) => setTimeout(r, Math.random() * Math.min(30_000, 500 * 2 ** attempt)));
}
throw new Error("ERP unavailable after 5 attempts");
}

Why a key table instead of trusting the ERP alone? Many ERP APIs do not enforce uniqueness on an external reference. If yours does not, look the order up by that field before creating it. Why not broker-level exactly-once delivery? It covers the queue, not the HTTP call to the ERP. The table costs one extra write per event, the price of a guard you control.

Real-World Application

In one of our ERP integration projects at Oodles, we implemented an open-source ERP for a Shanghai-based logistics provider, covering inventory management, order processing, and real-time tracking.

Derive keys from the business event and entity version, never from the request attempt.

Claim keys with ON CONFLICT, because check-then-insert races under concurrent webhooks.

Retry only 5xx and 429 responses, and fail fast on every other 4xx.
Apply full jitter so workers do not hit a recovering ERP in lockstep.

Hit another duplicate-write edge case? Share it in the comments, or talk to us about ERP integration services for a design review.

What are ERP integration services?

ERP integration services connect an ERP to other systems, such as storefronts, CRMs, and warehouse tools, through APIs, middleware, or files. They cover data mapping, sync logic, error handling, and monitoring so records stay consistent across systems.

Why do duplicate records appear in ERP integrations?

In ERP integration services Most webhook senders and queues guarantee at-least-once delivery. If a handler creates a record before acknowledging, any timeout triggers a retry that creates a second record. Without an idempotency key, the ERP cannot tell them apart.

What is an idempotency key?

An idempotency key is a unique value, derived from the business event, sent with each write. The receiver stores it and returns the original result for repeats, so retries cannot create duplicate records.

Should I retry 4xx errors from an ERP API?

No, except 429. A 4xx response usually signals invalid data or missing permissions, which retries cannot fix. Retry 5xx and 429 with exponential backoff and jitter, and send persistent failures to a dead-letter queue.

How long should idempotency keys be stored?

In ERP integration services Store keys longer than your maximum retry window and any sender replay window. Then purge older rows on a schedule, and keep the ERP-assigned ID elsewhere if audits need it.

Optimizing OptaPlanner: 5 Variables to Benchmark Before Production

Sanya Mittal — Tue, 27 Oct 2026 07:33:58 +0000

A scheduling solver can return a valid result and still perform poorly in production. It might leave too many soft constraints unsatisfied, take longer than the planning window allows, or produce inconsistent results as the workload grows.

It helps solve resource-allocation problems such as employee rostering, vehicle routing, and production scheduling. The challenge is choosing a solver configuration that works for your actual workload, not just a small development dataset.

Before deploying a scheduling engine, benchmark these five variables using representative inputs. This is especially important when planning decisions must meet operational deadlines. Teams evaluating OptaPlanner scheduling solutions should measure solution quality and execution cost together, rather than treating speed as the only success criterion.

Context and Setup

It uses planning entities, variables, and constraints to model a problem and search for better solutions. Hard constraints represent rules that must not be broken, while soft constraints express preferences that should be optimized.

For example, a factory scheduler might need to assign jobs to machines while respecting machine capacity, delivery deadlines, setup requirements, and operator availability.

OptaPlanner's official documentation, under "Score calculation performance tricks," notes that score calculation speed is normally above 1,000 calculations per second for many high-scale datasets, except when using an EasyScoreCalculator. This is a useful diagnostic reference, not a universal performance guarantee. Dataset complexity and constraint design influence the result.

OptaPlanner: 5 Variables to Benchmark

Step 1: Measure solution quality

Start by measuring whether the solver produces operationally acceptable schedules.

Record the final score and its hard and soft components.
Check hard-constraint violations independently.
Compare soft-constraint penalties against an agreed baseline.
Repeat the test with realistic and difficult datasets.

A higher score is useful only when the score definition accurately represents business priorities. A missing constraint can make an apparently excellent solution operationally invalid.

Step 2: Measure score-calculation speed

Score calculation is performed repeatedly during the search. Inefficient joins, unnecessary matching, and expensive custom calculations can consume time that would otherwise be spent exploring better solutions.

For example, a Constraint Streams rule can penalize overlapping assignments:

private Constraint overlappingShifts(
        ConstraintFactory factory) {
    return factory.forEach(Shift.class)
        .join(Shift.class,
            Joiners.equal(Shift::getEmployee),
            Joiners.lessThan(Shift::getStart))
        .filter((a, b) ->
            a.getEnd().isAfter(b.getStart()))
        .penalize(HardSoftScore.ONE_HARD)
        .asConstraint("Overlapping shifts");
        // Why: penalizes overlapping assignments for one employee.
}

This example assumes that Shift exposes the shown properties and that both shifts have assigned employees. Production code should also account for unassigned shifts and ensure each overlapping pair is counted only once. The exact temporal model should match the application's scheduling rules.

Measure calculation speed using the solver's logs and compare equivalent datasets. Do not optimize this metric in isolation: faster scoring does not automatically produce a better final schedule.

Step 3: Increase dataset size gradually

A solver configuration that performs well with 50 jobs may behave differently with 500 or 5,000 jobs.

Create small, medium, and large representative datasets.
Keep constraint definitions and test conditions consistent.
Record score quality and solve duration at each scale.
Investigate nonlinear growth before increasing production capacity.

Include difficult cases, not just larger copies of an easy dataset. Tight deadlines, scarce resources, and conflicting requirements can change the search difficulty substantially.

Step 4: Tune the solve-time limit

Set the solver's termination limit according to the business deadline. A warehouse schedule needed within seconds has different requirements from a production plan that can run overnight.

Use OptaPlanner's benchmarking facilities to compare configurations against the same input scenarios. Evaluate both the best score reached within the time limit and how quickly the solver improves that score.

A longer run may improve solution quality, but the improvement must justify the extra compute time. Establish an acceptance threshold before selecting a configuration.

Step 5: Check consistency across runs

Heuristics can produce different schedules across runs, depending on configuration, randomization, and search behavior.

Run each candidate configuration several times.
Record score, duration, and hard-constraint validity.
Compare median results and worst observed outcomes.
Document the random seed and termination settings.

This is important when operations teams expect predictable planning quality. A configuration with a strong best-case result but unreliable typical performance may be a poor production choice.

Real-World Application

For an Oodles scheduling project, the useful case study is one that connects solver tuning to an operational result. The project evidence should identify the scheduling system, its bottleneck, the optimization approach, and a measured outcome.

A publishable case study needs verified details such as:

System: [Verified scheduling use case]
Problem: [Measured baseline bottleneck]
Approach: Benchmarking, constraint analysis, and configuration tuning.
Result: [Verified change in solve time or solution quality]
Conditions: Dataset size, hardware, solver configuration, and measurement period.

These metrics should come from actual project records before publication. Oodles' broader engineering work is described on the Oodles website.

Key Takeaways

Measure solution quality and execution time together.
Validate hard constraints before comparing soft scores.
Benchmark with realistic datasets at multiple scales.
Tune termination limits against operational deadlines.
Repeat tests to understand consistency and worst-case behavior.

What is OptaPlanner used for?

It is a Java constraint-solving engine used for planning problems such as employee scheduling, vehicle routing, production planning, and timetabling. It searches for solutions that satisfy hard constraints while optimizing soft constraints.

How do I improve OptaPlanner performance?

Start by profiling score calculation, reviewing expensive Constraint Streams operations, and testing representative datasets. Then compare solver configurations under consistent termination limits. Measure solution quality as well as execution speed before adopting a change.

What is a hard constraint in OptaPlanner?

A hard constraint represents a rule that a valid solution must satisfy, such as preventing one employee from working overlapping shifts. A soft constraint represents a preference, such as reducing undesirable shift assignments.

Why should I benchmark different solver configurations?

Different configurations can behave differently across problem sizes and constraint patterns. Benchmarking helps determine which configuration provides the best balance between solution quality, solve duration, and consistency for your workload.

When should I review an OptaPlanner implementation?

Review it when planning duration increases, workloads grow, business rules change, or solution quality falls below operational expectations. Teams can discuss an OptaPlanner implementation with Oodles when they need help assessing these issues.

ERP Consulting Services: Test Partial Receipts in AL

Sanya Mittal — Mon, 19 Oct 2026 09:16:02 +0000

Partial receipts are a small business rule with consequences across purchasing, inventory, and accounts payable. In Microsoft Dynamics 365 Business Central, a quantity-validation mistake can allow an extension to calculate the wrong remaining quantity or reject a legitimate receipt. ERP consulting services need to define that behavior before developers implement it. In this walkthrough, we will encode a simple receipt rule in AL and test its expected outcomes.

Prerequisites

ERP consulting services for Microsoft Dynamics 365 Business Central development sandbox.
Visual Studio Code with the Microsoft AL Language extension.
An AL project targeting Business Central runtime 15.0 or later.
An available object ID range for your extension.
A test environment where you can compile and execute test codeunits.

The example uses core AL language features and does not require an external library. Microsoft documents the test-codeunit model in its official AL testing guide.

Why the obvious approach fails

A common mistake is to treat receipt validation as a single subtraction operation. The arithmetic is correct, but the business rule is incomplete.

Consider this fragment:

RemainingQty := OrderedQty - ReceivedQty;

This is a fragment, not a complete AL object. It assumes both quantities are valid and that the receipt cannot exceed the order quantity.

If OrderedQty is 10 and ReceivedQty is 12, the result is -2. The calculation has no knowledge of whether that outcome is permitted by the business process.

The opposite mistake is rejecting every receipt that differs from the ordered quantity. That prevents legitimate partial deliveries.

The first consulting decision is therefore not which function to write. It is defining the allowed states: zero receipt, partial receipt, full receipt, negative quantities, and over-receipt. Those states become our acceptance criteria.

Step 1: Put the quantity rule in one codeunit

We will separate the calculation from the page or posting workflow. This keeps the rule independently testable and prevents multiple UI entry points from implementing different versions.

Create a file named ReceiptQtyRules.Codeunit.al:

codeunit 50100 "Receipt Qty Rules"
{
    procedure GetRemainingQty(
        OrderedQty: Decimal;
        ReceivedQty: Decimal
    ): Decimal
    begin
        if OrderedQty < 0 then
            Error('Ordered quantity cannot be negative.');

        if ReceivedQty < 0 then
            Error('Received quantity cannot be negative.');

        if ReceivedQty > OrderedQty then
            Error('Received quantity cannot exceed ordered quantity.');

        exit(OrderedQty - ReceivedQty);
    end;
}

This codeunit defines a specific policy: receipts can be partial, but negative quantities and quantities above the ordered amount are invalid. Confirm that policy with the business owner before connecting it to an actual posting process.

Step 2: Turn the business rules into automated tests

A successful compilation proves that the code is syntactically valid. It does not prove that the rule handles the business cases correctly.

Create a separate test codeunit named ReceiptQtyRulesTests.Codeunit.al. The tests below cover a partial receipt, a complete receipt, and an untouched order.

codeunit 50101 "Receipt Qty Rules Tests"
{
    Subtype = Test;

    [Test]
    procedure PartialReceiptReturnsRemainingQty()
    var
        ReceiptRules: Codeunit "Receipt Qty Rules";
    begin
        if ReceiptRules.GetRemainingQty(10, 4) <> 6 then
            Error('Partial receipt returned an incorrect quantity.');
    end;

    [Test]
    procedure FullReceiptReturnsZero()
    var
        ReceiptRules: Codeunit "Receipt Qty Rules";
    begin
        if ReceiptRules.GetRemainingQty(10, 10) <> 0 then
            Error('Full receipt should leave zero quantity.');
    end;

    [Test]
    procedure ZeroReceiptReturnsOrderedQty()
    var
        ReceiptRules: Codeunit "Receipt Qty Rules";
    begin
        if ReceiptRules.GetRemainingQty(10, 0) <> 10 then
            Error('Zero receipt should leave ordered quantity.');
    end;
}

Each test fails when its expected result does not match the returned value. The tests exercise the business rule directly, without requiring a purchase order page or a warehouse workflow.

Step 3: Verify the rejection paths

The first three tests cover valid quantities. We must also verify that invalid inputs trigger errors rather than silently returning negative balances.

In ERP consulting services Business Central test codeunits support error assertions through the test framework. For this small example, you can add a dedicated error-handling test using the appropriate assertion codeunit available in your project's test dependencies. Confirm the exact assertion API and dependency version before adding it.

At minimum, manually verify these cases in the development sandbox:

Ordered	Received	Expected behavior
10	4	Remaining quantity is 6
10	10	Remaining quantity is 0
10	0	Remaining quantity is 10
10	12	Reject the receipt
10	-1	Reject the receipt
-1	0	Reject the order quantity

The table is the acceptance matrix, not a substitute for automated negative-path tests. The over-receipt rule may differ when a business explicitly permits over-delivery within a defined tolerance.

Step 4: Compile and execute the tests

Compile the extension in Visual Studio Code using the AL development workflow. Then run the test codeunit in a Business Central sandbox with the test runner and test dependencies configured.

The expected result is three passing tests. If a test fails, inspect the actual quantity and the error message before changing the implementation. Do not weaken an assertion to make a build pass without checking the intended business rule.

For continuous integration, compile the extension and execute its test suite before promoting the package to another environment. The exact command depends on the installed AL tooling and Business Central environment. Pin the tool version in your pipeline rather than assuming every developer uses the same release.

Trade-offs and limitations

The example is intentionally small. It isolates one quantity rule, but it does not implement a complete purchasing or warehouse process.

First, a receipt quantity is not always the same as the quantity invoiced or the quantity physically available. Business Central's posting workflow, unit-of-measure conversions, and warehouse handling may impose additional rules. A helper function cannot replace validation against those records.

Second, some businesses allow over-receipts within a tolerance. The example rejects every quantity above the ordered amount, so that policy would require an explicit tolerance rule and additional tests.

Third, the example does not prevent concurrent processes from changing the underlying order. A real posting operation must use the platform's established transaction and validation behavior rather than trusting a previously calculated remaining quantity.

Finally, a passing unit test does not prove that a complete purchase receipt posts correctly. Integration tests must verify the relevant records, posting behavior, inventory effects, and financial consequences.

At Oodles, we connect business requirements with practical software engineering decisions to help teams define, build, and test ERP extensions.

Real-world application: From consulting scope to testable AL rules

We implemented this principle in a Business Central project for a logistics client, where the agreed delivery scope included approximately 62 AL extensions over an 18-week plan.

The delivery plan used two-week sprints with separate development, quality assurance, and project management responsibilities. That scope required more than listing extensions. Each extension needed a defined purpose, an agreed boundary, and a testable outcome.

For a receipt-related requirement, that means documenting what happens when a shipment arrives partially, exceeds the expected quantity, or conflicts with the purchase order. The acceptance criteria must distinguish valid exceptions from errors before development begins.

The ERP consulting services documented project scope provides two verified planning figures: approximately 62 extensions and 18 weeks. We do not have a verified defect reduction, processing-time improvement, or cost saving to report.

This is where ERP consulting services connect business analysis to engineering. A clear requirement gives developers a rule to implement and testers a condition to verify. It also gives stakeholders a basis for deciding whether a requested behavior belongs in the original scope or requires an approved change.

Our ERP Consulting Services explains the broader context of building ERP solutions around business requirements. The same discipline applies whether an extension changes purchasing, inventory, or financial workflows.

Key takeaways

Define valid business states before implementing quantity calculations.
Keep reusable business rules separate from page and posting workflows.
Test partial, complete, zero, and invalid receipt quantities.
Confirm over-receipt policy with the business owner before enforcing a hard limit.
Treat unit tests as one layer of validation, not proof of end-to-end posting correctness.
Require measurable acceptance criteria for every material ERP extension.

If you have encountered an AL testing edge case around partial receipts, posting validation, or warehouse quantities, share the scenario and expected behavior. Comparing those cases is a useful way to improve acceptance criteria before the next release.

Should partial receipt validation run on the page or in a codeunit?

A reusable business rule belongs in a testable codeunit or an appropriate existing business-logic component. Page-level validation can improve user feedback, but it should not be the only protection for a rule that must hold across multiple entry points.

In ERP Consulting Services Can Business Central allow receipt quantities above the ordered amount?

ERP consulting services that depends on the configured process and the applicable business rules. If over-receipts are permitted, define the tolerance and test the boundary values. Do not copy the strict rejection rule into a process that explicitly permits controlled over-delivery.

Why does a passing AL unit test not guarantee successful posting?

A unit test verifies the specific logic it executes. Actual posting may involve inventory entries, warehouse records, permissions, and other validations. Use integration tests in a sandbox to verify those interactions.

Should receipt rules be duplicated across extensions?

Avoid duplicating the same business rule when a shared component or standard Business Central behavior can enforce it appropriately. However, reuse must respect the application's extension boundaries and posting events. Review the actual dependencies before extracting a common component.

In ERP Consulting Services How should developers test an ERP extension after a platform update?

Compile against the target platform's supported symbols, rerun automated tests, and exercise critical business workflows in a sandbox. Also review changed APIs and dependencies. Pin tooling and runtime versions so the test results are reproducible.

How to Build an Inventory Management Solution That Prevents Stock Drift

Sanya Mittal — Thu, 15 Oct 2026 05:21:43 +0000

A warehouse dashboard can show 120 units available while the picking team finds only 93. The discrepancy may come from delayed order reservations, duplicate webhook events, unrecorded returns, or concurrent updates from multiple sales channels. The result is overselling, failed fulfilment, and replenishment decisions based on incorrect data.

An Inventory Management Solution needs to do more than store stock quantities. It must preserve consistency across receiving, picking, order allocation, returns, and stock adjustments, even when multiple services update inventory simultaneously.

The architectural challenge is deciding which component owns the stock balance, how transactions are applied, and how failed integrations recover without creating duplicate movements. In this guide, we will design a practical inventory workflow using Node.js, PostgreSQL, and asynchronous messaging. For broader warehouse architecture considerations, explore inventory and warehouse management solutions.

Context and Setup

An Inventory Management Solution typically receives updates from e-commerce applications, ERP systems, warehouse management software, and third-party logistics providers. Each system may report a different event, but the inventory service must maintain one consistent view of available stock.

Consider a SKU with 100 units on hand and 15 units already reserved for unfulfilled orders.

The system should calculate:

On-hand quantity: 100 units physically recorded in stock.
Reserved quantity: 15 units allocated to existing orders.
Available quantity: 85 units eligible for new allocations.

A common implementation mistake is storing only a single mutable quantity. Without reservation tracking and transaction history, it becomes difficult to explain why stock changed or safely reverse an operation.

Research published in Management Science by DeHoratius and Raman in 2008 examined nearly 370,000 inventory records across 37 stores of one retailer. The researchers found that 65% of the records were inaccurate. This historical study demonstrates why inventory accuracy must be supported by operational controls rather than assumed from database values alone.

Prerequisites

The example assumes:

Node.js with an asynchronous PostgreSQL driver.
PostgreSQL tables for stock balances, reservations, and inventory movements.
A stable order identifier for deduplicating incoming events.
Database transactions and row-level locking.
A background worker for retrying failed downstream notifications.

Designing an Inventory Management Solution With Transaction Safety

The central design principle is to treat inventory changes as transactions, not independent quantity updates.

Step 1: Define the Inventory Data Model

Store physical stock, reservations, and movement history separately. This provides an auditable record of receiving, dispatches, returns, and adjustments.

A simplified schema could contain:

inventory_balance: SKU, warehouse, on-hand quantity, reserved quantity, version.
inventory_reservation: order ID, SKU, quantity, reservation status.
inventory_movement: movement ID, SKU, quantity delta, reason, reference ID, timestamp.
processed_events: event ID and processing status.

Use a composite key on (sku, warehouse_id) to prevent multiple balance records for the same product and location.

The movement table should be append-only for normal operations. Corrections should create compensating movements instead of silently rewriting historical transactions.

Step 2: Apply Stock Changes Atomically

A stock check followed by an independent update creates a race condition. Two checkout requests could both read the same available quantity and reserve more stock than exists.

The following PostgreSQL statement performs a conditional reservation. It assumes inventory_balance contains the SKU's current on-hand and reserved quantities.

-- Why: update only when sufficient unreserved stock exists.
UPDATE inventory_balance
SET reserved_qty = reserved_qty + $1,
    version = version + 1
WHERE sku = $2
  AND warehouse_id = $3
  AND on_hand_qty - reserved_qty >= $1
RETURNING sku, on_hand_qty, reserved_qty, version;
-- No returned row means the reservation was rejected.

Execute this statement inside a database transaction alongside reservation creation, event deduplication, and movement recording. Commit all changes together or roll them back.

The application must also validate that the requested quantity is positive and that the event has not already been processed.

Step 3: Make Event Processing Idempotent

Payment confirmations, order cancellations, and shipping notifications can be delivered more than once. An idempotent consumer ensures that replaying the same event does not apply the same inventory movement twice.

Use a unique constraint on the event identifier and insert the deduplication record within the same database transaction as the stock update.

async function reserveInventory(db, event) {
  const client = await db.connect();

  try {
    await client.query("BEGIN");

    // Why: a unique event ID prevents duplicate processing.
    const result = await client.query(
      `INSERT INTO processed_events (event_id)
       VALUES ($1)
       ON CONFLICT (event_id) DO NOTHING
       RETURNING event_id`,
      [event.id]
    );

    if (result.rowCount === 0) {
      await client.query("ROLLBACK");
      return { duplicate: true };
    }

    // Why: the conditional update prevents overselling.
    const stock = await client.query(
      `UPDATE inventory_balance
       SET reserved_qty = reserved_qty + $1,
           version = version + 1
       WHERE sku = $2
         AND warehouse_id = $3
         AND on_hand_qty - reserved_qty >= $1
       RETURNING sku`,
      [event.quantity, event.sku, event.warehouseId]
    );

    if (stock.rowCount === 0) {
      throw new Error("Insufficient stock");
    }

    // Persist the reservation and movement here,
    // using the same transaction and client.
    await client.query("COMMIT");
    return { reserved: true };
  } catch (error) {
    await client.query("ROLLBACK");
    throw error; // Let the caller retry or handle rejection.
  } finally {
    client.release();
  }
}

This is a simplified reservation example, not a complete production service. Production code must validate payloads, handle database connection failures, distinguish permanent business rejections from transient errors, and ensure reservation and movement records are committed in the same transaction.

Step 4: Separate Database Commits From External Notifications

Do not call a shipping API or publish a message while holding a database transaction open. External requests can time out after the remote service has already processed them.

Instead, use the transactional outbox pattern:

Save the inventory changes and an outbox event in one database transaction.
Let a background worker publish committed outbox events.
Retry transient failures with exponential backoff.
Deduplicate messages at the receiving service.
Monitor outbox age, retry counts, and dead-letter events.

A direct message publish after a database commit is simpler, but a process crash between those operations can lose the notification. The outbox adds storage and worker complexity while making recovery more reliable.

Real-World Application

At Oodles, an inventory implementation should begin by identifying where stock is created, reserved, consumed, and reconciled across connected systems. The appropriate design depends on the existing ERP, warehouse workflows, transaction volume, and integration contracts.

For example, consider a multi-channel retail workflow in which orders arrive through an online store while warehouse staff receive and dispatch stock through a separate system. A suitable implementation would centralize inventory movements, use transactional reservations, deduplicate inbound events, and reconcile warehouse quantities against system balances.

Measure the outcome using baseline and post-deployment data rather than assuming a performance improvement. Useful indicators include reservation failure rate, duplicate movement count, inventory record accuracy, API latency at the 95th percentile, and the time required to recover failed messages.

No verified Oodles project metrics were supplied for this article, so specific before-and-after improvements should be reported only after they have been measured in an actual deployment. You can explore Oodles for more information about its Inventory Management Solution software engineering and integration services.

Conclusion: Key Takeaways

Separate stock concepts: Track on-hand, reserved, and available quantities independently.
Enforce consistency in the database: Use conditional updates, transactions, and appropriate constraints.
Design for duplicate delivery: Make event processing idempotent using stable event identifiers.
Recover from integration failures: Use a transactional outbox, retries, and dead-letter handling.
Measure operational correctness: Track inventory discrepancies, reservation failures, and recovery times.

1. What is an Inventory Management Solution?

An Inventory Management Solution is software that tracks stock quantities, reservations, receipts, transfers, dispatches, and adjustments across warehouses or sales channels. It helps businesses maintain accurate stock records and coordinate replenishment and order fulfilment.

2. How do you prevent overselling in an inventory system?

Inventory Management Solution Prevent overselling by checking available stock and updating reservations atomically within a database transaction. Use conditional SQL updates or row-level locking, enforce quantity constraints, and ensure concurrent requests cannot reserve more units than are available.

3. Should inventory updates use synchronous APIs or message queues?

Synchronous APIs are useful when an operation requires an immediate reservation decision. Message queues are suitable for downstream notifications, warehouse events, and asynchronous integrations. A transactional outbox can connect committed database changes to reliable event publication.

4. How does an Inventory Management Solution handle duplicate webhooks?

It stores a stable event identifier under a unique database constraint and processes that event within the same transaction as the inventory changes. If the event has already been committed, the consumer skips the duplicate instead of applying the stock movement again.

5. Which metrics should developers monitor in inventory software?

Developers should monitor inventory record accuracy, reservation rejection rates, duplicate event counts, API latency, outbox processing delays, and failed-message retries. These metrics reveal whether the system maintains correct stock balances and recovers effectively from integration failures.

Let's Discuss Your Inventory Architecture

How does your current system handle concurrent reservations, duplicate order events, or inventory reconciliation across warehouses? Share your implementation challenges and questions in the comments.

If you are planning an Inventory Management Solution, discuss your requirements with the Oodles team, including your existing ERP, warehouse workflows, integration points, and consistency requirements.

QuickBooks Implementation Services: Fix Webhook Retries

Sanya Mittal — Mon, 12 Oct 2026 10:29:12 +0000

Quickbooks Implementation Services involve more than connecting an accounting application to another system. A QuickBooks Online webhook can arrive twice, arrive late, or never reach your application. If your integration treats every notification as a new accounting command, retries can trigger duplicate work or leave financial records stale.

For developers building accounting integrations, the difficult part is recovering the correct entity state when notifications are duplicated, missed, or delivered out of order. In this walkthrough, we will build a retry-safe reconciliation worker using Node.js and examine where the approach breaks.

Prerequisites

Node.js 22.12.0
A QuickBooks Online developer application and sandbox company for live integration testing
Familiarity with webhooks, asynchronous processing, and JSON
A persistent queue and database for production deployment

Why QuickBooks Webhook Handlers Fail

Quickbooks Implementation Services often require integrations to handle repeated notifications safely. A basic webhook handler receives a notification and immediately updates a local record. This assumes delivery occurs once and follows chronological order.

Intuit documents webhook retries when notifications are not acknowledged successfully. Its webhook guidance also recommends asynchronous processing because the endpoint has limited time to respond.

Consider this failure sequence:

10:00:00  Invoice notification received
10:00:03  Handler times out before acknowledgement
10:00:10  QuickBooks retries the notification
10:00:11  Both workers process the same invoice

A database uniqueness constraint may prevent duplicate records, but it cannot prevent repeated emails, exports, or external side effects. Reliable accounting synchronization needs both duplicate protection and a recovery mechanism.

Step 1: Acknowledge Webhooks Quickly

Quickbooks Implementation Services should separate notification delivery from expensive reconciliation work. Verify the incoming notification, persist the required work, and acknowledge it without waiting for several downstream API calls.

Use a durable queue rather than relying on an in-memory task. This lets workers resume processing after a restart and reduces the chance of losing accepted work.

Step 2: Coalesce Duplicate Notifications

Quickbooks Implementation Services benefit from entity-level coalescing when the application needs the latest accounting state rather than every intermediate event. Notifications for the same company and entity can share one pending refresh.

Create reconcile.mjs:

const queue = new Map();

function enqueue(notification) {
  const key = [
    notification.realmId,
    notification.name,
    notification.id
  ].join(":");

  const previous = queue.get(key);

  if (
    !previous ||
    Date.parse(notification.lastUpdated) >
      Date.parse(previous.lastUpdated)
  ) {
    queue.set(key, notification);
  }
}

async function reconcile(notification) {
  console.log(
    `Refresh ${notification.name} ${notification.id}`
  );
}

async function flushQueue() {
  const pending = [...queue.values()];
  queue.clear();

  for (const notification of pending) {
    await reconcile(notification);
  }
}

enqueue({
  realmId: "sandbox-1",
  name: "Invoice",
  id: "42",
  lastUpdated: "2026-10-12T10:00:00Z"
});

enqueue({
  realmId: "sandbox-1",
  name: "Invoice",
  id: "42",
  lastUpdated: "2026-10-12T10:01:00Z"
});

await flushQueue();

Run the example with node reconcile.mjs. Expected output:

Refresh Invoice 42

Both notifications produce one refresh. This example demonstrates coalescing, not durable processing, because the map disappears when the process exits.

Step 3: Fetch the Latest Accounting State

Quickbooks Implementation Services should treat webhook notifications as change signals, not as a complete and ordered ledger of entity changes. The reconciliation worker should retrieve the current entity through the supported QuickBooks Online API.

For updates, Quickbooks Implementation Services entities expose a SyncToken used for optimistic concurrency. Before updating an entity, retrieve its current state and use the appropriate token.

Your integration must also handle deleted records, unsupported entity operations, and conflicts. Do not assume every notification represents an ordinary update.

Step 4: Recover Missed Changes with CDC

Quickbooks Implementation Services need a recovery path for notifications that never reach the application. Intuit's Change Data Capture (CDC) functionality lets integrations retrieve changes for supported entities over a specified period.

Maintain a durable checkpoint for each company and relevant entity scope. Reconcile returned changes, then advance the checkpoint only after processing succeeds.

Advancing a checkpoint before persisting the changes can create permanent gaps. Keeping the checkpoint unchanged after successful processing can repeat work, so reconciliation must remain safe to repeat.

Testing and Verification

Quickbooks Implementation Services should include failure testing before production deployment. A successful demonstration with two notifications does not prove that the integration survives worker crashes or concurrent updates.

Test these cases in a QuickBooks sandbox:

Send the same notification twice and verify one pending refresh.
Send notifications with different timestamps and verify the newest timestamp remains queued.
Crash a worker after queue persistence and verify the job resumes.
Interrupt CDC recovery and verify the checkpoint does not skip unprocessed changes.
Submit an update using a stale SyncToken and verify conflict handling.

Track notification identifiers, company IDs, entity types, retry counts, and reconciliation results. Never log OAuth access tokens or other credentials.

Trade-Offs and Limitations

Quickbooks Implementation Services must account for the limitations of entity-level coalescing. It reduces redundant refreshes but does not preserve every intermediate state. If your application needs every business event for auditing, retain a durable event log and use an idempotent consumer.

A second limitation is concurrency. An in-memory map cannot coordinate multiple application instances or survive restarts. Production systems need persistent queue storage, atomic job claims, and recovery for abandoned work.

Finally, API limits and temporary failures can delay synchronization. Use bounded retries, backoff, dead-letter handling, and alerts for unresolved accounting records.

At Oodles, implementation decisions should be tied to the actual integration architecture and its acceptance criteria. The code in this article remains an illustrative demonstration until validated against the production requirements.

Key Takeaways

Treat webhooks as change notifications rather than an ordered accounting ledger.
Acknowledge notifications promptly and move expensive processing into a durable queue.
Coalesce duplicate notifications without suppressing legitimate updates.
Reconcile current state and use CDC to recover missed changes.
Persist checkpoints and test crash recovery before launch.
Measure accounting accuracy and reconciliation exceptions rather than deployment completion alone.

If you are building a QuickBooks integration, share how you handle missed notifications and reconciliation checkpoints. Our QuickBooks integration services page provides additional context on accounting integrations.

Should every QuickBooks webhook create a database record?

Not necessarily. If your application needs the latest entity state, coalescing notifications by company and entity can reduce redundant refreshes. If every intermediate event matters for auditing or business processing, retain a durable event log.

Can QuickBooks webhook notifications arrive out of order?

Yes. Intuit warns that notification ordering is not guaranteed. Reconcile against the latest authoritative entity state instead of applying notifications blindly in arrival order.

Is an in-memory queue suitable for production?

No, not when processing must survive crashes or coordinate multiple instances. Use persistent queue storage or a database-backed work table, along with retries and monitoring for abandoned work.

How should an integration handle a stale SyncToken?

Fetch the current entity state and resolve the conflict before retrying the update. Do not repeatedly submit the same stale token. Verify the conflict response against the current API documentation for the specific entity.

When should an integration use CDC?

CDC provides a recovery path for changes that webhooks missed or the application failed to process. Use durable checkpoints, reconcile the returned changes, and verify that recovery does not skip unprocessed records.

How to Build Reliable Zoho Integration Services with Node.js

Sanya Mittal — Tue, 06 Oct 2026 05:20:01 +0000

An implementation guide for webhook ingestion, idempotency, API limits, and failure recovery.

A Zoho webhook can trigger the right workflow and still create duplicate records or incomplete transactions. This happens when a Node.js integration treats every webhook as a new event instead of handling retries and repeated deliveries.

This guide explains a practical pattern for building Zoho Integration services around webhook ingestion, idempotency, API limits, and controlled retries. We will use Node.js, Express, PostgreSQL, and Redis in the reference architecture.

For broader implementation patterns, see how Zoho Integration services connect enterprise applications.

Context and Setup

The system receives events from Zoho CRM and updates an external application. A typical flow looks like this:

Zoho CRM
   |
   | Webhook
   v
Node.js API
   |
   +--> Redis: idempotency check
   |
   +--> PostgreSQL: event state
   |
   v
External API

Zoho Integration services supports webhooks for sending event notifications to third-party applications. Its documentation also states that a failed webhook can trigger another notification after 15 minutes. This makes duplicate-safe processing important.

Zoho's APIs also impose request limits. For example, Zoho Books documents a limit of 100 requests per minute per organization. It returns HTTP 429 when the rate limit is exceeded.

That means the integration needs more than an HTTP endpoint. It needs state management.

Building Zoho Integration Services with Idempotent Webhooks

The solution is to separate webhook acceptance from business processing. The endpoint should validate the request, record the event, and prevent the same event from executing twice.

Step 1: Validate and acknowledge the webhook

Do not perform several downstream API calls before returning from the webhook endpoint.

First, validate the request and identify the event.

For custom webhook authentication, we can configure a shared secret in Zoho Integration services webhook headers. Zoho supports custom header parameters for webhook requests.

import express from "express";

const app = express();

app.use(express.json());

app.post("/webhooks/zoho", async (req, res) => {
  const token = req.header("x-webhook-token");

  // Why: reject requests that do not contain our configured secret.
  if (token !== process.env.ZOHO_WEBHOOK_TOKEN) {
    return res.status(401).json({ error: "Unauthorized" });
  }

  const eventId = req.header("x-event-id");

  // Why: the event ID becomes the idempotency key.
  if (!eventId) {
    return res.status(400).json({ error: "Missing event ID" });
  }

  // Store the event before starting downstream processing.
  await saveEvent(eventId, req.body);

  return res.status(202).json({ accepted: true });
});

The exact authentication mechanism should match what the Zoho product and webhook configuration expose. Do not assume that every Zoho webhook provides a cryptographic signature.

Step 2: Make event processing idempotent

The second step is preventing repeated events from creating repeated business records.

PostgreSQL can enforce this at the database level.

CREATE TABLE integration_events (
    event_id VARCHAR(255) PRIMARY KEY,
    payload JSONB NOT NULL,
    status VARCHAR(30) NOT NULL DEFAULT 'pending',
    created_at TIMESTAMP NOT NULL DEFAULT NOW()
);

Then use the event ID as a unique key.

const result = await db.query(
  `INSERT INTO integration_events (event_id, payload)
   VALUES ($1, $2)
   ON CONFLICT (event_id) DO NOTHING
   RETURNING event_id`,
  [eventId, req.body]
);

// Why: an empty result means this event was already accepted.
if (result.rowCount === 0) {
  return res.status(200).json({ duplicate: true });
}

This is safer than keeping duplicate checks only in application memory. A process restart should not erase the integration's event history.

Step 3: Control downstream API calls

The third step is protecting Zoho and external APIs from retry storms.

A worker can consume pending events and process them with controlled concurrency.

async function processEvent(event) {
  try {
    await updateExternalSystem(event.payload);

    // Why: mark completion only after the downstream request succeeds.
    await markCompleted(event.event_id);
  } catch (error) {
    // Why: retain the event so a worker can retry it safely.
    await markForRetry(event.event_id, error.message);
  }
}

Do not immediately retry every failure.

Classify errors first:

400-level validation errors: usually require correction.
401 or 403 errors: require authentication or permission handling.
429 errors: require throttling and delayed retry.
5xx errors: can usually enter controlled retry processing.
Network timeouts: should use bounded retries.

For high-volume integrations, Redis can manage short-lived locks and queue state. PostgreSQL should remain the durable record of processing state.

Real-World Application

In one of our Zoho Integration services projects at Oodles, we connected Zoho Inventory and Zoho Books with the Yango API, Shopify, and analytics.

The problem was not a single API call. The workflow required data to move between four systems while keeping the Zoho applications focused on their respective business functions.

We implemented custom middleware as the Zoho Integration services boundary. The middleware handled external-system translation and orchestration while Zoho Inventory and Books remained part of the operational workflow.

The measurable architectural result was a single middleware boundary coordinating four participating systems. This avoided placing external integration logic separately inside each Zoho workflow.

Oodles applies this pattern when an integration needs centralized orchestration rather than isolated application-to-application workflows.

The same design can be extended with event queues, dead-letter processing, distributed tracing, and reconciliation jobs when transaction volume increases.

Acknowledge webhooks quickly. Move longer processing into asynchronous workers.
Use idempotency keys. A repeated event should produce the same business result.
Persist event state. Application memory is not a durable integration ledger.
Respect API limits. Zoho Integration services documents rate limits and HTTP 429 responses for exceeded limits. ([Zoho][2])
Separate validation from retry logic. Invalid data should not enter an endless retry loop.

Have a webhook, API, or synchronization problem in your Zoho environment? Share your architecture or failure scenario in the comments, or discuss your Zoho Integration services requirements with our integration engineers.

How do I prevent duplicate Zoho webhook processing?

Use a persistent event identifier as an idempotency key. Store that identifier in PostgreSQL with a unique constraint before starting downstream processing. If the same event arrives again, the database rejects the duplicate and the worker skips business execution.

Does Zoho retry failed webhooks?

Yes. Zoho CRM documentation states that after a webhook failure, another notification can be sent after 15 minutes. Integrations should therefore tolerate repeated delivery instead of assuming each webhook represents a unique execution.

What causes HTTP 429 errors in Zoho integrations?

HTTP 429 indicates that an API rate or concurrency limit has been exceeded. The integration should reduce request concurrency, delay retries, and process queued work according to the relevant Zoho API limits.

Should Zoho webhooks use a queue?

A queue is useful when webhook processing requires multiple downstream API calls or can exceed the expected request duration. The webhook endpoint can persist the event and return quickly while a worker handles business processing asynchronously.

When should I use middleware for Zoho Integration services?

Middleware becomes useful when several applications participate in the same workflow. It can centralize transformation, authentication, retries, logging, event state, and reconciliation instead of distributing those responsibilities across individual Zoho workflows.

ERP Integration Services: Fixing Event Order

Sanya Mittal — Fri, 02 Oct 2026 05:52:33 +0000

We once saw an ERP Integration Services return successful API responses while the business workflow was still wrong.

The order reached the ERP. The warehouse received the inventory request. The CRM received the customer update. Every HTTP call returned 2xx.

The failure appeared later.

The warehouse processed an order before its customer record was fully synchronized. Reconciliation then required manual checks because each system had accepted a different part of the transaction.

This is the part of ERP Integration Services that API documentation rarely solves. The difficult problem is not moving JSON between systems. It is preserving business-event order when systems fail independently.

In this article, we will build that reasoning into the ERP Integration Services design. The examples use Python 3.11+ and asynchronous HTTP patterns. The code is intentionally simplified so the sequencing problem stays visible.

Step 1: Start With the Business Event, Not the API

The first mistake is usually visible in the controller.

A developer receives an order and immediately calls three systems:

# Naive ERP Integration Services flow: every downstream call happens inline.
async def process_order(order):
    await erp.create_order(order)
    await warehouse.reserve_stock(order)
    await crm.update_customer(order.customer)

This looks reasonable until the warehouse call fails.

The ERP order now exists. The warehouse reservation does not. A retry of the whole function can create another ERP order unless the operation is idempotent.

The bigger issue is ordering.

The actual dependency may be:

Customer confirmed
       |
       v
Order accepted
       |
       v
Inventory reserved
       |
       v
Shipment confirmed
       |
       v
Invoice posted
       |
       v
Payment reconciled

That sequence should become an explicit state model.

Microsoft's Business Central documentation describes business events around changes in process state. It specifically gives a posted sales order as an example of a business event.

This is a useful distinction.

POST /orders is an API operation.

OrderPosted is a business event.

The second carries more meaning to downstream consumers.

Step 2: Separate the Transaction From Its Side Effects

Once the event sequence is explicit, the next problem is atomicity.

Your ERP database and your CRM database do not share a transaction. Neither should pretend they do.

A common workaround is to make the HTTP request part of the original transaction:

# The problem: the database transaction depends on an external network call.
async def create_order(db, order):
    saved = db.insert_order(order)

    await crm.create_customer(order.customer)

    db.mark_synced(saved.id)
    db.commit()

If the CRM takes 10 seconds, your application waits 10 seconds.

If the CRM returns 503, your local transaction now depends on whether the caller retries correctly.

We instead persist the business event locally and process the external call separately.

A minimal outbox table can look like this:

-- The important part is storing the event before attempting external delivery.
CREATE TABLE integration_outbox (
    id INTEGER PRIMARY KEY,
    event_type TEXT NOT NULL,
    aggregate_id TEXT NOT NULL,
    payload TEXT NOT NULL,
    status TEXT NOT NULL DEFAULT 'pending',
    attempts INTEGER NOT NULL DEFAULT 0
);

The application then commits the order and event together:

# The order and its integration event commit as one local transaction.
def create_order(conn, order):
    conn.execute(
        "INSERT INTO orders(id, status) VALUES (?, ?)",
        (order["id"], "confirmed"),
    )

    conn.execute(
        """
        INSERT INTO integration_outbox
        (event_type, aggregate_id, payload)
        VALUES (?, ?, ?)
        """,
        ("OrderConfirmed", order["id"], json.dumps(order)),
    )

    conn.commit()

Python's SQLite documentation confirms that explicit commit() and rollback() control pending transactions when using the standard transaction mode.

The important change is architectural.

The request no longer needs the CRM to succeed before the order can become confirmed.

Step 3: Make the Worker Idempotent

Persisting an event fixes one failure mode. It does not prevent duplicate delivery.

A worker may successfully call the ERP and crash before marking the event as processed.

The next worker execution can therefore receive the same event.

That is expected in many asynchronous systems.

The consumer must handle it.

# ERP Integration Services should treat duplicate delivery as a normal condition.
async def handle_event(event):
    if await already_processed(event.id):
        return

    await post_to_erp(event)

    await mark_processed(event.id)

There is a race in this simplified version.

Two workers can read already_processed(event.id) before either writes the processed record.

The production version should enforce uniqueness in the database:

-- The database becomes the final guard against duplicate event processing.
CREATE UNIQUE INDEX ux_processed_events
ON processed_events(event_id);

Then the worker can attempt to record the event inside a transaction.

This matters more than adding another retry library. Retries without idempotency can turn a temporary outage into duplicate invoices, duplicate customers, or duplicate inventory movements.

Step 4: Use Webhooks for Notification, Not Workflow Ownership

Once the worker handles events independently, teams often move everything to webhooks.

That introduces another trap.

A webhook tells you that something changed. It does not necessarily tell you that every dependent workflow has completed.

Odoo 19, for example, supports webhook-triggered automation and its external JSON-2 API exposes model methods through /json/2/<model>/<method>.

Odoo 19 External JSON-2 API documentation

For example, a webhook can produce:

{
  "event": "order.confirmed",
  "order_id": "SO-10482"
}

The consumer should not immediately assume that inventory, payment, and fulfillment are ready.

Instead, it should query or consume the next authoritative state.

Business Central follows a similar model. Its webhook subscriptions notify consumers about entity changes, and Microsoft documents retries when the subscriber returns 408, 429, or 5xx responses.

That retry behavior is useful, but it does not remove the need for idempotency.

A retry means the same notification can reach your service again.

Step 5: Keep Slow ERP Calls Outside the Request Path

The previous steps separate event persistence from delivery. The final piece is execution.

Do not make an API consumer wait while several ERP operations complete unless the caller genuinely needs the result synchronously.

With Python 3.11+, asyncio.TaskGroup provides structured concurrency for related asynchronous tasks.

For independent work, that can look like:

async def notify_downstream(order):
    async with asyncio.TaskGroup() as tg:
        tg.create_task(update_crm(order))
        tg.create_task(update_analytics(order))

But do not use concurrency when the operations have dependencies.

This is wrong:

# Do not parallelize events that depend on a specific business sequence.
async with asyncio.TaskGroup() as tg:
    tg.create_task(create_customer())
    tg.create_task(create_order())
    tg.create_task(reserve_inventory())

If create_order() requires the customer ID, concurrency has changed the business semantics.

The correct boundary is:

Order confirmed
      |
      +--> CRM notification
      |
      +--> Analytics event

Inventory reserved
      |
      +--> Warehouse notification
      |
      +--> Shipment workflow

Concurrency belongs inside an independent stage. It should not replace the dependency graph.

Real-World Application: Where This Changed the Outcome

That distinction between concurrency and dependency mattered in an Oodles logistics ERP implementation. The integration had to coordinate order processing, inventory, shipment workflows, and operational reporting.

We initially treated synchronization as data movement between systems. The harder problem appeared when different systems accepted updates at different points in the transaction.

We changed the workflow to use shared transaction states rather than treating each API response as completion. Downstream actions followed those states instead of blindly following the original request.

The result was a 45% reduction in order-processing time, 65% lower manual effort, and 99.5% inventory accuracy. Operational errors also fell by 35%.

The important lesson was not simply to add asynchronous processing. We had to preserve the business sequence first. Only then could individual stages run independently.

That is the trade-off behind good ERP Integration Services. More state and event handling adds implementation work. In return, failures become recoverable instead of becoming reconciliation exercises.

What Happens in Production

The happy path is rarely the difficult part.

Production introduces expired credentials, ERP maintenance, rate limits, duplicate webhooks, partial database failures, and downstream timeouts.

We therefore monitor the event lifecycle rather than only HTTP status codes.

A useful event record should answer:

event_id
event_type
aggregate_id
created_at
attempt_count
last_attempt_at
status
error_code
error_message

When an operator sees OrderConfirmed stuck in retrying, they should not need to inspect five application logs to understand what happened.

The ERP integration services system should make the failure visible.

Conclusion: Key Takeaways

Model ERP workflows as business states before designing API calls.
Commit the business transaction and its integration event together.
Assume webhook and queue delivery can happen more than once.
Enforce idempotency with a database constraint, not only application logic.
Use concurrency only after identifying which operations are truly independent.
Monitor event state, retry count, and reconciliation status instead of HTTP success alone.

What are ERP Integration Services from a developer's perspective?

ERP Integration Services connect ERP APIs, databases, webhooks, queues, and external applications into a controlled workflow. Developers must handle authentication, data mapping, event ordering, retries, duplicate delivery, monitoring, and reconciliation.

Should ERP integrations be synchronous or asynchronous?

Use synchronous calls when the caller needs an immediate result. Use asynchronous processing for workflows that can tolerate delayed completion or involve unreliable downstream systems. Many ERP integrations need both patterns at different stages.

How do you prevent duplicate ERP records?

Use an idempotency key or unique event identifier. Store processed identifiers with a database uniqueness constraint. The consumer can then safely receive the same event again without creating another order, invoice, or customer.

Are webhooks enough for ERP integration?

No. Webhooks provide notifications, but they do not define the complete business workflow. Your integration still needs state handling, validation, retries, idempotency, and reconciliation when downstream processing fails.

When should developers use middleware for ERP integration?

In ERP Integration Services Middleware becomes useful when several systems share routing, transformation, authentication, retry, monitoring, or orchestration logic. A direct API connection can remain simpler when only two stable systems exchange limited data.

QuickBooks Integration Services: Stop Duplicate Invoices

Sanya Mittal — Tue, 29 Sep 2026 06:57:22 +0000

The dangerous QuickBooks Online failure is not always a 400 or 429. It is the request that creates an invoice, then times out before your application receives the response.

A worker sees the timeout and retries. QuickBooks may already contain the invoice. Your worker does not know that, so it creates another one.

This is where QuickBooks Integrations become an application-design problem. The fix is not another retry loop. QuickBooks Integration Services need a durable source transaction ID, a unique local mapping, controlled retries, and reconciliation after uncertain outcomes.

We will build that flow with Python 3.11+, PostgreSQL, and the QuickBooks Online REST API. The examples focus on invoice synchronization because the same failure appears when connecting QBO with ERP, CRM, billing, or order-management systems.

For the broader implementation context, see the QuickBooks Integration Services service page.

1. Do Not Retry QuickBooks Integration Services Blindly

The duplicate starts with an innocent-looking retry. A naive worker treats every failed HTTP call as proof that QuickBooks rejected the operation. That assumption fails when the connection breaks after the server has processed the request.

# Python 3.11+: this naive QuickBooks Integration Services retry can create two invoices.
response = requests.post(qbo_invoice_url, json=invoice_payload, timeout=15)

if response.status_code >= 500:
    response = requests.post(qbo_invoice_url, json=invoice_payload, timeout=15)

The second POST has no knowledge of the first POST's outcome. It is simply another create operation.

QuickBooks documents SyncToken for updating existing objects, but that token does not make invoice creation idempotent. The application needs its own transaction identity.

A common production symptom is 6140 Duplicate Document Number Error. Developers often try to solve that error with another pre-check. That misses the larger problem. The integration needs to know whether it already owns the QBO invoice.

2. Give QuickBooks Integration Services a Durable Identity

Once the retry can no longer distinguish success from failure, the next decision is where that identity lives.

We normally create an integration mapping table with a unique constraint on the source transaction. The source system might provide order_id, invoice_id, or another immutable identifier.

-- PostgreSQL 14+: the unique constraint prevents two workers claiming one source invoice.
CREATE TABLE qbo_invoice_map (
    source_invoice_id TEXT PRIMARY KEY,
    qbo_invoice_id TEXT UNIQUE,
    status TEXT NOT NULL,
    last_error TEXT,
    created_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

The important field is not qbo_invoice_id. It is source_invoice_id.

Before creating an invoice, the worker claims that source transaction. A second worker sees the existing record instead of independently creating another invoice.

This pattern also addresses a recurring integration problem. Application state should record what the system attempted to send, rather than relying only on a QuickBooks-side duplicate search.

3. Separate “Request Failed” From “Outcome Unknown”

Once the mapping exists, the remaining problem is a process crash between the API write and the database update.

Imagine this sequence:

Worker inserts INV-1007.
Worker sends the invoice to QBO.
QBO creates invoice 381.
The worker loses its network connection.
The worker never stores qbo_invoice_id.
A retry starts.

The database says INV-1007 exists, but it does not know the QBO ID.

That state needs its own meaning.

# Python 3.11+: UNKNOWN means the worker must reconcile before issuing another create.
ALLOWED_STATES = {"PENDING", "SYNCED", "UNKNOWN", "FAILED"}

def should_create(status: str, qbo_id: str | None) -> bool:
    return status == "PENDING" and qbo_id is None

For UNKNOWN, we reconcile first. We do not automatically create another invoice.

If the application uses a controlled DocNumber, it can query using the source-derived document number and inspect the result. Intuit documents DocNumber behavior and duplicate document-number handling.

This is an important trade-off. A local mapping gives stronger application control. A QBO query can recover after a crash. Using both gives a better recovery path than either mechanism alone.

4. Treat 429 as a Queueing Problem

Once duplicate creation is controlled, QuickBooks Integration face another constraint: request volume.

Intuit currently documents a production limit of 500 REST requests per minute per realm and 10 requests per second per realm and app. A throttled request returns HTTP 429.

That changes how a worker should behave.

# Python 3.11+: the queue absorbs throttling instead of making every request retry immediately.
def schedule_retry(job, delay_seconds: int = 60):
    queue.publish(
        job,
        available_at=time.time() + delay_seconds,
    )

Do not put a while True loop around the HTTP request. That keeps the worker occupied while the request remains unavailable.

We prefer a durable queue with delayed jobs. Workers can process other realms while one realm waits for its QBO quota.

Intuit also documents a maximum of 30 payloads in one batch request. Batch processing can reduce request overhead, but each payload still needs individual result handling.

See the official QuickBooks API limits and throttles documentation for the current platform limits.

5. Use Webhooks for Change Detection

The rate limit makes constant polling expensive. QuickBooks Integration Services can use webhooks as another signal when QBO data changes.

Intuit's webhook documentation lists invoices among supported entities. Notifications include an event ID, entity ID, and QuickBooks company ID. Signature validation uses HMAC-SHA256 and the app's verifier token.

# Python 3.11+: verify the raw request body before accepting the webhook event.
expected = hmac.new(
    verifier_token.encode(),
    raw_body,
    hashlib.sha256,
).digest()

if not hmac.compare_digest(
    base64.b64encode(expected).decode(),
    request.headers["intuit-signature"],
):
    raise HTTPException(status_code=401)

We treat the event as a trigger to reconcile state, not as proof that our database is correct.

A webhook can tell us that invoice 381 changed. The integration database still needs to decide whether that change belongs to the source transaction.

Real-World Application

That distinction between duplicate prevention and recovery became central in an Oodles QuickBooks Integration Services project for a healthcare billing workflow.

We worked with CSV billing records that had to become QBO invoices. The workflow needed grouping, field mapping, duplicate detection, conditional invoice updates, and protection for invoices that already had payments.

We used OAuth 2.0 for QBO connectivity and rules around invoice state before allowing updates. The public project record documents these controls, but it does not publish a before-and-after latency or error-rate figure.

The trade-off was explicit. Automatic synchronization was useful only when the integration could avoid changing a financially settled invoice.

We therefore treated duplicate detection and payment-aware updates as separate rules. A new billing record could create an invoice. An existing invoice could be updated only when its state allowed that operation.

The project record does not publish a quantified business outcome. We will not invent one.

That missing metric is itself useful. Integration projects should measure recovery outcomes, not only whether API calls return 200.

QuickBooks Integration Services need a durable source transaction ID before creating financial records.
Production QuickBooks Integration Services should model unknown outcomes instead of treating every timeout as a failed write.
Store an UNKNOWN state when the application cannot determine whether QBO accepted a request.
Treat HTTP 429 as a queueing and scheduling problem rather than a tight retry loop.
Use QBO webhooks to trigger reconciliation while keeping operational state in your integration database.
It should measure recovery time and duplicate prevention, not only successful API responses.

If your CRM, ERP, ecommerce, or billing system needs controlled financial synchronization, connect with us to discuss your QuickBooks Integration Services requirements.

What Are QuickBooks Integration Services?

It is connect QuickBooks Online with CRM, ERP, ecommerce, billing, payroll, or custom applications. Production work covers authentication, mapping, synchronization, error handling, duplicate prevention, and reconciliation rather than only sending API requests.

How Do QuickBooks Integration Prevent Duplicate Invoices?

They store the QuickBooks ID and source transaction ID in an integration database. Before creating an invoice, the service checks that mapping. Retry logic then reuses the existing transaction instead of creating another invoice after a timeout.

Can QuickBooks Online Sync With A Custom ERP?

Yes. A custom ERP can exchange supported customers, items, invoices, payments, and other entities through the QuickBooks Online API. The architecture should define ownership, mappings, synchronization direction, retries, and reconciliation before production deployment.

Should QuickBooks Integration Be Real Time?

Not every record needs real-time synchronization. Real-time events suit changes that affect active workflows. Batch synchronization can suit historical imports and lower-priority reporting data. The choice depends on urgency, API limits, and recovery requirements.

How Much Do QuickBooks Services Cost?

Cost depends on systems, entities, data volume, synchronization direction, business rules, and testing. A two-system invoice flow can be much smaller than an integration covering CRM, ERP, ecommerce, payments, and historical migration.

ERP Consulting Services: Fix ERP API Sync Failures

Sanya Mittal — Thu, 24 Sep 2026 06:15:18 +0000

A sync job can look healthy while quietly creating duplicate ERP records.

We have seen this class of problem when an external system retries an ERP consulting services request after a timeout. The client sees a failed request, retries it, and the ERP receives both requests. The result can be duplicate customers, orders, invoices, or payments.

This is where ERP consulting services need to go beyond module selection. The integration contract, retry behavior, API version, and record identity should be decided before implementation starts.

This article walks through one practical pattern: designing ERP integrations around idempotency, bounded retries, and explicit API contracts. The examples use Odoo because its current API direction makes this decision especially relevant.

Odoo 19 introduced its External JSON-2 API. Odoo also deprecated the older XML-RPC and JSON-RPC external APIs in version 19.

That API change is not just a developer concern. It changes what an ERP implementation team should review during technical discovery.

Step 1: Find the failure before adding retries

The first mistake is usually simple:

The integration receives a timeout and assumes the ERP rejected the transaction.

A timeout only tells us that the caller did not receive the response. It does not prove that the server did not process the request.

Consider this simplified Python example.

import requests

ERP consulting services should identify whether a retry can duplicate a write.

response = requests.post(
"https://erp.example.com/json/2/res.partner/create",
headers={"Authorization": "bearer YOUR_API_KEY"},
json={"name": "Acme Ltd"},
timeout=10,
)

response.raise_for_status()

The problem is not the HTTP request itself.

The problem is what happens when the client receives a 504, connection reset, or local timeout after the ERP has already created the record.

Retrying the same write can create a second record.

Before adding retry logic, we therefore need a stable business identifier. For example, an external customer ID can become the identity boundary between the CRM and ERP.

That gives us the first design rule:

Never make retry behavior independent of record identity.

Step 2: Make the operation idempotent

Once the failure mode is clear, the next decision is where duplicate protection belongs.

For integrations, we generally want the middleware to know whether an external event has already been processed. A simple database table can hold the source system, event ID, target record ID, and processing state.

The write then becomes two operations:

Check whether the event already exists.
Process it only when it has not been committed.

A simplified implementation looks like this:

from dataclasses import dataclass

@dataclass
class SyncEvent:
event_id: str
external_id: str
status: str = "pending"

ERP consulting services should define this identity before building the connector.

events: dict[str, SyncEvent] = {}

def should_process(event_id: str) -> bool:
return event_id not in events

def mark_processed(event_id: str, external_id: str) -> None:
events[event_id] = SyncEvent(
event_id=event_id,
external_id=external_id,
status="processed",
)

This example uses memory for clarity. Production middleware should store the event state in a durable database with a unique constraint on event_id.

That constraint matters more than the Python dictionary.

Two workers can read “not found” at almost the same time. A database uniqueness constraint gives us the final guard against concurrent processing.

For a financial transaction, we would also store the ERP record identifier after successful creation. That makes reconciliation possible without searching by description or amount.

Step 3: Treat retries as part of the API contract

Idempotency prevents duplicate processing, but it does not solve transient failures.

The next question is how aggressively the connector should retry.

Microsoft's Business Central documentation explicitly calls out 429, 503, and 504 as conditions that integrations need to handle. It recommends retry strategies such as exponential backoff and queue-based traffic smoothing.

That gives us a useful production pattern:

import time
import requests

RETRYABLE = {429, 503, 504}

def post_with_retry(url, payload, headers, attempts=4):
# Retry only transient failures, while keeping the operation idempotent.
for attempt in range(attempts):
response = requests.post(
url,
json=payload,
headers=headers,
timeout=30,
)

    if response.status_code not in RETRYABLE:
        response.raise_for_status()
        return response

    if attempt == attempts - 1:
        response.raise_for_status()

    time.sleep(2 ** attempt)

raise RuntimeError("Request failed after retries")

The important part is not 2 ** attempt.

The important part is the boundary around it.

We should not automatically retry every 400 or 401. Those usually require a payload, authentication, or configuration fix.

We should also avoid retrying a non-idempotent operation simply because the network failed.

For high-volume integrations, a queue is usually easier to operate than synchronous retries inside the web request. Microsoft specifically recommends queueing to flatten traffic spikes against Business Central web services.

Step 4: Check the ERP API version before development

The retry design is only useful if the connector targets an API that will remain supported.

Odoo's current documentation introduces /json/2 for external integrations in version 19. Requests use a model and method in the URL, with named arguments in the JSON body. Authentication uses a bearer API key.

For example:

import os
import requests

url = "https://mycompany.example.com/json/2/res.partner/search_read"

headers = {
"Authorization": f"bearer {os.environ['ODOO_API_KEY']}",
"Content-Type": "application/json",
}

payload = {
"domain": [["is_company", "=", True]],
"fields": ["name"],
"limit": 10,
}

response = requests.post(url, headers=headers, json=payload, timeout=30)
response.raise_for_status()

print(response.json())

The important consulting decision happens before this code.

If an existing connector still depends on XML-RPC or JSON-RPC, we need to establish its upgrade path. Odoo states that those external RPC APIs are deprecated in version 19 and scheduled for removal in later releases.

That means an ERP assessment should inspect API dependencies alongside business requirements.

A connector that works today can still be the wrong implementation choice.

Real-World Application: Business Central Scope Before Build

That API and retry trade-off becomes easier to understand when the integration work sits inside a larger ERP implementation.

We applied this sequencing in a Business Central implementation for a graphics operations business. The project covered finance, inventory, operational workflows, and approximately 62 AL extensions.

We initially treated the extension list as development scope. The more useful approach was to separate standard Business Central capability from genuine extension requirements before sprint planning.

We then structured delivery into an 18-week plan with nine two-week sprints. Each sprint could be reviewed against defined functional decisions instead of allowing integration and customization requests to expand the scope informally.

The quantified outcome available from the implementation scope was therefore an 18-week delivery boundary and approximately 62 extensions.

The lesson for integration engineers is straightforward. API behavior should be treated as part of ERP architecture, not as a coding detail discovered after functional requirements are approved.

This is the point where Oodles treats ERP consulting services differently from a software configuration exercise. The consulting output has to survive contact with development, testing, migration, and operations.

ERP consulting services should identify integration failure modes before development, especially timeout and retry scenarios.
Idempotency needs a durable business identifier, not just a retry counter.
Database uniqueness constraints protect against concurrent duplicate processing when multiple workers consume the same event.
Retry logic should target transient failures, while permanent client errors should enter an error workflow.
API version changes belong in ERP technical assessments, because 6. deprecated interfaces can turn a working connector into future migration work.

If your ERP scope is growing faster than your delivery plan, discuss your requirements with our ERP Consulting Services team before the next change request becomes development work.

What do ERP consulting services include?

ERP consulting services typically cover process discovery, requirements definition, fit-gap analysis, platform evaluation, implementation planning, data migration strategy, integration architecture, testing, training, and post-go-live optimization. The exact scope should depend on whether the organization needs selection, implementation, recovery, or optimization support.

How do ERP consultants prevent scope creep?

They establish decision boundaries before development. Requirements are classified by business priority and technical treatment, while integrations, data dependencies, acceptance criteria, and change-control rules are documented early. This makes new requests visible as scope changes rather than allowing them to enter development informally.

Should companies customize their ERP?

Customization should address a genuine business or regulatory requirement that standard functionality cannot reasonably support. ERP consulting services should compare customization against configuration, process change, integration, maintenance, and future upgrade costs before recommending an extension.

When should data migration planning begin?

ERP consulting services Data migration planning should begin during process discovery, not immediately before go-live. Teams need early decisions about data ownership, required history, cleansing rules, transformation logic, validation, and reconciliation. Those decisions can affect the design of finance, inventory, sales, purchasing, and reporting workflows.

How long does ERP consulting take?

The duration depends on the number of processes, entities, ERP platforms, integrations, and migration requirements. A focused discovery can take weeks, while enterprise programs may require months of advisory and implementation planning. The useful measure is decision coverage, not simply elapsed consulting time.

Building Logistics Management Solutions That Keep Inventory Consistent

Sanya Mittal — Wed, 23 Sep 2026 06:32:35 +0000

A shipment can be created twice when inventory reservation happens in two systems. This occurs when an order service updates an ERP while a warehouse service reserves the same stock independently. Logistics Management Solutions must prevent that race before it becomes an operational problem.

The fix is not another synchronization job. The system needs a clear inventory owner, atomic reservation rules, idempotent APIs, and event-driven updates. This architecture becomes especially important when an organization connects ERP, warehouse management, carrier APIs, and customer portals.

For teams designing these systems, inventory and warehouse management solutions provide the operational foundation. The technical question is how to keep inventory state consistent while multiple services act on the same order.

Context and Setup

The core problem is distributed inventory state. An order service may see 10 units available while another fulfillment request reserves those same units milliseconds earlier.

This is common in Logistics Management Solutions architectures containing an ERP, warehouse management system (WMS), order management system (OMS), and logistics APIs. Each system may maintain a local representation of stock, but only one should own the authoritative quantity.

Extensiv's 2024 3PL Warehouse Benchmark Report found that 87% of respondents using a warehouse management system cited real-time inventory tracking and management as a top value proposition.

That number points to an architectural requirement: inventory visibility must follow inventory transactions, not periodic synchronization.

Designing Logistics Management Solutions Around Reservation Ownership

The safest design starts by separating available Logistics Management Solutions inventory from reserved inventory. The reservation service becomes responsible for changing stock availability, while other services consume the resulting state.

Step 1: Define the Inventory State Machine

Do not store inventory as a single mutable number.

Use explicit states such as:

available
reserved
allocated
picked
shipped
returned

Each transition should have one owner and a recorded event.

For example, an order service can request 4 units. It should not directly decrement warehouse stock. Instead, it calls the reservation service, which validates availability and creates the reservation.

This prevents different services from silently applying competing inventory rules.

Step 2: Make Reservation APIs Idempotent

The second step is preventing retries from creating duplicate reservations.

A carrier timeout, network failure, or application retry can cause the same request to reach the backend twice. The API should therefore require an idempotency key.

app.post("/reservations", async (req, res) => {
  const { orderId, sku, quantity, idempotencyKey } = req.body;

  // Why: repeated requests must return the original reservation.
  const existing = await db.reservations.findOne({ idempotencyKey });

  if (existing) {
    return res.status(200).json(existing);
  }

  // Why: the database transaction prevents competing reservations.
  const reservation = await db.transaction(async (tx) => {
    return tx.reserveInventory({
      orderId,
      sku,
      quantity,
      idempotencyKey
    });
  });

  return res.status(201).json(reservation);
});

The database transaction matters more than the API endpoint itself. Two concurrent requests must not both read the same available quantity and successfully reserve it.

Step 3: Publish Inventory Events

Once the reservation commits, publish an event such as InventoryReserved.

Downstream systems can consume that event without modifying the inventory owner.

A typical flow becomes:

OMS submits reservation request.
Reservation service validates stock.
Database commits the reservation.
Event broker publishes InventoryReserved.
WMS updates fulfillment state.
Customer portal receives the new availability.
Analytics consumes the event asynchronously.

This design introduces eventual consistency between services. That is the trade-off.

A fully synchronous architecture provides stronger immediate consistency but creates tighter dependencies. An event-driven architecture reduces coupling but requires reconciliation, retry handling, and observability.

Real-World Application

The reservation pattern maps directly to our KLG-ITM Logistics project. The client needed an open-source ERP for logistics operations covering inventory management, order processing, and real-time tracking. We implemented an ERP-centered workflow and integrated logistics processes around shared operational data.

The public project record confirms the system delivered real-time logistics insights and covered inventory, order processing, and tracking. It does not disclose a numeric performance result.

[PROJECT METRIC NEEDS INTERNAL VERIFICATION: insert a measured result such as inventory reconciliation time, order-processing time, reservation error rate, or API latency before publication.]

The architecture also included Java-based ERP applications and control-tower capabilities in the related KLG implementation record.

This is where Oodles approaches logistics engineering differently from a simple CRUD implementation. We first establish transaction ownership, then define integrations around those boundaries.

Conclusion: Key Takeaways

Give inventory one authoritative owner before designing integrations.
Model stock as explicit states instead of repeatedly modifying one quantity field.
Use idempotency keys for reservation and fulfillment APIs.
Commit inventory changes before publishing downstream events.
Accept eventual consistency only when reconciliation and observability are designed with it.
Measure reservation failures and reconciliation time, not only dashboard availability.

If you are designing or replacing Logistics Management Solutions ERP, WMS, OMS, and carrier integrations, share your architecture or implementation question in the comments. You can also discuss your Logistics Management Solutions requirements with our engineering team.

What are Logistics Management Solutions?

Logistics Management Solutions coordinate inventory, orders, warehousing, transportation, tracking, and fulfillment workflows. Technically, they often combine ERP, WMS, OMS, carrier APIs, event processing, and reporting. The architecture should clearly define which system owns each transaction and how other systems receive state changes.

How should inventory be synchronized across ERP and WMS?

The safest approach is to assign inventory ownership to one system or service. Other platforms consume controlled updates through APIs or events. Avoid allowing ERP and WMS to independently modify the same available quantity because concurrent updates can create inconsistent stock positions.

Why are idempotent APIs important in logistics software?

Idempotency prevents repeated requests from producing repeated business transactions. Network failures and client retries are normal in distributed systems. An idempotency key allows the backend to recognize a previously processed reservation, shipment, or fulfillment request and return the original result.

Should Logistics Management Solutions platforms use event-driven architecture?

Event-driven architecture works well when several systems need the same operational update. After an inventory reservation commits, the system can publish an event for warehouse, customer, analytics, and notification services. The trade-off is eventual consistency, which requires retries and reconciliation.

When should a Logistics Management Solutions use database transactions?

Use database transactions when multiple related changes must succeed or fail together. Inventory reservation is a common example. The transaction should validate available stock and create the reservation atomically. This prevents concurrent requests from reserving the same inventory.