Skip to main content

Legal

Tax & Accounting

Trade & Supply

Risk & Fraud

News & Media

Books

Developers

ONESOURCE table configuration for SAP

Other configuration tables

This is a list of various tables used for setup of your system with SAP.

Determine Condition Type for Taxes

Transaction Code:
/N/IDT/DETER_COND_TYPE
It's required that you use the table as shown above and make sure that initially you have it configured as shown. This would be the standard and usual configuration for this table. This table was preconfigured as part of the installation transports, but without the
Condition Type
 (CTyp) field populated. As of release 6.3.0.0 we have elected to not populate this table as many of our upgrade customers have additional configuration that they have added to this table that our transport was clearing. You will need to input these route names and condition type values as part of the initial system setup before executing any transactions in SAP. You will use the condition types that were setup in Configuration Guide for SAP Tables. Your condition type column should look like our example above if you elected to use the same ZITR, ZITE, ZITD, ZITF conditions as noted in the guide. However, if these condition type names were already taken in your system prior to your install, yours may be different. The condition types maintained here will drive what condition is used when displaying tax results in the transaction.
New Authority Type Column
As of release 6.3.0.0 a new column was also added to the table to tie the condition type to a specific tax authority in SAP. This was due to logic needed to support the use of multiple condition types being returned to SAP for direct linkage to tax authorities used for complex scenarios for Brazil. With the new Brazil logic now applicable with this release, the mapping is critical for being able to drive needed results to the various Nota Fiscal forms. For a non-Brazil implementation, you will not need to utilize this new column and your table would need to be populated like the example shown above with an “*” in this new field. Please refer to our new “
Brazil Enablement
” chapter in the Configuration Guide for Special Functions for further information as to how to add records to this table that are specific to Brazil condition types and tax authorities.
The condition types mapped should match the Nature of Tax meaning from Determination:
Percentage: Condition with a condition category of “A” for Percentage (ZITR in our sample)
Fee: Condition with a condition category of “B” for Fixed amount (ZITF in our sample)
Exempt: This would match best with a percentage-based condition (ZITR)
In some complex situations or based on some countries tax law, a specific condition type might need to be used to drive reporting, printing, or legal processes. For these cases the ERP_Tax_Code field is optionally available in this table. You would be able to setup a Tax Code Qualifier that is tied to a ERP_Tax_Code uniquely identifying that scenario. Based on that result you could then map to a special condition type. This condition type should be setup like ZITR or ZITF using the same template as outlined in the SAP configuration section.
Above sample applies to company code 7000 only, if the result ERP_TAX_CODE is AC_Z01 then the condition type assigned in the Orders pricing procedure will be ZITB.
Route Name
Cntry Grp
CoCd
NatureOfTx
ERP Tax Cd
Authority
Ctyp
/IDT/ROUTE_GROUP_BILLING_GEN
*
*
Fee
*
*
ZITF
/IDT/ROUTE_GROUP_BILLING_PA
*
*
Fee
*
*
ZITF
/IDT/ROUTE_GROUP_PURCHASING
*
*
Fee
*
*
ZITF
/IDT/ROUTE_GROUP_SALES
*
*
Fee
*
*
ZITF
/IDT/ROUTE_GROUP_DELIVERY
*
*
Fee
*
*
ZITF
/IDT/ROUTE_NON_GROUP_DOC_AP
*
*
Fee
*
*
ZITF
/IDT/ROUTE_NON_GROUP_DOC_AR
*
*
Fee
*
*
ZITF
/IDT/ROUTE_NON_GROUP_DOC_FI
*
*
Fee
*
*
ZITF
/IDT/ROUTE_NON_GROUP_DOC_SES
*
*
Fee
*
*
ZITF
/IDT/ROUTE_NON_GROUP_DOC_DT
*
*
Fee
*
*
ZITF
/IDT/ROUTE_NON_GROUP_DOC_DP
*
*
Fee
*
*
ZITF
/IDT/ROUTE_NON_GROUP_DOC_FB5
*
*
Fee
*
*
ZITF
/IDT/ROUTE_NON_GROUP_DOC_LIV
*
*
Fee
*
*
ZITF
/IDT/ROUTE_UPDATE_AUDIT_DB
*
*
Fee
*
*
ZITF
/IDT/ROUTE_NON_GROUP_DOC_A_GL
*
*
Fee
*
*
ZITF
/IDT/ROUTE_NON_GROUP_DOC_GM
*
*
Fee
*
*
ZITF
/IDT/ROUTE_GROUP_BILLING_GEN
*
*
Percentage
*
*
ZITR
/IDT/ROUTE_GROUP_BILLING_PA
*
*
Percentage
*
*
ZITR
/IDT/ROUTE_GROUP_PURCHASING
*
*
Percentage
*
*
ZITR
/IDT/ROUTE_GROUP_SALES
*
*
Percentage
*
*
ZITR
/IDT/ROUTE_GROUP_DELIVERY
*
*
Percentage
*
*
ZITR
/IDT/ROUTE_NON_GROUP_DOC_AP
*
*
Percentage
*
*
ZITR
/IDT/ROUTE_NON_GROUP_DOC_AR
*
*
Percentage
*
*
ZITR
/IDT/ROUTE_NON_GROUP_DOC_FI
*
*
Percentage
*
*
ZITR
/IDT/ROUTE_NON_GROUP_DOC_SES
*
*
Percentage
*
*
ZITR
/IDT/ROUTE_NON_GROUP_DOC_DT
*
*
Percentage
*
*
ZITR
/IDT/ROUTE_NON_GROUP_DOC_DP
*
*
Percentage
*
*
ZITR
/IDT/ROUTE_NON_GROUP_DOC_FB5
*
*
Percentage
*
*
ZITR
/IDT/ROUTE_NON_GROUP_DOC_LIV
*
*
Percentage
*
*
ZITR
/IDT/ROUTE_UPDATE_AUDIT_DB
*
*
Percentage
*
*
ZITR
/IDT/ROUTE_NON_GROUP_DOC_A_GL
*
*
Percentage
*
*
ZITR
/IDT/ROUTE_NON_GROUP_DOC_GM
*
*
Percentage
*
*
ZITR
/IDT/ROUTE_GROUP_BILLING_GEN
*
*
Exempt
*
*
ZITR
/IDT/ROUTE_GROUP_BILLING_PA
*
*
Exempt
*
*
ZITR
/IDT/ROUTE_GROUP_PURCHASING
*
*
Exempt
*
*
ZITR
/IDT/ROUTE_GROUP_SALES
*
*
Exempt
*
*
ZITR
/IDT/ROUTE_GROUP_DELIVERY
*
*
Exempt
*
*
ZITR
/IDT/ROUTE_NON_GROUP_DOC_AP
*
*
Exempt
*
*
ZITR
/IDT/ROUTE_NON_GROUP_DOC_AR
*
*
Exempt
*
*
ZITR
/IDT/ROUTE_NON_GROUP_DOC_FI
*
*
Exempt
*
*
ZITR
/IDT/ROUTE_NON_GROUP_DOC_SES
*
*
Exempt
*
*
ZITR
/IDT/ROUTE_NON_GROUP_DOC_DT
*
*
Exempt
*
*
ZITR
/IDT/ROUTE_NON_GROUP_DOC_DP
*
*
Exempt
*
*
ZITR
/IDT/ROUTE_NON_GROUP_DOC_FB5
*
*
Exempt
*
*
ZITR
/IDT/ROUTE_NON_GROUP_DOC_LIV
*
*
Exempt
*
*
ZITR
/IDT/ROUTE_UPDATE_AUDIT_DB
*
*
Exempt
*
*
ZITR
/IDT/ROUTE_NON_GROUP_DOC_A_GL
*
*
Exempt
*
*
ZITR
/IDT/ROUTE_NON_GROUP_DOC_GM
*
*
Exempt
*
*
ZITR

