FI-SD Integration.doc

General

SD-FI

Document History: Versio n ECC6.0

Date

Author

Aug 12th 2016

Amit Shrivastava

Comment

1

General

SD-FI

Table of Contents 1. PURPOSE ……………………………………………………………………………………………… ……………3 2. DESCRIPTION OF THE ISSUE/ERROR…………………………………………………………………….3 3. RESOLUTION/FIX FOR ISSUE…………………………………………………………………………3 4. ADDITIONAL INFORMATION (IF ………………………………………………………………….3

2

THE ANY)

General

SD-FI

1. Purpose: Overview of FI-SD Integration

2. Description: SAP R/3 is a fully integrated system. So, when a change is made to one application module, R/3 automatically updates the corresponding data in the other application modules. The automatic update of information in R/3 occurs as soon as data is entered into the system (real-time processing). FI-SD Integration is also very important integration in SAP R/3. 3. Details: Enterprise Resource Planning (ERP) packages are developed to run the organization as a whole and on the same lines, SAP does not allow any function to work in isolation, so, all modules like MM, PP, SD and FICO work together. Thus, SAP helps to inter-link all departments like Sales, Production, Purchase, and Finance in a company. This continuous and runtime interaction ensures better organization level planning and management. This interaction is viceversa, that is, not in one way, all the functions communicate with each other (where ever required), and so information flows both ways on need basis. The integration of application modules in real-time allows all the employees in company to see the most up-to-date information. Modules need to talk to each other, as part of the daily routine of running Business. Especially, all modules need to have an interface / integration necessarily with FI (and CO too, if it’s implemented) SAP is divided into modules, each representing a distinct Business Functionality / Department in the brick-&-mortar world  Finance & Controlling (FICO) – Finance / Accounting / Budgeting Department  Sales & Distribution (SD) – Sales / Customer Care Department  Materials Management (MM) – Purchasing Department  Human Resources (HR) – Personnel / HR Department  Production Planning (PP) / Plant Management (PM) – Manufacturing Department  Quality Management (QM) – Quality Assurance Department 3

General

SD-FI

 Warehouse Management (WM) – Logistics / Supply Chain (maybe both upstream & downstream) Department What binds all these Department together is the Corporate Goal of Generating Revenue & Making Profits.

Flow of Data from SD to FI (Order to Cash Process/Sales Process): Inquiry

Sales Quotation

No Accounting (FI) Effect

Sales Order Creation (Transaction VA01)

Finished Goods Stock Checking?

FI Document Created COGS Dr. To FG Stock Cr.

Delivery of Goods to Customer (Transaction VL01N) – Picking, Loading, Scheduling, PGI

FI Document Created Customer Dr. To Sales A/C Cr.

Billing (Transaction VF01)

4

General



  

SD-FI

Primary processes include: o Sales (to customers) 

Sales Order



Delivery, Picking & Post Goods Issue (PGI)



Invoicing (Billing)

o

Material Pricing for Sales Order (Pricing Procedure)

o

Credit Management for Customer Accounts

o

Touch Points with FI/CO occur at: 

Goods Issue



Invoicing (Billing)



Credit Management



Booking Revenues towards calculating Profitability (CO-PA)

At PGI, the accounting document debits cost of goods sold and credits inventory. At Invoicing (Billing), the accounting document debits the customer and credits revenue. Document flow is a tool that allows you to view the related documents in the process.

5

General

SD-FI

Organization Structure:  Organizational Elements include:



o

Plant

o

Sales Organization

o

Distribution Channel

o

Division

o

Sales Area

o

Storage Location

Master Data includes: o

Customer Master (Sales Area View)

o

Material Master (Sales related Views) 

Sales: Sales Organization View 1



Sales: Sales organization View 2



Sales: General/Plant

Client

Company Code 2

Company Code 1

Plant 1 Storage Location 1

Plant 3

Plant 2

Plant 4 SALES AREA

Sales Organization 1 Distribution Channel 1

6

Sales Office

Sales Group

Division 1

General

SD-FI

Sales Organization: Sales organizations are responsible for sales in SAP. A Company Code can be linked to several sales organizations.  Legally, a sales organization is included in exactly one company code. 

We can assign one or more plants to one sales organization.



The sales organization has an address.



Within a sales organization, we can define our own master data. This allows a sales organization to have its own customer and material master data as well as its own conditions and pricing.



