Skip to Content

SAP Business ByDesign Customization Use-Case: Approved Supplier Lists for Medical Device Manufacturer

While SAP Business ByDesign has an extraordinary array of out-of-the-box functionality in both breadth and depth, there will always be customer-specific scenarios and use-cases that are not natively handled entirely through standard functionality. Though most ERP systems allow customization to handle these scenarios, what sets Business ByDesign apart is the ability to quickly and easily create custom functionality that can be an integral part of standard processes.

See also: Customizing SAP Business ByDesign to Your Needs

As an example, we will walk through a use-case that we encountered for a medical device manufacturer. Compliance requirements associated with the manufacture of medical devices created the need to manage the procurement of materials and services used in the manufacturing process. Materials used in the manufacture of the devices and the services from third parties involved in the manufacturing process needed to be regulated to ensure that only approved suppliers could supply approved products.

Note that this is intended to provide an example of one approach used to fulfill requirements – your circumstances may be different, and variations to this process are definitely possible.

Before the creation of the customization, this data was managed in Excel and through strict oversight by employees involved in the manufacturing and purchasing processes. Despite this, with any process reliant on human input for validation, the possibility for human error occurs. To greatly reduce the likelihood of errors, the company wanted to utilize SAP Business ByDesignto manage the procurement and manufacturing processes.

The customization contains a custom Approved Supplier List Business Object to store and manage the custom data, an extension to the standard Purchase Order Business Object to execute the validation and store the result, an XML Integration to allow mass-data load and maintenance of the custom functionality and the associated user interface components. Within this blog, I’ll include “How It Works” tips to provide information on how the functionality is actually created.

The User Interface and Custom Business Object

Within the SAP Business ByDesign system itself, we immediately see that our custom Work Center “Approved Supplier Lists” is added amongst all the other standard Work Centers and can be interacted with in a manner indistinguishable from the standard user interface. To an end user, it should appear as if any of the custom functionality is just another standard out-of-the-box module.

How It Works: Assignment of custom Work Centers works in the same way as assignment of standard Work Centers. This means that you can restrict access to your custom functionality by user, in the same manner that you’d restrict access to standard functionality. This is especially important in this scenario due to the strict requirements related to who is allowed to add or update this data.

Within the Work Center, this is a Work List to view existing Approved Supplier Lists and associated data, which can be sorted and filtered like any other standard Work List. We can manually add new Approved Supplier List objects through the user interface using the “New” button, or use the “Edit” button to update existing objects. We can mass-upload this data as well, which we’ll explore later.

Approved Supplier List

How It Works: the basic UI screens are created through the standard “Floor plan with Navigation” option, which will create most of your screens automatically. You can then adjust and refine the generated screens, which saves a tremendous amount of time over trying to build them from scratch. You’ll want to wait until you’ve gotten your associated Business Object built out to the extent you can, as the generated screens will include all the elements and actions that were present at the time. If you add additional elements, you’ll need to go to the screens and add them back in.

Approved Supplier List

When we open an existing Approved Supplier List, we can see a screen that looks and feels identical to standard Business ByDesign screens. Within the screen, we see the relevant information for the Approved Supplier List we opened. You’ll notice that the Supplier ID is read-only – users are prevented from changing it after the list has been initially set up.

How It Works: the read-only property of the field is set to “Advanced” to allow a script to determine the property value. The script retrieves based on a hidden indicator which is set when the Approved Supplier List is saved with valid data for the first time. This means that one element of a Business Object can control user interaction with other elements.

Multiple Approved Supplier Lists for the same Supplier are automatically prevented through an annotation in the Business Object itself. How It Works: the [AlternativeKey] annotation automatically prevents multiple Approved Supplier Lists for the same Supplier to be saved. If an ID is entered which is present on an existing Approved Supplier List, it will raise an error and prevent data from being saved – there’s no additional coding required to enable this behavior.


Below the Supplier ID and Name, there is a “Qualified Supplier” checkbox. If an Approved Supplier List expires or is no longer valid, it can be changed at the entire-list level.

Within the Approved Supplier List, a table of Approved Products appears. Both Material- and Service-type products can be added. Additionally, the Value Helper will distinguish between the “Product Type” and suggest only relevant products. This means that if Product Type “Service” is selected, only Services will be suggested when the user begins to type in the Product ID or when the user clicks the Value Selector icon.

