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

listed
makeitgreat
global-priority
Tags: #<Tag:0x00007fa95b1a0138> #<Tag:0x00007fa95a0176a0> #<Tag:0x00007fa95a017ee8>

#1

What is the need / problem

Fred needs to be able to prepare the individual baskets for each customer who bought to him through Mary, in order to prepare them an deliver them on the pick-up point.
'> today he sees the individual orders but the columns “customer” and “email” are anonymized.

Who does it impact

All buying groups’ suppliers, in the case where the supplier needs to make the invidual baskets himself before the members’ pick-up

What is the current impact of this problem

  • Time unefficiency for the buying group manager: Today as Fred has no way to get access to a report where he has the name of the customer and/or order ID for each individual basket, Mary needs to spend an hour per week exporting the whole “total order per customer” report, break it for each supplier and send it by email to each supplier.
  • Fred cannot run his sales autonomously: He is dependant on Mary to prepare the baskets he delivers. If Mary forgets or make a mistake, he doesn’t controle anything.

What is the benefit in focusing on this

  • Gain in efficiency for buying group managers and suppliers
  • Shared responsability on the success of the delivery operations

Links to more details


Potential solutions that will solve this problem

  • Integrate Katuma specific hack report (but needs authorisation from hub anyway…)
  • Enable hub to “authorize producers to see customers names”, and remove anonymization in that case

Current top 10 global priorities
Current top 10 global priorities
#2

That’s something we’re being asked for in Katuma. The anonymization makes it hard to prepare the baskets when using the current reports.

What are the implications of removing the anonymization in terms of GDPR? is it something that needs to be purposefully configured by the producer? (please, say no. No more flags :disappointed_relieved:)

Integrate Katuma specific hack report (but needs authorisation from hub anyway…)

I would be very happy to merge this report into OFN.


#3

@sauloperez the agent responsible for customers data here is the hub, so making customers data visible for the supplier is not a question of GDPR for me as it is necessary for the realization of the service. We are not using customers data for any purpose that is not delivering the service that the customer asked for. The hub needs to be able to give a new permission to each producer to tell if they can or not see customers details, that’s the only thing I would implement, a new “hub2producer” permission.


Allow hubs to charge fees to producers
#4

have just discovered / realised that this is connected to post Notify Producers email to include customer details

NB. @tschumilas @CLFC @sstead that this is the main thread for this issue - this is the one that is ‘iceboxed’. Would having a report that enabled the producers to access the customer information do the trick? or it NEEDS to be in the ‘notify producers’ email as well?

NB. Noting relationship with post 1311 - it seems like amending the ‘notify producers’ email would be another potential feature candidate for meeting the specified need? @MyriamBoure @sauloperez?


Notify Producers email to include customer details
#5

I think a report would do it. A supplier would need to see the buyer’s name, the distributor/pick-up location, and the variants & amounts they ordered. Just thinking - IF the report also showed the naked costs (ie; the supplier’s price before any fees) - and it was downloadable as csv, then it could be easily used by the supplier to generate their invoice to the hub too, and producers just need to ‘learn’ about one report. @CLFC? would it matter if it was a report or through the ‘notify producers’ button?


#6

@tschumilas I don’t believe it would be of huge consequence which method was used, so long as they are able to see the buyer names and which hub they ordered from. We have earlier drop-off deadlines for products that are going outside of our main hub in Dryden, so they need to know if their products are going out of town or not.

In our situation, I think all we really require is that packing report to show the code/customer name/hub name, along with the product details. If it goes out in an email, that’s fine too. But for the last 5 years they’ve been conditioned to go to the website to print off their labels (similar to the packing report). So having that step wouldn’t be unusual here.

Producer invoices aren’t something that our producers generate in OFS - the software actually generates two sets of invoices for each order cycle - the customer invoice, and a producer invoice. So right now, we essentially generate their invoice for them, and pay them from it. That setup would definitely be a bit different in OFN.


#7

kind of related to this, but an aside – I don’t really know excel at all. But I’m guessing its possible to print labels directly from excel? Do you know how? I’d like to share the process in a little ‘help sheet’ because I’ve been asked a few times how to go from an excel packing sheet (downloaded from OFN as CSV) to labels. ??


#8

I think the notify producers button is more convenient than using the reports - in PCFC’s case a notify producer button would save 10+ producers from needing to login and filter the report correctly - notify producer seems easier and less error prone, to the extent that I can imagine PCFC continuing to email producers, to remove this room for error/miscommunication.


