Proposal For NetSuite & HROPAL Integration

Proposal Summary 

 

This proposal covers the development and implementation scope of the NetSuite and HROPAL integration for employees, timesheets, projects, and journals. It also outlines the integration modules and fields that need to be updated in both systems. The integration will be carried out using HROPAL APIs and NetSuite Restlets. 

This proposal is based on our discussions, expectations, and understanding from meetings and other communications. Any new requirements or updates during development will be treated as change requests. 

 

Requirement 

 

The client has requested the integration of NetSuite and HROPAL to streamline data exchange between the two systems, focusing on key areas such as Employee Master, Timesheet Entry, Project List, and Monthly Journals. This integration will ensure that employee records are created and updated in NetSuite once confirmed in HROPAL, with automatic synchronization for any subsequent updates. Timesheet data will be transmitted at scheduled intervals to efficiently manage large volumes, while project lists and monthly journals will be updated regularly to maintain consistency across both platforms. The integration will be executed using HROPAL APIs and NetSuite Restlets, with detailed field mappings and functionalities to ensure seamless data flow. These customizations are essential for automating business processes and streamlining operations. 

 

Prerequisites 

 

1. NetSuite Sandbox or Production Access: Access to NetSuite Sandbox and Production environment is required to facilitate the integration testing and deployment process. Additionally, the NetSuite account must have the “Token-based Authentication” feature enabled, along with other necessary settings for Restlet integration. 
2. API Documentation for HROPAL: Comprehensive API documentation for the HROPAL system is necessary to understand the available endpoints, data structures, and integration methods. 
3. Authorization Tokens/Client ID for HROPAL: Access to valid authorization tokens or the Client ID for the HROPAL system is essential to authenticate and establish secure communication between the two platforms. 
4. HROPAL System Access: Access to the HROPAL system will aid in better understanding the existing configurations and facilitate smoother integration efforts. 

 

Deliverables 

 

The implementer has reviewed the requirement thoroughly and proposes the following deliverables:  

Integration Setup for NetSuite Rest API: 

The implementer will configure the necessary integration setup for the Restlet integration in NetSuite, which includes the following steps: 

• Integration Record Creation: An integration record will be created in NetSuite to enable token-based authentication for the Restlet integration. This will ensure secure communication between NetSuite and HROPAL. 
• Custom Integration Role Creation: A custom integration role with limited permissions will be created in the NetSuite account. This role will be assigned to users who will interact with the RESTlet API, ensuring that only the necessary actions can be performed. 
• Access Token Creation: The implementer will generate an access token for the newly created custom role. This token will be used to authenticate API requests made to the Restlet. 
• Authorization Credentials: The implementer will share the necessary authorization credentials, including the access token, with the client, enabling them to make requests to the Restlet API. 

Employee Master Integration (Create & Update): 

The employee synchronization will occur from HROPAL to NetSuite, focusing solely on creating and updating employee records in NetSuite. Deletion of employee records is not part of the scope. As part of this integration, the implementer will create a Restlet endpoint that will handle both the creation and update of employee records. The HROPAL system will trigger this Restlet endpoint by sending employee details in the request body. 

The request body must include all employee details as per the predefined field mappings, including values for mandatory fields in the employee form. It will also contain an attribute for the NetSuite employee internal ID. If the internal ID is null or empty, the Restlet endpoint will create a new employee record in NetSuite using the details provided in the request body. After the record is created, the employee’s NetSuite internal ID will be returned in the response. If the internal ID is present, the Restlet will update the corresponding existing employee record in NetSuite. 

The new employee records will always be created using a custom employee form, which will be provided by the client before the development phase begins. The client will also disable existing scripts and workflows for the new employee form. Therefore, the implementer assumes that existing customizations will not interfere with the integration process, and these customizations will not apply to records created using the custom form. 

The Restlet will respond with either a success message or error details if any issues occur during the employee creation or update process. The client will handle triggering the Restlet from the HROPAL system, and the error handling will be managed within the HROPAL system. As per the current scope, the implementer will not store error/success history in NetSuite. 

 

Timesheet Entry (Create & Update): 

The time entry synchronization from HROPAL to NetSuite will focus on creating and updating time tracking records, excluding the deletion of records. This process will be scheduled within NetSuite as per the client’s preferences. The implementer will leverage HROPAL’s APIs to fetch the time entry details, specifically retrieving the recently created or updated entries from HROPAL, and subsequently creating or updating the corresponding records in NetSuite. 

Once a time tracking record is created in NetSuite, the NetSuite internal ID for the record will be sent back to HROPAL via the HROPAL API, where it will be stored. This enables future updates to the same record in NetSuite using the internal ID for seamless synchronization. 

As part of the integration, new time tracking records will be created using a custom form provided by the client. The client will disable any existing scripts or workflows associated with the new custom form to prevent interference with the integration process. The implementer assumes that these existing customizations will not affect records created via this custom form. 

