Translation Tables

[doris_karapici]

Hello everyone,

we have a development in CC 4.0 on a charge where we use a translation table. I read a hint on documentation that the Tier tables and translation tables are technically outdated and shouldn't be used.

The customer plans to upgrade the system to a higher version. Could someone give me a hint on what type of table I should use instead of the outdated translation table?

Thank you,

Doris

[francois_thimon · Accepted solution]

Hi Doris and Marius,

Thanks for your replies.

The official recommendation is really to go for mapping tables now, so we'll always recommend them over translation tables. They work slightly differently, but you can still achieve the same results using mapping tables anyway.
In particular, even though mapping tables no longer have the "Any" wildcard, the mapping table logic component has two output branches, to differentiate the case where no matching entry has been found. I understand you need that; you'll no longer have to emulate it using a special output value.

Regarding Marius's remarks about mapping tables being usable in contracts and charges.
I'm not completely sure this was your point but yes, charge components and macros may have parameters of the "Mapping table ID" type, and these parameters can be redefined at each level (i.e., contract, charge plan). Each of them contains both the mapping table class's name (mandatory, to force you to reference only tables compatible with the pricing logic), and the actual table name (optional, since it can be defined later by the charge plan or the contract).
Using that, you can make your logic point to any specific mapping table (from the catalog or from a subscriber account) depending upon your needs. This works with range tables too.

There's also a "Mapping table key" parameter type. Similarly to "Mapping table ID", it's a subtype of "String", but it indicates when a parameter is meant to be used as an input value for a mapping table component.

Furthermore, here are some new features that were developed for mapping tables, but not for translation tables:
- In the pricing logic, the mapping table component has a "longest prefix match" feature, to find the entry which best matches your input (even without having exactly the same complete value).
- The CC Cockpit (web-based replacement for several Core tool and Config tool features) has applications dedicated to defining mapping tables, range tables, and their classes.
- The mapping table editor (in Core tool and Cockpit) has advanced features for searching, sorting and paging the rows, and also lets you export the rows to a CSV file (either all the rows at once, or just a sorted and filtered list).
- Since SAP CRM (and SAP SOM) are integrated with mapping/range tables, there's an option in the SOAP WS API to list table descriptions without their rows. This is a nice optimisation when your tables contain a large volume of data that doesn't need to be carried over the network each time.

My point is that all the advanced features are now developed only for mapping tables (and range tables); this is why it's best to give up translation tables if you can.
Feel free to let me know if you have any additional questions, though.

Best regards.

François
SAP Convergent Charging Support

[francois_thimon]

Hi Doris,

It kind of depends upon what you're willing to achieve but, currently, the closest you can find to translation tables are the "mapping tables". They're very similar but, among other things:
- For mapping tables, you must first define a structure separately, in a "mapping table class" (the class gives the list of input and output columns). Then, all tables you create for a given class will have exactly the columns described by that class (while each translation table has its own individual structure, which cannot be shared).
- Each row of a mapping table has its own unique identifier (which makes it easier to recognize rows when populating and reading a table).
- For translation tables, the start and end dates were required only if you enabled them explicitly; they're now mandatory for each row of a mapping table. Thanks to this, an identical combination of input values may yield a different output, depending on the reference date. In particular, this allows you to override an entry for a given period (for example, you can use that to apply a discount for a limited time).
The detailed explanations are in the documentation of the "Mapping table introducer" logic component:
https://help.sap.com/docs/Convergent_Charging/c7120011d1c244168dc1f945a06f1350/bcfd45adc81944c8a602a...
- Mapping tables can pertain to a subscriber account (we call them "subscriber mapping tables"), instead of being defined globally (at the catalog level).
- Mapping tables can be referenced in parameters (i.e., in charges or contracts). There's a special parameter type for that, which also require you to specify a mapping table class explicitly, therefore guaranteeing that the pricing logic will be getting a table of the right structure (since the table's structure is defined by its class).
- A recent CC feature also offers an hybrid between "subscriber" tables and "catalog" tables: "agreement" tables. Each agreement table is defined at the catalog level, but is still explicitly assigned to a given set of subscriber accounts (using the table's "agreement ID"). The purpose is to let many subscriber accounts share a catalog mapping table, rather than having their own copy of it.
- Translation tables allowed you to use wildcards (represented by the value "Any"). This no longer exists in mapping tables.

Here's the documentation for mapping table classes, since they must be created before the table(s):
https://help.sap.com/docs/Convergent_Charging/c7120011d1c244168dc1f945a06f1350/6aaee2d7899c4a9b84aaf...

We also have "range tables": they're a bit different because they rely upon numeric ranges, such as "[0; 5[", "[5; 15[", [15; +Infinite[, for example.
The input value is therefore numeric, and matched against the available ranges, to pick the output values. For example, a range table can be used to pick the expedition fee, based on the weight of a parcel.
Furthermore, range tables have an recent additional feature, where you can use additional input values (all with the "String" type). They're like options: instead of having one list of numeric ranges, you can have one distinct list for each combination of string input values (for example, this lets you pick a different fee based on the options chosen by the subscriber).
Besides, similarly to mapping tables, range tables can also pertain to a subscriber account (what we call "subscriber range tables"), and be referenced in charges and contracts, through parameters.
Here's the documentation for range table classes:
https://help.sap.com/docs/Convergent_Charging/c7120011d1c244168dc1f945a06f1350/ab47bb8543564d5da095f...

SAP CRM and SAP SOM are both aware of mapping/agreement tables and range tables; they're consequently already able to invoke all the corresponding SOAP API's from CC.
Feel free to ask for any clarifications about these topics.

Best regards.

François
SAP Convergent Charging Support

[former_member815797]

Hello Doris, François,

While both mapping tables and translation tables can be used inside a charge, the significant difference is that the mapping table can be modified in the charge plan and the provider contract. In contrast, the translation table cannot be changed in the charge plan or the provider contract.

The question, in this case, would be: should we use translation tables in our logic or try a different approach, as the BR235 course indicates that the translation tables are technically outdated?

I would have to suggest that even if now the current version of the used SAP CC is 4.0, we are planning to do the upgrades to the latest available working version.

At the same time, we are aware of the SAP recommendation that in case of the charging services are based on provider contracts, mapping tables should be used instead of translation tables.

Taking everything into consideration, should you suggest that from a technical point of view, use translation tables?

[doris_karapici]

Hello Francois,

Thank you for the detailed answer. As Marius explained we have a plan to upgrade CC 4.0 to the latest working version. Maybe being more concrete could help you understand our concern and propose to us the best way to what we can go.

Our scenario is that we have built in a usage charge a logic that checks the records in the translation table X, and if it finds a record there by comparing it with the value received in the mapped field in the rating request then it will continue in the branch to decrement the corresponding counter. If not (so any record entry in the translation table) it will output a value "nofree" and continue in the branch where it finds further the corresponding price and calculated the final amount with the given quantity.

In fact, only for this record ', any' in the translation table was the reason why we decided to use the translation tables instead of mapping tables.

If there is a way to achieve what we want by a mapping table we would gladly and happily go with your suggestion and follow the SAP recommendations for not using the translation tables as they are outdated.

Wishing you a great day ahead,

Doris