Skip to main content

Posts

Showing posts from October, 2024

~ Voucher

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...

~ P2P

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...

~ Orders

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.

Classic vs. New GL Acctng

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 vs. S/4

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...

~ CO Area Assignment and Currency Type Settings

~  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: ...

? CO Area Assignment

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...

~ Tolerance Groups

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...

~ Field Status Variant

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...