Subscription functionality redesign

[PawanMeh]

• [ ] Create new "Subscription" doc type as below

• [ ] Remove the current fields of the "recurring" section from the doc types: Sales Order, Sales Invoice,Purchase Order, Purchase Invoice
• [ ] Refactor code that uses current fields to use the new "Subscription" doc type fields to create recurring documents and update the "Subscription ID" back to the base document(eg:Sales Order, Sales Invoice,Purchase Order,Purchase Invoice)

This new design will reduce redundant data which gets copied over to multiple invoices and also give a single page from where the user can set "Subscription IDs" for various doc types.

[kworm83]

I would have the following suggestions as well for now:

add an action to occur at the end date such as: expire, renew for x months, etc add an action to notify via email x days before end of recurrence term add a display field for the last time a recurrence was generated

[rmehta]

Why not "Subscription"? Recurrance seems like a non standard term

[kworm83]

Yes, I agree "Subscription" would be better especially for those who would be using it to bill subscribers like us. Do you feel this should be implemented as a new module or use one of the existing ones...I suppose Account would be the only existing one to fit since this would create documents from both Selling and Purchasing.

[PawanMeh]

The reason I used recurrence is because the functionality today exists in purchase order and purchase invoice as well, the base doc type would dictate which document recurs.

We can use subscription if that's what the majority thinks but I think it is not generic enough as a subscription generally means the amount you pay to receive a service.

On 7 Sep 2016 23:59, "Kevin W" notifications@github.com wrote:

Yes, I agree "Subscription" would be better especially for those who would be using it to bill subscribers like us. Do you feel this should be implemented as a new module or use one of the existing ones...I suppose Account would be the only existing one to fit since this would create documents from both Selling and Purchasing.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/frappe/erpnext/issues/6313#issuecomment-245329191, or mute the thread https://github.com/notifications/unsubscribe-auth/ATgz0ra6jabDtkLGlrDbHgQD9wqYHMZyks5qnt9sgaJpZM4J3DN3 .

[kworm83]

I think recurrence is a little confusing. For users like us we would be using this to represent subscriptions for services that we have sold to a customer on a contract…I suppose for purchasing it would be the same concept of buying under contract or having a standing order.

On Sep 7, 2016, at 11:56 AM, Pawan Mehta notifications@github.com wrote:

The reason I used recurrence is because the functionality today exists in purchase order and purchase invoice as well, the base doc type would dictate which recurrence to use.

We can use subscription if that's what the majority thinks but I think it is not generic enough.

On 7 Sep 2016 23:59, "Kevin W" notifications@github.com wrote:

Yes, I agree "Subscription" would be better especially for those who would be using it to bill subscribers like us. Do you feel this should be implemented as a new module or use one of the existing ones...I suppose Account would be the only existing one to fit since this would create documents from both Selling and Purchasing.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/frappe/erpnext/issues/6313#issuecomment-245329191, or mute the thread https://github.com/notifications/unsubscribe-auth/ATgz0ra6jabDtkLGlrDbHgQD9wqYHMZyks5qnt9sgaJpZM4J3DN3 .

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[PawanMeh]

Changed references to use "Subscription" and updated the screen shot.

In case anyone is taking this up for development,please do reference the issue number(6313) in your Git Branch.

[kworm83]

I have started working on this. What is the thought on using a series vs just a prefix for the subscription id naming? I have it using a prefix of SUBS-.###### for now but it could be a series.

[kworm83]

[kworm83]

In validation I'm going to require the base document be in the "draft" status so that the subscription will process all the occurrences. I will start on the backend work next...

[kworm83]

Revised to remove 2nd notify email textbox...probably no need for the redundant info.

[PawanMeh]

I would vote for naming series as different recurring base doc types could have different series. Maybe we can create one default naming series with the prefix of SUBS and leave it to the user in case they want to add different naming series they can.

[kworm83]

Ok, I have modified it to use a naming series with just SUBS- by default.

On Sep 8, 2016, at 12:55 PM, Pawan Mehta notifications@github.com wrote:

I would vote for naming series as different recurring base doc types could have different series. Maybe we can create one default naming series with the prefix of SUBS and leave it to the user in case they want to add different naming series they can.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[PawanMeh]

@kworm83 Any updates on further progress on the development of this feature?

[Etine]

My use case is that of a reseller of monthly use licenses for online services. Customers can add or drop licenses. They only pay for the days that a license is used. So I need a way to prorate the customer for their use of their current subscription plan. The difference in days has to be calculated and discounted from the full subscription price. So it would be nice if there was a box that you can tick to mark that the subscription has to be prorated.

I would also be nice if there also is a way to manage subscription plans.

[GSLabIt]

@PawanMeh @kworm83 any news on this?

[kworm83]

I’m still working on the functionality…it’s maybe 50% complete at this point.

On Oct 7, 2016, at 11:45 AM, joezsweet notifications@github.com wrote:

@PawanMeh @kworm83 any news on this?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[rmehta]

