@lin_d_hop - remembered this extension, looks like it’s being actively maintained. Could be worth looking into if you’re keen to get an ‘in house’ invoice generator happening
I’ve been working on getting the spree_print_invoice gem to work with our set up, and have made some progress. I’ve attached an example generated invoice as it stands.
I have a few questions I’d like the group to discuss before I continue too much…
As you can see when you look at an Order from the admin panel, and also in the attached invoices, the ‘adjustments’ in spree come out as a big list. So a 10% mark up on each item will appear as a long list of adjustments. I think this is ugly and confusing and off-putting to the customer receiving the invoice. I’d be keen on your thoughts about grouping these, on the invoice and also within the order screen.
The invoice gem has inbuilt invoice counting. However this will not work initially for us as we will need to hold a count for every enterprise. I wonder if this is high priority before anything gets merged or if we can get away without invoice numbers for the initial push. I think it would likely invalidate invoices to not have a proper invoice number, but my little food hub won’t care about this to start with.
Obviously the errors showing in the invoice now will be sorted, and a logo for the enterprise added. What else would y’all like to see in the invoice?
Thanks Lynne - it is great to see this coming togther.
My thoughts on your question numbers:
my preference would be to see the admin fee included in the product total for each product on the invoice so that next to 500ml yogurt it said $3.36 not $3.00 because i think it might be confusing for the shopper to see the items showing as less than they were when they put them in their cart… However I expect this might be tricky, so if we do need to see the admin fees listed separately, my preference would be to have just one total admin fee after the subtotal - so the example you sent us would have “admin fee $3.84”
when you say it will invalidate the invoice if it doesnt have a number do you just mean just from an HMRC point of view? If so I don’t think this matters to Stroudco - we never show the invoices to the accountant. However, it is important to us that there is a quick and easy way to input invoices in to Quickbooks. Would we need a number for this?
We will need to see any discount being subtracted from the invoice total if the shopper is a member or regular volunteer. Also it would be nice if the date was a bit more friendly - ie 17th March 2015 instead of 2015-03-17
Otherwise it is looking great. thank you very much
Nick
I think it would be a really good idea to use the order confirmation email calculation and format as your template for this, as then they will match up and people will not be confused. Also, we did quite a lot of ‘to and froing’ on how to portray the fees for minimal confusion. AND the order confirmation email should also work out and report the tax correctly which is obviously important on an invoice
If we were using this (which I’m sure people here will), would be important to have the producer showing as well. Very likely people would end up using these also as packing sheets . . especially once we have an easy way to select multiple orders and do an action on them
re. invoice number - for the xero reports we’ve taken the approach of letting people put ‘start number’ in as a parameter, so that it automatically numbers them all but only from where you tell it. depending on how you’re planning to call this (as single action from within edit order, or bulk action from order index page?), might be good to have it request a start number parameter in the same way?
Thanks @Kirsten
In that case it might be better not to use the spree_print_invoice gem and instead use a html to pdf gem such as pdfkit to do this. This should mean that we can reuse most of the code from the confirmation email and not have another clunky section of the website to maintain. Sounds like a win to me.
I haven’t explored this much yet but I’ll do some work this morning trying to plug this together
I’ve spent a bit of time thinking about the best way to implement invoice generation (without getting very far). I was hoping for a little feedback.
My current thoughts are that this would work best if it could be applied as a bulk action, as people will need to print an order cycle worth of invoices at a time.
So this would either mean 1) angularising the edit order page or 2) updating the Order Index page so that we could choose to display the results as full line item lists or per order. I would def prefer the second option as it feels cleaner and more likely to persist into the future.
So in my mind this would involve:
Adding a button to allow the user to select if they would like the invoices displayed as Per Line Item or Per Order.
Adding a ‘bulk action’ to print invoices. Should this only be available as Per Order?
Print Invoices generates a single PDF with all selected invoices, based on the order email template.
It would be great if you could confirm you’re happy for me to start making these changes to the Order Index page.
We’ve talked quite a bit about this here and strongly inclined towards angularising (probably fresh page build) of the order index page so that it can more easily be developed into additional functionality. @oeoeaio was showing me some stuff in another system that enabled drop-down of line items which was quite cool - not sure if that’s heading towards integrating Bulk Order Managmeent and Order Index page . . (I did think that was a good idea for a while, but now think perhaps is best to keep them separate)
If we do an angular rebuild of the Order Index page, can use some of the tricks from BOM page to easily include ‘select multiple / all’ and Bulk Actions (like collect payments, print invoice, resend emails etc)
So I would probably start with
angularise the Order Index page (fresh build so we have room to move)
put selectors down the side and create ‘bulk actions’ as in BOM
QUESTION how high priority to be able to edit line items from this page? ideal perhaps to have bom and order index integrated, but for now seems perfectly ok to keep separate, edit the orders on bulk order management and send emails / invoices from Orders?
Some thoughts on making sure we have the correct information on invoices when they are generated, stimulated by need to deal with this pretty soon for Enterprise User Accounts
Ideally we should be able to spec an invoice template so that it also works as a general customer invoice (i.e. for a normal order) as well as this ‘OFN Enterprise User Invoice’
Just doing a quick check, I have found this handy link for Aus tax invoices - https://www.ato.gov.au/Business/GST/Issuing-tax-invoices/ and if I get a chance before I go I will work it into a list of what fields we need to include on the invoice
@lin_d_hop have you had a look at this from UK perspective yet? @MyriamBoure@Selmo@lawrence@eric@tschumilas - I suspect it will be pretty easy to make minor adjustments to this later, but might not hurt to check if there are different fields / requirements in your countries in case we can just knock them all off at once!
@Kirsten for Norway here is the link about the legal requirement: https://www.altinn.no/en/Start-and-Run-a-Business/Operation/Accounts-and-auditing/What-is-a-bookkeeping-obligation/What-must-be-stated-on-sales-documents/?epslanguage=en
I think one of the major difference is that in Norway you cannot use an invoicing system that allows you to create yourself the number of the invoice (like excel!) you need to use a system that generates automatically the numbers for the invoices. So when you choose an online invoicing system (some are free) it first asks you if you were using another system before and then from which number the invoices shoud start. And then all the next invoices are automatically numbered (you cannot do anything manually). That is a legal requirement…
I called some Norwegian accounting package provider (e-conomics) and it seems it will be ok that the csv files that we import has a different invoice numberserie than other invoices generated in the accounting package itself. Indeed, as a hub, we can generate invoices for online sales, but maybe also for membership fees, etc. so not all invoices will be generated through OFN. But it seems we can legally have different numberseries, so that is ok.
So for Norwegian hubs to be able to use the invoicing option in OFN, we need to have a system that generate automatically invoice numbers for a hub without us being able to change it manually… Maybe that can be in the hub set up configuration? Or maybe can be done in the configuration panel for the instance? (but the numberserie has to be managed seperately for each entreprise…).
ping @CynthiaReynolds, @olemd and @sigmundpetersen for information
If it’s not possibe through OFN to have automatically generated numberserie, I think we’ll have to generate all the invoices throught the accounting package… so import the csv of a batch of orders, with fields for each line of the invoice, and generate/send the official invoices through the accounting system…
I’m jumping in here - perhaps prematurely - I’m still on a steep learning curve with what’s already gone on, so please forgive me if this is all redundant. I’m trying to monitor your discussions and anticipate situations for a future Canadian instance. For tax purposes here - we would require invoices to have unique numbers - but I don’t think we have the same requirements as Norway for example. But - we would need to be able to show relevant taxes – and unfortunately, those would differ in every province of Canada. So, I guess what I’m saying is, either now or down the road, we need the flexibility for a user to specify the tax rate. Further - this tax rate would need to be attached at the specific product level. ‘Raw’ food products (vegetables, meats, grains…) are not taxed for example, neither are processed foods (juice, bread). But - anything that crosses into confectionary could be, and things like flowers and plants (which are often sold on on-line markets here now) are taxed. And maybe you’ve already build in that flexibility - so sorry. (But it gives me a chance to learn how to interface with these discussions.
have moved this to ‘testing’ - although actually first version is now deployed in aus-production (so obviously also in staging2). Included in v1.3 which hopefully we will finally release next week.
Those with an interest in this functionality, please check it out and feedback asap with any critical changes and suggestions (which may go into wishlist for next round) @NickWeir@lin_d_hop@lisahill@MyriamBoure
Re: numberseries for invoices. We’ve solved that by having a separate model simply using the id-field and creating a new instance of this model per invoice.
somewhat like this:
invoice = new Invoice
invoice.invoice_number = (new InvoiceNumber).id
Obviously, the more sensible approach (for my system at least) would be to use postgresql sequences directly for the invoice-numbers but I’ve never gotten around to that - for OFN it would probably make sense to be able to register a starting-number when creating an enterprise or a hub(?). In case people would like to/must continue an already existing series.
Come to think of it, one could use the invoice-id directly. But that might interfere with using the invoice-number for other things since the invoice-id won’t exist until the invoice is actually created. Generating KID-numbers (The way one does for Norwegian banks to help track payments electronically) would have to be a two-step process - which is why I’m not doing it that way.
As a sidenote, we’ve been unexpectedly busy here in Bergen and I’m sorry we haven’t been able to do very much for OFN. We’re still very interested and will (mostly) reply to pings though. Besides, you seem to do very well without us.
Thanks Kirsten - great to see this deployed - I had a quick look on Staging 2 but could only produce a csv… Please can we talk it through on our skype tomorrow so I can do a bit more testing
Thanks
N
