On Fri, 2005-09-23 at 10:13 -0600, Chuck Bunn wrote: > Phase one would be to capture the data to a flat file phase 2 would > be to get it into a database, phase three would interface it to an > existing LAMP based time card apt and phase 4 would allow for phone > access to information stored in the time card such as how many hours > worked, hours by day etc. A final phase would interface these to both > Peachtree and Quickbooks.
A quick suggestion here is that there is likely as much effort to do phase one on your list as bypassing it and going to phase two. If you are sure a database is truly needed, you shouldn't start on a flat file. I know this next suggestion is influenced by my current like of the implementation, but if you choose to stay at a flat file, you may want to look at yaml as your storage format. I say this as it stores objects in a nice clean manner and there are many languages that can use yaml files. Also yaml allows for each entry to contain different data. That is something CSV or databases have problems with. While this point doesn't help most people's implementation, it would help a service provider wishing to support many companies at once. I don't even know if that would be a very marketable function either. It is usually a trivial task to write a script to convert from a yaml file to any other file format you might need. Also by staying at a flat file, you are going to lower barriers to entry. While your current needs may not need it, you might want to think about expandability to include referencing a contract or work order number. Contractors would probably enjoy being able to call home and log arrival times at a client site while specifying what work order that time is being billed to. Combine that with the ability to call back and "close" that session of the work order, possibly also recording any final notes about the session to be tied to the billing. You might also want to consider the ability to start/stop the clock for lunch breaks or other non-billable time. Just a few more thoughts to be tossed in the mix. -- Steven Critchfield <[EMAIL PROTECTED]> _______________________________________________ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
