Mismatch in GL balance between FAGLB03 and FAGLL03

Issue:

General Ledger account balance displayed in transaction FAGLB03, may not match with balance for the same period shown on double clicking any cell in FAGLB03. or with transaction FAGLL03.

Causes:

There could be various reasons for mismatch between FAGLB03 and FAGLL03, Below are some of  the common reasons 

Reason One: Transaction Figures not updated 

Some documents were posted in entry view, but did not update the ledger totals  

Solution:

To identify and correct such documents, follow the steps below 

• Execute t-code FAGLF03 ( Program: TFC_COMPARE_VZ) to compare document and transaction figures in order to identify the documents in error
• If FAGLF03 identifies documents which are not posted to one or more ledgers, Execute t-code GLGCU1 (Program: RGURECGLFLEX) to update the transaction totals for the documents in error in the corresponding ledgers 

Reason Two: Incorrect negative postings 

Due to a program error, some debit line items may be displayed as credit line items in transaction FAGLL03 or some credit line items may be displayed as debit line items as shown in the screenshot below.This is usually for negative postings made due for reversals

Solution:
There could be various causes for this error,
Check the following SAP notes for resolution according to your system conditions

Note 1113114 - FAGLL03: Incorrect plus/minus signs for negative postings
Note 1163346 - FAGLL03: Incorrect plus/minus signs for negative postings(2)
Note 1170400 - Document splitting: Incorrect posting key in new G/L

Reason Three: Database Inconsistencies 

Inconsistencies in the database at various levels may cause the transaction totals and balance to differ.

Solution:

Several reports are provided by SAP to analyze database inconsistencies for relevant tables. 

Note 1155429 - Analysis:Posting keys/debit/credit indicators in FI-GL (new) 

The not above provides reports to detect and analyze database inconsistencies in new GL line items.

Conditions Copied from Last Purchase Order

While creating a Purchase Order, If Net Price of the order is found to be zero with the calculation schema, System checks data in the last purchase orders and copies values from the last PO. 

The following conditions must be met before system copies price from the previous purchase order 

1. An Info record exists for the Vendor, Material Combination at the purchase org/ plant. 
2. The last document is not a request for quotation.
3. The calculation schema of the last document is the same as the schema for the Purchase Order being created
4. Net Price of the purchase order is zero based on the calculation schema  

A copy function is executed to copy values from the last document. No checks are made for requirements for the calculation schema.

As a exception to the above, system does not copy the condition records of the subsequent settlement (condition class "C"); instead, they are always determined again to ensure that the condition records are consistent with the field contents 

The copy control can be disabled at user level by maintained EVO parameter as described in SAP Note# 675523

Issue/Solution: Offsetting Account in FBL3N/FAGLL03

Issue:
You need Customer / Vendor Number (KUNNR/LIFNR) to be displayed for the offsetting GL accounts in the GL account line item reports FBL3N or FAGLL03

Soultion
There is no standard configuration to achieve this.
Using Sort key in the GL account will not populate data from the offsetting account
This can be achieved by using a BTE or BADI as described in the following SAP Notes
Note 112312 - Line item: Display of offsetting a/c information
Note 1034354 - FAGLL03: Display of offsetting account information

Further, if Vendor Name or Customer Name are also needed
Refer to the BTE solution provided by Burak in the following SDN thread..
http://forums.sdn.sap.com/thread.jspa?messageID=7848056&tstart=0#7848056

Issue/Solution: Asset XXXXXXXXX-0000 in CoCd XX00: Error in fiscal year change

Issue:
When the user try to execute Asset Fiscal Year Change transaction AJRW, they get the following error

Message No.: AA707

Short Text
Asset &-& in CoCd &: Error in fiscal year change

Diagnosis
The fiscal year change in one asset has produced an error.

System Response
No fiscal year change will be performed for this asset, processing will be continued with the following asset.

Procedure
Determine the error message using the function 'fiscal year change' when displaying the asset values.

