Account determination - loan taken

Dear expert,
Currently Iu2019m testing transaction FNM1 for loan given. But I hit an error u2013 u2018No posting details maintained for 0101 6147 1u2019. 6147 is a new flow type I had created for interest payable. The problem is, at account determination I already set :-
Payment transaction : X
Posting category : 42 u2013 p/l to subledger
Debit: 40 (interest payable)/ Credit: 14 (customer account)
But why the system check my flow type as u20181u2019 because u20181u2019 is not posted to customer? I want my posting debit GL & credit to customer account.
FYI, my product type u2018posting to fiu2019already setting to u20183u2019. And also, my setting u2018Assign flow types to condition group per applicationu2019, 6147 already set as application function 100-103 with payment transaction ID u20181u2019.
Anyone can tell me what could I be missing?
Thank you in advance

Hi ,
U try to post material from MB1C and to solve the above error u have to do the following changes:
OMS2-> choose your material from position button-> Select it> Click on Quantity/Value Updation under dialog structure> Choose your Value Area and Material Type> Uncheck Value Updation---> Save it and now try to post material .
Still if u find error reply me
Reward me points if helpful.
Regards,
Venuprasad

Similar Messages

Loans: Introduce vendor account during loan payments

Hello folks,
I have Loans managment module working fine for a bunch of flows. I would like to substitute a g/l account that we use during payment with a vendor account. Wondering if I could get some inputs on this.
We have receivable loans, not giving.
In the Accout Determination, I've configured a flow Z120 with Payment transaction 1 and a posting key 40 to the balance sheet account(276510) and 50 to a bridge account(275325). When this flow is posted, a payment request is created between the bridge account and the house bank's payment sub-account(175562). That would be a debit on bridge account(275325) and a credit on bank's payment sub-account(175562). So I run F111 and execute the payment. And then when the back statement comes in, an entry between 175562 and 175560 is made.
Now, I would like to replace this bridge account with a vendor. The primary reason is, the client wants to calculate withholding tax on every payment, interest and capital. Wondering what my options are?
In Account Determination, in the accounts section, in the g/l acct field, I don't know how to specify a vendor account against a acct symbol for the account determination to happen. There is only option for g/l account or +++++ for bank g/l accounts.
Should this be configured some place else. Not sure where I'm missing the part where I could use a vendor instead of using a g/l account as a bridge.
Also in SPRO, in the "Company code settings for product types", the FI posting field for my product is of type 4, which is "Actual records in subledger, posting in FI without customer". Should this be changed to 3, which is "Actual records in subledger, FI posting with customer" - wondering if this would open up a relation with a customer/vendor.
Any help greatly appreciated.
Thanks.

Thanks Kumar. Most of the steps got executed successfully.
Step 1:The moment I changed the FI posting from 4 to 3, I received an error in disbursement saying couldn't determine customer. I did not have a customer role in my BP. I set that with recon account and was able to do disbursement. The disbursement screen looks different too, with an added customer field populated and read-only. I think we are good there.
Step 2: I've ignored third party payment, I did revert it to uncheck the way it was.
Step 3: In Account determination, I configured one more posting specification for my Flowtype(Transaction type), payment transaction 'X', posting category 42. posting key 40(debit) for my interest account and 14(credit) for the new 2.4.4 symbol. I gave the BP/client's recon account g/l account against this new account symbol 2.4.4.
Now when I tried to do a post planned record, it wouldn't pick the newly created posting specification X. It still picks the one with payment transaction 1.
The documentation says, X would be picked if (a) posting for product type made via customer account and (b) payment transaction indicator set for the flow/condtion.
Here bullet (a) is true, because I could see the customer number when I do the disbursement. Now with regards to bullet (b), I've set done the following:-
-In flow type, I have the field "Payment request" checked.
-In condition type, I have the field Payt(Payment transaction) checked for my all my conditions.
-In the "Company code dependent settings for product type", I've checked the "Payment details" field.
-In the Main Loan Partner role for the BP, in the company code data, in the payment details tab, I've checked the Payment transaction and payment request fields, and entered information for payment method, housebank payer/ee etc.
Since the posting specification with payment transaction 'X' is not picked, I think something is missing on the payment transaction part.
One other interesting observation is, the moment I changed the FI posting from 4 to 3, the button "payment details" on the top of the screen has disappeared. Previously I used to specify payment details for each flow using the screen that comes off that button. So I assume now the payment details need to be taken care of in the BP/client level or flows level.
I'm not sure where I'm missing one fine detail.
Thanks a lot for your help in advance. I really appreciate it.

