---
title: "openepcis_connector_events_pos: point-of-sale events"
description: "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."
canonical_url: "https://openepcis.io/docs/connectors/odoo/point-of-sale-events"
last_updated: "2026-10-09T10:21:43.684Z"
---

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.

<table>
<thead>
  <tr>
    <th>
      
    </th>
    
    <th>
      
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      <strong>
        Module
      </strong>
    </td>
    
    <td>
      <code>
        openepcis_connector_events_pos
      </code>
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Depends on
      </strong>
    </td>
    
    <td>
      <code>
        openepcis_connector_events
      </code>
      
      , <code>
        point_of_sale
      </code>
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Installs
      </strong>
    </td>
    
    <td>
      Automatically, once the events addon and Point of Sale are both present
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Settings
      </strong>
    </td>
    
    <td>
      None — it reseeds the operation type's business step and disposition
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Source
      </strong>
    </td>
    
    <td>
      <a href="https://github.com/openepcis/openepcis-odoo/tree/18.0/openepcis_connector_events_pos" rel="nofollow">
        openepcis-odoo
      </a>
      
       · LGPL-3
    </td>
  </tr>
</tbody>
</table>

## 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.

![The EPCIS block on a till's operation type | Figure 1: The same two fields, now reading as a sale](/img/16.Connectors/odoo-operation-type-till.png)

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](/docs/connectors/odoo/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.