2 weeks ago
well i udnerstand the KISS prinzipal, but sadly this wont gonna cut it.
many projects tried it like this, all failed without exception.
forget the worldwide billing issue for a moment.
billing for any type of hosting companys is super tricky, product management even more so. thats an occupational hazzard in that field.
with the very diverse nature of the products and offers in that industry, recurring nature, and different ways to handle customers its just a lot more than just writing a few positions on a piece of epaper based on a product table.
the very core basics must be done by the core team and not 3rd party, and must be rock solid and must consider
as many possibilitys imaginable.
you need to define principals for the main workflows.
order process, refunding processes, credit systems, billing and renew processes, and so on. if you wait for a good high quality 3rd party module all that,.. well good luck with that. 7 other projects are still waiting, never came.
only if you have a good foundation you have a chance on good modules. in ideal cases modules wont have todo much and dont need high quality code to work properly.
modules should extend a crm, not interfiere with its core workflows and prinzipals.
while you have a really reyll good looking interface that feels rock solid,
the logic implementation of current features eally need someone who has some knowlege about it.
i see a ton of things that are the right features in the wrong order or place but i dont wanna go to deep into that here as it would mean another way to long post
i just fear this is gonna be just another good intentions, good start and sudden death project.
its almsot always the same, starting simple, then realize its not so simple, trying to rebuild the core, getting into trouble with updates, hitting a brick wall, requiring a half rewrite, never finish it...
2 weeks ago
country select billing module?
uhm no. that wont work. what could work is carefully select certain features as kind of a mode.
so if you select for example EU mode, a couple of features will work a certain way differently.
you need to be dam careful about that because it all has future major implications
and what you dont want is to reconsider every "mode" with every feature request that even remotly touches billing.
there many aspect in that business that will dictate the workflow anyway.
its mostly not so much the country or law difference, but differrent way companys have to work in their markets.
like upfront vs pay after, order into the past, order into the future, invoice usage based and so on.
also question is often not can you do something (by law) but is it a good thing todo.
theres a reason why majro companys or major software products for such companys work almsot identical for US, europe or any other country. they usually use strict workflows not becuase some country requires them, but because it streamlines its their own logic and workflows for the customer.
also think on future plugins or extended features that even remotly touches ordering or invoicing.
think of all the possible use cases (like upfront payment at order, upfront before renew, and pay later models) and all the different possible users that have different criteria how they have to invoice their customers (its usally not a "want" but "must").
so you need a common ground for all the most basic functions and workflows.or else you open yourself into a future bugworld, where 3 different plugins break 4 different use cases on different settings.
2 weeks ago - last edited 2 weeks ago
> many projects tried it like this, all failed without exception.
Well, that's why we are here But don't get me wrong, our goal is not to be 100% compatible with all countries and their billing requirements. Similarly, we don't want to handle 100% of everyone's workflows. What we want is to support most of the countries and most of the processes, and we believe it is possible. About 3k active UCRM instances from 90 countries could be a good prove.
> the very core basics must be done by the core team and not 3rd party, and must be rock solid and must consider
as many possibilitys imaginable.
Totally agree. The core should be hardcoded by us (invoice issuing, taxes, etc). The core must be robust, still easy to use, and sure, it won't satisfy everyone. However, some extensions can be done. For example, just now, a plugin pushing AFIP codes to invoices is being developed to enable Argentinian WISPs to be compatible with their requirements. Another example is the existing "FIO bank payments import" which gets payments from WISP's bank, push them to UCRM and links them to proper client/invoice based on specific rules. Such extensions are totally ok, don't interfere with the core and can be created by anyone to handle their needs.
To sum it up, I believe we are heading the right direction. The UCRM core is/would be suitable for 80% users, the plugins could improve this number to let's say 90%, and the rest 10% will never be probably able to use it which might sound rude but it enables us to keep this product robust, viable and still easy to use at the same time. That's roughly our strategy.