You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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):
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):
The text was updated successfully, but these errors were encountered: