Understanding Installed Assets
This topic discusses system management of new and updated data in the integrated system.
The CRM Installed Product table requires a Product ID for every Installed Asset. This enables users to see the kind of asset that is being referred to in the system. Since neither Product ID nor Inventory Item ID are required for entries in the Financials Asset table, it is important that CRM installed product table entries are assigned a Product ID.
The CRM system assigns Product IDs according to the Product Mapping table.
Note: PeopleSoft Financials assets do not store product data, but product ID is a required attribute for CRM installed assets. Therefore, a mapping table specifies the Product ID that CRM should use to create a new entry from Financials asset data. The administrator can add entries to the mapping table to link specific combinations of asset subtype, manufacturer, and model values from Financials with a particular CRM Product ID. Additionally, a default entry is required in the CRM mapping table (designated by just a Product ID value with no subtype, manufacturer, or model values). The CRM system uses the default to create installed asset entries if the mapping table contains no match on more specific combinations of subtype, manufacturer, and model values.
The system checks the mapping table first to determine the product ID since there should always be a default product ID for use in the mapping table (even when there are no matches on the asset subtype, manufacturer and model data). If no mapping table entry is found, the system derives the product ID from the item ID. Thus, the item ID is used only in cases where no mapping table exists for the setID. Not having a mapping table for the setID, however, would constitute an erroneous data setup.
Assignments by Matching Attribute Values
Ideally, each combination of Financials Asset_Subtype, Manufacturer, and Model corresponds to a CRM product, and each will map to an asset that can conceivably be returned by the Financials system (including the discovery process run on the Financials system). This enables a meaningful CRM product to be associated with each type of Financials asset.
Image: Assigning Product IDs in CRM
This graphic illustrates how a Product ID is determined for a new asset in the CRM system.
When receiving information on a new asset from the Financials system, the CRM system checks the Financials Asset table for a match on non-null values for the Asset_Subtype, Manufacturer, and Model fields. If there is a match, the CRM system uses the corresponding Product from the mapping table to create the new installed asset on the CRM system. If there is no match for the three fields, a match will be attempted on Asset_Subtype and Manufacturer. If a match is found here, the corresponding Product_ID will be used. If no match is found on these two fields, a match will be attempted only on Asset_Subtype. If no match is found on this field, a match will be attempted just on blank values for Asset_Subtype, Manufacturer, and Model (this type of row will correspond to a “default” Product_ID).
Note: A SaveEdit error on the mapping page requires a value for Manufacturer if a value for Model is present on that row. In addition, this SaveEdit error requires that the user enter a single “default” value specifying a Product that should be used when no other match applies. This helps ensure that CRM Products can be identified and used for any asset entry that comes from Financials.
As already mentioned, the user ideally would set up data so that the assets sent from Financials (Asset type of IT-Hardware) have values for Asset Subtype, Manufacturer, and Model, and ensure that each of these combinations is mapped to a distinct Product on the mapping page. This would involve setting up the appropriate Asset Subtypes and Profiles on the Financials side, and the appropriate Products and product mapping setup page on the CRM side. Providing a “default” Product ID as described above ensures that a Product ID can always be found for use in the CRM Installed product table. This is required since the CRM Installed Product table requires a Product ID value for each of its entries.
Important! Before adding data to the Product Mapping page, the user must run the Manufacturer_Fullsync and Copy_AM_Subtype full synchronizations. Synchronizations are discussed further in Chapter 2, Setting Up Integration and Data Transfer, “Setting Up the Mapping Table.”
When asset data is sent from Financials to CRM, the CRM installed asset table is updated with the corresponding asset data. The identification logic involves filtering data attributes to find matches between Financials and CRM. The logic must account for definite positive matches, assumed positive matches, and ambiguous match results.
Positive Matches
This table depicts the conditions that result in the three possible update outcomes when the CRM system identifies a match of one or more of the four asset table values in the Financials asset data:
|
Required Match Conditions |
CRM Update Outcomes |
|||
|---|---|---|---|---|
|
Serial ID |
Business Unit |
Asset ID |
Installed Product ID |
|
|
Match* |
Match* |
The CRM data for that row is updated with all the values from Financials. This may occur when data for an asset has previously been received from Financials by CRM and a change is subsequently saved and published by Financials. |
||
|
Match |
The CRM data for that row is updated with all the values from Financials. This may occur when data for an asset was created by CRM and sent over to Financials and a change is subsequently saved and published by Financials. The corresponding CRM entry would have the same Installed Product ID but would not yet have values for Business Unit and Asset ID. |
|||
|
yes |
No match* |
No match* |
The CRM data for that row is updated with all the values from Financials. This may occur if data for the same asset has been entered independently in both Financials and CRM prior to initial synchronization. If data for the same asset has been entered in Financials and CRM in a prior release, the Financials entry will initially not have the key fields for the corresponding CRM entry and the CRM entry will initially not have the key fields for the corresponding Financials entry. However, if both entries refer to the same Serial ID, it can be assumed that they refer to the same actual asset. |
* Both conditions must be true.
Assumed Positive Matches
Match conditions vary depending on the asset:
Asset Tag
If there is a match between Financials and CRM based on identical non-null values for asset tag and product, and if there is a blank value for Business Unit, Asset ID, and Serial ID on the CRM side, the CRM data for that row will be updated with all the values from Financials. This applies in situations where data for the same assets already existing in Financials and CRM (but in which CRM may only have a value for Asset_Tag, rather than Serial ID), and an update from Financials needs to be matched against the corresponding CRM entry.
Employee and Product
If there is a single matching row between Financials and CRM based on identical non-null values for employee ID and product ID, and there is a blank value for Business Unit, Asset ID and Serial ID on the CRM side, the CRM data for that row will be updated with all the values from Financials. This applies in situations where data for the same actual assets already exists in Financials and CRM, and an update from Financials needs to be matched against the corresponding CRM entry. If there is single entry in CRM that matches the assigned employee and Product, it is assumed to refer to the same actual asset, and the CRM entry will be updated.
Department and Product
If there is a single matching row between Financials and CRM based on identical non-null values for Department ID and Product ID and there is a blank value for SeriaI ID on the CRM side, the CRM data for that row will be updated with all the values from Financials. This applies to situations where data for the same actual assets already exists in Financials and CRM (but in which CRM may only have a value for Asset_Tag, rather than Serial ID), and an update from Financials needs to be matched against the corresponding CRM entry. If there is a single entry in CRM that matches the assigned department and Product, it is assumed to refer to the same actual asset, and the CRM entry will be updated.
Ambiguous Matches
When it is not possible to unequivocally determine that the asset is definitely the same or definitely different on both systems, the data for that row is sent to a reconciliation table that the administrator can access in the CRM application. The reconciliation table lists the assets, with their attribute data, that require reconciliation with CRM entries. The administrator can open each entry to view the possible matches with existing CRM installed assets based on the matches on Product_ID and one or more of the following: Emplid, Deptid, or Location.
The administrator can:
Confirm that the CRM entry refers to the same asset represented by the data from Financials and update the CRM data with all the values from the Financials system.
Specify that the Financials data does not refer to any asset on the CRM side and create a new CRM installed asset.
The asset manager reconciles ambiguous matches on the Asset Reconciliation page, shown in this figure.
Image: Asset Reconciliation example
This example illustrates the fields and controls on the Asset Reconciliation example.
In this example, a Financials entry for a Compass Notebook computer with Serial ID A43-22342 belonging to Carmichael Espinosa (Emplid KU0015) was received. However, the search results show two existing CRM installed assets for the same person and product. Since the CRM entries have no Serial_ID value, it is not possible to automatically determine if either asset is the same actual asset as the Financials entry; the match results are ambiguous.
The asset manager must now conduct research on the two CRM entries to determine whether either of them does indeed represent the same asset as the new entry from Financials (serial id A43-22342). If research indicates that the actual asset represented by the first CRM entry (Asset Tag GBI02–IT2037) has a serial ID of A43-22342, then it is in reality the same asset as the entry from Financials. To reconcile the data, the manager selects the first CRM asset in the table and clicks the Merge Selected Installed Asset button, thus merging the data from the new Financials entry with that CRM installed asset entry.
On the other hand, if neither serial ID of the two CRM entries corresponds to the Financials entry, then the entry represents a different physical asset. The manager reconciles the new data by clicking the Create New Installed Asset button to create a new CRM Installed Asset entry from the data of the Financials entry, giving Carmichael Espinosa a total of three Compass Notebook installed asset entries.
With ambiguous matches, often data for the same actual assets exists in Financials and CRM (but in which CRM may only have a value for Asset_Tag, rather than Serial_ID) because the lack of matching unique identifiers and/or the presence of multiple potential matches prevents a positive match.
Note: The status value of a Financials asset does not map directly to the status of the corresponding CRM installed asset. The Financials system will only update the CRM Installed asset entry to "Installed" or "Uninstalled", depending on what transaction is being executed in Financials.
For example, whenever a user updates an asset in the Basic Add page in Financials, the status of the new or existing CRM installed asset is updated to "Installed" (stored in the system as "INS") regardless of the actual status value of the asset in Financials. Whenever a user disposes of an asset in the Financials system, the status of the corresponding CRM installed asset is set to "uninstalled" (stored in the system as "UNI").