Also When they open Asset Explorer for the asset in error using transaction AW01N, they get the following error message

Message No.: AA634

Short Text
Correction to ordinary dep. greater than acc. dep. in area &

Asset affected:
Diagnosis
The line item cannot be posted, since the correction to ordinary depreciation in area exceeds the cumulative ordinary depreciation.

The error can occur during a transfer, a write-up, or post-capitalization.


Procedure
Correct your entry.

Solution:
1. Check all the planned deprication runs are posted in the fiscal year to be closed.
2. Check for incomplete asset master data with transaction code AVUA and correct any master data problems
3. Execute transaction ASKB - Periodic Asset postings, even if you do not have any depreciation areas which post periodically.

Information: Convert tcode FSE2 (Financial Statement Maintenance) to Current Settings

Requirement: Transaction Code FSE2- Maintain Financial Statements Versions is a configuration item by default and you need to convert it to current settings or a user transaction.

Solution:
The procedure to convert FSE2 from an IMG activity to a user transaction/current setting is outlined in SAP Note#200674- Fin.Statement Vrsn: Maintenance in production clients. This note cannot be applied using transaction SNOTE and the following manual activities need to be performed.

1. Change the SPRO settings for view V_T011 using SOBJ as outlined in SAP Note#135028 - Transfer IMG activity to Current Settings.
2. Further, Message FE-146, also needs to converted to an Information or Warning message, using OBA5 as outlined in SAP Note#109577 - Changing FS version although client not changeable.
The above activities may differ depending upon the SAP release.

Issue/Solution: Issuer details for paying company code XX01 are missing

Issue:
While generating a payment medium using the payment medium workbench (with t-code F110 or FBPM) the user get the following error message: "Issuer details for paying company code XX01 are missing"

Solution:
The issuer details need to be maintained through transaction FBZP in the node "Payment Method in Company Code".
Select the relevant company code and payment method combination and add text to the tab "Drawer on the form" in the Form Data.
The details to be filled varies depending upon the payment medium format in use
for example : White using MT103 SWIFT format the following details would be required
Field 1 - Name 1
Field 2 - Name 2
Field 3 - Address 1
Field 4 - Address 2

Issue/Solution: COPA Performance Improvement using Summarization Levels

Issue:
Very long processing time or frequent TIME_OUT errors while execution of COPA reports (KE30) or assessment cycles.

Solution:

1. Activate CO-PA log (T-Code KEDZ, Program: RKE_PROT_EVALUATE)

Purpose:
Any COPA report/cycle execution or data access from COPA tables would be recorded in the log after this activation. This allows SAP to analyze the CO-PA usage pattern /access information based on which automated summarization levels could be created to improve COPA performance.

Execution Steps:
Execute t-code KEDZ

• Enter the Operating Concern (PI02) and click “Activate” (Ctrl+F1)

2. Collect CO-PA log data for a few weeks or months. (T-Code KE30, KEU2, etc)
This will be done automatically by the system when COPA reports or assessment cycles are executed.
For quick resolution in reports with poor performance, you may choose to execute all COPA reports /cycles, for which performance improvement is required to update the log data.

3. Create Summarization levels proposal (T-Code: KEDVP, Program: RKETRERU)

Purpose:
In this step, the system would read the access log information as recorded in step 2 and present a proposal to create summarization levels according to the database access patterns identified in the COPA log.

Execution steps:
Execute t-code KEDVP

• Enter Operating Concern
• Select COPA Type (Costing Based /Account Based)
• Select the type of proposal to be created
  -Enhancement: Existing summarization levels are taken into account during optimization, and only additional summarization levels are proposed
  - Replacement: With this type of proposal, all existing summarization levels are ignored. The proposed summarization levels replace the existing levels. Even replacement proposal does not delete any existing summarization levels. However existing levels can be manually deleted using T-Code KEDV
• Select the period (select maximum period for which log data is available) for which logged COPA transaction data should be considered to create the proposal.
• Click “Create Levels” button to accept the summarization level proposal displayed

