Explanation:

When an organization implements any SAP Ariba Strategic Sourcing solution (such as Sourcing, Sourcing Optimization, or Contracts) together with SAP Ariba Buying and Invoicing, the supplier data that is shared across these solutions is the Common Supplier.
Common Supplier represents the core, global supplier record in SAP Ariba.
It allows the same supplier identity to be used consistently across Strategic Sourcing and Buying & Invoicing.
This shared supplier enables seamless processes such as sourcing events, contract creation, and downstream procurement activities without duplicating supplier master data.

Why the other options are incorrect

❌ A. Partitioned Supplier
Partitioned Supplier data is specific to SAP Ariba Buying and Invoicing and tied to a particular partition.
It is not shared with Strategic Sourcing solutions, which rely on the Common Supplier model.

❌ B. Remittance Locations
Remittance locations are financial and payment-related details used only in Buying and Invoicing.
They are not consumed or shared with Strategic Sourcing solutions.

❌ C. Tax ID
Tax IDs are part of transactional and compliance data used primarily for invoicing and taxation.
This information is not shared with Strategic Sourcing solutions as shared supplier master data.

References
SAP Help Portal – SAP Ariba Supplier Data Model Overview
SAP Ariba Procurement Configuration Guide – Supplier Management and Common Supplier Concept

Explanation:

When creating a non-catalog item requisition (also called a "free-text" or "off-catalog" item), the user must manually enter the supplier. The system assists by presenting available supplier sources to choose from:

B is correct:
Users can search and select from the global pool of public suppliers registered on the SAP Business Network. This network provides access to a vast, searchable directory of potential suppliers.

D is correct:
Organizations typically use SAP Ariba Supplier Lifecycle and Performance (SLP) or similar tools to pre-qualify, onboard, and categorize suppliers. A subset of these becomes the "preferred supplier" list for each category or commodity. This curated list is presented to requisitioners to encourage policy compliance and ensure purchases go to approved suppliers.

Why the other options are incorrect:

A is incorrect: While incumbent suppliers from sourcing events are often added to the preferred supplier list, they are not presented to the user as a separate, dedicated list labeled "incumbent suppliers responding to sourcing events." They are included in the broader preferred supplier list (D).

C is incorrect: There is no standalone, separate "global pool of supplier organizations available in Buying and Invoicing." The global pool is part of the SAP Business Network (B). Buying and Invoicing is an application that accesses the network's supplier data; it does not maintain its own independent global pool.

Reference
This functionality is core to the "Supplier Search and Selection" process in SAP Ariba Buying. The system is designed to guide users toward compliant, pre-approved suppliers (via the preferred list) while also providing flexibility to find new suppliers on the network if needed. This balances control with usability.

Explanation:

B. Catalog-Based Pricing This term allows organizations to link contract pricing to specific catalog items. It is highly efficient for "Subscription" or "Punchout" scenarios where the price is not fixed but is calculated as a percentage discount off a supplier's catalog price. When a user selects an item from the catalog, the system checks the contract and applies the negotiated discount automatically.

C. Tiered Pricing Tiered (or Volume) pricing is a core feature used to capture economies of scale. In SAP Ariba, you can configure these based on quantity or amount.

Example:
$0-500$ units cost $10 each; $501-1000$ units cost $8 each. The system tracks the cumulative spend or quantity to ensure the correct "tier" is triggered during the requisitioning process.

Why the Other Options are Incorrect

A. Forecast-Based Pricing:
This is a distractor. While SAP Ariba Supply Chain Collaboration uses forecasts to share demand with suppliers, "Forecast-Based Pricing" is not a configurable pricing term within the Contract Compliance module of Buying and Invoicing. Pricing is driven by actual transactions (orders), not projected forecasts.

D. Term-Based Pricing:
Although contracts have validity periods (Terms), there is no specific pricing category called "Term-Based Pricing" in the Ariba UI. Users often confuse this with Fixed Fee or Recurring items, but in the context of the C_ARP2P exam, it is not a recognized technical term for pricing logic.

References
SAP Ariba Procurement - Contract Compliance Guide: Sections on "Pricing Terms for Catalog Items" and "Defining Tiered Pricing."

Explanation:

In a suite-integrated realm, where SAP Ariba Contracts integrates tightly with SAP Ariba Buying and Invoicing, contracts used for procurement (e.g., compliance contracts enforcing pricing, quantities, and terms on requisitions, POs, and invoices) originate from the Contract Workspace in SAP Ariba Contracts.