SD tax G/L account determination

First, I am not a Finance person nor do I know a lot about tax configuration. My background (relevant for this issue) is in S/D pricing and associated account determination. This is an S/D tax calculation and account determination issue for the United States.
I am attempting to generate a use tax in an internal service order and then to populate the correct G/L account(s) with these tax values. The service order, which is really just a sales order, generates a statistical value for the basis and then I have pricing condition types (condition class = D (taxes), condition category = D (Tax)) specified in the pricing procedure. These tax condition types are correctly calculating the tax amount.
Normally, to point to the correct G/L account for a pricing condition type, you would configure Account Determination within S/D. The simplest form would be the usage of the account key. The account key would be specified in the AccKey column and account determination configuration would point this key to the correct G/L account.
I understand (both from my own very recent experience and also from some of the information I have read on the internet) that things might be a little bit different when determining a G/L account for tax. Originally I specified two different account keys in the pricing procedure for the tax condition types (normally I would have specified just one). I specified MW1 through MW4 in the account key column for all 4 tax condition types and MWS in the accrual column. My intent was to update the tax expense account from MW1 4 and the tax accrual account from MWS (I realize I might have this backward).
When I created a billing document, SAP would not create the accounting document. It indicated (from my recollection) that it was missing a tax code for the G/L account for the first tax condition type (YTX1). Cutting through the history, it appears that SAP needs this code to point to the correct G/L account for S/D. I also learned that there is a tax code field in the tax condition record (VK11) where you specify this code.
I am actually familiar with the configuration and setup for use tax for A/P vendor invoices. I had to perform this setup very recently. In short, I know that the tax code determines what the tax rates will be and also determines the G/L accounts. I know how to setup a situation for tax accrual (this is setup found in tax code U1).
My questions are the following:
1) Is it true that I have to use the tax code to determine the G/L accounts for taxes generated in an S/D pricing procedure? Is it possible I am doing something wrong in the S/D account determination (at the moment, not quite sure what this would have been)?
2) Is it possible that I am adversely affecting account determination by specifying an account key in the accrual column of the pricing procedure for the tax pricing condition types?
3) If we do have to specify a tax code in the tax pricing condition records in order to use the FI tax procedure to point to the correct G/L account, do we also specify the tax rates in this FI tax code or do we still specify them in the S/D tax pricing condition records? It does not make sense to have to specify these rates twice. In short, what does SAP actually use for tax calculation?
Thanks a lot Ed Seigler

Hello Edward,
The tax code represents a tax category which must be taken into consideration when making a tax return to the tax authorities.
Tax codes are unique per country. The tax rate calculation rules and further features are stored in a table for each tax code.
SAP supplies a tax calculation procedure for each country. The procedure comprises a list of all common tax types with rules for tax calculation.
You have to define a separate tax on sales/purchases code for each country in which one of your company codes is located. Each code contains one or more tax rates for the different tax types.
Tax codes are actually configured in FI, but they play a significant role while creating tax condition records for a particular condition type.
Account keys in the account determination procedure connect the condition types to the relevant GL accounts. It doesnt have any impact on tax calculation. Its a procedure that is purely used to map GL accounts to the condition types.
Finally, i would suggest you to check at the condition record level, whether you have assigned the correct tax code to the appropriate condition type to rectify the error.
<b>REWARD POINTS IF HELPFUL.</b>
Regards
Sai

Activation of open item management for loans taken.

Dear Experts,
How to activate opem item management for loans taken. Also how to link a vendor to business patner if both are same.

