I think that every Plan, Feature or Ticket should have a price
centrust opened this issue · 21 comments
Thanks I did not see that the charges are set in a different table
although needs a currency to the charges
Hey! Thanks for opening an issue! Could you provide more details about your question? 😅
Hi Thanks
In My case and maybe many other cases, the Plan Features should have currency attribute, so that I can have the same plan with different currencies, with their respective charges in the Feature Plan table .
Oh, I see: so a feature would have a column with USD, and their relationship with a plan would have something like 12, making this feature cost U$ 12 for that specific plan?
i'm using this package is so nice but i dont see how to add price to plan
Hi The package somehow has the table feature_plan, which is a pivot table that holds the charges to the Plan and the features.
I still have not seen the reason behind this pivot table, I did change it to add the price to the Features and the currency. this way I do not need to have an extra pivot with only charges. since all features must be priced. it is easier if the field charges is added to the features.
Hi The package somehow has the table feature_plan, which is a pivot table that holds the charges to the Plan and the features. I still have not seen the reason behind this pivot table, I did change it to add the price to the Features and the currency. this way I do not need to have an extra pivot with only charges. since all features must be priced. it is easier if the field charges is added to the features.
me to i dont know how to get a price fro the plan or for the feature
@lucasdotvin can explain why the prices, or charges are in a separate pivot table.
and how to get the price for a subscription to a named feature of a related Plan. this has to be through a deeply nested relation.
@Elshaden @hugo-abdou
I had the same problems, I dropped using the package, too complex for a simple task.
Hello! The feature_plan table associates the features to the plans, so the same feature can be present in multiple plans and the plans can have numerous features. If you need to add a price to each feature (so you can sell feature tickets, for instance), I would add a column named price to the features table.
The package currently does not intend to force any payment structure, so everybody is free to decide how to handle it. 😅
Could you provide some details about the application you're building? This way, I can help you to customize the database structure to fit your needs. 🤘
@lucasdotvin thank you for your time im just building a saas project and i nead to display a price on evry plan in the prising page but i dont know how to get the price
Oh, I got it! You could do this: publish the package migrations, add price and currency columns to the plans table and use it to show the values:
Then, when seeding the plans, you can set their price:
This way, you'll be able to get their price using the regular Plan model:
thank you so mush @lucasdotvin i Hope you are planning to add This to the package in the future
@lucasdotvin
Hi
I would not do that,
I would keep the Plan as it is now. and add the price in the features.
so that you can display different packages. example
would be Pro Plan
1 month feature, 3 Months feature and forever Feature
Each will have different price tag.
the same can be done for Basic Plan, with different pricing for each feature.
I hope this clears it
So to get the user can choose which Plan and which feature he wants.
in fact the user will be selecting a feature not a Plan.
to get the price you would do $plan->feature->price. or user->subscription->plan->feature->first() , as Plan HasMany Features, and feature BelongsToPlan
when creating a subscription, the user will be subscribed to a Plan with attached feature > he may at later date upgrade to another feature or downgrade. The plan will always be the same.
To add, You can also create different features with different currencies. for the same plan
Oh, I got it: you want to let your users choose which features they will get, right?
@lucasdotvin he whant to charge the users by the features not by the plan so if the plan has 3 features and evry feature is for 10$ so the plan it will cost 30$
@hugo-abdou @lucasdotvin
No Not Exactly @hugo-abdou ,
each feature has different price.
Example you have three Plans Plan A which has access to 10 users, Plan B which has access to 50 users and prime support, and Plan C which is Professional Plan with unlimited users and special support.
Now each of these Plans can be bought for one month , three months or yearly.
the Feature here is the period. so I want to buy Plan B for three months. means Plan b with feature 3 Months and pay the feature price .
and so on.
The Plan Model is only for naming and show different benefits Like support and Logo, Nice description. but all the rest should be in Features. Like subscription duration , and cost, and how many access to users using consumable trait. and what makes this feature different from the others. and Of course the Price, for each currency.
@lucasdotvin I think you can add a JSON column to save metadata that belongs to plans, features, and subscriptions. That should be good not just for the price, we can add any other metadata-related values like prices, free, credit, and others, and avoid creating pivot tables. In this way, you left on the developer side all things related to pricing, payments cause the package can't aboard all the use cases for subscription in any project.