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.
| Module | openepcis_connector_events_pos |
| Depends on | openepcis_connector_events, point_of_sale |
| Installs | Automatically, once the events addon and Point of Sale are both present |
| Settings | None — it reseeds the operation type's business step and disposition |
| Source | openepcis-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.
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
shippingandin_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.