Skip to content
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

3283 [Enterprise Fee Summary] Fix values when calculator is order-based #3337

Conversation

kristinalim
Copy link
Member

@kristinalim kristinalim commented Jan 16, 2019

What? Why?

Relates to #3283
Closes #2616

Because of constraints in the way we compute and store calculations for order-based calculators, there is no way currently to track the exchange to which an order-based exchange fee is associated, and to break down this fee per line item/variant/supplier.

So, we do not have an existing way to get "Fee Calc on Transfer Through" and "Tax Category" (when the Enterprise Fee itself does not have an associated tax category) for these exchange fees.

As proposed in #3283, we could use "Entire Orders through DISTRIBUTOR_NAME" for these order-absed exchange fees. For "Tax Category", we could use "Various" when there is no associated tax category to the enterprise fee.

What should we test?

  1. Set up an OC with different enterprises for producer, coordinator, and distributor.
  2. Set up an incoming and outgoing exchange for a variant with stock.
  3. Fees for exchanges: For the incoming exchange and also for the outgoing exchange, add one enterprise fee with order-based calculator (such as "Flat Rate (per order)") for each of the producer, coordinator, and distributor. For testing purposes, one of these enterprise fees should assign a tax category, one should inherit the product's tax category, and one should have no tax category.
  4. Coordinator fees: Add two "coordinator fees" with order-based calculator to the OC, not to an exchange. For testing purposes, one of these enterprise fees should assign a tax category, one should inherit the product's tax category, and one should have no tax category.
  5. Create and complete an order for the variant.
  6. Check the Enterprise Fee Summary.
  7. For the 6 rows marked "Incoming" / "Outgoing":
    • "Fee Calc on Transfer Through" for the exchange fees should show "Entire Orders through DISTRIBUTOR_NAME".
    • For tax category:
      a. If the enterprise fee itself has a tax category, this should be used.
      b. If the enterprise fee inherits the product's tax category, this should be "Various".
      c. If the enterprise fee has no tax category, this should be blank.
  8. For the rows marked "Coordinator":
    • "Fee Calc on Transfer Through" should be "All". For tax category.
    • For tax category: Same as in Step 6.

Release notes

No release notes needed as this would be packaged with the rest of the initial changes for the Enterprise Fee Summary.

Changelog Category: -

Dependencies

This requires #3319 to be merged to the transitional branch first.

@kristinalim kristinalim self-assigned this Jan 16, 2019
@kristinalim kristinalim force-pushed the feature-enterprise_fees_report-order_based_calculator_bug branch from 8321c43 to 57ea1f9 Compare January 16, 2019 15:22
@kristinalim kristinalim changed the title 3283 [Enterprise Fee Summary] (Pending) Fix values when calculator is order-based 3283 [Enterprise Fee Summary] Fix values when calculator is order-based Jan 22, 2019
module OrderManagement
module Reports
module EnterpriseFeeSummary
module DataRepresentations
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does this namespace provide other than making the nesting level pretty wide? These model classes won't clash with any other within the EnterpriseFeeSummary namespace, so I'd just remove DataRepresentations.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I disagree about removing DataRepresentations, @sauloperez.

The class ends up more deeply nested, but DataRepresentations I think makes it easier to find/ignore these classes and gives you an idea about their purpose.

If we reduce the nesting, I would want to rename the individual classes to reflect that they map DB query row attributes to report row attributes. For example, append "Representation" or "Presenter" (both terms actually from review of @mkllnk). Compared to this, I prefer nesting.

Let me know if you are okay with keeping this.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like this way of using namespaces to organize your code! #java

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

to me, it's pretty obvious already. The class name is a noun named after a domain concept. What else could it be? But if you guys prefer it, I don't mind.

spec/factories/orders.rb Outdated Show resolved Hide resolved
after(:create) do |order, evaluator|
create(:line_item, order: order, variant: evaluator.variant)
end
end
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we really need this new trait? Spree itself has the order_with_line_items factory already. Other than that, this could be done by simply creating two of the three entities and letting FactoryBot create the third one. I'm just concerned about having too many purpose-specific factories that need to be maintained over time. I believe that is already the case in OFN.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suppose you are talking about :order_with_totals_and_distribution:

