Automatic account determination - General Modifiers

Hi,
While creating service orders, if we make use of service master, then the system picks the G/L account based on the valuation class that we mention in the service master code.(We make settings in GBB with specific General modifier and valuation class combination).
1. As there is more than 1 General modifier available for a particular movement type(in Tcode OMWN), how to choose the correct General Modifier in OBYC?
2. In case we do not use service master codes, how will the system pick the G/L account?
3. What are Other fields like Val.string,Mvt,Cns etc in T code OMWN used for?
Thanks.

Hi,
Check link how default G/L picks in service PO creation:
Default G/L acct and Cost center in service PO with added Freight line also
Regards,
Biju K

Similar Messages

  • Automatic Account Determination for Sale order related PO

    Dear all,
    I am creating a purchase order with Account Assignment Category "C" (Sale Order).  The system asks for GL Account which I don't want the user to enter.  I would like to configure the GL account through automatic account determination.  In which Trans Key/General Modifier I have to assign GL Account for the Purchase order with Account assignment "C"
    Please suggest,
    Regards,
    S.Suresh

    Hi Suresh,
    Asssign one Account modifier For example ZBR in OBYC for GBB key
    with valuation class and your default account
    Then go to SPRO >purchasing>A/C assignment select C go to details and put
    Your valuation modifier as ZBR in that a/c assignment details
    So when you put a/c assignment as C system will auto default your G/L
    ACCORDING TO VALUATION CLASS IN OBYC
    Hope this will resolve your issue
    BR
    Diwakar
    reward if useful

  • Dfrnce in automatic account determination

    What is the dfrnce b/w automatic account determination with wizard and automatic account determination without wizard ?

    Welcome to the MM Account Determination Wizard!
    This wizard will ask you a series of questions which will help you to configure the MM account assignment environment.
    What is account determination?
    When you enter a goods movement, you do not have to enter G/L accounts since ERP automatically determines the correct accounts. ERP does this by using account information that you set up in advance in an area of Customizing known as "account determination". This wizard takes you through this pre-configuration process.
    What you need to know before you start:
    Depending on how you answer the questions on the following screens, the wizard may need to delete previous account configuration data. A warning will be given prior to any such deletions. No actual changes are carried out until the very end of the wizard session.
    The internal processing (transaction/event) key UMB is only shown for the price change transaction.
    Purchase account management postings are only shown in the case of goods receipts referencing purchase orders and in invoice verification.
    Accounts, cost centers, cost elements and other FI/CO data must be configured in advance.
    The wizard always sets the valuation class rule to "on" for the internal processing (transaction/event) keys AKO, AUM, BSV, BSX, EIN, EKG, FRL, GBB, and PRD.
    The wizard always sets the valuation grouping code to active.
    Restrictions:
    The wizard does not recognize non-standard account modifiers.
    Material Ledger postings are not taken into account.
    Account Determination Without Wizard
    In this step, you can make the settings for account determination in Inventory Management and Invoice Verification.
    Account determination without the wizard enables you to make a more complex configuration than account determination with the wizard, but requires that you are already familiar with the principle of automatic account determination in the ERP System.
    You can configure account determination with the wizard in the first instance, for example. Then, if the wizard does not meet your company's account determination requirements, you can work without it.
    Detailed documentation on account determination is contained in the step Configure automatic postings.
    Hope this will help.....

  • What is the user exit for automatic account determination in PO

    Hi Experts
       I ned to know  what is the user exit for automatic account determination in PO
    my client needs the document type to defines Account Assignment Category.
    choosen a document type Account Assignment Category is defined automatically.  you can't choose
    a wrong  Account Assignment Category from the drop down list.
    thanks form you help.

    If this is the case than why don't you use the Transaction variant
    SHD0: http://www.mortenhjorthnielsen.dk/Security/transactionvariants.htm
    If you have knowledge of Transaction variant then you can use SHD0 tcode and generate the transaction using default type and give that transaction to user instead of ME21N so they will not have the issue.
    The exact solution for your problem is as follows
    Go to Tcode SHD0 and enter the transaction variant
    In T code field enter ME21N and then enter the ZXXXX or the name you want to keep in transaction variant field and hit create button
    This will take you to ME21N transaction and here you just enter the data but make sure you enter the A/c which you want to default.
    Once you finish system will save this one as a variant
    Every time you hit or enter the pop up screen comes here you just hit enter and whichever data you want to default that you have to select in the Popup by checking the Box
    W content and output only for your case the field XXXXXXXX should be selected for W content and output only
    Make sure you have value 1 in contents field
    If not then restart the variant again and on the ME21Nscreen reselect the invoice field
    Later exit and save (save in the object which you can transport)
    Then from SHD0 transaction select GOTO create variant transaction and here you careate the tcode and use that tcode for ME21N (e.g ZTRAN - For specifix sto)

  • Transaction Code to see all automatic account determination GL

    Hi All
    Please let me know the Transaction Code to see all automatic account determination GL like FI -GL integration with other modules/ submodules like AA,MM,SD, FM,CM etc. I tried with FBKP, but it is not giving all.
    Regards
    Sekhar

    Hi
    OMWB  will give  you  account determination by  parameter selections combinations  viz,
    1)  plant / material / movement types
    2) by company code / valuation area
    3) the  account  determination in  OBYC  can also be seen here.
    Thanks
    kamala

  • Automatic Account Determinations

    Dear SAP Guru:
    I have created the PO:
    Goods Cost = 100
    Freight Cost = 10
    I have posted GR that posted the account:
    Stock of Spare Parts   100
          GR/IR Goods          100-
    But my requirement when the GR made:
    Stock of Spare Parts  110
       GR/IR Goods            100-
       Freight                        10-
    In my configuration M/08, for "Freight" :
    AccKey = FRE
    Accruals = ZFR 
    In my configuration OBYC for "ZFR", I assigned Debit/Credit G/L
    What is possible reason or what to do for my configuration.
    Thanks ,
    Shoyeb
    Edited by: AMShoyeb on Dec 5, 2011 11:21 AM

    P1119705 wrote:
    Dear SAP Guru:
    >
    > I have created the PO:
    >
    > Goods Cost = 100
    > Freight Cost = 10
    >  
    > I have posted GR that posted the account:
    >
    > Stock of Spare Parts   100
    >       GR/IR Goods          100-
    >
    > But my requirement when the GR made:
    >
    > Stock of Spare Parts  110
    >    GR/IR Goods            100-
    >    Freight                        10-
    >
    > In my configuration M/08, for "Freight" :
    >
    > AccKey = FRE
    > Accruals = ZFR 
    >
    > In my configuration OBYC for "ZFR", I assigned Debit/Credit G/L
    >
    > What is possible reason or what to do for my configuration.
    >
    > Thanks ,
    > Shoyeb
    >
    > Edited by: AMShoyeb on Dec 5, 2011 11:21 AM
    hi
    For this you have to remove the acc.key and put the accrual key tick mark in your fright condition in m/06 in control data2 view
    for FRE in obyc given the fright g/l account.

  • Valuation and Account Determination...

    Hello,
              Can anyone help me to get some of the functional implementing questions on "Valuation and Account Determinationa" ....
    Thanks
    Priyanka

    Hi,
    In SAP every movement of goods is followed by one movement type and movement type trigged transaction event keys. G/L account assignment and G/L account assigned to transaction event key (OBYC). GR & IR will updated by movement of goods only. In Account Determination, respective G/L accounts assigned to your chart of account,relevant to business transactions keys(Example:BSX,PRD,FRE,GBB),Account modifier(Example:BSA,VBR) and Valaution Calsss.If all are assigned then you would not face any problems during your posting of GR,IR etc..........
    Configuration of Automatic Account Determination with T.Code are as follow:
    1.OMSK: valuation Class with Account category reference,
    2.OMWM: Active Valuation Grouping Code,
    3.OMWN: Active Movement type with G/L account,
    4.OMWD: Active Valuation Area,
    5.OMWB: Active Chart of account,Valuation Grouping Code,Account Grouping Code,Valuation Class and G/L acocounts
    In OMWB or OBYC
    Click TE key and enter Chart of account and then save the Roles 1st for
    1.Debit/Credit
    2.General modification
    3.Valuation Modif
    4.Vakuation class
    And then enter respective critetia for that TE key and save.
    If assignment(Chart of account,Valuation Grouping Code,Account Grouping Code,Valuation Class and G/L acocounts are correct and u would not face any problems in G/GI/IV.
    For more check the links:
    http://www.sap-img.com/materials/general-test-of-sap-mm-knowledge.htm
    http://www.saptechies.com/category/financial-accounting/page/0
    http://e-mory.blogspot.com/2007/06/sap-mm-and-fi-doc-number-verification.html
    http://www.sap-img.com/materials/sap-mm-configuration-tips.htm
    http://moryhanry.com/sapmmfidocverify.html
    http://www.sapcustomization.com/document/fi_mm_integration.pdf
    Regards,
    Biju K

  • MM subcontracting Account determination

    Hi All,
    Any one knows MM subcontracting Account determination in OBYC?
    any help is appreciated..
    Thanks,
    Rau

    Hi,
    Hi,
    For Account Determination 5 major characteru2019s are as follow:
    1.Chart of Account,
    2.Valuation Class,
    3.Transaction Event Key,
    4.Valuation Grouping Code,
    5.Account Grouping Code/Account Modifier.
    Configuration of Automatic Account Determination with T.Code are as follow:
    1.OMSK: valuation Class with Account category reference,
    2.OMWM: Active Valuation Grouping Code,
    3.OMWN: Active Movement type with G/L account,
    4.OMWD: Active Valuation Area,
    5.OMWB: Active Chart of account,Valuation Grouping Code,Account Grouping Code,Valuation Class and G/L acocounts
    In OMWB or OBYC
    Click TE key and enter Chart of account and then save the Roles 1st for
    1.Debit/Credit
    2.General modification
    3.Valuation Modif
    4.Vakuation class
    And then enter respective critetia for that TE key and save.
    If assignment(Chart of account,Valuation Grouping Code,Account Grouping Code,Valuation Class and G/L acocounts
    are correct and u would not face any problems in G/GI/IV.
    The TE keys are:
    Expense/revenue from consumption of consignment material (AKO)
    This transaction is used in Inventory Management in the case of
    withdrawals from consignment stock or when consignment stock is
    transferred to own stock if the material is subject to standard
    price control and the consignment price differs from the standard
    price.
    u2022 Expenditure/income from transfer posting (AUM)
    This transaction is used for transfer postings from one material to
    another if the complete value of the issuing material cannot be
    posted to the value of the receiving material. This applies both to
    materials with standard price control and to materials with moving
    average price control. Price differences can arise for materials
    with moving average price if stock levels are negative and the stock
    value becomes unrealistic as a result of the posting. Transaction
    AUM can be used irrespective of whether the transfer posting
    involves a transfer between plants. The expenditure/income is added
    to the receiving material.
    u2022 Provisions for subsequent (end-of-period rebate) settlement (BO1)
    If you use the "subsequent settlement" function with regard to
    conditions (e.g. for period-end volume-based rebates), provisions
    for accrued income are set up when goods receipts are recorded
    against purchase orders if this is defined for the condition type.
    u2022 Income from subsequent settlement (BO2)
    The rebate income generated in the course of "subsequent settlement"
    (end-of-period rebate settlement) is posted via this transaction.
    u2022 Income from subsequent settlement after actual settlement (BO3)
    If a goods receipt occurs after settlement accounting has been
    effected for a rebate arrangement, no further provisions for accrued
    rebate income can be managed by the "subsequent settlement"
    facility. No postings should be made to the account normally used
    for such provisions. As an alternative, you can use this transaction
    to post provisions for accrued rebate income to a separate account
    in cases such as the one described.
    u2022 Change in stock (BSV)
    Changes in stocks are posted in Inventory Management at the time
    goods receipts are recorded or subsequent adjustments made with
    regard to subcontract orders.
    If the account assigned here is defined as a cost element, you must
    specify a preliminary account assignment for the account in the
    table of automatic account assignment specification (Customizing for
    Controlling) in order to be able to post goods receipts against
    subcontract orders. In the standard system, cost center SC-1 is
    defined for this purpose.
    Stock posting (BSX)
    This transaction is used for all postings to stock accounts. Such
    postings are effected, for example:
    In inventory management in the case of goods receipts to own
    stock and goods issues from own stock
    In invoice verification, if price differences occur in
    connection with incoming invoices for materials valuated at
    moving average price and there is adequate stock coverage
    In order settlement, if the order is assigned to a material with
    moving average price and the actual costs at the time of
    settlement vary from the actual costs at the time of goods
    receipt
    Because this transaction is dependent on the valuation class, it is
    possible to manage materials with different valuation classes in
    separate stock accounts.
    Caution :
    Take care to ensure that:
    A stock account is not used for any transaction other than BSX
    Postings are not made to the account manually
    The account is not changed in the productive system before all
    stock has been booked out of it
    Otherwise differences would arise between the total stock value of
    the material master records and the balance on the stock account.
    Revaluation of "other" consumptions (COC)
    This transaction/event key is only relevant to Brazil. It is used if
    a revaluation report is used for company codes in Brazil.
    The revaluation report uses the actual prices determined by the
    material ledger/actual costing to:
    Revaluate costs on the basis of actual prices
    Post the price differences arising from "other" consumptions
    (e.g. consumption to cost center) to a collective account
    This transaction/event key is needed to post the price differences.
    The account specified here is posted with the price differences for
    "other" consumptions.
    o documentation currently available.
    Small differences, Materials Management (DIF)
    This transaction is used in Invoice Verification if you define a
    tolerance for minor differences and the balance of an invoice does
    not exceed the tolerance.
    Purchase account(EIN), purchase offsetting account (EKG), freight
    purchase account (FRE)
    These transactions are used only if Purchase Account Management is
    active in the company code.
    Freight clearing (FR1), provision for freight charges (FR2), customs
    duty clearing (FR3), provision for customs duty (FR4)
    These transactions are used to post delivery costs (incidental
    procurement costs) in the case of goods receipts against purchase
    orders and incoming invoices. Which transaction is used for which
    delivery costs depends on the condition types defined in the
    purchase order.
    You can also enter your own transactions for delivery costs in
    condition types.
    External service (FRL)
    The transaction is used for goods and invoice receipts in connection
    with subcontract orders.
    If the account assigned here is defined as a cost element, you must
    specify a preliminary account assignment for the account in the
    table of automatic account assignment specification (Customizing for
    Controlling) in order to be able to post goods receipts against
    subcontract orders. In the standard system, cost center SC-1 is
    defined for this purpose.
    External service, delivery costs (FRN)
    This transaction is used for delivery costs (incidental costs of
    procurement) in connection with subcontract orders.
    If the account assigned here is defined as a cost element, you must
    Offsetting entry for stock posting (GBB)
    Offsetting entries for stock postings are used in Inventory
    Management. They are dependent on the account grouping to which each
    movement type is assigned. The following account groupings are
    defined in the standard system:
    AUA: for order settlement
    AUF: for goods receipts for orders (without account
    assignment)
    and for order settlement if AUA is not maintained
    AUI: Subsequent adjustment of actual price from cost center
    directly
    to material (with account assignment)
    BSA: for initial entry of stock balances
    INV: for expenditure/income from inventory differences
    VAX: for goods issues for sales orders without
    account assignment object (the account is not a cost
    element)
    VAY: for goods issues for sales orders with
    account assignment object (account is a cost element)
    VBO: for consumption from stock of material provided to
    vendor
    VBR: for internal goods issues (for example, for cost
    center)
    VKA: for sales order account assignment
    (for example, for individual purchase order)
    VKP: for project account assignment (for example, for
    individual PO)
    VNG: for scrapping/destruction
    VQP: for sample withdrawals without account assignment
    VQY: for sample withdrawals with account assignment
    ZOB: for goods receipts without purchase orders (mvt type
    501)
    ZOF: for goods receipts without production orders
    (mvt types 521 and 531)
    You can also define your own account groupings. If you intend to
    post goods issues for cost centers (mvt type 201) and goods issues
    for orders (mvt type 261) to separate consumption accounts, you can
    assign the account grouping ZZZ to movement type 201 and account
    grouping YYY to movement type 261.
    Caution
    If you use goods receipts without a purchase order in your system
    (movement type 501), you have to check to which accounts the account
    groupings are assigned ZOB
    If you expect invoices for the goods receipts, and these invoices
    can only be posted in Accounting, you can enter a clearing account
    (similar to a GR/IR clearing account though without open item
    management), which is cleared in Accounting when you post the vendor
    invoice.
    Note that the goods movement is valuated with the valuation price of
    the material if no external amount has been entered.
    As no account assignment has been entered in the standard system,
    the assigned account is not defined as a cost element. If you assign
    a cost element, you have to enter an account assignment via the
    field selection or maintain an automatic account assignment for the
    cost element.
    Purchase order with account assignment (KBS)
    You cannot assign this transaction/event key to an account. It means
    that the account assignment is adopted from the purchase order and
    is used for the purpose of determining the posting keys for the
    goods receipt.
    Exchange rate differences in the case of open items (KDM)
    Exchange rate differences in the case of open items arise when an
    invoice relating to a purchase order is posted with a different
    exchange rate to that of the goods receipt and the material cannot
    be debited or credited due to standard price control or stock
    undercoverage/shortage.
    Differences due to exchange rate rounding, Materials Management
    (KDR)
    An exchange rate rounding difference can arise in the case of an
    invoice made out in a foreign currency. If a difference arises when
    the posting lines are translated into local currency (as a result of
    rounding), the system automatically generates a posting line for
    this rounding difference.
    Consignment liabilities (KON)
    Consignment liabilities arise in the case of withdrawals from
    consignment stock or from a pipeline or when consignment stock is
    transferred to own stock.
    Depending on the settings for the posting rules for the
    transaction/event key KON, it is possible to work with or without
    account modification. If you work with account modification, the
    following modifications are available in the standard system:
    None for consignment liabilities
    PIP for pipeline liabilities
    Offsetting entry for price differences in cost object hierarchies
    (KTR)
    The contra entry for price difference postings (transaction PRK)
    arising through settlement via material account determination is
    carried out with transaction KTR.
    Price differences (PRD)
    Price differences arise for materials valuated at standard price in
    the case of all movements and invoices with a value that differs
    from the standard price. Examples: goods receipts against purchase
    orders (if the PO price differs from the standard pricedardpreis),
    goods issues in respect of which an external amount is entered,
    invoices (if the invoice price differs from the PO price and the
    standard price).
    Price differences can also arise in the case of materials with
    moving average price if there is not enough stock to cover the
    invoiced quantity. In the case of goods movements in the negative
    range, the moving average price is not changed. Instead, any price
    differences arising are posted to a price difference account.
    Depending on the settings for the posting rules for
    transaction/event key PRD, it is possible to work with or without
    account modification. If you use account modification, the following
    modifications are available in the standard system:
    None for goods and invoice receipts against purchase orders
    PRF for goods receipts against production orders and
    order settlement
    PRA for goods issues and other movements
    PRU for transfer postings (price differences in the case
    of external amounts)
    Provision for delivery costs (RUE)
    Provisions are created for accrued delivery costs if a condition
    type for provisions is entered in the purchase order. They must be
    cleared manually at the time of invoice verification.
    Taxes in case of transfer posting GI/GR (TXO)
    This transaction/event key is only relevant to Brazil (nota fiscal).
    Revenue/expense from revaluation (UMB)
    This transaction/event key is used both in Inventory Management and
    in Invoice Verification if the standard price of a material has been
    changed and a movement or an invoice is posted to the previous
    period (at the previous price).
    Unplanned delivery costs (UPF)
    Unplanned delivery costs are delivery costs (incidental procurement
    costs) that were not planned in a purchase order (e.g. freight,
    customs duty). In the SAP posting transaction in Logistics Invoice
    Verification, instead of distributing these unplanned delivery costs
    among all invoice items as hitherto, you have the option of posting
    them to a special account. A separate tax code can be used for this
    account.
    Input tax, Purchasing (VST)
    Transaction/event key for tax account determination within the
    "subsequent settlement" facility for debit-side settlement types.
    The key is needed in the settlement schema for tax conditions.
    Goods issue, revaluation (inflation) (WGI)
    This transaction/event key is used if already-posted goods issues
    have to be revaluated following the determination of a new market
    price within the framework of inflation handling.
    Goods receipt, revaluation (inflation) (WGR)
    This transaction/event key is used if already-effected transfer
    postings have to be revaluated following the determination of a new
    market price within the framework of inflation handling. This
    transaction is used for the receiving plant, whereas transaction WGI
    (goods receipt, revaluation (inflation)) is used for the plant at
    which the goods are issued.
    GR/IR clearing (WRX)
    Postings to the GR/IR clearing account occur in the case of goods
    and invoice receipts against purchase orders. For more on the GR/IR
    clearing account, refer to the SAP Library (documentation MM
    Material Valuation).
    Caution
    You must set the Balances in local currency only indicator for the
    GR/IR clearing account to enable the open items to be cleared. For
    more on this topic, see the field documentation.
    Thanks,
    Raja

  • MM Account Determination

    Hi,
               Can anybody explain total how many G/l Accounts, we will generally assign and please give the list including TE Key.. The reply will be highly appreciated...

    Hi,
    For Account Determination 5 major characteru2019s are as follow:
    1.Chart of Account,
    2.Valuation Class,
    3.Transaction Event Key,
    4.Valuation Grouping Code,
    5.Account Grouping Code/Account Modifier.
    Configuration of  Automatic Account Determination with T.Code are as follow:
    1.OMSK: valuation Class with Account category reference,
    2.OMWM: Active Valuation Grouping Code,
    3.OMWN: Active Movement type with G/L account,
    4.OMWD: Active Valuation Area,
    5.OMWB: Active Chart of account,Valuation Grouping Code,Account Grouping Code,Valuation Class and G/L acocounts
    In OMWB or OBYC
    Click TE key and enter Chart of account and then save the Roles 1st for
    1.Debit/Credit
    2.General modification
    3.Valuation Modif
    4.Vakuation class
    And then enter respective critetia for that TE key and save.
    If assignment(Chart of account,Valuation Grouping Code,Account Grouping Code,Valuation Class and G/L acocounts
    are correct and u would not face any problems in G/GI/IV.
    The TE keys are:
    Expense/revenue from consumption of consignment material (AKO)
    This transaction is used in Inventory Management in the case of
    withdrawals from consignment stock or when consignment stock is
    transferred to own stock if the material is subject to standard
    price control and the consignment price differs from the standard
    price.
    u2022 Expenditure/income from transfer posting (AUM)
    This transaction is used for transfer postings from one material to
    another if the complete value of the issuing material cannot be
    posted to the value of the receiving material. This applies both to
    materials with standard price control and to materials with moving
    average price control. Price differences can arise for materials
    with moving average price if stock levels are negative and the stock
    value becomes unrealistic as a result of the posting. Transaction
    AUM can be used irrespective of whether the transfer posting
    involves a transfer between plants. The expenditure/income is added
    to the receiving material.
    u2022 Provisions for subsequent (end-of-period rebate) settlement (BO1)
    If you use the "subsequent settlement" function with regard to
    conditions (e.g. for period-end volume-based rebates), provisions
    for accrued income are set up when goods receipts are recorded
    against purchase orders if this is defined for the condition type.
    u2022 Income from subsequent settlement (BO2)
    The rebate income generated in the course of "subsequent settlement"
    (end-of-period rebate settlement) is posted via this transaction.
    u2022 Income from subsequent settlement after actual settlement (BO3)
    If a goods receipt occurs after settlement accounting has been
    effected for a rebate arrangement, no further provisions for accrued
    rebate income can be managed by the "subsequent settlement"
    facility. No postings should be made to the account normally used
    for such provisions. As an alternative, you can use this transaction
    to post provisions for accrued rebate income to a separate account
    in cases such as the one described.
    u2022 Change in stock (BSV)
    Changes in stocks are posted in Inventory Management at the time
    goods receipts are recorded or subsequent adjustments made with
    regard to subcontract orders.
    If the account assigned here is defined as a cost element, you must
    specify a preliminary account assignment for the account in the
    table of automatic account assignment specification (Customizing for
    Controlling) in order to be able to post goods receipts against
    subcontract orders. In the standard system, cost center SC-1 is
    defined for this purpose.
    Stock posting (BSX)
    This transaction is used for all postings to stock accounts. Such
    postings are effected, for example:
    - In inventory management in the case of goods receipts to own
    stock and goods issues from own stock
    - In invoice verification, if price differences occur in
    connection with incoming invoices for materials valuated at
    moving average price and there is adequate stock coverage
    - In order settlement, if the order is assigned to a material with
    moving average price and the actual costs at the time of
    settlement vary from the actual costs at the time of goods
    receipt
    Because this transaction is dependent on the valuation class, it is
    possible to manage materials with different valuation classes in
    separate stock accounts.
    Caution :
    Take care to ensure that:
    - A stock account is not used for any transaction other than BSX
    - Postings are not made to the account manually
    - The account is not changed in the productive system before all
    stock has been booked out of it
    Otherwise differences would arise between the total stock value of
    the material master records and the balance on the stock account.
    Revaluation of "other" consumptions (COC)
    This transaction/event key is only relevant to Brazil. It is used if
    a revaluation report is used for company codes in Brazil.
    The revaluation report uses the actual prices determined by the
    material ledger/actual costing to:
    - Revaluate costs on the basis of actual prices
    - Post the price differences arising from "other" consumptions
    (e.g. consumption to cost center) to a collective account
    This transaction/event key is needed to post the price differences.
    The account specified here is posted with the price differences for
    "other" consumptions.
    o documentation currently available.
    Small differences, Materials Management (DIF)
    This transaction is used in Invoice Verification if you define a
    tolerance for minor differences and the balance of an invoice does
    not exceed the tolerance.
    Purchase account(EIN), purchase offsetting account (EKG), freight
    purchase account (FRE)
    These transactions are used only if Purchase Account Management is
    active in the company code.
    Freight clearing (FR1), provision for freight charges (FR2), customs
    duty clearing (FR3), provision for customs duty (FR4)
    These transactions are used to post delivery costs (incidental
    procurement costs) in the case of goods receipts against purchase
    orders and incoming invoices. Which transaction is used for which
    delivery costs depends on the condition types defined in the
    purchase order.
    You can also enter your own transactions for delivery costs in
    condition types.
    External service (FRL)
    The transaction is used for goods and invoice receipts in connection
    with subcontract orders.
    If the account assigned here is defined as a cost element, you must
    specify a preliminary account assignment for the account in the
    table of automatic account assignment specification (Customizing for
    Controlling) in order to be able to post goods receipts against
    subcontract orders. In the standard system, cost center SC-1 is
    defined for this purpose.
    External service, delivery costs (FRN)
    This transaction is used for delivery costs (incidental costs of
    procurement) in connection with subcontract orders.
    If the account assigned here is defined as a cost element, you must
    Offsetting entry for stock posting (GBB)
    Offsetting entries for stock postings are used in Inventory
    Management. They are dependent on the account grouping to which each
    movement type is assigned. The following account groupings are
    defined in the standard system:
    - AUA: for order settlement
    - AUF: for goods receipts for orders (without account
    assignment)
    and for order settlement if AUA is not maintained
    - AUI: Subsequent adjustment of actual price from cost center
    directly
    to material (with account assignment)
    - BSA: for initial entry of stock balances
    - INV: for expenditure/income from inventory differences
    - VAX: for goods issues for sales orders without
    account assignment object (the account is not a cost
    element)
    - VAY: for goods issues for sales orders with
    account assignment object (account is a cost element)
    - VBO: for consumption from stock of material provided to
    vendor
    - VBR: for internal goods issues (for example, for cost
    center)
    - VKA: for sales order account assignment
    (for example, for individual purchase order)
    - VKP: for project account assignment (for example, for
    individual PO)
    - VNG: for scrapping/destruction
    - VQP: for sample withdrawals without account assignment
    - VQY: for sample withdrawals with account assignment
    - ZOB: for goods receipts without purchase orders (mvt type
    501)
    - ZOF: for goods receipts without production orders
    (mvt types 521 and 531)
    You can also define your own account groupings. If you intend to
    post goods issues for cost centers (mvt type 201) and goods issues
    for orders (mvt type 261) to separate consumption accounts, you can
    assign the account grouping ZZZ to movement type 201 and account
    grouping YYY to movement type 261.
    Caution
    If you use goods receipts without a purchase order in your system
    (movement type 501), you have to check to which accounts the account
    groupings are assigned ZOB
    If you expect invoices for the goods receipts, and these invoices
    can only be posted in Accounting, you can enter a clearing account
    (similar to a GR/IR clearing account though without open item
    management), which is cleared in Accounting when you post the vendor
    invoice.
    Note that the goods movement is valuated with the valuation price of
    the material if no external amount has been entered.
    As no account assignment has been entered in the standard system,
    the assigned account is not defined as a cost element. If you assign
    a cost element, you have to enter an account assignment via the
    field selection or maintain an automatic account assignment for the
    cost element.
    Purchase order with account assignment (KBS)
    You cannot assign this transaction/event key to an account. It means
    that the account assignment is adopted from the purchase order and
    is used for the purpose of determining the posting keys for the
    goods receipt.
    Exchange rate differences in the case of open items (KDM)
    Exchange rate differences in the case of open items arise when an
    invoice relating to a purchase order is posted with a different
    exchange rate to that of the goods receipt and the material cannot
    be debited or credited due to standard price control or stock
    undercoverage/shortage.
    Differences due to exchange rate rounding, Materials Management
    (KDR)
    An exchange rate rounding difference can arise in the case of an
    invoice made out in a foreign currency. If a difference arises when
    the posting lines are translated into local currency (as a result of
    rounding), the system automatically generates a posting line for
    this rounding difference.
    Consignment liabilities (KON)
    Consignment liabilities arise in the case of withdrawals from
    consignment stock or from a pipeline or when consignment stock is
    transferred to own stock.
    Depending on the settings for the posting rules for the
    transaction/event key KON, it is possible to work with or without
    account modification. If you work with account modification, the
    following modifications are available in the standard system:
    - None for consignment liabilities
    - PIP for pipeline liabilities
    Offsetting entry for price differences in cost object hierarchies
    (KTR)
    The contra entry for price difference postings (transaction PRK)
    arising through settlement via material account determination is
    carried out with transaction KTR.
    Price differences (PRD)
    Price differences arise for materials valuated at standard price in
    the case of all movements and invoices with a value that differs
    from the standard price. Examples: goods receipts against purchase
    orders (if the PO price differs from the standard pricedardpreis),
    goods issues in respect of which an external amount is entered,
    invoices (if the invoice price differs from the PO price and the
    standard price).
    Price differences can also arise in the case of materials with
    moving average price if there is not enough stock to cover the
    invoiced quantity. In the case of goods movements in the negative
    range, the moving average price is not changed. Instead, any price
    differences arising are posted to a price difference account.
    Depending on the settings for the posting rules for
    transaction/event key PRD, it is possible to work with or without
    account modification. If you use account modification, the following
    modifications are available in the standard system:
    - None for goods and invoice receipts against purchase orders
    - PRF for goods receipts against production orders and
    order settlement
    - PRA for goods issues and other movements
    - PRU for transfer postings (price differences in the case
    of external amounts)
    Provision for delivery costs (RUE)
    Provisions are created for accrued delivery costs if a condition
    type for provisions is entered in the purchase order. They must be
    cleared manually at the time of invoice verification.
    Taxes in case of transfer posting GI/GR (TXO)
    This transaction/event key is only relevant to Brazil (nota fiscal).
    Revenue/expense from revaluation (UMB)
    This transaction/event key is used both in Inventory Management and
    in Invoice Verification if the standard price of a material has been
    changed and a movement or an invoice is posted to the previous
    period (at the previous price).
    Unplanned delivery costs (UPF)
    Unplanned delivery costs are delivery costs (incidental procurement
    costs) that were not planned in a purchase order (e.g. freight,
    customs duty). In the SAP posting transaction in Logistics Invoice
    Verification, instead of distributing these unplanned delivery costs
    among all invoice items as hitherto, you have the option of posting
    them to a special account. A separate tax code can be used for this
    account.
    Input tax, Purchasing (VST)
    Transaction/event key for tax account determination within the
    "subsequent settlement" facility for debit-side settlement types.
    The key is needed in the settlement schema for tax conditions.
    Goods issue, revaluation (inflation) (WGI)
    This transaction/event key is used if already-posted goods issues
    have to be revaluated following the determination of a new market
    price within the framework of inflation handling.
    Goods receipt, revaluation (inflation) (WGR)
    This transaction/event key is used if already-effected transfer
    postings have to be revaluated following the determination of a new
    market price within the framework of inflation handling. This
    transaction is used for the receiving plant, whereas transaction WGI
    (goods receipt, revaluation (inflation)) is used for the plant at
    which the goods are issued.
    GR/IR clearing (WRX)
    Postings to the GR/IR clearing account occur in the case of goods
    and invoice receipts against purchase orders. For more on the GR/IR
    clearing account, refer to the SAP Library (documentation MM
    Material Valuation).
    Caution
    You must set the Balances in local currency only indicator for the
    GR/IR clearing account to enable the open items to be cleared. For
    more on this topic, see the field documentation.
    Regards,
    Biju K

  • ACCOUNT DETERMINATION IN MM( OBYC)

    I HAVE NOT ANY IDEA OF INTREGATION OF MM PLZ HELP ME
    MOST PROBALY WHICH KEY USE AND WHICH GL ACCOUNT USE
    I M UNDERSTAND FOR FOUR STEP... BUT WHICH KEY USE FOR EXAMPLE
    AUA,BSA, PRD..........
    PLZ HELP ME
    I M WAIT FOR REPLY

    Hi Hiren,
    Following link would be helpful for your understanding:
    SAP MM Configuration Tips and Tricks: http://www.sap-img.com/materials/sap-mm-configuration-tips.htm
    General modification
    http://sap.ittoolbox.com/groups/technical-functional/sap-log-mm/automatic-account-determination-1359561
    http://www.simplysap.com/forums/threadflat.htm?tid=32
    Pls assign points as way to say thanks

  • Account determination in SAP?

    hii experts,
    Account determination is major concern in SAP.
    Whether account determination will be done only SAP MM consultant or any other module responsibilities in account determination?
    Becas SAP has more business scenario , each will have account determination ??
    So how ..
    Thanks

    Both FI and MM can do the account determination. FI does the account determination through OMWB and MM does it through OBYC.
    Automatic Account Determination
    This is perhaps the part that causes the most heartache for the FI Configurer.   For some reason, although it is an integration area, the FI team always ends up with responsibility for it.  To do a good job you need a reasonable understanding of :
    the business processes in the source modules
    the FI account postings that they should be generating (what sort of account should be debited or credited etc)
    the organisation structure and its relationships between the source modules
    the reporting requirements that are expected from the General Ledger or Profit Centre Accounting
    your chart of accounts
    Sounds daunting doesn't it ?  Here is a suggested approach ...
    The IMG section under GL / business transactions / integration will take you through all the necessary account determination for the automatic postings that the system may need to post.  You may not need all of these.You could maintain on an as needed basis.  As the project teams test or prototype their expanding functionality, the SAP system will look for the accounts to which it should post.  The error message and the SAP documentation and configuration does not always explain clearly which piece of account determination is used for which type of functionality, so it is sometimes difficult to be pro-active. 
    Being reactive has the benefit that hopefully each side (eg: MM and FI) can develop an understanding of what the business transaction is and therefore where it should be posting. Otherwise the MM person may not even be aware that he has generated a certain type of posting ! (You'd be amazed at some of the lack of ownership from a logistics consultant for the financial postings that they generate).
    I will be explaining each account determination area simply and clearly with posting examples
    SD to FI Account Determination (aka revenue account determination).  This and MM seem to confuse people the most.
    More later - This may take a while to complete........
    In the meantime, some general warnings:
    Whenever you change the field status settings for an account, ensure that you have verified that any automatic postings will be able to meet the requirements. EG: do not make business area mandatory if your system may make a posting which cannot determine and post the business area.
    Consider specifying that accounts that are posted to automatically can only be posted to automatically.  This will simplify reconciliation between the source module and the GL account should you need to do this.
    SD-FI Account Determination and Postings
    This is known in the IMG as "revenue account determination", but it covers a lot more than that (discounts, taxes etc).  This is what determines how the financial impact of your SD Billing document is posted into the FI General Ledger.
    The integration is controlled both in SD and in FI.
    In SD there is a awesome area of configuration called the pricing procedures.   The pricing procedure determines the final price quoted to the customer for a particular product.  This could be a complicated calculation taking into account the base price, any special prices or discounts that may apply to that scenario, taxes, freight charges etc.  These prices or charges are called 'condition types'.  This condition technique is used in a number of areas of SAP.
    For now all we need to know is that each condition type is assigned to an account key (or in the case of rebates two account keys).  You can assign multiple condition types to the same account key. There are a number of account keys that are pre-defined in the system. For example:
    ERF freight revenues
    ERL revenues
    ERS sales deductions
    EVV cash settlement
    MWS sales tax
    Now we start getting to the integration by mapping the account keys to GL accounts.  But it is not as simple as that. It can be as flexible (ie: as complex) as you want. Start off with the most simple approach.  Generally if one is using a good sales / revenue reporting tool (eg: CO-PA) then one does not need a lot of flexibility and variety in the GL accounts that are posted to.  The level of detail that you need in GL should be determined by your financial statement reporting requirements - you may end up with only one Revenue account - it is a good bet!
    So, taking the simple approach we would ignore most of the configuration possibilities : procedures, access sequences, condition tables etc  (Yes it is that 'condition technique' kicking in again.  Once you have worked through it once in one area and encounter it in another then hopefully you will be comfortable in knowing that most of the standard configuration can be left as is. )  
    We have to decide which access sequences we want to use (Five access sequences are defined in the standard SAP R/3 System). To keep it simple, let us assume we just use one - for example: the access sequence "chart of accounts/sales org./account keys".
    The chart of accounts part is standard in all account determinations, so let us look at the rest.  This access sequence allows us to specify different GL accounts for different Sales Organisations. 
    So if we had a billing document line item where the customer had some special deductions for one of the products he purchased, we could map accounts by Sales Organisation.  To make it even simpler a document is within one Sales Organisation so we have an overall mapping as follows:
    SD Line Item  Condition type SD Amount Account Key Sales Organisation GL Account
    1  Sales deduction for being such a nice guy $10 ERS 1000 800010 - Sales deductions for 1000
    Sales deduction for special promotion on particular product $15 ERS
    Base Revenue $200 ERL 800000 - Revenue for Sales Org 1000
      Total for item 1 $175  
    2 Base Revenue $100 ERL 1000 800000 - Revenue for Sales Org 1000
      Total for item 2 $ 100  
    Document Total $ 275  
    So the invoice that the customer gets (and that you can view in SD) will look something like:
    Item (Note this is the SD Invoice line item) Amount
    Item 1:  $175
    Item 2:  $100
    Total owing , 30 days terms etc:  $275
    The GL document posting that the system will make to FI will look something like this though:
    FI Line Item  Debit / Credit  Account Amount
    1 Debit (PK=01) Customer (AR Account) $ 275
    2 Credit (PK=50) Revenue (GL Account) -$ 300
    3 Debit (PK=40) Sales Deduction (GL Account) $25
    Balancing to 0 as all GL documents must....
    $0
    Note : There is no direct relation between an SD Line item and an FI Line Item - they are different things.
    Other considerations:
    Remember that if you are using business areas, then depending on your configuration there, the system may create additional FI line items if it needs to post to different business areas.  This may be even more of a reason why you do not need additional GL accounts.  If your Sales Organisations already map to different business areas, you could use the GL accounts for all Sales Organisations.
    Different access sequences will allow a broader variety of GL accounts (for example: by customer account) group. I strongly suggest having a good understanding of the reporting requirements expected to be supported from the General Ledger vs the SIS (Sales Information System)  or CO-PA (Profitability Analysis) or (CO-PCA) Profit Centre modules before you create too many GL accounts.  At the risk of repeating myself, the SD to FI account determination should only be as detailed as your statutory reporting requirements.   The reporting from other tools like Profitability Analysis are so much more flexible and powerful, you may never look at the General Ledger for internal profit reporting again except to do a reconciliation check.

  • Account determination for entry 0010 GBB not possible

    Hi,
    While doing the GR, the above error is displayed.
    Please guide.
    rgds,
    AJit

    Ajit,
    During GR automatic account determination takes place based on the materail type/valuation class assgned in the materail/controlling area/chart of accounts/GL account/Movement type.
    In your case system is not able to determine which GL account it has to hit. You need to set up the right GL account under GBB accounts for the account modifier and Valuation class combination mentioned in the error message. Please use transaction OBYC for this purpose.
    Regards,
    Prasobh

  • Account Determination- MM Purchasing

    Hi all,
    I'm unable to understand how exactly the Automatic Account Determination works, can any one please explain it from SAP implementation point of view.

    Hi,
    In SAP every movement of goods is followed by one movement type and movement type trigged transaction event keys. G/L account assignment and G/L account assigned to transaction event key in OBY T.code. GR,GI & IR will updated by movement of goods only.
    In Account Determination, respective G/L accounts assigned to your chart of account,relevant to business transactions keys(Example:BSX,PRD,FRE,GBB),Account modifier(Example:BSA,VBR) and Valaution Calsss.If all are assigned then you would not face any problems during your posting of GR,IR etc..........
    For Account Determination 5 major characteru2019s are as follow:
    1.Chart of Account,
    2.Valuation Class,
    3.Transaction Event Key,
    4.Valuation Grouping Code,
    5.Account Grouping Code/Account Modifier.
    You can Configure Automatic Account Determination with T.Code are as follow:
    1.OMSK: valuation Class with Account category reference,
    2.OMWM: Active Valuation Grouping Code,
    3.OMWN: Active Movement type with G/L account,
    4.OMWD: Active Valuation Area,
    5.OMWB: Active Chart of account,Valuation Grouping Code,Account Grouping Code,Valuation Class and G/L acocounts
    For more check the links:
    http://sapdup.peteandmegan.com/?p=19
    http://www.bluemarlinsys.com/ns/0603-03.asp
    SAP MM Automatic Account Determination
    Regards,
    Biju K

  • Reg: MM account determination

    can someone please provide the different (real time) structure for account determination in MM?

    No one can give you the information you are looking
    What is the Std SAP has given is same like real time.
    For Account Determination 5 major character’s are as follow:
    1.Chart of Account,
    2.Valuation Class,
    3.Transaction Event Key,
    4.Valuation Grouping Code,
    5.Account Grouping Code/Account Modifier.
    You can Configure Automatic Account Determination with T.Codes & Steps are are as follow:
    1.OMSK: valuation Class with Account category reference,
    2.OMWM: Active Valuation Grouping Code,
    3.OMWN: Active Movement type( types) with G/L account,
    4.OMWD: Active Valuation Area,
    5.OMWB: Active Chart of account,Valuation Grouping Code,Account Grouping Code,Valuation Class and G/L acocounts
    Note:
    In Account Determination, respective G/L accounts assigned to your chart of account,relevant to business transactions keys(Example:BSX,PRD,FRE,GBB),Account modifier(Example:BSA,VBR) and Valaution Calsss.If all are assigned then you would not face any problems during your posting of GR,IR etc..........
    http://www.sap-hefte.de/download/dateien/1159/110_leseprobe.pdf
    http://sapdup.peteandmegan.com/?p=19
    Thanks & Regards,

  • Transaction key / event key in account determination??

    hii
    I want to know what is transaction key and event key in account determination??
    Thanks

    HI,
    Transaction/event key (internal processing key) Posting transactions are predefined for those inventory management and invoice verification transactions relevant to accounting. Posting records, which are generalized in the value string, are assigned to each relevant movement type in inventory management and each transaction in invoice verification. These contain keys for the relevant posting transaction (for example, inventory posting and consumption posting) instead of actual G/L account numbers. You do not have to define these transaction keys, they are determined automatically from the transaction (invoice verification) or the movement type (inventory management). All you have to do is assign the relevant G/L account to each posting transaction. Account grouping (only for offsetting entries, consignment liabilities, and price differences) Since the posting transaction "Offsetting entry for inventory posting" is used for different transactions (for example, goods issue, scrapping, physical inventory), which are assigned to different accounts (for example, consumption account, scrapping, expense/income from inventory differences), it is necessary to divide the posting transaction according to a further key: account grouping code. An account grouping is assigned to each movement type in inventory management which uses the posting transaction "Offsetting entry for inventory posting". Under the posting transaction "Offsetting entry for inventory posting", you must assign G/L accounts for every account grouping, that is, assign G/L accounts. If you wish to post price differences to different price difference accounts in the case of goods receipts for purchase orders, goods receipts for orders, or other movements, you can define different account grouping codes for the transaction key. Using the account grouping, you can also have different accounts for consignment liabilities and pipeline liabilities. Valuation class of material or (in case of split valuation) the valuation type The valuation class allows you to define automatic account determination that is dependent on the material. for example: you post a goods receipt of a raw material to a different stock account than if the goods receipt were for trading goods, even though the user enters the same transaction for both materials. You can achieve this by assigning different valuation classes to the materials and by assigning different G/L accounts to the posting transaction for every valuation class. If you do not want to differentiate according to valuation classes you do not have to maintain a valuation class for a transaction.
    Regards
    KK

Maybe you are looking for

  • Two phones with same ID. How do I set up new account on one phone to begin using family share?

    sset up wife's phone with my Apple ID so we could share all music I downloaded. Now we want to use family share but I keep finding if we change her Apple id on her phone she will have to wait 90 days to start syncing using family share. Please help.

  • Using swc in AIR project built with CS4

    Hi, excuse my poor english, I hope I am in the good place. I use Flash CS4 to build an AIR 1.5 Application. In the library path of ActionScript 3 I add an swc (textLayout.swc) needed to display hebrew text. While developing with flash, it works fine.

  • Few errors while working with Oracle 9i developer suite.

    I am facing a few errors working with Oracle 9i developer suite. 1. while running forms we have to press "ctrl +F11" to execute a query. is there any other way of executing a query where the user can do it at a click of button or so? and similarly so

  • Run time data binding via FormCalc/JavaScript+wrong text formating

    Hello Everybody I need to print a text block with company details depending on company code (different details for different codes). I tried to use this code for event "calculate": if ($record.LS_HEADER.BUKRS == "1000") then $ = $record.COMP_DETAILS_

  • Thorowing error

    Hi Apo Masters, I am getting following when copying data from one version to another version through report it is throwing following error please suggest me. Date       Time     Message text