Skip to Content

Frequently Asked Questions about Currencies in SAP BRIM

When selling or implementing SAP Billing and Revenue Innovation Management (SAP BRIM) several questions about currencies can arise. The purpose of this document is to provide the SAP customer facing specialists with answers to some frequently asked questions about currencies in SAP BRIM. SAP BRIM joins the SAP Customer Relationship Management application, the SAP Convergent Charging application, the SAP Convergent Invoicing package, and the SAP Customer Financial Management package to create a comprehensive software solution that supports the order-to-cash business process for service industries.

Is it possible in SAP Convergent Invoicing to receive inbound information in different currencies and to create an invoice with one currency?

Yes, the postings will then all be made with the invoicing currency.

Is it possible in SAP Convergent Invoicing to create multiple posting documents with different currencies for one invoicing document?

No.

Where do we maintain the currency exchange rates used in the billing/invoicing process to convert the different currencies line items into the account currency?

The currency exchange rates are maintained centrally in FI(-GL) in SAP ERP Central Component (ECC) and used in CI/ FI-CA in various contexts. From a homogeneous aspect, CI, FI-CA and FI-GL are just components of the integrated SAP ERP. It doesn't matter where the currency exchange rates sit in SAP ERP as long as they sit 'somewhere' and there is only one copy that governs/controls everything in SAP ERP.

In the Implementation Guide (IMG), the configuration interface/tool for SAP ERP, there are many places within the various modules of SAP ERP where there is a configuration entry to maintain exchange rates, but they all arrive at the self-same screen/transaction. One configuration navigation path is "Enterprise Controlling → Consolidation → Data → Automatic Posting → Currency Translation → Exchange Rates → Maintain Exchange Rates", but there are at least 3 other paths all leading to the same transaction.

In case we put SAP BRIM on top of a general ledger other than SAP’s general ledger where does SAP CI/FI-CA take the currency exchange rates from?

In case we have another general ledger that is the corporate general ledger (e.g. Oracle), one must have a process to synchronize the applications that need to share and harmonize this data. The 'organizational arrangements' usually define which application is master and which is slave. They are influenced slightly by the 'technical arrangements' too. There are, of course, all of the integration topics to sort out: i.e. of FI-CA to SAP general ledger or to external general ledger.

How can one define a custom currency in a SAP CC 3.0 system part of a SAP BRIM systems landscape?

The SAP proprietary currencies consist of:

·         A unique SAP currency code

·         An ISO code which can be:

-       Filled with a proprietary and specific value

-       Filled with the code of an ISO 4217 currency defined by the International Standards Organization

-       Empty when a currency like "PNT" (Point) does not correspond to standard currencies

·         The precision which represents the number of decimal places

As SAP ERP is the master system of the currencies, one has to define first the custom currency as SAP currency in the SAP ERP system and then synchronize the list of currencies of the SAP ERP system with the list of currencies defined in the core database of the SAP CC system by using the SAP CC Core Tool menu “Tools → Currencies → Synchronize”. The synchronization only takes into account SAP currencies.

How can one define an additional currency in a SAP ERP system?

Here are the steps for defining an additional currency (e.g. USD6 in addition to the standard default currency USD) in a SAP ERP system:

1.    Access SAP Customizing Implementation Guide (IMG) → NetWeaver → General Settings → Currencies → Check Currency Codes. Here you create a new entry for the additional currency, for example USD6. NOTE: do not set the primary currency indicator/checkbox. If the primary indicator is not set on the ISO currency, in this example USD, then be sure to add the check box indicator to USD so that USD6 is converted to USD in CI Invoicing.

2.    Access SAP Customizing Implementation Guide (IMG) → NetWeaver → General Settings → Currencies → Set Decimal Places for Currencies. Create new entry USD6 and input 6 in the Decimals column.

3.    Access SAP Customizing Implementation Guide (IMG) → NetWeaver → General Settings → Currencies → Enter Exchange Rate. Here you indicate that USD6 to USD = Direct Quotation 1.00000.

How does the rounding of decimal places take place in SAP Convergent Charging 3.0?

The bulk-loader of SAP Convergent Charging 3.0 adapts the amounts of the charged items regarding their currency precision. The following sequence describes how the amount and currency are adapted by the bulk-loader:

·         The not relevant trailing zero are removed e.g. 1.23400 EUR -> 1.234 EUR

·         All the compatible currencies with the amount currency are listed. Two currencies are compatible if they have the same ISO code. For an amount in EUR, the list could be EUR, EUR4 and EUR6.

·         The currencies with a precision lower than the number of the amount decimal places are removed from the list e.g. EUR is removed from the list. If the list is empty, the charged item is rejected because there is no way to send the amount to SAP CI.

·         The compatible currencies having the closest precision with the amount precision will be the amount currency e.g. for the amount 1.234, the currency EUR4 will be chosen.

·         The amount is adapted to have exactly the precision of its new currency e.g. 1.234 EUR4 will be 1.2340 EUR4.

           Finally the amount 1.2340 EUR will be sent to SAP CI as 123.40 EUR4.

If the charged item has several amounts and several currencies, the amounts will be converted to have the same currencies or compatible currencies. If the currencies aren’t compatible (EUR and USD), the charged item is rejected. The reason of this decision is that SAP CC doesn’t know which currency field is associated to which amount field.

Here are some samples of charged items having several amounts and currencies and how they are converted to be loaded into SAP CI:

Charged Item Field Values

BIT Field Value

EUR

1.23

EUR6

9.87

EUR 1.23

EUR 9.87

1.234

9.87

EUR

EUR6

EUR6 12340.00

