openepcis_connector_events_pos: point-of-sale events

The bridge to Point of Sale. A till's orders leave the warehouse through an operation type that looks exactly like a delivery to the stock module; this addon knows the difference and reports a sale as retail_selling with the goods retail_sold — and keeps that reading current as tills are configured and moved.

A point-of-sale order leaves the warehouse through an ordinary outgoing operation, and to the stock module it looks exactly like a delivery: outgoing, shipping, in_transit. It is not one. The goods are not in transit to a customer's address; they have been sold and carried out of the shop.

EPCIS has a word for that — retail_selling, leaving the goods retail_sold — and it is the one thing no code on the operation type reveals. This bridge knows where to look, and does nothing else.

Moduleopenepcis_connector_events_pos
Depends onopenepcis_connector_events, point_of_sale
InstallsAutomatically, once the events addon and Point of Sale are both present
SettingsNone — it reseeds the operation type's business step and disposition
Sourceopenepcis-odoo · LGPL-3

What makes an operation type a till

Not its name — it is called "PoS Orders" either way — but the fact that a point-of-sale configuration points at it. Pointing a till at an operation type changes none of the codes the events addon pre-fills from, so an operation type seeded before the till existed would keep reporting sales as shipments, with the correct override sitting there unreached.

Figure 1: The same two fields, now reading as a sale

So the bridge hooks the moment the fact appears:

  • When a till is created or re-pointed, the new operation type learns it is a sale.
  • When the last till is pointed elsewhere, the old operation type goes back to being a loading bay — plain shipping and in_transit.
  • At install, every till that already exists is walked once, so a database that adds the bridge later does not have to touch each configuration by hand.

On the instance in the walkthrough the operation type read shipping / in_transit until a till was created, and retail_selling / retail_sold immediately after.

A choice somebody made by hand is still never overwritten: the reseed fills the two fields the same way the pre-fill does, and the pre-fill never replaces a value that is already there.

Last updated: