Hey @tschumilas, we’ve put a call out for feedback with our users and just waiting on responses. Hope to have something for you next week.
@tschumilas I have done some investigation work about the different “logistic processes” used by hubs and producers in France. I have not detailed all the cases as I find it super hard to read, I summed up the 5 use cases in your document, that from what I read (I didn’t read every cases but went through some) cover most of the cases, maybe even all (you can check and see if yes or no, and if we miss some, describe the general use case missing).
From all the material I gathered from hubs (home made packing slips from reports) I built 5 “templates” for each use case, with both a report and a printable version. This is a base I use for discussion with users now to get feedback and understand if that fit their needs, or not, what is missing, what is useless, etc. That’s how I’m moving forward for French case on this. i shared the link to those “templates” in your document.
I think packing slips are somehow a paper version of delivery note. Maybe goes a little bit forward in term of support to organize logistics, but I think that will come in further iterations of delivery note feature. So both goes hand in hand and we need to envision them together.
One thing not clear yet to me: I think there is still a confusion between “packing step” and “delivery step”.
- packing step: need to capture gap with what was ordered, specify real weight for variable weight products, maybe need to stick a label on the box identifying the customer, but doesn’t need customer phone, neither price to pay by the customer on delivery, etc.
- delivery step: don’t need the details of what is in the basket, they need info of the customer in case she doesn’t come, they need price to pay if paid on collection, and to be able to identify the basket to deliver.
In real life, a “delivery note” is actually used by the person who delivers in that purpose, there is the phone number of the client on it, and sometimes (not always) the price to pay as transporters sometimes collect money. So maybe that’s only one feature, but we need to see when we need the price and phone info for instance, at which step in the process. Ping @Rachel
It might be interesting to get real life example on delivery notes, we might get inspired
Actually I think I see the connection more clearly:
- the delivery note feature we are desining enable to capture what is actually put in the basket, which can differ from what has been ordered
- this can be issued then as a “delivery note”, per customer, but we could also imagine to issue some “delivery note report” with all the baskets (each basket identified by a delivery note number), and for each basket the customer name, phone number, and price to pay and if already paid or not. That way everyone will have what is necessary to operate. So I think prices shouldn’t appear in packing slips. Ping @Rachel
I think we need to visually map the end to end process to see what is done at which step with which “tool/feature” This is at the heart of delivery note feature design, so let’s do that first to make sure we understand clearly the need !
OK so I have more clarity now of the process. I checked with some users to be sure I understand it well, and this is my understanding.
To clarify the words we use (also as we are not all english speakers here, and semantic is key to understand each other) I suggest those terminology:
- the producer or hub who receive orders will “prepare the orders”. For that he needs
1- To be able to print some "labels" to put on each box to identify them (some hubs will just write on the box and won’t use it, some advanced ones will have barcodes or QRcodes ;-)). Shall we call them “basket id labels”?
2- Some tool, an interface, either digital or paper, that we can call an “order preparation tool” whose purpose is to enable… order preparation (packing). This tool enable to make basket preparation easy and capture gaps between what is ordered and what is put in the basket. If it is a paper version we will call it “packing document” (a document that makes packing easier). If it is digital, done through tablet for instance, the call to action can be “capture packing info” or “create delivery note” (we will need to test what is best CTA).
3- When this is done she needs to be able to print the “delivery notes” (a non compulsory but “legal” document that can be given to the transporter and tells what is in the basket, so the customer when receiving it can check if the content is good). A delivery note is a single document per basket to be delivered, it is usually put in the basket and given to the customer so they can check when receiving the product. Usually it is required if an external transporter do the delivery.
4- The person doing the delivery may need a “shipping document” which is a document that tells what basket needs to be delivered where, to whom, with phone number of customer, tells if needs to collect money, etc.
I summed up all the documents needed to support the logistic process here, with some template documents to show what it coudl look like, with the info required at each step (based on practice analysis from hubs, I commented to explain)
@tschumilas please check on your side all that to see if that sounds consistent and acurate to you. I will again on my side circulate this understand with French users to make sure I understood everything well, and get feedback from template documents to see if there are the necessary and suffisent info. @sstead @rbarreca @CLFC @robert @FoodConnectRD check as well if that seems consistent.
@Rachel all that is key in the thinking and building of “digital” version of packing document, which is “create delivery note” feature.
We also have actually lots of requests from users to get those type of packing documents, so maybe we can discuss at next pitching session about priorisation, as we work on delivery note as next priority after bulk invoice printing, and it might be wise to include the “paper version” of it at the same time at marginal cost… I don’t want to hack priorization process of course @danielle
fyi - I’ll be digging into this in a couple of days - just swamped right now. BUT - I just realized that I understood something totally different by ‘delivery note’ I think there is a step before the ones you outline where the hub receives the deliveries from the suppliers and compares what was ordered from each supplier and what was delivered from each supplier. I think one of the report hacks that @CLFC designed is useful for this. At this point in time, it has nothing to do with what the end buyer/customer yet. So maybe I’ll call this ‘supplier reconcilliation’ or ‘supplier check’ or something. Then, once the hub knows what they have actually received, they know where they need to either make substitutions (if the supplier brought a substitute product/variant) or where they have to issue credits because the goods were not received. And somehow the ‘delivery note’ (as you correctly call it above) - that is directed at the buyer - needs to inform them on any details where their order differs from what their on-line confirmation told them. So - the delivery note is closest to an invoice - no?
Actually @tschumilas the step when producer deliver and hub compare is done thanks to a delivery note The producer receive an order from hub, “create a delivery note” when packing the order, so if there is a gap it will be captured. The hub receive the order, ideally with the delivery note attached to it, so they can compare and know what is there or not. So yes the hacky report from @CLFC does a bit of that, for the producer level.
Then the hub do the same when they prepare the individual baskets for customers, and customer then check when receive the order with the delivery note.
Both are delivery note and we are going to build only one feature that can be used by multiple actors ideally. As soon as you have an order, and a delivery of something, you have a delivery note.
And the invoice can then be issued based on the info on the delivery note, but this can vary a little. For instance in the case of subscription, the invoice is issued when subscription is bought, but when there is a delivery, there will be a delivery note, each week. But no new invoice for the product. A delivery note most of the time doesn’t have prices on it. It is mostly a logistic document.
One order can be delivered in 2 or more times, for instance if one product is missing hub might deliver it next day. So in that case you would have one order, 2 delivery notes, and then probably 1 invoice. But maybe this client is a regular client, and the hub only invoice one a month for all the products delivered in the month, so then you will have 1 invoice for multiple delivery notes. Same the other way around, you can have 2 orders delivered in one delivery with only one delivery note.
“delivery note” is the technical term used by the domain workers, the official name of the paper, well at least that’s how we would translate from French
This is basically our packing flow …
We don’t use a ton of documents, really. It comes down mainly to our producers baskets (which I don’t think too many actually print), the labels (which are always printed and attached by producers), and our invoices.
The labels look like this:
Which shows which hub the product is going to, if it’s refrigerated [REF]/frozen [FROZ]/non-refrigerated [NON], who the producer of the product is, the customer name (blurred out), and their member number (in front of product name/quantity).
On our invoices, we have everything we need to pack the orders at the hub, when the labelled products arrive from the producers:
If there are frozen or refrigerated products, the hub workers highlight them on the invoices in yellow (refrigerated) or blue (freezer). As each item is put in the basket after being dropped off, it is checked off. When the order is fulfilled, the invoice goes on top of the basket.
So when our customers come in to pick up, they give their name, someone gets their basket (with the marked invoice inside), and there is another check as each item is taken out - or retrieved from the fridge/freezer. If there is anything missing, we know ahead of time, because it isn’t checked off on the invoice.
When we have a producer who can’t fulfill an order fully, they are responsible for contacting their customers directly. If we find that a delivery was short items, we are able to contact the producer - AND the customer knows who it was from, because it’s on their invoice, and is able to contact them directly to remedy the situation. (Sometimes there is a boxed missed when they’re loading up, etc.)
The way I view it, Myriam’s logistic flow and documents sound like they would work just fine here - almost. The only spot I could see an issue is id labels are both marked by ‘box’ or ‘basket’ instead of each item. We really need per-item labels here to mesh with our distribution system. The rest looks good.
@tschumilas I’ve put our survey responses into your google doc, and have written a summary of our user feedback here - https://docs.google.com/document/d/1_m3EWvyLGOp9i9CgeEcf0ifWDCTHD14l7_tPGV-s6Pg/edit?usp=sharing . I’ve tried to comment as to whether @MyriamBoure’s templates would suit these users, but once we’re closer I can run the templates past the users themselves. It’s interesting to note that Food Connect are using Xero to print and manage packing slips and invoices. It makes sense - this way they have any order adjustments immediately updated in their accounts receivable system.
Add supplier name into default invoice template
scanned the icebox to check I wasn’t duplicating, and found this thread. I haven’t read through it all, but note that it was opened with this comment
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
Would we be encouraging ‘bad’ behaviour / use of invoices by adding the Supplier name to them?
For my 2c, I think we should still just do it, as people are using the invoices as a workaround and this would make that workaround much easier and save people lots of time, while the more complex most amazing packing sheets ever are worked out?
The invoices look nice and are easy to do - which is why people use them for packing slips now. if it was easy to add supplier names - this would be perfecto - while we design the packing slips - delivery notes - reconcillation processes. (And I think this will be big because many pieces need to work together.) As far as encouraging ‘bad behaviour’ - I know what you mean - but people will find the simplest way to do things. If our packing slip - delivery note - invoice reconcilliation… process is overly complex - they’ll use the invoices for packing and giving refunds anyway. So - maybe we anticipate that. Smaller less sophisticated hubs will use the invoices - and more complex hubs, esp those with integrations with accounting packages - will look for a more complex system.
Is having multiple ways of doing things a bad thing?
Also - fyi - the script that @CLFC pulled together works very well. It pulls from either the ‘pack by customer’ or ‘pack by supplier’ report. I’ve been using the ‘pack by customer’ version - and it spits out a new page per customer, with that customer’s order (the supplier, the variant and the amount ordered). As a hub manager, I first make modifications to customer orders (eg. drop products that weren’t delivered, make subs for other products in the OC,) and then pull the report - so it works pretty well. But there are two problems with it: 1. as far as I can tell (unless I’m missing something) in OFN right now, when I’m making modifications to an order, I can only add products that were in the OC. Sometimes a producer sends a substitute product - that was not in the OC - and there is no way to add that i don’t think. (let me know if I’m wrong.) 2. The pack by customer and pack by supplier reports do not have item costs or payment info. So if I’m issuing a refund - I need to have the invoice anyway since it has the financial info. So - if all the info was on the invoice - I’d only need one sheet…
You can always edit a past OC and add some products, I don’t see why you couldn’t.
If the OC has closed, you can still edit an order - but only variants that were in that OC show up as options to add in the dropdown on the order edit page. The ‘status’ of the order (eg. pending…) doesn’t seem to matter - still only variants from that OC show up. I try to add a new product and place it in a new OC - but still it does not show up in the dropdown - because it was not a product in the OC that the order came from.
So packing usually happens AFTER the OC is closed. I want to add a different product - that was NOT in the OC - to an order. I want this change to be reflected on either the invoice or the pack by customer report so I can generate up-to-date- packing slips. But - whenever the variant was NOT in the Order Cycle - my only option is to hand write the change on a printed slip.
@tschumilas I was not clear, I said you can go to the closed OC (not the order) and modify the OC, so add in incoming and outgoing the product you need to update some orders of this past OC (with replacement products for instance). And THEN you can edit the order.
AH… OK I see what you mean. So to edit an order and add a new product that a producer delivered to the hub, I would enter that product, go into the closed OC, select the product - and then it will show up in the dropdown on the edit order page. I understand. (But still - a lot of work - which is why we need new processes for delivery notes … )
The other, hacky, option would be to change the affected product in the CSV before uploading it to create the labels. The major negative there is it would not reflect anywhere within OFN … but it would solve writing it in by hand on the packing slips. Not ideal either way, but it is an option.
yes - that’s what we’ve been doing. But the nicer thing about changing it in OFN as @MyriamBoure suggests is that then everything re-calculates (taxes, fees if they are attached to specific products, ) and when you work with total sales kinds of reports in the back end, everything is correct.
In the UK I have gotten around some of these problems by using Google Scripts to generate the packing file a user needs. Currently I have done this for one paying user and another is interested in the format.
Here is an example of the format:
Tamar Automated PackingEg.xlsx (12.0 KB)
this is great @lin_d_hop. Am I able to link to the script so I can upload a file and try it out?
The nice thing about what @CLFC did - is that the output (in PDF) has 2 sections. The first section lists ALL the orders in that cycle by supplier. The second section lists the orders for each buyer (as your’s does). So - what we’ve been doing - for each different drop spot/distributor - the first volunteer takes a little cart, visits each supplier’s pile of goods, and puts the aggregated orders onto the cart. Then a second volunteers fills each buyers orders from the cart. We do this because in this particular hub - MOST buyers pick up and select their own order - so basically we create a mini hub in the big hub for delivered orders.
It works - thanks to you both for all this - BUT our problem is that - if something is not available (which is always the case) - we refund by putting cash into the delivered box (because other refunding in OFN is overly cumbersome). So - to do that, we still need a copy of either the order confirmation or the invoice - so we can easily see the shop price of the item. So - I think once we have supplier name on the invoice - we’ll pack using invoices anyway.
Is there any way that the shop price for an item can be pulled onto these scripts easily? (Otherwise we use invoices and wait until we get ‘proper’ packing slips done)
And I’m curious about your ‘picked’ and ‘double checked’ columns - love to hear your process.
the hub I’m working with wonders if we can print these slips with a highlight or bold or colour… anytime quantity is greater than 1. Because this is where the packers ususally screw up.
BIG thanks - and glad to know others are trying to improve the packing stuff. Its a big turnoff for hubs here.
This is an update on the ‘packing slips’ wishlist item. LOTS of different problems and uses here. My humble summary:
Pick Sheets/Harvest Sheets are needed: These are reports/sheets that a producer uses to pick product after an OC changes. (So pre- delivery to a hub or drop spot. Pre- order packing). Based on the stories we gathered - many producers need to integrate a la carte orders in an OC with some kind of CSA/Basket program - so the solution needs to be more than totallying what has been ordered in the OC for that producer. Second - there is the problem of units - a hub might list ‘bunches’ of carrots - but a harvester picks pounds of carrots and later bunches. So - very messy stuff.
Receiving Sheets - these are records that a hub or distributor or host at a pick-up spot uses to ‘receive’ goods as they arrive, check them against what was ordered, and reconcile differences so that 1. customer orders can be modified, 2. supplier invoicing can be reconciled. Sometimes hub do this ‘live’ on-line - but often its done on paper, for later entry into some system (in or out of OFN)
Packing slips/sheets/labels - these are used to pack orders. IN some cases this is the producer who is packing per customer, or packing per delivery site - before the goods leave the farm. Sometimes these are generated at a hub with bulk orders for a distribution site. Sometimes these are generated at a hub for each customer’s order. They need lots of customized info: the producer name (product source), the shop price (sometimes money is collected at delivery), the customer details (name, contact, how/if they’ve paid). AND they need to be EASY to read - especially when there are multiples of specific products (everyone misses this in the current OFN reports). Ideally they can be printed right to labels.
But there is GOOD news!
Tthere is now a rich collection of the hacky ways in which various users are using combinations of OFN reports, ZERO uploads, CSV downloads and modifications/merges, and Google Scripts to pull together their harvest/pick sheets, receiving sheets and packing slips. ITS RIDICULOUS!! and also marvelous at how ingenious our users are!!
But we are a long ways from incepting specific new features based on this - and its very caught up in disucssions (we need to have) about where we envision reports heading I think. Do we want these new kinds of reports to be 'internal ’ to OFN, or have a set of outside OFN tools (google scripts, zero uploads, Zapier zaps?) that we offer to users, along with some instructions as options? I think the latter would be quicker.
I’m now asking about process (@danielle) . We are not ready to do any specific inception or wishlist items I don’t think. BUT is there a way to make more clear and systematic the hacks currently being used? Maybe to make a system of better hacks and then share them. If for example - I prepared a set of excel sheets that we want to end up with (so they can be moved to PDFs or labels) - might others be able to hack us to them via: Zapier? Google Scripts? Zero? Other?
I know most of you think in pictures/diagrams - sorry - please feel free to put this into a picture. I’m a word & language thinker - so thus my long post.
Others - @lauriewayne1 @luisramos0 ? please add to the google sheet additional thoughts/cases and solutions from your instances.https://docs.google.com/document/d/1lp8UXHFYU1zbDfkx3--qmjbSvE6MM9AU2tgmiGQWM-g/edit
@tschumilas as you say there are lots of hacky ways, and we regularly have feedbacks from users in France, and also users who are blocked from using OFfrance because we don’t have an easy to download and use packing slip adapted to their need. When we are going to incept (properly) we will look at the various options you mentioned, the good thing here is to have a better understanding of the need.
We had a new feedback from a potential user in France who was blocked because manipulating csv seems for them too complicated when they currently have a PDF they download with all what they need. They want something “as easy” as what they have to get the info they need to prepare the orders. I guess it’s just another case with the same need expressed above from the beginning. I’m sure this topic will be discussed at the global gathering, integrations / report is one of the first needs in term of integrations.