The Contract Workspace acts as the central container for the full contract lifecycle: drafting, negotiation, approvals, amendments, and execution. Key pricing and terms are captured in the Contract Terms document within this workspace. Upon approval and publishing (or execution), SAP Ariba automatically creates a corresponding compliance contract (often no-release or blanket type) in Open status directly in SAP Ariba Buying and Invoicing. This ensures seamless downstream use without manual recreation.

Why the other options are incorrect:

A. Contract template
— Templates define structure and rules to initiate a Contract Workspace; they are not the origin of the actual contract.

B. Contract requisition
— A Contract Request (or requisition) is an upstream initiation step that triggers creation of a Contract Workspace; the final contract does not originate here.

C. Contract hierarchy
— This manages parent-child relationships for amendments/renewals within existing workspaces; it is not the creation origin.

This reflects standard suite integration behavior, where upstream contract management in Contracts feeds downstream procurement compliance.

References:
SAP Learning: "Advancing Contract Management" (Managing SAP Ariba Procurement journey) — explicitly states: "If SAP Ariba Contracts is integrated with SAP Ariba Buying and Invoicing, the creation of contracts takes place within SAP Ariba Contracts" and describes Contract Workspace → Contract Terms → compliance contract in Buying and Invoicing.

Explanation:

In SAP Ariba Contracts, a subagreement can contain pricing terms that override the master (parent) agreement price when the contractual structure allows releases or operational use of pricing from the parent agreement.

If the parent agreement is a release order contract, the subagreement can define more specific or revised pricing that takes precedence over the master agreement during requisition and purchase order creation.

If the parent agreement is a no-release order contract, the parent serves as a governing or framework agreement, and the subagreement pricing is used operationally, allowing it to override the master agreement price.

In both cases, SAP Ariba allows pricing defined at the subagreement level to be applied instead of the master agreement pricing.

Why the other options are incorrect

❌ A. When both agreements have item-level price discounts
Having item-level discounts in both agreements does not by itself enable price override. Override behavior depends on the agreement type and hierarchy, not merely on discount configuration.

❌ C. When both agreements have the item aggregator turned on
The item aggregator controls how line items are grouped in contracts. It has no impact on pricing precedence or override logic between master and subagreements.

References
SAP Help Portal – SAP Ariba Contracts: Master Agreements and Subagreements
SAP Ariba Contracts Configuration Guide – Agreement Types and Pricing Behavior

Explanation:

A Collaborative Requisition is a sourcing event initiated from a requisition where the buyer invites one or more suppliers to submit quotes or proposals before a purchase order is created. During the Collaboration phase, the invited suppliers can actively engage with the buyer's request.

C is correct: The core action a supplier performs in this phase is to submit a formal proposal or quote in response to the buyer's detailed request (which includes items, quantities, delivery requirements, etc.).

D is correct: Communication is central to collaboration. Suppliers can use the SAP Business Network's integrated messaging system to ask clarifying questions, negotiate terms, or provide updates directly within the requisition event.

E is correct: Suppliers can attach supporting documents (such as technical specifications, certifications, drawings, or alternative product brochures) to their proposal to provide additional information or context to the buyer.

Why the other options are incorrect:

A is incorrect: Suppliers cannot cancel the collaborative requisition itself. Only the initiating buyer (or a buyer with appropriate authority) can cancel or withdraw the requisition/event. The supplier's options are to respond, communicate, or decline to participate.

B is incorrect: The action to "Finalize collaboration to trigger the purchase order" is a buyer-side action. After reviewing the supplier proposals, the buyer selects a winner and finalizes the award. This action converts the requisition and chosen proposal into a purchase order. The supplier cannot trigger this step.

Reference:
This question highlights the bidirectional, collaborative workflow in SAP Ariba Procurement, moving beyond a simple "request-for-quote" to an interactive process. The Collaboration phase is designed for negotiation and information exchange before a binding PO is issued.

Explanation:

This is a specific invoice exception scenario in SAP Ariba Buying & Invoicing where the invoice was successfully matched to a purchase order, but it is the wrong PO. The key characteristic here is that the purchase order exists in the system, just not the one the invoice should be tied to.

D is correct: The "Manual match to the correct purchase order" processing option allows the exception handler to disconnect the invoice from the incorrect PO and manually search for, select, and link it to the correct PO. This is the most direct and appropriate resolution for this specific error, as it corrects the matching relationship without rejecting the invoice or involving unnecessary steps.

