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

Refactored invoices to seperate invoice processing from exporting #97

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

Conversation

QuanMPhm
Copy link
Contributor

@QuanMPhm QuanMPhm commented Sep 18, 2024

Closes #95. The Processor class has been implemented, and all processing steps that I could think of has been implemented as a subclass of the Processor class. I have also tried my best to implement every feature listed in #95.

I will do cleanup of some comments I've left in after everything is settled.

I hope the commit messages provide enough explanation.

A `Processor` class has been added, subclassing from the `Invoice` class.
This is the first step to refactor invoicing in order to seperate the
processing and filtering/exporting functionalities of our current
Invoice subclasses. Subclasses of `Processor` should only process invoices
and manipulate its internal data, while subclasses of `Invoice` should
only perform fitering and exporting, never changing any data itself.

In addition to implementing `Processor`, two of its subclasses,
`ValidatePIAliasProcessor` and `AddInstitutionProcessor` has been
added to perform some preliminary processing steps.
Note that, for now, only the Lenovo invoice will take the processed
data from the `LenovoProcessor`. All other invoices will take the
data from `AddInstituteProcessor`. This is due to the processors
adding new columns. This odd code design will be removed once invoices
gain the feature to filter out their exported columns.
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 this discount.

During discussions about billing, it was made noted that some discounts
are not provided by the MGHPCC, but instead rom other sources, such as
the BU subsidy. This provided motivation for the `PI Balance` field,
which reflects how much money the PI owes, as opposed to the `Balance`
field, which reflects how much money the MGHPCC should receive.

`apply_discount_on_project` has been slightly modified, where the
PI balance and MGHPCC balance is now calculated seperately.

For now, the `PI Balance` field will appear in all invoices after
the Billable invoice.
Since all current discounts have been implemented as processors,
the `DiscountInvoice` class is now removed. No invoice class will
now class `_prepare()` or `_process()`.

`BUSubsidyProcessor`, which handles processing for the BU subsidy,
requires introduction of a new field, `BU Balance`, because the
subsidy is not provided by NERC. Because of this, `BU Balance` indicates
the money which BU (not the PI they are subsidizing) owes to the
MGHPCC.
… and column names

Two class attributes, `export_columns_list` and `exported_columns_map`,
has been added to `Invoice`, along with a class function `_filter_columns()`.
Subclasses of `Invoice` must now define `export_columns_list`, containing
the ordered list of columns that must be exported in their respective
invoices. Subclasses can optional define `exported_columns_map`,
containing mappings between "internal" column names and what their
name should be when exported.

The field name `RATE_FIELD` has been added to `invoice.py`. It was
previously forgotten.
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 billing by implementing a Processor class
1 participant