Oder Capture component

PeopleSoft CRM runs mainly on Application package code and it is reducing its dependency on the Function Library with each release.
HRMS, FSCM, EPM and other modules of PeopleSoft are yet to adopt the Application Package totally.

Application package is the heart of the PeopleSoft where in it will allow reusability, Object oriented programming, building complex architecture for representing component and also expose PeopleSoft business logic through CI adapters.

Order Capture module in CRM is one such example for displaying the power of the Application package. The whole component is captured into RO_CAPTURE and RO_CAPTURE_TYPES application package.

The logic is built so well that it closely integrates with other application packages. We all know that PeopleSoft doesn’t support multiple inheritances while building/creating the classes. To bring the business logic of the other application packages, PeopleSoft uses a combination of property, super class and get/set concepts.
Our team was facing a complex problem in Order Capture module, it goes something like this:
1. Pricing Engine currently runs on Header level keys; configure it run on combination of Header and Line level keys.
2. Currently, Price List cannot be associated to a Catalog code so build the customization for the same
3. We will not be using the PS delivered Catalog functionality, so on the line level details add a new field Catalog Code. On the field change event, run the pricing engine with the Catalog code as line level key.

The above one liners were looking simple to read and understand, but as we started to look into the code and architecture of the Order Capture component, we realized one thing. It doesn’t look as simple as the requirements are written in the document. :-(
But, we were determined to crack this complex puzzle. Yeah, the whole application package looked like one complex jigsaw puzzle with all pieces thrown around. It required complete understanding of these huge code and classes to get the complete picture.
So, we started understanding the requirements and breaking down this huge task into smaller ones.

Initially, we started understanding the Order Capture and Pricing engine (Price Rule + Price list + Arbitration Plan) linkage.
While the CSR (Customer Service Rep) takes the Order, PeopleSoft calculates the discounts and offers on Products using the Header level information (record.RO_HEADER). The Price Rule, Price List and Arbitration plan are built in the PeopleSoft which will identify the information on the Header level records.
The above scenario was existent in the earlier versions of PeopleSoft i.e before PeopleSoft CRM 9.0.

One of the major enhancements in the PS CRM 9.0 was that PeopleSoft is able to calculate discounts and offers now on line level also. This was what the client wanted in our case and it matched with their requirement.
Strangely, the gap analysis was done against PS CRM 8.9 by the functional team and they had listed this request by the client as one the major enhancement as it was changing the whole logic of the Pricing Engine.

Now, once we started work in this aspect we found that Pricing engine could be configured to recognize the keys not just on the Order Header level but also in the Line level.
But, we wanted to confirm this with the Functional team whether we are on the right track. We told them about our finding, they too were surprised and asked us whether we can give them a demo of our work till now.

We smelled some success, after so many hours of understanding, reading and searching. We readily agreed and we were excited also at the same time.
The summary of our customizations are as follows:
1. We built a Price Key for Catalog Code. This will be used to capture the Transactions data of the Order Capture component. (Homeà Setup CRMàEnterpriser PriceràBuild Price key by transaction)
2. Once this is done, check whether the newly built key is available as “Related object” in Price List, Price Rule, Arbitration plan. If this is done, then you are on the right track.
3. Now build your own Price Rule, Price List, and Arbitration Plan for testing purposes (Homeà Pricing Configurationà Price Rule, Price List and Arbitration plan).
4. Go to Homeà Pricing Configurationà Simulator. Simulator is equal to Order Capture logic and this is used by the Marketing Team to determine whether the Price Rules and Price lists created are working as intended.
5. Here, create a new Order and check whether the Pricing engine is running as intended. (Line level keys can be added or deleted by clicking on Key symbol in the line level details section)

Finally, the D-day arrived. We were all tensed, will we able to pull it off or not. But it turned out to be a smooth one with the functional team happy with our findings and told us that we are on the right track.

A complex puzzle solved with great team effort and some own thinking helped :-D

App