Hub can easily generate accurate packing slips

What is the need / problem

At present hub managers have no efficient way to pack customer orders, resulting in tedious work-a-rounds, inefficiencies and packing errors.

Who does it impact

Hub managers who pack customer orders.

What is the current impact of this problem

Inefficient use of packers time, packing errors, lost potential users

What is the benefit in focusing on this

Packing orders needs to be done quickly and accurately at the food hub. At present a hub manager needs to download a CSV file, manipulate it, and make a packing sheet for each customer, and print them out to take to the packing location. Hub managers find this process cumbersome. So to avoid it, they are using invoices to pack orders. But invoices are not designed as packing slips, and there are other problems associated with this use. By focusing on the hubā€™s packing process we can develop ā€˜packing slipsā€™ that help them pack orders more efficiently and OFN will respond to new hub users primary questions/concerns.

Links to more details

Some discussion on slack brainstorm-incept channel: https://openfoodnetwork.slack.com/messages/CC0HNNKL6/convo/C0BJ86CH5-1526454003.000474/. @Matt-Yorkley notes: ā€œThe second thing is this idea of the Packing Sheet. We already have this concept in the reports section, but the reports section doesnā€™t create usable packing sheets. With the two hubs that I work with in the UK, the first thing they both said is they need packing sheets, and that packing sheets are not invoices.We talked a bit before about the issues with invoices being used in this way, as an invoice is a legal document that comes with a lot of complications. If you issue one and then an item gets damaged during delivery for example, you technically have to issue a new invoice with a new number, and/or a void for the previous invoice. Itā€™s not great if our users are using invoices as packing sheets. They are currently using invoices for this because they donā€™t have usable packing sheetsā€

Potential solutions that will solve this problem

printable packing slips, that have all the information packers need, co-designed with packers who have weekly experience with what makes packing easy and clear

1 Like

Thanks @tschumilas! I think there was a bit more in the Slack discussion about potential solutions / different approaches? It might be worth capturing them as dot points here as they will disappear into the ether in slack - never to be seen again

I have created a row in the Global roadmap tracking sheet and put that is of interest to Canada, UK (@sstead has this come up in Aus? I know it used to annoy me at South East Food Hub!)

I have changed the title to something that I hope meets @MyriamBoureā€™s standards - but probably not :wink:

My sense from Australian users is that they all have a slightly different way of structuring their pack sheets. Some use email confirmations, some use the invoice, some modify reports, some want colour coding, another woman wanted all the pack data on a big spreadsheet to save printing lots of paper. This could be a good thing to do a survey of users? e.g. Josh was saying today that rather than 3x500g of spinach he changes it to 1.5kg spinach - everyone has so many different preference :stuck_out_tongue:

Itā€™s the same story with Local Orbit. Many hub managers print an awkward combination of invoices, packing slips, export CSVs to modify in order to create packing sheets (for packers and drivers). It takes anywhere from 1 hour to 4 hours for really large hubs to prepare all the documents needed for a successful delivery and/or pickup day. Iā€™m very interested in discussing this story in the future.

Iā€™m planning on whipping up a script that will take the csv file, upload it to my server, drop it in a database table, then generate a sheet of labels with relevant data. Maybe add a separate packing checklist while Iā€™m at it ā€¦ weā€™ll see how ambitious I get on our long weekend. lol

1 Like

