-
-
Notifications
You must be signed in to change notification settings - Fork 730
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Flower Farms] - Pay Suppliers Report #12879
[Flower Farms] - Pay Suppliers Report #12879
Conversation
271aa44
to
bbed8f2
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great work! This looks good, but I have a ❓ query and a ±
request for a change.
Also some other comments, but they are less important.
end | ||
|
||
def order_number | ||
proc { |line_items| order(line_items).number } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
❓I could be wrong, but it looks like there could be multiple orders grouped together, so I don't think we should show an order number here, should we?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, you are right. Now, that I think of it and reviewed the report again, each order and their respective order cycles should have been displayed here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doing this fix now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's fixed here 8ee8b37
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great!
±
Now I think the line item helpers are no longer needed: variant
, order
, supplier
, distributor
, item_order_cycle
lib/reporting/reports/suppliers/helpers/line_items_access_helper.rb
Outdated
Show resolved
Hide resolved
b793d82
to
8ee8b37
Compare
@dacook - I've addressed your comments, please review. Thanks |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good @chahmedejaz ! But I think we can improve the testing a little bit.
line_items.each do |line_item| | ||
summary_hash[:total_excl_vat_and_fees] += total_excl_vat_and_fees.call(line_item) | ||
summary_hash[:total_excl_vat] += total_excl_vat.call(line_item) | ||
summary_hash[:total_fees_excl_vat] += total_fees_excl_vat.call(line_item) | ||
summary_hash[:total_vat_on_fees] += total_vat_on_fees.call(line_item) | ||
summary_hash[:total_tax] += total_tax.call(line_item) | ||
summary_hash[:total] += total.call(line_item) | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We are only testing with one order and one line item. I think we need to update the spec to use more than on order and more than one line item in order for this to be properly tested.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It has been addressed here: 03c8e2c#diff-36e7c39c383994d08652e0192d25c4f629d776cc106cb7cec3268bbb8cbd59bf
def variant(line_item) | ||
line_item.variant | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now most of these helpers are no longer required and can be removed ;)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not as of now, I think they are used in multiple places 😅
I think this addresses Gaetan's feedback sufficiently. Ready for manual testing. |
03c8e2c
to
9c70867
Compare
9c70867
to
7f150c7
Compare
Hi @chahmedejaz, @RachL and @tschumilas, Wow, there's a lot to think of and to test here. Overall it's looking really great already. I found two things which I would like to have your confirmation for (marked ❓) and two things around fees need updating, I think (marked ❌). Here is a quick summary:
Regarding assignment of feesThis is the fee I have set up: It is applied to the distributor of the order cycle: In the order details we can see that it's charged by the distributor (Konrad Testhub): The fee is added to supplier of the product (not the distributor, who is charging the fee). I think this leads to incorrect results if you want to pay your suppliers. ❓ It's tricky to solve. Do we have to list those line items again in the area of the distributor? And then only list the fee there? Regarding taxes on feesTaxes on fees are not displayed (all zero): Unfortunately we are not displaying those taxes in the order details, but doing the calculation shows that it is included in 2.78 $: Also the report "Enterprise Fees With Tax Report By Order" shows that the tax was calculated: Open for testing
ConclusionI will move this back to "In progress" but before working on it, let's hear the feedback. Adding the feedback needed label too. |
Test taxes (blank if supplier is not tax registered) This is a report to payout suppliers. So it is supplier enterprise fees and supplier tax status (registered or not) that matters. The tax shown may be different than the taxes (on fees or products) shown in other reports. (This is why we need this particular report)
(1) The supplier is tax registered AND the distributor (hub) is tax registered. The distributor (hub) will collect tax on taxable products. The hub will pay the supplier these taxes the hub collected, so the hub needs this number. (The tax registered supplier will remit this tax to the government) |
@chahmedejaz is it clear for you on how to proceed here? Let me know if you'd need a call. |
Thanks @drummer83 and @RachL I'm looking into the issue to understand it properly, I validated the fees part, I think it's worked fine for me. I'm a bit confused on whose fees should be included? Supplier's or the distributor's? |
In response to the question - whose fees should be included - supplier fees, distributor fees or both? But maybe there are other use cases elsewhere? I'm going to post in instance managers to see. |
Thanks for the response @tschumilas. Sorry for the delay, I'm just back from my wedding vacation. Anyhow, as per my understanding, of:
Do we need to include only the green highlighted enterprise fees? CC: @RachL , @drummer83 |
7f150c7
to
25611fd
Compare
Co-authored-by: David Cook <[email protected]>
- wrong enterprise fees - always 0 tax on fees
…er.rb Co-authored-by: David Cook <[email protected]>
7a715ea
to
ed76852
Compare
I don't know why this was not merged, but I agree we can move to production and test with real-life cases now, so I've rebased and will merge with bypass. KUDOS @chahmedejaz @drummer83 @filipefurtad0 this was a tough one |
Forgot to click the button 😅 |
I think we have 2 issues with this report. Maybe this is a translation issue? But the column labelled "Total Tax ($)" is calculating the tax on just the product - column I * tax rate (.13 in this example). So I think this column should be 'Product Tax'. So is this my mislabeling in transifex? Second issues is trickier - and maybe my mistake at the beginning. A hub collects taxes on the sale. But the hub will only payout these taxes to a supplier IF the supplier is tax registered. That is, if 'charges tax = yes' If for a given supplier, 'charges tax' = no, then NO taxes should be paid out by the hub to this supplier , so columns L and M should be blank. So - we as a minimum, we need this report to have a column that indicates if the supplier's tax registered status. This should be the 'charges tax' status. Maybe in other places, the ACN/ABN number is this - but here in Canada, an enterprise can have a business number but not be tax registered. If we have a 'charges tax' column (with yes/no), then the hub manager can 'do the math' and payout or not payout the taxes. In the testing notes above @drummer83 noted this same issue during testing: Here's an output with a single supplier who does not charge tax. This is their business setting: And here is the report output for a charges tax = 0 supplier |
@tschumilas thank you for this detailed testing! regarding the tax, can I clarify who is the owner of the fee in your example? I'm a bit confused why the tax on the fee is greater than the total tax 🤔 Regarding the naming, I don't think this is how we've specified it in the issue: https://docs.google.com/spreadsheets/d/1XDi3whY2h2DnHQtYS0Fbogr_VTJmYhAXzt1p9ElBBbM/edit?gid=0#gid=0 The total tax was (to my understanding) the sum of all taxes, including fees. So that total excl. tax + total tax = total. But maybe what's missing is actually a column showing the total product tax? |
The total tax does not include the tax on fees. Maybe that's what is missing here 😅 Moreover, as per this:
I think we need another column in the report to show the tax status of the supplier. |
so if I understand - right now on the example above - 'total tax' is the tax on product, sorry I missed that. Yes that calculates. .13 (the tax rate on for this product) * 21.69 (total excluding fees and taxes ) - total tax (2.82) And, it makes sense that total tax in this report (tax on product) can be less than total tax on fees. In the example above there are very steep per item shipping fees - so thats why. (These are supplier fees - which is why they are showing in this report - so all good there.) As an aside - I've been thinking of trying to make a section for the user guide dedicated to understanding reports. We have a not of new ones, that are very specific. I know I'm getting the mixed up - and questions on reports is now the most common area of questioning I'm getting from users. So yes we need a column to show tax status of the supplier. Perfect! |
@tschumilas maybe we should have a quick call about it? I'm thinking it would be clearer to have a column called product tax + a total tax column. so we have the full breakdown. We can add a column indicating if the producer is tax registered, but to me, if the producer is not tax registered, then the product tax column is 0. So I think we have a bug in the example you've shared? |
I agree with you @RachL and maybe we should have a call because I'm also wanting make sure this report is useful outside of Canada. But I'm not clear how hubs where taxes are included in prices issue payouts. So my thining was to have all the numbers show - even when the supplier is not tax registered - and the hub can decide which total to payout (without or with tax). It seems its more generally useable that way. |
just a quick answer:
I don't think there is an OFN country currently that pays taxes to suppliers if they are not registered. So, the CA use case is as far as I know the general use case; So let's make it easy for our users 👍 |
@chahmedejaz I've created #13013 in order to add the columns. Theresa has sent me on slack the fees set up in the example above, I will try to set them up on a staging server to reproduce the problem of tax columns not at 0 when producer is not tax registered and create an issue accordingly. |
Sure, Rachel 👍🏻 |
What? Why?
What should we test?
Release notes
Changelog Category (reviewers may add a label for the release notes):