Hello,
In your case, though balance is ZERO, they are not cleared against each other. It is the reason you are still facing the problem.
If ther is no open item management check box, then copy program RFSEPA02 to ZRFSEPA02 and append the initialization control.
If there is already open item management but you want to remove then copy RFSEPA03 to ZRFSEPA03 and append the initialization control.
Do the following steps:
1. Block the account for postings (all check boxes) in FS00
2. Run the customized Z program (Give the company code and account number)
3. Unblock the account for postings (remove all check boxes) in FS00
Take help from your ABAPer to stopping the initilization error check.
Hope this solves your issue.
Regards,
Ravi

Account determination for entry ECCA WRX 0018 ZZ1 9126 not possible

Hi all,
I am getting this error while doing GR using MIGO.
"Account determination for entry ECCA WRX 0018 ZZ1 9126 not possible"
There are 5 items in the PO and I get this error if I try to post all of them together. However if I try to post 1 item at a time, I am able to post all the materials individually.
I have checked the entry in OMWD, where valuation grouping code is maintained againt the valuation

Hi,
There are two confusions in your posting -
1) At first, the error message has indicated that SAP has verified the G/L account with valuation class 9126 and therefore, blank valuation class was not taken into account;
2) Secondly, if you can be able to post GR individually for each and very PO line item, then it has nothing to do with missing account assignment determination.
Are you pretty sure that you can post GR individually?. Did you actually maintain the valuation class for all of your material IDs in material master? If the answer for two questions is ''Yes'', then I would suggest you to debug your program to see why SAP has populated the error message only in case of GR for all material items.
Cheers,
HT

Dual "Define Account Determination" under SAP Banking ??

Hi, all
There are two "Define Account Determination" transaction under IMG SAP Banking:
1) SAP Banking -> Loans Management -> Transaction Management -> Update Types -> Define Account Determination, which is the same as the one under FSCM/Treasury and Risk Management.
2) SAP Banking -> Loans Management -> Functions -> Accounting -> General Ledger Update -> Define Account Determination
By trial and error, it seems that the later one should be used in Loans Management. Could anyone tell me under which conditions should the former one be used?
Thanks.

We use product types under both SAP Banking->Loans and FSCM/Treasury and Risk, but I never realized that the Account determination for FSCM was included in the IMG path for SAP Banking->Loans.... When I learned Loans configuration, I was pointed in the direction of the Account determination under Functions, and never noticed it elsewhere.
I poked around the IMG a little and it looks like you would use the Account Determination under Update Types if you set up your Loans for parrallel valuation - that is if you need to maintain multiple valuations for Loans. It appears the Account Determination under Update Types appears to be needed for the postings to the parrallel valuation areas.
We don't use parrallel valuation for Loans, so that would be another reason I've not needed the Account Determination under Update Types.
From what I'm seeing in the IMG, I would say that if you only need one valuation for Loans, like we do, then you shouldn't need the Account determination under Update Types - just the one under Functions.
Regards,
Shannon

Account determination not possible in MIGO

Hi Gurus,
While posting GR i am getting this error msg as "account determination for entry not possible"
Pls if any have worked on it give the solution asap
It will be highly appreciable
Thanks
Usha

Hi,
You have to click on the message, it will then give you full details.
What it will tell you is that for the combination of the following fields does not have a GL assigned to it in the auto account determination config
Chart of accounts
Transaction event key
Valuation area group
Account modifier
Valuation class
(some might be blank, the error message will show you the entry it is looking for)
Just make a note of the data for each of the above that it is trying to use.
At the bottom of the error message is a proceed button.
Click on this and (if you have authorisation) you will be taken to the config directly.
Just use the above data to go to the correct transaction event key and make sure that you add an entry for the right valuation area, account modifier and valuation class with the correct GL to be used.
Steve B

CIN - EXCISE ACCOUNT DETERMINATION

HI CIN experts,
I need ur valuable suggestion cin excise accounts determination.
The blw is the example of account determination ;
GRPO - 25930004
OTHR - 25930004 (SAME NBR)
DLFC- 14224023
Like this the gl numbers are assigned , can we assign as per abv ?? as per understanding the Debit entries are flown frm GRPO and Cr entries frm OTHR and DLFC...
so what's the benefit of keeping same gl nbr in GRPO and OTHR???
As well, if keep diff nbr agsinst OTHR compared to GRPO and what's impact? if i do return delviey it will hit on diff gl compared to GRPO nbr, in that case how to nullify?
Jay

