Introduction
What is the IPC?
The IPC is the ‘Internet Pricing and Configurator’. It is a Java-based client-server package. It provides R/3 pricing and R/3 product configuration outside of an R/3 system.
1) The Sales Pricing Engine, or SPE (relates to R/3 Condition Technique)
2) The Sales Configuration Engine, or SCE (relates to R/3 Variant Configuration)
3) The Product Modeling Environment, or PME (relates to R/3 Variant Configuration master data)
In addition, it has Java Server Page (JSP) front ends and a Java UI. The JSP front ends are integrated into the different CRM scenarios (telesales, internet sales, mobile sales, etc). You can deploy them normally on your J2EE stack.
Short answer: to enable consistent pricing and configuration through all sales channels, without needing an online R/3 system, whilst still maintaining pricing and configuration data in one place.
The IPC is typically used in a CRM scenario, using the CRM database (for Telesales and Internet Sales). It uses its own database for other scenarios.
The IPC consists of a set of engines which execute pricing (in a broad sense) and product configuration functionality in a variety of scenarios and SAP applications (CRM, SRM, ERP). The most important components of the Internet Pricing and Configurator are: 1) Sales Pricing Engine (SPE) is the single source of pricing for all sales and procurement channels. The pricing is based on product, business partner or hierarchy. Pricing conditions can be applied at header, item, or detail level. It supports discounts, surcharges, rebates, volume based pricing, tax determination, price overrides - on percentage or on value basis. The SPE also used for integrated pricing for procurement in SAP SRM. 2) Sales Configuration Engine (SCE) is the single source of intuitive product and service configuration information for all sales channels (E-Commerce, Enterprise Sales, Field Sales, Interaction Center) across sales reps, business partners and customers. It uses an intuitive and adaptable Web user interface based on JSP. 3) Free Goods Engine: Used to determine free goods of the same or another product (for example, “Buy two, get three”) in all scenarios. Free Goods are also based on condition techniques. 4) Listings allow to determine whether a certain products are explicitly allowed or excluded for a specific customer in e.g. a sales order. The determination of listings is based on condition technique and part of the IPC. 5) Free Goods Engine: Used to determine free goods of the same or another product (for example, “Buy two, get three”) in all scenarios. Free Goods are also based on condition technique. 6) Listings and Exclusions allow to determine whether a certain products are explicitly allowed or excluded for a specific customer in e.g. a sales order. The determination of listings is based: -> Based on condition technique and part of the IPC. IPC Architectural Sketch As of the 2005 edition, the IPC engines (SCE, SPE, etc.) run within the so-called Virtual Machine Container (VMC). It is part of the SAP Web Application Server in Netweaver 2004s and allows the SAP Kernel to execute ABAP as well as Java programs. Some relevant technical information for administrators regarding the VMC can be found in note 853711. The VMC executes java programs within a strong and robust enterprise scale infrastructure and offers: 1) SAP kernel technology (work processes, transport system) 2) Fast in-process Java-ABAP communication 3) Strong user isolation, robustness However, this does not mean that Java is “translated” to ABAP. The IPC itself remains a Java program; however, it enjoys the same infrastructure as an ABAP program. The IPC engines are installed and patched with the AP Foundation layer (see SAP Note 844817). The VMC is not a J2EE Container and does not contain an EJB container. Hence, the IPC UI used for product configuration or pricing analysis runs on the J2EE Engine like in previous releases. Note: Execution of byte-code in the Java VM is accelerated by something that is known as a Just-In- Time (JIT) compiler. Currently, the JIT is not available for all platforms. |
Pricing Configuration Guide with Used Cases
http://scn.sap.com/docs/DOC-36366
SAP Community Network Wiki - ERP Operations - 16 Fields in Pricing Procedure and Their Description
Steps for creating pricing userexits for beginners.
Go to SAP Note 809820 for pricing manual and download the project and the document.
5.1 Set VMC in Debug Mode
The logical application server is usually hosted on different servers and load balanced via the message server. To debug
the VMC the user has to know on which host his work process run. In the SAPGUI menu System -> Status… the Server
name (first part) is displayed. On the next page (3rd button) also the corresponding IP address is given. Switching
between hosts of one server can be done via transaction sm51.
Run transaction sm52 to display the available VMCs. This window will later show the servers running virtual machines
and also the debug state and port of each one.
A VMC work process switches into debug mode when a program flow from ABAP to Java (RFC function module) is
passed and ABAP was in debug mode (with /h). To help debugging each call of such a pricing RFC module a
conditional breakpoint triggered. To active the breakpoint the user parameter PRC_RFC has to be set to X (transaction
su3).
While running the transaction (e.g. order processing) each call to pricing will hold and with a step-into debugging into
the RFC module (F5) a VMC debug port will be activated. This VMC will stay attached as long the ABAP transaction
runs.
5.1 Set VMC in Debug Mode
The logical application server is usually hosted on different servers and load balanced via the message server. To debug
the VMC the user has to know on which host his work process run. In the SAPGUI menu System -> Status… the Server
name (first part) is displayed. On the next page (3rd button) also the corresponding IP address is given. Switching
between hosts of one server can be done via transaction sm51.
Run transaction sm52 to display the available VMCs. This window will later show the servers running virtual machines
and also the debug state and port of each one.
A VMC work process switches into debug mode when a program flow from ABAP to Java (RFC function module) is
passed and ABAP was in debug mode (with /h). To help debugging each call of such a pricing RFC module a
conditional breakpoint triggered. To active the breakpoint the user parameter PRC_RFC has to be set to X (transaction
su3).
While running the transaction (e.g. order processing) each call to pricing will hold and with a step-into debugging into
the RFC module (F5) a VMC debug port will be activated. This VMC will stay attached as long the ABAP transaction
runs.
5.2 Attach Eclipse Java Debugger
After a VMC work process has an open debug port, which can be viewed with transaction sm52, the eclipse debugger
can be attached to it.
Because attaching the debugger to the VMC will run directly the code, first interesting java breakpoint may be set.
Attaching eclipse works then as follow:
1. Open menu Run->Debug…
2. Create a new Remote Java Application Configuration
3. Enter as host the server where the VMC work process is running on
4. Enter the debug port as the one VMC work process debug port shown in transaction sm52
5. Click on Debug
The debugging view will normally popup automatically and a successful attachment will show all working threads of
that VMC work process.
Attach Eclipse Java Debugger
After a VMC work process has an open debug port, which can be viewed with transaction sm52, the eclipse debugger
can be attached to it.
Because attaching the debugger to the VMC will run directly the code, first interesting java breakpoint may be set.
Attaching eclipse works then as follow:
1. Open menu Run->Debug…
2. Create a new Remote Java Application Configuration
3. Enter as host the server where the VMC work process is running on
4. Enter the debug port as the one VMC work process debug port shown in transaction sm52
5. Click on Debug
The debugging view will normally popup automatically and a successful attachment will show all working threads of
that VMC work process.
http://scn.sap.com/people/dheeram.kallem3/blog/2010/07/07/pricing-user-exits-in-crm
we found another way without JCo to transfer the differences from ABAP to JAVA.
If you use the COND_COM_BADI then do the following in method item_name_value:
METHOD if_ex_crm_cond_com_badi~item_name_value.
DATA: ls_inv TYPE prct_attr_name_value,
lv_seq TYPE prct_attr_sequence_number,
lv_pricing type char1.
FIELD-SYMBOLS: <ls_inv> TYPE prct_attr_name_value.
get parameter id 'YY_PRICING_EXIT' field lv_pricing.
check: lv_pricing = 'X'.
READ TABLE ct_item_name_value ASSIGNING <ls_inv>
WITH KEY attr_name = 'CAMPAIGN_GUID'.
IF sy-subrc 0.
lv_seq = 0.
ELSE.
lv_seq = 1.
ENDIF.
* CRM_PRIDOC_COMM_BADI
ls_inv-attr_name = 'CAMPAIGN_GUID'.
ls_inv-seq_number = lv_seq.
ls_inv-attr_value = '11111111111111111111111111111111'.
INSERT ls_inv INTO TABLE ct_item_name_value.
lv_seq = lv_seq + 1.
ls_inv-attr_name = 'CAMPAIGN_GUID'.
ls_inv-seq_number = lv_seq.
ls_inv-attr_value = '22222222222222222222222222222222'.
INSERT ls_inv INTO TABLE ct_item_name_value.
lv_seq = lv_seq + 1.
ls_inv-attr_name = 'CAMPAIGN_GUID'.
ls_inv-seq_number = lv_seq.
ls_inv-attr_value = '33333333333333333333333333333333'.
INSERT ls_inv INTO TABLE ct_item_name_value.
ENDMETHOD.
Then in JAVA you can read the multi-value attribute with the following coding:
String[] test = pricingItem.getAttributeValues("CAMPAIGN_GUID");
userexitLogger.writeLogDebug("Length: " + test.length);
for (int i = 0; i < test.length; i++){
userexitLogger.writeLogDebug("CAMPAIGN_GUID: " + test);
}
The BADI CRM_COND_COM_BADI is used for filling the pricing communication structure.
If you have added any field at header level of the field catelog that will available in the changing parameter of the method HEADER_COMMUNICATION_STRUCTURE.
If you have added any field at item level of the field catelog that will available in the changing parameter of the method ITEM_COMMUNICATION_STRUCTURE.
Additional fields added at catalog can be filled with the values using this BADI.
KOMP - is the table in the R/3 which holds information about Pricing Communication Item
KOMV - is the table in the R/3 which holds information about Pricing Communications-Condition Record
VBAK---- is the table in the Sales Document: Header Data
KSCHL - is Condition Type
KWERT - is Condition value
kzwi3 - is Subtotal 3 from pricing procedure for condition
Characteristics :
CABN Characteristics ( o.a. batch/vendor)
CABNT Characteristics description
CAWN Characteristics ( o.a. material)
CAWNT Characteristics description
AUSP Characteristic Values
Class types and objects :
TCLAO Several class types for object
TCLA Class types ( vb. lfa1 => v10 en 010)
TCLAT Class type text
TCLT Classifiable objects
TCLC Classification status
Links :
INOB Link between Internal Number and Object
KLAH Class header data
KSSK Allocation Table: Object (vb.matnr) to Class
KSML Characteristics for a class (internal number)
1) Requirement 620:
sy-subrc = 4.
if komp-matkl = 'ZV87' or
komp-matkl = 'ZV96'.
clear sy-subrc.
endif.
Explanation:
Just material group ZV87 and ZV96 will be valid for this requirement.
This is User Exit of type Requirement(REQ).
The following is the java code for the above ABAP requirment.
package com.sybase.pricing.userexits;
import com.sap.spe.condmgnt.customizing.IAccess;
import com.sap.spe.condmgnt.customizing.IStep;
import com.sap.spe.condmgnt.finding.userexit.IConditionFindingManagerUserExit;
import com.sap.spe.condmgnt.finding.userexit.RequirementAdapter;
import com.sap.spe.base.logging.UserexitLogger;
/**
*
*
* To change the template for this generated type comment go to
* Window>Preferences>Java>Code Generation>Code and Comments
*/
public class Z620 extends RequirementAdapter {
private static UserexitLogger userexitlogger = new UserexitLogger(Z620.class);
public boolean checkRequirement(IConditionFindingManagerUserExit item, IStep step, IAccess access)
{
if (item.getAttributeValue("HIER_CAT_ID").equals("ZV87") || item.getAttributeValue("HIER_CAT_ID").equals("ZV96"))
{
return true;
}
return false;
}
}
http://wiki.sdn.sap.com/wiki/display/CRM/Pricing+validations+using+requirement+routine
http://scn.sap.com/people/tapan.jain/blog/2009/06/25/ipc--facts-you-always-wanted-to-know--fact-1
You will write the Java functions based on the custom VC functions in the ECC system. You will closely work with ECC Variant configuration team and get the details of the custom functions that are developed in the designtime VC model for supporting their runtime VC. This runtime environment is not available in CRM, only the design time information is downloaded as "Knowledge Base". SAP provides the Java code for all the standard "VC" functions in ECC. In ECC see function group "CUPR" for the standard VC functions. Variant function is the other face of the IPC and should not be confused with any of the features of the Pricing in IPC. The SCE(Configuration Engine) deals with with the configurable product. The design time configuration of configurable products are downloaded as Knowledgebase in CRM. Since the design time (KB) is available to IPC, during runtime the reference to pfunctions and functions are known to IPC and IPC be design will look for the instances for the classes of these variant functions. In ECC, you use transactions CU65,CU66,CU67 to maintain the interface definition of a variant function. Here, Variant functions are implemented as ABAP functions with a generic interface which contains QUERY and MATCH arguments with structure CVOV_2. The interface definition of a variant function(import and export parameters) is part of the knowledge base generated in ECC. Function: Function provides read access to the knowledge base to derive the export parameters. PFunction: Compared to Function, PFunction offers extended functions it provides read and write access to configuration and dynamic database(DDB). For this reason, you cannot use PFunctions in declarative dependencies(constraints and actions).
At the start of the configuration process, the Configuration Engine automatically searches the knowledge base for java classes of variant functions that have the same name as the variant functions created in ERP. If no variant function is found, the Configuration engine executes the function sce_noop_fn instead, with the output true. Definition You can use variant conditions to influence the price of a configurable material depending on the characteristic values assigned. Use You can use variant conditions in Sales and Distribution and Purchasing to define surcharges and discounts for the basic price. Structure Variant conditions consist of a variant key and an amount that is identified by the variant key. |
Go to SAP note 870201 for pfunctions implementation manual.
Use
In Purchasing, you can use variant conditions to define surcharges and discounts for configurable materials that are procured externally. The surcharges and discounts depend on the values assigned to the characteristics in the sales order or (for material variants) the material master.
If you order a bicycle frame in the color ‘Silver metallic’, the vendor adds a surcharge of $20. You create a variant condition called SILVER. When you select a frame in silver metallic, the variant condition is added to the price automatically.
Prerequisites
You have created a characteristic that refers to table MMCOM, field VKOND. The characteristic is assigned to the variant class for the configurable material.
An object characteristic with a reference to the table MMCOM field VKOND is multi-value because several variant conditions can be entered.
In Customizing for Purchasing, you have defined a new access sequence (0014) and 2 new condition types (VA00, which is quantity-dependent, and VA01, which is a percentage). These condition types are in schema RM0000. You have set the Variant condition indicator.
Process Flow
1. You create a purchasing info record for the externally-procured, configurable material, in which you maintain the variant conditions.
2. You create a procedure where you enter the reference from the characteristic to the structure MMCOM and the variant key.
CHAR_VARCOND = 'SILVER' if PAINT = 'Silvermetallic'
- You have created a characteristic, CHAR_VARCOND, that refers to table MMCOM, field VKOND.
- The variant condition SILVER with the amount $ 20 is maintained in the purchasing info record.
3. You allocate the procedures to either the characteristic values that trigger the variant conditions or the configuration profile, depending on the condition defined in the procedures.
4. You configure the material:
- In the material master, as a material variant
- In the sales order
5. In material requirements planning (MRP), a purchase requisition is created for the material. The purchase requisition contains the configuration of the material.
6. Once released, the purchase requisition is converted to a purchase order. The net price for the material is displayed in the item overview of the purchase order. When you display the conditions for an item, you see the value of the variant condition that is included in the net price.
Maintaining Variant Conditions in the Info Record
Prerequisites
The material for which the info record is to be created or changed is configurable.
Procedure
Result
The next time the material is needed in a sales order (i.e. the configurable material is either reconfigured in such a way that a characteristic value is reached or it is already so configured), a requisition is generated for it and converted into a purchase order, the system applies the variant conditions when determining the purchase order price.
http://scn.sap.com/people/santosh.v/blog/2007/03/05/configuration--part-1
http://scn.sap.com/people/dheeram.kallem3/blog/2010/07/07/pricing-user-exits-in-crm
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.