The currency symbol is printed almost nowhere, maybe it should just be
removed.  For multiple currencies would one need multiple prices for
everything?  That sounds like a total mess.  Why would you want to do
that to yourself?

A volume discount could be done during your import script by assigning
it to different services depending on what the amount was, say under
100 gets one service id and over 100 gets a different service id.

Each rate you offer would usually be a different service at a
different price.  You do end up with a huge number of services.  At
least that's how it's meant to be.

Paul

On Wed, May 23, 2012 at 6:40 AM,  <n...@hush.com> wrote:
> I'm evaluating CitrusDB for a telecoms-like application, having
> abandoned an evaluation of jBilling.
>
> CitrusDB seems more limited, but at least I got it working quickly
> with a simple initial demo setup of my own - which is more than I
> can
> say for jBilling, after spending around a week on it.
>
> These are the points I'd like to share. Thanks to anyone who can
> confirm or correct or make suggestions.
>
> Limitation to a single currency: as I'm not evaluating on my own
> behalf, I'm not sure yet if this is a showstopper. There doesn't
> seem
> to be an obvious workaround, though I noticed that no currency unit
> appeared on the sample invoice I generated. Perhaps the simplest
> way
> would be to run a separate installation of CitrusDB for each
> currency (which might be acceptable if they could be limited to,
> say,
> three, but which is obviously not an appealing solution)?
>
> Volume discounts, discount for advance payment, etc. I didn't see a
> section dealing with this subject in the manual. My understanding
> is
> that this would have to be implemented by whatever code is
> importing
> the usage data into the Citrus database. So if the user has paid
> for
> 100 units in advance for the month, getting a fixed discounted
> price,
> then a separate PHP script that finds the usage is 90 does nothing,
> but if it finds the usage is 110 then it adds another service with
> a quantity of 10 to be billed at the usual rate. Correct?
> (The equivalent logic in jBilling would be in Drools rules.)
>
> Only one piece of ancillary data in the invoice: if an options
> table
> is defined to store extra information associated with a service
> then
> only the first column from this appears in the invoice.
> Workaround: store all the data that should be printed in the first
> column, duplicating parts of it in other columns if it is necessary
> or convenient to access them as separate numbers or codes, etc.
>
> (Ideally, I think one of those numbers might be a rate so that the
> same service could be billed at different rates, rather than
> creating a different service for each rate. The rate might be the
> outcome of some complex function of durations, ratios or the like,
> so that the number of services needed could otherwise be large
> due to the many different possible outcomes of the rate
> calculation.
> However, that's probably expecting too much.)
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Citrusdb-users mailing list
> Citrusdb-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/citrusdb-users



-- 
The CitrusDB Project | http://www.citrusdb.org
Open Source Customer Care & Billing System

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Citrusdb-users mailing list
Citrusdb-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/citrusdb-users

Reply via email to