Abstract: A sales catalog interface, wherein the architecture allows the user the ability to controllably view the data with certain engines either running or not running, so that certain items of detailed information is either displayed or not displayed to the user. Data from engines may include, price, eligibility, and availability, may be retrieved synchronously or asynchronously, and may be based upon consumer context, such as account type, geography, etc.

Abstract: Disclosed are systems, methods, and computer program products to implement product group mappings. In order for different CRM applications (e.g., sell side and internal side applications) to work in cohesive manner, the disclosed approaches provide mapping functionality that can map product groups captured in one system using one hierarchy to be translated to the other system using the hierarchy that the consuming system understands.

Abstract: Described is an improved approach for implementing a handshake mechanism to permit effective versioning and updates for data within an enterprise application. Version numbers are associated with sales catalog objects, where the appropriate version number is associated with the specific object to be published as the run-time object for the sales catalog. Each of the sales catalog versions is associated with a unique identifier, where one of the identifiers is recognized as the “run-time” version identifier. The sales catalog having the recognized run-time identifier value is visible to and accessible to the ordinary users of the system as the runtime sales catalog. All other sales catalog versions associated with other identifiers are not visible/accessible to ordinary users.

Abstract: Disclosed are systems, methods, and computer program products to implement product group mappings. In order for different CRM applications (e.g., sell side and internal side applications) to work in cohesive manner, the disclosed approaches provide mapping functionality that can map product groups captured in one system using one hierarchy to be translated to the other system using the hierarchy that the consuming system understands.

Abstract: Described is an improved approach for implementing a handshake mechanism to permit effective versioning and updates for data within an enterprise application. Version numbers are associated with sales catalog objects, where the appropriate version number is associated with the specific object to be published as the run-time object for the sales catalog. Each of the sales catalog versions is associated with a unique identifier, where one of the identifiers is recognized as the “run-time” version identifier. The sales catalog having the recognized run-time identifier value is visible to and accessible to the ordinary users of the system as the runtime sales catalog. All other sales catalog versions associated with other identifiers are not visible/accessible to ordinary users.

Abstract: A sales catalog interface, wherein the architecture allows the user the ability to controllably view the data with certain engines either running or not running, so that certain items of detailed information is either displayed or not displayed to the user. Data from engines may include, price, eligibility, and availability, may be retrieved synchronously or asynchronously, and may be based upon consumer context, such as account type, geography, etc.