In SAP condition records are stored in condition tables.
Condition tables name has three digits. From 1 to 500 are reserved by SAP and from 501 to 999 are given to customer space. In the actual database a persistent data base table is created with “A” prefixed to the table number .i.e. condition table 980 creates a table with name A980.

 During the condition table creation required fields can be selected. Only the fields present in the field catalogue are available for selection in the condition table. Fields present in the KOMG table can be added to the field catalogue. By default SAP does not add all the fields of KOMG to field catalogue. KOMG table is a union of KOMP, KOMK tables. KOMK table contains the header information of the document (Sales order or Billing), KOMP contains item level information of the document (Sales order / Billing). New fields can be added to the KOMP, KOMK structures. To add the new fields to these structures, an append structure should not be created. To add a field to KOMP structure, field should be added to KOMPAZ structure, which is an include in KOMP structure. Similarly fields should be added to KOMKAZ structure.
 If it is required to create a condition table with a custom field the following steps should be followed.
 Add the field in KOMKAZ or KOMPAZ structure. If the field is at the header level, add the field to KOMKAZ, and if the field is at the item level add to KOMPAZ structure. This step should be done SE11 transaction.
Activate the structure.
Add the new field to field catalog.
Create the condition table.
Adding the field to field catalog and condition table creation can be done VOK0 transaction.
 At run time the custom field should be filled with the appropriate value. To to this the following user exits should be used.
 USEREXIT_PRICING_PREPARE_TKOMK in RV60AFZZ .
 USEREXIT_PRICING_PREPARE_TKOMP in RV60AFZZ.
 Below is an example to add sales representative , who is a partner at item level to KOMP structure.
 1. Go to Se11, and add the field WWSR1.

 2. Open the program RV60AFZZ using SE38 transaction.

 3. Add the field to field catalog. To do this go to VOK0 transaction. Then environment ? condition table ? field catalog.

 4. Create the condition table. To do this goto VOK0 transaction. Goto environment-> condition table create. Enter the condition table number 980 .

 Once the condition table is created, this table can be used in the access sequence. Access sequence is assigned to the condition type. Condition type is inserted in the required pricing procedure. Condition records can be created in VK11 transaction. All the condition records are created with reference to the condition type. As the condition type is linked to access sequence, and access sequence to condition table, system displays all the condition table assigned to access sequence , in the initial screen. User should select one table, and enter condition records.

MMPI - This is done to initialize the period for the company codes not for regular use. This will open your previous period which u have closed. T.code MMPI is used to open the old period in which you want to post. It is used for the first time when you start period after factory calendar settings.

MMPV - This will open your next period. It is done to close the current period and open the new period. If we enter the date or month in MMPV means we are opening that date or month by closing previous date or month. Never use MMPV without completing the transaction in previous month.For e.g. we have to open the JAN then for the given company we can close the DEC. In this way we can post our posting in JAN month.

MMRV - To Check the Current Period in company and to allow postings in previous periods. It is done when you have to display and view the previous period and current period. It is used to allow posting in a previous period as per your company requirement.

• RE:[sap-log-mm] Error in Method PO_POST while Saving PO ME21N
• RE:[sap-log-mm] Can I park and later post GRN
• Re: [sap-log-mm] Direct posting to material
• RE:[sap-log-mm] Mass Deletion of Purchase Requisitions
• RE:[sap-log-mm] Check table TFBEFU_CR: entry 10 does not exist
• RE:[sap-log-mm] Purchasing Info Records Automatic Creation Defaults
• Re: [sap-log-mm] ME062 Error During RFQ
• RE:[sap-log-mm] User already processing Purchase Requisition - how to unlock?
• RE:[sap-log-mm] Occurs Error message when create subcontract P/O
• [sap-log-mm] Entry 0402000131 Does Not Exist in VBUK (Check Entry)

In the integration of MM & FI i.e OBYC we have to assign a GL Account for the transaction key GBB- INV ( Inventory difference)
Generally on a periodic basis we conduct the Physical inventory verification which will revels the difference in actual physical quantity and the stock in system. The difference is taken as increase / decrease in stock.

Step 1:In SAP we have to create a Physical inventory document for all the material for which you want to conduct the verification in T code "MI01 - Create"
Step :2 Count the stock and enter the actual quantity in T code "MI04 - Enter" for the Physical inv doc created in first step
Step 3: Go to the T code " MI07 - Post" . This posts the difference to an GL a/c which was assigned in OBYC.

Configuration Step:
Go to FS00 To create GL A/C
GL Accounts – Increase / decrease of stock Accounts
Company code – TAST
Click on create field
Account group – Incomes
Select profit and loss accounts
Short text – Increase or decrease of stock Account
Long text – Increase or decrease of stock Account
Click on control data tab
Select line item display
Sort key – 001
Click on create/ bank / interest tab
Field status group – G030 (Chang in stock Account)
Press enter key and Save.