EUR6 98700.00

EUR

1.234

USD

9.876

Not possible.

1.23

9.876

EUR

EUR6 12300.00

EUR6 98760.00

1.23

9.876

1.23

98.76

EUR

USD

EUR

USD

In regards to the step where the bulk-loader removes the currency where it is lower than the number of the amount decimal places, what if there is only one currency in the list (e.g. JPY) and the amount is e.g. 2.11? Would the bulk-loader logic remove the only matching currency (e.g. JPY has a precision of zero) since it is lower than the number of amount decimal places?

In this example the bulk-loader CANNOT send the amount JPY2.11 because there is no compatible currency with JPY supporting at least 2 decimal places defined in the landscape. The goal of the bulk-loader is to convert data from SAP CC to SAP CI. The conversions are technical conversions and they are not business (via exchange rate for instance) and they comply with the strong constraint that the conversions must be lossless. For instance, if the rater indicates that a prepaid account has been debited of JPY2.11, then the bulk-loader MUST NOT inform SAP CI that the prepaid account has been debited of JPY 2. That's the reason why the bulk-loader throws an exception when the amount has too many decimal places regarding its currency. The error message one gets is the following: "BillableItemFieldValidatorException: No currency was found to format an amount with '2' decimal places".

So for this example one has to create a new currency JPYX having a precision of 2, or the amount JPY

2.11 must be rounded in the raters. There are several ways to do that:

  • if the SAP CC platform has to work with  currency precision only, one can configure the parameters "TRANSACTION_*_PRECISION" and "TRANSACTION_*_ROUNDING_MODE" to force the charging engine to work with the currency precision.
  • or the amount rounding can be done directly in the price plan.

Is there a way to influence the bulk loader currency selection procedure in SAP CC?

No.

Does the SAP CC 3.0 parameter TRANSACTION_PRECISION need to be set to “-1” and TRANSACTION_ROUNDING_MODE to “nearest” in order to enable the rounding of decimal places in SAP CC 3.0?

The bulk-loader sequence for adapting the amount and the currency is independent of the TRANSACTION_PRECISION and of the TRANSACTION_ROUNDING_MODE. These two configuration parameters are relevant for the raters. They define the precisions of the amounts computed by the charge components. If TRANSACTION_PRECISION is between 0 and 6 then the amounts computed by the charge component can have up to the same number of decimal places e.g. up to 4 if TRANSACTION_PRECISION is 4. The TRANSACTION_ROUNDING_MODE defines how the amount is rounded if it has more decimal places than defined in the TRANSACTION_PRECISION. If TRANSACTION_PRECISION is "currency precision" (=-1) then the amounts computed by the charge component will have the number of decimal places of the currency of the charge component. For instance, if the charge component is configured to compute amount in EUR4, then its computed amounts will have up to 4 decimal places.

Which currency is used in the rounding if the charge is defined as multicurrency and the charge plan is defined as multicurrency (the advance currency of the charge within the subscription)?

The currency of a multi-currency charge component can be specified in the charge plan item or charge condition. If the charge plan item or the charge condition is itself multi-currency then the currency MUST be defined by the charge activation of the subscription or by the charging contract items. As soon as the currency is defined, it isn't possible to overwrite it in an upper level e.g. if the charge condition defines the currency then it isn't possible to define another currency in the referencing charge activation. The currency of a charge component is the first one found from the charge activation to the charge component.

Does the currency setting on the subscriber account in SAP CC 3.0 overwrite the currency setting on the charge/charge plan/subscription or does the system issue an error if the currency is inconsistent (like in SAP CC 2.0)?

Like in SAP CC 2.0, the currency of the subscriber account in SAP CC 3.0 is mainly relevant to check customer related provisioning inconsistency and is not used as possible currency of a multi-currency charge component. 

What do the parameters TRANSACTION_DETAIL_PRECISION and TRANSACTION_ROUNDING_MODE affect?

Transaction is the internal business object representing the result of the activation of a charge component. The transaction has main fields e.g. the computed amount and details e.g. the computed property introduced in the price plan. The transaction is visible in the charged item mapping of the charge condition as the possible values for the charged item fields. Some of the transaction details are numerical. The two configuration parameters TRANSACTION_DETAIL_PRECISION and TRANSACTION_ROUNDING_MODE are used to define the precision and the rounding mode of these numerical details.

Can I use more than 5 decimal places for amounts in SAP CI?

Generally currency maintenance in NetWeaver allows 5 decimal places and exceptionally 6 digits. Please note that for the standard fields like BIT_AMOUNT, domain WRTV7 is used which is a 7Byte packed field.

Can I use more than 6 decimal places for amounts in SAP CI?

Currently there is no standard solution for handling more than 6 decimal places in CI. See question “How to use arbitrary number of decimal places for ISO and non-ISO currencies in SAP CI?”.

How to use arbitrary number of decimal places for ISO and non-ISO currencies in SAP CI?

An option for a project can be to provide in BIT_AMOUNT and BIT_CURR a TCUR* conform currency code and an amount with a corresponding number of decimal places.

If the customer wants to use 8 decimal places or even an unrestricted number of decimal places, then an option could be to use a character type field (e.g. CHAR18) in the billable item class to store the amount in maximum precision. For example: Z_BIT_AMOUNT = 1.23456789 also linked to the currency stored in BIT_CURR.

If you want to use the maximum precision amount for computation, then you can convert it into a packed field.

A prototype of a CHAR18 to WRTV7 conversion is present in function module Z_GL_CONVERT_CHAR18_TO_WRTV7 in System VBS.

Tags:
Former Member

No comments