We can define our own sales document types within a sales organization.



We assign sales offices and our own employees to a sales organization.



All items in a sales & distribution document, that is, all items of an order, delivery or a billing document belong to a sales organization.



A sales organization is the highest summation level (after the organizational unit Client) for sales statistics with their own statistics currency.



The sales organization is used as a selection criterion for the lists of sales documents and for the delivery and billing due list.



For each sales organization, we can determine the printer for output differently based on sales and billing documents.

If we do not distinguish different sales organizations in our company, we can use sales organization 0001 as a "general sales organization". To define a sales organization, enter a four-character alphanumeric key and a description. Enter an address as well. Definition of Organization Units in SD:

7

General

SD-FI

Assignment of different Organization Units in SD:

Revenue Account Determination Whenever a sale is posted to accounting, SAP must find (or determine) the account to which the revenues and discounts are posted. Therefore, a determination procedure is used to find the respective account, called the Account Determination procedure. One can define the control of Revenue Account Determination for transferring Billing Document values from the Sales module to the Finance module. Revenue account determination is carried out using the condition technique. In Sales and Distribution, under Account Assignment/Costing we can configure various types of Accounts. The various types of Accounts are Revenue Account, Reconciliation Account and Cash Account. We also have Revenue Recognition Account where we determine the Revenue Recognition Methods.

8

General

SD-FI

For example a Service Contract of 12 Months generates Revenue upfront while the Service will be provided for the entire 12 months therefore the Revenue can be recognized at the end of each month after the Service has been provided. The Balance Amount is parked in Deferred Revenue Account. We need do to remember that whenever there is a Transaction there is a Billing Document generated and each Billing Document may differ from each other. Therefore there is a need to understand various Billing Document Types. Each Billing Document Type captures certain financial information. The Billing Document Types can be Cash Sale, Invoice, Credit or Debit Memo, Pro Forma for Order etc. The financial information mentioned in these documents needs to be posted to the respective Revenue Accounts.

Configuration Steps for Revenue Account Determination: 

Define Material Account Assignment Group



Define Customer Account Assignment Group



Define Condition Tables with Field Catalogs



Define and Assign Access Sequence with the Condition Tables



Define and Assign Account Determination Procedure



Define and Assign Account Keys



Assign G/L Accounts

When we will execute Check Master Data Relevant for Account Assignment, we will get the following screen:

9

General

SD-FI

Here we define which account groups we need for materials and customers to be able to group the master records together for account determination. We should ensure that the account groups are entered in the material master records and customer master records. Material Account Assignment Group: Material Account Assignment Group is a field specifically used for identifying the group of materials with the same accounting requirements. Reasonable subdivisions of materials can, for example, be: 

Revenues for services (material type DIEN)



Revenues for packaging (material type VERP)



Revenues for finished products (material type FERT)



Revenues for trading goods (material type HAWA)



Revenues for Scrap Materials



Revenues for Spares

10

General

SD-FI

Material Account Assignment Group is maintained in Sales: Sales Org View 2 in Material Master as shown below:

The system automatically proposes the account assignment group in the Sales Documents from Material Master. Customer Account Assignment Group: Customer Account Assignment Group is a field specifically used for identifying the group of customers with the same accounting requirements.

11

General

SD-FI Reasonable subdivisions for customers can, for example, be:

    

Revenues Revenues Revenues Revenues Revenues

for for for for for

foreign customers at home foreign customers abroad affiliated companies (internal trading partners) customers from EU member states customers from EFTA states

Customer Account Assignment Group is maintained in Billing Tab of Sales Area Data in Customer Master as shown below:

The system automatically proposes the Account Assignment Group from Customer Master of the Payer into the Sales Document. This can be changed in Sales document or Billing document. Condition Tables with Field Catalogs: When we will execute Define Dependencies of Revenue Account Determination, we will get the following screen:

12

General

SD-FI

Field Catalog: Field Catalogs are used in the Condition Tables. One can define the Fields in the Field Catalog. This Field Catalog Identifies a field that we can select when we create or maintain a Condition Table.

Condition Tables: Condition Tables are defined with the Combination of fields from the Field Catalogs for Account Determination.

13

General

SD-FI

There are 5 Standard Condition Tables: Table 1 2 3 4 5

Name Cust.Grp/MaterialGrp/AcctKey Cust.Grp/Account Key Material Grp/Acct Key General Acct Key

