Fusion-5

Legal Entity and Legal Employer in Fusion Application Objective: In previous article, we saw how to create users and roles in fusion app. In this article we will see how the basic terms in Fusion apps that are used once the project is created. Legal Entities: It will be created via XLE (Legal Entity Configurator) UI and can be marked as PSU (Payroll Statutory Unit) or Legal Employer classification. Legal Employer: It is the employer from HR law point of view. It will only contain HR related information and not payroll tax information. For each legal employer created via XLE, a corresponding Organization Unit gets created in HCM Payroll Statutory Unit: Legal entity can be marked as Payroll Statutory Unit also. Using PSU we can group multiple legal employers so that statutory calculations can be performed at this level. A legal employer can only belong to one PSU and PSU is the highest level of the aggregation for the person. For each PSU created via XLE, a corresponding Organization Unit gets created in HCM with PSU as a classification. While creating Legal Entity marked as Legal Employer, Parent PSU has to be entered. So while creating payroll relationship this Parent PSU would be employee’s relevant PSU which is associated with employee’s legal employer. Tax Reporting Unit: Tax Reporting unit groups employee records so that they can be reported together for tax or other purposes. To create a TRU, users will need to enter registration information via XLE. Each time a Legal Entity is created in XLE, a primary Legal Reporting Unit is also created. Users have the option to define additional Legal Reporting Units if required and there is a parent/ child relationship between Legal Entity and Legal Reporting Units. HR Reports would be based on legal employers and reporting establishments within a legal employer. For Payroll Reports TRUs would be used, as PSU is an employer from Payroll perspective. TRU would be directly linked to the person’s terms and assignments via deduction cards. Legislative Data Group: An LDG defines the payroll and related data partition context for a user allowing customers to partition their Payroll data. A user can partition payroll data at a level that is relevant to their enterprise, i.e. at one of the following: ·  PSU level ·  Country level ·  Level between PSU and country Department: A Department can be any organization to which workers are assigned e.g. HR Department, IT Department etc. Difference between Legal Entity and Legal Employer : Legal entity will be created via Legal entity configurator also known as XLE user interface. It is without employee and is a dummy entity. Legal entity cannot be a legal employer. Legal employer contains PSU(Payroll Statutory Unit). PSU(Payroll Statutory unit) is “legal entity” that are responsible for paying workers, including payment of payroll tax and social insurance. The legal entity that has given privilege of PSU will be considered as Tax Reporting Unit. If there are 2 legal employer, there will be 2 data group to save data for each legal employer separately. For example: ·  In the above diagram, ABC Pvt. Ltd is an Organization. ·  L.E 1 i.e Legal Employer 1 is just below the Organization. ·  L.E 2 i.e Legal Employer 2 is the Legal Employer of US. It is country specific and will have its own payroll. ·  L.E 3 is legal employer of India. ·  Suppose India has 2 branches i.e one in Mumbai and the other one in Bangalore, the Mumbai branch is head office. So the Mumbai branch i.e L.E 3 will be parent and Bangalore branch i.e L.E 4 will be child. ·  As L.E 3 is a parent Employee so it will have payroll for L.E 4 employer as well. Note: Oracle uses Universal Time format(UTC) in fusion apps. Legislation code will describe the country where transaction takes place and accordingly the time and date can be recognised.

