Hub's suppliers can prepare the invidual orders for the hub's customers

I won’t be there. I have flagged it in my notes to @danielle here and you could add your chorusing voice if you like :slight_smile:

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 :confused:

  1. 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?

  1. 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 :heart:

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?

  1. 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? :upside_down_face:

So I’m a bit unclear of the scope here.

I guess a call would be better - I’m not sure I’m making myself clear here :eyes: Maybe on next product curation meeting? ping @lin_d_hop @danielle @Kirsten

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:

  1. 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.
  2. 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_supplier and the report order_cycle_supplier_totals

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 :smile:) 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:

  1. 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.

  1. 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!

  2. 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 :scream_cat:
    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.

1 Like

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.

@tschumilas @Kirsten here are my notes from last week, sorry for the delay:

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.

Finally we still need a tech lead on this: @sauloperez @maikel @Matt-Yorkley @luisramos0 anyone? :slight_smile:

And further clarifying - the names would be displayed on all reports that have those columns now - correct?

yes that is correct, :+1:

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.

1 Like

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

For the current cases in OFN-CAN - it can be an enterprise property - so that the selection applies to all the hub’s suppliers. We don’t have a use case right not for only specified suppliers to see customer details. @Kirsten @Rachel - what about for you?

I have to say that logically - if I was a new user - I would think of this as a ‘permissions’ thing before I would assume its a ‘shop preferences’ thing. So for me, there is logic to doing it in permissions. The hub is on this page anyway - thinking about what permissions to give suppliers anyway. So - eventhough there is no use case for this right now, I wonder if its a better way to go.??

I think that on my side we can do it as an enterprise property for now. What do you think @Kirsten ?

The amazing @sauloperez suggested that we add a message on the report for the suppliers trying to reach a hub’s report saying something like: “By default the customer credentials are hidden, if you need to access the customer’s name, please contact the shop you are working with” (we need to improve that sentence, but it is just an idea).

At least we would have question from hub on how to do it and we can redirect them to shop preferences? What do you think @tschumilas ?

this is an amazing suggestion from the amazing @sauloperez !

How amazing you all are, amazing people hahaha.

We could even add a link to the actual page in the guide so that they can tell the hub, “hey, guys, you just need to do X”.

I think:

  • enterprise property is fine
  • hubs generally aren’t setting up permissions for producers, producers are doing it for hubs. So sending the hub into enterprise_relationships is confusing. They will be more familiar with the shop preferences
  • Perhaps we can have some sub-headings in the shop preferences, for settings that affect customers and settings that affect producers - then it will be clearer
  • agree with the sentence on the report page. Should include contact the shop and ask them to set the ‘show customer details to producers’ setting ON (so the Hub knows what to do when the Producer asks them)

Are we clear? Let’s do it!! :wink: farmers markets onboarding - i think this will be needed by a lot of people quite fast

Thank you for your feedbacks :slight_smile: I feel I have everything now to prepare the issues.

Just a few comments:

We could even add a link to the actual page in the guide so that they can tell the hub, “hey, guys, you just need to do X”.

The link would be different across local user guides. What was your idea @sauloperez ? Put the link in translations?

hubs generally aren’t setting up permissions for producers, producers are doing it for hubs. So sending the hub into enterprise_relationships is confusing. They will be more familiar with the shop preferences

In France it’s quite the opposite… Hubs are managing their producer profiles, so they are constantly managing permissions…
If one day we will want the hub to be able to fine tune the permission per producer, we will need to go through permissions. But for now I agree we can leave it like this.

Should include contact the shop

Let’s not forget we can have the case of a producer working with several hubs… this is adding the complexity of looking into the data to see which hubs has set it to ON and which didn’t. What do you think @sauloperez ?

I will prepare the issues and put the links here

I don’t have a particular idea. We can consider making it translatable or configurable by other means. Or we can start without the link.