Tax Exemption Settings

Transaction Code:
/N/IDT/EXEMPT_SETTINGS
In standard SAP taxing scenarios, the customer (TSKD-TAXKD) and material (TSKM-TAXKM) tax indicators would be used in condition records to drive taxability via a tax code. With Integration for SAP’s use of a driver and results tax code, a custom table had to be created to manage the same concept. We still use the data in the master records. The customer master tax indicator with potential values of taxable (1), not taxable (0), or force a tax calculation (2), and others. The same is true for material master tax indicator. A force code is not applicable for the material as Determination will override this for the materials.
The combination of these indicators drives taxability in Determination via the XML field
IS_EXEMPT
. This field can have three different values:
Blank
 Determination decides if the transaction is taxable or not based on current Determination rules configured.
Always tax-exempt
 Force an exemption and override what Determination would decide.
Always taxable
 Force a tax calculation and override what Determination would decide.

SAP Tax Code/DET Tax Code Index

Transaction Code:
/N/IDT/DET_TAX_CODE
Above is an illustration example for explanation purpose only, this table is shipped empty. There are two main functions that this configuration can provide:
  1. Map tax codes that are designated as exempt override codes using the
    IS_EXEMPT XML
     field.
  2. Maps override tax codes utilizing the
    TAX_CODE XML
     field.
The benefit of using designated override tax codes is that they can be easily identified and reported on. You might want to review at month end closing which transactions were overridden and why, if the taxing decision made was the correct one, or if an adjustment is required. The use of override tax codes could also indicate a need to revisit tax policy setup, configurations, and processes as they indicate an opportunity for better tax automation.
Exempt Status Override
There may be situations where a user may need to override a tax calculation as being totally exempt from tax above what Determination would calculate based on the tax indicators on the customer, material, or exemption certificate processing in Determination. If this is the case then a tax code would need to be established and act as a driver tax code that would drive the transaction to an exempt status without the use of a Determination tax rule. It is exempt based on the tax code. In this situation the system will bring back a response from Determination that will have a tax block that is designated as IS_EXEMPT = true in the XML response and would not show that a tax rule was accessed in Determination.
In our example we have established A0 as an output tax exempt code and V0 as an input tax exempt tax code by designating them in the “Is Exempt?” column as TRUE. These two codes could then be used in place of the O1 or I1 driver tax codes on a specific transaction and would tell Determination to ignore the normal logic and consider the line exempt for all taxes on that line.
Tax Rate or Treatment Override
There may be situations where business requires overriding a tax code to something other than what is returned based on the tax policy maintained in Determination. For example, in a finance transaction (i.e. FB60) not enough details are available to match a vendor invoice to the tax charged by the supplier. However, it is assumed that the invoice was correctly coded when issued, so the user needs to be able to override the taxing decision made by Determination
This can be achieved in providing a value in the XML TAX_CODE field that either matches an already established “9000” rule in Determination or custom rule.
Sometimes there is not an established 9000 rule that has the correct tax code that is needed for your mapping. If that is the case, then you will have to have a custom rule created. For example, if the 9000 rule for STANDARD does not exist, and you have a line mapping in your table for the override of Y1 for STANDARD, (see above) then create a custom rule with this Determination tax code of STANDARD. There must be a one to one maintenance and match between the entry in your Determination tax code table configuration as noted above and the tax code rules in Determination.
In below example we have a Thomson Reuters provided 9970 rule that is coded as reduced rated. If the TAX_CODE in the XML request has the value REDUCED, then this rule is used.
To have a specific
SAP tax code
 use the 9970 rule for a reduced tax calculation, that tax code would be mapped in our configuration table in
