Enabling OFN to integrate with external systems (POS, standalone websites, Odoo ERP modules, other plateforms with DFC sandard, etc.)

Integrations
1

What is the need / problem

There are a set of problems/needs shared with many users, related to the fact that we don’t have a clean API:
1- A significant number of hubs want to be able to use a POS system to be able to handle on-site sales as a site as OFN online sales and have consistent stock management / accounting / etc. So they need to be able to connect a POS and OFN on product catalog / sales / accounting / etc.
2- Some hubs want to be able to manage seamlessly their accounting and invoicing for sales that happen on the OFN. For that they need to connect with some accounting/invoicing system (like Odoo ERP) on sales.
3- Quite a lot of hubs want their standalone website, so they want to drive their customer in their own UX and graphic design, and just use the OFN features but in their own css.
4- Producers selling via multiple platforms need to be able to share their catalog info with other platform (Data Food Consortium)
5- Hubs sourcing from producers managing their catalog outside of OFN need to be able to easily sell on OFn (Data Food Consortium)
6- Food enterprises wanting to mutualize logistics routes and services need to be able to share planned logistics flows (Data Food Consortium)
7- We want to build an open directory showing all local food systems, producers, etc. with rich filters without having to manually maintain and update it so data of food hubs need to flow through API (Data Food Consortium and open directory project)
8- Am I missing cases?

Who does it impact

Lots of hubs in all instances, and especially potential big actors that can’t use our system, but would give a lift to the OFN if they would!

What is the current impact of this problem

We are loosing some potential big users that would make the financial sustainability of the OFN.
Ex: Alterconso in France (need POS absolutely among other things), Ficos in italy ( a BIG cooperative selling to a large number of buying groups in Sicily and Europe and using Odoo to manage their product catalog and accounting, invoicing, etc.), VillageCenter in Germany want their standalone website, Micromarché in France is one of our main user and need a POS Asap, Rob for BawBaw has done some script to connect some Odoo POS already because he needed it, etc.

What is the benefit in focusing on this

  • Making the OFN a sustainable project by serving not only small actors but also bigger/more structured ones who are more able to financially support it.
  • Enable us to scale up the impact and usability of OFN in various cases
  • Give more flexibilty for food enterprises on how they use the OFN, adapt it to THEIR specific need
  • Enable integration that would help food enterprises to be more efficient, and them more resilient and sustainable
  • Increase the possible outreach of the OFN

Links to more details

Potential solutions that will solve this problem