Financials need to be updated only in certain business steps and not throughout the Organizational proceedings. Inter-module integration hence helps in smooth running of the business throughout. Sales and distribution Module has its own set of data entries, tables, master data, programs, transaction code, processes, system, and so on. Every organization is structured in a different way. Points of integration of Sales and Distribution and Finance: 1.     The Sales Organization is to be matched to the Company Code. 2.     Master Data needs to be created (GL, Vendor, Customer, and so on) 3.     Integration Configuration VKOA SD-FI. SAP SD Master Data related to FI: 1.     Vendor Master 2.     Customer Master 3.     Material Master Data 4.     Bill Of Material 5.     Credit Management 6.     Pricing Conditions A company has contact with its business partners, who are customers and Business Partners. Data on each of the business partner is stored in a separate master record. These master data have three segments considering the integration of usage of master records in different modules. Customer Master Record Vendor Master Record Products/ Services. Products and services are combined in SAP under the term Material since information necessary for the management of a material and its stock, as well as its use, is maintained in the so-called material master record.  Let us understand the sales process and its integration of SD and FI. By assigning Sales organizations and plants you create a link between company codes and sales organizations. Within a company, code can be assigned to different sales organizations. Within a single company code  several sales organizations can be active. Business transactions can also be carried out between different company codes (for example, during intercompany sales processing.) Sales Process: ·  Sales Order ·  Delivery Goods Issue ·  Return Delivery & Credit Memo ·  Billing ·  Payment ·  Now as per the above process let us see at what point Financials are impacted. The Accounting entries posted in the above scenarios will be as follows: 1.     Sale Order – No FI entry gets triggered. 2.     Creating a Delivery Document – No FI entry gets triggered. 3.     Change a Delivery Document – No FI entry gets triggered 4.     Post Goods Issue- FI entry gets triggered of Good movement. The entry would be Cost of Goods Sold A/C                     Dr.             To Stock A/C                         Cr. 5.     Create Billing Document: FI entry is triggered as the Customer is impacted. The FI entry would be Customer A/C                                    Dr. To Sales Revenue A/C        Cr. 6.     Payment received: FI entry is triggered as the Final payment is received from the sales of product or services. Bank A/C                                           Dr.             Customer A/C                        Cr. The major process for determining the Accounting entries in FI through SD must be accessed through Pricing Procedures. The procedure will trigger the conditions and the Account keys, which need to be picked in a particular business process being performed. This will post the automatic accounting postings via SD route. The Finance users are not in picture and the SD users post SD transactions and the system posts the FI entries to the system updating the financials, the goods movements, and so on. The pricing procedure is a setting available in SAP that can determine a complex pricing calculation and conditional Tax or expense calculation which need to be picked at certain sales. Different sales processes occur in an organization, and we can make multiple pricing procedures. 7.     Direct Sales. 8.     Depot Sales 9.     Service Center Sales. 10.  Job Work. The pricing procedure can incorporate all the different permutations and combinations considering pricing of the sales material, the Taxes involved, the logistics expense, profit, and so on. The SAP Pricing Procedure screen example would be like: How GL accounts are triggered through the Pricing is shown by a simple flow below: •Company Code Segment

