I haven’t made it that far yet. I had just corrected the import, so the right values were going into the right fields. The pack by customer list will take some extra work. Hopefully will have that going this weekend. It’s next on my list. 
No rush - we are making do at the Bailey’s hub and satellites for now. But its taking me hours to pack orders with the current OFN packing slips, plus I keep making lots of errors. So I’m going to work up an icebox proposal for improvements. (It took me 1.5 hrs to pack 8 orders yesterday - can’t imagine how this will work once we start getting more customers.)
So you don’t really need the section for individual product labels at all, right? Just the split out pages per customer with what they purchased, and from which supplier?
Can you take a look at this setup and tell me if this is basically what you’re looking for? I used one of the OCs you imported as my test data.
https://31eagledrive.com/ofn/create_labels.php?oc=2018-08-17-1534520281&rpt=c
I’m going to stop making any changes until I hear back from you regarding if I’m getting close to what you’re looking for.
(Looks like this … Generate Labels_CustomerPackingList_TEST_1.pdf (50.5 KB)
This is almost (
) perfect. It is what I need to pack orders. We would actually use both kinds of reports to back - the first one - by supplier - we’d use as orders arrive to assemble/aggregate the goods for different drop spots. then we’d use the by customer report to pack each individual order. Ideally - the packing slip would also have the customer contact info - at least phone number. Because our process (I think) would be: print 2 copies of each packing slip. As they are packed, note by hand on each sheet any modifications necessary based on the product that is actually supplied. (It takes WAY to much time to do this electronically and not enough of our volunteers are familiar enough with OFN to do make modifications right to the orders on-line.) One copy of the packing sheet goes into the bag with the order. the other stays with the coordinator (me at this point) to make e-modifications and reconcilliations in the platform and email the customers their official receipts. So - at the pick-up spot - if contact info is on the packing sheet - the volunteer has a number to call if someone is late picking up their food. If its not possible to pull the contact info for the packing slip - we will print off their unofficial invoice too - since that has their contact info. But it would be nice to avoid that duplication.
If the customer contact information was available in the packing reports, it wouldn’t be difficult to include it. But since that data isn’t available, it makes it nearly impossible. The only place that appears to show up in reports is the customer mailing list report…which seems to include the same customer data multiple times. At least on the report I’m looking at on one of my test OCs.
To smoosh the two together, I’d also have to develop a separate database of customer data, then match the names from the order to the names in the database. Which can be done if you are doing a members/registered customer only shop … but if it allows guests or anyone with an OFN account set up to shop, that information wouldn’t even exist.
Looking ahead into how this would work for CLFC, it wouldn’t be an issue. I’m working right now on a way to do membership management/tracking and tying it in with OFN customer lists. So there will definitely be duplication, maintaining two lists essentially, but because we would be using the code field to house membership numbers, it will be relatively simple to tie the databases together on that field. The only downside will be if a customer updates their details in OFN, there’s no way we would a) know or b) have that automatically update our separate member database. Not IDEAL, but I should be able to make that work.
What would be amazing if OFN had a remote data API, where the data could be pulled right from OFN through a web request directly … without having to export the existing data to csv, and re-import it to another site. But I don’t think that’s going to be an option any time in the near future. I’m very curious to see where we end up with the next generation of reports being worked on. Maybe that will take care of some of these little issues for us.
In the meantime, if this little script is going to save you hours of manually putting the data together, I’ll call it a victory … and work in progress. 
Let me know if there is anything else I can try to do with it for your next delivery day!
So lets not worry about consumer contact info for now - I see these packing slips as temporary until we can work on revised ones in the platform that suit multiple business models. So for now - we’ll print out the packing sheets by customer you’ve done (thanks very much) as well as a customer list with contact info.
FYI we are working on managing mailing lists for each hub and satellite in mailchimp. In OFN the customer list is only a list of people who have actually ordered (unless its a members only shop and they are added in). But for building sales, we really need a mailing list for the hub of ‘interested’ people who might have or might not have ordered, to send promotions and reminders… notes of new products… So we’ve created a landing page to build that list in mailchimp and then the link to that will appear in the ‘about us’ part of the hub or satellite. Best we’ve come up with so farm.
The script is fantastic - big thanks for that.
1 Like
We are now starting to brainstorm about OFN packing slips. i’ve created a doc where we can pull our ideas together. It would be most helpful if people could document how they are currently doing packing using OFN reports/data… Once we have a range of processes documented, we can start to work on what we want the packing slips to look like, and how these integrate with the delivery note inception. (because they are very related)
@CLFC @rbarreca @MyriamBoure @robert @Rachel - and others - can you contribute processes to this file?
https://drive.google.com/drive/folders/1-B74howu84l1ypOdzkzz1vM4mSe32ta1?usp=sharing
1 Like
I’ve added CLFC’s process to the document, using your Bailey’s example as a template. Let me know if there is anything in there that I should clarify further. Thanks.
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 
1 Like
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.
@tschumilas @MyriamBoure I was just about to create a wishlist for adding Supplier / Producer name to the invoices so that they ‘can’ be used as packing sheets, as per discussion here
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.