The user would like to be able to change an account to a different, new account in the system. The first steps to enabling this process will be to create a service that encapsulates the handling of this process. In this issue we will create the interface and initial implementation of this service as well as updating the current-year's transactions to point to the new account. We will also be adding an entity/aggregate to track changes to accounts.

• Create an AccountTransition entity class

  • AccountTransition will be an aggregate so we also need to create a basic repository with CRUD operations

  • One instance of AccountTransition represents exactly one change from a single account to another account within a fiscal year. Therefore, this class should have the following:

    • fromAccount : GeneralLedgerAccount

    • toAccount: GeneralLedgerAccount

    • fiscalYear: Integer

    • Update Liquibase changelog as required

• Update GeneralLedgerAccount to have a getSourceAccounts() : Set<AccountTransition> method. This method should use the AccountTransitionRepository to query for all AccountTransition where the toAccount equals the given account (or return an empty list if no sources exist)

  • NOTE: This Set of AccountTransition is intended to provide traceability for reporting purposes. We should be able to trace a single general ledger account through all of its historical transitions to help generate reports. The AccountTransition will be the owning side of the relationship.

• Create AccountChangeService interface and implementation classes

  • Should be a Spring bean annotated with @Service

  • Should have a single method post(Iterable<AccountTransition> accountTransitions)

  • The post method should iterate through the account transitions one-by-one and update all associated transactions for the associated fiscal year with the new account. The user will be required to create an account in the UI before the AccountTransition is sent to the post method. A non-existent account passed via an AccountTransition is a programmatical error and should throw an assertion error.

    • When writing this, keep in mind this process is expensive and we may need to break this down into concurrent tasks. Having different private methods for each type of entity associated with a single account might be a good idea to help decompose this process. Get creative but be sensible so we can easily modify this in the future if we need to optimize the code. Please do not write this process as one monolithic private method.

    • Need to update:

      • PurchaseOrderCharges (ExpenditureAccount change only)

      • RequisitionCharges (ExpenditureAccount change only)

      • ReceiptItems

      • DisbursementExpenditureItems (ExpenditureAccount change only)

      • RefundItem (RevenueAccount change only)

      • DistributionItem

      • InterFundCashTransaction

      • InvoiceItem (ExpenditureAccount change only)

      • DO NOT update PayableJournal's reference to account. This should be fixed by updating the InvoiceItem

      • DO NOT update PendingTransactionItem's reference to account. We are going to let pending transactions fail if they have an incorrect account and force someone else to re-post a pending transaction with the correct account

      • Look through the model and see if you can find any other transactions/objects that should be updated as part of this process. If you find any discuss with the group whether or not the change should be included in this process if it isn't obvious

    • In order to do the previously mentioned changes to accounts associated with transactions, we will need to do the following:

      • Record which periods are current open in fiscal year (for restoration later)

      • Open all closed periods in the fiscal year

      • Update the transaction information and save the transaction

      • Close the periods that were closed at the beginning of the change process

NOTE: After this issue is complete this process will be broken in that remapping of accounts to the correct appropriation, updating stop dates for accounts, etc. will not have been implemented. This was done purposely to limit the size of this issue.