In the process of trying to reduce this project budget / maintenance, we are wondering if having only 1 template for invoices would work for OFN worldwide (OFN currently maintains 2 templates in instance general settings: a regular and an alternative one).
Please find herewith a template proposal in euros (most used currency), but of course the final invoice would have your currency and your translation.
Proposal (PS: donāt pay attention to alignment / space - if this is validated I will spend time cleaning the template - please focus the feedback on the content):
Can @instance_managers validate / comment in this thread if this new template would legally work for your instance? Deadline on August 28th would be ideal to us
Beyond merging the 2 templates, whatās new for all users:
invoices will show the unit price (currently only shown in the shopfront). Design-wise on the new template, the unit price is shown in brackets -in place of current final weight from BOM). Current final weight from BOM is moved to a dedicated column.
invoices will have their own sequential number, by hub
Hubās terms of sales will be shown at the bottom
Vouchers will have a dedicated line (the example has a voucher code AAA of 5 euros)
Payment delays and fees in case of no payment (required in FR) will be shown at first thanks for the custom text we can already add in enterprise settings
same goes for the sentence that explain why the hub is not tax registered (again required in FR)
Finally to comply, invoices wonāt be edited anymore, but cancelled by credit invoices or new invoices (will explain more in a dedicated discourse post soon, as this does not impact the template).
What would be new for regular template users only:
instead of tax/gst total amount you would have a total breackdown per tax rate - do you guys need the total as well? As I think most regular users only have 1 tax rate, you would already have the total anyway
Presentation of manual adjustment has changed
Shipping methodās name will be shown in line within the table instead of separately
Price per quantity ordered would be new to you
As well as hubās logo
Finally name of the order cycle would be considerably smaller in design - I did this because alternative template users are currently not paying close attention to the name of their OC as it does not appear to shoppers - but if thatās a problem, please tell me and I will work on something else
What would be new to alternative invoice users:
Price per quantity ordered would be shown tax EXCLUDED
Shipping methods name would appear
OC name would appear
Totals incl. and excl. have inverted positions
Many thanks for your help on this! And kudos to @tschumilas for previous work on the template topic
And finally - please note that legally compliant invoices are a work funded by the core budget, which is running low at the moment. So funded features and major bugs will always be prioritized by the team. This means I canāt give a due date on this work, so DONāT start advertising to your users that this will be released soon
Thanks @NiftyGaloot nice catch! Wrong copy paste on my side for the numbers, I will fix this tomorrow: the title of the column is correct: the numbers should be excluding tax
Looks compliant from a UK perspective - the only thing to confirm is that the manual adjustment row will also include negative adjustments? We have to show discounts in the UK so thatās the only thing thatās missing
Thanks @BethanOFN yes manual adjustment can be negative or positive, sorry this was not clear in the example. I have dited my post to add it and took the time to add an example of a voucher too.
And I should have fix the column as well @NiftyGaloot
Fingers crossed I havenāt done any wrong calculationā¦ Iām sooo bad at calculating tax from the including tax amount
Looks good! Thank you for the tons of thought that went into this work. Three questions:
Translations: I assume everything will be translated through Transifex. We are having a longstanding issue with translations applying to invoices (see this issue, example 2) - wondering if the new invoice will make this problem go away (customers and users are just annoyed by seeing terms like āGSTā and āABNā that they arenāt familiar wiith).
If a hub has not set up terms of sales, where does that link go? Is it possible too have a āgenericā or site wide one in that case?
Invoice number is by hub, so there will be (for instance) multiple invoice numbers ā500ā for instance? If so I wonder if that would be confusing or an extra step for folks who are managing multiple hubs or shops+hubs and just in general for us for user support? Are unique invoice numbers across the system out of compliance, or maybe I am not understanding?
Thanks @Rachel, it is so awesome to have you back by the way!
I am not sure about #1, I mostly only pay attention when it comes in email (our support team is copied so we see the examples there) - nobody has complained in a while, so I have not checked or put energy into it. Hoping it becomes a non-issue with the new invoice procedure.
Looks generally compliant - but a couple of questionsā¦
Under the Weight/Vol column - when something is sold as a āitemā, will it be the āunitā + āunit nameā as appears in the ādisplay asā field?
OC Name will be the name given to the order cycle at setup (general settings) or will it be the text that appears in the delivery details box on the āoutgoingā OC screen? Either is OK - I am asking because I thought this was an issue for you in France? It doesnāt matter to me - Iāll let users know whichever it is.
The new template does not have pickup method any longer. Is there a way to include that - or a reason not to include? It is handy when the hub packs by invoice and gives the invoice at pickup, its easy to sort the orders if PU option is on the invoice. I know we have a few hubs (including mine) that do this.
If there are multiple adjustments - will each show as a separate line?
Finally - is my math wrong? I canāt get to the same order total in my calculation.
OH also - just confirming where the enterprise contact info is coming from
assume it is the content given for ālegal nameā if they have entered anything there, but if ālegal nameā section is not completed, then it is the information from the enterprise āprimary detailsā
And the email in the invoice: right now it is the login listed as the enterprise owner (I think). Is that what we want - or should it be the contact email for the enterprise? Maybe it doesnāt matterā¦ Iām just noticing this.
Thanks @tschumilas ! To understand how this was made: when the field was not required legally I took it as it is currently working. This means:
Yes. The weight / volume is only changing place, itās not changing how it behaves. Note it takes BOM values if weight was changed in BOM
Oc name in step 1. Yes itās a problem for user who put silly names because for alt template users OC names are not shown to shoppers - thatās why in the new template proposal itās less big.
The new template has the shipping method: Iāve moved it on the price line: āhome deliveryā is my shipping method name
Yes, like today
Itās probably me - I suck at backwards tax calculation
Yes we will keep that rule, the email is the contact email if Iām not mistaken
Super. I had assumed the shipping line would only be there if there was a cost - but now I understand that even for pick-up where there is no cost, it will be on that line - and it will show $0 cost. Is that right?
Right now on the invoice I use, the email address is the shop owner, I thinkā¦(different from the enterprise contact). Iām good with either - not sure if it matters to anyone elseā¦?
I had assumed the shipping line would only be there if there was a cost - but now I understand that even for pick-up where there is no cost, it will be on that line - and it will show $0 cost. Is that right?
Yes. If there is a better idea Iām all ears, but itās the only one I have given the logo takes a lot of space.
Right now on the invoice I use, the email address is the shop owner,
Then itās a difference between the 2 template I havenāt spotted yet! I will add it to the change log and letās see if everyone agrees. But it makes more sense to use the public contact detail as the email the shop owner is using to login might be something they donāt want to communicate (a personal email address for example).
Hi folks, spoke to our Tax Office, who advised that Australian tax invoices need to specify the total GST, specifically using the word āGSTā, rather than just ātaxā, so unfortunately there would be an issue for us here. @Kirsten does this sound right to you?
@amida you will be able to put GST in your translation file, like what you are doing today. In other language, ātaxā does not work as well, so itās a strong requirement.
I note to add the total as well (although like I said I think that even with the breakdown, your invoices would show the total in AU, but I will make sure to test that part).
Thanks @Rachel for all your work on this. The new template looks good to me. I know that Bethan has already given feedback from a UK perspective. I will also check with @aaron but if you dont hear from him by your deadline then please assume the UK is happy