Hi all,
Thought I’d weigh in, because we’ve struggled with almost every single one of the issues raised here over the years. Just for clarity: I work for both the Baw Baw Food Hub (as warehouse manager), and also for the Open Food Network (as web developer). I am writing this with my food hub hat on, but with an obvious bias for the solutions offered by the OFN. 
I think designing with interoperability between platforms/solutions in mind is vitally important, so that users can take the parts they need and make them fit together in a way that works for them. I think Graham’s approach of integrating with other platforms via APIs or dedicated reports is the right one, and I would encourage all of us who are developing solutions to keep these kinds of discussions going - I think they are really valuable.
Where I’m coming from
The Baw Baw Food Hub runs a subscription-based weekly veggie box program and retail space, currently servicing about 160 households per week, which we run out of a warehouse in Warragul, Gippsland. We offer delivery, but this is only taken up by about 5% of our customer base, despite being offered below cost. The vast majority of customers come to the hub to collect their orders and purchase other products - we think mostly because they like the community and social aspects of it!
Online Store
We accept online orders for “casual” (non-subscription) boxes, as well as for “extras”: a wide range of locally produced foods, from fruit, spreads, breads, dairy products, meat, dry-goods and prepared meals. These are received via the Open Food Network, which collates our orders and has a range of reports which we use to print out order labels (via a spreadsheet which formats the report).
The OFN offers a range of options for restricting who can access a given store. Stores can be completely open, or can set up a white-list of customers who are able to purchase from the store. In the latter case, store managers can opt to allow the general public to see which products are available, but only allow purchases to be made by approved customers, or alternatively they can just make the store completely inaccessible to anyone who isn’t approved. At the food hub our store is open, so we accept orders from anyone.
At the moment, we redirect users to the Open Food Network store from our own website, and we have very few problems with this. It would be nice to have more of our own branding and to remove the dislocation of moving the customer to another site, but this is not a high priority for Baw Baw at present. It is for others in the OFN community though, and the UK team have almost finished work on a first cut of ‘embeddable shopfronts’, enabling stores to embed their shopfront operations via an iframe in their own website. This means customers place their orders ‘through’ OFN without ever leaving the Hub’s website. We anticipate that this will be available in Aus in the next few weeks.
Subscriptions
At present, we receive new subscription requests via our website (which I built as a bespoke solution for us, so unlikely to be of use to others), and are managed via another spreadsheet.
That said, I have spent the better part of the last year working on a new subscriptions feature for the Open Food Network, which will provide an extremely flexible and reasonably sophisticated system for handling a range of subscription models, fully integrated into the existing inventory management and e-commerce elements of the OFN platform. Editing (in bulk or individually), cancelling and pausing of orders is definitely something it will be able to handle. It is built around the OFN’s “Order Cycles” system, which means that frequency can literally be anything you like (weekly, fortnightly, third Tuesday of every second month, etc). It has also been the primary impetus for the integration of Stripe payments into the OFN, in order to allow for automated payment processing of subscription-based orders. The first iteration of this feature is focussed on subscriptions that are created by the shop owner rather than the customer, but customer-created subscriptions will follow.
There has been talk of developing ‘customer wallets’ as a payment option within OFN, so people could top up and draw down credit, but we are going to see how many people actually still need that once there is a good ‘on demand’ credit card processing system in place. The OFN already supports Paypal, Pin Payments, eft and cash - but no bank reconciliation (and it hasn’t actually really come up, not sure why).
At the food hub, we anticipate retiring our existing subscriptions spreadsheet and migrating entirely onto the OFN platform as soon as possible.
POS
The only other feature required by us before we can migrate our subscriptions across is a “point of sale” interface, capable of creating/loading, adjusting and processing orders as quickly as possible. I too have played around with countless options for point of sale platforms, including Vend, Kounta, Odoo and Shopify. None of which really met our requirements. Our main desire is for a system that can be used for both adjustment/processing of online orders and the creating of ad-hoc orders for walk-in retail customers in a single interface, and preferably with a single inventory management system.
Since we made the decision to use the Open Food Network platform to handle our subscriptions, I have also been focussing energy on the development of a “point of sale” system for the OFN. I use quotation marks because the initial cut is very unlikely to include any hardware integration (scales, thermal printers), which some may consider integral components of a true POS. It will be focussed on quickly loading orders, making adjustments, making notes, and processing payments. I would be very interested in any input with regard to the requirements others have for point of sale.
Customisations
From my perspective, one of the fundamental decisions that contributes to the workability of our particular model is the way we handle customisations (basically, we don’t). All boxes are packed as standard (in three sizes) and any customisations are performed by the customer using our “swap table”: a table at the hub that everyone can swap produce into and out of, using a value-based guide describing what constitutes a fair swap. We find this works very well, even for those with intolerances, or those who have productive home gardens over summer. I recognise that this is not a viable solution for others, but I thought it was worth describing where we are coming from, and why our requirements are the way they are.
Box planning
We plan our boxes using a spreadsheet that we developed ourselves. Given that there is no requirement to take customisations into account, I imagine this is very simple compared to what a lot of you are using/developing. It works extremely well for us however, and incorporates our wholesale and ad-hoc orders as well. It also generates a packing sheet for our three box sizes.
‘Box planning’ / ‘box building’ is on the OFN wishlist and there is some community discussion (including links to some other open source CSA software projects) here - but it is not imminent. It may increase in priority once we have launched the subscription features and therefore have more ‘csa-like’ users.
Accounting
OFN does integrate with Xero (via specific report designed for easy upload) but we don’t use this at the hub.
Wasn’t sure how much would be the right level of detail in this response, apologies if too much and if too little perhaps check out the OFN feature list and/or user guide.
Rob
