Following interfaces are available to work with cost allocation definitions and hierarchy between cost allocation definitions.
All CA related interfaces can work with single Cost allocation set only per call. If there is more than one
Cost allocation set available, set ID needs to be specified in URL of an interface, otherwise request cannot be processed.
If there is only single set available, it is not needed to specify set ID as this set will be selected automatically.
CostAllocation/Create
URL
{url}/ERP/CostAllocation/<set ID>/Create {url}/ERP/CostAllocation/Create
Type POST
Description Method is used to create new cost allocation definitions for cost allocation step with specific type. Type is referenced by name (f.e. ‘Machine’) and step with this type must exist in the system. Value type of the step must be Hierarchy or List. Set ID needs to be specified in URL when there is more than single Cost allocation set available.
Schema Schema illustrates maximum allowed length for string types, which is supported to import by the system. Type information are marked orange in the schema.
{ "CostAllocationValues": [ { "Type": "string", 100 "Value": "string", 100 "IsActive": true, "CostCarrier": "string" 4000 } ] }
CostAllocation/UpdateHierarchy
URL
{url}/ERP/CostAllocation/<set ID>/UpdateHierarchy {url}/ERP/CostAllocation/UpdateHierarchy
Type POST
Description
Method is used to create new relations between cost allocation definitions.
Definition is identified by its value and name of step for which it is defined.
Definition must exist and cannot be created by this interface. Only definitions defined for steps of type Hierarchy can be added to relations. Hierarchy must be always defined from root (first step of type Hierarchy) and order of steps must be maintained.
When definition is already in specific place in hierarchy, existing instance of definition in this place is reused. List of restrictions by items, users and user groups are ignored when sent (restrictions cannot be updated by this interface).
Lists are accepted only to support compatibility with data provided by CostAllocation/GetHierarchy interface. Only part of hierarchy to create can be sent (it is not necessary to send complete hierarchy).
Set ID needs to be specified in URL when there is more than single Cost allocation set available.
Schema
Schema illustrates maximum allowed length for string types, which is supported to import by the system. Type information are marked orange in the schema. References to existing entities are marked bold.
[ { "Value": "string", 100 "StepType": "string", 100 "Items": [ ignored, optional "string" 50 ], "Users": [ ignored, optional "string" 100 ], "UserGroups": [ ignored, optional "string" 100 ], "Instances": [ { child definitions defined recursively } ] } ]
CostAllocation/DeleteHierarchy
URL
{url}/ERP/CostAllocation/<set ID>/DeleteHierarchy {url}/ERP/CostAllocation/DeleteHierarchy
Type
POST
Description
Method is used to remove specific relations between cost allocation hierarchy definitions. Definitions are identified by their value and name of step for which it is defined. Hierarchy must be always defined from root (first step of type Hierarchy) and order of steps must be maintained. Only specific relations can be sent to be deleted, with following rules:
- If definition has other relations not mentioned to be deleted, this definition is not deleted
- All children of last step sent are deleted
Examples
| Original hierarchy | To delete | Result | ||||||
| A1 | A1 | A1 | ||||||
| B1 | B2 | B1 | ||||||
| C1 | C1 | |||||||
| B2 | ||||||||
| C1 | ||||||||
| C2 | ||||||||
| A1 | A1 | A1 | ||||||
| B1 | B2 | B1 | ||||||
| C1 | C1 | C1 | ||||||
| B2 | B2 | |||||||
| C1 | C1 | |||||||
| C2 | ||||||||
List of restrictions by items, users and user groups are ignored when sent (restrictions cannot be deleted by this interface). Lists are accepted only to support compatibility with data provided by CostAllocation/GetHierarchy interface. Set ID needs to be specified in URL when there is more than single Cost allocation set available.
Schema
Schema illustrates maximum allowed length for string types, which is supported to import by the system. Type information are marked orange in the schema. References to existing entities are marked bold.
[ { "Value": "string", 100 "StepType": "string", 100 "Items": [ ignored, optional "string" 50 ], "Users": [ ignored, optional "string" 100 ], "UserGroups": [ ignored, optional "string" 100 ], "Instances": [ { child definitions defined recursively } ] } ]
CostAllocation/UpdateItemRestrictions
URL
{url}/ERP/CostAllocation/<set ID>/UpdateItemRestrictions {url}/ERP/CostAllocation/UpdateItemRestrictions
Type
POST
Description
Method is used to update restrictions for items in specific place in hierarchy. Definition is identified by its value and name of step for which it is defined. Hierarchy must be always defined from root (first step of type Hierarchy) and order of steps must be maintained. Item restrictions can be updated in following way:
- If Items list is sent containing item IDs, item restrictions are set according this list for this hierarchy instance
- If Items list is sent as empty array, all existing item restrictions are removed for this hierarchy instance
- If Items list is not sent, no change is made for item restrictions of this hierarchy instance
List of restrictions by users and user groups are ignored when sent (these restrictions cannot be updated by this interface). Lists are accepted only to support compatibility with data provided by CostAllocation/GetHierarchy interface. Only part of hierarchy can be sent (it is not necessary to sent complete hierarchy). Set ID needs to be specified in URL when there is more than single Cost allocation set available.
Schema
Schema illustrates maximum allowed length for string types, which is supported to import by the system. Type information are marked orange in the schema. References to existing entities are marked bold.
[ { "Value": "string", 100 "StepType": "string", 100 "Items": [ optional, item IDs from item detail "string" 50 ], "Users": [ ignored, optional "string" 100 ], "UserGroups": [ ignored, optional "string" 100 ], "Instances": [ { child definitions defined recursively } ] } ]
CostAllocation/GetHierarchy
URL
{url}/ERP/CostAllocation/<set ID>/GetHierarchy {url}/ERP/CostAllocation/GetHierarchy
Type
GET
Description
Method returns complete hierarchy of relations between cost allocation definitions. Hierarchy contains restrictions to items (referred by item ID), users (referred by username) and user groups (referred by user group name) in specific place in hierarchy. Hierarchy is returned in response instead of request ID. Set ID needs to be specified in URL when there is more than single Cost allocation set available.
Response example
[ { "Value": "string", 100 "StepType": "string", 100 "Items": [ "string" 50 ], "Users": [ "string" 100 ], "UserGroups": [ "string" 100 ], "Instances": [ { child definitions defined recursively } ] } ]
CostAllocation/GetRequestResult
After API method is successfully called (response code 200), GUID of the request is returned in response. This GUID can be used to check status of the request.
URL
{url}/ERP/CostAllocation/GetRequestResult
Type
GET
Parameters
| Key | Value |
requestGuid
|
GUID returned by calling POST method |
Description
Method returns result of create/update method based on GUID of previous calling. For the request, following statuses can be shown:
- ‘Created’ – Request has been received but it has not been added to task queue yet
- ‘Ready’ – Request has been added to task queue and is currently waiting to be executed
- ‘Running’ – Changes are currently in progress according the request
- ‘Completed’ – All changes required by the request has been finished
- ‘Failed’ – Request has failed to be performed
For each new object created/updated, information is shown if create/update process was successful. Ids of all cost allocation values created are shown with ID of related step. Each object can have one of following statuses in request result:
- ‘None’ – Object has not been created/updated/deleted due do validation error
- ‘Created’ – Object has been successfully created
- ‘Updated’ – Object has been successfully updated
- ‘Deleted’ – Object has successfully been deleted
If any validation errors are found, these errors are listed separately for each object referring to invalid parameter.
Schema
{ "Message": "string", "Status": "Created", "Result": { "Status": "None", "Errors": [ "string" ], "CreatedItems": [ "string" ] } }