Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Vouchers can be associated with one or more acquisitions units via a new acquisitionUnits field the assignment table.  This indicates the acquisitions unit(s) for the voucher and all associated voucherLines.
  • The voucher's acquisitions units will often be the same as the invoice's, though this will not necessarily be true for "aggregate" and "batch" vouchers which relate to multiple invoices.
  • When generating vouchers upon invoice transition to "Approved", transpose the invoice's acquisitions units onto the voucher's.
  • The general approach is very similar to that of orders... 
    • For search, we're inserting a prefix to queries
    • For get by id, we're retrieving the record from storage, and then making a decision on whether to return it the user or not
    • For put/post also work the same way
    • NOTE: not all CRUD operations for vouchers are currently exposed at the business logic layer.  As such, not all of the bullets above make much sense.  Endpoints for these operations will be needed for "aggregate" and "batch" vouchers, and will eventually be added.

Organizations

TBD

  • Since acqUnits only apply to account records, not the entire oranization:
    • split out accounts into a separate table and API
    • add an acqUnitIds field to the account schema
  • Make necessary adjustments in the business logic module and UI to support this change.
  • Once this is in place the usual acquisition units handling can be performed like in other areas (orders/invoices/etc.)

Funds

  • TBD - This is a WIP and is subject to change.
  • funds can be associated with one or more acquisitions units via the assignment APIs.  This indicates the acquisitions unit(s) for the fund.
  • The general approach is very similar to that of orders... 
    • For search, we're inserting a prefix to queries
    • For get by id, we're retrieving the record from storage, and then making a decision on whether to return it the user or not
    • For put/post also work the same way
  • A new schema needs to be introduced which combines fund and an acquisitionUnits field containing an array of acquisition unit UUIDs. 
    • This will be used in POST/PUT and can be phased into the GET APIs
    • The business logic layer (not implemented yet) will be responsible for making calls to both finance-storage.funds and finance-storage.acquisitions-unit-assignments APIs
  • Views will need to be created in the storage module and will be used when querying funds.
    • Join the fund and acqUnitAssignments tables on fund.id == recordId (Requires DISTINCT ON)

...