Lem Stand Notes

A posting key is a two-character code used in SAP S/4HANA FI to determine how a transaction is posted. It specifies the account assignment and transaction type. • Examples: ○ 40: Credit to customer (e.g., when a customer pays an invoice) ○ 50: Debit to vendor (e.g., when you purchase goods or services on credit) ○ 70: Debit asset acquisition (e.g., when you buy a new machine for your business) ○ 71: Credit to bank account (e.g., when you deposit a check into your biz. bank account) Posting Key 40: Credit to Customer When a customer pays an invoice, the following double-entry accounting occurs: 1. Cash (or Bank) Account: This account is debited to record the increase in cash balance received from the customer. 2. A/R Account: This account is credited to reduce the outstanding amount owed by the customer.                   |                  Account          ...

Let me walk you through the explanation again, this time incorporating an example to clarify Q4 (Specify Open and Close Periods), focusing on a quarter-end closing activity. Q1: Initially, before Posting Period Variant (PPV) creation, are all the posting periods open? Yes, in a newly configured SAP system, all posting periods are open by default. This setup is primarily for testing purposes, ensuring that transactions can be posted without restriction during the initial configuration. However, in a production system, this state is a security risk, as it allows transactions to be posted in any period, potentially compromising data integrity. Q2: What exactly are we doing in Step 1 (Define Variants for Open Posting Periods)? You are correct that this step is essentially about creating a "placeholder" for the Posting Period Variant. Here, you define the PPV as a 4-character key (e.g., QEND) with a descriptive name (e.g., "Quarter End Variant"). • Purpose: At this sta...

> In SAP S/4HANA discussions, I find two discussions of client. One uses terms like dev or prod. Another uses numbers like 100. What is the difference? You're right, the term "client" in SAP S/4HANA can be confusing because it's used in two distinct contexts: 1. Logical Clients (Numbers like 100, 200, etc.): Definition: These are numerical clients within an SAP system. They represent separate, independent business entities or organizational units within the same physical SAP system.   Purpose: Data Separation: Each client has its own master data, transactional data, and customizing settings. This means data in client 100 is completely separate from data in client 200. Organizational Isolation: It allows different departments, subsidiaries, or even entirely separate companies to use the same SAP system without interfering with each other's data. Testing and Development: Clients are often used for different purposes, such as: Development (DEV): Clie...

 (1) Every CC is assigned to at least 1 LE and 1 CA. (2) A  Company Code  is always tied to one  Legal Entity  for  legal reporting  and to one  Controlling Area (CA)  for internal cost accounting. However, a  CA  can encompass multiple  Company Codes  if they have the same internal accounting structures (e.g., same fiscal year variant and chart of accounts). (3) Company Codes are for the external financial view, but they also provide feeds into the CA. While  Company Codes (CC)  are primarily responsible for external financial reporting, they also play a crucial role in providing financial data to the  Controlling Area (CA)  for internal management accounting. Here's how this relationship works: Company Codes  record all  financial transactions  (e.g., revenue, expenses, asset purchases) for external reporting purposes. This financial data is then  integrated into the Controlli...

Let's clarify the relationship between vouchers and receipts, and the role of vouchers in financial transactions. Sequence: Voucher Before Receipt You're correct that a receipt typically comes after a voucher in the financial process: 1. Voucher creation: When a company receives an invoice or needs to make a payment, a voucher is created. 2. Payment processing: The voucher is used to authorize and process the payment. 3. Receipt issuance: After the payment is made, a receipt is issued as proof of payment. Vouchers as Evidence Your insight about vouchers acting as witnesses to settle disputes is spot-on. Vouchers serve several important functions in this regard: 1. Proof of Obligation - Vouchers document the details of a financial obligation before payment is made. - They include critical information like amount owed, due date, and payee details. 2. Audit Trail - Vouchers create a clear audit trail of financial transactions. - This trail can be crucial in resolving disputes or d...

Purchase-to-Pay (P2P) Process in SAP S/4HANA The Purchase-to-Pay process in SAP S/4HANA is a streamlined workflow that automates the procurement cycle, from identifying a need to paying a supplier. Here's a simplified overview of the process: Create Purchase Requisition: A user in a department identifies a need for goods or services. They create a purchase requisition in SAP, specifying the items, quantities, and delivery dates. Create Purchase Order: The purchase requisition is approved, and a purchase order is generated. The purchase order includes details like supplier information, pricing, delivery terms, and payment terms. Goods Receipt: When the goods are received, a goods receipt document is created in SAP. The system verifies the quantity and quality of the goods against the purchase order. Invoice Verification: The supplier sends an invoice to Company XYZ. The invoice is entered into SAP and compared to the purchase order and goods receipt documen...

