Shared contract

[eduardo_barbeta]

Hi experts!

On a scenario with multiple Provider Contracts sharing an Allowance, trying to run the Recurrence for a Provider Contract "member" we are facing following behaviors:

Running the Activation for the Provider Contract 30, CC is catching data of another "member" (26) linked to the same owner.

This provider contracts have different Subscriber Accounts.

how to solve this situation?

[Eric_F · Accepted solution]

Hello,

Using  root/linked contracts and share allowance is unusual business case. It seems normal to activate the subscriber account of the shared allowance as soon as you are sending an allowance event to this shared allowance. 

If you still thinking that there is an issue, please open a case on SAP Support portal. 

Best regards,

Eric F.

[eduardo_barbeta · Accepted solution]

Hi Eric.

[eduardo_barbeta · Accepted solution]

Hi Eric. I see it now. I got how it works. Thanks for your attention

[eduardo_barbeta · Accepted solution]

Eric... one more doubt... is there a way to work with shared allowance without linked contract?

[Eric_F]

Hello,

According to your description, the activation of the provider contract is sending allowance event to a shared allowance which has been created by the provider contract  26. 

Due to a No Access Function that you have set in the rating logic of the shared allowance, the activation is failed. This is expected as soon as the rating on the shared allowance is reaching a "noAccess" component. 

The main advice is to not use "noAccess" component in your allowance logic.  Consider this specific component as an technical error component which has to be used only to highlight provisioning issue (missing subscriber table, ...) . It should not be used in a business logic.  

Best regards,

Eric F.

[eduardo_barbeta]

Hi Eric! contract 27 and 26 linked to the contract 20 (where the shared allowance was created) Activating the contract 27 the logic is running with data belonged to the contract 26. I used the No Access component to "debug" the recurring rate execution to understand what was doing wrong...