#9

Here’s an example of what the packing labels look like for CLFC now with OFS. In our producers panel, there is just a link to “Print Labels” that pulls this up: (the blurred out lines are the customer names)


And when they print, all the page formatting is stripped away, leaving just the text data. So they get the hub location, member number (which we would enter in OFN under ‘code’), the producer name, product number/name/quantity, and the [NON] is for [REF]rigerated, [NON]-refrigerated, [FRO]zen. At our hub, the information is compared to the invoices to ensure the correct items are put with the correct orders.

There are options to print one label per item, or one per customer - so our producers can package everything for one customer together if they wish.

I’d imagine something similar could be easily accomplished with the data returned from the packing report. I’m not sure what the best way to do that from a CSV file would be. It would be a simple loop statement on the server. Maybe I could mock up a csv converter in PHP to test it out, since I’m not at all skilled in Ruby programming.


#10

my thought was to just have a help sheet for users - and this would be outside of the OFN platform. I think there are a number of such sheets using the CSV data that we could develop. It would be more flexible than doing it inside the platform I think, and it could be done more quickly. We just need an excel power user to do these tip sheets, and then can share them widely. Do you know someone who would do this?


#11

I think this would need Mail Merge in Word to work. I’ll play around with it and see what I can come up with.


#12

my initial thought was mail merge too - and if someone set up and shared the word file so that all you had to do is:

  • download a csv (probably can use an existing report that has all the necessary info but could tweak if needed)
  • tell the word doc to use that csv and merge
  • print

but then I also did a quick google and this might be even quicker - https://gist.github.com/kgodard/5072573

@CLFC do you want to have a play with that and see if it works? would save a couple of fiddle steps?


#13

I had looked at the Avery label stuff too. My only issue relying on a 3rd party platform is they are subject to change without notice, or any sort of control. It wouldn’t be great to have a hub log in one day to find nothing works anymore. At least with a Word mail merge, there’s some relatively guaranteed consistency.

I’ll take on testing out a mail merge and post the file so others can test it too. Once the basic form is working, it would be easy enough to customize for individual shops/hubs as needed.

There seems to be a way to do it with Google Docs too. Maybe I’ll investigate that first, since it’s freely available to all, without needing an Office license/subscription.


#14

if there’s a way to do it with google docs then it’s more likely that something relatively simple could be built to send the info directly to the google doc from OFN?


#15

wow sync brain. I just finished my slack stalking with a quick check in to the UK and found that @lin_d_hop has got zapier sending info from OFN UK into a google doc, so it seems that this might be quite doable . .


#16

I did a test with what appeared to be a free Docs addon (Smartsheet Merge), but turns out it’s only a 30 day free trial. Too bad, because the first test almost worked flawlessly.

Oh, even better! Found a free addon - autoCrat. Pulled the csv into Google Sheets, ran the addon, and it generated THIS lovely label doc. And the template is a really simple Google Doc with the field names in << >> double brackets. You can also add exceptions on the import, so that it will skip lines conditionally. IE: the csv has lines for total items, but the hub column is blank, so it skipped any rows with blank hub data. I should have also tried a test where it skipped anything with “Membership Fee” since those don’t need labels. (Actually, tried that, won’t work … buuuuuuut just deleting those rows from the spreadsheet does the job just fine!)

So that’s a possible solution, but I’m not confident that a lot of our producers would have the knowledge to do this themselves. We do have some who aren’t what you’d call tech savvy. It would also hinge on producers being able to see customer information from their hub orders in the packing reports.

We’d need to figure out a much more automated way to make that happen, even if the results are quite good. Otherwise it’s an extra job that would fall on our hub co-ordinators that would be very time sensitive, and require a separate merge for each individual supplier. Workable, but not exactly ideal.


#17

So given this discussion @sstead it seems to me that the report fixing is the way to go as the usage possibilities of the data are much broader than the notify producers email. We can see later on if we want to improve producers UX by changing the email content.
Your label sheet looks awesome @CLFC!

This icebox item has been prioritize but only in 6th position in the priority list


As you were not here to pitch in our “pitching session” in Barcelona @tschumilas , if you want to propose changing the priority of this need I guess you can make a proposal. We sized the feature as “small”. I’ll open a thread for our “evolving top10 priority list” so that there is a space to propose evolutions of the list over time, we’ll see if that meets our need for agility here :wink:


#18

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


#19

@tschumilas here it is TOP10 priority needs evolution process

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 :wink: 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…


#20

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