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

Implemented processor for New-PI credit #112

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

QuanMPhm
Copy link
Contributor

@QuanMPhm QuanMPhm commented Nov 7, 2024

Closes #101. Depends on #108. I've implemented processor for applying the New-PI Credit, and included a new field to distinguish between the PI balance and the NERC balance. More details are in my commit message.

There are two commits to this PR, starting with Initialized processor for applying the New-PI Credit and discounts. The first one only copies over code, while the second commit actually makes functional changes.

@QuanMPhm QuanMPhm force-pushed the 101/proc_new_pi_credit branch 2 times, most recently from 0299851 to 59c0012 Compare November 11, 2024 20:23
@QuanMPhm
Copy link
Contributor Author

I fixed a bug with apply_discount_on_project(). In its old version, the function could lead to a negative PI balance.

@knikolla @naved001 I could write the test cases that would catch this mistake in this PR, but since the PR for #102 would catch this, I believe I will just write these tests in that PR?

@naved001
Copy link
Collaborator

I fixed a bug with apply_discount_on_project(). In its old version, the function could lead to a negative PI balance.

Could you say more about the impact of this bug? Would we need to rerun the invoice with the bug fix?

I could write the test cases that would catch this mistake in this PR, but since the PR for #102 would catch this, I believe I will just write these tests in that PR?

Which commit has the bug fix? the commit message in the 3rd commit covers a bunch of things and I didn't find a note about the bug fix. Also, if the fix for a bug is in this PR I think the test should also be a part of this.

@QuanMPhm
Copy link
Contributor Author

QuanMPhm commented Nov 12, 2024

@naved001 The bug fix was made when I amended my PR and force-pushed on Nov 11. This should show you the changes I made to fix the bug.

Edit: @naved001 This was a bug I found in this PR, not in upstream, so it has not have any impact on any of our past billing data.

process_report/invoices/NERC_total_invoice.py Show resolved Hide resolved
Comment on lines 9 to 13
"""
Dependancies:
- ValidateBillablePIsProcessor
- NewPICreditProcessor
"""
Copy link
Member

Choose a reason for hiding this comment

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

What are these dependencies? Are we documenting them here (and elsewhere in this file) because they are otherwise non-obvious?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Many of the invoice subclasses expect certain columns to exist in the dataframe they are given, and some of those columns are initialized and populated by certain processors. ValidateBillablePIsProcessor populates the IS_BILLABLE_FIELD and MISSING_PI_FIELD, while NewPICreditProcessor populates many columns, such as BALANCE_FIELD. These columns are used by many invoice classes, including NERCTotalInvoice, during their filtering or exporting steps. As such, I believed that there are dependencies between invoices and processors, since many invoices need certain processors to run before them to work properly.

I thought that I should highlight these dependencies with these docstrings. I will follow your advice if you believe something better should be done.

Copy link
Member

Choose a reason for hiding this comment

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

I think it's fine to document this in the class docstring, but I think you should be a little bit more verbose. E.g., This class requires the following columns to be defined in the input dataframe:. This makes it clear that you're not referring to Python modules or classes or something else that could be considered a "dependency". If the required fields are only provided by a specific processor, it's probably better to say something like This class operates on data that has been processed by NewPICreditProcess.

Also note that the spelling is "dependencies".

from process_report.processors import discount_processor


@dataclass
Copy link
Member

Choose a reason for hiding this comment

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

Why is this a dataclass? It doesn't appear to have any class attributes. I guess the same question applies to discount_process.DiscountProcessor as well.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

NewPICreditProcessor does have old_pi_filepath and limit_new_pi_credit_to_partners as its class attributes, but as for DiscountProcessor, you are right, it has none. I guess I made them dataclasses for uniformity with all the other processors and invoices and didn't put too much thought into it.

I will remove @dataclass from DiscountProcessor

Code from `BillableInvoice` and `DiscountInvoice` has been copied over
without change
The `DiscountProcessor` class has been created, to be subclassed by
processors which applies discounts, such as the New-PI Credit.
This processor class introduces an important class constant,
`IS_DISCOUNT_BY_NERC`, which detemines whether the final balance,
as opposed to the PI balance (more info below), reflects the discount
being applied.

The New-PI credit is now implemented by `NewPICreditProcessor`

During discussions about billing, it was made noted that some discounts
are not provided by the MGHPCC, but instead from other sources, such as
the BU subsidy, which is provided to BU PIs by BU. This provided
motivation for a `PI Balance` field, which would reflect how much money the
PI should be billed, as opposed to the `Balance` field, which currently
reflects how much money the MGHPCC should receive. These two fields would
not equal each other if the PI received discounts not provided by the
MGHPCC.

Implementation of `NewPICreditProcessor` and the new billing
feature required a range of changes:
- `apply_discount_on_project()` in `DiscountProcessor` has been slightly
modified, where the PI balance and MGHPCC balance is now calculated seperately.
- As `BillableInvoice` no longer performs any processing itself, the
dataframe from `NewPICreditProcessor` is now passed to all invoice objects.
- The test cases for the New-PI credit have been refactored. Test cases
for the new billing feature is not written yet. I plan to write
them when the processor for the BU Subsidy is implemented
- With the new processor, certain Processor and Invoice classes depend on
fields created by other Processors, such as the case with
`NewPICreditProcessor` and `ValidateBillablePIsProcessor`. As such, docstrings
have been added to indicate dependancies
Copy link
Collaborator

@naved001 naved001 left a comment

Choose a reason for hiding this comment

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

This looks fine to me. However, I'd like in the future that PRs this size be broken down into smaller commits.

It would also be nice if we split the unit tests, right now it's all one giant file.

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.

Refactor processing for the New-PI credit
4 participants