Understanding the class structure and their relationships

The below image represents the big picture of SAP Ariba applications on a functional level, with the main components and connections, including external systems. SAP Ariba offers two types of solutions called Sourcing and Procurement. These solutions include SAP Ariba, SAP Ariba Buying and Invoicing and SAP Ariba Invoice Management.

The Sourcing solutions cover what is sometimes called strategic procurement. This includes collaborative sourcing (finding suppliers for a given need), collaborative contract management, supplier lifecycle and performance, and spend analysis. The Sourcing solutions are sometimes referred to as Shared Services Strategic Sourcing (S4).

The Procurement solutions cover the operational procurement processes. This includes, managing buyer catalogs, creation, and approval of purchase requisitions, creating, and sending purchase orders, receiving items, and invoice reconciliation and approval. The Procurement solutions are sometimes referred to as Shared Services Procurement (SSP).

Those who use both Sourcing and Procurement solutions can access functions from both areas from one integrated dashboard User Interface. Depending on the purchased solutions and on the user’s permissions, different Sourcing functions such as sourcing, supplier management, and procurement, appear as tabs in the dashboard. To enable the integration, data is synchronized between the Sourcing and Procurement applications. One example of such data is supplier data, which is stored in the databases of both the Sourcing and the Procurement applications.

A Java class is essentially a blueprint from which individual Java objects are created. A Java class contains attributes and methods that are common to all objects of one type.

Let's use a dog as an example. A dog is a representation of a class. Its attributes are breed, size, age, and color. Its methods or behaviors include eat, sleep, sit, and run.

In Java, an object is an instance of a class. Your dog would be an instance of a class. Your neighbor's dog would be a different instance.

A hierarchy defines the inheritance relationship between classes. Inheritance means all child classes, also referred to as subclasses, get all the attributes and behaviors from the parent class, also referred to as superclass. Every class except for BaseObject, the root class of SAP Ariba class hierarchy, has a superclass. Each class inherits fields, triggers, etc. from its superclass. Subclasses can override field properties for fields inherited from the superclass.

The below images represent portions of the Class hierarchy in SAP Ariba Solutions.

Classes in blue are not customizable, classes in yellow are customizable.

Commonly customized parent classes in Procurement include the following:

• ProcureLineItemCollection
• ProcureLineItem
• Accounting
• StagedReceiptLineItem - Staged Receipt Line Item (For custom fields to be added to GR import)
• LineItemProductDescription - General Line Item descriptions
• PurchaseOrder – applicable on Orders sent to ERP as well as Copy Orders synchronized from SAP Business Network to Ariba Procurement solutions.

Classes in blue are not customizable, classes in yellow are customizable.

Commonly customized parent classes in Sourcing include the following:

• AbstractContractWorkspace - Customizations applied here appear in all types of Contract Workspaces and Requests
• ContractWorkspace - Customizations applied here appear in Contract Workspace (Procurement) and Contract Request (Procurement)
• SalesContractWorkspace - Customizations applied here appear in Contract Workspace (Sales) and Contract Request (Sales)
• SourcingProject - Customizations applied here appear in Sourcing Projects and Sourcing Requests
• ServicesProcurementWorkspace - Customizations applied here appear in Procurement Workspaces and Procurement Workspace Requests

While Customizing, make note of the below implications:

• Field properties are inherited from superclasses. For example, if you are editing a field on ReqLineItem, you can add any field property that also exists in the superclass (parent) of ProcureLineItem, ProcureLineItem's superclass, etc.
• Keep in mind that fields used in an object (i.e. ReqLineItem) often are defined at various levels of classes in the hierarchy. For example, if I create a custom field at the ProcureLineItem class, this custom field will then appear in all subclasses of ProcureLineItem (ReqLineItem, POLineItem, etc). I can still edit the field at a specific subclass (i.e. ReqLineItem) and override the behavior by adding or removing additional field templates, conditions, etc.
• When creating/editing a custom field or editing a Standard field, consider the class where that field is defined and whether you should be editing it at the class where it is defined or overriding the field at a subclass. The answer depends on what the business case requires.