How It Works: when you change a field type to “Value Selector”, you can still configure the public Object Value Selector that you use. As part of this, you can bind a field as an input parameter for the OVS query. The Product Type you see in the user interface is passed as the value to the Product Type parameter of the query. You can do this with multiple input parameters as well, depending on what is supported by the Object Value Selector used.

Pictured below is another example of an Approved Supplier List – in this case, for a Service-type product. Note that “…Changed On” elements are present to allow visibility into the control process behind the maintenance of the lists.

Approved Supplier List

Extensibility of Purchase Orders

We will now explore how the custom functionality integrates with the standard Purchase Order functionality. As we can see, a Purchase Order is created for one of our Approved Suppliers. All the user actions performed for a Purchase Order use the standard screens and processes.

New Purchase Order

Within the standard Purchase Order screen, we see that there’s a new field in the Item table – “ASL Status”. This status displays one of multiple possible statuses related to the validity of the product for purchase from the particular Supplier. As shown below, the Service pictured has the status of “ASL Check Successful”, which means it’s allowable for Purchase.

However, you can see that there are also two materials on the Purchase Order, one ordered To-Stock and one ordered as Non-Stock. For the first To-Stock material, we see the status Product Not Found on ASL, which is one of the status which will prevent us from issuing this Purchase Order. For this particular customer-specific customization, it was requested that Non-Stock Materials (used for internal testing) would not be subject to Approved Supplier List restrictions, so we can see that the second material has a status which indicates that the line on the Purchase Order is allowable, as the Approved Supplier List restrictions are not relevant.

How It Works: “ASL Status” is an element as part of a Business Object Extension, which is used to enhance the functionality of a standard Business Object through the new data elements, the presence of these data elements on standard screens, and additional scripts that can be run when standard Business Objects are modified. “ASL Status” is a custom data-type, which contains a defined list of codes and their related values (the descriptions shown below). The value of this field is controlled by custom code within the Business Object Extension that is run when the Purchase Order Item node is modified.

ASL Status

It’s important to use code-list data types to ensure that the values in the field are kept consistent. Additionally, it is best practices to use a code-list data type to display text or descriptions, as it allows for the ability to easily translate the Description text into other display languages. What this means is that this customization could be developed in English, then translated and used by non-English-speaking users. The ability to export the original and upload translated values is a standard part of the Cloud Applications Studio.


The user will go through the Purchase Order and fill in the relevant information (though in reality the user should stop before this, as they would have noticed that one of the Products cannot be ordered on the Purchase Order).

However, when the user goes to Release the Order, the user is actually stopped and an error message appears. As one of the Line Items violates the Approved Supplier List validity checks, the user is prevented from executing the “Release” action on the Purchase Order.

How It Works: In addition to the code that determines the “ASL Status”, code is added as an “Action Validation” on the standard “Release” action. “Action Validations” are used to allow customer-specific controls to be placed that can prevent standard actions from being executed. In this case, Release is not allowed if the ASL Status is not “Successful” and not one of the “Not Relevant” type statuses.

ASL Status Action Validation

One extremely valuable component of the customization is that the custom code being performed is related to the Purchase Order Business Object itself (through the Business Object Extension). The association of code with the Business Object (as opposed to screen or transaction) ensures that these validations are used regardless of the method that the transaction is managed – these checks will be performed regardless of whether the data is managed through the User Interface, web service integration from external systems, the upload of data from Excel, or XML integrations used to load data. This is critical for the integrity of data – no matter where the data is managed, it will always be subject to the same checks and validations without the need to deploy code or maintain code in multiple system locations.

In addition to simply allowing or not allowing a Purchase Order to be released, it’s important to give users insight into why, so if data needs to be updated, users can know what to change or request changes to.

For example, if a user tries to create a Purchase Order for a Supplier that has not yet been set up as an Approved Supplier List.

Approved Supplier List

As we can see here, the status tells me that this Supplier has yet to be set up within the Approved Supplier Lists.

Approved Supplier List

How It Works: an example code snippet from the script that determines this data – for example, if the query to retrieve the Approved Supplier List data does not return any results, then the status indicates that no Approved Supplier List was found.

Approved Supplier List Script

Additionally, we see the purpose of the “Qualified” indicator at both the Approved Supplier List Root and Item level – users can disqualify an Item on the Approved Supplier List without having to remove it from the list completely.