@kworm83 hey let us know if you need any help. Even if its partially done, we can review it

[GSLabIt]

@kworm83 would be possible to enable/disable pro-rata invoice for subscription?

[hwinkel]

Seems great progress after all. @Etine especially your use case is intended here as well. I could offer to test the functionality with our use cases. @kworm83 is there anything in PRs.

[hwinkel]

@kworm83 regarding your suggestions of monthly extension, I would prefer to not only do that on month might also be in years, weeks or even days?

[hwinkel]

@Etine and all, seems we have a similar use case for online services. From a perspective of the subscription contracts developed here I would suggest another feature which should appear as part of this functionality. Usually such kind of subscription contracts have the following pricing structure which I think could internally modelled with a BOM:

• a price for non recurring costs (NRC)
• a price for monthly (or any other schedule) recurring costs (MRC)
• a price for (additional) usage based costs items (SMS, Gigabytes, Time, etc...)

Especially the latter must be imported or edited with every recurrence cycle.

[hwinkel]

We also can imagine that subscription contract might change over time, i.e. mid month. Do you have any envisioned ideas how to deal with that? It seems a bit like the use case @Etine has described where items getting in and out the contract framework. Or you terminate the current subscription contract and start a new one. Both might be partly charged.

I know this could become complex, but at least I would drop the comments and ideas here.

[mhbu50]

+1

[GSLabIt]

hi there, any news on this?

[hwinkel]

Would be interested as well about the status

[GSLabIt]

@manassolanki @nabinhait Any news on this?

[hwinkel]

Is there any plan to go forward with this? for us service management based on booked subscriptions is a crucial point to get running with ERPnext. As ERPnext self is a subscription based service I'm wondering why its not in the software self.

[Etine]

@hwinkel Perhaps we can pool some resources to develop this feature. For some reason this project has halted. I also think it's a useful addition to Erpnext.

[ronniegarcia]

I would love to switch to ERPNext, and we also require a subscription mechanism as we sell Cloud Computing hosting services. We sell "one shot" services like setup fees, also known as NRC (Non Recurring Charge), and MRC or YRC like hosting services or internet domain names or SSL certificates (Monthly/Yearly Recurring Charge). Both of this service may appear in the same Sale Order. And like many of you, services may vary during time for a same customer. We would love to participate to this development : developer resource or money

[rmehta]

@hwinkel @Etine yeah we have this on our list too, just that there are so many competing things for priority. Maybe starting a bounty will help move things faster!

Just added $100 for this https://www.bountysource.com/issues/37656603-subscription-functionality-redesign

[hwinkel]

@rmehta Thanks for the feedback, I can imagine. However if we put the money on the table, is there a estimate whats happens then an when? ;-)

[hwinkel]

@Etine Yes, I would like to avoid to look for another tool or external service like www.freshservice.com and missuse the ITSM for ordering things like Cloud Subscriptions etc... I think its a natural fit for ERPnext. Like automatic workflows as well: https://discuss.erpnext.com/t/automated-workflow-execution/17527

[rmehta]

@hwinkel @Etine hope you guys add to the bounty too. Please show some "skin in the game" that you really need this feature!

[hwinkel]

@rmehta I have no problem adding to the bounty, but I'm not used to the bounty process. What happens after adding funds? Is there a minimum limit? is there any rough timeframe? Many thanks for advise.

[Etine]

@rmehta Same here. I would like to define the requirements more precisely and have some kind commitment over the lead time. Thanks.

[rmehta]

@hwinkel You add your commitment and hope someone picks it up, I think at $500 you might find some developers willing to go for tit

@Etine feel free to share the requirements more clearly.

Edit: If you want something more specific, feel free to hire a developer and get it contributed.

[hwinkel]

I have already contacted somebody who will come along with suggestions. @rmehta how ever it goes, the result will be contributed. @Etine shall we have a session at gitter to discuss the requirements?

[hwinkel]

@ronniegarcia You are also interested in joining efforts?

[ronniegarcia]

@hwinkel sure i will, but i will first write some bits about my specs/requirements. I will do this within the next 5-6 days.

[Etine]

I am, need some time to think out / write up the requirements. But I am certainly interested. It makes more sense to commit to bountysource when there is a clear vision a what is going to be build.

[hwinkel]

Sure, but let the ball rolling. I have pointed another developer team too to the bounty. Let's see how they respond. I was thinking the upstream team would participate on developing the stuff even with bounty. I'm fine with sponsorship for the feature.

[ronniegarcia]

My thoughts :

Add a property to the Services Items, which allows them to be "one time only" (as for commissioning fees, Non Recurring Charges), or "subscription" (Monthly/Yearly Recurring Charges). For "subscriptions", it would be necessary to be able to specify their frequency of recurrence (per month, per year, etc)

Add a property to Customers, to specify if they want to be charged:

• "by Customer's Purchase Order reference", in which case the system will generate periodically as many Invoices as Sales Order
• "Globally", in which case the system will generate periodically a single Invoice with all active subscriptions