Note: The analysis can take quite a long time. If the program aborts during dialog processing, due to run time being exceeded, restart the program in background processing. To display the result when the program has completed, choose Display last proposal.

4. Build Summarization levels (T-Code: KEDU)

Purpose: Large volume of data available in COPA tables is organized into various summarization levels using this transaction, which allows for quick data access at the summary levels for various reports and cycle executions instead of the high time and system consuming process of direct data retrieval from COPA tables.

Execution Steps
Execute t-code KEDU

• Enter Operating Concern
• Choose type of Profitability analysis (Costing/Account)
• Select “Build new Levels”
• Execute in background mode only using menu option Program > Execute in Background (F9)
• Click “Immediate”
• Click “Save”

5. Wait for the summarization level build process to complete (T-Code: SM37)

Status of the background job scheduled in step 4 can be using t-code SM37 with job name “RKETRER


6. Schedule a Daily Background Job to refresh summarization level data (T-Code: KEDU/SM36)

Purpose: The summarization levels created above would hold only the data available in COPA tables as on 30 minutes before the build process. To update the summary tables with the latest transaction data, summarization level refresh process needs to be executed daily.

Execution Steps:
Execute t-code KEDU

• Enter Operating Concern
• Choose type of Profitability analysis (Costing/Account)
• Select “Refresh”
• Save as a variant “COPA Summarization Refresh”

Execute t-code SM36

• Click “Job Wizard” button
• Click Continue
• Enter a descriptive job name (example: COPA summarization refresh) and priority, leave the target server blank and click “continue”
• Select “ABAP Program Step” and click “Continue”
• Enter ABAP program name as “RKETRERU” and choose variant “COPA Summarization Refresh” and click “Continue”
• Do not select add additional steps and click “Continue”
• Select option “Date/Time” and click “Continue”
• Enter a scheduled start date and time (non- business hour) , Check “Periodic” and click “Continue”
• Select “Daily” and click “Continue”
• Click “Complete”

Notes:

- Report for which performance improvement is sought must be configured to use the summarization levels in the report option field for presummarized data
- Population of initial summarization level , could be a very time consuming job and hence it may require to be executed into multiple parts with different executions for different summarization levels.
- Do not execute t-code KEDV while trying to execute a background job for summarization level population using KEDU.

Issue/Solution: Accounting document posted without Profit Center even if Profit Center is mandatory in document splitting

Issue:
An accounting document is posted without profit center, segment or business area, even though it is mandatory field in the document splitting characteristic configuration. The system may not allow to reverse or clear such corrupt line items, and users may get the following error while trying to reverse of clear the erroneous document.
Balancing field "Profit Center" in line item 001 not filled

Erroneous line items thus posted would have blank Profit Center even in the general ledger view.
All such inconsistent documents may be found from table FAGLFLEXA - General Ledger: Actual Line Items, Profit Center=Blank

Solution:
Implement the following SAP Notes to prevent further occurrences of this issue
Note 1249888 - Simulate General Ledger: Incorr. data or dump MESSAGE_TYPE_X

To reverse any inconsistent documents which have already been posted erroneously before implementation of the above note, create an OSS message under the component FI-GL-GL-X

Issue/Solution: No profit center determined for withholding tax items after document splitting

Issue:
While making vendor payments using the automatic payment program (F110) or manual payment using F-53 , user receives the following error
Balancing field "Profit Center" in line item 002 not filled
Depending upon the document splitting characteristics defined in your system, the error may be for Segment, Business Area or any other field
for example
Balancing field "Segment" in line item 002 not filled
Balancing field "Business Area" in line item 002 not filled

Causes:
If Extended Withholding taxes applicable at the time of payment are being used , The standard splitting rules and transaction variant may not be able to identify the profit center/segment/business area for withholding tax line item which is automatically generated the during payment posting.

This is due to fact that the newly generated item may be considered as a base item category instead of a derived item category due to the document splitting configuration