1) When BB Co. buys goods from SS Co., it creates a Purchase Order to send to SS Co.  2) When SS Co. sells goods to BB Co., it creates a Sales Order based on the Purchase Order it received from BB Co.  2.1) Next, SS Co. sends the Sales Order to BB Co. 3) SS Co. ships the goods to BB Co. as per the agreed-upon delivery terms. 4) SS Co. generates an invoice in their SAP S/4HANA system and sends it to BB Co. electronically. 4.1) SS Co. posts the invoice to the A/R subledger. 5) BB Co., receives the goods and records goods receipt. 6) BB Co., receives the bill (aka invoice from seller's perspective) from SS Co. and records it. 6.1) BB Co., posts the bill to A/P subledger. 7) BB Co., makes a payment to SS Co.

The key differences between Classic Accounting and the New GL (General Ledger) concept in SAP. Classic Accounting (Old Approach): Separate ledgers: G/L accounts were managed in the General Ledger Customer accounts in Accounts Receivable (AR) subsidiary ledger Vendor accounts in Accounts Payable (AP) subsidiary ledger Asset accounts in Asset Accounting subsidiary ledger Each subsidiary ledger had its own reconciliation account that needed to be balanced with the General Ledger. Limited parallel accounting capabilities - difficult to maintain multiple accounting principles (like US GAAP and IFRS) simultaneously. New GL Accounting (The Ledger Approach): Integration: All subsidiary ledgers are directly integrated into one unified ledger No reconciliation accounts needed between sub-ledgers and GL Real-time integration and posting Parallel Accounting: Supports multiple parallel ledgers (leading and non-leading) Can maintain different accounting principles simult...

Currency Types in ECC and S/4HANA FI: ECC: There are indeed only 3 Currency Types in ECC: Company Code Currency: The primary currency used for financial transactions in the company code. Group Currency: The currency used for consolidation purposes at the group level. Hard Currency (or Additional Currency) S/4HANA FI: There are 10 Currency fields available in the ACDOCA: Company Code Currency Group Currency Document Currency Global Currency Free-Defined Currency 1 .  .  . Free-Defined Currency 6 Differences Between OB22 and FINSC_LEDGER: OB22: Primarily used for setting currencies at the company code level. Allows you to define and manage local currencies for a specific company code. The screen for "Change view additional local currencies for a company code: details" is specifically for ECC, as it only lists three local currencies. FINSC_LEDGER: A more comprehensive transaction for managing currencies and other financial ledger settings. Offers a wider range of options and f...

~  The choice between "Controlling Area Same as Company Code" and "Cross-Company-Code Cost Accounting" in transaction OKKP does indeed affect the currency type options available. Here's a breakdown of the currency type options for each scenario: Controlling Area Same as Company Code: Only one option is available: Company Code Currency . This means that the controlling area will always use the same currency as the company code it is assigned to. Cross-Company-Code Cost Accounting: Six currency type options are available: Company Code Currency: The default currency of the company code. Controlling Area Currency: A currency defined at the controlling area level, allowing for different currencies within a single controlling area. Group Currency: A currency defined at a higher organizational level (e.g., a corporate group). Hard Currency: A currency typically considered stable and less prone to fluctuations (e.g., USD, EUR). Index-Based Currency: ...

OKKP: Controlling Area Assignment in SAP S/4HANA Transaction OKKP  in SAP S/4HANA is used to define the assignment of controlling areas to company codes . This assignment determines how the controlling area will be used for cost accounting purposes within a company code. OKKP: CO-A ==> CC  Two Options: Controlling Area Same as Company Code ( CO-A : CC ) A one-to-one relationship between controlling area and company code. Each company code has its own unique controlling area. Suitable for smaller organization s or where there's no need for separate cost accounting. Cross-Company-Code Cost Accounting   ( CO-A : nCC ) A one-to-many relationship between controlling area and company codes. A single controlling area can be used for multiple company codes. Commonly used in larger organizations with different business units or divisions. Requirements for Cross-Company-Code Cost Accounting: Fiscal Year Variant (FYV): Must be the same for all company codes sharing a cont...

In SAP S/4HANA FI, tolerance groups (transaction OBA4) are used to set posting limits for different types of transactions. Let's understand using two amounts: 1. "$1000 for Amount per document": - This refers to G/L (General Ledger) postings - It means users can post G/L account transactions up to $1000 without requiring additional approval - These are direct postings to G/L accounts (like expense accounts, revenue accounts, etc.) 2. "$2000 for Amount per open item account item": - This refers to postings to open item managed accounts, which includes both A/P (Accounts Payable) and A/R (Accounts Receivable) - This $2000 limit would actually apply to both A/P and A/R accounts since both are open item managed accounts - G/L postings are direct transactions that need to be controlled separately from subledger postings The difference between G/L (direct) postings and subledger postings: G/L Direct Postings: - These are transactions posted directly to G/L accounts w...

In SAP S/4HANA FI, Field Status Variants and Field Status Groups are related but distinct concepts: Field Status Group: Defines a set of fields that are relevant for a specific business process or transaction type (e.g., customer invoices, vendor payments). Determines the field status (e.g., required, optional, suppressed) for each field in the group. Can be reused across multiple transactions and documents. Field Status Variant: A specific implementation of a Field Status Group, tailored for a particular business requirement or transaction variant. Assigns a Field Status Group to a specific transaction type, company code, or document type. Defines additional settings, such as: Screen layout and field sequence. Default values for fields. Field-specific rules and validations. When creating a Field Status Variant from scratch, you typically: Create a Field Status Group, defining the relevant fields and their statuses. Create a Field Status Variant, assigning the Field Status Group and cu...