Why the other options are incorrect for this specific scenario:

A. Reject and request resubmission:
This is a valid option for many exceptions (e.g., data errors, pricing mismatches), but it's inefficient here. It would force the supplier to re-create and re-submit the entire invoice, causing delay, when the issue is simply a wrong PO reference that can be fixed internally.

B. Request for a credit memo and resubmit:
This is an overly complex solution. It implies the matched invoice must be canceled (via credit memo) and a new one submitted. This is suitable for correcting major content errors on an already posted invoice, not for a simple PO matching error caught during exception handling.

C. Refer to Accounts Payable group:
While Accounts Payable may be involved in complex disputes or payment holds, the action described in the scenario is a standard operational correction within the purview of an invoice exception handler. Referring it out would create unnecessary handoffs and delay.

Reference:
This question tests knowledge of the Invoice Exception Management workflow and the appropriate use of resolution actions. The goal is to resolve exceptions efficiently at the right level of authority.

Explanation:

In the Exception Management workspace, exception handlers are authorized to take specific actions to resolve or escalate discrepancies between invoices, purchase orders, and receipts.

A. Modify is correct:
The exception handler often has the ability to modify certain fields on the invoice or its matching data to resolve the discrepancy. Common examples include correcting a unit price, updating a quantity, or fixing a tax code to align with the PO, allowing the match to succeed. This is a primary resolution action.

C. Refer is correct:
If the exception handler cannot resolve the issue themselves (e.g., it requires buyer clarification, supplier negotiation, or higher approval), they can refer the exception to another person or group (like the requisitioner, a category manager, or the Accounts Payable team) for further investigation and action. This escalates the issue while keeping it tracked in the workflow.

Why the other options are incorrect:

B. Delete is incorrect:
Exception handlers cannot typically delete invoices that have triggered exceptions. The invoice is a business document that must be accounted for. The correct action for an invalid or duplicate invoice is to reject it (sending a notification to the supplier), not delete it from the system. Deletion is usually a system administrator function, not an exception handler function.

D. Accept is incorrect:
"Accept" is generally not a standard action in the context of resolving a matching or validation exception. Accepting would imply approving an invoice with a known discrepancy, which violates the control purpose of the matching process. The goal is to resolve the exception by making it match (Modify) or by getting it resolved by someone else (Refer). Once resolved, the invoice is approved, not the exception itself "accepted."

Reference:

This question tests the understanding of the standard resolution paths available to an exception handler. Their role is to clear exceptions by either fixing data errors or escalating issues they cannot fix.

Explanation:

The Procurement Operations Desk (POD) is a centralized, workflow-driven application in SAP Ariba Procurement designed to orchestrate and optimize the manual processing of requisitions (e.g., converting shopping carts to POs, handling exceptions, managing supplier adds). Its core function is intelligent, rules-based task assignment.

A is correct: The POD uses a sophisticated rules engine that considers multiple factors to ensure efficiency and proper routing:
Requisition Attributes: Such as commodity, cost center, supplier, total value, or region.

User Workload: To balance the volume of tasks among available agents (load balancing).
Defined Queues: Work is organized into specific queues (e.g., "IT Hardware," "Services > $50k," "Supplier Onboarding") staffed by users with the appropriate expertise.

This ensures tasks are processed by the most qualified available person, reducing turnaround time and improving accuracy.

Why the other options are incorrect:

B. It randomly distributes requests...:
This is the opposite of the POD's purpose. Random distribution would be inefficient, wouldn't leverage user expertise, and could overload some users while underutilizing others. The entire value of the POD is intelligent, rules-based assignment.

C. It escalates all high-priority requisitions directly to Finance:
This is incorrect in several ways. First, not all high-priority requisitions are financial in nature (some may require technical or legal review). Second, the POD routes tasks based on defined business rules, not a blanket escalation to a single department. High-priority items might be routed to senior buyers or managers within Procurement, not necessarily Finance.

D. It uses vacation calendars to avoid assigning tasks to unavailable suppliers:
While supplier unavailability is a consideration in procurement, the POD's primary function is to assign tasks to internal buyers/agents within the buying organization, not to assign work to suppliers. Managing supplier availability calendars is typically a function of supplier collaboration or sourcing tools, not the internal Operations Desk workflow.

Reference:
The Procurement Operations Desk transforms ad-hoc procurement tasks into a managed, measurable service operation. It is a key tool for centralizing and professionalizing procurement support, ensuring consistency, leveraging specialized skills, and providing clear metrics on processing times and workloads.

