This discussion puzzles me a little bit. What is the "master record table?" That title makes it sound kind of like a big flat database file, like one that contains demographic info as well as transactional data, and even line item transaction data such as payments, new charges, etc.
In my system, every transaction item refers to several other tables for the info that should not need re-imputing or rarely updated, such as a table for company names and account numbers, another for transaction date, time, etc, another for item descriptions, and finally, the "live" table that is input directly, but which really just a transaction detail table that includes only a transaction number that refers to the transaction table that refers to the company table, etc and an item number that refers to the item description tables, an amount, a quantity, an extended amount, a discount amount and a short comment field. The invoices, statements, P & Ls etc. are then just reports based on the various views involved and are generated "on the fly". Am I missing something? On Tue, Feb 21, 2012 at 4:10 PM, J BLAUSTEIN <[email protected]> wrote: > ** > I would record your invoicing data to a intermediate table - run a program > to check for errors, duplications,overlaps... and when you are satisfy that > data is correct, then update it to your invoice data file > J > On 2/21/2012 1:55 PM, TFred wrote: > > We are expanding our service billing capability and have become stuck on > a good way to do this. Info can come from any number of computers, but most > will be through 2-3 office machines. We currently check for typos, billing > overlaps, and other errors. Right now everything goes directly to a master > record table and then uses a form to ID a date range to check the selected > bills. It works. The question becomes: as we allow more sites to enter > their billing info is there a best way to do this with the least likelihood > of problems? **** > > 1. Send all info directly to a master record table. This makes sure > all the data is collected and problems are resolved later. Conflicts should > be minimal but are likely as existing data is checked while rows get added. > Final checker may not always see the problem. **** > > 2. Send data to temporary tables at each computer as it is entered > and review the temp for problems, then append it up to the master table. > The temporary nature of temp tables means stuff could happen before a temp > is appended and data gets lost. At the same time, hopefully, the person > entering will see a problem long before the final checker. Final checker > still has to check for overlaps and errors in the master table.**** > > 3. Looked at regular tables for each computer but that seemed like > asking for problems that temp tables solve.**** > > ** ** > > Any other methods people use?**** > > ** ** > > Tom Frederick**** > > Jacksonville, IL**** > > > > -- > ** **** **** ** > > *J. Blaustein***** > > *J Blaustein Associates, Inc.* > > * 12 Herrick Drive* > > * Lawrence, NY 11559* > > *516-371-3445 FAX 516-345-8009***** > ************ > -- William Stacy, O.D. Please visit my website by clicking on : http://www.folsomeye.net
