Fields: Funds
See the associated Accounting Funds resource section for more information on how to use this resource and supported operations.
Additional references
| Type | Value | Additional information |
|---|---|---|
| Permissions resource | accounting/funds | Permissions |
| Hooks filename | accounting.funds.groovy | Pre and post-processing hooks |
| Distinct query-supported | No | Distinct |
API version 3
A fund is a container for a time-bounded reference currency called credits for which the usage is restricted by constraints that define how the credits must be used. Much like with a bank, an fund is a repository for these resource or service credits which are added through deposits and debited through withdrawals and charges. Each fund has a set of constraints designating which entities (such as Users, Accounts, Machines, Classes, Organizations, etc.) may access the fund or for which aspects of usage the funds are intended (QualityOfService, GeographicalArea, Feature, etc.). Fund constraints may also be negated with an exclamation point leading the constraint value.
When credits are deposited into an fund, they are associated with a time period within which they are valid. These time-bounded pools of credits are known as allocations. (An allocation is a pool of billable units associated with an fund for use during a particular time period.) By using multiple allocations that expire in regular intervals it is possible to implement a use-it-or-lose-it policy and establish an allocation cycle.
Funds may be nested. Hierarchically nested funds may be useful for the delegation of management roles and responsibilities. Deposit shares may be established that assist to automate a trickle-down effect for funds deposited at higher level funds. Additionally, an optional overflow feature allows charges against lower level funds to trickle up the hierarchy.
Funds may have an arbitrary name which is not necessarily unique for the fund. Funds may also have a priority which will influence the order of fund selection when charging.
| Field Name | Type | Description |
|---|---|---|
| id | Long |
The unique fund identifier |
| allocated | BigDecimal |
Total Adjusted allocations. This value is affected positively by deposits, activations and destination transfers and affected negatively by withdrawals, deactivations and source transfers that have occurred since the last reset. |
| allocations | Set<Allocation> |
The allocations associated with this fund. |
| amount | BigDecimal |
The sum of active allocation amounts within this fund. It does not take into fund current liens. |
| creationTime | Date |
Date this fund was created |
| creditLimit | BigDecimal |
The sum of active credit limits within this fund |
| defaultDeposit | String |
The default deposit amount |
| deleted | Boolean |
A boolean indicating whether this fund is deleted or not |
| description | String |
The fund description |
| fundConstraints | Set<FundConstraint> |
Constraints on fund usage. |
| initialDeposit | BigDecimal |
The initial deposit amount |
| modificationTime | Date |
The date this fund was last modified |
| name | String |
The name of this fund |
| priority | Integer |
The fund priority |
| requestId | Long |
The id of the last modifying request |
| transactionId | Long |
The id of the last modifying transaction |
An allocation is a time-bounded pool of resource or service credits associated with an fund. An fund may have multiple allocations, each for use during a different time period.
An allocation has a start time and an end time that defines the time period during which the allocation may be used. By default an allocation is created with an unbounded time period (-infinity to infinity). An active flag is automatically updated to true if the fund is within its valid timeframe or false if it is not. An allocation may also have a credit limit representing the amount by which it can go negative. Thus, by having a positive balance in the Amount field, the fund is like a debit fund, implementing a pay-first use-later model. By establishing a credit limit instead of depositing an initial balance, the fund will be like a credit fund, implementing a use-first pay-later model. These strategies can be combined by depositing some amount of funds coupled with a credit limit, implementing a form of overdraft protection where the funds will be used down to the negative of the credit limit.
Constraints designate which entities (such as Users, Accounts, Machines, Classes, Organizations, etc.) may access the encapsulated credits in a fund or for which aspects of usage the funds are intended (QualityOfService, GeographicalArea, etc.).
API version 2
A fund is a container for a time-bounded reference currency called credits for which the usage is restricted by constraints that define how the credits must be used. Much like with a bank, an fund is a repository for these resource or service credits which are added through deposits and debited through withdrawals and charges. Each fund has a set of constraints designating which entities (such as Users, Accounts, Machines, Classes, Organizations, etc.) may access the fund or for which aspects of usage the funds are intended (QualityOfService, GeographicalArea, Feature, etc.). Fund constraints may also be negated with an exclamation point leading the constraint value.
When credits are deposited into an fund, they are associated with a time period within which they are valid. These time-bounded pools of credits are known as allocations. (An allocation is a pool of billable units associated with an fund for use during a particular time period.) By using multiple allocations that expire in regular intervals it is possible to implement a use-it-or-lose-it policy and establish an allocation cycle.
Funds may be nested. Hierarchically nested funds may be useful for the delegation of management roles and responsibilities. Deposit shares may be established that assist to automate a trickle-down effect for funds deposited at higher level funds. Additionally, an optional overflow feature allows charges against lower level funds to trickle up the hierarchy.
Funds may have an arbitrary name which is not necessarily unique for the fund. Funds may also have a priority which will influence the order of fund selection when charging.
| Field Name | Type | Description |
|---|---|---|
| id | Long |
The unique fund identifier |
| allocated | BigDecimal |
Total Adjusted allocations. This value is affected positively by deposits, activations and destination transfers and affected negatively by withdrawals, deactivations and source transfers that have occurred since the last reset. |
| allocations | Set<Allocation> |
The allocations associated with this fund. |
| amount | BigDecimal |
The sum of active allocation amounts within this fund. It does not take into fund current liens. |
| creationTime | Date |
Date this fund was created |
| creditLimit | BigDecimal |
The sum of active credit limits within this fund |
| defaultDeposit | String |
The default deposit amount |
| deleted | Boolean |
A boolean indicating whether this fund is deleted or not |
| description | String |
The fund description |
| fundConstraints | Set<FundConstraint> |
Constraints on fund usage. |
| initialDeposit | BigDecimal |
The initial deposit amount |
| modificationTime | Date |
The date this fund was last modified |
| name | String |
The name of this fund |
| priority | Integer |
The fund priority |
| requestId | Long |
The id of the last modifying request |
| transactionId | Long |
The id of the last modifying transaction |
An allocation is a time-bounded pool of resource or service credits associated with an fund. An fund may have multiple allocations, each for use during a different time period.
An allocation has a start time and an end time that defines the time period during which the allocation may be used. By default an allocation is created with an unbounded time period (-infinity to infinity). An active flag is automatically updated to true if the fund is within its valid timeframe or false if it is not. An allocation may also have a credit limit representing the amount by which it can go negative. Thus, by having a positive balance in the Amount field, the fund is like a debit fund, implementing a pay-first use-later model. By establishing a credit limit instead of depositing an initial balance, the fund will be like a credit fund, implementing a use-first pay-later model. These strategies can be combined by depositing some amount of funds coupled with a credit limit, implementing a form of overdraft protection where the funds will be used down to the negative of the credit limit.
Constraints designate which entities (such as Users, Accounts, Machines, Classes, Organizations, etc.) may access the encapsulated credits in a fund or for which aspects of usage the funds are intended (QualityOfService, GeographicalArea, etc.).
API version 1
A fund is a container for a time-bounded reference currency called credits for which the usage is restricted by constraints that define how the credits must be used. Much like with a bank, an fund is a repository for these resource or service credits which are added through deposits and debited through withdrawals and charges. Each fund has a set of constraints designating which entities (such as Users, Accounts, Machines, Classes, Organizations, etc.) may access the fund or for which aspects of usage the funds are intended (QualityOfService, GeographicalArea, Feature, etc.). Fund constraints may also be negated with an exclamation point leading the constraint value.
When credits are deposited into an fund, they are associated with a time period within which they are valid. These time-bounded pools of credits are known as allocations. (An allocation is a pool of billable units associated with an fund for use during a particular time period.) By using multiple allocations that expire in regular intervals it is possible to implement a use-it-or-lose-it policy and establish an allocation cycle.
Funds may be nested. Hierarchically nested funds may be useful for the delegation of management roles and responsibilities. Deposit shares may be established that assist to automate a trickle-down effect for funds deposited at higher level funds. Additionally, an optional overflow feature allows charges against lower level funds to trickle up the hierarchy.
Funds may have an arbitrary name which is not necessarily unique for the fund. Funds may also have a priority which will influence the order of fund selection when charging.
| Field Name | Type | Description |
|---|---|---|
| id | Long |
The unique fund identifier |
| allocated | BigDecimal |
Total Adjusted allocations. This value is affected positively by deposits, activations and destination transfers and affected negatively by withdrawals, deactivations and source transfers that have occurred since the last reset. |
| allocations | Set<Allocation> |
The allocations associated with this fund. |
| amount | BigDecimal |
The sum of active allocation amounts within this fund. It does not take into fund current liens. |
| creationTime | Date |
Date this fund was created |
| creditLimit | BigDecimal |
The sum of active credit limits within this fund |
| defaultDeposit | String |
The default deposit amount |
| deleted | Boolean |
A boolean indicating whether this fund is deleted or not |
| description | String |
The fund description |
| fundConstraints | Set<FundConstraint> |
Constraints on fund usage. |
| initialDeposit | BigDecimal |
The initial deposit amount |
| modificationTime | Date |
The date this fund was last modified |
| name | String |
The name of this fund |
| priority | Integer |
The fund priority |
| requestId | Long |
The id of the last modifying request |
| transactionId | Long |
The id of the last modifying transaction |
An allocation is a time-bounded pool of resource or service credits associated with an fund. An fund may have multiple allocations, each for use during a different time period.
An allocation has a start time and an end time that defines the time period during which the allocation may be used. By default an allocation is created with an unbounded time period (-infinity to infinity). An active flag is automatically updated to true if the fund is within its valid timeframe or false if it is not. An allocation may also have a credit limit representing the amount by which it can go negative. Thus, by having a positive balance in the Amount field, the fund is like a debit fund, implementing a pay-first use-later model. By establishing a credit limit instead of depositing an initial balance, the fund will be like a credit fund, implementing a use-first pay-later model. These strategies can be combined by depositing some amount of funds coupled with a credit limit, implementing a form of overdraft protection where the funds will be used down to the negative of the credit limit.
Constraints designate which entities (such as Users, Accounts, Machines, Classes, Organizations, etc.) may access the encapsulated credits in a fund or for which aspects of usage the funds are intended (QualityOfService, GeographicalArea, etc.).
Related topics