Products Priced in Other Currencies Should Not Be Available for Selection
We maintain separate prices for INR and USD. While preparing sales transactions such as Quotations, Sales Orders and Invoices, only products that have a price defined in the same currency as the transaction should be available for selection.
At present, Tuhund automatically converts prices from other currencies and allows those products to be selected. We do not want this behaviour. Products that do not have a price in the transaction currency should not be displayed for selection.
Tuhund's current behaviour is designed to support real-world international pricing rather than simply converting a price whenever the transaction currency is different.
For example, suppose you are preparing a quotation, PI, CI or another sales transaction in VND.
-
Tuhund first checks whether a price is explicitly defined in VND. If it is, that price and its applicable pricing rules are used.
-
If there is no VND price, Tuhund checks whether a price is available in the company's home currency. If it is, the system converts that price to VND using the current market exchange rate.
-
This conversion does not use a rate published by the Federal Bank, Customs or another authority. Those rates are relevant for financial and statutory transactions. For commercial price conversion, Tuhund uses the actual bank selling rate prevailing at that time, with the system accounting for rates available within the preceding few hours where necessary.
-
If a price is not available in the home currency, Tuhund checks the configured priority currencies, such as USD, then EUR, then RMB.
-
If no price is found in those currencies, it can finally look for a price in any other available currency.
This means you can maintain prices in multiple currencies while still preparing a transaction in any currency enabled through the Currency and Exchange Rates management.
For the requirement described above, our experience has been that the more robust approach is not to alter this underlying pricing mechanism, but to control which pricing structure is applicable to which transaction.
This recommendation comes from a considerable amount of implementation and support experience with real-world pricing scenarios. A requirement may appear straightforward when considered in isolation, but over time organisations tend to encounter situations involving multiple currencies, customer-specific pricing, different sales processes, different users, exceptions and changes in commercial policy.
This is also consistent with the Poka-Yoke principle followed in Tuhund. Rather than depending on users to remember which products should or should not be selected, the system should be configured so that the correct pricing structure is naturally presented to them and incorrect combinations are prevented by design.
This is where Tuhund's Price Lists, Price Maps and Record Types become important.
For example, you could maintain:
-
INR Price List
-
USD Price List
-
A general/common-currency Price List if required
-
Additional currency-specific price lists where necessary
The application of these price lists is controlled through Price Maps. A Price Map is not simply a currency filter. It can consider record type, entity type, customer group, user group, terms and several other parameters.
The currency restriction itself can be controlled through the Record Type.
For example:
-
USD Quotation → restricted to USD
-
Other Currency Quotation → allows the required currencies
The Price Map then determines which price list and the other pricing rules apply to each combination.
This approach allows the organisation to maintain completely independent INR and USD commercial pricing while still retaining Tuhund's broader ability to work with currencies where a direct price has not been defined.
More importantly, the configuration becomes part of the business process itself. The user does not have to know which price list should be used or remember that a particular product should not be selected. The system's configuration guides the transaction towards the intended outcome.
That is generally the approach we recommend in Tuhund: use configuration to prevent the wrong business outcome rather than relying on users to avoid it.
