Fiscal Year Variant

Assuming that you are newly implemention with go live date of Sept 1st 2006 and Fiscal year January - December, what will be the best way?
Would it be better to define a Shortened Fiscal year for Sept-Dec 2006 and then regular Fiscal years OR Define a full Fiscal year for the entire 2006 and future FYs

Normally, the best way is to keep it simple and leave the first year "normal" (12 + 4 months starting January). You convert old data as of August 31 (unless the client requests opening balance as of December 31, 2005 and then monthly movements - I have experienced both options) and then start normal bookings in month 9 on September 1.

We never tried shortened fiscal year in this context and it is surely not needed here. It just adds complexity.

If we create the normal Jan-Dec Fiscal Year for 2006 also, how will we handle the assets when we go live in Oct 2006? Do we load the book value at that time or we load the book value for January 2006 and depreciate in the system for January to September

The ordinary way is to load fixed assets which exist on September 30 (if you go live with AA module on October 1) with trans. AS91.
- First, you need to set in configuration that the last closed fiscal year for legacy data upload is 31.12.2005 and the last period for depreciation will be 9/2006. (Do it in IMG: Financial accounting - Asset accounting - Asset data transfer - Parameters for data transfer - Date specifications)

Within trans. AS91, you enter the following values:
- acquisition value and accummulated depreciation as of 01 January 2006
- all asset movements (acquisitions, retirements, but not ordinary depreciations) between January 1 and September 30 with their respective dates
- already posted depreciation in 2006 until September 30

Then you enter GL movements per month (either you temporarily change the asset reconciliation accounts for direct booking with trans. OAMK, then book with FB01 and finally reset with OAK5, or you book there directly with trans. OASV). This way, your asset accounts (acquisition value and accummulated depreciation) are the same as asset module as of September 30.

You can also let the system recalculate the depreciation from the beginning of the year, but then you may end up with a different value as of September 30 than your legacy system calculated. So, I would not recommend it unless there is no reliable source data.

Difference between Posting Key and Field Status Variant

What is the use of Field Status Variant. Why it is required?

What is the difference between "Posting Key Variant and Field Status Variant". Why both the things are required to define as both control the fields. What specific fields are controlled this fields.

'Posting Key Variant ' Controls- fields of Posting Key and 'Field Status Variant' controls fields of G/L Account.Fields of G/L Account which are controlled by FSV can see in T.Code OBC4 and Fields of Posting Keys in SPRO-FAGS-Document- Line Item. Both can controls common fields, then SAP applies 'SDRO' rule.

SDRO rule. The fields can be Suppressed, Displayed, Required, Optional.

Posting is key controls
- which type of accounts can be posted to
- whether the line item is debit or credit
- and the field status of the document line item

Where as FSG (group into Field status Variant) controls only the the document line item for that account.

There are only three field status options during document entry:
- Suppressed
- Required
- Optional

If both Posting key and FSV has the same field as Required and optional, system uses the link rules, takes the one which has the highest priority(in this case required).

But in case of Master record Field status which is controlled by Account Group, there are 4 options of field status:
- Suppressed
- Display
- Required
- Optional

Account group defines:
a. length of gl account number
b. no. ranges of the gl account numbers
c. field status of the GL account master data in the company code segment.(which fields to appear when you create a gl account) (to control...double click on your GL account group in Screen transaction code OBD4)

Posting key defines:
a. whether the line item is a debit or credit
b. to which type of account the amount should be posted to(ex: when you use posting key 40, you will be able to post to gl accounts. When you use Posting key 01, you will be only able to post to customer account.
c. document screen layout during posting of a document. (which fields to appear in a document...double click on the posting key and select field status and make the entries as required /optional etc)

Field status group defines:
Document screen layout during posting of a document. (which fields to appear in a document...double click on the field status group and select fields and make the entries as required /optional etc)

LOGIC: you assign field status variant to the company code, FSV is a bundle of field status groups.

ex: in FSG G001 you have made the text as required entry...you assigned the field status group g001 to cash account..so when you use cash account and try to post a document it will definitely prompt you to enter the text (text made as required.)

Both FSG and PK control the same feilds in a document.There is no dominance between FSG and Posting keys..but we should know the allowed combinations....

If text is made required in PK and suppressed in FSG..the system will issue a error msg..Rules for PK...and FSG....is set incorrectly for SGTXT field.

Permissable combinations:

Pk R/S O/S R/o R S O

FSG S/R S/O o/r R S O

Result e SD RD NP NP NP

R = required
s = suppressed
e = error
SD = Suppressed dominates
Rd = required dominates
np = no problem.