Billing system best practices - php

I'm currently developing a web application for one of my clients. This client requested a small billing module. The client istelf is small SIP provider. There are several pricing items, plans, etc. All they different types of payment like onetime, monthly, annual. Are there any best practices, good books, articles on blling systems architecure?
Btw the web app based on symfony framework.
Any help is appreciated!

There is usually nothing "small" about a billing system.
I just ran across something called citrusdb. You might want to go through it to decide if you want to build something or just integrate theirs.
Barring that, depending on their business they might be better served just using QuickBooks in combination with an online ordering / payment system.

Some Google Books? Some are available with extended previews, that can be helpful.
http://books.google.com/books?id=lOImNtO96L0C
Flow Charts?
http://www.google.com/images?q=billing+process+flow+chart
You can also get some useful info from audit programs, that describe the kind of things you (or your system, probably) will be asked to produce. Ctrl-F Billing:
http://www.dcaa.mil/standardguidance.htm
These are very general, and not very specific to any programming language. Hope it helps :)

Related

Can reputation scoring system be implemented using business rule management system (BRMS), such as OpenL Tablets, in PHP?

Can reputation scoring system be implemented using business rule management system (BRMS), such as OpenL Tablets, in PHP? From reputation scoring system I mean the reputation systems as in StackOverflow.
I recently come across Business Rules Management Systems (BRMS). OpenL Tablets looks promising, though at the onset it seems to be created with the use in insurance sector in mind.
I looked at SO and found this Best Open Source Business Rule Management System but it does not answer the question.
Another post Is using Rule Engine to implement chain of rules [complex business logic] overkill? but still couldn't figure out.
There are bunch of different product suggestions here but still doesn't answer if it will be worth the effort PHP Business Rule Engine
I will highly appreciate your answer.
Note: This is a yes/no question, and not an open ended question. Please give it a chance.
Regarding OpenL Tablets
1) It is a general-purpose business rules management system, though you are right in the sense, that many customers happen to be in the insurance sector :)
2) It is a pure java application, so you will have to call it from your PHP module, there could be a performance overhead because of JVM startup cost. There is an option of deploying OpenL Tablets as a web service and calling the service, this approach will have better performance
3) Yes, you can implement scoring system using OpenL tablets. You can use decision tables, lookup tables and calculation spreadsheets to develop a fast calculation engine, i do recommend to give it a try and post your feedback.
Overflow reputation system looks like a simple table-driven calculation. The algorithm should just run all stored events for a particular user through these tables and accumulate the score.

An existing eCommerce solution VS Custom built

I'm about to launch a few online stores and I would like to share my thoughts so everyone can benefit and also was wondering about your opinion related to the question: open-source eCommerce vs custom built.
I've been exploring some the existing solutions (Magento, OpenCart, OSCommerce, Xcart).
Advantages and cons:
Existing solutions:
Advantages:
You don't maintenance the code.
Plug and Play extensions.
Support.
Less code hours (not so sure about that anymore).
Cons:
Hard to custmoize: custom templates, plugins, special needs has to be implented over an heavy code already (not a MVC fan).
Too many features (could reduce performance).
Custom built:
Advantages:
Easy theme customization (no limits).
Lightweight.
More secure (questionable: Minimal is more secure, though existing solutions has more pen-testers == Users/Coders).
Easy work-around.
Cons:
Hours, a lot of them.
Lack of plugins, you need to craft everything yourself.
More things to consider:
If I'm going for the custom built - which PHP framework would help me the must?
Do you know any existing solution which is lightweight, has good plugins database, and is easy to customize?
at the moment I have to 'like' custom built more, since i'm going to built a network of stores and would like to get a customized solution, though wondering if I might be wrong.
Please, share from your experience and your thoughts related,
Thanks in advance, your help is appreciated.
Sagi.
a few things to consider, in addition to what you stated.
Developing a new eCommerce solution requires not only manpower, but also knowledge. Many topics require dedicated knowledge. Some examples:
Integration of payment systems requires knowledge about federal laws, about the regulations for VISA and Mastercard
Integration of customer systems requires knowledge of encryption systems, of federal regulations for personified data, of opt-in and opt-out customer relation systems
Integration of interfaces to other solutions (ERP, CRM) requires knowledge of secure transactions and channels, secure authentication, transport layer security
Many of the solutions available on the market already have most of this down. If not, they usually don't gain a competitive market share. Some swipe these requirements under someone elses carpet, Magento is known for redistributing it to writers of plugins.
If you are confused between open source or Custom eCommerce solution then I would advice you to choose Custom eCommerce solution. The reason behind this is that if you choose Custom eCommerce solution then the end product that you will see is fully according to you that will satisfy your requirements.
Its true that you have to pay a bit more than a normal eCommerce solution but you will get a powerful and engaging Online Store that will also help you to generate good revenues and sales.
If you are looking for a Smart eCommerce Solution but still confused about choosing then Go for a FATshoppe eCommerce System and check the demo website of your Online Store.

Multi-supplier online shopping platform

