Hi Raj On Mon, May 5, 2014 at 1:35 AM, Rajbir Saini <[email protected]> wrote: > Ted, > > I am sorry for the confusion and half information. May be I was too quick in > replying. Regarding example in OFBiz, there are an example but it is more > about the subscription of newsletters. That could be a good starting point > and that is the place I have started. > Ah, OK. So the material I saw isn't so out of date after all.
> I think key to the implementation is putting together your data properly. > SubscriptionResource is the most important entity and it has most of what > you need. Your product type should be digital goods to make the subscription > work. OK. That is straight forward. > > You may need to write a fulfillment service to fulfill the orders depending > upon your fulfillment process. For recurring billing, there are two ways to > handle it. Auto and manual. For auto billing, your payment processor must > support it and if this flat in your subscription entity is set to true and > auto renewal service is schedule, it will create an order which will be auto > approve the order and charge the credit card etc. For manual, you will need > to write your own code and action is user initiated (e.g. a renew > subscription link on profile page). > OK. I would have thought that this would have been developed and included, for it to be said that subscriptions and recurrent billing are available out of the box. So, If it is the case that I develop and deploy a subscription based service using Wordpress (not a simple newsletter) and Perl (say, something that allows users to prepare meal plans and evaluate whether or not the meal plans so created meet the nutritional requirements of each member of the household without breaching their nutritional constraints imposed by various chronic diseases), I would have to develop a service within OFBiz to connect the two (and manage access to the service according to what has or has not been paid). For autobilling, it can be said it is only partly developed. I work mostly in developing transaction processing services for ecommerce merchants, and the vast majority of processors I deal with do not support it. Yet, the president of the company I work with wants to offer it since most of the merchants he deals with need it. That is why I will have to design and develop a vault at some point this year. If a merchant's business model requires rebilling (as do subscription based businesses), use of either a processor that supports it, or a vault, is essential. This is about PCI compliance. For, say, book sellers, PCI compliance is easy, since there is no need to store a customer's payment information. But, with rebilling, the customer's payment information must be stored somewhere, and that means a vault maintained either by the merchant, a third party vault service (and this is feasible ONLY if that service has integrated into the processor you're using), or the processor. There is, thus, a way to go before rebilling can be said to be fully supported out of the box. And, I half suspect that creation and deployment of a vault may almost be a separate project as a properly constructed vault shouldn't even be on the same local subnet as the server running OFBiz (it requires a segmented LAN, and a machine that provides an API to which OFBiz can submit customer payment information for subsequent use in processing rebills). Cheers Ted > Thanks, > > Raj > > > On Monday 05 May 2014 07:53 AM, Ted Byers wrote: >> >> On Sun, May 4, 2014 at 10:11 PM, Rajbir Saini <[email protected]> >> wrote: >>> >>> Ted, >>> >>> By the way why should contens of a web site has to be related to Ofbiz? >>> Contents of a web site are to be related to a business and not the OFBiz. >>> >> No, of course not. But just showing the url for a businesses website, >> with out some explanation, leaves open the question as to the purpose. >> >> I would have expected either a statement that the site is deployed >> using OFBiz, and a pointer to those parts that deal with the original >> request about support for recurrent billing and subscriptions, or >> information on it about OFBiz related to the original question. >> >>> The site in question is 100% OFBiz. Only addition is URL rewriting and we >>> use Apache HTTPd and mod rewrite to do that. >>> >> OK. But you should have said so. If you had, I would have said >> nothing. Or rather, I probably would have just asked you what you did >> to support the subscription business model and the matter of rebilling >> customers. >> >> There is no real conflict here. But now that matter has been >> clarified, can you tell us what you did specifically to support >> subscriptions and rebilling? Everything I have found to date is >> dated, and seems to be from before support for commercial >> subscriptions was added to OFBiz. >> >> Cheers >> >> Ted >> >>> On May 5, 2014 7:24 AM, "Ted Byers" <[email protected]> wrote: >>>> >>>> On Sun, May 4, 2014 at 9:36 PM, Rajbir Saini <[email protected]> >>>> wrote: >>>>> >>>>> You can have a look at http://www.webovs.com/ >>>>> >>>>> >>>> What does this site have to do with the question of subscriptions and >>>> recurring billing? >>>> >>>> If you're claiming that site uses OFBiz and has deployed code that >>>> supports subscription and rebilling, then it would be useful to >>>> provide an URL that lets us examine the code. >>>> >>>> The content of that site does not appear even to be related to OFBiz, >>>> let alone support subscription and rebills. >>>> >>>> Cheers >>>> >>>> Ted >>>> >>>>> On Monday 05 May 2014 03:33 AM, anon wrote: >>>>>> >>>>>> Hello everyone, >>>>>> I have a small application in grails that I would like to port to >>>>>> ofbiz >>>>>> to >>>>>> take advantages of things like billing, payment and other things. But >>>>>> before >>>>>> I set out to do it, I was wondering if there was an example in ofbiz >>>>>> of >>>>>> an >>>>>> application where users can subscribe to different plans like "basic", >>>>>> "professional", "enterprise" with recurring billing, so I can see >>>>>> whether >>>>>> the switch is worth it. >>>>>> Thanks for your help. >>>>>> >>>> >>>> >>>> -- >>>> R.E.(Ted) Byers, Ph.D.,Ed.D. >>>> [email protected] >> >> >> > -- R.E.(Ted) Byers, Ph.D.,Ed.D. [email protected]