Hi,
Please explain in details which account are taking abt. for GRPO , OTHR and DLFC there are many accouts.
And for accounting entries. the accounts are not taken from different Excise TT. for eg all accounts whether debit or credit will be taken from same excise TT for eg GRPO. the entries whether do debit or credit are dittermine from setting
Logistics - General->India->Account Determination->Specify Excise Accounts per Excise Transaction
here u give the accouting entries to be created and which gl accounts are pick from the Logistics - General->India->Account Determination->Specify G/L Accounts per Excise Transaction.
so check this setting.
eg for account entries..
GRPO          CR Credit     CLEAR CENVAT clearing account
GRPO          DR Debit     ONHOLD CENVAT on hold account
GRPO          DR Debit     RG23AED RG 23 AED account
GRPO          DR Debit     RG23AT1 RG 23 AT1 Account
GRPO          DR Debit     RG23BED RG 23 BED account
GRPO          DR Debit     RG23ECS RG 23 ECS Account
GRPO          DR Debit     RG23SED RG 23 SED account

MM role in Account determination

hii
What are major MM consultant roles in account determination.??
Explain in detail...?
Thanks

Hi MM Group,
SAP MM Role in Account Determination :
This account determination is for MM settings u2013 Rajgeetha
Account determination is based for combination of valuation grouping code, general modifier/account modifier, valuation class in SAP MM.
This will be defined for particular transaction event key. Transaction event key will inturn be defined for each movement type of SAP MM.
Basically GL account are assigned for certain combination of above.
To put down in flowchart format-
- Movement type-
- Transaction event key
- GL account determination (one debit and one credit)- based on below combination
- Valuation grouping code (see definition below)
- Account modifier (see definition below)
- Valuation class (see definition below)
SAP will see transaction is made in MM, it searches the transaction event key from movement types. Based on valuation grouping code, account modifier and valuation class, determination will be done for GL account for debit and credit.
Some definitions and assignments
1) SAP MM Valuation grouping code: It is maintained as part of plant configuration same for all plants within company code having same chart of account.
This will be applicable only if valuation control is active for organization
2) SAP MM Account modifier: This is defined in each movement type. There may be more than one account modifier per movement type based on combinations of different special stock, movement indicator, consumption type.
3) SAP MM valuation class: This is maintained in material master. Material type is taken from material master. Account category reference is taken from material type which in turn is assigned to valuation class. GL account are assigned to valuation class
Example:
Material 1016101 is received in stock for plant SEPC by movement 101 in SAP MM.
1) Valuation class determination from material master of 1016101.
2) Valuation grouping code determination based on plant SEPC
3) Account modifier will be taken from movement type 101
4) Transaction event key will be always BSX for inventory posting. (that is programmed) and also defined in movement type
5) In account assignment, for combination of above GL account determination as we saw in above hierarchy.
Hope, it is useful for you,
Regards,
K.Rajendran

"Account determination for entry CHFS BSX 37AP not possible" -goods receipt

I have a student using ECC 6.0 getting the following message when posting a goods receipt for a purchase order:
"Account determination for entry CHFS BSX 37AP not possible"
This is in the Fitter Snacker configuration phase 2 client, but now doing the configuration for the Marshall Muffler Company case. No other student has this message. I have checked everything that I can think of -- company, plant, purchasing organization, G/L account numbers, vendors, materials, quanity and value updating, valuation grouping code, automatic postings for inventory posting (BSX), controlling area, .. but cannot find anything amiss.
Can anyone help with this? We are client 625 on the moscow server at Chico. The student is user 625-037, using 37 as a prefix for the various components e.g. company code 37MM. One PO for exampe is 4500000116. The student has created a number of orders trying to get it to work. Strangely, the student did get one raw material received on one PO for a vendor earlier, but now cannot do so.

1st thing to do is understand the error message format. - comp. code - transac - valuation class. so you need to tackle BSX part.
goto transaction code OMS2 make sure the Mtype for Raw materials (RM) , Semifinished (SP) and Finished (FP) is selected for Quantity / Value updating tick box. You can check this by going clicking Quantity/valur updating on left hand panel.
then goto transaction code OBYC for BSX transaction , make sure your plant it is assign to the correct valuation classs 3000. save everything.
now try goto transaction code MIGO to cerate the GR again. Normally if you don't maintain the BSX properly, you bond to have similiar error for WRX. so please make sure that is also taken care off.
Now you should be fine creating the GR. Good luck.

