Add supplier name into default invoice template

@tschumilas did you get around to checking if this ‘invoice-setting’ dealt with oyour tax thing? https://ofn-user-guide.gitbook.io/ofn-super-admin-guide/ofn-platform-configuration/invoice-settings

sorry - I should have posted my findings. I was wrong - the invoice setting does NOT alter the problem I was describing. Basically, I was looking for a way to display the tax - where applicable - per item on the invoice. There is no way to do that in an instance where tax is calculated at checkout (as opposed to being included in the shop price.). this is not a big issue - just not as transparent as ideal. I have one user who doesn’t care - they have only a few taxable items and showing the tax total at the bottom of the invoice is fine. I have a second hub whose customers seem to want to know which products have tax - and that user is putting an (*) on taxable items and then we have a note at the bottom of her invoice indicating that means there was tax on that item.

The more I have been learning about sales taxes in Canada, the more I realized that there are some more fundamental changes to OFN that will need to happen. I suspect we’ll have to get into this in the US too. Multiple tax types and rates at different sub-instance levels for example, It will be important for anyone trying to interface with an accounting package too. But - I’d say this isn’t an immediate fish fo fry – but I’m going to be on the US call next week and I might just table it. We could set up a NA working group to at least understand what is ultimately needed perhaps. I think I have an accountant who would help us here in Canada. (We’ll need an accountant to work on this - its stupidly complex). I echo the point I’ve made elsewhere though – if we want ot be a global instance - we’ll need a way for OFN to be more flexible about taxation I think.

But this should be in a thread about taxation - is there one?

In terms of name on default invoice - I’d say we still really need that - but likely don’t understand the tax thing now to move on it.

@Kirsten T-shirt size XS to S, probably affecting 3 or 4 files (logic, template, styles). Do we have a scale for t-shirt sizes?

@MyriamBoure what do i need to do to progress this?

@MyriamBoure @danielle as this is already prioritised, is XS to S etc - can I create an issue and get it into ‘dev ready’? please? :slight_smile:

I don’t see why not @Kirsten.

Looking at the process map the next step for you is to incept it, create the GH epic/stories, and then get it slated for prioritisation in the roadmap by the product curation team.

16%20pm

Agree, it’s of course not the thing with most votes but it has some votes and is XS probably (to check) so let’s move on @Kirsten and make @tschumilas happy :slight_smile: !

1 Like

@MyriamBoure and @Kirsten - need help with process here. This item is still high on the list of what I want to vote for - but its not a ‘voting candidate’. Does it still go into the list of issues for voting?

Just a refresher - remember - there was some discussion on the bigger issue of generating accurate packing slips

I think we agreed ? that packing slips is a larger issue (and frankly I’m suppose to be leading that, and haven’t pulled a discussion piece together yet) – so I’d still like to vote for adding supplier name to default invoice template as a good, XS, short term solution to the packing slip challenges.

@tschumilas as far as I understand, we had already prioritized the bulk invoice printing and said we would add that bit as for Can that was needed for the need to be satisfied, so for me this is already prioritized, we will incept (should be suuuuper quick!) and we need a PO for it (it’s so tiny that maybe doesn’t need tech owner and kick off…) the PO will open an issue and put it in “feature backlog” so that it can be prioritized (before or after mobile ready which is already waiting for space in the pipe)… @Rachel it is super tiny but do you want to be PO for it ? Else I’m happy to :wink: We need to remember that there are two invoice templates and decide if we apply that change to both or not. Tiny inception but still a bit of inception.

So to answer your question you don’t have to vote for it anymore @tschumilas it went already through the first step :wink:

You are amazing - @MyriamBoure and @Rachel - BIG thanks for this. Means I have another vote to cast!! :yum:

Seems that this is already in the delivery pipe being built, yes @MyriamBoure? It’s #3437 and is being built by @maikel. So I’m changing the sub category of this to be in progress.

Please advise and move it back to the inception category if this isn’t correct :slight_smile:

hmmm @maikel has just asked me about the two invoice templates thing - I am obviously out of a loop as I had missed / forgotten that there were two! why are there two? Is there any reason why it wouldn’t go on both - I would assume that it should go on both as for whatever reason people are using one or the other we would still want them to be able to use to pack . . @MyriamBoure @tschumilas

I just opened a pull request where I put the name on both invoice templates.

There is a clue in the super-admin option to activate the newer template:

Use the alternative invoice model that includes total tax breakdown per rate and tax rate info per item (not yet suitable for countries displaying prices excluding tax)

So I think the solution here would require some inception:

  • Is there one view that would suit both cases?
  • If not, how do we deal with multiple countries which could have different tax settings?

so as I understand it - in super admi config - an instance decides to either include taxes in the shopfront price for each item (as Aus does I think) or add the tax - at checkout (As Can does). The tax settings (ie the tax categories and the tax rates the super sets up) are applied to the products the same way - its just that in option a - they are applied and shown in the shop. In option b - they show at checkout.
The issue with the invoice is that - IDEALLY - with option B (when taxes are calculated a checkout) they should show for each taxable item, and then a new item total with tax. BUT right now - the taxes show as a lump sum on the invoice. Its not a big deal. There are few taxable products. We just put an * on the product, and then a note on the invoice that says * means taxable. For now - and to keep this issue XS - I don’t think we have to change the way the tax is show - do we? Can we just add the supplier name to the templates that currently exist? (One day, we’ll have to embrace tax stuff - but that day is not today :wink:)

OMG - I just realized I could have said that all more clearly - and maybe you @maikel know this. So the separation of taxes on an invoice, at present, only works if price is included in shopfront price (as in Aus). If taxes are not included in shopfront price (as in Can) the invoice calculates the tax - but does not calculate it per taxable item on the invoice. Is that it? So - I don’t know why that is - but if its easy - why don’t we fix it now too? if its not easy - lets ignore it at this point.

hey @tschumilas - I am not clear why all or any of the above affects showing the Supplier name? Both invoices include a list of the Products ordered, so both would just have the Supplier name added under each product name? We don’t need to change anything with taxes at the moment, that would be out of scope for what this issue is

All the tax stuff is actually off topic here. We should solve that somewhere else. It was just good to understand why there are two different invoice templates that I needed to put the supplier name on. That is already in review and can get tested soon.

Agreed - the tax stuff is off topic here - I got us sidetracked. Sorry.

AND we are SOOOOO happy here in Canada that its done!!!