I have been tasked by a client to rebuild an E-Commerce platform. The goal is an online shop on which vehicles are sold. The specialty is that it's supposed to be multi-supplier capable, i.e. external suppliers will have their own login back-end where they can manage their listings, add new ones, view their sales, etc.
The shop shows all the suppliers' products in one big catalogue that should ideally support some options like sorting and filtering, but they are not a requirement. Orders are transmitted to each relevant supplier, and the administrator, by E-Mail.
The ordering process is very simple - it's essentially just taking the ordered item out of the catalogue, and informing the supplier (and the administrator) that the item has been ordered. No online check-out / payments are required, although they are nice to have as an option.
All the on-line shopping systems I know are targeted at one single administrator.
Are there shop systems out there that can handle what I need?
Requirements:
Top priority: Quality code. Preferably PHP 5 and object oriented. I don't care about the exact feature set of the product as long as the existing code is nice and neat to work with.
Access control: Suppliers can log in and add and manage own products; have no access to the rest of the system. Administrators can manage listings and configure the shop. Administrators create supplier accounts
Must be multi-language or localized to German
The sales process is very simple: An E-Mail to the supplier and to the administrator, containing the buyer's data, is enough.
No need for on-line payment/checkout, although it is a welcome extension
Open Source is preferred, but a commercial solution is not out of the question if the product is really, really good and well documented
As long as the basic product is fine and supports the basic catalogue and user management necessary for this, all further features are negotiable (i.e. I'll add them myself if necessary.)
If no payment methods and checkout is involved, it is surely better to write from scratch. With any of the existing systems, you will just have the overhead of code that is not actually used. Also, not so many systems support searching and filtering by parameters and this seems to be a core feature for such a large project.
Magento ! You have to use it, its the best thing since sliced bread.
I've created a multi agent e-commerce system that had reps login and add sales, credit notes and so on. The system had a standard catalogue setup. It could even be customised so that supplier A could have their own shop, supplier B have their own. They could both skin them and so on.
We have different languages. It has a massive developer community so anything we didn't have I just bought and integrated (My time is expensive, this gave the customers real return). There is an open source version, which is what I used, there is also a pay version. I really cannot recommend it enough.
I'm currently working on a similar project.
I'm trying things out with magento to begin with. There's an add-on module for advanced permissions aitoc_magentomods_advanced_permissions which might help you.
The first problem you're going to have in getting a multi-supplier type system is that it will never meet your needs.
If you really wish to have the right system then you should create your own from a decent framework.
if you still wish to use a pre designed system that meets the needs you specified i would go with Magento
Magento is one of the most advanced E-Commerce system I have ever worked with.
The code itself is not so much easy to work with at the start but you get used to it after a few days/weeks.
In regards to the "Access control", im not 100% weather this is supported but the Magento system is very abstract and im 80% positive that this can be done.
"Must be multi-language or localized to German", Every language you need.
"The sales process is very simple: An E-Mail to the supplier and to the administrator, containing the buyer's data, is enough."
instead of me going on about the features i advise you to check it out.
http://www.magentocommerce.com/
But I still would prefer to develop my own framework and build from that.
Regards.
If you're going to build from scratch, do it in Seaside. You're likely to find available solutions don't meet enough of your needs. The quality of code is going to be much better in Seaside. Real reuse, no templates.
Talk to Norbert Hartl

Steps to setting up my first eCommerce site

I'm about set up my first eCommerce site. I was hoping you could recommend some shopping cart software. What are the perks of using pre-built software rather than developing some simple solution catered to my needs. Also, are there pre-written Terms and conditions for sites? Or templates that outline what aspects need to be addressed? What other things should I look out for when building this website?
Also, I develop in PHP server side, so software in that language would be best.
I use osCommerce a lot, but this software is a bit outdated. Magento is a good alternative for setting up a commerce website.
Google Checkout is probably a good starting point for a clean base to start from: http://checkout.google.com/sell/.
The hands down easiest all in one ecommerce platform IMO is the Yahoo Small Business platform - you have a number of options there, including using hosting and php. It's not free, but you get EVERYTHING you need to run an eCommerce store all in one painless spot - your cart, ssl, content management, integration for merchant gateway, shipping rules, integration with ups realtime rates... Order processing, the whole nine.
There are two ways to develop on this platform - using their proprietary RTML language, or use the hosting that you get with it and access the items in your catalog through what they call store tags.
So I wound up writing my own shopping cart software because the site is not based in the U.S. and services like PayPal and Google Checkout do not cover it. I coupled my cart with an API from a national bank to charge credit cards. This required SSL which was easy enough to set up.
I found a Terms and Conditions generator online and used that to lay out the basics of the document. Then I added site specifics myself and tried to sound as much like a lawyer as possible.
I second Yahoo! Small Business (although I would get a developer, their default template looks horrible). If you are looking for something that looks nice and is out of the box good to go, Bigcommerce would be my second choice. After that, I would go with 3dcart (it's a little more flexible, but the default themes are not as good as what Bigcommerce offers). Although, if you are a hardcore programmer, going with Drupal Commerce would probably be your best bet, but you will really need to know some programming to customize it. On the plus side, it is the only cart that I have mentioned that is free (minus hosting costs of course).

Providing customizable forms to non-technical users [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I'm curious how others have offered customizable forms to their website's users (who are primarily non-technical). It is possible that there is a library out there that achieves this, but I have not seen one.
Some of the concerns are:
Options for each form element
What kind of options to provide to the user, keeping in mind that all of these need to be persisted.
Layout Customization
Is it enough to just have a top to bottom sequential layout. Is it really necessary to offer different layouts? (For instance, a two column layout)
Database storage
Any efficient/relatively quick methods for storing the data entered in the form in a database. The issue here being that you don't know how many columns will be needed. And also, is it okay to store everything as a VARCHAR (losing some of the 'queryability' of dates/integer).
Validation
Should validation be built in (dependant on field type), or customizable?
There are a lot of possibilities, and I'm looking to see what others have used/offered and what they found to be effective. And any potential gotchas or whether it is not really worth it to offer this.
This is one of the holy grails of vertical market application software architecture. Many have tried, most have failed. See what Sharepoint does in this regard. You can't see the architecture, but you can see the user interface.
Beyond a fairly trite level of complexity you will need to add technically literate people into the process. For example, an insurance platform called ZygoWare was released under the premise that it could be customised directly by the business. In practice this tends not to work very well on something like an insurance policy administration system and the product has a reputation for being difficult to implement.
For something like salesforce.com or an online store builder the product is simpler, so it will be easier to achieve direct end-user customisation.
At one point I was involved in specifying an insurance underwriting product. Supporting customisation in such a product has several key aspects:
Database schema - allowing the system to be configured with custom attributes. In commercial insurance a contract record can have 200 fields and may also have several complex structures sitting below it.
User interface. The system will need to record these, so a means to custom fields on a form is necessary. You may also need to set up other screens and database tables.
Business rules. You may want to use a business rules engine to support configurable business logic. This gets quite complex in its own right and the analyst designing the rule sets needs to be deeply familiar with both the business domain and the system architecture.
Workflows. Workflows are de rigeur in volume business and making inroads into large commercial business as well. In subscription markets your workflows involve third parties that may or may not actually have the facilities to participate in the workflow.
Products. A platform may need to support multiple insurance products (e.g. commericial property, life/health, marine cargo, motor, offshore energy). In order to avoid having to deploy a different policy administration system for each department in your company (A typical Lloyds syndicate employs 50-200 people) your platform must support different product lines in some way, possibly involving custom screens, workflows and business rules for the different products.
This lives at the complex end of software customisation. In practice, software like this requires analyst and development skills to sucessfully implement a business solution. The domain and product are sufficiently complex that they are not feasible to implement without specialist skills.
On that basis, my approach to customising a system has a few key pillars:
Recognise who will actually be customising the system
Build it to suit them. In the case above the right level is a team of analysts and developers working for the vendor, in-house (contractors and permanent staff) or a third party consultancy. The appropriate level of abstraction is a scripting language that allows extension (on a per-product basis), a form building tool (such as QT designer or Visual Studio), a database schema management tool and possibly a rule engine such as Ilog. In the case of an on-line store builder a power user could reasonably figure out how to do it themselves.
Address what needs to be customised
In the case of an insurance platform you will have customisation at a level that you are rolling out a substantially bespoke system. The system architecture for this should allow extensions to be plugged in without having to regression test the whole system. In the case of an online store you are substantially customising the layout of the displays and configuring account information with payment providers.
Don't delude yourself about the complexity of the problem.
Don't try to dumb down a system beyond its natural level. History is littered with people who thought they could make a platform that end users could use to build and maintain a complex business application. The only commercially successful example of such a product is a spreadsheet. If you want to see how well this works in practice, try spending some time working in the back office of a large finance company.
Most regulatory authorities such as the FSA take a dim view of 'end-user computing' and the regulatory environments of such industries drive many FTEs worth of time-consuming CYA and manual controls over such processes. It is quite common to find the same computation done redundantly in multiple areas within the back office of such an organisation and the results reconciled against each other to provide a manual control so somebody can feel safe signing off the figures.
I would not try to build a system like that from scratch. Creating a generic form building application that would be able to edit data of any shape, as well as edit the layout, is indeed a holy grail.
Entire companies have been built around this; take a look at, for example: www.wufoo.com, or Microsoft Office InfoPath.
Simpler efforts include Google Spreadsheet (with its form editing / data entry piece), but it's a bit too simplistic for most scenarios.
Have you considered using MS Dynamics CRM? Similar in a lot of ways to Salesforce. It's very easily customisable from a user's perspective, so much so that we have to lock some users out from customising the UI.
From a dev's perspective it has the following building blocks:
DB layer persistence (to SQL Server).
UI customisability
Form-level and field-level security profiles
Reporting (via SQL Server Reporting Services).
Customisable business processes, workflows and dialogs.
Extensible custom code injection points (through registering custom plugins)
We use it a lot to build solutions in the public-sector, health industry we're in. It's really quite good.
The bad about it, it requires a good network/infrastructure team...

Categories