Ariba Guided Buying: Configuring and Managing Landing Pages & Procurement Policies

[ajaypakhale]

SAP Ariba Guided Buying

Guided buying is a persona-based application that integrates with SAP Ariba Buying. With Guided Buying, users outside the professional procurement group have one place to search for goods and services, making purchases with little to no involvement from procurement departments. Guided buying captures organization's purchasing policies and uses them to guide casual users and functional buyers to the outcomes they need.

Guided buying is a built-in capability available at no additional cost to customers, using the SAP Ariba Buying and SAP Ariba Buying and Invoicing solutions. It provides a smart, easy, and intuitive user interface for employees to create any type of procurement request. These actions can include buying, contracting, sourcing, and making services and non-catalog requests, as well as other types of requests.

Users know right away when a policy is violated, rather than finding out after submitting a request. Depending on rules, users might proceed with the exception or make an alternate decision that doesn't violate the policy.

Guided buying also lets users collaborate in context with the right procurement experts. Based on what the user is buying and where the user is located, guided buying gives instant access to the category expert in that user's purchasing unit.

In addition, the integration with SAP Ariba Sourcing allows users to request quotes from suppliers via Ariba Network as well as select preferred suppliers when creating ad-hoc requests.

THE VALUE PROPOSITION FOR GUIDED BUYING

Guided buying generates value to customers using SAP Ariba solutions in many ways. Most notably, it:
1. Increases user adoption of SAP Ariba Procurement solutions dramatically
2. Provides users with a single gateway to complete any procurement request
3. Increases compliant spend using smart guidance to steer users to the right item and to
preferred suppliers, and helps ensure they work within contractual and corporate policies
4. Simplifies procurement operations by making low-dollar, high-volume requests completely self-
service
5. Increases savings by driving more spend through three bids and a buy, allowing self-service
collaboration with suppliers for tactical spend

Guided Buying: Process Flow (with RFQ)

                                         Figure 1: Process Flow With RFQ

 

SAP S/4HANA Cloud Integration

Guided Buying can optionally integrated with SAP S/4HANA Cloud

Users launch guided buying from organization's intranet, such as from enterprise employee portal or a tile in SAP Fiori. In guided buying, they shop for items and add them to their shopping cart. When they check out, guided buying uses data from SAP S/4HANA Cloud to validate the request. It receives real-time master data from SAP S/4HANA Cloud, so it can check all information, such as business unit, ship-to address, commodity code, and supplier.

Guided buying routes the request to other users for approval. It then sends the validated, approved request to SAP S/4HANA Cloud.

SAP S/4HANA Cloud receives the request and processes it as if it were generated natively. For example, it accumulates spend against the user’s departmental budget and performs checks against business rules. It converts the request to a purchase order, either automatically or manually through the actions of a purchasing professional. It then sends the PO to the supplier through any available method, including through Ariba Network.

Figure 2: S/4 HANA Cloud Integration Option Process Flow

Guided Buying: Features

Operational sourcing:

To allow users to request quotes from suppliers through guided buying, this is limited sourcing functionality to create sourcing templates specific to guided buying.

