[SOLVED] [#9091] Programmatically invoice a subscriber

The cb_ecms_fee_pmva field type is Decimal Number and in my test of the "a fixed amount A from a CB field" promotion the user had a field value of 100. I also tried a field value of 100.00, since the promotion amount field tool-tip says the amount must be in the currency.

Although, since then, I've also tried other promotion types such as a percentage off or a flat amount defined in the promotion config. I've tried applying the promotion on different plans. So far, no promotion has successfully applied to the basket.

Very strange. No promotions at all work on your site? Ensure CBSubs Promotions is public access permission and published in CB > Plugin Management. Next within CBSubs > Settings > Promotions ensure "Promotions enabled" is set to "Yes". Your issue suggestions promotions are globally turned off.

That seems to be the case. I've verified that the CB Promotions plugin is enabled and Public. I've also just now tried to change it's order to last to see if that made a difference - no difference.

Promotions are also enabled in the CB Subs config.

Please PM backend super users login credentials and will take a look.

Have reviewed your install and appears your promotion applies to the plan id 27 as per your configuration under the Basic tab. It then also requires the purchasing user to have a specific usergroup as per configuration under the Group tab. If the user doesn't meet these requirements the promotion won't apply.

The problem I'm seeing is plan id 27 is a child plan of plan id 23, which has "Allow access from site frontend" set to "No: this plan is not visible in site, only in admin backend" under Access. Plan id 27 is also set to the same. This means these plans are not visible on frontend. You can't buy them on frontend. Is this intended? That setting is meant to be used to have backend based plans which don't have payment processing and are just programmatically assigned to users.

The plan access is likely the cause, but could also be due to the access check on the promotion. Does your test user have the required usergroup?

The test user I was using did have the correct group assignment and plan added to the basket. I also tried removing the group assignment condition from the promotion, but that didn't resolve it.

Regarding that particular case, our goal was to limit the ability for a user to subscribe to plan 27 until we supplied the link for them to add it to their basket. We don't want them to be able to choose to subscribe to the plan on-demand because it represents a certification they must meet requirements to achieve. Is there a better way to control the exact moment a user is offered plan 27 for subscription and still be able to apply the promotion to adjust their fee for GDP?

Concerning promotions in general, I've also tested with the promotion named "Test ECMS Fee" and tried various settings from different promotion types to different plans, plans that are available on the frontend, to just a blanket percent promotion on any plan. The promotion was never applied in the basket. The only condition on that promotion is a specific user ID of a test user I was testing with.