Explanation:

When integrating SAP Ariba Procurement (Buying & Invoicing) with a backend ERP/SAP S/4HANA system, a set of master data must be synchronized to ensure consistent business processes. The required elements are foundational for creating and processing documents.

B. Suppliers is correct:
Supplier master data is critical. The integration needs a common, synchronized set of suppliers (with IDs, addresses, bank details, etc.) to ensure that purchase orders and invoices created in Ariba reference valid, approved suppliers in the backend system for payment processing. This is a non-negotiable master data requirement.

D. Payment terms is correct:
Payment terms (e.g., Net 30, 2% 10 Net 30) are key financial conditions that must be consistent across the procurement and financial systems. They are pulled from the backend ERP (like SAP S/4HANA) into Ariba to ensure POs and invoices reflect the correct terms, which directly impact payment runs and cash flow management.

Why the other options are incorrect:

A. User groups is incorrect:
While user roles and authorizations are essential for the Ariba system, "User groups" as an organizational structure are typically defined and maintained within the SAP Ariba application itself based on the company's internal approval and delegation policies. They are not a standard master data element replicated from the ERP. The ERP may provide employee/user master data (like user IDs and names), but the functional grouping is configured in Ariba.

C. Historical spend data is incorrect:
Historical spend data is highly valuable for analysis, reporting, and sourcing, but it is not a required master data element for the core operational integration to function. Spend data is often loaded separately for visibility and can be imported, but the system does not require it to process requisitions, POs, or invoices. The integration's primary focus is on real-time transactional data and foundational master data, not historical analytics.

Reference:

This question addresses the Master Data Governance (MDG) and integration scope for an SAP Ariba implementation. The implementation guide clearly defines which data objects must be harmonized between systems.

Explanation:

Why B is correct:
This structure is specifically designed for indirect procurement scenarios.

The Master Agreement (Parent):
Is created with the Manufacturer. This is where you track the global spend, negotiated prices, and volume across the entire organization, regardless of which reseller fulfills the order.

The Subagreement (Child):
Is created with the Reseller. This agreement "inherits" the terms from the manufacturer's master agreement but identifies the reseller as the party to whom the Purchase Orders (POs) are sent and payments are made.

Spend Accumulation:
When you buy from the reseller (subagreement), the spend automatically "rolls up" to the manufacturer (master agreement), allowing the customer to see the total business value provided to the manufacturer.

Why the Other Options are Incorrect

A. Master agreement with reseller;
Subagreement with manufacturer: This is the reverse of what is needed. If the reseller is the parent, you are tracking spend against the reseller's entity. It is illogical for a manufacturer to be a "child" to a reseller in a procurement hierarchy meant for tracking manufacturer-level spend.

C & D. Standalone agreements:
Standalone agreements do not have a parent-child relationship. If you use standalone contracts, the spend for the manufacturer and the reseller would be completely isolated. You would lose the "rollup" functionality, making it nearly impossible to automatically track total manufacturer spend through the reseller's transactions.

References
SAP Ariba Contract Compliance Guide: Section on Contract Hierarchies and Manufacturer/Reseller scenarios.

Explanation:

C. Select the Withdraw button The Withdraw action is performed by the requester.
If a user realizes they made a mistake or need to change a line item after they have already submitted the requisition (but before it is fully approved), they can withdraw it. This action immediately stops the approval workflow and moves the requisition back to Composing status, making it editable again.

D. Select the Edit button In many configurations, clicking Edit on a submitted requisition acts as a shortcut.
It automatically triggers a "Withdraw" action in the background. Once the user clicks Edit, the requisition is pulled out of the approval queue and placed back into Composing status so that changes can be made.

Why the Other Options are Incorrect

A. Select the Return button:
This is a distractor in terms of terminology. While an approver can "Send Back" a requisition, the standard button used by an approver to request changes from the user is typically labeled "Send Back", which returns it to Composing. However, "Return" is not the standard UI term for moving a submitted document to composing in this specific exam context.

B. Select the Deny button:
When an approver selects Deny, the requisition moves to the Denied status, not Composing. A denied requisition is considered "dead" or final. While a requester can sometimes "recreate" a new requisition from a denied one, the original document does not return to the Composing state; it remains Denied for audit purposes.

References
SAP Ariba Buying and Invoicing Guide: Requisition Lifecycle and Statuses.
SAP Learning Hub (AR510): Lesson on Managing Requisitions.