Learn, Practice, and Improve with SAP C_TS452_2410 Practice Test Questions

Explanation:

In SAP PP (Production Planning) and MM (Materials Management), issuing components to a production order can be done in several ways, depending on the material, production process, and control parameters.

Option B (Correct):
You can post a goods issue manually with reference to a reservation. When you create a production order, the system automatically generates reservations for components. Using Transaction MIGO (or MB1A), you can post a goods issue (movement type 261) by referencing this reservation. This is a standard, planned goods issue process.

Option C (Correct):
Backflushing (also called automatic goods issue) is a common method where the goods issue is posted automatically when a confirmation is made for a production order operation or when the order is completed (goods receipt). The system calculates the quantity to be issued based on the BOM and the confirmed yield. This is typically used for low-value or bulk components.

Option E (Correct):
You can post a goods issue manually as an unplanned issue using movement type 261. In MIGO, you do not need to reference a reservation. You directly specify the production order as the account assignment (order number) and the material/quantity. This is used for ad-hoc issues, replacements, or when components were not included in the original BOM/reservation.

Why Other Options Are Incorrect:

Option A (Incorrect):
The Final Issue indicator is a field in a reservation, but setting it does not in itself post a goods issue. It is a planning parameter that indicates no further issues are expected for that reservation line item. The actual goods issue must still be posted via a separate transaction (MIGO, MB1A). This option describes a reservation setting, not a method of posting.

Option D (Incorrect):
Posting goods issues periodically based on inventory differences is not a standard method for issuing to a production order. This describes a cycle counting or inventory adjustment process (like movement type 701 for a write-off). Production order issues are deliberate transactions to consume specific components for a specific manufacturing order, not adjustments based on periodic variance calculations.

References

Key Transactions: MIGO (Goods Movement), CO11N (Order Confirmation - triggers backflush), MB1A (Goods Issue - classic).
Movement Types: 261 (Goods Issue to Cost Center/Order), 262 (GI for Scrapping).
Backflushing: Controlled by the material master's MRP 2 view ("Backflush" indicator) and the routing operation control key. Requires component assignment in the BOM and production order.

Explanation:

The goal is to prevent all procurement of a material in a specific plant. This requires a block at a high level that stops any purchase order, production order, or other procurement means.

Option C (Correct):
Using a plant-specific material status in the material master is a direct and comprehensive way to block procurement. In the material master's "Plant Data / Storage 1" view, you can assign a material status (e.g., "Z1 - Blocked for Procurement"). This status, when configured accordingly in the background, prevents the creation of any procurement documents (purchase requisitions, purchase orders, production orders, etc.) for that material in the specified plant.

Option D (Correct):
Creating an entry in the source list with a blocking indicator and no supplier is an effective procurement block. The source list (transaction ME01) is a key control document for source determination. An entry with a valid period, the material, plant, and the blocking indicator checked, but with the supplier field left blank, effectively means: "For this period, there is no valid source of supply, and sourcing is blocked." This will prevent the creation of purchase orders and can also cause MRP to create an exception message.

Why Other Options Are Incorrect:

Option A (Incorrect):
Creating a blocking entry in the supplier master record (e.g., a purchasing block at the vendor level) blocks procurement from that specific supplier. It does not block the material completely. Procurement could still occur from other approved suppliers for that material. This is a supplier-specific block, not a material/plant-wide block.

Option B (Incorrect):
A quota arrangement (transaction MEQ1) determines the proportional distribution of requirements among different sources. An entry with a quantity of zero would mean that source receives 0% of the quota. However, this does not completely block procurement. If there are other valid sources in the quota arrangement, procurement could still go to them. If it's the only source, the system may treat it as an invalid source and potentially create an exception, but a quota arrangement is not designed as a primary blocking tool; it's for sourcing distribution. A zero quota is not a guaranteed comprehensive block.

References:

Material Status:Configured in SPRO: Materials Management -> Material Master -> Settings for Key Fields -> Define Material Statuses. Key statuses like "Blocked for Procurement" prevent document creation.
Source List Blocking: Transaction ME01. A blank vendor with a blocking indicator is a standard method to prevent purchasing.

Explanation:

A. Client (Highest Level)
Field status can be defined at the Client level. Settings made here apply to all Business Partners across the entire system client, regardless of their role or type. This is often used for fields that are universally required or should always be hidden for a specific implementation.