Business transaction key in account determination..?

Hi all
Can anybody explain me in simple form form, what is business transaction key in account determination , for eg, GBB,BSA,BSX,PRD,VBR,.WRX....etc (Approximately 60 transaction keys in std SAP)
If i want to do configuration the for new client, what are all the business transaction key,,, How the configuration wil happen..?
Pls giv me expaination,
Reply will be rewardable..
Thanks
sap-mm

Hi MM,
Please Search in SDN threads solution is given already in lot of threads.
Go to SAP Library
SPRO> Help> SAP Library
Or go to SPRO> IMG> MM>Valuation and Account Assignment>Account determination> Account det without wizard> configure Automatic postings
Click on IMG ACTIVITY DOCUMENTATION
These transactions are important for Accounts.
Postings are made to G/L accounts automatically in the case of Invoice Verification and Inventory Management transactions relevant to Financial and Cost Accounting.
Example:
Posting lines are created in the following accounts in the case of a goods issue for a cost center:
Stock account
Consumption account
Agency business: income (AG1)
This transaction can be used in agency business for income deriving from commission (e.g. del credere commission). The account key is used in the calculation schemas for agency business to determine the associated revenue accounts.
Agency business: turnover (AG2)
This transaction can be used in agency business if turnover (business volume) postings are activated in Customizing for the payment types. The account key is specified in Customizing for the billing type.
Agency business: expense (AG3)
This transaction can be used in agency business for commission expenses. The account key is used in the calculation schemas for agency business to determine the associated expense accounts.
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.
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.
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.
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.
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.
Supplementary entry for stock (BSD)
This account is posted when closing entries are made for a cumulation run. This account is a supplementary account to the stock account; that is, the stock account is added to it to determine the stock value that was calculated via the cumulation. In the process, the various valuation areas (for example, commercial, tax), that are used in the balance sheet are taxed separately.
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.
Revaluation of other consumption (COC)
This transaction/event key is required for the revaluation of consumption in Actual Costing/Material Ledger.
Revaluation of consumption valuates single-level consumption using the actual prices determined in the Actual Costing/Material Ledger application. This revaluation can either take place in the account where the original postings were made, or in a header account.
The header account is determined using the transaction/event key COC.
Del credere (DEL)
Transaction/event key for the payment/invoice list documents in Purchasing. The account key is needed in the calculation schema for payment/settlement processing to determine the associated revenue accounts.
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.
Note
Due to special legal requirements, this function was developed specially for certain countries (Belgium, Spain, Portugal, France, Italy, and Finland).
Before you use this function, check whether you need to use it in your country.
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 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.
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:
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 Materials Management(AVR) (KDG)
When you carry out a revaluation of single-level consumption in the material ledger for an alternative valuation run, the exchange rate difference accounts of the materials are credited with the exchange rate differences that are to be assigned to the consumption.
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.
Exchange Rate Differences from Lower Levels (KDV)
In multi-level periodic settlement in the material ledger, some of the exchange rate differences that have been posted during the period in respect of the raw materials, semifinished products and cost centers performing the activity used in the manufacture of a semifinished or finished product are debited or credited to that semifinished or finished product.
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.
Accruals and deferrals account (material ledger) (LKW)
If the process of material price determination in the material ledger is not accompanied by revaluation of closing stock, the price and exchange rate differences that should actually be applied to the stock value are contra-posted to accounts with the transaction/event key LKW.
If, on the other hand, price determination in the material ledger is accompanied by revaluation of the closing stock, the price and exchange rate differences are posted to the stock account (i.e. the stock is revalued).
Price Difference from Exploded WIP (Lar.) (PRA)
If you use the WIP revaluation of the material ledger, the price variances of the exploded WIP stock of an activity type or a business process are posted to the price differences account with transaction/event key PRA.
Differences (AVR Price) (PRC)
In the alternative valuation run in the material ledger, some of the variances that accrue interest in the cost centers, are transfer posted to the semifinished or finished product.
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)
Price Differences (Material Ledger, AVR) (PRG)
When you carry out a revaluation of single-level consumption in the material ledger during the alternative valuation run, the price difference accounts of the materials are credited with the price differences that are to be assigned to the consumption.
Price differences in cost object hierarchies (PRK)
In cost object hierarchies, price differences occur both for the assigned materials with standard price and for the accounts of the cost object hierarchy. In the course of settlement for cost object hierarchies after settlement via material account determination, the price differences are posted via the transaction PRK.
Price Difference from Exploded WIP (Mat.) (PRM)
If you use the WIP revaluation of the material ledger, the price and exchange rate differences of the exploded WIP stock of a material are posted to the price difference account with transaction/event key PRM.
Price differences, product cost collector (PRP)
During settlement accounting with regard to a product cost collector in repetitive manufacturing, price differences are posted with the transaction PRP in the case of the valuated sales order stock.
This transaction is currently used in the following instances only:
Production cost collector in Release 4.0
Product cost collector in IS Automotive Release 2.0 (product cost collector in connection with APO)
Offsetting entry: price differences, product cost collector (PRQ)
The offsetting (contra) entry to price difference postings (transaction PRP) in the course of settlement accounting with respect to a product cost collector in repetitive manufacturing in the case of the valuated sales order stock is carried out via transaction PRQ.
This transaction is currently used in the following instances only:
Production cost collector in Release 4.0
Product cost collector in IS Automotive Release 2.0 (product cost collector in connection with APO)
Price Differences from Lower Levels (PRV)
In multi-level periodic settlement in the material ledger, some of the price differences posted during the period in respect of the raw materials, semifinished products, and cost centers performing the activity used in a semifinished or finished product, are transfer posted to that semifinished or finished product.
Price differences for material ledger (PRY)
In the course of settlement in the material ledger, price differences from the material ledger are posted with the transaction PRY.
Expense and revenue from revaluation (retroactive pricing, RAP)
This transaction/event key is used in Invoice Verification within the framework of the revaluation of goods and services supplied for which settlement has already taken place. Any difference amounts determined are posted to the accounts assigned to the transaction/event key RAP (retroactive pricing) as expense or revenue.
At the time of the revaluation, the amounts determined or portions thereof) are posted neither to material stock accounts nor to price difference accounts. The full amount is always posted to the "Expense from Revaluation" or "Revenue from Revaluation" account. The offsetting (contra) entry is made to the relevant vendor account.
Invoice reductions in Logistics Invoice Verification (RKA)
This transaction/event key is used in Logistics Invoice Verification for the interim posting of price differences in the case of invoice reductions.
If a vendor invoice is reduced, two accounting documents are automatically created for the invoice document. With the first accounting document, the amount invoiced is posted in the vendor line. An additional line is generated on the invoice reduction account to partially offset this amount. With the second accounting document, the invoice reduction is posted in the form of a credit memo from the vendor. The offsetting entry to the vendor line is the invoice reduction account. Hence the invoice reduction account is always balanced off by two accounting documents within one transaction.
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).
Expenditure/income from revaluation (UMD)
This account is the offsetting account for the BSD account. It is posted during the closing entries for the cumulation run of the material ledger and has to be defined for the same valuation areas.
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.
Inflation posting (WGB)
Transaction/event key that posts inflation postings to a different account, within the handling of inflation process for the period-end closing.
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.
WIP from Price Differences (Internal Activity) (WPA)
When you use the WIP revaluation of the material ledger, the price variances from the actual price calculation that are to be assigned to the WIP stock, an activity type or a business process are posted to the WIP account for activities.
WIP from Price Differences (Material) (WPM)
When you use the WIP revaluation of the material ledger, the price and exchange rate differences that are to be assigned to the WIP stock of a material are posted to the WIP account for material.
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.
GR/IR clearing for material ledger (WRY)
This transaction/event key is not used from Release 4.0 onwards.
Prior to 4.0, it was used for postings to the GR/IR clearing account if the material ledger was active. As of Release 4.0, the transaction is no longer necessary, since postings to the GR/IR account in parallel currencies are possible.
Reg,
Ashok
assign points if useful.