Apart from these 5 Standard Condition Tables, we can also create our own Condition Tables. When creating the condition table, we have to select a key between 501 and 999 for the condition table. Access Sequence: In Access Sequence, we maintain a sequence of Condition Tables with which these will be accessed during determination of G/L Accounts at the time of Billing.

14

General

SD-FI

Account Determination Type (Condition Type): Account Determination condition type is the one that controls to which G/L accounts the system posts line items. Here, Account Determination condition type can be defined and assigned with Access Sequence. In the standard SAP R/3 System, an account determination type (condition type) is stored with the key "KOFI".

15

General

SD-FI

Account Determination Procedure: In an account determination procedure, we define the sequence in which the SAP System should read the account determination types (condition types) used for revenue account determination. In the standard SAP R/3 System, an account determination procedure with the key "KOFI00" has already been defined.

16

General

SD-FI

Assignment of Billing Document Type with Account Determination Procedure: Account determination procedures are allocated to the billing types for which a corresponding account determination is to be carried out.

Account Keys: Account keys are defined by specifying an alphanumeric key with up to 3 characters and a description. The following account keys are predefined in the standard SAP R/3 System: 

ERF freight revenues



ERL revenues



ERS sales deductions



EVV cash settlement



MWS sales tax

17

General

SD-FI

Assignment of Account Key with Condition Type: Account Keys are allocated the condition types in the pricing procedures.

18

General

SD-FI Assignment of G/L Accounts (Transaction Code VKOA):

Scenario in SAP Transaction: VA03 Sales Order: 14485 (Order Type OR – Standard Order)

19

General

SD-FI

Item Conditions in Sales Order:

Analysis of Pricing in Sales Order:

20

General

SD-FI

Condition Record for Condition Type PR00:

21

General

SD-FI

Document Flow:

Delivery: 80016270

22

General

SD-FI

Picking: Picking request 20100829

PGI (Post Goods Issue): Goods Issue 4900037698

Accounting Document at the time of Delivery (at the time of PGI): 4900000129

23

General

SD-FI

In MM Billing Document: 90037256 (Billing Type F2 - Invoice)

Analysis of Revenue Account Determination during Billing:

Accounting Document at the time of Billing: 1400000017 (Document Type RV – Billing doc. transfer)

24

General

SD-FI

Accounts maintained in transaction VKOA:

Credit Management Credit Management is an important functionality to be implemented in every organization for the following reasons: • To increase the Sales by extending the credit limit to customers who has a good payment track record. •

To minimize the risk of loss from bad debts by restricting or denying credit to customers who do not have a good payment record.

2 Types of Credit Checks:  Simple Credit Check  Automatic Credit Check Simple Credit Check happens considering the Document value + Open Items value.  Document Value is the total value of the Sales Order that is created currently.

25

General

SD-FI

 Open Items Value is the value of Sales Order has been saved , Delivered, Invoiced & Transferred to FI, but not received the payment from the customer. If Credit Limit exceeds, the available options of systems reaction are:  Credit Check A: Run Simple Credit Check with (Information)

Warning

Message



Credit Check B: Run Simple Credit Check with Error Message (Sales Order will not be allowed to Save)



Credit Check C: Run Simple Credit Check with Delivery Block. (Sales Order will be created but Delivery will be blocked)

Setting Credit Limit in Customer Credit management:

26

General

SD-FI

Configuration Settings for Credit Check: Menu Path: Sales and Distribution  Basic Functions  Credit Management/Risk Management  Credit Management  Assign Sales Documents and Delivery Documents (Transaction OVAK)

27

General

SD-FI

Definition of Credit Control Area: Menu Path: SPRO  IMG  Enterprise Structure  Definition  Financial Accounting  Define Credit Control Area (Transaction OB45)

Assignment of Company Code to Credit Control Area: Menu Path: SPRO  IMG  Enterprise Structure  Assignment  Financial Accounting  Assign company code to credit control area (Transaction OB38)

28

General

SD-FI

Scenarios: Credit Limit for Customer T-L63A19 (Credit Control Area 1000):

Case 1: Credit Check A

29

General

SD-FI

Case 2: Credit Check B

30

General

SD-FI

Case 3: Credit Check C

31

General

SD-FI

If we will try to create delivery, we will get error message:

References: http://help.sap.com

32

General