Solution:
1. Identify the document type being used for the payment posting. For example KZ or ZP
2. Identify the transaction type and business variant being used for the document type found in step 1 from SPRO node " Classify Document Types for Document splitting" (SIMG_GLT0_T8G12). Most likely it would be Transaction Type : 1000 - Payments and Variant 0001 - Standard, unless you have defined your own transaction types and variants
3. Identify the document splitting method being used in your implementation from SPRO node "Activate Document Splitting" (SIMG_FAGL_ACTIV_SPLI) . Most likely to be 0000000012 or 0000000012
4. Go to the SPRO node "Define Document Splitting Rule" (FISL_PS_GBEB_SPLT_DC) and locate the header item with Splitting Method, Business Transaction and Transaction Variant identifies in step 1,2 and 3. For our example it would be 0000000012, 1000 - Payments, 0001 - Standard respectively
5. Add item category "05200 - Withholding Tax", into the "Item categories to be edited" list for the header selected in step 4.
6. Add "Base item categories" "02000 - Customer" and "03000 - Vendor" for item category "05200 - Withholding Tax".

Short dump in t-code CJ30 while updating budget

Symptom
When a user attempts to modify budget allocations to a project from transaction code CJ30, the following ABAP runtime error (short dump) is resulted.

Runtime Errors : MESSAGE_TYPE_X
System error in : OBP_GE
Report : LBPFCF81
Routine : BUDGET_FILL_TBPJA_XX

screenshots:

Cause*:

The above condition may result when a configuration change is made to the project profile using t-code OPS91

Solution:
1. Execute transaction CJBW to deactivate availability control for the concerned project
2. Reconstruct availability control using transaction CJBN
3. Maintain budget in CJ30.

* This is one of the causes, there can be various other reasons for such dump.

Add document header text (BKPF-BKTXT) to dynamic selection in FB03,FBL3N,FAGLL03

Requirement
Doc. Header Text to be added in the dynamic selection in FB03, FAGLL03 etc.

Solution
Refer to the reply from Jeccas_DJ on the following SDN thread
https://forums.sdn.sap.com/thread.jspa?threadID=357594&tstart=0

Incorrect occurances of record type 31 in BTL91 format

What is BTL91 format ?
BTL91 is foreign bank transfer format used in Netherlands
BTL91 is available is SAP DME as tree BTL91 of type PAYM, for use with Payment Medium Workbench (PMW) and other transactions.

What is record type 31?
Each file generated for BTL91 format contains footer records starting with constant '31'.
The record consists of currency wise summary of the detailed transfer records.
for example:
If the file contains 3 transactions for currency USD, 2 transactions for currency GBP and 1 transaction for currency INR ( in a single batch)
The BTL91 file generated for this example should contain three records of type 31, one each for USD,GBP and INR with the total transaction amounts for each currency.

Issue:
File generated from SAP program SAPFPAYM (T-code: FBPM) carries multiple record type 31 for same currency
For example: 2 records with USD, 2 records with GBP and 1 with INR for the example used above

Solution:
The issue of multiple records type 31 is caused due to a program error while generating the DME/PMW file
It can be rectified by the applying SAP Note 1136370 - DMEE PAYM: REGUH-SRTF1 is wrongly filled
Even after implementation of the above note, the problem may persist for the payment runs for which DME file has already been generated incorrectly. This is due to the fact that sort data for such payment runs is already stored in the system. To rectify such cases user may execute the program RFPAYM_RESET for these payment run to resent the payment medium information.

Cost Center not updated in General Ledger view, New GL tables

Issue
A Financial Accounting document has been posted in the system with multiple CO account assignment objects, and some Controlling account assignment objects of the entry view are not updated in general ledger view.
For example: A FI document is posted with a WBS element and a Cost Center, and the cost center is displayed in the entry view of the document (FB03) but not in general ledger view. The cost center is also not updated in table FAGLFLEXA and hence does not appear in GL line item display transaction FAGLL03 as well.
Even when New GL is active and Cost Center Update scenario (FIN_CCA) is assigned to the concerned ledger

