Enable hubs to use record retail (onsite) sales alongside with their OFN online sales [POS]

Tags: #<Tag:0x00007f45e1a80e70> #<Tag:0x00007f45e1a80da8>

What is the need / problem

Mary sells online and people get their basket in a pick-up point. But there she also proposes some products for sale.

  1. For this she needs to quickly create and process new orders on site.
  • Today she can do it via a shop or admin but it is painful and slow, multiple steps are required, some unecessary (ex: shipping).
  • She cannot place anonymous orders.
  1. Also Mary needs to quikly modify existing orders (if someone ordered online but decide to buy something else onsite)
  • same pain
  1. Once the onsite sales has happen Mary needs also to provide appropriate documents to the customer: receipt + invoice (if requested)

  2. Mary also needs consistent data whatever tool she uses to capture those onsite sales, about her stock level, sales data, accounting export data, etc.

Also maybe Mary is managing a complex store, like a cooperative grocery store with multiple checkout lines, etc. But she also manages an online shop connected to the same inventory and she is using OFN for that, so she wants both systems to be connected.

Who does it impact

Mary. Even if she sells online, she often has “on the shelf” items for sale at the pick-up point. And some Mary’s have both a physical and an online store.
(Here we can be more specific and give users names in different instances that need that: BawBaw in Aus, Alterconso and Micromarché in France, etc.)
Users who need that are usually bigger hubs, so in term of trade potential through the OFN they are potentially important users (sales volumes) and contributors ($) to the commons.

What is the current impact of this problem

  • Mary can’t use the OFN if she manages regularly onsite sales (In France for instance Alterconso would like to use OFN but manages complementary sales on the distribution points and needs the OFN to be able to manage that) So having that feature would allow for new and pretty big users on local instances.
  • or if she does this is very painful (we have the case of Micromarche in France who uses OFN to manage a physical store… this is painful, but they also manage online sales with pick-up points and they wanted to manage all in one system) So having this feature will enable us to not loose current users who believe in us but are fighting to meet their needs.
  • or she uses two systems and duplicates efforts in filling in products, and she can’t manage her stock properly in just one place. This is actually not happening in reality, no one does that as a moment, too painful, so users either hack OFN and do POS in it (Micromarché in France) or don’t use OFN.

What is the benefit in focusing on this

  • Hub managers will be able to process more quickly sales on site so they will be happier and will improve their efficiency, will have more time to discuss with their customer, etc.
  • More hubs will be able to use OFN as they will be able to manage easily both click & collect and physical store options.
  • Enable biger and complex hubs to use OFN, enable physical stores to develop OFN based online shops.
  • Prevent loosing current users who need a POS solution and are fighting with some hack within OFN…

Links to more details

Potential solutions that will solve this problem

1- Build internal POS feature: Rob apprently dropped this idea and went for Odoo for his food hub, so that might not be such a good idea. POS is a BIG thing. If we do something, we want to do it properly, so it might not be wise to fo in that direction.
2- Expose data (pull/push) through an API so that hubs who want to use some POS can ask some integrator to deploy their POS (like Odoo or Unicenta or Pastèque or … ) and connect both systems thanks to that API.
3- Propose some pre-made integration with a broad and powerful open source POS system like Odoo POS or Unicenta
This integration could be proposed as custom deployment = we deploy for you Odoo, customize some things if needs be, and connect with OFN so both databases are always consistent and you know what to use each tool for
OR as a SaaS offer = we do a deployment of Odoo or Unicenta and offer “packages” alongside OFN access: you login and can access both services easily
For illustration, here is the discussion we had on that topic with Unicenta
For now I don’t see other options apart from Unicenta and Odoo that has an international, multilingual scope and with active teams behind them. Odoo has probably a stronger community.

  • 3.1 This pre-made integration is done through a “DB connector” = a specific “connector” using a manual script or Zapier and touching directly the database
  • 3.2 This pre-made integration is done through an “API based connector” = a specific “connector” using a manual script or Zapier consuming the OFN API

So folks, do you see other solutions in the “brainstorm solutions” space? Then we can maybe convey some call to discuss and do some “value - ease matrix”? To see where we want to go, which solution among those 4 will bring more value given the need, for the less effort, and also call in that brainstorming our vision and long term strategy to drive our choice… see discussion about API strategy references in that post Enabling OFN to integrate with external systems (POS, standalone websites, Odoo ERP modules, other plateforms with DFC sandard, etc.).

@lin_d_hop @oeoeaio @danielle @Kirsten @maikel @sauloperez @Matt-Yorkley

@danielle interestingly this case is good to refine our processes. Value-ease matrix is not enough to decide. Vision and strategy also need to be taken into account, as building a quick and easy “patch” might be a very bad idea on a mid-long term, so even if bring quick value easily, shall we do it? And if yes for which specific scope until we switch to the sustainable solution?

To my mind a good option might be a three step process:

  1. Link with Zapier to use one of the POS solutions the already have integrated.
    This will enable a very quick spec of exactly what data needs to be exposed through the API. And it will let us see exactly how users use the POS tool.
  2. Once we have this data we can expose the API and link it with Zapier so the user doesn’t experience any change of service.
  3. Then when we are confident we can speak directly to the POS tool API ourselves.

Security risk is minimised by having a specific DB user for Zapier that must come from the Zapier IP.
Dev risk is minimised as we know our EXACT use case before we develop anything at all.
AND the user gets the functionality very quickly. Super fast turnaround so (if charging) revenue comes in quickly.

Down side is that a support person will need to set this up for each user. But that seems like a small price to pay.

I like Lynne’s idea of an iterative process in which we do it step by step. But accessing the database directly can lead to inconsistent data. We need to make sure that we do transactions in the same way the OFN is doing it or we run into stock conflicts.

So folks, do you see other solutions in the “brainstorm solutions” space?
Nope

Agree with the iterative process but although 1. is faster than maybe implementing an API it will still require some time. However, we already have lots of API endpoints and we might just need to implement few more, if there are any missing. I’d great to check that before the meeting.

From the top of my head these are the operations the POS will have to perform against OFN:

  • Read product catalog
  • Create order
  • Update stock levels

I don’t have any idea how this is handled from the POS’s side.