QUOTE(cancer10 @ Sep 13 2004, 08:46 AM)
Well, I have designed it as a generalise software. It is ment accordig to the requirement of wot a billing software would require.
If my clients want to customize it further then I can do that for them.
Else everything is fine.
I can understand that, but the big question is, how does the sales information get into the application? If there is a customer base, then sales transactions would have to be billed under the customer, so how are the sales transactions handled? Does this pull the information from an existing database that is used primarily for a POS system? If so, what limitations does the application have regarding the different types of POS systems available? If the application shows inventory, hows does the inventory enter the system?
Don't think that I am criticizing your application, because I am not. I have built an accounting application myself so I know what has to be integrated with it. Accounting information is only as good as the way the information is gathered from within the system. If there is a manual entry of information anywhere in the sales tier, then the application is useless. There are many other aspects regarding a retail application and the only reason I ask these questions is that you have created features that are not accounting features, such as inventory and a customer base. These things are sales and credit processes. Accounting deals directly with the GL.
You should also consider the benefits of such an application as it pertains to the growth of a retail operation. The application needs to be able to grow with the company. There should be a way to allow for multiple company information thereby allowing for seperate GL's while maintaining the ability to cross reference company information. If the application is based in part by a customer base, then other factors also need to be considered such as pricing levels and credit options. I am under the assumption that the customer base is a "Credit" based customer file as the customers are billed and simply not given a transaction receipt, so this brings up more things that need to be considered. Credit limits, credit status, invoicing, statements, etc, etc. Because the customers are "Credit" based, usually Net30, then there has to be aging buckets involved for accouting purposes. 30 days, 60 days, 90 days, etc, etc. Aging analysis is an extremely important part of any customer base that uses Net30 credit.
Any retail operation that maintains an inventory must be audited at least once a year, sometimes more. Because of this, inventory reporting is critical. If inventory is integrated into the application then the ramifications of this must be considered. A way to enter packing slips or bills of lading must be created to maintain a history for auditing purposes. Control over ordering and receiving must also be applied. For example, when a product is ordered, there must be a way to track that order such as a purchase order. The order is created and is left outstanding until the product arrives and the packing slip entered thereby fulfilling the inventory order process and closing out the purchase order. This maintains a history of ordering and receiving in conjunction with the inventory. Auditors ask for this information and more when processing inventory audits. You must also have a system in place to control who can do what. The system cannot allow anyone to adjust inventory. This is a managerial duty and should be taken seriously.
Again, I am not criticizing your application in the least, but when building an application such as this, there are lots of business issues that have to be considered. The legalities of owning a business are critical to the software that the business runs.
m8
woo!! lol grrr i hate coursework 