SD-FI

4. Tax Configurations In SAP Tax configurations are done in SAP at the country level. This is because all businesses in the same country need to follow the same taxation policies and generally accepted accounting principles while preparing their financial statements. Therefore, tax configurations in SAP are done for each country. Any company code which is then created in that country can then automatically use the tax configuration that is done for that country. So tax configurations need not be done for each and every company code again and again. This saves the effort required to carry out the tax configurations for every company code separately. SAP allows the tax rates to be defined internally or the tax rates may be fetched from an external taxation system like Vertex. The tax configurations are stored in SAP in the form of tax calculation procedures and tax codes. These procedures can then be assigned to different countries. These procedures then become available to any company code which is created in that country. The tax rates are provided by the tax codes are the different tax types while the method of calculation is defined in the tax calculation procedure. SAP allows the following taxes to be processed while posting documents:    

Tax on sales and purchases. Additional taxes like VAT which our country specific. Sales and Use tax as in USA. Withholding tax like income tax in India. Sales and Use tax as in USA In the United States, tax on sales and purchases is known as sales and use tax. Sales and use tax is levied on the sale of tangible personal property and is imposed by tax authorities on transactions. Most states in the United States impose a sales tax on sales of goods. As a general rule, the consumer bears the tax and the vendor merely acts as a collector for the jurisdiction. Most jurisdictions that impose .Sales Tax also impose a complimentary use tax on the use or consumption of goods originating from another state. Transactions are generally subject to sales or use tax, but not both, and payment is generally self-imposed by the buyer or seller.

Use In the R/3 System, you can configure your system to automate calculation and posting of sales and use tax. When posting a document, the system automatically determines the sales and use tax amounts and assigns the amounts to the appropriate accounts or retains the information for reporting.

Calculation Procedure 33

General

SD-FI To calculate sales and use tax in the United States, you must assign one of the

three calculation

procedures, namely, TAXUSJ, TAXUS, and TAXUSX. The calculation procedure you

choose depends on your specific business requirements. When you create a company code using the template for the United States, the system automatically creates the following calculation procedures.  TAXUS - Based on tax codes, but not jurisdiction codes (Non-jurisdiction method)  TAXUSJ - Based on tax jurisdiction method with tax codes (Jurisdiction method)  TAXUSX - Used in combination with third-party tax calculation packages (TAXWARE International and Vertex) A calculation procedure is assigned by country. The relationship is that a country has only one calculation procedure but a calculation procedure can be assigned too many countries.

Assign Tax Procedure To Country

Step 1: The tax configuration details are stored in the tax procedure. The first step is to assign the tax procedure to the country in which the company code exists. Navigate to the Implementation Guide menu path as shown below or execute the transaction code OBBG.

34

General

SD-FI

Step 2: Position to the country to which the tax calculation procedure is to be assigned and enter the tax calculation procedure details as shown in the screenshot below.

Step 3: Click on the save button to save the changes. A success message showing that the changes have been saved is displayed.

35

General

SD-FI Tax Code

When you create a company code using the template for the United States, the system sets up sample tax codes for the calculation procedures TAXUSJ and TAXUSX. You can either use the tax codes provided or create your own using these as samples. Tax codes for TAXUSJ Tax code

Description

S0

A/R Sales Tax, exempt

S1

A/R Sales Tax, taxable

I0

A/P Sales Tax, exempt

I1

A/P Sales Tax, taxable

U0

A/P Use Tax, exempt

U1

A/P Use Tax, taxable

Tax codes for TAXUSX Tax code

Description

I0

A/P Tax Exempt

I1

A/P Sales Tax

I3

A/P Lease Tax

O0

A/R Tax Exempt

O1

A/R Sales Tax

O2

A/R Service Tax

O5

A/R Sales Tax (Product Code 9937299)

U1

A/P Self-Assessment Use Tax

Step 1: Navigate to the Implementation Guide menu path as shown in the screenshot below or execute the transaction code FTXP from the SAP Easy Access menu.

36

General

SD-FI

Step 2: Enter the country in the pop -up as shown in the screenshot below and click on the continue button.

Step 3: Enter the tax jurisdiction code and the other details on the screen as shown in the screenshot below and press the Enter key. The tax code represents the type of the tax for which the rates are going to be maintained.

37

General

SD-FI