First feature candidate is to build a clean and clear API and use it ourselves for our own frontend (so we would ourselves be a standalone website, but others could make different ones)
A direction to go there could be:
A - modularize the rails app (Breaking OFN down into Domains)
B - organize the way we grow the API (Road map for OFN's API?)
C - and both 1. grow the api and 2. decouple the website with this option 3: How we build web pages: rails views vs angular templates (edited)

2

Ok I started a draft icebox to try to sum up the needs/problems connected to the fact that we don’t have an API. It’s sourced from many wishlist, gathering, slack discussions. Devs have apparently moved forward on a strategy on how to do it technically, so I think it’s time to clarify the need and the potential it has for OFN, and how aligned it is with our strategy, to decide to prioritize or not as “big tech infra thing” after the Spree upgrade is done. @danielle before we invite more people to that discussion do you agree that it’s the way to proceed?
From that draft API we might want to propose a reduced scope for the first API version, it won’t cover all the OFN domains at once, so this is the type of discussion we will have here. *
So the idea here is NOT TO HAVE A TECH DISCUSSION please, it’s about product strategy,current/target users need, and the opportunity it can open for the OFN if we decide to prioritize it.

1 Like
3

Feature Candidate: Use an external integration system to deliver some of this quickly. Then we can explore exactly what people use and use real data to drive our development, while delivering value to users and spending more time understanding the tech debt perspective on this issue.

UK use Zapier to solve mailchimp integration, accounting integration, business analytics integration and I know we can do POS integration too. I’m also about to set up a customer feedback system for a user in this way.

I know I’ve not been transparent enough on showing people how to do this. I feel like this is unfair but capacity is capacity. Writing up a simple how-to guide is on my to do list. I’m still catching up on Barcelona tasks :-/

4

would be awesome if you can find a time @lin_d_hop to have a call with @oeoeaio who has set up odoo POS for baw baw food hub. In depth knowledge of odoo and OFN likely helpful insights and if you know the zapier bit then perhaps not that hard . .

5

One thing @MyriamBoure, in terms of what we spoke about in having something considered “ready” to become an icebox item - understanding the global appetite for this particular problem.

Also…it’s a REALLY BIG THING. I’m not sure you can…but is it maybe better to be specific about the particular problem you’re wanting to solve (e.g. need: selling products at the hub; problem: OFN doesn’t have this functionality)? Then there is an analysis as to why it makes more sense to connect to 3rd party applications to provide this ability rather than building it from scratch (pros and cons, trade offs, etc), which then leads to a feature candidate of integrating with an existing applicaiton (e.g. Odoo) to provide this feature.

My concern would be focusing on building out APIs just for the sake of having them, rather than on the value we will create. The API itself doesn’t provide value, it’s the use of the API that does. So, we wouldn’t just build an API for the sake of it, we would do it because there is a particular need/barrier to that need that we want to resolve.

Know what I mean?

6

Also…we have four key themes for 2018 in terms of what we prioritise:

  1. Make what we have great
  2. Future proof the tech platform
  3. Build the network in the OFN
  4. Be a single, cohesive OFN unit.

Is it worth talking about which of these we believe this fits into?

7

I don’t have an appreciation for big things and little things – but just want to say that all of the use cases above resonnate with me. Plus I’d add - integration of OFN with marketing software (ie mailchimp). (Seriously - if we don’ t do something soon to help buyers find sellers - other than our ‘put it online and they will come’ strategy (which is failing) - then we will be losing users. This is the biggest request from our users here in CAnada - ‘how can OFN help new customers find me?’. So - integration with programs that already do this would be great.

IN responde to @danielle - seems to me it fits under ‘make what we have great’ - because what we have can’t fully work for users without the things @MyriamBoure listed above. And I really like what (I thing?) @lin_d_hop is suggesting - re: Zapier (I don’t know what it is , but it sounds too good to be true). Wouldn’t this be a relatively quick fix to these use cases?

1 Like
8

Thinking about this further @MyriamBoure I really do believe this isn’t ready to be an icebox item yet. Which problem are we solving? How will we know we have solved it?

If we made this a wishlist item then we could take one of the problems you have described and turn that into an icebox item. There are SO MANY different features that will come out of all those problems you listed. I believe we have to choose one at a time. It shouldn’t be just about integration, it should be able solving one of these problems alongside of recognising that we don’t have to build everything and we can integrate with software that already offers the functionality.

So, I think the next step is to flesh out each of these problems related to their particular need that the problem is a barrier to meeting, and then turn them individually into an icebox item. Don’t try to shove them all into a single item with the problem being “we can’t integrate” because it makes it wayyyyy too big to solve and isn’t focused on a specific value and will be open forever and ever and ever.

#smallisbeautiful :slightly_smiling_face:

9

so…going on @lin_d_hop’s lead…let’s make this about the need for POS and fact that OFN software doesn’t have POS or connect to a POS system…that’s a rather important and appetising problem to solve that will require APIs, right?

And then all the others can go into a wishlist bucket of things we’d like to integrate with and what need we would meet by doing so…

10

I would rather suggest this go into the #integrations category first as it’s a quite generic discussion about integrations

11

Interesting post!

I am not sure it’s clear for everyone but there’s already an extensive OFN API, the Spree API plus the 3 or 4 different forms of OFN API… it’s messy (there’s no single tech approach), but it is an API.
The tech analysis required is about organising this and setting a tech approach for the future.

I think the approach of separating these problems in smaller parts with independent business value is a good approach. I think @MyriamBoure objective was to raise awareness of the importance of this space. Also, the post is correct in assuming that all these problems should depend on the existence of an API.

Can we pick the most valuable item from this list and get it into the pipeline? We could then use it to do the API tech analysis and solve it with the proposed solution.

12

Thanks everyone for your contributions to that discussion :slight_smile:

@danielle I agree with you, that’s why I put it as draft as there are already lots of wishlist items so I was trying to synthetize the needs from those wishlist items. But I agree that to move it forward, EVEN IF the solution was to build the API we would do it bit by bit for specific cases. So I propose to move that one back to wishlist (or integration, could be both) and reactivate the discussion and evolution of the POS case: Enable hubs to use OFN to record retail (onsite) sales [POS] (that I will put back as “draft” until we agree that the need is clearly understood).

So on this draft icebox we can start brainstorming solutions. We did it in Australia but it seems things have changed, Rob got rid of his home made POS and went for Odoo, etc.

In brainstorming solutions, there are basically 3 main solutions for each of the "needs" listed above:

1- Develop it ourselves inside OFN. Which leads to the question: where do we draw the line of what OFN does and where we integrate with others? If we want to do too many things, we won’t do anything properly… I think there is some form of consent on this from the previous discussions. But still that’s always a possible answer to the above needs.

2- Develop a specific connector to integrate with a specific external system. For instance @oeoeaio has built some "script" to integrate OFN and Odoo POS. Zapier is a form of connector that @lin_d_hop has developped between OFN and Google Sheet to build custom reports and dashboards.

2.1 That connector can directly call the database. That’s what we do today with Zapier and some manual scripts. This can be a quick patch but present a certain number of risks on the long run:

  • if external system directly connect to DB, if we decide to change the DB they will be impacted, and we might not know exactly who uses our DB data for what: can you imagine the process of changing a DB that everyone (from outside) is accessing with their integrations

  • external systems consuming data directly from DB could involve random load on a production database so performance issue (ex: users will write the wrong SQL query and break our prod database)

  • there can be data security issues

  • each new specific system we want to integrate with will require a specific connector.

So it is quicker, but it’s like a patch, it’s not a long term solution, and it is highly problematic on a long term.

2.2 Or it can consume the API. So you can still use easy to set up connectors like Zapier, but they consume the API and not directly the DB.

  • it requires the API to exist of course so it takes a bit more time and investment on short term

  • but it’s much more scalable, less security issue, it’s easier to maintain and manage the API than all the separate random integration plugged directly to database, easier to profile the clients: know exactly what clients are doing what in our API, etc.

3- Clean and refine the OFN API so that it can be used for that specific use case, but to connect with any external system. It means a bit more investment as said above, but there is already something, we don’t start from scratch. We can use unmet needs to step by step build our API and consume it to answer the need. It seems like the only reasonable path for a long term strategy. it can be used with or without an integrator tool like Zapier. A dev could deploy Odoo and connect through both APIs OFN and Odoo for a specific user who needs POS (on a short term).

SO I think, and we discuss sometimes with @luisramos0 about it, that on how to answer all the needs above, we need a clearly affirmed strategy. That will drive the choice we make among all the possible solutions. Sitting where I am, I see 3, eventually combined with 2.2 as a valid strategy. I’m not a tech, but I’m working on some projects with other platform coops on interoperability and that’s the direction all platforms are going toward. If we don’t go that way, we are going to miss the train.

I stop here and will continue on the specific POS use case to move forward on a concrete case.

13

It seems to me we hastily went to the POS integration issue here - without discussion about other possible integrations - as the list @MyriamBoure mentioned at the outset. I’m wondering how many of our users need the POS integration versus how many need more help with marketing - which would take us to some kind of integration with mailchip or other. have we already decided that POS integration should be the priority? I just want to again argue the case that every single enterprise needs to do marketing. And nothing in OFN right now is making that easy. so the potential benefit of pursuing an integration that every single user could use carries weight with me. Do we know how many of our users would use POS?

14

I wouldn’t object to start with another integration, it’s just that users needing POS are big enterprises blocked to use OFN right now and that could be money contributors to the project and also be good windows to showcase. In France they are recognized actors. But we can still discuss… They also need marketing but today they use open source mailing lists tools and not mailchimp for instance. Or customer reports/dashboard for me is even the top one priority as every hub have their own way to set up their packing sheet, etc. I suggested maybe @lin_d_hop could drive that project from wishlist to implementation as she has already work on some first step of it.

15

I understand that Katuma have / are doing some work on integrating OFN and Odoo in some form, is that right? If so, any chance @sauloperez @enricostn could give us a couple of sentences about what that is and where it’s up to? Also @lin_d_hop have you done any zapping to odoo, and if so what for specifically?

16

Nope, sorry it’s still just a desire. I could share the very first rough MVP we thought of for one of our clients, which sadly won’t see the light for now.

17

@sauloperez yes I would be interested in the mvp and any thinking you’ve done. Seems like momentum could be building in that direction around here

18

Just commented here @Kirsten but hopefully @Sacha might be able to propose as a project to his Ruby students team to develop a very first MVP standalone website consuming OFN API to show products from OFN database in a custom shop/ecommerce website. Let’s see and cross fingers that can happen !

19

Ok, now that I’m back to Coopdevs office I can share the notes we took about a possible MVP of an Odoo integration.

Context

This came up after talking to Capfoguer, craft beer makers, good friends of us and now clients of Coopdevs (the ones who made the Katuma beer). Their need was to improve their processes in order to reach more customers by owning a bottling machine. They are putting lots of effort into buying one. It’s the next big step in the project.

It turns out (what a surprise) their biggest pain point so far is to manage the relationship with their customers such as restaurants and bars and invoice them without suffering. They now do that with google spreadsheets. They also acknowledge the fact that this process is quite inefficient now.

They also thought it could be a good move to also start selling the new bottles online on Katuma.

Odoo-OFN integration POC

@enricostn and I gave it a quick thought before having our first meeting with Capfoguer but this soon fell off the quotation as they have little money to invest. This is what we thought about.

Customer creation

When a customer is created in OFN, the same data is sent to Odoo so that the same customer is kept in Odoo. Considering OFN as the single source of truth, we would need updates and delete to be synced as well.

Order creation

Likewise, since the idea was to get orders from Katuma, we would need orders to show up in Odoo as well. To make things lean, we thought of leaving product catalog for a later iteration. Then, the trade-off would be to populate Odoo invoices with simple text entries out of the line items in the OFN order. Meaning that the actual invoice lines wouldn’t be associated with any product in OFN; just textual information.

All this is very specific for this case but it can bring some ideas.

As I said, the agreement we reached with this client was to just introduce the very basics of Odoo into their stock management and invoicing processes. After that, we’ll see what’s the next iteration. Hopefully, joining Katuma.