SAP ERP Configuration and Business Processes

Partner determination procedures are assigned at document type/category level: Sales Activity (assigned to activity type), Shipment (assigned to shipment type), Delivery (assigned to delivery type), and Billing Item (assigned to item category). For billing headers, the procedure comes from the billing type configuration, not directly from the document type - this distinction matters because billing headers inherit from the billing type definition.

In SAP, a plant can be assigned to only ONE company code, not several - this is a fundamental organizational principle. All other statements are true: plants are production facilities and stock storage locations, assigned to credit control areas, assigned to sales organization+distribution channel combinations, and represent one or more stock locations. The question asks for the FALSE statement, making B the correct answer.

In SAP SD consignment processing, a consignment fill-up establishes stock at the customer site and is relevant for picking. A consignment return reverses this process, issuing a credit memo that decreases customer receivables.

All five statements are correct in SAP SD: availability check configuration is transaction-specific in Customizing, transaction variants allow multiple variants per transaction, availability checks run at plant level (not storage location), cross-company billing uses automatic output types, and cash orders allow invoice printing directly from sales documents. These represent standard SAP SD capabilities.

SAP backward scheduling calculates delivery creation date by working backwards from requested delivery date, considering lead times for: Transportation Planning (route determination and transit time calculation), Picking and Packing (warehouse processing time), Loading (goods issue time), and Transit (actual transportation time). Replenishment lead time is for materials planning, not delivery scheduling. 'Transit lead time' isn't a standard SAP field.

Route determination in SAP checks both Sold-to Party and Ship-to Party master data for transportation zone and weight group information. The Sold-to defines the general shipping requirements from the customer's headquarters location, while Ship-to defines the specific destination logistics zones. Payer and Bill-to Party are financial partners without transportation zone data, so they're not relevant for route calculation.

In precise scheduling within SAP, loading time is maintained in hours and minutes (not in days) to allow for precise timing calculations. Pick/pack lead time and transit time have their own handling - transit time is maintained in days, and pick/pack lead time is also typically maintained in days. The key distinction is that loading time requires finer precision (hours/minutes) for accurate scheduling.

In asynchronous updating, the application document is updated first and commits successfully regardless of what happens with the statistics update. The statistics update happens separately in a background job 'slightly later' and can fail independently without affecting the main document. Synchronous updating would ensure both complete together before committing.

To enable billing plan types at the item level in SAP, you must assign the billing plan type to the item category in the item category configuration (table TVC). This assignment determines how billing plans are created and processed for specific line items. Sales document types, delivery types, and delivery item categories have their own configuration but don't control item-level billing plans.

The schedule line category in SAP is determined by the item category group from the material master and the MRP type also from the material master record. These two fields control scheduling behavior through the schedule line category determination table. Document types, shipping points, and strategy groups influence other aspects but not the direct determination of schedule line categories.

In SAP, customers and vendors (business partners) are defined at the client level (also known as the cross-client level). This means they can be used across multiple company codes within the same client. Company code, controlling area, and other lower-level organizational units reference these master records but don't define them. The client level is the highest level for master data that's shared across organizational units.

The SAP R/3 system architecture consists of three central interfaces that handle different communication layers: the Presentation Interface manages user interactions, the Database Interface handles data persistence and retrieval, and the Operating System Interface manages system-level operations. These three interfaces work together to form the complete R/3 architecture, making option D correct.

Business areas in SAP are designed for external reporting across multiple company codes, not restricted to a single company code. They provide a way to consolidate financial statements and generate business area-specific reports that span organizational boundaries, making option C the correct choice.

When creating a sample account in SAP, you need to enter both the Chart of Accounts (COA) segment data and the company code segment data. The COA segment contains account control information valid across all company codes, while the company code segment contains account management data specific to that company code. Both segments are required for a complete account definition.

When payment terms are configured with baseline date, cash discount periods, and discount percentage rates, the SAP system automatically calculates both the invoice due date and the applicable cash discount dates/amounts. This dual calculation enables effective cash management and timely payment processing.

A company code can have multiple retained earnings accounts in SAP, which is necessary when using different chart of accounts or when business operations require separate tracking of retained earnings for different purposes. Option A is incorrect because the system supports multiple retained earnings accounts per company code.

SAP provides two main methods to prevent duplicate vendor accounts in Accounts Payable: using match codes to search for existing vendors before creating new ones, and enabling the automatic duplication check feature that warns when similar vendor data is entered. Option B (sensitive dual control) is a security feature, not a duplicate prevention mechanism.

Document types in SAP control which account types (assets, liabilities, expenses, etc.) can be posted and determine field status for document header fields like text and reference. Posting keys are controlled separately at the posting key level, not by document type configuration.

Posting keys are defined at the client level in SAP (not company code specific). Field status groups follow the variant principle where the same definition can be used across multiple objects. A field cannot be both 'suppressed' (hidden) and 'required' simultaneously - these are mutually exclusive states. Option B is incorrect because line item display is controlled at the account level, not by posting key.