Today, I thought I would start a series of a few posts regarding running a “large” RFx in E-Sourcing. A few years ago, I worked with an E-Sourcing customer that used E-Sourcing to solicit bids from around 250 suppliers for a very large number of products. I would actually characterize the objective of the RFx as a “catalog refresh” - the E-Sourcing customer required pricing updates from all of their suppliers for a number of products. In some cases, the supplier provided just a few products; in other cases, the supplier provided thousands of products.

In addition to requiring price updates from the suppliers, the customer also needed to use E-Sourcing to negotiate updated terms and conditions for their contract.

Overall, this scenario presented a very interesting use-case for E-Sourcing: to negotiate contract terms and conditions and follow that negotiation with solicitation of updated pricing from suppliers.

After much thought and analysis, we decided to structure the “event” as follows. We started by creating a basic E-Sourcing RFI. The purpose of the RFI was to negotiate the contract terms and conditions as well as to solicit some other information from the suppliers. The RFI was a very basic RFx in E-Sourcing: it consisted of only a few questions. One of the questions we defined was an “attachment question” - the purpose of this question was to have the suppliers upload a red-lined version of the draft contract terms and conditions, which were provided to the supplier as an attachment published by the E-Sourcing customer. This single RFI was published to the 250 suppliers.

Due to the large number suppliers participating in the RFx, we allocated three months to process the results and complete the contract negotiations.

Next week I will write about how we collected the updated pricing from the suppliers.

Hi All - I apologize that I missed my posting last week. I am doing my best to write weekly, but it is not always so easy.

In the past couple of weeks, I have spoken to some people about the E-Sourcing / CLM Page Customization feature. This feature allows you to make configurations to the user interface in E-Sourcing without changing code. The types of configurations include: hiding fields, making fields required, changing the labels on fields, positioning fields on a page, and making fields not editable.

Page customizations are setup for a business object class or master data class. That is, each of the major business objects (Projects, RFx, Auctions, Master Agreements, etc) in E-Sourcing / CLM will have one page customization object. Each page customization object will consist of overrides that indicate the individual field configurations. For example, to make the Description field required in the Projects module, there will be a single override that specifies the field DOCUMENT_DESCRIPTION will have its required property set to a value of yes.

Each override in the page customization object will specify a single property for the field, so there could be many overrides for a single field. Unfortunately, the system does not perform many validations when the overrides are setup, so the specification of the field id must be done correctly; additionally, the system allow the same override to be specified for the same field multiple times. At run-time, however, the first one in the list of the overrides is the one that will be applied.

When page customization overrides are used as described above, they will apply to all instances of the business object class (e.g., all projects in the system would have the description being required). In many cases, however, there are requirements to conditionally implement page customization overrides. That is, the requirement might be that the description should only be required when the project is a specific type.

Conditional page customization overrides are available in E-Sourcing / CLM through additional fields on the page customization override. The fields are referred to as the dimension fields and they logically work as follows:

If the dimension field specified has the value as specified in the dimension field value then apply the override, otherwise, the override is ignored.

Following through with the example described above, if the description should only be required for Projects of a specific type (e.g., Category Project), then the dimension fields would be set as follows:

Dimension Field: DOC_TYPE

Dimension Field Type: Project Type

DImension Field Value: Category Project

Page customization overrides that are implemented with dimensions provide a lot of configurability in E-Sourcing and CLM. There are two important considerations that must be taken into account when implementing overrides using dimensions. The first consideration is that page customization overrides are applied when a document is entered and not applied again until the document is re-entered. This means that clicking save on the document will not re-apply the page customizations. I point this out because a common question I have heard is: could the page customization override dimension field be a value list value field and when the user changes the value in the drop down, could another field be hidden or made required. Unfortunately, this will not work well because changing the value list value will not refresh the page customization overrides. The second consideration is in the way the system process page customization overrides. They are processed in the order that the exist in the page customization object and as soon as an override is “found” for a particular field and property, it is applied. This means that the dimension field overrides must precede the non-dimensioned overrides so that they will be applied correctly.

An exmple of the above may be necessary to ensure it is clear. Suppose that the system has ten Project Types configured and there is an extension field named IT Project Type that only applies to projects that are of type IT Project. The requirement might be that the extension field should only be visible on the IT Project Types. This would be accomplished with two page customization overrides on the Project module: the first override would indicate that the IT Project Type field has the hidden property set to no when dimension field DOC_TYPE is set to IT Project Type. The second override would indicate that the IT Project Type field has the hidden property set to yes (no dimensions are required here). These two overrides would implement the requirement stated above.

As I mentioned above, page customizations are a very nice feature of E-Sourcing / CLM. They provide for a lot of powerful configurations to be made, yet require careful setup to ensure proper operation.

In a future posting, I will describe how scripting and hidden extension fields can help you do even more with page customizations.

Good luck!

SAP E-Sourcing / CLM is well known for its flexibility and configuration capabilities. Examples of this flexibility include the ease with which new fields can be added to the system and the ability to configure the user interface with different field labels and layouts. There is another fantastic feature of E-Sourcing that many customers use to advance their use of E-Sourcing: User Defined Business Objects.

User Defined Business Objects (UDOs) allow system administrators to configure an entirely new business object. They include all of the major features of E-Sourcing business documents including the document type / template creation model, configurable phase definitions, workflow, and user collaboration. Customers have found many uses for user defined business objects, but the two most common that I have seen are: a repository for non-disclosure agreements and a sourcing request (a way to capture request for sourcing from business users).

A base installation and setup of E-Sourcing does not come with UDOs enabled. UDOs are enabled via system properties that are set by the system user. There is a single property that turns them on and separate system properties that enable each of the five configurable UDOs. There are system properties for both purchaser side and supplier side enablement (UDOs are able to be seen by suppliers in addition to buyers if the requirements dictate such).

System Properties to enable UDOs (click to enlarge)

Once the system properties are enabled, UDOs are available for use in the system. However, E-Sourcing does not come with any security profiles that provide access to the UDOs; as a result, adjustments to the relevant security profiles are required to provide the appropriate access to the UDOs and the associated setup objects (document types and configurable phase definitions).

Security Profile configuration for UDOs (click to enlarge)

With the system properties set and the security profile settings established, a new navigation menu option will exist for UDOs. In the following image, only one of the five UDOs is enabled, but it does show how the common business document functionality is immediately available for the UDO:

Navigation Bar with UDO 1 Enabled (click to enlarge)

E-Sourcing provides a basic set of tabs and data that can be used on a UDO. Obviously, the real power is achieved by adjusting the layout through page customizations and adding new fields via extension definitions. Also, for UDOs, it is important to update the localized resources so that terms such as ”User Defined BizDoc” are changed to the appropriate term based on the configuration.

Default Configuration of a UDO (click to enlarge)

As you can see, there is a lot of functionality provided by the system without any configuration. However, the real power of UDOs is achieved through the inherent E-Sourcing flexibility that enables custom fields and user interface adjustments using the extension definition and page customization capabilities in setup.

To review, the key things to do when adding UDO functionality to an implementation are:

- Enable UDOs using system properties

- Update the appropriate security profiles with the necessary access rights

- Update the appropriate localized resources to reflect the true use of the UDO

- Add the necessary extensions and page customizations for the business functionality required

- Create the appropriate Document Types

- Create the appropriate Phase Configurations

- Add Workflow (if required)

In a future posting, I will look at a real  UDO example. In the mean time, I hope you found this information useful.