Uploaded image for project: 'UX Product'
  1. UX Product
  2. UXPROD-2409

Limit percentage of spend by expense classes

    XMLWordPrintable

    Details

    • Template:
      UXPROD features
    • Front End Estimate:
      Large < 10 days
    • Back End Estimate:
      Large < 10 days
    • Confidence factor:
      Low
    • Development Team:
      Thunderjet
    • Calculated Total Rank:
      28
    • PO Rank:
      33.1
    • Rank: Chicago (MVP Sum 2020):
      R4
    • Rank: Cornell (Full Sum 2021):
      R2
    • Rank: Duke (Full Sum 2021):
      R4
    • Rank: 5Colleges (Full Jul 2021):
      R4
    • Rank: GBV (MVP Sum 2020):
      R1
    • Rank: Grand Valley (Full Sum 2021):
      R4
    • Rank: MI State-Lib of MI (Sum 2021):
      R5
    • Rank: MO State (MVP June 2020):
      R4
    • Rank: TAMU (MVP Jan 2021):
      R2
    • Rank: U of AL (MVP Oct 2020):
      R3

      Description

      Problem: Allocating money to each individual Fund can be time-consuming for an administrator. When using shared pools there are no restrictions/limits on spending by expense class. One group could spend all money before others have a chance too.

      Use cases:

      • Librarian creates a shared allocation and once of the codes spends all the money before others are able to make any purchases. More money then needs to be added to the Fund. Other groups feel cheated if the budget can't be increased
      • If user is spending money against a code we are able to restrict their visibility to the specific Budget from which they are spending. They can see how much they have spent and how much is left
      • Manager would like to communicate a target amount for the fund and have it be clear how much has been spent toward that target.
      • When rolling over budgets we want our targets to function as a percentage of the allocated amount. Budgets can drop or increase drastically.
      • Manager wants to set limits for expense classes that would equal more than 100%. This allows each class to spend up to maybe 60 percent of the total but at the end of the day they are restricted to spending 100% of the budget as a group, factoring in allowable expenditure. We don't care which one gets closer to 60% but want to make sure that neither one spends more than 60%
      • User may create one Fund for Endowments and use expense classes to track the specific sources individually. In this case exact amounts need to be set for each expense class to restrict expenditure

      Requirements:

      1. Each expense class can view how much money is left and how much they have spent within a given Fund/budget factoring in restrictions
      2. When processing invoices/orders limits are factored into the 'do we have enough money' check
      3. Restriction are NOT required
      4. User can set an Expenditure target for each expense class. Target can be a percentage or amount value.
      5. All values are carried over to the next years budget as is. User can edit them if needed.
        • Note: target amounts may be more manageable. The target values would not need to equal 100% of the budget, they would act as a limit for the expense class but could not be used if the actual budget had already been exhausted.
      6. User can toggle limit expenditure to restrict use of the expense class be less than or equal to it's Expenditure target.
      7. If allowing percentages it is suggested we use Allocation rather than Available. Calculating this may be problematic. Available will fluctuate

      Questions:

      1. Would these limits need to persist year over year or would they be reset? Yes it is valuable to not need to start from scratch each year.

        TestRail: Results

          Attachments

            Issue Links

              Activity

                People

                Assignee:
                dennisbridges Dennis Bridges
                Reporter:
                dennisbridges Dennis Bridges
                Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                  Dates

                  Created:
                  Updated:

                    TestRail: Runs

                      TestRail: Cases