Proposal: a unique invoice template for all instances

Helloo!

The delivery team is currently working on getting OFN invoices legally compliant.

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.

Previous regular template example:
Regular_previous_v2.pdf (29.4 KB)

Previous alternative example:
alt_previous_v2.pdf (46.6 KB)

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):

newtemplate_v3.pdf (62.6 KB)

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 :pray:

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
  • A date of service will be shown (see Legally compliant invoices: Include date of service (payment or delivery/shipping/pickup date) Ā· Issue #58 Ā· openfoodfoundation/wishlist Ā· GitHub)
  • 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 :slight_smile:

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 :wink:

2 Likes

Should the Price per unit column say (Including tax) instead of (Excl. tax)? Or, is my math wrong?

1 Like

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

1 Like

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 :see_no_evil:

Looks good! Thank you for the tons of thought that went into this work. Three questions:

  1. 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).
  2. 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?
  3. 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?
1 Like

@lauriewayne1

  1. Yes it should, thanks for sharing I forgot that one! Does it occur as well when you print from the edit order screen?

  2. If no terms of sales, no link. We can improve this in the future of course, but I would leave it like this for first release

  3. Aparently a unique invoice number is needed in the UK, we are still figuring this one out, discussion here: Slack

1 Like

Thanks @Rachel, it is so awesome to have you back by the way! :green_heart:

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ā€¦

  1. 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?
  2. 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.
  3. 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.
  4. If there are multiple adjustments - will each show as a separate line?
  5. Finally - is my math wrong? I canā€™t get to the same order total in my calculation.
1 Like

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.

1 Like

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:

  1. 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

  2. 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.

  3. The new template has the shipping method: Iā€™ve moved it on the price line: ā€œhome deliveryā€ is my shipping method name

  4. Yes, like today

  5. Itā€™s probably me - I suck at backwards tax calculation

  6. 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ā€¦?

1 Like

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).

@instance_managers a small reminder for instances who havenā€™t check this thread yet: deadline is next Monday :slight_smile:

Many thanks to all the people who commented so far :pray:

Hi Rachel,

It seems good to me ! All the remarks were very useful, thanks you folks :slight_smile: Consider it ok for OFN Be!

1 Like

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 :slight_smile:

1 Like