Rezerwacja odbiorcy (RO) in Comarch Optima: how the reservation really works, and where integrations break it

Why I'm Writing This

For about a month now, Google has been sending people here on the query "ro" "rezerwacja odbiorcy". They land on my Optima and B2B portal article, which gives the RO document one paragraph and then moves on to something else. That's not what they came for. This is.

The RO is the document Optima uses for a customer order. It's also the one mechanism that decides three things: whether your warehouse oversells, whether your online shop shows honest stock, and whether the integration you paid for is quietly making inventory disappear. Most of the people who raise ROs every day couldn't tell you what one actually holds. Most of the integrators writing to them have never read the three configuration parameters that change what it means.

Everything below comes from Comarch's own documentation and from installations I've had to debug. None of it is a guess.

What an RO Holds, and What It Does Not

Start with the sentence Comarch itself uses: the reservation does not take goods off the warehouse, it only reduces the quantity available for sale. Two numbers sit on every product card. Ilość is what's physically in the warehouse. Ilość dostępna is that number minus reservations. An RO changes the second one and leaves the first alone.

That's the whole mechanism. Arithmetic, nothing more. Physical goods leave the warehouse when a WZ is created, or when an invoice or receipt is saved as pobranie rather than rezerwacja. Until then, a reservation is a number that somebody, somewhere, may or may not be looking at.

Three consequences follow. Each one is a project failure I've watched happen.

A reservation only blocks an issue if somebody ticked the box. In Konfiguracja Firmy → Magazyn → Parametry → Zamówienia i Rezerwacje there's a parameter called Nie pozwalaj na wydanie towaru gdy występują rezerwacje. Leave it off and the program allows an issue whenever the warehouse holds enough physical stock, reservations or not. Switch it on and an issue is refused when the available quantity is insufficient because of existing reservations. Comarch presents these as two legitimate ways of running a warehouse. Fine. But on an installation with that parameter off, an RO is a note on a whiteboard, not a lock on a shelf. A WZ for another customer can walk out with the reserved goods and Optima won't say a word.

So ask this on day one of any Optima project: is the blocking parameter on? Not once has a client known the answer without going to check.

A reservation has a clock. Every RO carries two dates: Data wystawienia, from which the goods are reserved, and Termin rezerwacji, after which they aren't. Comarch's documentation is blunt about what happens next: goods from expired reservations are unblocked and increase the available quantity. The document stays open. It still appears on the RO list, still shows on the customer's account, still sits on the product card's Rezerwacje tab flagged as overdue. It just doesn't hold anything any more.

An overdue RO is the worst of both states. The customer is still expecting the goods. The sales rep still sees an open order. And the stock belongs to whoever asks for it first.

The default deadline is a day count in Konfiguracja Firmy → Handel → Parametry, counted from the issue date. Go and look at what that number is on the installation you're integrating with. Then note the exception that matters for integrators: for ROs imported from XML the configured default does not apply at all, the deadline always comes from the file. Your integration owns that clock. Write a deadline nobody thought about and the reservation can expire before the picker ever sees it.

A confirmed RO cannot be edited. Zatwierdzonego dokumentu RO nie można korygować. Two supported paths, and that's it. Close it, optionally with Zamknij i wygeneruj RO różnicowe, which creates a new RO in the buffer holding only the unrealised lines and quantities and links it back to the source. Or cancel it, which only becomes possible once every resulting document has been cancelled or deleted first. Neither one is an edit.

Every online shop, every B2B portal, every sales-rep app lets a customer change an order after placing it. So every integration has to decide, in writing, which of those two paths it takes and when. The ones that never decided are the ones running two ROs that hold stock for a single order.

The Lifecycle, So You Can Reason About It

The statuses on the RO list are the state machine. Worth memorising, because every integration bug I've chased maps onto one transition.

• Empty status: confirmed, not yet realised, no pro forma attached.
• PF: not realised, linked to a pro forma invoice.
• W realizacji: partly transformed into resulting documents.
• Zrealizowano: fully transformed. Nothing more can be done with it.
• Zamknięto: closed by a person, whatever was or wasn't realised. Reservations disappear from the resource lists.
• Anulowano: cancelled.

Two columns show up on the document only after a permanent save: Zrealizowano, the quantity already pulled through to WZ, FS or PA, and Pozostaje, what's still reservable. Close the document and Pozostaje disappears completely. That's the tell for any integration reading the RO list. If you're computing "remaining" yourself from line quantities, you're already wrong on every closed document.

The transformations run to FS, PA, WZ, RW, MM, FPF and ZD. Two rules bite in practice. A WZ removes goods immediately, so it needs physical stock on every line, and if one line is short the WZ isn't created at all. And an RO can only become a receipt if it was calculated from gross, a field (Dokument liczony od) that any integration writing ROs has to set deliberately.

