Accounting Database Tables

For this project I need a DBA or Software developer to develop a MYSQL write file for a mid sized accounting database. I anticipate the write file to require roughly 150-300 tables and will follow Camel case format such as "InvoiceTaxDetail" with table field names and types consistant and carefully organized. *** I'm really looking for a programmer/DBA who will put some serious thought into this, someone who wants to form a long term relationship and extend the project into something substantial over time *** ## Deliverables The delivered accounting database must NOT be compose of any tables or fields from a existing accounting system such as, but not limited to, Microsoft Office Accounting, Microsoft Dynamics, Microsoft Axapta, Peachtree, Quickbooks, Oracle Accounting, Peoplesoft or any Open Source database... This write file(s) must be wholly authored by the developer or DBA chosen to complete this project, however the author should review existing accounting systems for reference purposes. The size of the database should be similiar to that of Quickbooks with supporting tables for all general functions. This should not be a quick solution, the developer/dba should put significant thought into concepts such as batch processing, item classes, tax tables, etc and all tables should be complete and reasonable designed to support a 5 million + per year US company with all accounting functions. The delivered program will not be required to be shipped with any data except where specified. The developer/DBA should use their expertise in some cases to deliver the most realistic solution for a given module, in addition, the developer/DBA should choose extensibility and reusability over fixed controls. Design Guidelines * All tables will have a GUID ID field called "ID" and where necessary Title, Description, and Comment fields * Constants should be defined for major fields such as inactive, debit, credit, etc. * All tables will have a BIT field called "Inactive" * Tables should be prefixed with their module such as "GL" or "Company", "SOP", "IVC", "INV", "MFG" so that the tables names look as follows "GL_Account", "IVC_Detail", "IVC_Detail_Tax" * The developer does NOT have to worry about relationship enforcement at this time. * No plurals such as "<strike>InvoiceDetails"</strike> instead use "InvoiceDetail" * As a naming convention all table and field names will consist of camel case such as InvoiceTaxDetail not <strike>INVOICETAXDETAIL</strike> * All tables will have a helper tables for history denoted with "History" as the suffix with the following fields HistoryID (GUID), ID(GUID of original table's ID), Modified (DateTime), ModifiedBy (GUID), Created (BIT to identify this record as being the "created" record) * All tables will have a helper tables for audits denoted with "Audit" as the suffix with the following fields HistoryID (GUID), ID(GUID of original table's ID), Modified (DateTime), ModifiedBy (GUID), Created (BIT to identify this record as being the "created" record) * There should be a help table called SYS_Tables with an ID (GUID), Title, Modele, Description General Accounting * Accounting modules must support batch processing * Use US model of City, State, Zip sales tax (no VAT) - note that some US taxes are taxable. * Underlying system must support both goods and services for sale, not just products Modules Expected. I have included some basic expectations but the developer should definitely use a lot of thought and creativity here. * System - tables responsible for managing the system * Posting Type * Fiscal Year start * Depreciation schedules * etc... * General Ledger * Support for segmented GL * Inventory * There should be lots of supporting lists for the inventory module * Item classes * Take special note of UOM, Price Levels for batch purchases, Classes, and Taxes * Inventory tables and must have necessary tables to track all inventory UOM, price levels, storage locations and support shipping of products to different locations. * Support FIFO, LIFO, none, etc * Asset Management * Provide support for major depreciation schedules * Purchasing * Support partial receipts * Sales Order Processing, Invoicing, Estimates, Shipping * Customer classes * Customer must support multiple addresses, different tax values based upon ship-to, Ship on Hold, Sale on Hold, Sales Tax Exception * Accounts Receivable * Support partial reciepts * Aging + Finance Charges * Accounts Payable * Support partial payment * Aging + Finance Charges * Banking * Author bank tables such that by design they can support import from a financial entity * Support Transaction categories tables with auto-categorization of data import based upon keywords, for example "Rent" should be a keyword to categories a rent payment imported from the bank account to debit "Rents Payable" and credit the "Rents Paid" account. * Payroll * Employee Roster * Salary, Part Time, and Hourly payments * Payroll tax * Basic manufacturing * Step based maufacturing * Multi-parent BOM * Tax * Define the tax tables necessary to support a large acounting system * For sales tax fields refer to <[login to view URL]>, note that each US Zipcode has unique taxes so the tax system should support rate tables not hardcoded taxes. * Payroll Tax Accrual and payment (including partial payments) * Sales Tax Accrual and payments (including partial payments)