factory :order_with_totals_and_distribution, :parent => :order do #possibly called :order_with_line_items in newer Spree

The problem I found with this is that it does too many things, including creating a product and a line item for the product. It's not reusable for the Enterprise Fee Report tests, which need explicit variant and line item setup. That's why I set up these factory traits which do fewer things for the factory object.

end
end

trait :completed do
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Spree has the completed_order_with_totals factory, which we reused to build more complex ones in OFN. Can't we use just that one?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same problem with this factory, @sauloperez.

@mkllnk mkllnk force-pushed the feature/enterprise_fee_summary branch from b7131b4 to 545d482 Compare January 22, 2019 23:10
@kristinalim kristinalim force-pushed the feature-enterprise_fees_report-order_based_calculator_bug branch from ed8991a to 9e98b60 Compare January 23, 2019 19:28
@kristinalim
Copy link
Member Author

This is ready for another round of reviews. 🙂

Copy link
Member

@mkllnk mkllnk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice abstractions. :-)

@kristinalim
Copy link
Member Author

I updated the issue description to also close issue #2616. This is the last PR addressing known issues in the report values.

@kristinalim
Copy link
Member Author

Thanks, @luisramos0! Moving this to "Test Ready".

@RachL RachL added the pr-staged-au staging.openfoodnetwork.org.au label Feb 2, 2019
@RachL RachL assigned RachL and unassigned RachL Feb 2, 2019
@RachL RachL removed the pr-staged-au staging.openfoodnetwork.org.au label Feb 2, 2019
@sigmundpetersen sigmundpetersen added the pr-staged-au staging.openfoodnetwork.org.au label Feb 8, 2019
@luisramos0 luisramos0 force-pushed the feature/enterprise_fee_summary branch from 3200492 to b6be8c4 Compare February 8, 2019 21:27
@kirstenalarsen
Copy link
Contributor

YIHIYIPPEEEEIO!!! YES!!! Passed the tests and good to go! Fantastic test notes @kristinalim I was overwhelmed but when I looked closely and just worked through the steps it made perfect sense and was thorough and I am confident that it works. YAY! So excited! MERGEROONIE!

@kirstenalarsen kirstenalarsen removed the pr-staged-au staging.openfoodnetwork.org.au label Feb 9, 2019
@sauloperez
Copy link
Contributor

sauloperez commented Feb 11, 2019

Sorry to ruin the party but I think it's better if you rebase it @kristinalim first

@kristinalim kristinalim force-pushed the feature-enterprise_fees_report-order_based_calculator_bug branch from 9e98b60 to b85506d Compare February 12, 2019 09:04
@kristinalim
Copy link
Member Author

I've rebased, @sauloperez. Conflict now gone, and build is green. Thank you!

@kristinalim
Copy link
Member Author

As discussed here #3415 (comment), @sauloperez I recommend merging #3415 first. And then I will change the base of this PR to master and rebase, to comply with the process. 👍

@sauloperez
Copy link
Contributor

done. #3415 merged

This is not filling the "Fee Calc on Transfer Through" column. This will
be addressed in another commit.
For exchange fees with calculator that is order-based:

* "Fee Calc on Transfer Through" should show "Entire Orders through
  DISTRIBUTOR_NAME".
* For tax category:
  a. If the enterprise fee itself has a tax category, this is used.
  b. If the enterprise fee inherits the product's tax category, this is
     "Various".
  c. If the enterprise fee has no tax, this is blank.

For coordinator fees:

* "Fee Calc on Transfer Through" should be "All".
* For tax category: Same as abova.
The superclasses will include this module, instead of inheriting the class.
There is no more need to pass the summarizer.
@kristinalim kristinalim force-pushed the feature-enterprise_fees_report-order_based_calculator_bug branch from b85506d to 5e8a336 Compare February 12, 2019 14:52
@kristinalim kristinalim changed the base branch from feature/enterprise_fee_summary to master February 12, 2019 14:52
@kristinalim
Copy link
Member Author

Aha! 🙂 Finally, a green build.

I've rebased this already, and changed the base branch to "master". This is ready to go.

@sauloperez sauloperez merged commit bda5eb1 into openfoodfoundation:master Feb 12, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Build Enterprise Fee Summary Report
8 participants