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

Record whether allocation is for core funding #57

Open
llewelld opened this issue Nov 22, 2024 · 0 comments
Open

Record whether allocation is for core funding #57

llewelld opened this issue Nov 22, 2024 · 0 comments

Comments

@llewelld
Copy link
Contributor

User story: "As someone performing cost-recovery, I'd like to know if an allocation was intended to come from a project finance code, or from core funding, so that it can be established automatically whether a core funding request is valid or not"

When an approval is made for a subscription, it's currently assumed to be form Core funding unless a finance row has been added to cover the costs.

This means that core funding is assumed unless there's a project code to draw the funds from.

As part of the cost recovery integrity checks, there's a check for "Costly subscriptions without cost recovery" as well as for "Approvals without a matching finance row".

If core funding had to be requested explicitly as an alternative to using a finance code, it's possible these integrity checks could be streamlined.

It might also make it possible to have a command to enter approvals and fiance rows simultaneously, which would avoid duplicating similar information and also reduce the likelihood of mismatched data (which could help avoid entries being generated from the other integrity checks as well):

rctab sub --subscription-id <UUID> \
    --ticket <TICKET> \
    --amount <AMOUNT> \
    --date-from <FROM> \
    --date-to <TO> \
    --finance-code <CODE> \
    --priority <PRIORITY> \
    --allocate
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

No branches or pull requests

1 participant