High- Level Specification

Functional Overview

Syniti which is the source of Currency Conversion Master Data will be integrated with Icertis to create currency exchange masterdata records in Icertis custom Currency Exchange masterdata table using Icertis Business API.

This Exchange rate will be used to convert the local Value into Euros to identify the DOA approvers in agreement.

In Icertis, records will be created/updated in bulk once in a month preferably 1st of every month and it will take the rate of last date of the previous month.

Scope and Objectives

Functional Scope:

This interface facilitates the monthly integration of currency exchange rates from Syniti into Icertis Contract Intelligence (ICI) to support accurate financial calculations and DOA (Delegation of Authority) logic in contracts.

Scope Includes:

1. Source System:

   • Syniti as the master source for currency exchange rates.

2. Target System:

   • Icertis, with a custom Currency Exchange Master Data table.

3. Integration Mechanism:

   • Syniti will call Icertis Business API used for bulk creation and update of masterdata records.

4. Data Elements Transferred:

   • Source Currency
   • Target Currency (EUR)
   • Exchange Rate
   • Effective Date (last day of previous month)
   • Rate Source (Syniti)
   • Timestamp of update

5. Frequency:

   • Monthly, preferably on the 1st of each month.

6. Operation Type:

   • Bulk Upsert (create new or update existing records).

7. Usage in Icertis:

   • Used to convert local currency values to Euros.
   • Enables correct DOA approver identification based on Euro thresholds.

Functional Objectives:

1. Ensure Accurate Currency Conversion

   • Maintain up-to-date exchange rates for converting local values to Euros in contracts.

2. Support DOA Logic in Agreements

   • Enable automated identification of approvers based on Euro-converted contract values.

3. Maintain Data Integrity

   • Prevent outdated or duplicate exchange rate records.
   • Ensure historical accuracy by using the rate from the last day of the previous month.

4. Enable Auditability and Traceability

   • Ensure all exchange rate records are timestamped and sourced for compliance and audit purposes.

5. Minimize Manual Intervention

   • Automate the monthly update process to reduce errors and improve efficiency.

Out of Scope:

1. Deletion of any existing currency exchange masterdata record
2. De-activating any existing currency exchange masterdata record

API Information

Get bulk api prepare for masterdata

POST/v{version}/bulk/masterdata/prepare

Sample Request

POST/{{baseUrl}}/{{version}}/bulk/masterdata/prepare

{

"Data": {

"ContractTypeName": "ICMOtherPartyMaster",

"SelectedAttributes": []

}

}

Create or update masterdata records in Bulk

POST/v{version}/bulk/masterdata

Process Flow Diagram

Assumptions

• Syniti will provide validated and complete exchange rate data for all required currency pairs.
• The exchange rate for the last day of the previous month will be available in Syniti by the 1st of the current month.
• Icertis Business API will support bulk upsert operations without performance degradation.
• The Icertis custom Currency Exchange master table is already configured and accessible via API.
• Exchange rates will be used only for DOA logic and not for financial reporting or invoicing.
• No real-time updates are required; monthly sync is sufficient.
• Error handling and logging will be managed by the middleware or integration layer.
• The integration will be triggered by a scheduled job or batch process on the 1st of each month.

Dependencies

• Syniti Data Availability: Exchange rate data must be finalized and accessible by the 1st of each month.
• Icertis API Availability: Business API must be operational and accessible during the integration window.
• Middleware/ETL Tool: A tool or service must be in place to extract data from Syniti and push it to Icertis.
• Authentication Setup: Secure tokens or credentials must be configured for API access.
• Schedule Dependency: This interface must run after Syniti’s daily currency update job completes.
• Team Coordination: Dependencies on Syniti data team and Icertis integration team for support and monitoring.

Security, Integrity and Controls

• Authentication: API access to Icertis must use secure OAuth tokens or API keys.
• Authorization: Only designated integration service accounts should have write access to the Currency Exchange master table.
• Encryption: Data in transit must be encrypted using HTTPS/TLS.
• Audit Logging: All API calls and data changes must be logged for audit purposes.
• Data Validation: Exchange rates must be validated for completeness and correctness before pushing to Icertis.

Configuration Requirements

• Icertis Custom Table: Must include fields for Source Currency, Target Currency, Exchange Rate, Effective Date, Source System, and Timestamp.
• API Endpoint Configuration: Business API endpoints must be configured to accept bulk upsert payloads.
• Job Scheduler: A scheduler (e.g., Control-M, SAP PO, or custom script) must be configured to run the job monthly.
• Error Handling Rules: Define retry logic, failure notifications, and fallback mechanisms.