Solution
This behavior occurs if the CO account assignment is statistical and not actual (real).
In the above example, If the WBS element involved in real, the posting to Cost Center would only be statistical and thus it would not be updated in New GL tables. However, if the WBS element involved is statistical, the posting to Cost Center would be real (actual) and it would be updated in general ledger view and New GL tables.

The following SAP Note provides details of this system behavior
Note 964686 - Transfer of statistical postings in CO to FI

References
Thanks to Radha and Sanil for answering this query on SAP forums at the following thread
https://forums.sdn.sap.com/thread.jspa?threadID=1305266&tstart=0

Report S_ALR_87012174 displays cleared items

Issue
The report S_ALR_87012174 - List of Customer Open Items , displays cleared items also.
(Program Name: RFDOPO10)

Solution
Implement SAP Note 1164663 - RFDOPO10: system incorrectly displays cleared items

Incorrect Book Value in Asset Explorer and Asset History Sheet

Module: FI-AA (Financial Accounting - Asset Accounting)

Issue: Incorrect book value in Asset Explorer and Asset History Sheet
Asset explorer: shows incorrect Fiscal year-end value
Retirement transaction of 594173,13 is not included in change

In the asset history sheet as on 31-12-2008 transfer using Transaction Type 340 is not subtracted from the book value at FY start to calculate the current book value

In the asset history sheet as on 30-11-2008 value of retirement transfer using Transaction Type 340 is subtracted from FY start book value to arrive at the currency book value

Table ANEP(Asset Line items) shows the correct net book value

Table ANLC (Asset Value Fields) displays incorrect values

Solution : Execute t-Code AS02, Open the asset master data and click the menu option Edit > Recalculate Values.

After Recalculation
Asset Explorer (Aw01n) shows the correct year end and change values

Asset history sheet as on 31.12.2008 also stands corrected

Table ANLC is Updated

BDC error when processing in Background

What is BDC?
BDC (Batch Data Communication) is an ABAP programming technique, which allows to record and playback SAP user transactions using an ABAP program
More information on BDC can be accessed at the following SDN Wiki link :
https://wiki.sdn.sap.com/wiki/display/ABAP/BDC

Various Modes of BDC execution ?
Once an BDC has been recorded using SHDB it can be run in an ABAP program by using statement CALL TRANSACTION
for example :
CALL TRANSACTION l_c_tcode USING i_bdcdata
UPDATE l_c_update
MODE l_c_mode
MESSAGES INTO i_bdcmsg

More details on the "CALL TRANSACTION" statement are available at the following SAP Help link :http://help.sap.com/abapdocu/en/ABAPCALL_TRANSACTION.htm

BDC Modes
An ABAP program may use one of the following common mode options for the call transaction statement
A - Execution of the transaction with display of each transaction screen
E - Execution in background with display of transaction screen only in the case of an error
N - Execution in background without display of transaction screens

A mode is generally used to run the BDC while the program is in development to test the exeuction of each screen of the transaction under various conditions. while the N mode is generally used for integration or performance test

Issues
Certain messages, like the ones listed below may appear as an information or warning message while a BDC is executed in A mode.
example : Field BSEG-ZTERM. is not an input field

Solution
A consultant should check all the conditions where the ABAP program may try to enter data in a field which may or may not be available for input depending upon inputs in previous screens of the transaction or otherwise.
All such inputs should be avoided or controlled by adding adequate program logic conditions in the ABAP code.
For Example :In transaction F-32, if no residual item is created, the Payment Term field ( BSEG-ZTERM) for the first line item of the FI document would not be available for input. but when a residual item is going to be created, the first line item would contain the residual amount to be posted and its Terms of Payment would be editable (depending upon field status group and document layout settings)Hence the above logic of determining the residual amount needs to added to the program logic