This integration setup guarantees a smooth synchronization process by keeping track of internal IDs, enabling efficient handling of future updates to time entries from HROPAL to NetSuite. Additionally, the client will provide the HROPAL API to fetch bulk time entries in a single API call, as well as the API needed to update the internal ID back to HROPAL. 

 

Project (Data Retrieval): 

The project synchronization will occur from NetSuite to HROPAL, focusing on sending project data from NetSuite for creation and updating in the HROPAL system. Deletion of project records is not included in the scope. The implementer will configure the integration to use the HROPAL API, with separate endpoints for both project creation and updating. The synchronization process will also ensure that inactive project records in NetSuite are included in the data transfer to HROPAL. 

For this integration, two custom fields will be added to the project record in NetSuite: Latest Response and Latest Request. These fields will store the most recent API request and response information to track the integration status and ensure transparency in data flow between the systems. The HROPAL system’s response ID will also be stored on the corresponding project record in NetSuite for future reference and to maintain synchronization integrity. 

The project data retrieval will be handled in real-time while creating/saving Project record in NetSuite, and HROPAL’s API will be used to manage both the creation and update of project records in their system. 

Monthly Journals (Create): 

The synchronization of journal entries will occur from HROPAL to NetSuite, focusing exclusively on the creation of new journal records. Updates or deletions are not included in the current scope. If the client wishes to add journal updates in the future, this will be considered as new scope, and the solution can be only defined after the full analysis of the HROPAL system. For now, only the creation of journals will be considered. 

The journal synchronization process will be scheduled within NetSuite, with the timing based on the client’s preferences. The implementer will utilize the HROPAL API to fetch the most recently created journal details. If any journal contains more than 1,000 lines, the script will automatically split them into multiple journal entries. Additionally, the system will auto-balance journal amounts, ensuring the final amount is rounded off for accuracy. 

Once a journal is successfully created in NetSuite, its internal ID will be sent back to HROPAL through the HROPAL API. However, the implementer assumes that the journal data model in HROPAL will be similar to that of NetSuite. If the data model differs, it may affect the ability to send the internal ID back. Any discrepancies that arise will be analysed and addressed in future phases, potentially extending the scope to include journal updates. 

As part of the integration, journal records will be created using a custom form, which will be provided by the client. The client will also disable any existing scripts or workflows linked to the custom form to avoid interference with this integration. It is assumed that existing customizations will not impact the newly created records using this form. 

The client will provide the HROPAL API for fetching bulk journal entries in a single API call, as well as the API for updating the internal ID back to HROPAL. 

Error Handling: 

The integration process will include error handling for the scheduled processes. If any errors occur during the scheduled execution, the implementer will send a consolidated email to Admin, detailing the issues after each script run. 

For the employee synchronization REST API, the error details will not be stored within NetSuite. Instead, errors will be returned in real-time within the API response, ensuring immediate feedback for the HROPAL system. 

For the project synchronization, two custom fields will be added to track the latest request and response. These fields will store the integration status on the corresponding project record in NetSuite, allowing the client to monitor the synchronization history and troubleshoot any issues that arise. 

Assumptions 

 

• Since this proposal was prepared without access to the client’s NetSuite account, HROPAL system, or HROPAL API documentation, any such discrepancies may impact the development process. If any discrepancies or issues arising is observed during development, due to existing customizations, accounting setups, or configuration errors this can be only rectified by considering as a change request.
• The implementer assumes that the client will provide detailed API documentation for HROPAL prior to the development phase to ensure a smooth integration process. 
• It is assumed that the client will create custom forms for employee records, time entries, projects, and journal entries specifically for the HROPAL integration. Additionally, the client will ensure that existing workflows and scripts do not trigger for these newly created forms. The custom form setup and any related updates will be handled by the client, and the implementer will not be responsible for modifying the form layout or updating related scripts. 

Notes 

• All Restlet APIs developed by the implementer will use the POST method for this integration. 
• The implementer will not be responsible for any customizations within the HROPAL system itself. 

Risks 

• NetSuite does not support the PATCH request method. If any HROPAL API endpoint uses PATCH, the implementer will not be able to incorporate it into this integration. 
• Restlet Script Usage Limits: Each Restlet script in NetSuite has a limit of 5,000 usage units and a maximum execution time of 5 minutes per run. These constraints must be managed to avoid timeouts or usage issues. 
• Request/Response Size Limits: The size of the request body or response content for any REST API call should be less than 10MB. Larger content sizes may result in failed API calls. 
• Concurrency Limits: There is a minimal chance of encountering concurrency limit issues when calling NetSuite’s REST API, particularly if multiple integrations are triggered simultaneously. While this is unlikely in the current scenario, it could occur if multiple integrations (REST, SOAP, or others) are triggered in the client’s account at the same time. 
• Server downtime Risks: There is always a possibility of integration failures if either the NetSuite server or the HROPAL server experiences downtime.