Step 4: Enter the tax rates as shown in the screenshot below. These tax rates can be used to calculate the tax while posting a document in SAP. The method of calculation will be determined on the basis of the tax calculation procedure.

Step 5: Click the save button to save the changes. A success message indicating that the changes have been saved is displayed. 38

General

SD-FI

Tax Jurisdiction Code Definition The United States consists of more than 55,000 jurisdictions. A jurisdiction is the taxation authority that imposes the tax. Each jurisdiction is identified by a tax jurisdiction code. This code provides the location for the transaction to be taxed. The tax jurisdiction code is a key, which together with the tax code and other parameters, determines the tax amount and the way in which payment of the entire tax amount is divided between different tax authorities. The R/3 System can handle up to four jurisdiction levels for calculation procedure TAXUSJ and six jurisdiction levels for calculation procedure TAXUSX. Each jurisdiction level has its own jurisdiction code.

Use When posting a document or calculating prices, you use jurisdiction codes in combination with tax codes to calculate tax amounts. Moreover, the jurisdiction code determines how the tax amount is divided among the different tax authorities. If you use the tax calculation method with jurisdictions, you have two options to calculate taxes: 1. Using calculation procedure TAXUSJ, you manually enter the required jurisdiction codes and enter the corresponding tax percentages. 2. Using calculation procedure TAXUSX, you calculate taxes in an external system which contains jurisdiction codes and their corresponding percentages.

Structure A jurisdiction structure is a freely definable 15 character field with up to four levels. A level corresponds to a tax authority such as state, country or local government. For example, a jurisdiction code using the TAXUSJ structure has nine characters with the first two denoting the state, the next three denoting the county or parish within the state and the last four denoting the city.  Jurisdiction of the state of Pennsylvania - PA0000000  Jurisdiction of the county of Allegheny - PA0010000  Jurisdiction of the city of Pittsburgh - PA0010100

Integration Jurisdiction codes are defined for key master records. For sales transactions, the jurisdiction code is determined based on indicators on the customer and material. For purchasing transactions, the jurisdiction code is determined based on indicators on the material for simple tax scenarios.

39

General

SD-FI

Define the Tax Jurisdiction Codes Step 1: Navigate to the implementation guide menu path as shown below or execute the transaction code OBCP from the SAP easy access menu.

Step 2: Enter the work area details in the pop-up as shown in the screenshot below and click on the continue button.

40

General

SD-FI

Step 3: Enter the tax jurisdiction code and its description as shown in the screenshot below. On the basis of the configuration for the tax jurisdiction code structure, the first two letters of the tax jurisdiction code will represent the state, the next three letters will represent the county, and the next four letters will represent the city. Therefore, every tax jurisdiction code will be nine characters long. It will be possible to determine the correct taxing authority on the basis of the tax the jurisdiction code described above.

Step 4: Click on the save button to save the new tax jurisdiction code. A success message indicating that the new tax jurisdiction code has been saved is displayed.

Tax Determination 41

General

SD-FI The system automatically determines the amount of tax and how the tax is

distributed among jurisdictions. Several factors influence tax determination such as the origin and destination of goods and the material/customer taxability. In a sales transaction, the ship-to location determines the jurisdiction code. In a purchasing transaction, the location where consumption occurs determines the jurisdiction code. Other factors that influence the tax rate include:  Customer taxability Some customers such as non-profit organizations may be tax exempt.  Material taxability Raw materials used for manufacturing will typically be exempt while finished goods are typically taxable. Another example - race horses may have a different tax rate than farm horses. Indicators on the customer and material master records allow you to determine taxability. These indicators are used in condition records to specify the tax code in transactions. For example, the customer and material taxability indicators are criteria in determining tax codes in a sales transaction.

Methods of Calculating Sales and Use Tax SAP offers three methods to calculate sales and use tax. You select the method according to your specific requirements. Once you choose your method, you customize the system accordingly.

Features The three methods include: 

Non-jurisdiction method With this method, you allocate percentage rates to tax codes. This method is seldom used.



Jurisdiction method With this method, you manually define the jurisdiction for every region in which you do business.



Jurisdiction method with external tax calculation system With this method, you automate tax compliance activities by using an interface to an external tax calculation system. The choice of methods is a parameter in configuring the country's global

42

General

SD-FI settings. Every company assigned to the country uses the same method.