Determination Tax Code
 to a value of REDUCED. In our screenshot shown above, this is the case for Y2 and Z2, both would use rule 9970.

US Specific Logic Table

Transaction Code:
/N/IDT/US_LOGIC
This table is used for specific logic used for US and US territory Sales and Consumer Use tax self-pay accruals. This table ties the tax codes used for US Sales and Use tax to the correct Company Role and Tax category fields as well as telling the program that an offsetting account entry is needed to balance the Consumer Use Tax self-accrual.
To configure this table, you will need to identify:
  1. Relevant company codes that are in the US or US territory and are configured for Sales and Use tax. You will also need to identify what customers in specific countries are shipping into the US that are calculating and charging US sales tax. They will be needed to configure the ship-from country and country group columns on the left side of the table.
  2. Identify all the tax codes used for Sales and Use tax on each company code per step 1.
  3. All tax codes used for Sales tax should be designated as using the
    Seller
     Company role.
  4. All tax codes used for Consumer Use tax should be designated as using
    Buyer
     Company role.
  5. All Consumer Use tax codes should also have the check box checked to create the offsetting entry to expense the use tax to account key NVV (another account key can be selected but must be created with like configuration to the standard SAP account key NVV if desired).
This table is normally shipped as blank and only has a customer view for customer input. To use the I1 and U1 tax codes for the US company codes you will need to configure this table like our example that we show here. In our example we used “*” for the ship from country group and ship from country columns. You may elect to use this wild card assignment or can specifically list different countries based on your accounting policy and tax code and account key assignments.
The seller role is used on transaction for vendor charged US sales tax so that the calculation is done correctly and uses sales tax rates from Determination content. The buyer role is used when the transaction is supposed to be self-accrued based on Use Tax rates in Determination content. Use tax rates can quite often be lower that sales tax rates as some lower level jurisdiction are not involved in the scenario for use tax. Use tax calculation using the buyer roll will only produce a single tax block to calculate the tax liability and the entry requires an offsetting posting to be created within Integration in order to balance the self-accrual entry and post the debit to the expense account using account key NVV. This is accomplished through the proper mapping of this table for the driver and all downstream tax codes.
It is important that you not try to mix a driver tax code that is set to seller role with a final tax code that is used for buyer role use tax accrual or errors will occur within the transaction. This is why we tell you to create both a I1 driver tax code and a U1 driver tax code and use them as needed to drive the transaction to the correct buyer/seller role and proper calculation. Transaction entry personnel need to be instructed as to which code to use based on the needs of the transaction. All final tax codes that are used in TCQ logic must also be configured in this table. They are required for proper calculation of tax at all points in the transaction process.

Cash Discount/DET Tax Code Index

Transaction Code:
/N/IDT/CASH_DISCOUNT
This table has been created to support functionality for countries that require a tax calculation adjustment on cash discounts taken at time of payment. (See Appendix 1 section on “Cash Discounts Taken/Received at Payment for country configuration requirements) For purposes of demonstration we will use configuration for Germany as an example. The table is used to map the original tax code from the cash discount document line to a determination tax code to be able to drive the TCQ correctly for cash discounts adjustments. See sample view of the table below:
This is an example and will be different for your country configuration based on the list of tax codes that you have elected to set up for the specific country. Only countries that are configured to accept cash discount tax adjustments at time of payment are needed in this table.
The table will be shipped empty upon your installation of the Integration and the user must configure for each country configured for cash discount at time of payment. To configure this table the following steps should be addressed:
  1. Identify all tax codes that you have established for the related country required in the table and enter a line for the country and the tax code.
  2. Identify and input the applicable Determination LINE.TAX_CODE that matches the SAP tax code function. For example, for an A1 standard rated output tax the Determination tax code would be “STANDARD”.
Logic for use of this table:
If the line-item tax code on the invoice being adjusted for cash discount matches an entry in this table, then
  1. Pass the country of the company code and the Determination tax code from the line in this table to the request for Determination to calculate the correct tax on the adjustment based on the custom rule logic set up in determination.
  2. Populate attribute 46 at the line level in the request to Determination with a 2-digit code of the two-digit SAP tax code from the table. Example: tax code is A1 and attribute 46 request would be populated with “A1”.
Population of Line Level Attribute46 Within the Request to Determination
This two-digit logic would be required so that the TCQ could establish the correct tax code between an A1 and an Y1 tax code. Without the extra designation using this attribute there would be no difference between a Determination tax code of “standard” representing a request for an A1 code from a driver tax code on the original invoice line of Y1.

