This topic includes additional information about creating BP records.
BP XML Structure
To get the BP XML structure, first send a message to get BP record. Refer to the Web Service getBPRecord for more information.
Interface
This interface can be extended with additional data elements. In order for Unifier to recognize those elements, the data element name must match those created in uDesigner for this business process.
YTB/AFC
If the tags YTB or AFC are present in the line items, Unifier processes these tags. If they are not present, Unifier will check the uDesigner BP setup configuration for Cost Adjustment. If this field has been set, the line item amount is treated as YTB/AFC and processed.
Single Record BP
Record Exists
If you send a message for single record BP and a record already exists then Unifier will not send back and error but if you send an invalid record number then Unifier will send back an error.
Record does not exist
If you send a message for single record BP and a record does not exist then Primavera Unifier will create a record for you. If the BP type is of Line item then any line items included in the message will be added to the BP record. If the BP type is of Simple then any line items added as part of message will be ignored.
If your BP has uuu_creation_date then it will be populated when you send a message
If your Cost BP has fund related information then you have to send Fund code details. If you are using multi segment fund code then send the code segments with delimiters.
Example:
Fundseg1-Fundseg2-Fundseg3.
The fund information send as part of Cost BP will be rolled up to Funding Sheet or Cost Sheet.
You cannot send fund related information for Cost Type BPs such as General Spends and Payment Applications.
All data element values provided as part of integration message will be validated against the action form selected as part of design in uDesigner. Validation includes required field, form validation etc..,
The following XML tag <_refnum> </refnum> should be added under BP line item tag <_bp_lineitem> </bp_lineitem> to support the ability to import the line items for General Spends and Payment Applications if SOV is individual line items. For Group by commit codes lines are identified by CBS Code.
If the action form used for validation is auto-populating values from a Business Process picker then system will auto-populate these values if a valid value is provided for that Business Process Picker.
This service can be used for both Project (Standard) and Shells of cost code type CBS and Generic.
Additional element and sub elements (XML tags) within the line items (_bp_lineitems) of Summary Payment Application SOV Type
To perform Cost allocation to line items, use the following information:
Note: For additional details, refer to the Unifier Reference Guide.
Tag Name | BP Type | Description |
|---|---|---|
<_cost_allocation> | Cost (Base Commit and Change Commit of Summary Payment Application SOV type) | Cost allocation for the summary line item will be done using _cost_allocation. |
<bItemID> | Cost (Base Commit and Change Commit of Summary Payment Application SOV type) | bItemID, which is CBS Code, is a required field if you are sending costed line item information under _cost_allocation. |
<short_desc> | Cost (Base Commit and Change Commit of Summary Payment Application SOV type) | Required field. |
<uuu_quantity> | Cost (Base Commit and Change Commit of Summary Payment Application SOV type) | Required field if cost line item type specified in _bp_lineitems has been set as Unit Cost. The Unit Cost information is specified in _bp_lineitems. |
<amount> | Cost (Base Commit and Change Commit of Summary Payment Application SOV type) | Required field if cost line item type specified in _bp_lineitems has been set as Lump Sum. |
<_bp_lineitems> | Cost (Base Commit and Change Commit of Summary Payment Application SOV type) | Optional field. Use when modifications are needed for line items that have already been committed in an SOV. |
The Payment Application detail form is a customized form that is designed in uDesigner. This form will have a set of fixed and user-defined fields. The Input XML for Payment Application will include the following:
- All existing XML tags that are currently applicable for the classic Payment Application Business Process.
- The tags listed in the following table:
Note: The table only lists out the system defined Data Element behavior specific to Payment Applications of SPA SOV type
Available for data input in Elements | Tags / Data elements specific to Payment Application | Additional comments |
|---|---|---|
_bp_lineitems and _cost_allocation | Reference (_refnum) | This will be the identifier for the line item that needs to be paid. This field cannot be empty when the _bp_lineitems block has values in other fields. This will be the identifier for the costed line item as well. |
_cost_allocation | bItemID (Cost Code) | This field cannot be empty when the _cost_allocation block has values in the other fields. Combination of _refnum and bItemID will be used to identify the costed line against which the payment has to be made. If there are duplicate _refnum and CBS codes in multiple cost allocation blocks then the creation/update will fail. |
_bp_lineitems and _cost_allocation | short_desc (Description) | Both at summary and costed line levels. |
_bp_lineitems and _cost_allocation | uuu_spa_qty_tp (Quantity this Period) | Since the Input XML will be common for both Lump Sum and Unit cost the tags will always be available. Any value entered in this field when cost type is Lump Sum, will be ignored. |
_bp_lineitems and _cost_allocation | uuu_spa_amt_tp (Amount this Period) | Since the Input XML will be common for both Lump Sum and Unit cost the tags will always be available. Any value entered in this field when cost type is Unit Cost, will be ignored. |
_bp_lineitems and _cost_allocation | uuu_spa_other_tp (Other Amount this Period | Both summary line items and costed lines can have this field value. |
_bp_lineitems and _cost_allocation | uuu_spa_mat_stored (Material Stored) | Both summary line items and costed lines can have this field value. |
_bp_lineitems | uuu_spa_per_comp (Percentage Complete To Date) | Only summary line items can have this field value. |
Notes:
- The “_bp_lineitems” elements will be as per the detailed integration interface design.
- The “_cost_allocation” elements will mostly be the same as “_bp_lineitems” elements, but the editability of the fields is governed by the logic currently existing in the system.
- The Payment Application has certain restrictions regarding fields that can be edited at the Summary or Allocation levels:
- If the XML template has values in the “_bp_lineitems” elements that are not allowed, for example, CBS codes, then such values are ignored.
- There are certain fields such as “uuu_cost_li_type” which should be entered only at the Summary level.
- If the XML has the value in the “_cost_allocation”, then such values are ignored.
Behavior Specific to Summary Payment Application SOV type BPs
Note: The following information is applicable to Base Commit, Change Commit, and Payment Application Business Processes of Summary Payment Application SOV type.
- Business Process records can be created both with and without line items, by using various Create methods.
- Standalone Create methods also exist by using a line items that can be added to an existing Business Process record, for example, Add BP Line Item.
In both cases mentioned above, you can add the summary line items along with the cost allocation.
For adding line items to the Change Commit BP records from SOVs (modifying committed line items) using Input XMLs use the following:
- The reference tag uuu_sovlinum in the _bp_lineitems element determines the SOV line that will be modified. The costed lines that need to be updated will be identified by the uuu_sovlinum and Cost Code/ bItemId. The combination of uuu_sovlinum and Cost Code/ bItemId must be unique. Post record creation of all costed lines belonging to the summary line item will be added.
- If the input XML has the cost line item type field, then the system checks to ensure that the uuu_sovlinum and uuu_cost_li_type are as per SOV line. If there is a mismatch, the system generates an integration error.
- If the input XML has both uuu_sovlinum and uuu_cost_li_type fields, but the uuu_cost_li_type field has an invalid value, then the system generates an integration error.
- If the input XML has just the uuu_sovlinum and the uuu_cost_li_type field is blank, then no check will be performed for cost line item type validation.
- The Short description from a committed line comes from the SOV. When a line item has the uuu_sovlinum value, the short description field can empty. At runtime the value comes from SOV; however, if the short description value is included in the XML, then the existing value replaces the one coming from SOV.
Payment Application
The following information is specific to Payment Application.
At the time of creating a Payment Application record, details of the line items that are getting paid will be entered in the Input XML. Post creation of the record, all the line items existing for the Commit record will be seen in the in the record.
Example
Payment is made against Contract CON-009 and this record has 5 line items which exist in the SOV, but the payment has to be made only for Line item 1. The input XML will have all the data for this line item. After a successful integration, PayApp-010 gets created. When you open this record, all the 5 line items will be seen in PayApp-010.
Validation
Since the system adds all the line items from the SOV, which do not exist in the Input XML, the system performs additional checks at the time of creating the record.
- All auto-population and default values set for String fields will be honored at the time of creating the records. If no auto-population and default values exist for these required string fields then, the creation of record through integration will fail.
- All auto-population and default values for Numeric fields will also be honored. If no values exist then the system will default these fields to 0.
- Errors messages will be pertaining to the required field check validations.