Hello viewers

Welcome to our SAP FICO Q&A Blog

This blog is meant to be a forum for SAP FICO Professionals all over the world to share knowledge and experience, as well as to provide timely suggestions and solutions for the work related issues.

Please provide your valuable suggestions to improve this Blog.

Website counter

Search This Blog for SAP Solutions

Tuesday, April 19, 2011

BAdI: Tax Jurisdiction Code from Delivery Address

Hi Sharavana,

Please find below solution for your issue on populating Tax Jurisdiction Code in a Purchae Order:

The Business Add-In (BAdI) ME_TAX_FROM_ADDRESS provides you with additional functionality to determine the tax jurisdiction code in purchase orders. At item level, the tax jurisdiction code maintained in the delivery address can be used for tax calculation purposes.


You activate tax handling with tax jurisdiction codes in FI Customizing (transaction OBCO). In the standard system, When an Enjoy purchase order (transaction ME21N) is created, the system takes the following sources into account for the jurisdiction code: reference documents (RFQ, contract), plant table, manual user input, account assignment object (if a tax jurisdiction code has been maintained there). In the process, the system overwrites the previous value in this list in each case. If, for example, you have maintained a tax jurisdiction code for a PO item with the account assignment object, this entry "wins" over the entry in the plant table.

If you implement the BAdI ME_TAX_FROM_ADDRESS, when a PO item is created, these tax jurisdiction codes previously determined by the system will be overwritten with the value from the delivery address. This also applies if no value has been maintained in the delivery address. In this case, the field remains empty. However, you can modi fy this behavior in the code of the implementation (cf. the following description of the example implementation). The checks provided in the system (e.g. whether the combination of tax code and tax jurisdiction code in the system is valid) continue to be run. If you implement the BAdI ME_TAX_FROM_ADDRESS, you must thus ensure that a valid tax jurisdiction code is always maintained in the delivery address. One option is to use an external system for tax calculation purposes here (e.g. Tax ware or Vertex). Or you stipulate in the implementation that an empty field is populated with a value from another source.

Manual input of the tax jurisdiction code by the user is taken into account in all cases. If the BAdI is active, however, input is only possible on the "Delivery Address" tab page, not on the "Invoice" tab page.

Requirements

• You can only use the functionality of the BAdI ME_TAX_FROM_ADDRESS in the "new" purchase order transaction ME21N. In the "old" PO transaction ME21, the code is not utilized.

• For the country belonging to the plant/company code of the PO item, tax handling with tax jurisdiction codes must have been activated.

• The system message 06 263 "Tax jurisdiction & of account assignment adopted in item", should be set to ' ' ("no message") in Customizing for Purchasing (transaction OLME -> Environment Data -> Define Attributes of System Messages -> System Messages).

Example

In the example implementation for BAdI ME_TAX_FROM_ADDRESS supplied, the following system behavior is defined:

• The tax jurisdiction code from the delivery address is set.

• If no value has been maintained there:

- A warning message is issued

- The value for the jurisdiction code previously determined by the system is inserted again

- The cursor jumps to the "Delivery Address" tab page, giving the user the opportunity to correct the tax jurisdiction code manually.

The following data is available to control the system behavior in determining the tax jurisdiction code with the BAdI:

• Purchasing document header (EKKO),

• Purchasing document item (EKPO) - old and new status

• Account assignment data for item (EKKN),

• Tax jurisdiction code from delivery address

• Tax jurisdiction code from plant table


Regards

Murthy Pillutla

Jurisdiction code determination in a PO

Murthy,

How the jurisdiction code is determined in a PO? Most of the time it
is defaulted from the plant. When a cost center is entered, the cost
center jurisdiction code overwrites the plant code. Is there any
sequence in the configuration? Or is it from a user exit/BADI?

Thanks,
Sharavana

Saturday, April 16, 2011

Hi murthy,

Can u please send me 3 critical issues and solutions in SAP FI
thanks in advance
Thanks & Regards
G.Narayana
8892789544

Hi Narayana,

Please find below some scenarios


Accounts Payables



Question: Problem in running a automatic payment program. Suppose we have a balance of $125000 in my bank account and today we running an Automatic payment run. Total payment of the run is $175000. So when we run Automatic payment run it is not giving any error message. What to do with this problem.

Answer: The Automatic Payment Program does not check the Balance of your Bank Account. (GL A/c. Bal.) What it does check is the min & max amounts that you have maintained in your customization.
In Bank determination (FBZP), you have to fill in the available amounts for each Bank. This is the maximum amount up to which payments will be generated by the Auto. Pay. Run.
So if you want to ensure that on any single day the payment run does not pay more than bank balance, you have to update on a daily basis available balance to match with your bank balance.

Accounts Receivables:

A. How SAP handles the Dunning process?

In SAP system there are 9 predefined payment reminder notices which we can directly use as a notice for the particular customer relating to one dunning area (OB61)

You define your dunning levels in the dunning procedure (FBMP), and you may define as many as 9 dunning levels. To simplify, dunning levels may be understood as counter for the dunning notices you send to your customers:

- for dunning level 1 you will send him a kind payment reminder

- for dunning level 2 you send him a reminder (not so kind)

- for dunning level 3 you add to the reminder a deadline for payment etc...

So the dunning levels will reflect the number of letters sent, also the number of days the items is overdue (Interest will be calculated based on number of days & amount –OB42, and dunning charges will be calculated based on overdue due amount specified in notice),and dunning text(type of notice –Reminder/formal/with interest/) will be specified per dunning level Following a dunning run (F150), the dunning procedure/area/level/ block reasons, is updated in the customer master record (FD01) and in the open items.

B. Lock Box

Question: We are using partial payment option in lockbox (OB10) and we have 0 tolerance at both customer and user level.
The customer has an open invoice of $82500 and that he pays $95000 towards this invoice.
When tested this scenario
- the check status as applied and
- the Invoice and the payment document is still open.
What is the reason for this situation?

Answer: The check status applied is that because of ‘0’ tolerances, lockbox applied the cash to that invoice. If we had any tolerances then overpayment beyond the tolerance amount is not allowed and that the amount sits on the account.
Coming to the point b, because the customer is overpaying the invoice (not exact invoice amount) the invoice is still open.

Asset Accounting:

What is unplanned Depreciation and when we post it?

Unplanned depreciation (ABAA)

Use this procedure to post an unplanned depreciation manually. Ordinary depreciation reflects the deduction for wear and tear during the normal use of the asset. Unusual influences, such as damage that leads to a permanent decrease in the value of the asset, are covered by unplanned depreciation.

CO-PA

Question: Client requires the CO - PA report (KE30) match with their Profit & Loss Account ( F.01). Our doubt is the revenues we can get from SD, But other Incomes (ex : Interest recd, Excess Expenses paid recovered, Excess Taxes paid recovered etc ) and the Expenses how can we get the values in our CO - PA report. So, overall  we want the CO-PA report like Profit and loss account. How it can be achieved?
Answer:

1. For a complete reconciliation between FI P&L with COPA, the best way is to activate Account based COPA and develop reports. Also ensure that all the P&L GL accounts have to be created as Cost elements

                                                                              or
2. All FI postings which were not flown to CO-PA through PA transfer structure can be uploaded directly into CO-PA through T code: KEFC, but prior caution is needed while preparing the upload file where appropriate value fields are to be selected. This way we can run the KE30 report in close proximity to F.01 report.
Correct me if I am wrong in any scenario

Murthy Pillutla