General Configuration Values

Transaction Code:
/N/IDT/GEN_CONFIG_VALS
This table is provided to map a variety of general settings for Integration. This table is provided empty, the picture above is for illustration and explanation purposes filled with sample data (yours might be different).
Freight
To allow Determination to assess taxes on the portion of a price associated with freight we need to send freight specific information. This is done by creating a related line to the product line for freight in the request XML. If the requirements for freight are fulfilled based on this table configuration then the following logic applies:
Request
:
  • Create a freight line in the XML request by copying the existing product line to a freight line
  • Sets the related line number on the freight line to the non-freight line's line number
  • Sets the description on the freight line to "Freight for line <original line number>"
  • Sets the freight line's line number to the non-freight line's number plus one million (this way we can tell which lines coming back from Determination are freight)
  • Sets the product code to the freight product code configured
Response
:
Determination is returning the freight line as a related line to the non-freight line. Both are then returned as separate lines. The authority names for freight authorities can be prepended based on configuration. Each taxing authority is returned uniquely; if there are 4 taxing authorities involved there could be 8 lines in total; 4 for product and 4 for freight.
When there is Freight in a transaction, the Line ID for the freight line that is following the product line should be '2' as it is a unique key in audit database. The line number should be prepended with '1'.
If the line number of the product line or Line ID 1 is 000010, then the Freight line number should be 1000010 and line ID is '2'.
Configuration Option
Description
Freight product code
A product code used in Determination to drive taxability for freight. This code will be sent in the PRODUCT_CODE field of the XML request in the freight line.
Freight condition sub-total
The sub-total field configured in the pricing procedure indicating the freight price values.
Freight condition text prepend
A prepend text to indicate freight in the condition screen, for example F: It is recommended to keep this short since the display field in SAP is 20 characters long.
Sales order line example with product and freight taxability:
External Company ID Prepend
When transaction data is passed to Determination the EXTERNAL_COMPANY_ID XML element determines which company’s rules, rates, and other processing logic are applied. The standard source of the EXTERNAL_COMPANY_ID is the SAP Company Code to which the transacting business process belongs to. In instance where one Determination is covering multiple installations of SAP where you might have the same company code numbers in multiple systems this would lead to inconsistencies. To prevent the mix up of data when this occurs, the system would need to uniquely identify each company code. The prepend option enables this as you can add a value to each systems company code.
In this example the value
MYSAMPLE_
 would be prepended to any transaction from this system. So, in the case of a transaction for company code 3000 the value send to Determination would be
MYSAMPLE_3000
.
It is required that the External Company ID in Determination is configured to match the field value of the prepended company code if using this feature.
Override Addresses
The four override address options on the General Configuration table are used to establish the name of the new IDT address fields that can be added to the MIRO invoice entry line-item detail. Here you would identify the name of the field that you added in the other setup and configuration this optional MIRO feature. If you wish to have the ability to change the ship to address at time of MIRO invoice entry then this would be required configuration to tell the system the new field name within the program.
IDT Account Key Assignment
The IDT Account Key Assignment option in this table is used to set up a default account key of IDT for certain program uses. Currently this is used if you wish to set up certain tax codes as not being relevant to tax and not make a call to Determination. This is noted in the configuration instructions for the Tax relevancy table. See section “Tax Relevancy Table”
Taxation for Split Account Assignment Lines on PO
A new option (Option 5 in dropdown) is added from release 6.5.0.0 in the /IDT/GEN_CONFIG_VALS - General Configuration Values table. The Global Next code checks for a value of YES to enable split account assignment for purchase order (PO)
YES = Enable split account assignment (Taxes are at the Individual Split Account Assignment level)
Not Equal to YES = Turn off feature (Taxes are at the Purchase Order Line level)
Please note that if TAXATION FOR SPLIT ACCOUNT ASSIGNMENT LINES ON PO is enabled (Option 05 = YES) then
  1. Ensure that only a fixed number of account assignment lines are entered so that total of tax lines do not go beyond 99.
  2. Or write a customer specific logic to summarize tax lines “within” a PO line (not for the whole PO). ONESOURCE Professional Services team can help with this.

Configure Logs

This table gives you significant flexibility on the setup and use of logs in the system. New with this Integration, the logs are now written to custom tables in SAP and a user can locate and search the list of logs quickly and easily. Changes to the type of logging that you need in your system are now fast and easy with no down time or interruption. Log configuration changes will go into effect immediately after saving the change. This table is delivered so that maintenance in a production system is allowed. Your SAP Security Administrator can set this up for you. Access can be controlled via the transaction code
/N/IDT/LOG_CONFIG
.
There are two views to this table.
/N/IDT/LOG_CONFIG_V
 transaction is in the standard tables section of the menu and is populated with one line as part of the installation of the product. Transaction
/N/IDT/LOG_CONFIG
 is in the Customer user menu and is where system users can manage their own setting for log level by person, transaction code, company code, etc.
Transaction Code:
/N/IDT/LOG_CONFIG_V
Transaction Code:
/N/IDT/LOG_CONFIG
For the Customer view of this table the sort order begins with 100001 through 999999.
The different configuration options are as follows:
Column
Description
Username
The SAP system logon ID of the user logging should apply to.
Transaction Code
Transaction code to be logged.
Company Code
Company Code
Application Server
To isolate a network connection issue, you may want to limit your Log Level to a given SAP server that may be experiencing a problem.
Log Level
NONE – no logging at all
ERRORS – only severe errors
DEBUG – all request/response XML details

