I''m just about finished with my business natural language system for defining recurring billing periods, but have one major question that I haven''t decided on. Since I''ll be releasing this as open source very soon, I''d like to get some feedback. Right now the language is very open ended. To the point where you can define billing periods that wouldn''t ever get used in real life. However since I can''t predict what people might end up actually using I''m hesitant to limit it. The basic concept is you can define multiple stages in a complete recurring billing definition, with each stage being a billing cycle. The first stage has it''s own unique syntax as it also defines what and when the first charge is. In this example we have a biling cycle that is fairly common: - charge $10 now then charge $10 every month until cancelled. Another variation on the same theme: - charge $10 now then charge $5 every 2 weeks until cancelled But there is also the ability to bill on a set day of the month, which often involves prorating the first charge: - charge $10 now prorated then charge $10 every month on the 1st until cancelled Now here comes the part that can get a bit complicated and where certain assumptions have to be made. - charge $10 now then charge $5 every 2 weeks for 3 times then charge $10 every month on the 15th until cancelled. The ''then'' keyword separates stages. The potentially confusing part comes when we transition from one stage to another. It''s not difficult to do the calculations or build in some assumptions about whether to prorate or not when moving from stage to stage, but there is probably a high potential for users to get confused. Right now the only time proration is done is on the first stage/charge. I also built in the next two types of billing cycles which could also be confusing for people if they have multiple stages and transition to/from them: - charge bimonthly on the num_suff and num_suff - charge every week on day_of_week (sunday, monday, etc..) In any case, my opinion right now is to expose common stage combinations via a web interface, and let advanced users define whatever they want using the bnl directly. Chris --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---