• Self-service only: Operational sourcing (doesn't require an SAP Ariba Sourcing subscription)


• Self-service, low touch, and high touch: Requires SAP Ariba Sourcing

Supplier database:

• Manage qualified and preferred suppliers.

Forms:

• Design forms to guide users through complex purchases.

Private help community:

Provide targeted help content to users, and collaborate more efficiently in the purchasing process.

Prerequisites:

Two separate web addresses to control access to guided buying:

1. Guided buying web address: Users who make purchases through guided buying and administrators who configure guided buying.


2. The web address for buying solution: To login directly to Ariba Buying solution.

Objective of this blog is to introduce SAP Ariba consultants, detailed aspects of configuring and managing Landing Page and Procurement Policies.

This blog is divided into two sections:

1. Guided Buying: Landing Page


2. Procurement Policies

Section 1: Guided Buying - Landing Page

Landing Pages are created to make the buying process easier for casual users and for functional buyers who make purchases in specific categories, such as marketing, facilities, or IT. Guided buying supports four hierarchy levels for landing pages.

A landing page contains clickable tiles for navigating through the catalog. After logging into guided buying, users see an initial landing page call the ‘home landing page’. This page can be customized and addition ones to show different categories with images. For optimum usability, display up to 9-12 tiles on landing pages, including the home page.

Landing pages provide a curated buying experience at the category, sub-category, or commodity level.

Figure 3: Guided Buying Landing Page

User Search Experience

The user searches for "workspace setup" in guided buying, which shows facilities landing page. This landing page shows facilities services that are specific to the user's location.

Figure 4: Search Result

Creating Landing Pages

Access Menu: Admin --> Landing Pages

Three options are available:

• Manage Using JSON


• Manage Using Excel


• Manage Using UI

Figure 5: Landing Pages - Configuration Options

Using JSON: Maintain landing pages in a JSON file. Useful for people who are more technical and who want to see one text file with all the landing page information.

Using Excel: Useful for moving large numbers of landing pages and tiles from your test site to your production site.


Using UI:Maintain landing pages in an easy-to-use interface. Recommended for most users.

In this blog, I will explain configuring options using Excel and UI.

Landing Page Configuration – Excel Sheet

Figure 6: Landing Pages Configuration - Excel Upload

Excel template contains three sheets: Manage Your Pages, Content & Instructions.

‘Manage Your Pages’ Sheet: This sheet defines organization’s landing pages & home pages. Each Purchasing Unit has its own home page which is displayed when users login. Tiles on a home page are called landing page, and landing pages are main categories which contain everything.

Requirements:

• Home & Landing pages must have a valid Purchasing Unit.


• Each Purchasing Unit can have only one home page.


• Landing pages can belong to a Parent Home Page ID only if one of the following is true:

1. Purchasing Unit of landing page is same as of Parent Home Page.


2. Purchasing Unit of landing page is a child of Purchasing Unit of its Parent Home Page & it can’t have it’s own home page.

Figure 7: Excel Template - Manage Your Pages

‘Content’ Sheet: Use this sheet to add new tiles, such as pages, catalogs items, and forms to the landing pages.

Figure 8: Excel Template - Content

Landing Page Configuration – Landing Page Designer: UI

Configuration option from User Interface (UI) has following options:

• Click Admin Home to view all the sets of landing pages.


• Click the back arrow to return to the previous view.


• If organization uses purchasing units and has multiple sets of landing pages, use the purchasing unit drop-down to select different sets of landing pages.


• Click Exit to return to the guided buying administration page.

Figure 9: Landing Page Designer - UI: Options

To add a new set of landing pages for a particular purchasing unit or for all purchasing units, click Add new set.

Figure 10: Landing Page Designer - UI: Adding New Page

To edit the content for the Policy, Guidance, or Contacts sections at the bottom of the home landing page, click the pencil icon and then use the rich-text editor to enter and format text or links for those sections.

Figure 11: Landing Page Designer - UI: Editing Contents

To add a tile to a landing page:

• Click Add new tile.


• From the Create new tile panel, choose one of the tile types.


• Fill in any required attribute fields that appear (for example, Target url is required for the External Site tile type).


• Click Create.

Figure 12: Landing Page Designer - UI: Adding Tile 1

Figure 13: Landing Page Designer - UI: Adding Tile 2

To edit the tile, click the pencil icon

Figure 14: Landing Page Designer - UI: Editing Tile 1

After editing the tile, save the changes.

Figure 15: Landing Page Designer - UI: Editing Tile 2

Section 2: Procurement Policies

The smart-policy engine allows to define rules that users must follow when buying online in order to comply with an organization policies. Policy alerts are embedded into the purchasing experience so users don’t need to know or remember the policies. A policy will appear in the context of purchasing if a policy has been violated or, preemptively, to remind the purchaser that a justification is needed. For example, a policy could be this: “Require a justification for purchases of IT equipment.”

Policies can also support users in the process of requesting quotes from suppliers (also known as tactical sourcing). Depending on the spend category and purchase volume, procurement can use policies to guide users on what they should do. An example of a supplier policy could be this: “The purchase of IT equipment requires three quotes from preferred suppliers for products costing
US$5,000 or more, and one quote from preferred suppliers for products costing less than US$5,000".

Procurement Policies – Types of Policies

1. Validation Policy: Configure validation policies to make sure users follow internal procedures when making purchases.


2. Supplier Selection Policies: Configure supplier selection policies to narrow the pool of suppliers available for selection in forms, based on attributes such as form type, amount, purchasing unit, commodity code, and preferred supplier level.


3. Supplier and Touch Policies: Configure supplier and touch policies (N bids and a buy policies) to determine how much procurement department involvement is necessary for purchases where users are requesting quotes from suppliers through the RFQ process.


4. Checkout Section Generation Policies: Configure checkout section generation policies to dynamically determine which fields display in the Checkout page and to enable a simplified user interface and mass editing.

Procurement Policies – Configuring Policies

Configure policies to make sure users follow internal procedures when making purchases.

By having a single starting point for all organization's purchases, organizations can load and enforce one set of validation policies. These policies ensure consistent compliance for all purchases and help users understand the right process to follow for any purchase. These built-in policies decrease the need for users to read procurement manuals, and they free up procurement department to focus on high-value procurement activities.

organizations can configure policy errors and warnings related to different scenarios that occur during the creation of a request. Warnings and errors are messages that inform users about a policy violation. With warnings, organizations can give users the opportunity either to provide a custom justification or to choose from a predefined list of justification reasons. With errors, users can't submit the request until they fix the violation.

Limitations

If multiple validation policies apply to the same request line item, the request checkout page shows only one validation policy to users for that line item.

Access Menu: Admin --> Policies --> Manage Policies

Figure 16: Manage Procurement Policies

Figure 17: Policy Management - 1

Figure 18: Policy Management - 2

Policy Management – Importing Policies

In the Policy section on the Policy Management page, click Import Policy and browse for policy file. And click Upload to import the file.

When new policies are uploaded, guided buying creates new data and updates existing data. To delete an existing validation policy, click the trash icon to the right of the policy on the Policy Management page.

Any newly created requests are subject to organization’s policies. Anything that was already submitted is not affected.

Load a file in Excel (XLS or XLSX) format to configure validation policies. The policies go into effect immediately after loading the configuration file.

Policy Management – Validation Policies

Validation Policy: Configure validation policies to make sure users follow internal procedures when making purchases.

Load a file in Excel (XLS or XLSX) format to configure validation policies. The policies go into effect immediately after loading the configuration file.

Excel file contains 4 sheets: Description, Key Definition, Expression & Message.

Sheet 1 -  Description: This contains columns

1. Policy Name: Name of purchasing policy. This should not be more that 256 characters.


2. Policy Description: A description for policy. This should make up to 256 characters.

Figure 19: Validation Policy - Description Sheet

Sheet 2 -  Key Definition: This contains columns

1. Policy Name: The name of purchasing policy. This needs to match a policy name from the Description sheet.


2. Lookup Key: Describes which users the policy applies to. At the moment, ProcurementUnit is the only supported value.


3. Lookup Key Value: The purchasing unit name that is affected by the policy.

Figure 20: Validation Policy - Key Definition Sheet

Sheet 3 -  Expression: This contains columns

1. Policy Name: The name of purchasing policy. This needs to match a policy name from the Description sheet.


2. Left hand side Type: At this time, field is the only supported value.


3. Left hand side Field: A determinant for when to trigger a policy. This column uses the database field name for fields at the request header and line levels (Requisition and ReqLineItem field classes in SAP Ariba) and supports dotted notation fields. Custom fields are also supported.


4. Right hand side Type: At this time, constant is the only supported value.


5. Right hand side Field: The ID value for whichever Left hand side Field is specified. The value configured for this column is compared to the field value on the request.


6. Operator: Describes operators that evaluate whether to enforce a policy. Valid operators for the amount-based fields are - < (is less than), > (is greater than), == (is equal to), != (is not equal to), <= (is less than or equal to), >= (is greater than or equal to).


7. Logical Operator: Describes how to evaluate multiple rows in the file for the same policy name. Valid values are: 1. && (and): The next row for the same policy is also required to trigger the policy. 2. || (or): Either the current row or the next row for the same policy is required to trigger the policy.

Figure 21: Validation Policy - Expression Sheet

Sheet 4 -  Message: This contains columns

1. Policy Name: The name of purchasing policy. This needs to match a policy name from the Description sheet.


2. Severity: Describes what guided buying should do when a user violates a policy. Valid values are: 1. Info: Shows an informational message about an item. 2. Justification: Asks users to provide an optional justification for purchasing an item. 3. Error: Prevents users from submitting the request.


3. Message: Specifies the message you want to show to users when enforcing a policy. At this time, guided buying doesn't support translating these validation messages into multiple languages.


4. Justification Options: When you specify Justification for the Severity column, there are two options:

1. To allow users to fill in a custom justification reason, leave this column blank.

2. To offer a list of predefined reasons to users enter a comma-separated list of the reasons
for the Justification Options column.

Figure 22: Validation Policy - Message Sheet

Policy Management – Supplier Selection Policies

Supplier Selection Policy: Configure supplier selection policies to narrow the pool of suppliers available for selection in forms, based on attributes such as form type, amount, purchasing unit, commodity code, and preferred supplier level.

Upload a file in Excel (XLS or XLSX) format to configure supplier selection policies. The policies go into effect immediately after uploading the configuration file.

Excel file contains 5 sheets: Description, Key Definition, Expression, Config & Filter Criteria.

Sheet 1 -  Description: This contains columns

1. Policy Name: Name of purchasing policy. This should not be more that 256 characters.


2. Policy Description: A description for policy. This should make up to 256 characters.

Figure 23: Supplier Selection Policy - Description sheet

Sheet 2 -  Key Definition: This contains columns

1. Policy Name: The name of purchasing policy. This needs to match a policy name from the Description sheet.


2. Lookup Key: Describes which users the policy applies to. The supported values are location and commodityCode, which represent the purchasing unit of the user and the commodity code associated with the form.


3. Lookup Key Value: The purchasing unit ID or commodity code ID that is affected by the policy.

Figure 24: Supplier Selection Policy - Key Definition sheet

Sheet 3 -  Expression: This contains columns

1. Policy Name: The name of purchasing policy. This needs to match a policy name from the Description sheet.


2. Form Type: The type of form affected by the policy. The supported values are Form (request form) and ReqForm (customized ad hoc request form).


3. Expression Name: Any name to be used to define a selection policy expression.


4. Left hand side Type: At this time, field is the only supported value.


5. Left hand side Field: A determinant for when to trigger a policy. The value price and form attributes, such as the user's first and last name (Form.First Name and Form.Last Name), are the supported values. The value price refers to the total amount of the request form.


6. Right hand side Type: At this time, constant is the only supported value.


7. Right hand side Field: Enter one of: 1. For the price attribute, enter the monetary amount entered on the request form. 2. For other form attributes, enter the text for that attribute that triggers the policy.


8. Operator: Describes operators that evaluate whether to enforce a policy. Valid operators for the amount-based fields are - < (is less than), > (is greater than), == (is equal to), != (is not equal to), <= (is less than or equal to), >= (is greater than or equal to).


9. Logical Operator: Describes how to evaluate multiple rows in the file for the same policy name. Valid values are - && (and): The next row for the same policy is also required to trigger the policy. || (or): Either the current row or the next row for the same policy is required to trigger the policy.

Figure 25: Supplier Selection Policy - Expression sheet

Sheet 4 -  Config: This contains columns

1. Policy Name: The name of purchasing policy. This needs to match a policy name from the Description sheet.


2. Expression Name: The name of a particular selection policy expression.


3. Supplier Chooser Template: Only the allow all suppliers template is supported. Users can choose from the full list of suppliers on forms associated with the policy expression.

Figure 26: Supplier Selection Policy - Config sheet

Sheet 5 -  Filter Criteria: This contains columns

1. Policy Name: The name of purchasing policy. This needs to match a policy name from the Description sheet.


2. Expression Name: The name of a particular selection policy expression.


3. Supplier Attribute Name: Only the attribute Suppliers.PreferredLevel is supported.


4. Field Value Operator: Determines how to narrow the pool of suppliers for the commodity and location to a smaller set, based on preferred supplier level. Valid operators are: IN (includes at least one value from): Supplier Attribute Name includes at least one value from Field Value List. NOT IN (includes no values from): Supplier Attribute Name includes no values from Field Value List.


5. Field Value Type: Only the values constant and field are the supported.


6. Field Value List: For constant, enter a comma-separated list (no spaces) that identifies the preferred supplier level to show on the form. For field, enter a field path on the form that contains values related to the preferred supplier level.

Figure 27: Supplier Selection Policy - Filter Criteria sheet

Policy Management – Supplier and Touch Policies

Supplier and Touch Policy: configure supplier and touch policies (N bids and a buy policies) to determine how much procurement department involvement is necessary for purchases where users are requesting quotes from suppliers through the RFQ process.

Following categories supported for supplier and touch policies:

1. Self-service policy: Quote requests don't require any procurement department involvement.


2. Low-touch policy: Quote requests require a small degree of procurement department involvement.


3. High-touch policy/sourcing request policy: Quote requests require a high degree of procurement department involvement.

Upload a file in Excel (XLS or XLSX) format to configure supplier and touch policies. The policies go into effect immediately after uploading the configuration file.

Excel file contains 5 sheets: Description, Key Definition, Tier Definition, Template Configuration & Message.

Sheet 1 -  Description: This contains columns

1. Policy Name: Name of purchasing policy. This should not be more that 256 characters.


2. Policy Description: A description for policy. This should make up to 256 characters.

Figure 28: Supplier & Touch Policy - Description sheet

Sheet 2 -  Key Definition: This contains columns

1. Policy Name: The name of purchasing policy. This needs to match a policy name from the Description sheet.


2. Lookup Key: Describes which users the policy applies to. At the moment, the supported values are location and commodityCode, which represent the purchasing unit of the request and the commodity code of the requested item.


3. Lookup Key Value: The purchasing unit ID or commodity code ID that is affected by the policy.

Figure 29: Supplier & Touch Policy - Key Definition sheet

Sheet 3 -  Tier Definition: This contains columns

1. Policy Name: The name of purchasing policy. This needs to match a policy name from the Description sheet.


2. Tier Name: The name use to define a particular amount-based tier for a policy.


3. Phase: The part of the process to which policy applies. Supported values are Request Quotes and Accept Quotes.


4. Left hand side Type: At this time, field is the only supported value.


5. Left hand side Field: A determinant for when to trigger a policy. Two possible values are:1. price (the total monetary amount of the request form). 2. The total number of preferred suppliers chosen on the request form, such as Suppliers.PreferredLevel.


6. Right hand side Type: At this time, constant is the only supported value.


7. Right hand side Field: The ID value for whichever Left hand side Field is specified. The value is configured for this column is compared to the field value on the request.


8. Operator: Describes operators that evaluate whether to enforce a policy. Valid operators for the amount-based fields are - < (is less than), > (is greater than), == (is equal to), != (is not equal to), <= (is less than or equal to), >= (is greater than or equal to).


9. Logical Operator: Describes how to evaluate multiple rows in the file for the same policy name. Valid values are - && (and): The next row for the same policy is also required to trigger the policy. || (or): Either the current row or the next row for the same policy is required to trigger the policy.

Figure 30: Supplier & Touch Policy - Tier Definition sheet

Sheet 4 -  Template Configuration: This contains columns

1. Policy Name: The name of purchasing policy. This needs to match a policy name from the Description sheet.


2. Tier Name: The name use to define a particular amount-based tier for a policy. This needs to match a tier name from the Tier Definition sheet.


3. Sourcing Template Name: The ID of the sourcing template which needs to be associated to the policy and tier combination.


4. Auto publish sourcing request: Specify whether to automatically publish the sourcing event for the policy and tier. To auto-publish the event for the self-service flow, enter true. To require procurement department intervention before publishing the event, enter false.

Figure 31: Supplier & Touch Policy - Template Configuration sheet

Sheet 5 -  Message: This contains columns

1. Policy Name: The name of purchasing policy. This needs to match a policy name from the Description sheet.


2. Tier Name: The name use to define a particular amount-based tier for a policy. This needs to match a tier name from the Tier Definition sheet.


3. Severity: Describes what happens when users try to submit a request form that doesn't comply with the supplier and touch policy. Valid values are:1. Info: Shows an informational message that advises users about the next steps in the quote process. 2. Error: Prevents users from submitting the request form or accepting the quote until they comply with the policy.


4. Request Quote Message: Specifies the informational or error message that will be shown to users when filling out the request form associated with the policy and tier combination.


5. Accept Quote Message: Specifies the informational or error message that will be shown to users when accepting a quote from a supplier for a particular policy and tier combination.

Figure 32: Supplier & Touch Policy - Message sheet

Policy Management – Checkout Section Generation Policies

Checkout Section Generation Policies: Configure checkout section generation policies to dynamically determine which fields display in the Checkout page and to enable a simplified user interface and mass editing.

Use the default checkout section generation policies or modify them to make custom fields dynamically appear on the Checkout page based on your business. When checkout section generation policies are enabled, this also enable a simplified user interface and mass editing:

1. The checkout page user interface is simplified. The request header is expanded to include more information, which means users will spend less time scrolling to find the details they need. In addition, line items display in a more streamlined way and take up less space.


2. Users can perform mass edits on line-item shipping or accounting fields with one operation. They can make a change in the request header and choose all line items or a subset of line items; guided buying then makes the change to the chosen line items. This capability helps users quickly and easily set shipping or accounting information for multiple line items at the same time.

Parameter Setting:

Access Menu: Admin --> Parameters --> Manage parameters

Figure 33: Checkout Section Generation Policy - Admin

Set parameter ‘PARAM_ENABLE_NEW_CHECKOUT’ to true.

Figure 34: Checkout Section Generation Policy - Parameter Setting

Import Policy:

Access Menu:  Admin --> Checkout Page Configuration --> Configure

Figure 35: Checkout Section Generation Policy - Import Policy

Upload a file in Excel (XLS or XLSX) format to configure Checkout Section Generation. The policies go into effect immediately after uploading the configuration file.

Excel file contains 5 sheets: Description, Key Definition, Expression, Summary & Grouping.

Sheet 1 -  Description: This contains columns

1. Policy Name: Name of section generation policy. This should not be more that 256 characters.


2. Policy Description: A description for policy. This should make up to 256 characters.

Figure 36: Checkout Section Generation Policy - Description sheet

Sheet 2 -  Key Definition: This contains columns

1. Policy Name: The name of purchasing policy. This needs to match a policy name from the Description sheet.


2. Lookup Key: Describes which users the policy applies to. The value ProcurementUnit is the only supported value.


3. Lookup Key Value: The purchasing unit ID that is affected by the policy.

Figure 37: Checkout Section Generation Policy - Key Definition sheet

Sheet 3 -  Expression: This contains columns

1. Policy Name: The name of purchasing policy. This needs to match a policy name from the Description sheet.


2. Generation Type: The type of information generated by the policy. The supported values are: 1. Summary for information in the summary section at the top of the Checkout page and the section summary in each line item. 2. Grouping for information used for mass editing in the Checkout page.


3. Realm Type: The type of realm to which guided buying is integrated.


4. Case: A name for referring to a specific policy expression.


5. Left hand side Type: The type of value on the left-hand side of the expression. Use field for the name of a field or constant for a constant value, such as TRUE or FALSE.


6. Left hand side Field: A determinant for when to trigger a policy. This column uses the database field name for fields at the request header and line levels (Requisition and ReqLineItem field classes) and it supports dotted notation fields and custom fields. One can use the values TRUE or FALSE so the expression is always evaluated as True or False.


7. Right hand side Type: At this time, constant is the only supported value.


8. Right hand side Field: The value for the field that you specified as the Left hand side Field. The values TRUE or FALSE can be used for the expression term.


9. Operator: Describes operators that evaluate whether to enforce a policy. Valid operators for the amount-based fields are - < (is less than), > (is greater than), == (is equal to), != (is not equal to), <= (is less than or equal to), >= (is greater than or equal to)


10. Logical Operator: Describes how to evaluate multiple rows in the file for the same policy name. Valid values are - && (and):The next row for the same policy is also required to trigger the policy. || (or): Either the current row or the next row for the same policy is required to trigger the policy.

Figure 38: Checkout Section Generation Policy - Expression sheet

Sheet 4 -  Summary: This contains columns

1. Policy Name: The name of purchasing policy. This needs to match a policy name from the Description sheet.


2. Case: The name of a particular policy expression. Use only expressions defined for Generation Type "Summary“.


3. Summary Field: Enter the field to display if the expression evaluates to True.

Figure 39: Checkout Section Generation Policy - Summary sheet

Sheet 5 -  Grouping: This contains columns

1. Policy Name: The name of purchasing policy. This needs to match a policy name from the Description sheet.


2. Case: The name of a particular policy expression. Use only expressions defined for Generation Type “Grouping“.


3. Grouping Fields: Lists the fields to be displayed when the expression evaluates to True.

Figure 40: Checkout Section Generation Policy - Grouping sheet

Configure Endpoints

Configure the guided buying endpoint:

configure this so that forms and requests for quotation (RFQ) flow seamlessly to and from guided buying. This endpoint needs to match the endpoint that is configured in Ariba Network buyer account. This configuration can be done by raising an SAP Ariba Service Request or it can be configured by the SAP Ariba Delivery Services team.

Access Menu: Admin --> Tactical Sourcing --> Endpoint Configuration

Figure 41: Endpoints Configuration

 

Happy reading and feel free to ask questions with reference to this blog, will be happy to respond as much as possible.