SpendMap User Guide (v15)

Tax and Exchange Rate codes can also be added "on-the-fly" as you work in other areas of the system.

You can track changes to this master file with the Master File Update Log.

Once a Currency Code is specified for a supplier in the [MISCELLANEOUS] Folder of the Supplier Master File, the supplier's pricing in the Item Master File and on Purchase Orders and other documents for that supplier will be entered in the supplier’s currency. The currency code or symbol will print beside dollar values on POs and other forms and will show on various screens and reports.

On screens, reports and when making internal calculations that can include dollar values with different currencies (i.e. when the dollar values could include foreign currency amounts), all values will be automatically converted to your Landed Currency based on the exchange rate for each transaction. Some examples include cost center budgets, inventory valuation, PO listing, when determining requisition approval routing based on dollar amount, etc.

For subsequent transactions related to Purchase Orders (e.g. releases, invoices, etc.), the conversion can either be based on 1) the exchange rate for the applicable PO (i.e. locked in when the PO was created) or 2) the current exchange rate at the time the calculation takes place (e.g. when the transaction is being processed). For details, see the applicable setting in PO Processing Settings.

•You must establish your default/landed currency using the setting in User Defined Field Defaults.

•The Exchange Rate will default on POs and other documents based on the selected supplier.

As with Account Coding, some organizations do not code transactions with taxes until very late in the procurement process, often not until the supplier’s invoice is approved and processed. While this might satisfy the needs of the Accounting Department, “late stage” tax coding means inaccurate valuation for transactions in the procurement process leading up to the invoice approval stage. For example, if a Requisition or PO is processed without taxes, the spend history reporting, budget commitments, inventory value, etc. will be off by the amount of the taxes.

Therefore, a common goal for many organizations when implementing e-procurement systems is to have transactions coded with the appropriate taxes earlier in the procurement process, ideally at the very first stage (requisition creation).

In addition to more accurate reporting, if you are using the Invoice Approval Module, when invoices are finally processed in A/P, the taxes will already be filled in for each transaction, so there is less work for the people processing invoices and the invoice approval process can happen much faster, often contributing to the elimination of late payment charges, the ability to take advantage of early payment discounts, etc.

To reduce data entry, eliminate the need to train end-users on tax rules, and to help ensure that transactions are coded with the appropriate taxes as early as possible in the procurement process, SpendMap can default the taxes on POs and other documents based on a number of fields.

The following is the priority of fields that affect how taxes default on POs and other documetns - if a field is not being used to default the taxes, the system will use the next setting in priority sequence...

1.The item’s Tax Category

2.The Cost Center's tax rate (either the charge-to OR ship-to cost center, based on the applicable setting in Tax Settings)

3.The Item's tax rate

4.The Supplier's tax rate

5.System-wide default Tax Settings

 
That is, other than the item’s Tax Category (details below), when creating POs and other documents in SpendMap, the cost center’s tax rates are considered to be most important/accurate for each document (since taxes are usually based on where goods are shipped or are being used), while the system-wide tax settings are least important/accurate, since there are many other fields/rules that could affect taxes on an order-by-order basis.

While SpendMap will consider taxes that are set up in all areas outlined above for each order, the lower priority tax defaults will be overridden by higher priority settings on a document-by-document basis, based on the selected item, supplier and cost center. However, if tax codes are not set up for an item, supplier or cost center, the system-wide defaults will be used.  Therefore, if you pay the same taxes on all your orders, you only need to set up the system-wide defaults, which will be applied to all orders since nothing else will override them.

Once taxes have been determined by considering the cost center, item, supplier and system-wide tax defaults, the Tax Category specified for the selected item will be considered and will override the taxes, if applicable. That is, for the Tax Category to apply, a tax rate must first be determined using at least one of the other four default options.

For system settings related to taxes, see Tax Settings.

The terms "Tax 1" and “Tax 2” are user-definable and can be renamed on screens and reports.  

You can use one tax field or both of these fields if you pay more than one tax on your orders.  For example, most companies in the USA would use a single field as “State Tax” while many Canadian companies might title the fields “Provincial Tax” and “Federal Tax”.  Other common examples include “County Tax”, “City Tax”, etc.