Hi Instance managers ~ @instance_managers We wanted to get feedback on the below use case (square <> OFN) and whether there are other live use cases for this user problem (assuming yes looks like this has come up before) Currently, we have a hub that uses OFN as the source of truth for inventory and Square as the source of truth for point-of-sale (POS) data.
Because these systems don’t talk to each other, reconciling stock levels before the weekly store opening requires significant manual data entry - creating a risk of overselling and admin.Open Questions for the Community
How are other hubs managing the friction between POS (Square/Shopify) and OFN?
Are there any indications of appetite for an OFN-native payment/POS solution, or are people looking toward specific alternatives to Square due to fee structures?
We are considering two pathways for the integration and are open to co-funding a feature that benefits the wider network - payments is out of scope at this stage. Have you built something similar? Would any hub be interested in co-funding a standardised Square-OFN connector?Option 1: Feature Integration (High Effort) A dedicated Square/OFN Connector utilizing the Data Food Consortium (DFC) protocol.
The Goal: Real-time bi-directional stock syncing.
Pros: Highly reliable, interoperable, and aligns with the DFC focus on farmer control.
Cons: Higher development cost and longer timeline.
Option 2: The Middleware Automation (Lower Effort) A workflow via a third-party tool (e.g., n8n)
The Goal: A simple “trigger” where a Square sale automatically deducts stock from the OFN inventory. Square does not track stock.
Pros: Faster to deploy and lower upfront cost.
Cons: Assumes that OFN Order Cycle is closed when the in-person shop is open. Also more risk of breakage/ requires ongoing maintenance.
Hello!
We have many questions from users regarding links between OFN and POS or invoicing software. Meanwhile, we were never asked for a Square connection, as, while it is now available in France, it is not widely used.
I am not sure if your use case is:
people use Square and they need a link with OFN
people need a POS linked to OFN
As OFN, I think we aim at building digital commons, so I would not advise investing too much in tools that tie our users to “Big tech” firms.
Regarding my point 2, in France we are currently working at linking OFN with Dolibarr, a FOSS ERP with integrated POS. Please ask if you are interested in more insights.
Currently in the UK we frequently get enquiries from existing and potential users about whether or not we integrate with Square/any POS system, but as far as I know we don’t have any who are managing both simultaneously (e.g. if any hubs/shops are using a POS system, it’s managed separately to OFN without any input from me!). When I’ve suggested building an integration as an option users generally don’t have the funds, so it’s yet to progress.
I’d be keener on option 1 for longer term benefit and utility - however I agree with @nicotentin that tailoring it to one for-profit POS system doesn’t align with our values, although of course the more POS systems we try to include the greater the development required. It makes sense to continue working with the DFC protocol especially as I’d think it’d be easier to work on payments at a later date using DFC
My concern with option 2 and using n8n is that it would be rather resource intensive to run for every interested enterprise as I imagine it would be popular and require a lot of maintenance & user support. I’m not sure why the OFN OC would need to be closed when the in-person shop is open though as it’s possible to update stock levels during an open order cycle? Also there is already a Square integration for updating stock levels referenced in the API user guide (I’ve not used it) so is the idea to build on/rebuild this? Said workflow might be the reason you mention OFN OC being closed
I am having trouble teasing out the issues here - so posting how I think of it (which could be totally misguided - so please be patient with me)
Inventory mangement - I think this is a separate issue from the Square integration issue. Mosts of our users are farmers selling through hubs. Farm products are not shelf stable. They are out there growing each week in climate chaotic conditions - which is what OFN was built for (ie our approach to ‘cycles’). So these suppliers/farmers need to update their inventory weekly regardless of the POS system used. So - I’d put this as a separate issue. We need to do more improvements to help our farmers manage inventory - regardless of how payments are taken by the seller. (We’ve already started down this path).
Order creation - currently our users who sell ‘in person’ are struggling to create, or add to existing, OFN orders at point of sale. it takes way too long. It isn’t the payment that is the issue (most take cash anyway) - its the order creation/management. Does it help us if we focus instead on better UI for order creation/addtion? I worry we could spend time integration a POS payment system - only to discover that the real issue is creating/adding to orders.
POS payment management - currently our users who sell ‘in person’ often open a separate ‘market’ order cycle so the customer can authorize a credit payment. Currently, our OFN-Stripe integration does not allow the seller to hit a card for an outstanding balance. Would it be better for us to focus on this? If a hub could hit a card for an outstanding order balance, then at POS - the hub just needs to add the in person purchase to an order (simplified as noted in 3 above) and hit the customers’s saved card.
On a personal note - I currently offer Square on my own farm to take payment for POS purchases when a customer wants to pay on credit. So my OFN orders and my square orders are separate. Ingetrating these would not help me because most of my in person sales are cash methods anyway. (Here in Canada people prefer to pay by ‘bank transfer’ using our domestic ‘Interac’ system because the square and credit card fees are too high.) So given, farmers have to keep separate records of cash sales anyway - so not sure how useful a POS integration is.
I think this is worth exploring further, so I’d suggest leaving some time for folks to engage, and possibly sending out a couple of follow‑up pings on Slack or similar channels (happy to assist with the latter).
I’m not too keen on the n8n approach, except for a few tightly time‑bounded rapid prototyping experiments to learn more. It’s proven too brittle and slow for us to consider incorporating into long‑term workflows, in my view—outside of fairly simple use cases like sending newsletters or updating Google Sheets/Airtable, etc.
Is this a project where we could try out Claude Code and see how far it gets? With the right guardrails in place, it could be a good test case. (I think Colin Stewart at MO could give us some good general pointers on who to set up workflows etc).
It would also be worth checking in with Gareth at FDC to hear more about what they learned from building their Shopify apps. There are likely a lot of relevant lessons we could take on board before committing further to this work (what to do, what not to do etc).
To Theresa’s point, it would be good to gather more feedback from producers and hub managers. I imagine there are many folks who already keep separate records of cash sales, so it’s worth validating assumptions and hearing more directly from users before committing. That said, integration with Square POS did emerge as a key use case from @Rachel’s work on the CQCM project, if I’m remembering correctly - be curious in her take on the value of this use case.
A couple of final thoughts:
It would be good to explore whether it’s feasible to build something that works with multiple payment connectors (i.e. not just Square).
A POS connector could be useful to other organisations within the DFC ecosystem. It’s likely worth exploring whether groups like FDC or LiteFarm would be interested in this functionality, as that would have implications for both how we build it and how we fundraise around it.
That’s a very good overview of in person sales for those of us that sell in person and through a hub. I also track in person sales separate from the online sales. Almost all of the in person sales are cash or market scrip and few or non of them are credit/debit card on a given market day. One trend I’ve noticed is that many shoppers and vendors are taking electronic payments with their phones. Venmo is becoming more popular with both customers and vendors. Stock management for sales of perishable products can be quite different than for sales of shelf stable products. Something to keep in mind when considering this topic.
Thanks everyone for your responses, they are most helpful! Genevieve is going to reach out to Garethe. I would love to hear from Rachel too.
That looks really interesting, thanks for sharing. I’d like to know what stage the project is at, and what technology has been used to implement it. Is it something that could be publicly documented for other users and perhaps a new section on our OFN API Handbook?
I was considering a much simpler integration because I implemented the referenced solution last year, and it turned out to be quite a bit of effort, and is still clunky and error-prone, so would like to avoid it if possible.
The other proposal would be so simple that Square would not actually check if the physical stock has been reserved by an OFN order, so it would be possible that somebody could order the last bag of apples online, then someone else could come to the shop and take it. Therefore it’s not a great option, but could be acceptable for the two stores we have discussed with so far.
I’ve been wondering this, so it’s interesting to hear it is the case. We could (for example) improve the current system, or consider creating an alternate POS-like interface that is tailored for that situation.
Of course, this would not be a complete solution for shops that want more POS features like selling by weight and integrated card payments.
That’s a clever idea! Your two suggestions are useful individually, but complement each other nicely.
You are definitely right on your last point, but time is missing for the moment !
Regarding the connection between Dolibarr and OFN, there are two aspects:
1 internal tool
we use it to invoice our users. For this we had a module developped for Dolibarr (that we use as ERP for CoopCircuits). It is not perfect but is a huge improvement. This plugin is available here. Of course it is taylored to CoopCircuits needs but could be adapted.
2 a tool for shops and hubs
Workflows Created for Les Goulues
(flows can be shared privately)
I already use it for my own needs. It uses N8N. As is it is not suited for medium user.
Creating an Order in Dolibarr from Sales Cycle Orders
This workflow does not create one Dolibarr order per OFN order: it combines them all into a single Dolibarr order.
The link between OFN products and Dolibarr products is made using the product code, which must be the same on both sides.
Use case: sales to individuals, allows managing stock and generating a global invoice for the sales cycle.
Adding Order Numbers
This workflow is used after the previous one and allows adding the numbers of the orders that were grouped together as a note on the Dolibarr order.
This information is then used to reconcile Stripe payments.
Creating Supplier Orders from OFN Orders
This workflow retrieves orders from a hub over a certain period and creates corresponding supplier orders in Dolibarr.
This allows sending purchase orders to producers so they know what to invoice and makes it easy to later record their invoices based on the purchase order information.
A tool to help a hub invoice pro customers
I am currently building N8N flows allowing a hub to transfer orders from OFN to Dolibarr. It is a first step as we aim to have a Dolibarr module developped with wider specs. @Rachel is working on the specs.
Further projects
Later we want to build a proposition of Dolibarr instances working together with OFN/CoopCircuits. It would give shops and hubs access to many features including POS and invoicing compliant with moving regulations.