The parameter is called the calculation procedure. Every method has the same final goal of applying appropriate tax percentages to line items in SD, MM, and FI. The non-jurisdiction method establishes rates separately in these areas using tax codes while jurisdiction methods use jurisdiction codes to determine the tax rates. In the R/3 System, you use jurisdiction codes for calculating taxes if you have transactions with business partners whose locations have many jurisdictions or if you expect that it will be the case in the future. You can also opt to calculate taxes without jurisdiction codes. This method only applies when your business partners are located in a few jurisdictions. You simply allocate percentage rates to the different tax codes. The jurisdiction method with an external tax calculation system is used when a company operates in many tax jurisdictions. Withholding Tax In the United States, invoice recipients are sometimes required to collect withholding tax on behalf of certain vendors, such as self-employed people or non-resident foreigners. However, normally, invoice recipients need only to report withholding taxes and do not have to collect and pay withholding taxes. In this common case, the vendor is liable for paying the tax amount to the Internal Revenue Service (IRS).Withholding tax amounts must be reported to the IRS at regular intervals and a statement is also sent periodically to the vendor. Companies submit annual statements of withholding tax amounts to the vendors and the IRS by using the pre-printed forms 1099 Misc, 1099-G, 1099-INT, and 1042S. With SAP R/3, you can create the 1099 and 1042S reports. Integration with Vertex System VERTEX is a SAP certified tax calculation package that calculates the taxes at each tax jurisdiction level (federal, state, county, city, etc) based on zip code. This is for calculating US taxes and VERTEX has very sophisticated way of identifying the jurisdiction codes based on zip codes, geocode etc. It calculates the Use Tax and Sales Tax (relevant for purchasing side as well as sales side).

Vertex System Configuration with SAP

1. Define a physical destination 43

General

SD-FI

Communications between ERP and a sales/use tax package are established using SAP RFC (Remote Function Calls). You must create an RFC destination that specifies the type of communication and the directory path in which the tax package executable or shell scripts program is installed. You must set up the RFC destination as a TCP/IP communication protocol. The destination name is user defined. IMG Path: Financial accounting (New)>Financial accounting global settings (New)>Taxes on sales/purchases>Basic settings>External tax calculation>Define physical destination 1.

* *Choose Execute;

2.

Choose Create;

3.

Select and input a logical name for the RFC Destination, “VERTEX”;

4.

Under Connection type enter T;

5.

Enter a short description text;

6.

Choose Enter;

7.

Define the directory path. This is the directory path in which the tax package executable or shell script program is installed. There are two recommended methods to define the directory path*:* A) SAP and Tax Software Package reside on the same server If ERP and the external tax package are to reside on the same server, click Application Server to select as the program location. In the field Program, the external tax package’s executable or shell script program, along with the directory path in which it was installed, must be specified. Click Save.

B) SAP and Tax Software Package reside on different servers If ERP and the external tax package were to reside on different servers, then this would be an explicit communication setup. Click Explicit host. In the field Program, input the external tax package’s executable or shell script program along with the directory path in which it was installed. In the field Target Host, enter the host name of the server where the external tax package resides. Click Save.] 8.

If necessary, set up the correct SAP gateway host and gateway service. This setup is frequently an area of concern. An understanding of the directory path is of utmost importance.

44

General

SD-FI

Transaction: SM59

45

General

SD-FI

The entries for the fields under “Start on Explicit Host” must be pretended by your system administrator.

Test the connection To test the connection between ERP and the external tax system, choose the Test connection button in the upper left-hand corner of the screen. If any error occurs, verify that: 1. The connection type is TCP/IP. 2. Program location and host name are correctly specified. 3. The directory path and the name of the executable program are correct. 4. The gateway host and service name is correctly specified 5. The external tax package has been installed correctly and is the correct version. 6. The external tax package’s API for the ERP tax interface is installed correctly and is the correct version. 7. The ERP RFC libraries are the correct version. 8. The correct permissions are set for the user account. 9. The user has read/write authority. If this test fails, halt the installation! This test must be successful in order for ERP to communicate with the external tax package. If the connection is successful, also verify that the external tax package installed supports the ERP version of the API. You do that by going to: System Information -> Function List

   

Check if the following functions are listed: RFC_CALCULATE_TAXES_DOC RFC_UPDATE_TAXES_DOC RFC_FORCE_TAXES_DOC RFC_DETERMINE_JURISDICTION

46

General

SD-FI

47