You carry out the results analysis for an object (sales document item, internal order, service order, maintenance order, WBS element) and use the settlement to transfer the results analysis data to Profitiblity Analysis (CO-PA) and Financial Accounting. The values in Financial Accounting or Profitiblity Analysis for individual periods do not correspond with the values that the system displays in the reports of CO-PC (Product Cost by Sales Order), CO-OM (Product Cost by Order) or of PS (Project Controlling).

The differences are often due to the fact that the results analysis was subsequently carried out for periods which have already been closed, without having first settled the newly determined results analysis data.

You can also carry out the results analysis if the periods in FI and CO are closed. For the results analysis, only the cutoff period of the results analysis always to be set separately is relevant (compare with Note 190816).

Example:
You carried out the results analysis and the settlement for an object in periods 6/2000 to 8/2000. On 15 September 2000, in period 9/2000, you carry out the results analysis for period 6/2000 again. With the standard Customizing, this causes the results analysis to re determine all of the results analysis data from period 6/2000 to Period 8/2000 again. (In standard Customizing, the 'End' parameter is set to 'M' in the valuation methods. For a different end indicator, you have to adjust the correction options discussed in this Note accordingly.) Since factors which are not periodic are also involved in the determination, the results analysis data typically changes with redetermination. The non-periodic influencing factors are status and planning data changes. For this reason, a results analysis in the update run for previous periods which have already been closed is not useful, as a rule, particularly as a settlement with a prior settlement period is not possible without first having reversed the settlements of the subsequent periods which had already been carried out.
After you have carried out the results analysis subsequently for period 6/2000, carry out the usual period-end closing for period 9/2000, that is, you carry out a results analysis for the object and afterwards you settle it. You can distinguish between two situations:

1. You entered a cumulated settlement rule (full settlement):

              The settlement for period 9/2000 groups together all of the results analysis data changes in periods 6/2000 to 9/2000 and posts these changes as a total to period 9/2000. Therefore, all of the changes relevant to Profitability Analysis in period 9/2000 are settled and all of the changes relevant to FI are posted to period 9/2000. The total of the results analysis data of the object in CO-PC/CO-OM/PS corresponds with the data in Profitability Analysis and FI, however, the periodic values of 6/2000 to 9/2000 differ.

2. You entered a periodic settlement rule:

              The settlement for period 9/2000 only groups together all of the results analysis data changes in periods 6/2000 to 9/2000 for the transfer to Financial Accounting and posts the total of these changes to period 9/2000. For the results analysis data changes relevant to profitability analysis, only the changes to period 9/2000 are settled. The changes to periods 6/2000 to 8/2000 are not settled. In Financial Accounting, the total of the values correspond with the results analysis data of the object in CO-PC/CO-OM/PS, the periodic values from 6/2000 to 9/2000 differ as they did in the first example. In Profitability Analysis, the total of the values do not correspond with the results analysis data of the object in CO-PC/CO-OM/PS, the periodic values only correspond with period 9/2000. The costs of sales and the revenues of the object were not settled completely.

The correction options depend on your requirements for the correspondence between the different modules (CO-PC/CO-OM/PS, CO-PA, FI). The description refers to the above example.

1. The totals of the values should agree in the current period 9/2000, they do not have to agree in the previous periods.
a) You have a cumulated settlement rule:
                       In this instance, you do not have to do anything. The totals of the values agree with the values of the last settlement for period 9/2000.

b) You have a periodic settlement rule:
                       Insert a full settlement rule and carry out the settlement for the current period 9/2000 again. The totals of the values now agree in the individual modules. SAP recommends using the full settlement as the settlement type for objects with revenue.

2. The values should agree in all of the periods.
a) You update line items for the results analysis (you can set this in Customizing of the results analysis version):

Reverse the line items of the results analysis dated 15 September 2000 (program SAPKKA13). The subsequent changes to the results analysis for periods which have already been closed are thus reversed again.

Carry out the results analysis for period 9/2000 again.

Carry out the settlement for period 9/2000 again.

b) You do not update line items for the results analysis:
                       You can only undo the results analysis changes for closed periods with considerable effort. You have no choice but to transfer the changed values to CO-PA and Financial Accounting. Note that results analysis data exists, that does not correspond with the historical status of the object in each of the periods, because of the non-periodic portions for periods 6/2000 to 8/2000. Here, you absolutely have to check whether this changed results analysis data may be transferred to CO-PA and Financial Accounting.

Reverse the settlement for periods 9/2000, 8/2000 and 7/2000 (in this order). You may have to reverse the settlement several times for a period, since the settlement reversal is a document reversal. You do not have to reverse period 6/2000. If necessary, you have to open the periods in FI and CO.

Carry out the settlement for periods 6/2000, 7/2000, 8/2000 and 9/2000 again (in this order).

You can prevent an unintentional overwriting of the results analysis data of closed periods by using the cutoff period of the results analysis (Transaction KKA0). For further information about this, refer to Note 190816.

Transaction : KKA0

Data FI Table Featured Material Ledger Sale Sap FICO TaxVAT Validation customer payment ntercompany reconcilliation account screen layout taxation GL vendor PR