I agree with @sstead and all that hubs have pretty specific needs depending on their operational organisationā€¦ I think this reflexion should be linked to the one on delivery note (https://docs.google.com/presentation/d/1CX7me25x_a7yb8zO6PmgQtydSFU8G_cPvp1YBBHvpAI/edit#slide=id.p) so that we can work on a consistent end to end UX. Delivery note IS actually a packing sheet for packers who use tablets for instanceā€¦

Most natural logistic flow would be IMO:

  1. As a hub I order the big quantities to the suppliers, when I receive them I check their delivery note and accept or not. There might be gaps between what I ordered and what I delivered.
  2. But most likely I wonā€™t recount everything when I receive my order from suppliers, and I will directly print packing sheets / or display the delivery note interface (see doc above) on a tablet/computer used by the packer
  3. If the packer use a packing sheet, she might notice gaps between the order and the products available to prepare the baskets, so she will record those gaps, maybe with a pen on the packing sheet to start with, but then will report in the delivery note interface to capture those gaps, so that then the invoice generated in OFN is accurate with what is actually delivered.
  4. If an external transport is contracted to deliver the basket, the hub will print the delivery notes so that the transporter have the document they legally need to take in charge the products (we might need some more aggregated delivery note for him but letā€™s see that on a further iteration if need is here).
  5. Then when delivery note with potential gaps captured are created, it is possible to issue an invoice. Some hubs might want to print them to put them physically in the food baskets.
  6. Others might want to dematerialize the invoicing operation. For that the hub will need to be able to capture when a basket is delivered/collected, and that action could automatically issued an invoice, send it by email to the customer and attach it to the customer account.

I think itā€™s important that we agree on the flow(s) we offer our users. I tried to sum up that workflow here (@Rachel is it what you said we should do for all our workflows? In terme of functional documentation?).
We see that it wonā€™t be possible to issue invoices for packing once delivery notes are in place, you will need first to have the delivery note so you wonā€™t be able to bulk print invoices and use them for packing, but we still need to be able to bulk print invoices for hubs who want to physically put the invoices in the baskets, so it still makes sense to develop the bulk invoice printing anyway.

So yes we do need some easy to print packing sheets, and we need some user investigation, to document how various hubs do to see some common patterns, maybe we will realize that one common solution could fit all needs, or that we need 2-3 different types of packing sheets. So to find one or various features candidates we need some investigation workā€¦ I think we need a ā€œproduct ownerā€ to organize and facilitate that workā€¦ would you like to take that role @tschumilas? Iā€™m happy to do some investigation in France with our main users and document those in our Drive for instance. I guess if every instance does that then we can look at all that and see the common patterns to draw potential solutionsā€¦

Hi @Kirsten @sstead @tschumilas @MyriamBoure @FoodConnectRD
We are with you all on this. Myriam summed it up best in that last paragraph,

ā€œSo yes we do need some easy to print packing sheets, and we need some user investigation, to document how various hubs do to see some common patterns, maybe we will realize that one common solution could fit all needs, or that we need 2-3 different types of packing sheets. So to find one or various features candidates we need some investigation workā€¦ I think we need a ā€œproduct ownerā€ to organize and facilitate that workā€¦ would you like to take that role @tschumilas? Iā€™m happy to do some investigation in France with our main users and document those in our Drive for instance. I guess if every instance does that then we can look at all that and see the common patterns to draw potential solutionsā€¦ā€

We would like to participate in this, @FoodConnectRD, what do you think?

Yikes! Iā€™d love to help do this but this would be my first time in the role of ā€˜product ownerā€™ so as long as people can be a bit patient with me, Iā€™m up for it. Iā€™m not very good at various platforms/apps people use to display pictures and charts though. So as long as people are ok with rudimentary displays/descriptions (maybe scans of my hand drawn flow charts for example) then Iā€™m happy to take on this role. I think the first step would be for everyone interested to talk with a variety of users and write out (as @MyriamBoure did above) or draw a flow chart of the process. I will then collate these and put them together, and we can see where the process overlaps and where it diverges. Is that the first step?

1 Like

Awesome @tschumilas! Itā€™s great that we support one other in learning those kind of roles :slight_smile: For sure @danielle (and I, but Danni is my yoda master ;-)) can support you in learning this role! If I may, can I suggest that we use Google Drive for documenting each case? Cause Iā€™m afraid that thread becomes unreadable if every instance post 6 posts to describe each way users do that in their context, etc. I would suggest you create a new folder in https://drive.google.com/drive/folders/0B_HDFsX1e_2VWlhJZXRSQUNoOGc, and share a public link in he main thread here (you can update the thread taking into account the latest discussions so that we follow up the current status easily!) and each instance can document there? So as the owner of that need you can ask every instance to do the work, put some form of deadline, and kick people ass if they donā€™t do the job :wink: When you have everything, analyze and share your findings, it can be manual mockups/drawing yes! With different options maybe. And then convey some hangout with both tech and product people to discuss those solution, put them on a value ease matrix and choose. If you get lost in what you have to do in that role, please reach at @danielle or I or @Rachel! Awesome @robert if Food Connect wants also to work on that and share (in the drive folder Theresa is going to create) how you work today and what you would need in that ideal packing sheet :wink:

1 Like

HI there, just a small comment on the link to the delivery note presentation, it is now out of date since the last inception in Barcelona. Iā€™ve created new mockups and I have all the notes ready to final brainstorm before making issues around first release of delivery note, where shall I put this ? Shall I continue on the thread of delivery note or in drive only ?

@Rachel you can put your mockups in the delivery note inception folder in google drive, and change the link in the GH epic and share it in any other relevant discussion. Thatā€™s what I would do :wink:

Happy to help @tschumilas. Just yell out if you need anything. Weā€™re also writing up the process in gitbooks so you can have a read of that (first draft is in process).

I need some help to get me started - so I should be creating a space (presumably on google docs) where people can write out their process? I can kick start the discussion with processes from the hubs Iā€™m working with, and then invite others. If people prefer, they can also send me or upload here on this thread a diagram. Am I making sense and is this how to start? (Sorry for my delay - I will get to this on the weekend when my flower orders are all out.)

I think the process is creating a new folder for the feature in OFN Global > 09 Technical > Brainstorm solutions and incept feature candidates and put everything in there; design docs, diagrams, scanned drawings etc.

@MyriamBoure or @Rachel can confirm

Iā€™ve put together something of a ā€˜sort ofā€™ solution for our purposes.