The field I'd point every integrator at is the smallest one on the form: Numer zamówienia, the external order number. It's the natural home for the shop's or portal's own order ID, it's how you make an import idempotent, and on transformation it carries through into the description of the resulting document. Use it and a duplicated import becomes a query rather than a mystery.

Where This Goes Wrong in Integrations

In the Optima developer guide I listed reservation semantics as one of the five places Optima integrations break. Here's the longer version.

One RO per basket. A shop or portal raises an RO the moment a customer drops something into a basket, "so the stock is held". Now every abandoned basket is a reservation with a deadline nobody chose. Within a month the available quantity on the best sellers is fiction, the warehouse is convinced it has a shrinkage problem, and the fix takes three days because nobody suspects the integration. An RO should exist only for a confirmed order. That's exactly what Comarch's own e-Sklep connector does: it imports an order only once the customer has confirmed it and the shop status has moved to awaiting the shop's confirmation, and it creates the RO in the buffer.

The wrong warehouse. An RO reserves stock in one warehouse, the one on the document. The e-Sklep connector has a default-warehouse setting for exactly this reason, and when it's empty the reservation lands in the operator's warehouse or the main one. A portal reserving in the main warehouse while goods are picked from a second one is holding air.

Which number goes to the shop. I'd ask this before anything else. Comarch's connector has a checkbox called Stany na dzień. Ticked, it sends Ilość dostępna, the reservation-adjusted number. Unticked, it sends total stock. One checkbox, and it is your entire oversell policy. Send total stock and every open RO becomes a promise you can break twice, once in the shop and once in the warehouse. Send available quantity and the overdue-reservation problem from the previous section starts driving what your shop displays. The second is still the right choice. It just comes with a maintenance obligation attached.

Edits that create instead of replace. Covered above. The portal sends an updated order, the integration creates a second RO, the first keeps holding stock until its deadline passes, and by then the customer has already been told the item is out.

Reservations the integration can't see. More than ROs reduce the available quantity. Unpaid sales invoices and receipts saved as rezerwacja hold stock with no deadline at all, and so do service orders with delivery batches assigned to parts. An integration that reads ROs to reconstruct "what is reserved" will never match Optima's own available-quantity figure. Read the figure Optima computes. Don't recompute it.

The One-Hour Audit

This is the check I run before proposing anything on an Optima installation, and the one I'd want every wholesaler running once a month. It costs one export and a sort. Same shape as the credit-limit staleness audit I described for enova365.

Open the RO list. Filter Rodzaj to reservations still to be realised. Switch the Przeterminowane filter on so overdue documents come through. Export with the deadline and the Pozostaje column.

Then three numbers:

1. Share of open ROs past their deadline. Every one is an order a customer is expecting that no longer holds a single unit of stock. On installations where nobody set the default day count with any thought, I've seen this above half. That isn't a warehouse problem. It's a configuration problem wearing a warehouse problem's clothes.
2. Open ROs older than your longest delivery lead time. Orders that should have turned into a WZ or a ZD weeks ago and did nothing at all. Usually the customer changed their mind on the phone and nobody closed the document.
3. ROs sitting in the buffer for more than a day. Imports that arrived and were never confirmed. The e-Sklep connector puts every order in the buffer, and a buffer document is a reservation that isn't yet a reservation.

The first number tells you whether ilość dostępna means anything on this installation. If it's high, don't connect a shop to that figure until it's fixed. You'd only be exporting the fiction.

What an Agent Does Here, and What It Must Not

The boundary between reading and deciding is unusually clear here, which is what makes this a good first automation.

The read side is all upside. A nightly job that pulls the RO list and reports the three numbers above. That flags any RO whose deadline falls within the next two days with unrealised quantity. And that names the ROs whose lines cannot be covered by physical stock and have no linked ZD. That last one earns its keep: a reservation for goods that aren't there and haven't been ordered from a supplier is an order that's going to be late, and today nobody finds out until the picker does.

The write side is where I stop. Extending a deadline is a commercial decision about whose order matters more. Closing an RO is telling a customer no. Generating a ZD commits money. An agent can put each of those in front of a person as a proposal with the whole case attached. None of them is something it should do on its own. Same read-first, human-on-every-write rule I set out for enova365 agents, and it applies harder here, because what's being decided is physical goods.

One more metric, worth running from week one: ROs closed or cancelled per hundred created. High means orders get placed and withdrawn constantly, and no reservation setting will fix that, it's a sales-process problem. Low, with a high overdue share, means the orders are real, the deadlines are wrong, and one configuration change moves the whole picture.

Where This Leads

The RO is the bridge between how a customer orders and what the warehouse does about it, and every channel feeding Optima has to cross it: the shop, the B2B portal, the rep's phone, the email order somebody retypes by hand. Get the reservation semantics right and you have a portal that shows honest stock. Get them wrong and you've taught your customers to ring up and check.

If you're scoping an integration with Optima and want somebody to run the one-hour audit on your actual data before anyone writes a line of code, get in touch. It's the first thing I do on every AI agent project against Optima, and it's usually the thing that changes the scope.