Negate Direction of Tax Types

Transaction code:
/N/IDT/NEG_TAX_TYPE_V
This table is used to negate one side of double-sided tax entries. Certain tax types like acquisition tax or reverse charge scenarios calculate a self-pay accrual as an outgoing tax accrual and an incoming side for the recovery amount. Two tax blocks are returned from Determination in these scenarios and one side of the entry must be negated so that the net balance from the Determination tax calculation correctly nets to zero with a debit and credit to the correct General Ledger accounts that are assigned. In this standard view of the table the user cannot change the entry, but it is available for viewing and is populated with the five tax types that are used for the double-sided entry scenario. The output direction for these tax blocks are identified as the ones requiring the negation entry.
Transaction code:
/N/IDT/NEG_TAX_TYPE
This view of the table is available in the user configuration section of the menu for use by the customer to either override a line-item from the standard view of the table or to assign a new entry. The table is shipped blank and a user will not likely need to make any adjustments using this table. In the print screen above we show the example of an entry in the customer view of the negation table that changes the standard table view for the AC tax type. Here the negation has been switched to the “I” direction rather than the O direction. This is just an example of how this customer view of this table could be used if needed.

Offset Configuration by Country

Often with Canada taxes, a vendor may charge the Federal level GST but they are not registered in a specific province to collect PST. In this situation the person receiving the invoice may be required to self-accrue the PST for their province. A new table
/IDT/D_PART_SA
 has now been created to address the need for an offset posting to be created for the accrual of the required tax. This new table can be used for the self-accrual of Canada PST for various provinces but it can also be used to establish other self-accrual entries in situations where the Determination has returned only one tax block and must be offset with another side to the entry other than the customer or vendor account. This was often handled in the past with the system user creating a second custom authority and special rules to reverse the sign on the custom authority to post the credit to the tax liability account and also the debit with an offsetting custom authority to the expense account. This new table can eliminate the use of a second custom authority in such cases however it should only be used for items that are being accrued from a Vendor invoice as a non-recoverable and charged to expense, as the offset line is not included in the audit database or tracked for recoverability of the item. This table cannot be used now for offsetting items charged to a customer through an SD sales order.
Tax Code and TCQ Configuration
In order for the new table to work you will first need to configure a new tax code that will be used to trigger the self-accrual input tax of the specific authority’s tax liability. In the example below, we established I2 tax code as a driver input tax code and created a Tax Code Qualifier to assign the same tax code number as the final tax code in the transaction for the PST self-accrual. A data entry person in Accounts Payable would need to be trained to recognize when the vendor should have charged PST for the province and know how to input the new tax code that drives the self-accrual process. (With proper use of access sequences in the calculation schema, a system could be configured to include a vendor and ship to address sequence logic to allow for an automated assignment of the new tax code for default processing.)
When the entry is triggered from the table below the
LINE.USER_ELEMENT.ATTRIBUTE46
 is populated with the tax code that was used. This attribute is then also used in the tax code qualifier conditions in order to drive the final tax code to the same final tax code for reporting purposes. See example above of the TCQ for the self-accrual input tax code for Canada PST in British Columbia.
Table Configuration
Transaction code:
/N/IDT/OFFSET_CONFIG
Now that you have created the tax code and the TCQ then next process is to configure this table as shown above with two options for setting the tax parameter and tax parameter value:
Option 1: Tax parameter set on tax type allows you to then set up to 10 values in the tax parameter value field. Each must be separated by a comma. This option can be used if you want to drive the mapping based on a set of tax parameter values that are used for the various applicable transactions.
Option 2: Tax parameter set on authority type allows you to then set up the table entry based on the authority (in this case PST) that you want to self-accrue for the transaction.
The offset account must always be either to a NVV type of account key that drives the posting to the expense account, or you must set this to an account key assignment that will post to another expense account from the P&L. This side of the entry coming from this table is never posted to the audit database and must be used only for expensing the debit posting side and never assigned to a recoverable tax account on the Balance Sheet or to a liability account that must be reflected in audit.
Required Route Configuration with New Journey for Offset
A new journey has been established for this self-accrual offset table process and mapping must be done in the /IDT/AUTO_JOURNEYS custom view of the table to activate this function for given processes within the system. See below an example of the required additions you must enter to this table to activate the use of the offset functionality:
Transaction:
/IDT/AUTO_JOURNEYS
The new journey /IDT/JOURNEY_SELF_ASSESSMENT must be mapped in this table for each of the routes that you need the offset to work within. The FI, LIV, and non-group A/P routes have been mapped to activate this response logic for vendor invoices. If you have other processes that you may also have need for an offset function, then other routes may also be required. In this example above, we did the mapping for only company code 4000 for a Canada scenario however you may wish to leave this with an “*” in order to cover all possible company code requirements.

Plants Abroad Billing Types