Successful Businesses require effective communication with all the parties involved. Communication is required at various levels whether it is a legal requirement or for internal and external requirements. SAP provided multiple standard correspondences from the system. Correspondence in sap can be requested from various screens from itself. You want to automate correspondences as much as possible to simplify these communications. Examples of various communications are as mentioned below: - Payment Advice - Notes to payee - Account Statement - Balance confirmation - Payment Reminders (Dunning) - Payment Difference - Document Creation - Periodic Bank Account Statement Configuration Steps for Correspondences Correspondence types: Every Day your company requires different kinds of correspondence, which is mapped in the SAP system by Correspondence types. Must be created for each and every correspondences required in the system Standard Correspondence types are as below: Payment Notice                                 SAP01 Account Statement                            SAP06 Individual Correspondence             SAP10 Open item List                                   SAP14 User Defined Configuration for Correspondence Types -          Required Information ·  Account Number ·  Document Number -          Additional Texts required -          Correspondence can be used cross company code wise -          Number of date fields required Forms: Every letter in SAP is created as a form. The layout of the letter used in correspondence is created as a form. Standard SAP forms are already provided in SAP. Customizing by copying these standard forms is possible. Programs: StandardPrograms exist in SAP to generate these output correspondences by fetching data from the system in accordance to the requested correspondences. Variants:To execute programs in background the selected variables are saved in the system as inputs so that it is not required to enter the same details repeatedly. Call Up Functions:To specify which correspondence can be used in conjunction to which online SAP function there is a configuration required for it is which is called the Call up function The Configuration steps can be described in a flow as below -Correspondence type is assigned to a print program a print program is assigned to a selection Variant and a Form. Defining Correspondence is done in three ways: The process steps to generate a correspondence is in two steps: Example of Requesting a Correspondence: Cash Journal in SAP Finance Purpose: There are numerous reasons why a business might record transactions using a cash Journal instead of a cash account. Daily cash balances are easy to access and determine. Mistakes can be detected easily through verification, and entries are kept up-to-date since the balance is verified daily. Usage: A cash journal is used as a financial journal that contains all cash receipts and payments, including bank deposits and withdrawals. Entries in the cash journal are then posted into the general ledger. Larger firms usually divide the cash book into two parts: the cash disbursement journal that records all cash payments, such as accounts payable and operating expenses, and the cash receipts journal, which records all cash receipts, such as accounts receivable and cash sales. A cash Journal, or petty cash log, is a ledger for keeping track of small cash purchases. Some small businesses find cash Journal especially useful because these companies tend to need small quantities of easily available supplies to make up for unpredictable shortfalls. Others, like tech companies, usually use their cash Journals less frequently because they are less likely to have urgent needs for tangible items. Cash Journal in SAP: Can create multiple cash journals in a Company Code as required by the Business. With this functionality for one company code - ·  A separate cash journal for each currency can be created. ·  Cash Journal can post to Vendor, Customer and General Ledger Accounts. ·  Run several cash journals in each company code. Configuration Steps: ·  Create Cash Journal: A 4 digit alphanumeric key can be given to each cash journal. While posting cash journal transaction, the particular cash journal in which the cash transaction needs to be posted to needs to be selected. Once the Cash journal is created, the following needs to be defined for the same. ·  Company Code ·  Currency in which the Cash journal is to be maintained. ·  Ledger to which the Cash journal posts. ·  G/L Account to which the Cash Journal Business transactions. ·  Document Types for: ·         GL to GL ·         Outgoing payments to vendors/Customers. ·         Incoming Payments to Vendors/Customers. ·         Create Business Transaction Types The various business transactions in a Cash Journal would be as below: ·         Expense (E) ·         Revenue (R) ·         Cash Transfer from Cash Journal to Bank (B) ·         Cash Transfer from Bank to Cash Journal (C) ·         Customers-Incoming/Outgoing Payment (D) ·         Vendor – Outgoing /Incoming Payment (K) ·         Create Business Transactions Business Transaction can be created in SAP in two places ·         Cash Journal itself, while creating the posting. ·         Customizing (IMG) ·         Account Determination Each Cash Journal can have a separate Cash Journal Account for postings in a Cash Journal. Also According to different business transaction the GLs can be configured with an offsetting Account. The derivation rules can be made for the Cash Journal Postings in Customizing (IMG).As General Ledger Accounts are impacted as per this configuration it is very important . Further it updates the Financials. ·         Number Range for Cash Journal Documents: Cash Journal Document Number range needs to be maintained and assigned to the Cash Journal for usage. Steps: Postings to Cash Journal Accounts can be as per below steps: ·         Select Company Code and Cash Journal. ·         Check the Opening Balance, Closing Balance, receipts, payments. ·         Enter a Business Transaction you want to post. (If not exist can create a new Business Transaction.) ·         Enter Currency, Amount, tax Code as required. ·         Simulate and Save the entry. ·         At the end of the day check the entries and post the entries, which will create follow on documents in FI. ·         Check the follow on FI entries created. ·         Print the Cash Journal if required. Ledgers in Cash Journal: Separate Cash Journals can be created to facilitate different ledgers. Ledgers represent different Accounting principle followed by a company. For example IFRS, US GAAP etc. Hence while creating a Cash Journal in customizing the ledger for which the cash journal is maintained needs to be mentioned. Posting to Accounting Document in SAP: Cash Journal entries are made on a daily basis, the individual entry can be transferred to General Accounting or on a daily at the end of the day the total entries can be posted to Accounting. Once you save an entry the same remains in the Cash Journal once the Entries are selected and Post button is selected the entries create an Accounting document In Financial Accounting. The entries are as below. Journal entries in Accounting General Ledger: ·  Expenses: 1. ExpenseDr. To Cash Journal. Cr. ·  Revenue: 2. Cash Journal Dr. To Revenue. Cr. ·  Cash Transfer: ·  Cash Journal to Bank: 3. BankDr. To Cash Journal. Cr. ·  Bank to Cash Journal: 4. Cash JournalDr. To Bank. Cr. ·  Accounts Receivable: 5. Customer Payment ReceiptDr. To Customer. Cr. 6. Cash JournalDr. To Customer Payment Cr. ·  Accounts Payable: 7. Vendor Payment Dr. To Cash Journal. Cr. 8. Cash Journal Dr. To VendorCr. SAP screen shots: Go through the cash journal in the below SAP screen shot. Points to be considered are: 1.       Post and Save Clicks. 2.       Follow on Document. 3.       Opening/ Closing Balance. 4.       The green light in the posting means that the transactions have been posted to FI. 5.       The period for which the transactions are viewed.