So where and when do I make this ‘pitch’? Happy to do so. But my mind is to a larger discussion I recal from our Australia meeting and am looking for thoughts @MyriamBoure @Kirsten. I remember a discussion about reports where we were imagining the possibility of (I have the language wrong here) a system where a user can customize their own reports, rather than having OFN pre-made reports (or a combo). So as a user, I would go in and choose the data categories I wanted in a report and generate whatever I wanted. We did not prioritize this. But now I’m re-visiting because there are a couple of report-related issues looming here - the fees report, the above issue, there is another issue from @CLFC re: combersome way of using existing reports to generate customized producer invoices… So - all these 3 issues would be solved (?) if we went down the customized reports route - no? Is this worth a re-visit? (I LOVE the way you’ve taken on this syncing work @CLFC and this kind of thing could surely solve some of our challenges short term.)
Whatever this “hidden” thing needs to be worked on before you get any data in your reports so it needs to be done first @tschumilas Then about reports if you think it is more prioritary than split payments (the other big job as rewritting reports and generate a big one will be a big job I guess) you can still share your arguments in the other thread. Apart from Split payment the other things are not big big things, we don’t want to have many big things at the same time as it becomes unmanageable. Especially for now that we have the Spree upgrade…
I’m a fan of that idea @tschumilas. Having customizable reports that give shops/hubs access to all the data OFN offers (which is a lot, and that’s awesome!) - but letting them choose the data they need - would be great.
I also agree with @MyriamBoure though, it’s a major overhaul of the reporting system, and that’s a big job. Not just from the coding perspective, but also from the design perspective. How do you make the UI simple and understandable … and turn that into an easy to read/use report with so many variables. It can certainly be done, but it’s not a small task.
The coder in me wants to dig into it and try to make it myself. But I’d have to learn a couple of new languages and frameworks first, and that takes too long. lol
Both are important here and in fact users use 3 different methods for packing their orders:
- Notification emails
- Order management
A solution should take all three into account otherwise it will only be a partial solution satisfying a subset of users.
I’d like to propose that in this issue we package three different issues that continually are raised:
- Reports: Hub's suppliers can prepare the invidual orders for the hub's customers
- Emails: Notify Producers email to include customer details
- Order Management View Enable to identify customer on orders view (this is a different issue but there is overlap)
The packaging of these three issues solves a often raised UX issue for producers in a complete way and gives a level of consistency to the UX which would be missing if only one of these was tackled.
In defining potential solutions to this issue there is a forth step to include, mentioned in many places:
- Create a UI that allows Hubs to share customer permissions with Producers.
This final step is important for GDPR reasons as stated by others above. The UI should allow sharing for customer details on a producer by producer basis.
So if I read you properly @lin_d_hop you are starting to do some inception and share reflexion about the scope of this feature
So the need remains to enable producers to easily prepare the orders for the individual customers. For that you suggest that there should be multiple stories:
- the producer needs to see customer name in reports
- she needs to receive the customer details in the notify producer email ? (I would personally discuss that, I disagree, I think if we include all customers detail the “summary” email of what was ordered is going to be huge, I would rather redirect to the reports for customers detail, but I agree that we can at least review the template of the email)
- she needs to have the authorization from buyer to have access to his/her personal details. For me this should be included in the terms of sales and might not require a specific UI. We need to check, but anyway that is part of the scope I agree.
Anyway, the three points above for me will be discussed in the inception stage where we brainstorm about the things to be done and how we do them, if we do all in one iteration or multiple iterations, etc. So I think prioritizing this wishlist will cover discussing those points. So as there are 6 votes I think we are going to do the inception very soon, and if you want to drive that inception you will be most welcome to
About 3. As you say enable to identify customer on order view is a different story, even if as you say I see some connexion (linked to enable everyone to prepare orders, not only producers), I would rather prioritize two smaller features than try to pack them all in a big one that takes weeks and months to do… don’t you think ? If we prioritize 5 small things, then we can have another round of voting for next things earlier, that would be great !
Yeah, basically starting inception based on the fact it has 6 votes and is likely to go through. It felt like between wishlists there was a bit of duplicate based on the actual user need (“Hubs Producers Can Prepare the Individual orders for the hub’s customers”).
So I thought I’d just link things together ready for the inception process so that we don’t miss anything strictly linked to the user need.
I agree that 3 is totally separate, but without 3 for producers this functionality does not satisfy the user need so I thought it was worth linking.
I agree to keep things small. Doing Enable to identify customer on orders view is a tiny issue alone so if that get’s voted as well it would make sense to do it first.
autoCrat is indeed nice option; another, more flexible one is to populate a single spreadsheet from external CSV (OFN report?), and then use other spreadsheets in the same documents to generate different views, report, tables, layouts… opt. with print page jumps, you name it.
The only thing the hub managers then needs to do is link the “template” to the data csv url (maybe with a unique token as security measure), open the template to trigger a data update, and export to pdf (or other).
OFN could then provide for a library of beautiful report templates, adapted by the community.
I adapted the script from https://ctrlq.org/code/20279-import-csv-into-google-spreadsheet
I realize we’ve prioritized this feature. BUT I also know we’ve put new issues on the back burner for at least the first half of the year (I suspect longer). I have 2 hubs where the producers need to know the names of their customers - and they need this now. Can you tell me - what is this Katuma hack referred to and is there a way OFN-CAN could apply this hack - as a temp solution - until the new feature is developed? I’m looking for temporary solutions here. (@CLFC)
I had my fingers crossed that this would have been fixed in v2.1 when it rolled out to Canada, but I see it’s still unchanged. I’m expecting to start officially onboarding CLFC next month (YAY!) but this is one of those small bits that will directly affect our users, since almost all sales are through suppliers, and not from the hub itself.
I’d love to see how the @sauloperez / Katuma hack works for this.
I don’t know anything about the Katuma hack on this, but I wonder if @lin_d_hop could whip up a zappy solution into a google spreadsheet? I could have a go but haven’t attempted any zappy report creation so unlikely to be very efficient . . probably if Lynne helped Canada get zap-ready (or are you already @tschumilas) I suspect @CLFC will be off and running very quickly?
This problem has come again for another user in France. Just noting for memories and future priorization.
We have another hub in Canada needing the same thing - The Local Flower Collective (hub) basically acts as a flow through for suppliers. The suppliers communicate directly with buyers and pack the buyers orders. So right now - the hub (Collective) downloads the orders by customer report as CSV, breaks it apart, and moves it to a separate google sheet we set up for each producer. It works - but of course takes time so we add a percentage into the OC for the hub to cover their time. A zappy report would be marvelous. Idea on cost @lin_d_hop? I’m assuming since this isn’t prioritized for global budget we need to find money to pay for it. @CLFC - would you be prepared to take this out of the CLFC Trillium funds?
It is always hard to cost without a clear idea of what you want
Perhaps you could link me to the final spreadsheets that your users use and I can take a look?
Then I can cost a Zapier solution. Are you currently using Zapier for other things or would this include Zapier set up?
Apologies all, I missed all the above as I haven’t checked the forum for a while… Please if ever I am slow at responding feel free to ping me on Slack
No prob - I’m constantly missing discourse things these days as slack has gotten busier. @CLFC - it would be ideal if you could link @lin_d_hop to the kind of spreadsheet your producers need. Here is a link to the google sheet that the Flower Hub I mentioned uses: https://docs.google.com/spreadsheets/d/1reOkOX0RPMGvtJOpJlnl7FKyqM8O4gAsQ96zrtyUIKs/edit?usp=sharing The hub runs a report (not sure which) and splits the orders by producer. Then each producer has their own google sheet with their orders so they can pack them by buyer. Basically needs: buyers name (email would be nice too for quick access), variant, quantity ordered, and ideally the supplier’s price + supplier’s fees + taxes charged - then they could use this for generating invoices to the hub too. (Although maybe that’s overly complicated). @CLFC - what other requirements would your producers have? If we have a ballpark on cost we can try to move forward. and, no - we don’t have Zapier set up in OFN-Can yet.
My plan is to just run the packing report (as the hub) and zip it through the script I created to convert it to packing labels. It just means I’ll have to split it out into files for each producer and email it to them each week.
I’m not sure how our producers would react to checking Google Sheets - but they won’t have any problems printing a pre-formatted PDF. I may tweak my script a bit before CLFC makes the switch to automatically split everything up into one file per producer, so I just have to download them and email them off.
Essentially, it’s a variation on what Zapier would do … only in a way I understand and can tweak as needs dictate. Our producers don’t invoice the hub for anything - we generate invoices for them that show their sales, minus our 5% administration fee, and generate a cheque list for our coordinator when she’s handling payments. Since my solution will use the OFN-generated packing reports, and runs off CLFC’s existing server, it’s a zero cost solution for us.
I’m looking for any update on process here. I now have a third user that needs the suppliers to see the names of the customers who bought there goods. Today - a farmer had an unexpected frost and wanted to notify the customers who bought their stuff while the OC was still open, so those customers had time to source from other suppliers. The supplier knew WHAT had been sold, but not to WHOM. So - having names of buyers on the ‘notify producers’ email would not have been a solution in this situation anyway. Because the hub would have to cue that email AFTER the OC closes. We need the names of buyers to show in reports for the supplier. Can anyone tell me where this issue is in our process? Frankly - I think the flower hub here could be enticed to pay for this - they REALLY want it.
this seems like another candidate for things that we all agree need to be done and lots of user demand for - but in this case it seems the scope / feature / approach is not clear? If we can get to a clear agreement on how it should be tackled I’d certainly endorse moving it into focus frame . .