This takes the ā€˜pack by customerā€™ report from our hub, as a csv (example) from OFN, user uploads it through the form, selects the OC date from the date picker field, and clicks import.

The script uploads the data, imports it to a mySQL database, then pulls the data, sifts through it all, and spits out a display like this. When the user prints, it turns into something like Generate Labels_CLFC-TEST_1.pdf (78.3 KB), with labels for each producer separated into separate pages, and each page has the variants broke down by customer. So if Bob bought 300g of tomatoes, and Sally bought 500g of tomatoes, there will be a label for each, showing the number of 100g of tomatoes each purchased.

The final page is kind of a packing checklist - just the products/variants and how many in total of each item are needed to fulfill all the orders. So if a producer needs 16 heads of Romaine lettuce to fill all of their orders, it just says Lettuce - Romaine - 16, and thereā€™s a space on the left they can check off when theyā€™ve harvested the 16 heads.

If anyone wants to try it with their own files, itā€™s the pack by customer report you need (other reports will give unexpected results, since the DB is set up for this report specifically), and the script is here. Iā€™ve removed the CLFC logo from the script.

My ideal situation here is that we get the OFN producer pack by customer report able to display the customer names instead of ā€œHIDDENā€ ā€¦ then they could run the script to have their own labels/packing sheets made, instead of having it at the hub level, as this is.

this is great @CLFC - but see my trial below - it is putting BOTH the last name of the buyer/customer and the name of the supplier in the ā€˜sold toā€™ column.
Second - would there be a way to do this same thing but with the option of printing a packing sheet for each customer? So something that a hub that packs orders would use - for example, theyā€™d pick up a sheet for Theresaā€™s order and then put all the correct products and varients in it. So - a different paLabels test - R&T Food Hub.pdf (101.4 KB)
ge for each customer/buyer (versus a different page for each producer). ??

1 Like

I think thereā€™s something different about the csv file youā€™re uploading. Could be a slightly different report than I have it set up for. Can you upload/link a copy of the csv for me to compare to what Iā€™m getting out of my report? It looks like maybe you exported the packing list by supplier instead of by customer?

I based the packing list on something I discussed with one of our producers, who thought it would be great if he had a list of what products and how much of each he needed when he went to the greenhouse to harvest it, so he didnā€™t come back in to package things and find himself short. But realistically, thereā€™s no technical reason it couldnā€™t be set up to do the same thing by customer instead of producer.

I actually have plans to allow the output to be customized before itā€™s displayed ā€¦ so you can skip the code/member # field I have there, if thatā€™s not something a hub uses. If there is only one hub or pick-up location, the hub field isnā€™t really needed and could be skipped. Stuff like that. I just wanted to make sure I had the basics working before I make things complicated! :slight_smile:

Iā€™ll add these to my list, and maybe do a variant for packing reports by supplier instead of by customer. Shouldnā€™t require a huge change ā€¦ can probably just add a checkbox/dropdown option for which version of the report is being imported.

@tschumilas - I think thatā€™s exactly what happened. The order of the data in the pack by customer report is different than in the pack by supplier report. So instead of being imported in this order:
Hub[0], Supplier[1], Code[2], First Name[3], Last Name[4], Product[5], Variant[6], Quantity[7], TempControlled[8]
your data imported in this order:
Hub[0], Code[1], First Name [2], Last Name[3], Supplier[4], Product[5], Variant[6], Quantity[7], TempControlled[8]

So when it imported, the code went into the supplier field, first name into the code field, last name into first name, supplier into first name. The hub, product, variant, quantity, and tempcontrolled fields all still lined up.

I tested it with my own report, switching to by customer instead of by supplier and got the same results ā€¦ last name stuck to the front of the supplier name in the sold to field. Verified!

It shouldnā€™t be much work to make the incoming report type selectable before uploading, and just have the data re-mapped as itā€™s imported. Itā€™s just a few fields that get swapped around, the fields themselves are still the same either way.

@tschumilas - try it again. Iā€™ve added the option to use either by supplier OR by customer. I did a quick test, and both are mapping correctly now. Getting a bit late to start working on changes to the packing list displays, but Iā€™ll work on that this week for you.

Am I missing something - here is the same hub, the same order cycle - first is the pack by customers report, second is the pack by suppliers. BUT both print outs are structured the same - they have a different page for each supplier, and are ordered by supplier alphabetically. the only difference is that the pack by customer report lists the customers names - for each producer - in alphabetical order. But what Iā€™m looking for, is a report where the customer name appears at the top of the page - where the supplier name appears now. and every customer starts a new page. Then within each customer, there is a list by supplier of the products ordered. See what I mean? I know that you have suppliers do packing - so these reports work in your model. But, I wonder if it is possible for you to modify what youā€™ve done (which is fantastic) so that a hub that packs orders by customer can get the labels so that each customer starts a new page???

Generate Labels _ pack by customer.pdf (115.2 KB)
Generate Labels _ pack by supplier.pdf (120.5 KB)