Loan taken from banks and Fixed deposit scenerios

Dear experts,
Please guide me, i have two Scenarios,
1. My client have fixed deposits in bank - how to configure in sap
2. loan taken from bank - when i repayment the loan amount it should deducted from my loan principle amont in the this process what is role of my house banks. what entries should make, how to calculate interest on loan -- how to configure this Scenario in sap
please guide me
Regards
Chandu

Hi Chandu,
A loan with a bank is no different from an Asset creation process albeit this will NOT be within the Asset A/c module of SAP.
I am assuming that you have SAP FI/CO - in that case you may look at a few options to meet this process:
1. Post an accounting entry creating an asset (FB50) - dr loans held (asset a/c on your BL) and cr cash. (Note your customer ie your bank in the description field etc for record purposes or mention the loan #, a/c etc)
else
2. Post a customer receivable via FB70 with your bank as the customer and ensure that your payment terms match the maturity of the loan. (Post a FB70 with a debit to customer, credit cash etc (you get the idea - hit an asset a/c on the credit side as well)
When its time to collect principal or interest or whatever, if you use 1) - post a journal entry again to offset this posting and post interest as income gained and in case if you use 2) post collection.
with 2) you may need to pass a journal entry for interest collected as a separate line item.
Hope this helps,
Thanks

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.....

