Best Practices in Design of Billing / Invoice Software in .NET [closed]

Question

I am currently working on a project where I have to design / implement the billing/invoicing system for our companies new project. We will be generating the invoices once a month as pdf files and sending out a link to the file to the customer.

The framework in use will be .Net 3.5 / C#. As I do not have a lot of experience doing this from scratch I was wondering if there were some best practices from a software perspective that I should consider while doing this that are specific to this type of application?

I realize this question is probably pretty subjective, but I'm looking for guidelines that keep in mind that - specifically those that would commonly be missed or might not be obvious.

Baines

Answer 1

Keep it secure! Make sure your users can get the information through a password-protected HTTPS connection! Let the users pick their own passwords. And be careful because billing/invoice information is considered very sensitive, thus be prepared someone will attempt to hack into this system. There will be people who will attempt to abuse this invoice system so one thing is important: Security!

Some companies have gone completely broke after having to pay for damages simply because a hacker gained access to their system!

Start with writing a multi-tier design, which should involve multiple, physical servers. One database server with customer invoice/billing data. One middle-tier business server to store your business logic. And one web server which can only talk to the business layer and not to the database in the background! If possible, keep the database in a different network. Preferably a network that has no gateways to the outside world.

Xenophobe

Answer 2

Don't send invoices for $0.00. I hate that. ;)

Tishatishri

Answer 3

Are you implementing the billing/invoicing system proper, or just the part that creates a pdf and sends out a link? If the former, you'd have to provide actual requirements to receive guidance. If the latter, something like SSRS could work well.

Nocti

Well it is the former. Actual requirements given to me are pretty much what I wrote, so I am flying just a little more blind than I like on this one - however I am working on getting better requirements - once I get them I'll update my question as needed. Thanks! – Baines

At this point, I would be more worried about getting accurate requirements than about specific implementation issues. Once you have a starting list of requirements, you can evaluate the scope of work and decide whether it is more cost-effective to buy a COTS product. Try to discover the Roles (e.g., AccountsReceivable, Customer, SysAdmin) along with the uses you need to support. And try to make a clear distinction between functional requirements (e.g., a Customer views a Bill) and non-functional requirements (e.g., the application is written on .NET 3.5). – Nocti

Answer 4

Unless you have a very small company or a very unique/niche business, it might be a lot less painful to look into purchasing a 3rd party billing/invoicing system and then customize it as needed.

A commercial product will probably have a lower cost of ownership in the long run, and they will already have thought out all the security issues and done a lot of numerical testing, which could save a lot of money in mistakes. An additional bonus would be industry-standard interfaces to link your billing/inviocing system with your accounting system, CRM, etc. If you write your own, you will have to work all of this out yourself.

Pilcher

Answer 5

Consider using SSRS, or some other reporting package, to create and send the PDFs to your customers.

Rundown

Answer 6

Interface with your accounting software and let it do most, if not all, the work. On the two projects where we've done billing & invoicing, the one that was successful had several developer-years of work put into it; the other one worked but it was/is a maintenance nightmare.

If you still opt to do it all in-house, unit-testing (especially regression testing) is key. You have to be sure any fixes don't break anything else. With these tests, it's wise to have a very large test base.

Nalepka