Special Requirements

• Localization: Ensure currency formats comply with regional standards (e.g., decimal separators).

Design Rationale

This interface is designed as an API consumer. Icertis will consume data from Syniti via a scheduled integration that uses the Icertis Business API to create or update currency exchange master data records.

The API will be used to:

• Push monthly exchange rates from Syniti to Icertis.
• Ensure that the latest rates are available for contract value conversion and DOA logic.

API Use

• Type: API Consumer
• System Consuming API: Icertis
• System Providing API: Syniti (or middleware extracting from Syniti)

Data Structure

The following fields will be used to provide the required data structure of the interface:

Calculation and Validation

Populate the table below to list the calculation and validation rules per field

Processing Logic

• The integration job runs on the 1st of each month.
• It fetches exchange rates from Syniti for the last day of the previous month.
• The data is transformed into the required format and pushed to Icertis via the Business API.
• The API performs bulk upsert: updates existing records or creates new ones.
• Errors are logged and flagged for manual review.

Delta or Full Load Requirements

• Full Load:
  • The interface always pushes the complete set of exchange rates for all supported currencies.
  • No delta tracking is required since the data is refreshed monthly.

Interface Alert & Monitoring

• Alerts should be configured for:
  • API failures
  • Missing or incomplete data
  • Validation errors
• Monitoring tools (middleware logs) should notify:
  • Integration support team
  • Business users (email)
• Retry logic should be in place for transient failures.

Language Requirements

• No multilingual support required for exchange rate data.
• All fields are numeric or standard ISO codes.

User Interface Requirements

Not Applicable

Volumetrics

Provide volumetrics details: Initial load volumes, Number of Records, Expected Frequency, Expected Long term Growth)

Performance Consideration

Scheduling and Execution Window

• The integration job should be scheduled during off-peak hours (e.g., early morning on the 1st of each month) to avoid contention with other system processes.

Error Handling

Validation Errors

• Cause: Missing mandatory fields, invalid currency codes, negative exchange rates.
• Handling:
  • Reject the record.
  • Log the error with detailed message.
  • Notify integration support team via email or dashboard.
  • Continue processing remaining records.

2. API Failures

• Cause: Icertis Business API is unavailable, authentication failure, timeout.
• Handling:
  • Retry up to 3 times with exponential backoff.
  • If retries fail, log the failure and raise an alert.
  • Notify support team with error code and timestamp.

3. Data Load Failures

• Cause: Payload formatting issues, bulk upsert failure.
• Handling:
  • Validate payload structure before submission.
  • Use staging logs to identify failed records.
  • Allow manual reprocessing of failed records.

4. Partial Success

• Cause: Some records succeed, others fail due to validation or API issues.
• Handling:
  • Log both successful and failed records.
  • Generate a summary report for review.
  • Provide reprocessing option for failed records.

5. Missing Data from Syniti

• Cause: Exchange rate data not available on schedule.
• Handling:
  • Alert business users and integration team.
  • Optionally use previous month’s rates (if approved by business).
  • Flag contracts that rely on missing data for manual review.

6. Monitoring and Alerts

• Tools: Integration monitoring dashboard, email notifications, log files.
• Recipients: Integration support team, business operations team.
• Alert Types:
  • Job success/failure
  • Record-level validation errors
  • API connectivity issues
  • Missing or delayed data

Testing

How to Test

Please provide some guidance and/or test data to help the developer unit test the interface. Please include both positive and negative testing (to validate error situations handling)

The developer will need to test repeatedly, so where appropriate provide instructions to reverse the actions performed so the test may be run again, or explain how to create new input data to the test. In particular, the developer will need logons for test users representing the various roles within the approval process.

Test Conditions and Expected Results

Test Considerations/Dependencies

List any considerations essential for application test planning (e.g., test this before ABC along with DEF separate from GHI). If the development encompasses a user interface, explain how to test it. List any insights as to how this component could be tested the most efficiently.

Other Information

Development Details

Package

Other Development Objects

Appendix

See also

Insert links and references to other documents which are relevant when trying to understand this decision and its implications. Other decisions are often impacted, so it's good to list them here with links. Attachments are also possible but dangerous as they are static documents and not updated by their authors.

Change log