Transaction code:
/N/IDT/PLANTS_ABROAD
This table is used by the Plants Abroad Journey to identify which billing types are to be used for the Plants Abroad calculation. The table is customer view only and is shipped blank. The user will need to populate the table with the correct billing type for their specific Plants Abroad calculation and configuration settings. In the standard set up scenario this would be billing type WIA however a user could elect to create a different billing type for this purpose and would need to enter the new billing type here for the Plants Abroad journey to pick it up correctly.
To remove an entry from this table, switch over to change mode on the table, select the line you wish to delete and then select on the delete button (shift F2).
To add an entry to this table, switch over to change mode on the table, select the
New Entries
 option from the app menu and enter the new billing type from the drop-down list. Hit
ENTER
 to save the entry.

FI Process Control Configuration

This table defines what “FI Processes” might run for a specific document type on the transaction and lists them in order of preference.
Each “FI process” then has logic to see if it is appropriate for the current transaction.
Transaction code:
/N/IDT/FI_CONTROL_V
The standard view of this table contains some of the mappings of standard document types as they relate to the hierarchy of tax calculations used for the document type. You will see that there are multiple tax calculation process classes assigned to a given document type code, for example: SA document type could use the following nine process class:
  1. /IDT/FI_PROC_DEFAULT_GL
  2. /IDT/FI_PROC_CUSTOMER_CREDIT_M
  3. /IDT/FI_PROC_CUSTOMER_INVOICE
  4. /IDT/FI_PROC_VENDOR_CREDIT_MEM
  5. /IDT/FI_PROC_ VENDOR _INVOICE
  6. /IDT/FI_PROC_LIV_CREDIT_MEMO
  7. /IDT/FI_PROC_LIV_INVOICE
  8. /IDT/FI_PROCESS_DEFERRED_TAX
  9. /IDT/FI_PROCESS_FB05
The sort order of these classes is dependent on the given document type. A document type for a credit memo would use the credit memo class as higher in this sort order than an invoice class. A document type for an invoice would use the invoice class first followed by the credit memo class. Not all classes are assigned to the table depending on where the document is used. Example: for a customer document type, you would not assign a vendor class and vice versa. The list should sort from the most specific to the most general being at the top of the sort. This is why you see the deferred tax and FB05 process classes listed last on the sort order for SA document type as they are the most complex and specific.
The table below lists the various tax calculation process classes including a brief description.
Tax calculation process CLASS
description
/IDT/FI_PROC_DEFAULT_GL
Used for general FI transactions that do not contain either a customer or a vendor
/IDT/FI_PROC_CUSTOMER_CREDIT_M
Used for a customer credit memo or returns type of document
/IDT/FI_PROC_CUSTOMER_INVOICE
Used for a customer invoice type of document
/IDT/FI_PROC_VENDOR_CREDIT_MEM
Used for a vendor credit memo or returns type of document
/IDT/FI_PROC_VENDOR_INVOICE
Used for a vendor invoice type of document
/IDT/FI_PROC_LIV_CREDIT_MEMO
Used for a LIV vendor credit memo process
/IDT/FI_PROC_LIV_INVOICE
Used for a LIV vendor invoice process
/IDT/FI_PROCESS_DEFERRED_TAX
Used for either a customer or vendor document that uses the deferred tax process
/IDT/FI_PROCESS_FB05
Used for a document that could be for customer invoice or credit memo, vendor invoice or credit memo, deferred tax or cash discount.
/IDT/FI_PROC_AP_DOWN_PAYMENT
Used for A/P down payment process
/IDT/FI_PROC_DELIV_NOTA_FISCAL
Used for Brazil Nota Fiscal
/IDT/FI_PROC_GM_BR
Used for Brazil goods movement process
/IDT/FI_PROC_SERVICE_ENTRY_SHE
Used for service entry sheet process
/IDT/FI_PROCESS_GOODS_MOVEMENT
Used for the Goods Movement product processes
The table is part of the standard settings and set as shown as part of the initial transport process however your system may be configured to use more than this list of document types or you may have created your own customer document types. The standard view of the table as provided is not all inclusive and you must add entries to the customer view of this table based on your specific needs.
If you go back and review the print screen of the standard view of this table, you will see that there are two lines at the beginning that are populated without a document type being specified. The two lines are added to the table for specific situations where the document type is not available at the time of the document line being called. This happens within the calculation for a purchase order line-item and for a deferred tax processing line-item. Both classes are added to this table for specific processing needs that occur when the tie to a document type is not possible due to system logic within SAP. You will not need to worry about these two lines, nor will you have to adjust them within the customer view of this table. They are internal to our processing logic.
Transaction code:
/N/IDT/FI_CONTROL
This transaction will take you to the Customer view of this table in the Customer Setup menu. In this view of the table you can add your own lines for any missing document types that you need to configure, and for missing class configuration for all document types you are using. Note that the sort order range again uses numbers starting at 100001 through 999999. In the sort order the program starts with the highest number and the most applicable highest number in the mapping is used.
The table initially comes up in display mode. Switch to CHANGE mode and select NEW ENTRIES. This table is shipped blank for user input. Because this is a Customer view you will not be able to check the standard checkbox as this is only used on the standard view of the table.
Overriding the Standard Table
If you wish to remove or override a line that is on the standard view of the table, you will need to replicate the full set of classes that you want in your new mapping for the given document number. (Excluding the line you wish to remove) For example:
View of the standard table for SA document Type.
If you have configured your system differently so that customer credit memo and invoices are using a custom document type rather than SA for your given transaction you would want to remove the line 20 and 30 from this list. To do so the entry in your customer setup view of the table would look like this example below.
Because of the way the table sort order works it will pick up the last applicable line entry starting with the customer view of the table (100050,100040, etc.) and ending with the last sort order applicable from the standard view setup (50,40,30,20, etc.) for the given document type.
It is important that you check your system configuration for each document type and make sure that this table has the appropriate classes listed for the document type you are using based on the list of Account Types that have been checked as “allowed” for the document type. To do this, go to the following transaction:
Transaction:
SPRO
 navigate to