In my opinion, the normal workflow is: Quotation → Sales order → Contract (or "Subscription") → Invoices periodically generated                                           → Invoice for initial charges

The Contract (or "Subscription") is created from the contents of the Sales Order.

The same Sales Order can contain both "one time" and "subscription" services. "One-time" items only need to be charged once. "Subscription" items need to be charged periodically

Each line of a Contract (or "Subscription") should be independent of the others. That is, each line may have a different start date, a different end date, and a different commitment time. Each line can be terminated while the others continue to be active and therefore charged.

The status of a line of a Contract (or "Subscription") can be for example: active, expired, terminated. We would need a list view to get an overview of all the items that are active or not.

When the start or end dates do not coincide with the first day of the month, invoicing must be prorated.

Each line of a Contract (or "Subscription") should have a readable reference, enabling it to be identified quickly. For example, the reference for subscribing to an e-mail account might be "a.smith@example.com". The one for renting a vehicle could be the license plate. The reference would be entered manually when the services were delivered.

Ideally, elements such as the quantity or price of a subscription can change over time. For example, a customer may consume more or less of a service from one month to the next. Changes in quantity or price can be made manually or by scripts.

What do you think ?

(If this can help understand my comment, we sell IT infrastructure hosting services (IaaS, PaaS, SaaS) on a subscription basis)

[hwinkel]

I think a subscription or contract is just the commercial agreement between the parties allows the supplier to charge regularly the items consumed by the customer based on a contracted price basis I.e. Price list. Therefore I would like to see a deliver note or similar doctype which collects the items consumed. A regular invoice will bundle all the items on a regular schedule to charge for everything consumed. This way you have the flexibility what to add when to a invoice rather then just make a copy if existing invoice items. If you ever have received a amazon or gce invoice you know what I mean. Further based on the delivery slip infos you might have the option to show a estimate of the monthly cost to the customer in a Portal.

[hwinkel]

@ronniegarcia I'm just reread your specs. As a user of a couple of Cloud, IaaS and SaaS Services I would like propose to decouple the Items booked either Non Recouring or Reccouring totally from the Contract. In Example, theses days you signup for IaaS Provider i.e. AWS, Azure etc. The Items of these Providers changing regulary and may even change prices. USer start to book and terminate service more or less on demand. With the design of the intendted Functionality we should be prepared for such functionality. I Envision rougly the follwing concept:

A user signs up to a given service and starts therefore a contract. This Contract holds a ID and the Charging relationship, duration etc. with the customer. Once the customers starts to book items theses are selected from the Items (may organised in Groups, Categories, BOM etc). As the price for a Item might not allowed to change while contracted via a contract the item price would need to be part of a Customer/Contract based PriceList. Another option would be to use versioned item objects. A booking transaction will then create a given Sales Order or similar confirmation transaction which get mailed to the Customer as booking confirmation. If it required to charge immediately or either up Front BTO style Items could be used to trigger a immediate payment cycle.

Thats all for now. Contract and eventually NRC Items are charge and the contract is in place.

Next two things going to happen:

The User starts to book or consumes further items which receive order confirmations, delivery notes etc. All of them are collected in a standing order and available as "usage" in the system.

A periodic, regular Job (workflow, automatic workflow) will iterate over the contract status and collected Items. The Parameter for cron must me smaller as the smallest billing period which is stored in the contract. The Contract also holds the regular Items always used per billing cycle. I.e. MRC.

The Billing Cycle Job will collect all Open Items (NRC, MRC, Recurring Usage, etc) and Creates a automatic Invoice and the payment process.

Hope the proposal makes some sense for this intended functionality. The good thing is that also other use cases like monthly billing for time consumed against a collected timesheet can be modeled. In reality its just the automation of given, may already existing Workflows, where the Automatic Workflow receives some Parameters how and when to execute rather pressing the "NEXT" buttton.

Some Background about such automatic execution ist mentioned in the forum.

https://discuss.erpnext.com/t/automated-workflow-execution/

[hwinkel]

Coming back to this issue. has anybody thought how to quote for such recurring items. The recurrence should be seen somewhere in the quotes. further sums about the maybe different recurring items may be shown i.e. 12 months = Costs * 12? At least a button line should be able to say: Non Recurring Costs sum = ####.## Monthly Recurring Costs Sum = ###.##

What you think? may we have sections in the Item Tables summarise the items?

[federicocalvo]

+1 for the bountysource mont!

This topic was somewhat deserted, perhaps if we revive it in discuss more they join either for the economic or functional contribution.

[federicocalvo]

Hi @rmehta , The link to bountysource that is still to make contributions is still valid for this functionality?. So we collaborate and spread this a little.

[fproldan]

Hi, any idea to continue with this? I can contribute with a bounty.

[Etine]

Perhaps it's useful to put our heads together to define a set of requirements / backlog of stories. I really would like to see this feature sooner than later..

[hwinkel]

as mentioned, we are still happy to add to the bounty, once we can see an estimated release date on the horizon. I'm still happy to add Ideas how to model the functionality.