Approved Supplier List Root and Item Level

Similar to Item disqualification, the entire Approved Supplier List can be disqualified without having to go through item-by-item. This may be necessary, as Suppliers may only be temporarily disqualified – by enabling a disqualification at the root level, upon requalification the list can be resumed from the last point of qualification.

Approved Supplier List

Below, we see the associated ASL Status which tells the user that, while the Approved Supplier List exists, the Supplier is not qualified.

ASL Status

How It Works: The ASL Status is determined by a set of queries that starts at a broad level, then gradually becomes more detailed. If the script cannot progress any further (for example, due to lack of results or disqualified suppliers or items in the results), based on the point it stops, a status is determined. Pictured below are two reasons that the script would return an irrelevant or not-allowable status.

An ASL is Found

To simplify the process, a “Reuse” Library can be created within the custom solution. This means that functions can be created with input and output data that can be reused elsewhere. For example, while this currently only effects the Purchase Orders, this functionality could easily be added to Purchase Requests or Supplier Invoices.

Library Functions CheckItem

Custom Change Log

Also included is a simplified, but highly necessary function – a basic Change log. Not to be confused with the system standard Change Logs (which automatically track this information and can be added through an embedded component for any custom Business Object), the intention of this log is to simplify the reporting of changes over time across the entire array of Approved Product Sales lists. This is used to meet auditing requirements, with the elements that are changed, from / to values and the date and time of changes.

More important than just being able to see a list of changes, this data can be used within the standard SAP Business ByDesign reporting engine to produce audit reports with data from all the Approved Supplier Lists.

How It Works: by using the AfterLoading events (only usable with custom Business Objects) and elements with the [transient] annotation, the value when an Approved Supplier List is entered can be compared to the value when it is saved. If these are different, an entry is added to the Approved Supplier List Changes node. Additionally, a custom Data Source can be created based on any “node” of the object. As the “Changes” are a node within the Approved Supplier List Business Object, it can be used to create a Data Source that contains information from all instances for this node within all the Approved Supplier Lists. Once the custom Data Source is created, it can be joined to existing Data Sources, or other custom Data Sources.

Approved Supplier List Business Object - "Changes"

Data Import and Update

As mentioned above, there are ways of importing data to simplify the process of initial data population or ongoing maintenance. An Excel file was created to allow users to create the set of Suppliers and associated Products. For example, to create the lists used in this example, the file would be populated as pictured below.

Approved Supplier Lists

Approved Products

Upon click of a button linked to a simple Excel macro, the macro that generates an XML file would run and produce a file, such as the one pictured below with the “.xml” extension.

Excel Macro ASL XML File

The contents of the file would be in a common XML structure, as determined by the XSD produced from the SAP Business ByDesign file input. This means that, in addition to the use of Excel, any system that can produce data in the necessary XML format can be used to generate the files for use in import.

Approved Supplier List XML Format

This file could then be uploaded into the standard “Application and User Management” -> “File Input” interface, and processed through use of a scheduled run.

File Input Runs

Additionally, data upload can occur through making the WebDAV location available as a network drive as pictured below, or through external messages. This means that, once created, the mass management of data can be done by users without the need for further partner involvement.

Direct File Access (WebDAV)

Final Notes

As we can see, this customization, while fairly simple in scope, provides highly important functionality to managing the procurement process related to oversight, compliance and audit.

As with any customer-specific enhancement, the design is intended to be truly customer-specific – the scope and complexity of the custom data that can be managed within SAP Business ByDesign is nearly limitless, and made simple through use of the standard ByDesign development functionality, which can:

  1. Provide a familiar user interface to manage data
  2. Add extensions to standard functionality to incorporate your data in the out-of-the-box screens and processes
  3. Integrate with external sources or systems to synchronize create, update, and synchronize data
  4. Report on custom data to provide valuable oversight and analytics

Whether you have similar requirements or something completely different, FMT Consultants is here to help you get the most out of your SAP Business ByDesign system – as we’ve seen time and time again, a small enhancement can make a big difference – so don’t hesitate to ask whether we can help you too.

Contact FMT Consultants to learn more about SAP Business ByDesign

Written by: Dan Edelman, Senior SAP Business ByDesign Consultant FMT Consultants 

Be the first to leave a comment
You must be Logged on to comment or reply to a post.