The POC discussion focused on integrating the SAP system with the IT Asset Management system so that asset codes created in SAP can be reflected in the asset management application.
The discussion covered two possible integration approaches: a manual process, where asset data is exported from SAP and imported into the asset management system, and an API-based integration, where the two systems exchange asset information automatically. The main concern discussed was maintaining a proper asset-code structure, especially when multiple physical assets are purchased under a single Purchase Order (PO).
The meeting also covered the need for coordination with the finance team because asset-code structures maintained in SAP can affect the integration process.
The POC discussion focused on the integration between SAP/HANA and the Asset Management system for asset-code synchronization.
The main requirement discussed was that when an asset code is generated in SAP, the same asset code should be reflected in the Asset Management system. The discussion also covered the possibility of synchronization in both directions, where an asset code created in Asset Management could also be replicated in SAP through API integration.
Manual data transfer through export and import.
API integration between SAP/HANA and Asset Management.
The team also highlighted a potential challenge with asset-code creation when multiple physical assets are purchased under a single purchase order.
The SAP integration discussion focused on integrating the SAP system with an asset management and RFID-based asset tracking solution. The main objective is to keep SAP as the system of record for relevant asset master, finance, procurement, and maintenance information while using the asset management/RFID solution for asset visibility, movement tracking, lifecycle management, and real-time location tracking.
The discussion covered the complete integration flow, including unique asset identification, purchase orders, asset codes, serial numbers, API-based synchronization, asset transfers, RFID tracking, maintenance, depreciation, and handling of existing assets. The initial implementation is planned for approximately 100 assets, with the possibility of scaling to 1,000–2,000 assets later.
The SAP–ITSM API integration establishes a link between SAP and the ITSM system so that transaction data can be exchanged between both systems.
The discussion primarily focused on integrating SAP GRN-related data with ITSM, handling different transaction statuses, preventing duplicate records, validating unique GRN/reference numbers, and defining appropriate API responses.
The integration is intended to support communication between SAP and ITSM through APIs and a scheduled process for transferring data.
The project implementation plan focuses on reviewing the existing portal, validating the available inventory data, preparing the required employee and asset information, and completing the configuration required for asset allocation and tracking.
During the discussion, the team reviewed the portal and identified 236 inventory records for the Kolkata location. The implementation process includes verifying the imported data, preparing the employee master, mapping users with laptops or desktops, installing missing agents, generating QR-code tags, and assigning assets to users.
The team also discussed integration with Microsoft Azure / Microsoft 365 for employee data synchronization and Single Sign-On. The required Azure credentials and application details need to be prepared before the synchronization process can be completed.
The implementation will proceed step-by-step after the required templates, employee data, asset data, and Azure-related information are received and verified.
Key features
Google Workspace Integration
Connect the application with Google Workspace to manage and synchronize user information.
Multiple Domain Support
Support and manage users from multiple domains such as Spinny Capital and Spinny Works.
User Synchronization
Synchronize employee/user information from Google Workspace with the application.
Single Sign-On (SSO)
Provide single sign-on functionality for users across supported domains.
Bulk User Import
Allow users to be imported in bulk instead of manually creating each user.
Entity Management
Manage users and information based on separate entities and provide entity filtering functionality.
Role-Based Permissions
Configure access and permissions according to user roles.
Asset Check-in / Check-out
Allow users to record asset check-in and check-out information along with the applicable reason.
Ticket Management
Support ticket-related email configuration, ticket group email IDs, and ticket reporting.
Email Templates
Configure and customize email templates used for system communication.
Daily Reports
Provide daily reports, including check-in/check-out and ticket-related information.
Admin Configuration
Provide administrative configuration for Google Workspace, domains, users, permissions, and synchronization. The API configuration needs to be completed on the ITSM side to establish the required communication and response handling.
Employee Information Sync
Synchronize employee information such as manager email and other available attributes.
Verification & Go-Live
Completed features are verified and cross-checked before final confirmation and go-live.
SAP Integration
The solution can integrate with SAP through APIs. SAP can provide asset-related information, while the asset management system can send relevant changes back to SAP as part of a defined two-way integration process. For inter-city or real-time asset movement tracking, GPS trackers can be integrated with the system. The discussion noted that GPS hardware and connectivity would be separate requirements. The discussion specifically mentioned consuming APIs from SAP HANA to support the integration. The system can establish an API-based connection between SAP and ITSM to transfer relevant transaction information between the two systems.
Asset Master Synchronization
Assets created in SAP can be synchronized into the asset management system. The integration requires a unique asset code/ID for each individual asset so that both systems can identify and track the same asset correctly. When an asset code is created in SAP, the same asset code can be replicated in the asset management system through the integration.
Purchase Order Integration
Purchase order information generated in SAP can be used as part of the asset creation and synchronization process. The discussion highlighted the need to define how multiple assets within a PO are represented individually.
Unique Asset Identification
Each physical asset should have its own unique asset code. Using one code for multiple physical assets would create difficulty in identifying and tracking individual assets between SAP and the asset management system. A major requirement is to maintain appropriate asset codes for individual physical assets. Having one asset code for multiple physical devices can create problems for tracking and integration.
Serial Number Mapping
The exact serial number of each physical device must be associated with the corresponding asset code so that the SAP record and asset-management record can communicate correctly.
API-Based Integration
The integration can consume exposed APIs from SAP and synchronize information between the systems. The exact integration process depends on the APIs exposed by the SAP environment. API integration can be used to automate the exchange of asset-code information between SAP/HANA and Asset Management.
Batch Synchronization
The discussion indicated that SAP synchronization would generally be performed in batches rather than continuously. A schedule such as every few hours or a few times per day can be used to reduce unnecessary load.
Real-Time Asset Visibility
Real-time visibility is handled separately from SAP synchronization. The RFID solution can provide near-real-time or real-time information about asset movement and location.
RFID Asset Tracking
RFID tags can be attached to assets and used to track their movement. RFID readers can detect assets when they enter or leave locations and can also support continuous tracking for selected assets.
Asset Transfer Workflow
Assets can be transferred between employees, departments, locations, buildings, or cities. The system can maintain a controlled workflow with approval, dispatch, receipt, and transfer history.
Asset Lifecycle Tracking
The system maintains information throughout the asset lifecycle, including purchase, assignment, transfer, maintenance, repair, audit, and disposal.
Maintenance Management
Maintenance plans can be created for assets with scheduled tasks, responsible users, GPS requirements, proof/photo requirements, and mandatory activities.
Asset History
The system records asset history such as previous users, transfers, modifications, audits, dates, and other lifecycle activities.
Depreciation Reporting
A depreciation report can be maintained based on asset value, current value, end of life, and depreciation rules configured for the organization.
Accessories, Components and Consumables
The system can track accessories, internal components, and consumables associated with assets.
Alerts and Notifications
Alerts can be configured for events such as transfer delays, maintenance activities, asset movement, untraceable assets, and other business conditions. Notifications can be sent through email and other supported channels.
Real-Time RFID Dashboard
The RFID dashboard provides visibility into asset movement, including assets entering and leaving monitored locations, untracked assets, and movement history.
SAP Asset Code Integration
Asset codes generated in SAP can be reflected in the IT Asset Management system. The Asset Management system can be integrated with SAP so that an asset code generated in SAP can be reflected in Asset Management.
Two Integration Methods
The discussion identified two possible methods:
- Manual Integration: Export the asset data from SAP and import it into the asset management system.
- API Integration: Use APIs to exchange asset information between SAP and the asset management system.
Two-Way API Integration
The integration can work in either direction. The asset management system can consume SAP/HANA APIs, or SAP can consume APIs exposed by the asset management system. The discussion confirmed that integration can work in both directions:
- SAP creates the asset code → Asset Management receives/replicates it.
- Asset Management creates the asset code → SAP can receive/replicate it. For this, the respective APIs need to be consumed/integrated by the systems.
Manual Asset Code Import
Where API integration is not immediately available, asset codes can be exported from SAP and imported while adding assets to the asset management system. Asset codes can be transferred manually by exporting the required data from SAP and importing it into Asset Management while adding the asset.
Finance Team Coordination
The finance team needs to review and confirm the existing asset-code structure before implementation because SAP asset records and financial processes are involved.
POC / Testing
The team has provided the console for further evaluation, testing, and feedback. The next step is to conduct the POC/testing and collect feedback from the relevant team.
SAP API Data Exchange
SAP can send transaction data to ITSM through an API, and ITSM can return a response confirming whether the data was successfully received or whether it was already processed.
GRN Data Integration
The integration discussed GRN-related transactions, including received entries, cancelled entries and purchase returns.
GRN Number as a Unique Reference
The GRN number is treated as an important unique reference for identifying a transaction and validating whether the record has already been processed.
Status-Based Processing
The API data includes a status that represents the transaction state. The discussion specifically referred to status values for received, cancelled and purchase-return scenarios.
Duplicate Data Validation
Before processing an incoming record, the ITSM system should validate whether the same GRN/reference information has already been stored.
Duplicate Response
When the same data is received again, the system can return a duplicate response rather than processing the record again.
Success Response
When a new record is received and successfully processed, ITSM can return a success response to SAP.
Reject Response
When a record has already been processed, the system can reject the repeated request and return the appropriate response indicating that the data is already available.
Two-Way API Communication
The discussion covered two-way communication where SAP sends data to ITSM and ITSM provides a response back to SAP.
API Response Validation
The response from ITSM should contain the relevant GRN/reference information and status so SAP can determine whether the transaction was accepted or rejected.
Scheduled API Execution
The API process can be executed through a scheduler. The discussion mentioned a scheduler running once a day.
Duplicate Prevention During Scheduling
The system needs to prevent duplicate processing when the scheduler retrieves records that have already been sent and successfully processed.
Database Validation
The ITSM database can be checked before processing an API request to determine whether the relevant record already exists.
Existing Record Handling
When the same GRN/reference number has already been processed, the system should not create another record. Instead, it should return the appropriate duplicate/reject response.
Transaction Modification Handling
The discussion considered scenarios where transaction information may be modified or cancelled after the original transaction has been sent.
Cancelled Transaction Handling
Cancelled transactions should be identified through their corresponding status and processed separately from received transactions.
Purchase Return Handling
Purchase-return transactions can be identified through their transaction status and corresponding GRN/reference information.
Header and Line-Item Structure
The discussion covered a structure in which the GRN information can contain a header and multiple line items.
Multiple Line Items
A single GRN can contain multiple line items, and the API must handle those items while maintaining the correct GRN/reference relationship.
Reference Number Validation
The reference number received from SAP should be validated to ensure that the correct transaction is being processed.
Data Consistency
The integration requires consistent GRN numbers, references and statuses so that SAP and ITSM maintain the same transaction state.
Testing Environment Validation
The API was being tested in a testing environment, and some data behavior observed during the discussion was attributed to the test environment.
Handling Multiple Assets Under One PO
A potential challenge was identified when a purchase order contains multiple physical assets, such as 10 laptops, but SAP generates only one asset code for all 10 laptops instead of creating an individual asset code for each laptop. This type of data structure needs to be clarified with the Finance team because it can create asset-tracking and financial-record challenges.
POC Evaluation and Feedback
The team had provided positive verbal feedback on the POC, while the written feedback was marked as satisfactory. Further evaluation and testing were requested from the concerned team.
Further Testing and Support
The concerned team was asked to continue testing the POC, provide any required support or feedback, and complete the evaluation.