> Financial Accounting > General Ledger Accounting > Business Transactions >G/L Account Posting > Make and Check Document Settings > Define Document Types.
Select your document type and double select to go to the first screen on the document type.
Review the account types that have been allowed for the given document type. If Customer has been checked then you will want to have the Customer Invoice and Customer Credit memo class listed for this document type in the
/IDT/FI_CONTROL
 table. Likewise, if Vendor is checked then add the Vendor Invoice and Vendor Credit Memo Class. If G/L account is checked then you will likely need the Default G/L class. If this document type will be relevant for deferred taxes or cash discount processing then the respective classes will also need to be added to the list for this document type in the table.

Tax Relevancy Table

A customer may wish to set a given tax code as one that is not relevant to tax using ONESOURCE Indirect Tax for a couple of reasons:
  • The tax code is not relevant to tax at all and the user does not want the tax code included in any calls to Determination.
  • The tax code is one that will be used in a specific module of SAP using SAP’s native or internal tax processes and will not be used for a call to Determination for an external tax calculation.
For both situations a table has been added so a user can identify these tax codes to prevent a call to Determination. This table is available in the Customer Setup and Extensions Configuration Tables menu.
Transaction Code:
/N/IDT/TAX_CODE_REL
By adding a given tax code for a specific list of countries or company codes you are telling the system to not include this tax code in any request call to Determination for your country/company code combination. A user can note in the Option column if the exclusion is because the tax code is exempt for tax completely, or if the tax code is to only be used by SAP internal or native tax processing separately from a call to our Determination tax engine.
This table has only a customer view and will be shipped empty upon download of the software.
Tax codes that are added to this table should be used like a driver tax code to tell the system the item is not relevant to a tax calculation. This is different than the use of a tax code that is brought back from a tax call as being exempt from tax after a call has already been completed by determination. In such a case a user should have two different tax codes.
  • One should be used via the tax code qualifier as an exempt tax amount or zero tax. Entries using an “Exempt” tax code will create a call and calculation in Determination that will go to audit along with other tax codes on the same transaction. They would not be included in this table. Such would be the case if a trans-editor sent a tax block for one tax authority as taxable and a second tax block on the line as exempt for another tax authority for possibly a regional, city, or district level tax.
  • A tax code as Not Relevant to tax would be used on the line as a driver and would not make a call for the whole line-item on the order. It would be used on this table to tell the system to not make a call at all for this item. No tax will be calculated, and nothing sent to the audit database for this line.
The program looks for an account key associated with this non- relevant tax code as part of an internal check. We therefore need a “dummy” account key to internally have the program find and use for the non-relevant tax code assignment. We can do this by creating a new configuration within the general configuration table and create the dummy account key using transaction code
OBCN
.
  1. Set up “IDT” account key in OBCN with same configuration as current NVV account key.
  3. Add line to transaction
    /N/IDT/GEN_CONFIG_VALS

Tax Filters Table

The tax filters table was added to the system with release 6.4.0.0 as a replication of the tax filters option that was provided in the prior 5.x Integration as part of the TaxMappings.xml and its Extension file. This was originally provided to filter out or remove from SAP a zero-rated tax result that was returned from Determination. Such zero-rated tax types as NL, ZC, ZE, ZR could be mapped to remove the additional tax block from the calculation. However, this removal only applied to the SAP side and would still carry over this zero-value block into the Determination audit data. As such it was only used to remove zero valued tax results. The new transaction and table with sample data is shown below:
Transaction Code:
/N/IDT/TAX_FILTERS
With this new feature as provided in the Customer Configurations Tables menu, a user can once again filter out these tax types. The prior version of this also allowed the option of filtering based on other objects such as by tax code or authority name. The new table also allows for this via a drop-down list in the options column of the table. See example below:
If the AUTHORITY_NAME option is selected, then the user could input in the General Configuration Value column the name of the tax authority that is being brought back in the XML thereby filtering based on the authority name. Similarly, the TAX_CODE option could be used if a filter omission of a given tax code is desired.
The AUTHORITY_UUID option was added as a more stable mapping based on the UUID number of the tax authority. Whereas the AUTHORITY_NAME field value can change over time, the UUID number does not change. We recommend that if you desire to filter based on the authority that you change your mapping to use the AUTHORITY_UUID instead to avoid a future issue with the name change. See example above. The UUID can be copied from the XML in the log file.
The second column of this table is the sequence number column. A user would populate this in numerical order for each line of the table. This table is a customer use table and is shipped blank with no entries. If you want to filter any results based on the criteria you will need to enter new lines to this table.
Expected Results:
Suppressed taxes will not appear on transactions/documents.
Suppressed taxes will not be saved in BSEG/BSET.
Suppressed taxes will not be shown in normal XML log (NON_AUDITED log).
But suppressed taxes will be shown in audit log. Meaning AUDIT logs will be shown with ALL the taxes.
Audit database will contain all the taxes including suppressed and non-suppressed.

