Guide: Enterprise Resource Planning: Difference between revisions
Created page with "The bwCloud-OS provides an RESTful API that allows our customers to overview and manage the accounting data and resources of their memebers. == Testing == {| class="mw-message-box mw-message-box-warning" | style="vertical-align:middle;" |'''⚠️ Please Note:''' This API-Service is in a late testing phase and will be available soon. |} == Entitlement == === Entitlement validation === This endpoint can be used for validating syntax and checking the interpretation of a..." |
No edit summary |
||
| (19 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
➡️ '''To the''' '''[[Guide: ERP-API|ERP-API]].''' | |||
The bwCloud-OS provides an [[Guide: ERP-API|ERP with a RESTful API]] for overview and management of the [[Guide: Entitlement & Eligibility|entitlements and eligibilities]]. Hence, for managing accounting data and resources of members. | |||
__TOC__ | |||
== | == Motivation == | ||
The bwCloud-OS [[Guide: Enterprise Resource Planning#Contract relationship bwCloud-OS|negotiated only contracts with institutions (customers)]] but not with individual members (users). This is a crucial [[Guide: Enterprise Resource Planning#Contract relationship bwCloud-OS|difference compared to other known cloud providers]]. | |||
=== Automated resource provisioning === | |||
[[Registration]] is streamlined through entitlements: | |||
* Entitlements are automatically evaluated during registration. | |||
* Users receive immediate access and resources ([[Projects and Quota|project quota]]) once their entitlement is confirmed. No manual activation is required. | |||
=== Shared resources === | |||
All resources in the bwCloud-OS are shared between all users. Since everyone should be able to access them, project quota limits are set. However, not every user group (e.g., teacher and student) requires the same [[Guide: Project and Quota#List of quota flavors|quota flavor]]. | |||
=== Charging === | |||
All consumption within the bwCloud-OS, within projects, are [[Guide: Charging|charged]]. Charging will be based on the projects [[Booking Units|booking units]] (BEH) and will be addressed to the [[Projects and Quota|project owner]]'s home organization. | |||
=== Delegating resposibility === | |||
The institutes can define an internal process so their members can set entitlements in the home IdP. There are several different types of sponsors (e.g., faculties, research projects) located at the institutes that should be enhanced to manage the resources of sub-groups of their members (e.g., students of a faculty). With access to their internal data (e.g., from the local IdP), different eligibilities can be assigned. | |||
=== Reimbursement === | |||
Entitlements also help define who is financially responsible for producing BEH. | |||
* Defining [[Guide: Entitlement & Eligibility#Cost centers|cost centers]] to separate costs into [[Guide: Entitlement & Eligibility#Example eligibility 1|different cost positions]], allowing institutions to reimburse the costs internally. With access to their internal data (e.g., from the local IdP), different eligibilities (e.g., with different cost centers) can be assigned. | |||
* bwCloud-OS will generate aggregated usage reports and invoices per institution—no individual billing. | |||
=== Budget (Not supported yet) === | |||
Sometimes resources should only be consumed up to a certain level or amount of time. | |||
* [[Guide: Entitlement & Eligibility#Constraints|Constraints]] can be used to manage the valid period for the eligibility. | |||
* After reaching an eligibility constraint, no more costs can be produced within the associated project. | |||
=== | ==== Paidafter ==== | ||
This | This may be seen as a 'paidafter' credit (analog to 'prepaid'). Institutes grant their members an amount of BEH to consume. Members can freely choose how to consume those, but not more. After the [[Guide: Charging|payment period]], the institute will only be charged for the consumed BEH. | ||
=== Central eligibility platform === | |||
The gimmic with the eligibility enhances (later) the bwCloud-OS local support to manage quota privileges within the bwCloud-OS environment. Such a [[Guide: REST-API for accounting and resource management#Eligibility rules|central service]] could simplify local processes within the customers. | |||
== Contract relationship bwCloud-OS == | |||
The contract is closed between the bwCloud-OS and the institutes (customers), as illustrated in the picture. Due to this, one bill will be sent to the customer, including all generated costs from members/ projects related to this institute. Therefore, it is possible that an additional organizational or technical process within each institution may be necessary to manage the accounting relationship between the institution and its members.[[File:Compare cloud provider contracts v3.drawio.png|thumb|Contract relationship compared between bwCloud-OS and other IaaS providers|center]] | |||
Latest revision as of 15:02, 3 March 2026
➡️ To the ERP-API.
The bwCloud-OS provides an ERP with a RESTful API for overview and management of the entitlements and eligibilities. Hence, for managing accounting data and resources of members.
Motivation
The bwCloud-OS negotiated only contracts with institutions (customers) but not with individual members (users). This is a crucial difference compared to other known cloud providers.
Automated resource provisioning
Registration is streamlined through entitlements:
- Entitlements are automatically evaluated during registration.
- Users receive immediate access and resources (project quota) once their entitlement is confirmed. No manual activation is required.
Shared resources
All resources in the bwCloud-OS are shared between all users. Since everyone should be able to access them, project quota limits are set. However, not every user group (e.g., teacher and student) requires the same quota flavor.
Charging
All consumption within the bwCloud-OS, within projects, are charged. Charging will be based on the projects booking units (BEH) and will be addressed to the project owner's home organization.
Delegating resposibility
The institutes can define an internal process so their members can set entitlements in the home IdP. There are several different types of sponsors (e.g., faculties, research projects) located at the institutes that should be enhanced to manage the resources of sub-groups of their members (e.g., students of a faculty). With access to their internal data (e.g., from the local IdP), different eligibilities can be assigned.
Reimbursement
Entitlements also help define who is financially responsible for producing BEH.
- Defining cost centers to separate costs into different cost positions, allowing institutions to reimburse the costs internally. With access to their internal data (e.g., from the local IdP), different eligibilities (e.g., with different cost centers) can be assigned.
- bwCloud-OS will generate aggregated usage reports and invoices per institution—no individual billing.
Budget (Not supported yet)
Sometimes resources should only be consumed up to a certain level or amount of time.
- Constraints can be used to manage the valid period for the eligibility.
- After reaching an eligibility constraint, no more costs can be produced within the associated project.
Paidafter
This may be seen as a 'paidafter' credit (analog to 'prepaid'). Institutes grant their members an amount of BEH to consume. Members can freely choose how to consume those, but not more. After the payment period, the institute will only be charged for the consumed BEH.
Central eligibility platform
The gimmic with the eligibility enhances (later) the bwCloud-OS local support to manage quota privileges within the bwCloud-OS environment. Such a central service could simplify local processes within the customers.
Contract relationship bwCloud-OS
The contract is closed between the bwCloud-OS and the institutes (customers), as illustrated in the picture. Due to this, one bill will be sent to the customer, including all generated costs from members/ projects related to this institute. Therefore, it is possible that an additional organizational or technical process within each institution may be necessary to manage the accounting relationship between the institution and its members.