C. Business Partner Role
This is the most common factor used in procurement. Different roles require different data. For example, the FLVN01 (Supplier) role makes purchasing-related fields available, while the FLVN00 (FI Vendor) role focuses on company code and reconciliation account data. You can configure specific field groupings to be mandatory only when a BP is being maintained in a specific role.

D. Business Partner Type
The BP Type (not to be confused with Category) is a field in the BP header used to group partners according to your own business criteria (e.g., "Small Business," "Subsidiary"). You can configure field status specifically for each BP Type, allowing you to make certain fields mandatory for "Organizations" but optional for "Individuals" if they are categorized by type.

Why the other options are incorrect:

B. Partner Schema:
A partner schema is used in Partner Determination to define which partner functions (like Invoicing Party or Goods Supplier) are allowed or mandatory in a purchasing document or master record. It controls the relationship, not the field attributes (Required/Optional) of the BP master data itself.

E. Business Partner Category:
The category (Person, Organization, or Group) is a fixed system attribute that determines the basic structure of the BP. While the category influences which tabs and screens appear, the actual configuration of "Field Attributes" in the IMG is technically driven by Role, Type, Activity, and Client, rather than the Category itself.

Reference:

SAP Help Portal: Sourcing and Procurement -> Master Data -> Business Partner -> Field Status Control.
Customizing Path: Cross-Application Components > SAP Business Partner > Business Partner > Basic Settings > Field Groupings.

Explanation:

Centrally agreed contracts (often simply called "central contracts" or "contracts with a central purchasing organization") are a key tool in SAP for leveraging corporate-wide purchasing agreements.

Option A (Correct):
Centrally agreed contracts are a perfect fit for a procurement hub scenario. In this scenario, a central purchasing organization (the "hub") negotiates and manages contracts on behalf of other purchasing organizations ("spokes" or operating units). The local purchasing organizations can then create release orders (purchase orders) against this central contract to fulfill their local needs, while the central organization retains control over pricing and vendor relationships.

Option C (Correct):
Within a centrally agreed contract, you can maintain plant-specific conditions. While the header of the contract is created for the central purchasing organization, the contract item conditions (prices, discounts, surcharges) can be maintained for specific plants. This allows a corporate-wide agreement to still accommodate local variations in cost structures (e.g., different freight costs per plant).

Why Other Options Are Incorrect:

Option B (Incorrect):
This statement is false. The main purpose of a centrally agreed contract is that multiple purchasing organizations can create release orders against it. Release orders (purchase orders) can be created by the central purchasing organization and by any other purchasing organization that has been assigned as a "release-against" purchasing organization in the contract's partner functions or through the item's assignment. This is the core functionality that enables decentralized procurement under a central agreement.

Option D (Incorrect):
You cannot use centrally agreed contracts "without restrictions" for any purchasing organization. There are specific restrictions and a setup process:
The contract must be created with a specific central purchasing organization.
Other purchasing organizations can only use it if they are explicitly assigned to the contract (e.g., via the "Release-against purchasing org" assignment in the contract item details or partner functions).
The local purchasing organization must be assigned to the same company code as the central purchasing organization, or inter-company settings must be configured if they differ. It is not an unrestricted, global document available to any org without configuration.

References

Document Type: Typically contract type "WK" (Central Contract) or "MP" (Scheduling Agreement with Central Release).
Configuration: The ability for other purchasing organizations to release against a central contract is controlled in the contract item details (field: "Rel.-against-pur.org" or via partner function "SP - Release-against purchasing organization").

Explanation:

A. Two Accounting Documents
When you use the "Invoice Reduction" layout in transaction MIRO, the system does not simply change the invoice amount to a lower value. To maintain an audit trail that matches the physical paper invoice from the vendor:

1.First Document (Invoice): The system posts the full amount as specified by the supplier on their paper invoice.
2.Second Document (Credit Memo): The system automatically creates a second, separate accounting document for the difference (the reduction amount). The net effect in the vendor’s account is the reduced amount, but both original values are recorded.

B. Notification Message (Letter of Complaint)
Because you are effectively paying the supplier less than they requested, you must notify them of why the reduction occurred. In configuration, a specific Message Type (Standard: REKL) is assigned to invoice reductions. When you post the transaction, the system generates this output (a "Letter of Complaint"), which can be printed or sent via email/EDI to the supplier.