Product Version Table

The product version table was added to the system in a prior release but until 6.4 it was hidden for internal uses. As of release 6.4 this table is now available for viewing within the Basic Setup-Display only menu. The table contains the most current version information based on the transport of the version to your system. There should be one line on this table per product and will show you which upgrade version of the product you are currently using. (If you also have the Goods Movement product installed then you would see a line for product GM along with a version number.) It is not a table that the user will need to be concerned with configuration but is used for support information.
Transaction Code:
/IDT/VERSION
 - Global Next Product Version

Summarization of Tax Lines on BSEG and BSET Tables

SAP has a limit of 999 lines on FI or LIV documents and users often have a need to summarize or consolidate like lines to maximize the size of the entry. (Currently this feature does not work on SD billing documents.) To decrease the number of tax lines on a large order we have provided a new table that can be used to control summarization of the tax data lines on the accounting document for like information. This new table is a single customer view table located within the Customer Configuration Tables menu. A user can summarize tax data lines for both the BSEG and BSET tables based on General Ledger account, Tax Code, Account Key, and UUID tax authority. This feature will not summarize the expense lines. The table is part of the initial transport and is shipped blank for users to be able to configure.
Transaction:
/N/IDT/TAX_SUM_CONFIG
This table is shipped blank and the user can elect to input a summarization like the example shown above. The table can be configured for specific country groups and company codes. In the example above all four fieldname options are shown and this would provide the most detailed example with the least amount of line-item summarization based on all four criteria at once. One could also elect to have the maximum amount of summarization by only entering the first line of G/L Account. In all cases it is imperative that you start by using the G/L account fieldname first in your selected setup. This table summarization logic will also keep debit and credit entries summarized as separate totals to avoid any possible logic errors where the net of the lines sums to zero. If you elect to add additional levels of summarization then the tax code, account key and UUID options may also be selected.
A new option has been added to this table that provides user the ability to prevent the standard SAP summarization from happening on the FI and LIV documents. If the user selects this option then the SAP method that does the standard summarization will be skipped and the other table options on this table will follow afterwards to allow alternate summarization. This can sometimes be helpful for companies that utilize large LIV or FI documents that contain many lines and multiple account assignment features that can hit the 999 item limit per line. Depending on how tax codes and account keys/accounts are assigned, standard SAP summarization may cause summation of different tax authority items that are not in sync with desired detail reporting needs downstream (more often seen in US sales tax scenarios).
A new BADI function has also been added to this table as one of the options. A user can elect to use it to add other custom ABAP enhancements to the summation logic such as limits based on the number of tax lines on the document, document type, or any other logic that the user wishes to add to the summarization beyond the four options noted above. For example, you may wish to only have summarization occur on the transaction if there are more than 100 revenue/expense lines on the document.
The new BADI is
/IDT/BADI_ADJUST_TAX_SUMMATION
. You can learn more about utilizing this addition via the Installation and Programmers Guide. This BADI was added as of release 6.2.0.1. If you select this option from the drop-down list on the table then you can activate it and program your required logic within the BADI using an ABAP program. The BADI must be selected and activated in this table for the logic to be applied for your selected company code(s).
Currently this table will summarize BSEG and BSET table tax lines only for LIV and FI module transactions being posted to the General Ledger. We have not extended this functionality to SD billing documents. The process will be extended to billing documents in a future release of the product.
Consideration When Using Summarization
If you elect to summarize data on the BSEG and BSET tables then your VAT report will reflect this summarized level for reporting. This will need to be considered when looking at downstream reporting processes and where you will get your information for reporting and compliance. The Audit database in determination as well as the BSEG and BSET tables will have summarized data at the level that you have selected and depending on how you have assigned tax codes and G/L account numbers you may require a finer breakout for reporting and compliance needs than you have allowed with this configuration. If this is an issue then you may be able to get full detail data on your transaction by using the data stored in the
/IDT/D_TAX_DATA
 table.
The
/IDT/D_TAX_DATA
 however may not have all the fields that you require. Currently the tax amount is not repopulated there and a user may elect to add additional fields to the
/IDT/D_TAX_DATA
 table to have the required fields for detailed reporting using this table. Use of summarization will require that you play with this feature given your specific transaction size, complexity, and tax policy. Several iterations of testing and adjustments may be required.
Summarization for Partial Payments on Deferred Tax Invoices (RFUMSV25)
If a deferred tax invoice with multiple line-items is processed with a partial payment the system will potentially incorrectly transfer to the target tax account the full amount of the line-items rather than the partial payment amount. This occurs at time of the F.38 transfer program being run, and only on invoices that have multiple lines on them that are charged to the same tax code.
Workaround: If you use partial payments on deferred tax invoices this issue can be avoided by setting the tax summarization table configuration to summarize tax lines at both the tax code and G/L account level. By doing this the lines on the invoice will be summarized into one tax line for the authority and the F.38 program will then handle the amount correctly and only transfer the partial payment amount to the target tax code.
Special Note for India
Per documentation for India GST that we have seen, your India company codes should not contain any summarization. Make sure that if you use the summarization table that you do not blindly use the “*” asterisk for selection of company code or country group. Take time to create appropriate country groups so that you configure this table to not include country India.

This article applies to:

  • Product: ONESOURCE Indirect Tax
  • Sub Product: SAP