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 . .
Above @lin_d_hop identified 3 integrated issues related ot this:
- 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)
So #3 is already being pursued - @Kirsten - I think you are doing this .
#2 - putting names on the notify producer emails - might be ‘nice to have’ - but not essential (and has the limitation that the supplier has to wait until the OC closes to see the info - which is a big drawback). Plus if we have #1 - don’t think #2 is that critical.
#1 - is where this all started - wanting a supplier to be able to run a report and see who bought their goods. I’d say that just solving this piece is the focus. Can we move it forward?
yep #3 is now in an issue at https://github.com/openfoodfoundation/openfoodnetwork/issues/4378
I endorse #1 moving forward. But we need someone to drive that. With a very strong view to the quickest / cheapest way to get basic outcome. I suggest you bring this to the product curation meeting next week @tschumilas
Alright, so I need some feedback before going further into this inception. In particular, after reading several times all the discussions, I 'm a bit unsure of the scope here
- The need is to be able to prepare the individual orders so anything that helps supplier to know how much has been ordered this week is I think out of scope, and belonging to => Inception session: delivery note
Do we agree?
- About customers name and email : I’ve asked some of our hubs about this and they agree that for some cases, they don’t want the supplier to know the name and email. Not because of data privacy but because they don’t want the supplier to be able to contact their customer. Does this ring a bell for anyone?
So I ended up asking myself why suppliers would need to have the customer names? Is it only in order to know that the customer ordered several times during the OC or that the buyer is a recurring customer?
Because if this is the case, I would like to propose something different: assign a number to the buyer and display it inside the reports. This number would be always the same for the buyer of a particular enterprise.
The hub has a list of buyers with their associated numbers. The suppliers then pack products per number and not Name/firstname/email.
The suppliers I asked about this agreed that they don’t need customers name and email: the number would do the job for them.
But maybe people I have interviewed have biases so I really would love to hear about others on why the customers names and emails should be important for the suppliers. Thank you in advance
Also note that I’m proposing this because in the (French?) invoicing system a buyer should always have the same number associated to him. The number should start with the buyer number and end with something unique to the order.
So we will end up creating this number at some point, whereas having to implement a privacy / permissions feature is something additional, and maybe just for this case?
- While working on this I have been constantly draw to Hub can easily generate accurate packing slips
So I’m having scope issues. I’m thinking that if we manage to get a packing sheet for hubs, isn’t the supplier packing sheet just a sub-permission?
So I’m a bit unclear of the scope here.
As a side note, here is all the problems I have seen in our current reports that prevent to really be able to cross read and compare info from the Orders page vs. the reports but also when comparing reports:
- No reports are showing the order date. So there is no way to find the same order list shown in the order page on a report.
- When matching product data across reports, you need to merge Producer & Product name & Variant. But variant names are not displayed equally through all reports. See the excellent work @tschumilas has been doing to follow up the problem here: https://openfoodnetwork.slack.com/archives/CG7NJ966B/p1572299037088400 This means that you cannot match the data coming from the report
pack_by_supplierand the report
Here in Canada, I have 2 hubs where the suppliers need to pack the orders by customer and they need to know the buyers identity: 1. the Flower hub and 2. a hub that sells to restaurants… In both cases, there needs to be frequent communication between buyer and seller (how open do you want the flowers? is it OK if they are a bit more orange? Can I substitute red leaf for green leaf lettuce? …)
In both our cases, the hub prefers that the suppliers contact the buyer directly on these issues versus being ‘in the middle’. (Very interesting that your hubs take the opposite perspective in France!) Right now, the workaround these hubs have is to run an OC pack by customer report for each supplier, and post it on a google sheet for each supplier. But the hubs only do this once the OC closes. If the producers could see buyer identities, then they could contact them while the OC is still open and perhaps even steer people to other purchases… It would lesson the stress of doing all this in the few hours between OC closing and deliveries starting (producers are so busy in these few hours doing harvesting…)
Having numbers for the buyers could work in both situations - where the hub wants to be in the middle (France) and where the hub does not want to be in the middle (Canada) of buyer-producer communicatinos. Basically - when the hub WANTS the buyer-producer contact (as in Canada) then the hub would give each supplier/producer a key (buyer number = buyer name). Knowing this, the supplier/producer can monitor purchases of their products, while the OC is open buy using OC reports. And, when a hub does not want this producer-buyer contact (in France) - then the producer would pack using the number, and wouldn’t know the name/identity. Of course this code or ‘key’ approach would only work in wholesale type situations, where the buyer is repeat and their identity known.
The other thing that might relate here - There IS a code field in the Pack by Customer report. This is the code that can be assigned to a buyer in a shop’s customer list. (The flower hub uses this to write in the name of the company - so its easy to match up with an individual’s name & email). But at present, a producer can’t access this report for a hub they sell into. They can only access it for a hub where they are also a manager. (So not sure if this is helpful or just adds to the muddle.). If we add a new variable - lets just make sure we don’t confuse it with this current ‘code’.
I don’t think this is quite the same need as hub can easily generate accurate packing slips. The current need is for a supplier to see what is going on (who has bought their stuff) while an OC is still in operation - so ‘notify producers’ or hub packing sheets - would all happen after an OC is closed. I think the strength we have in reports, is that there is loads of info there for suppliers - if they have a way to see it.
I think order date on reports would be fantastic. The hubs here need to regularly allocate product in short supply to people who ordered first. To do this now, they have to go through the orders list (which appears in sequential ordering order). And of course - concurring on variant name issues.
@tschumilas and what prevents in your case the idea of giving manager access to the producers? The fact that they would see other producers data?
because it looks to me like a producers’ hub and indeed not a hub = middlemen. We also have this case in France and producers just share access to the hub.
The other thing that might relate here - There IS a code field in the Pack by Customer report.
Ah interesting! I’m going to check this out! Thanks.
The current need is for a supplier to see what is going on (who has bought their stuff) while an OC is still in operation - so ‘notify producers’ or hub packing sheets - would all happen after an OC is closed
But you can use these features any time currently, especially the reports.
The hubs talked about making producers managers. But 2 reasons not to: 1. yes, the producers see each others data (many producers don’t want other producers to see their sales) and 2. there is some worry that too many managers (it would be over 50 in one hub) carries a risk that someone messes some other setting up.
The hubs here exist to aggregate product - so in that case the hub is a ‘middleman’. The producers want to aggregate into one shop because 1. it attracts more buyers (seeing everything together) and 2. it is more efficient transport (distances are quite large) because each producer doesn’t drive to each buyer. So - middlemen in terms of aggregation, transport, but not middlemen in terms of seller perhaps.
Yes, the buyers can ‘track’ sales now in reports (ie: they can run an OC suppliers total report for their own farm) but they just can’t know who has bought these products, and therefore who to contact. So they have to call the hub and say, ‘someone bought 5 bunches of astilbe, and I don’t think its the right colour, who should I contact…’ They want to do this before the OC ends because the buyer needs a product to make something and they want to work with the buyer to get them what they need.
Maybe this is a particular problem for hubs (producer aggregations ) where the buyer is some type of artisan (ie: high end floral designers, high end chefs) and there is a need to make sure the buyer knows exactly what they are getting… I doubt very much if consumers would care about the same product details.
I think the issue you raise @Rachel (2) is the one that was the reason it was done like this in the first place. That Hub’s are a ‘middleman’ and that they don’t necessarily want all the producers to have all the customers names and contact details as it might encourage them to circumvent the hub. I don’t know how much of a problem this would be in practice but it was very clear what they wanted at the time. I have imagined that this feature needs to be a ‘choice’ at the Hub level, depending on the situation, that they can allow Producers to see Customer details or not. I think that opening it up to all with no opt out would cause plenty problems
Alright so I’ve added a call in the agenda on Monday March the second at 10pm CET to chat on this topic.
In particular I would like to go through three topics:
- From your feedbacks @Kirsten and @tschumilas I conclude that we need to be able to let the Hub choose whether or not he wants to share this info with their suppliers.
The first place to do this that comes into my mind would be to create a new enterprise permission:
Which would be called something like “To see customers names in reports”.
However, and this has been mentioned earlier in this conversation by @lin_d_hop and @MyriamBoure , it would be cleaner if the buyer is aware a hub can do that.
The ToS of the hub should mention this (of course we could argue that no one reads them, but it is I think a minimal requirement).
So I wonder if Hubs can ask their customers to validate their own terms and conditions isn’t a pre-requisite here.
Ideally, if a manager checks this new permision checkbox, we could display a message encouraging him to add this info to their ToC / ToS.
Also, I wonder if this solve this need or not. Especially: do we have the case where we want suppliers to prepare individual orders but the hub does not want them to contact the buyers?
I believe this can happen in France, but this is not a priority right now, so I would leave it for later. But this needs to be validated by the community.
Second topic: the customer name and emails within the notify producer emails. I don’t think this is necessary if the reports are working, but let’s talk about it!
The consequence of enabling producer to see customers details, is that they will start packing, and then hit the same packing problems the hubs have currently when they need info that are not in the packing report So I see an increase in support time after we release this. On my side I won’t have only one person asking for stuff, but probably 20 per hubs
So I think I would like to discuss the idea of coming up with a user guide section on “How to pack orders”, with the current OFN set up. I believe this would help us to settle the ground for Hub can easily generate accurate packing slips or at least gives me a better view on how other instances are helping hubs to do that currently. As a support person, this is a pressing need, but maybe I have been advising my users wrong.
So in short my conclusion is: improving the packing reports is out of scope here, but I’m afraid that improving our documentation on how to use the reports to pack is not, given that after releasing this even more people will start to do packing.
Thanks for the clear thinking on this @Rachel to guide our discussion. I concur that this is linked to packing reports - even though I only have 2 hubs who have suppliers pack, it escalates the requests for support because this means 20 suppliers who will be totally new to OFN backend will contact me. Lets talk about how to make an easy process instruction for them. Packing orders could be the only thing they ever do in OFN. They might not even realize that they have profiles set up at this point. Good call.
We agreed that displaying customer names and firstnames only would already answer 90% of the need. This seemed a good way to compromise between shops who don’t want the producer to get the credentials, and shops who do need them.
Releasing names only first can help us get feedback on how many people will really need the full credentials (emails, phone number etc), and then iterate.
If we only have to display names and firstnames, this can be done over a switch in the shop preferences section rather than enterprise permissions. The switch would be “off” by default (producers can’t access names = current situation). I guess we will definitely settle the place (permissions vs shop preferences) once we have dev feedback on this. Maybe there is a place easier to maintain.
Also, if we do a switch we can take the opportunity to set up a Matomo event on the switch and check how many shops do turn it on?
We have validated that we don’t need to do something about the “notify producer” email. This email is triggered only at the end of the OC, which is too late anyway.
And further clarifying - the names would be displayed on all reports that have those columns now - correct?
yes that is correct,
I could take the lead as @luisramos0 is on top of way too many thing. But first I have to get familiar and fully understand what this is. I haven’t followed it closely.
I’ve not gone through all the details but I think this is useful at this point:
- if we are adding a enterprise property like “this enterprise allows all producers to see customer details” - this will be much easier to do on the report and it will be a check on the enterprise for example in “shop preferences”
- if we are adding a relationship between specific enterprises like “this enterprise allows THAT producer to see customer details” this will be a new enterprise permission and will add some extra complexity to the report