Why the other options are incorrect:

C. The invoice is blocked for payment until the supplier confirms:
This is a common point of confusion. The invoice is not automatically blocked for payment in a way that requires supplier confirmation. Because the credit memo is posted simultaneously with the invoice, the net payable is already corrected. The payment can proceed for the reduced amount according to the payment terms.

D. Only one accounting document is created:
As explained in Option A, the hallmark of the "Invoice Reduction" feature is the generation of two distinct accounting documents to ensure the vendor's original claim and your correction are both documented.

Reference:

SAP Help Portal: Sourcing and Procurement -> Logistics Invoice Verification -> Invoice Reduction.
SAP Training (TS452): Invoice Verification -> Variances and Invoice Block.

Explanation

B. It is used to calculate different prices for material valuation.
The Material Ledger allows the system to calculate the Periodic Unit Price (PUP). While materials are typically valued at a standard price during a period, the Material Ledger collects all price and exchange rate variances. At period-end, these variances can be used to calculate a multi-level actual price (PUP), which provides a more accurate reflection of the material's value.

C. It is mandatory in SAP S/4HANA.
This is a significant change from SAP ECC. In S/4HANA, the Material Ledger is the mandatory sub-ledger for inventory valuation. Even if you do not intend to use "Actual Costing," the Material Ledger must be activated to handle the simplified data structure and to allow integration with the Universal Journal (ACDOCA).

D. It is used to valuate materials in different currencies.
One of the primary strengths of the Material Ledger is its ability to maintain inventory values in up to three parallel currencies (e.g., Company Code currency, Group currency, and a third freely definable currency like Hard currency). This ensures that global organizations can report their inventory values consistently across different regions and legal entities.

Why the other options are incorrect:

A. It must be activated per controlling area:
The Material Ledger is actually activated at the Valuation Area level (which is almost always the Plant level in SAP). While it is often discussed in a Controlling (CO) context, the technical activation occurs per plant.

E. It is used to calculate the standard price:
The Standard Price is typically calculated through Product Cost Planning (using a Cost Estimate via CK11N or CK40N), not by the Material Ledger itself. The Material Ledger's job is to capture the variances from that standard price and calculate the actual price (PUP).

Reference:

SAP Help Portal: Sourcing and Procurement -> Inventory Management -> Material Ledger.
Simplification List for SAP S/4HANA: Section on Mandatory Activation of Material Ledger.

Explanation:

In SAP S/4HANA, a supplier is created as a Business Partner (BP) with the role of Supplier. The BP data is structured in a modular way, where certain data is maintained at specific organizational levels to enable different business processes (like purchasing, accounting, tax reporting).

Option C (Purchasing organization) - Correct:
You must maintain purchasing-specific data for a supplier at the purchasing organization level. This data includes terms of payment, ordering address, and other procurement-relevant information. This is maintained in the BP role Supplier (Purchasing). A supplier can be valid for one or more purchasing organizations.

Option D (Company code) - Correct:
You must maintain accounting and financial data for a supplier at the company code level. This includes payment terms, reconciliation account, withholding tax information, and dunning data. This is maintained in the BP role Supplier (Accounting). This data is essential for posting invoices and making payments.

Option E (Client) - Correct:
The general data of a business partner (like name, address, central contact information, and the BP number itself) is maintained at the client level. This data is universal and shared across all organizational units (company codes, purchasing orgs) that use this supplier BP.

Why Other Options Are Incorrect:

Option A (Plant) - Incorrect:
While plant-specific data (like a particular delivery address or MRP controller contact) can be maintained for a supplier, it is not a mandatory level. The mandatory levels for creating a functional supplier are Client (general data), Company Code (accounting), and Purchasing Organization (procurement). Plant-specific data is an optional extension.

Option B (Purchasing group) - Incorrect:
The purchasing group is an internal organizational unit (a group of buyers) within a purchasing organization. It is not a mandatory organizational level in the business partner master data for a supplier. A purchasing group is assigned to purchase orders or requisitions, but a supplier's master record is not maintained at the purchasing group level.

References:

Business Partner Concept: In S/4HANA, the Business Partner (BP) is the central master data object for customers, vendors, and other partners, replacing the separate vendor master (LFA1/LFB1/LFM1) and customer master structures.