Valuation grouping code account determination

We currently have 25 plants (valuation areas) setup using one chart of accounts and a common valuation grouping code for account determination. We now have a need to change one of the plants to use different accounts than the other 24 for the GBB transaction. I can see that transaction OMWD allows me to enter a different valuation group code by plant; so I've entered a different code for the plant we want to change. I then go into OBYC, double-click on GBB and I can see all the accounts set up. From here, if I press the 'rules' button I can see the options to base account determination on. Currently, the 'valuation modification' checkbox is unchecked - I believe this has to be checked in order to use the valuation grouping code.
I'm a little unclear on how to setup the different accounts for the valuation grouping code I've assigned to my one plant. When I checked the 'valuation modification' checkbox and save, I get a message 'the current account determination will be deleted if the rules are changed'. I've done this in a sandbox environment and it certainly does delete all the accounts setup for GBB! But it does then give me the option to enter the valuation grouping code, which is what I need to enter different accounts.
Am I doing this correctly and in the right sequence? Is there a way to save the current values in GBB so they don't go away when I choose 'valuation modification'?

Hi,
What your are doing is correct.
As you mentioned above if you want a different G/L for Plant they you have to change the valuation grouping code. As per Std.SAP when you change the rules in OBYC the existing G/L assignment will get deleted. Hence Please take a copy of the same before you carryout the changes in OBYC rules settings, so that you can maintain the correct G/Ls based on valuation grouping code as existed by checking the file which you have taken as a backup + the new Val.group code,val class & G/L assignment.
Thanks & Regards,

Gl account determinations

hello
we have a live system that we have been working for close to 8 months now. we now notice that a few gl account determinations have been marked wrong. i tried to change them on the setup-financials-gl account determinations form. but it does not seem to accept the change.
is there anything else i need to do to change the gl accounts? or is it not possible to do that? if so, why? could anybody clarify?
thanks
prem

Hi Prem,
Check that you changed them in the right place.
Where should they be changed?
The accounts under:
Administration -> Setup -> G/L Account Determination -> Inventory
These accounts are only defaults. When you create a new Warehouse, Item Group or Item the accounts that are populated on creation are taken from here. If you change an account here nothing will happen with the existing Warehouses, Item Groups or Items.
Check your Items, on the warehouse tab, are they set up with 'Set G/L Accounts By':
Warehouse, Item Group or Item?
If it is by warehouse, go to the corresponding warehouse and change the accounts.
If it is by Item Group, go to the Item Group of the Item and change the accounts.
If it is set to Item Level. In the form settings of the Item expose all the accounts in the warehouse line on the warehouse tab and change them there.
If the new document that you are creating is based on a different document the GL account that can be exposed on the row will be the same as in the base document.
I hope this helps.
Jesper

Account determination - loan taken

Similar Messages

Maybe you are looking for