Showing results for 
Search instead for 
Did you mean: 

CC establish Mapping Table name dynamically in pricing logic

0 Kudos


I am looking for solution how to look for prices in several mapping table which have the same mapping table class.

Based on some configuration parameters the logic should look into one particular mapping table. So it's name can be determined only during rating.

I tried to use input property to pricing macro. It can have type "Mapping table ID". But I cannot find how to set this parameter when we call pricing macro. There is only one option to choose property... but I cannot use "string" property or any other type...only "input parameter/property" which is input to charge or pricing macro. So it is only possible to forward the table name. I cannot change it.

Is there a possibility to change a mapping table name in the pricing logic at all?

best regards


Accepted Solutions (0)

Answers (2)

Answers (2)

0 Kudos


thanks a lot. You have just confirmed my assumptions.

Sending a new identifier in a new parameter might be an option. It will require additional CCM update for all contracts in the system. I will think about it.

Using "one big table" would be the best solution, but is not an option in my case. The snapshot size for mapping tables is limited to 1MB (default BLOB field size in DB). So "big table" cannot be "big" enough. And disabling snapshot for all mapping tables in CC server configuration is also not an option.

There are also another solutions which can be implemented.

best regards


Active Participant
0 Kudos

Hi Rafal,

It's indeed not possible to compute mapping table identifiers from within your pricing logic. Most use cases can be satisfied using a different approach, though.
It's still possible to send the targeted identifier in a parameter (defined in the contract, in the charge plan, in the charge or in the macro itself), but this is feasible only if you know this identifier early enough in the process.
Otherwise, you might for example consider using only one big table, and creating an additional column that filters the rows. So, instead of computing a full table ID, you would just have to compute the key that designates a range of rows in your unique table (the keys are allowed to be plain strings, so you can compute them anywhere in your pricing logic).

Feel free to ask for more advice if needed.

Best regards.