Tag Archives: fiscal year variant

  • Setting Up The SAP Fiscal Year Variant For New Implementations

    Concept Of A Fiscal Year

    Every business has to follow a certain accounting cycle in order to record the business transactions. Some businesses follow a January to December cycle while other businesses may follow an April to March cycle. The choice of the accounting year or the fiscal year depends on the business requirements. The fiscal year is usually a 12 month period over which all the business transactions are recorded. At the end of this period financial statements are prepared to review the performance of the business. These business requirements for the accounting year can be mapped into SAP by using a two alphabet identifier called the fiscal year variant.

    A posting period is a period contained in the fiscal year over which transactions are recorded and clubbed together. Every transaction that is recorded in SAP has to be assigned to a posting period. Normally, every month is considered as a posting period which results in a total of 12 posting periods in a financial year. The special periods are meant for the year-end closing transactions. It provides flexibility to the accounting department to make adjustment entries while executing the year-end closing process.

    The fiscal year variant can be used to define the following:

    • Number of normal posting periods available in a financial year.
    • Number of special posting periods available in a financial year.
    • The duration of the accounting cycle i.e. a complete fiscal year or a shortened fiscal year.
    • Whether the fiscal year is the same as the calendar year.
    • Procedure to determine the current period while posting.

    The fiscal year variant is defined at the client level and is therefore available to all the company codes in the client. If there is more than one company code which uses the same fiscal year configuration, then the configuration need not be defined again and again for each of the company codes. The settings can be defined one as once as a fiscal year variant and can then be assigned to multiple company codes. This saves time during new implementations and also reduces the errors that may happen due to repeated manual entry. The fiscal year variant is first defined and then it is assigned to the company codes for which it is to be used.

    The fiscal year variant is one of the first configurations that is needed to be done while setting up the organizational structure in SAP. No transactions can be recorded without defining the fiscal year variant and assigning it to the company code. The fiscal year variant is used to define the normal and the special posting periods that are available for posting business transactions in a company code and the posting period variant is used to control which of these periods is open for posting.

    Navigate to the implementation guide menu as shown in the screenshot below or execute the transaction code OB29 from the SAP Easy access menu display the fiscal year variant configuration screen.

    Navigate To The Fiscal Year Variant Menu Path

  • Organizational Structure In SAP

    The fundamental purpose of any ERP system like SAP is to integrate the various business functions like finance, HR, logistics, etc. so as to facilitate the flow of information between them. This helps the entire business to function as a single coherent and cohesive unit and allows the senior management to understand the impact of a decision on the business as a whole.

    Any successful ERP system must allow the business processes to be efficiently mapped into it. SAP facilitates this mapping by providing standard organizational elements like client, company code, fiscal year variant, etc. All these organizational elements with their own significant roles are configured and integrated to represent the actual business processes.

    CONCEPT OF CLIENT

    The client is the highest level in the SAP organizational structure hierarchy. SAP stores master data as well as transactional data in tables in a database. Every client has its own set of master records and tables i.e. every client has its own set of data in the database. If changes are made to the data in one client, then the data in other clients is not affected.

    FIGURE 1 (SAP 3 CLIENT ARCHITECURE)

    SAP best business practices suggest the creation of at least the following three clients in any SAP landscape: