Definitely not perfect, but the database changes seem to be OK, along with the sitelink script. Certainly workable if not yet complete.
git-svn-id: file:///svn-source/pmgr/branches/yafr_20090716@358 97e9348a-65ac-dc4b-aefc-98561f571b83
This commit is contained in:
abijah
427
db/schema.sql
427
db/schema.sql
@@ -922,13 +922,6 @@ UNLOCK TABLES;
|
||||
-- ----------------------------------------------------------------------
|
||||
-- ----------------------------------------------------------------------
|
||||
-- TABLE pmgr_ledgers
|
||||
--
|
||||
-- REVISIT <AP>: 20090605
|
||||
-- We may not really need a ledgers table.
|
||||
-- It's not clear to me though, as we very
|
||||
-- possibly need to close out certain
|
||||
-- ledgers every so often, and just carry
|
||||
-- the balance forward (year end, etc).
|
||||
|
||||
DROP TABLE IF EXISTS `pmgr_ledgers`;
|
||||
CREATE TABLE `pmgr_ledgers` (
|
||||
@@ -969,123 +962,144 @@ CREATE TABLE `pmgr_transactions` (
|
||||
`id` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
|
||||
|
||||
`type` ENUM('INVOICE',
|
||||
'CREDIT',
|
||||
'RECEIPT',
|
||||
'REFUND',
|
||||
'DEPOSIT',
|
||||
-- 'CREDIT',
|
||||
-- 'REFUND',
|
||||
'TRANSFER')
|
||||
NOT NULL,
|
||||
|
||||
`stamp` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
|
||||
|
||||
-- The account/ledger of the transaction set
|
||||
-- (e.g. A/R, Bank, etc)
|
||||
`account_id` INT(10) UNSIGNED NOT NULL,
|
||||
`ledger_id` INT(10) UNSIGNED NOT NULL,
|
||||
|
||||
-- For convenience. Actually, INVOICE will always set crdr
|
||||
-- to DEBIT, RECEIPT will use CREDIT, and DEPOSIT will use
|
||||
-- DEBIT
|
||||
`crdr` ENUM('DEBIT',
|
||||
'CREDIT')
|
||||
NOT NULL,
|
||||
|
||||
-- amount is for convenience. It can always be calculated from
|
||||
-- the associated double entries (and therefore will need to be
|
||||
-- updated if they should change in any way).
|
||||
`amount` FLOAT(12,2) DEFAULT NULL,
|
||||
|
||||
-- `customer_id` INT(10) UNSIGNED DEFAULT NULL,
|
||||
-- `lease_id` INT(10) UNSIGNED DEFAULT NULL,
|
||||
|
||||
`comment` VARCHAR(255) DEFAULT NULL,
|
||||
|
||||
PRIMARY KEY (`id`)
|
||||
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
|
||||
|
||||
|
||||
-- -- -- ----------------------------------------------------------------------
|
||||
-- -- -- ----------------------------------------------------------------------
|
||||
-- -- -- TABLE pmgr_charge_details
|
||||
|
||||
-- DROP TABLE IF EXISTS `pmgr_charge_details`;
|
||||
-- CREATE TABLE `pmgr_charge_details` (
|
||||
-- `id` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
|
||||
-- -- Through date is used if/when a charge covers a certain time period,
|
||||
-- -- like rent. A security deposit, for example, would not use the
|
||||
-- -- through date.
|
||||
-- `through_date` DATE DEFAULT NULL, -- last day
|
||||
-- `due_date` DATE DEFAULT NULL,
|
||||
|
||||
-- PRIMARY KEY (`id`)
|
||||
-- ) ENGINE=MyISAM DEFAULT CHARSET=utf8;
|
||||
|
||||
|
||||
-- -- -- ----------------------------------------------------------------------
|
||||
-- -- -- ----------------------------------------------------------------------
|
||||
-- -- -- TABLE pmgr_payment_details
|
||||
|
||||
-- DROP TABLE IF EXISTS `pmgr_payment_details`;
|
||||
-- CREATE TABLE `pmgr_payment_details` (
|
||||
-- `id` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
|
||||
|
||||
-- -- name may (or may not) be used to clarify in reports
|
||||
-- -- for example, 'Check #1234' as the payment name.
|
||||
-- `name` VARCHAR(80) DEFAULT NULL,
|
||||
|
||||
-- -- REVISIT <AP>: 20090716
|
||||
-- -- Type may needs to be another table, so that the user
|
||||
-- -- can add new types. If so, they will also have to
|
||||
-- -- specify the required data1/2/3/4 fields.
|
||||
-- -- For now, this will work.
|
||||
-- `monetary_type` ENUM('CASH',
|
||||
-- 'CHECK',
|
||||
-- 'MONEYORDER',
|
||||
-- 'ACH',
|
||||
-- 'DEBITCARD',
|
||||
-- 'CREDITCARD')
|
||||
-- DEFAULT NULL,
|
||||
|
||||
-- -- REVISIT <AP>: 20090605
|
||||
-- -- Check Number;
|
||||
-- -- Routing Number, Account Number;
|
||||
-- -- Card Number, Expiration Date; CVV2 Code
|
||||
-- -- etc.
|
||||
-- -- REVISIT <AP> 20090630
|
||||
-- -- I _think_ that CVV2 is NEVER supposed to
|
||||
-- -- be stored ANYWHERE. Merchants agree to
|
||||
-- -- use it only to verify the transaction and
|
||||
-- -- then leave no record of it, so that even
|
||||
-- -- if their security is compromised, no one
|
||||
-- -- will know the CVV2 code unless they are
|
||||
-- -- in physical possession of the card.
|
||||
-- `data1` VARCHAR(80) DEFAULT NULL,
|
||||
-- `data2` VARCHAR(80) DEFAULT NULL,
|
||||
-- `data3` VARCHAR(80) DEFAULT NULL,
|
||||
-- `data4` VARCHAR(80) DEFAULT NULL,
|
||||
|
||||
-- PRIMARY KEY (`id`)
|
||||
-- ) ENGINE=MyISAM DEFAULT CHARSET=utf8;
|
||||
|
||||
|
||||
-- -- ----------------------------------------------------------------------
|
||||
-- -- ----------------------------------------------------------------------
|
||||
-- -- TABLE pmgr_entries
|
||||
-- -- TABLE pmgr_ledger_entries
|
||||
|
||||
DROP TABLE IF EXISTS `pmgr_entries`;
|
||||
CREATE TABLE `pmgr_entries` (
|
||||
DROP TABLE IF EXISTS `pmgr_ledger_entries`;
|
||||
CREATE TABLE `pmgr_ledger_entries` (
|
||||
`id` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
|
||||
|
||||
`type` ENUM('CHARGE',
|
||||
'PAYMENT',
|
||||
'DEPOSIT',
|
||||
'TRANSFER')
|
||||
NOT NULL,
|
||||
`transaction_id` INT(10) UNSIGNED NOT NULL,
|
||||
|
||||
-- The account/ledger of the entry
|
||||
`account_id` INT(10) UNSIGNED NOT NULL,
|
||||
`ledger_id` INT(10) UNSIGNED NOT NULL,
|
||||
|
||||
-- For convenience. Actually, CHARGE will always set crdr
|
||||
-- to CREDIT and PAYMENT will use DEBIT.
|
||||
`crdr` ENUM('DEBIT',
|
||||
'CREDIT')
|
||||
NOT NULL,
|
||||
|
||||
-- The actual ledgers where this entry is recorded
|
||||
`double_entry_id` INT(10) UNSIGNED DEFAULT NULL,
|
||||
`amount` FLOAT(12,2) NOT NULL,
|
||||
|
||||
`comment` VARCHAR(255) DEFAULT NULL,
|
||||
|
||||
PRIMARY KEY (`id`)
|
||||
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
|
||||
|
||||
|
||||
-- -- ----------------------------------------------------------------------
|
||||
-- -- ----------------------------------------------------------------------
|
||||
-- -- TABLE pmgr_double_entries
|
||||
|
||||
DROP TABLE IF EXISTS `pmgr_double_entries`;
|
||||
CREATE TABLE `pmgr_double_entries` (
|
||||
`id` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
|
||||
|
||||
-- The two entries that make up a "double entry"
|
||||
`debit_entry_id` INT(10) UNSIGNED NOT NULL,
|
||||
`credit_entry_id` INT(10) UNSIGNED NOT NULL,
|
||||
|
||||
-- REVISIT <AP>: 20090720
|
||||
-- The amount from ledger_entries should be moved here to
|
||||
-- eliminate duplication, and crdr should just be deleted.
|
||||
-- However, it can always be changed later, and I thinks
|
||||
-- those fields will come in handy when generating a
|
||||
-- a ledger report. So, duplication for now.
|
||||
|
||||
`comment` VARCHAR(255) DEFAULT NULL,
|
||||
|
||||
PRIMARY KEY (`id`)
|
||||
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
|
||||
|
||||
|
||||
-- -- ----------------------------------------------------------------------
|
||||
-- -- ----------------------------------------------------------------------
|
||||
-- -- TABLE pmgr_statement_entries
|
||||
|
||||
DROP TABLE IF EXISTS `pmgr_statement_entries`;
|
||||
CREATE TABLE `pmgr_statement_entries` (
|
||||
`id` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
|
||||
|
||||
`type` ENUM('CHARGE',
|
||||
'PAYMENT')
|
||||
NOT NULL,
|
||||
|
||||
`transaction_id` INT(10) UNSIGNED NOT NULL,
|
||||
|
||||
-- Effective date is when the charge/payment/transfer actually
|
||||
-- takes effect (since it may not be at the time of the transaction).
|
||||
-- Through date is used if/when a charge covers a certain time period,
|
||||
-- like rent. A security deposit, for example, would not use the
|
||||
-- through date.
|
||||
`effective_date` DATE DEFAULT NULL, -- first day
|
||||
`through_date` DATE DEFAULT NULL, -- last day
|
||||
`due_date` DATE DEFAULT NULL,
|
||||
|
||||
`customer_id` INT(10) UNSIGNED NOT NULL,
|
||||
`lease_id` INT(10) UNSIGNED NOT NULL,
|
||||
|
||||
`amount` FLOAT(12,2) NOT NULL,
|
||||
|
||||
-- The account of the entry
|
||||
-- REVISIT <AP>: 20090720
|
||||
-- We don't want to confuse statement entries with ledger entries,
|
||||
-- yet we're including account here. It doesn't feel right, but at
|
||||
-- the same time, it will allow us to show _what_ was charged for
|
||||
-- in the statement. Keeping it for now...
|
||||
`account_id` INT(10) UNSIGNED DEFAULT NULL,
|
||||
|
||||
-- Allow the payment to reconcile against the charge
|
||||
`charge_entry_id` INT(10) UNSIGNED DEFAULT NULL,
|
||||
|
||||
`comment` VARCHAR(255) DEFAULT NULL,
|
||||
|
||||
PRIMARY KEY (`id`)
|
||||
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
|
||||
|
||||
|
||||
-- ----------------------------------------------------------------------
|
||||
-- ----------------------------------------------------------------------
|
||||
-- TABLE pmgr_payments
|
||||
|
||||
DROP TABLE IF EXISTS `pmgr_payments`;
|
||||
CREATE TABLE `pmgr_payments` (
|
||||
`id` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
|
||||
|
||||
-- name may (or may not) be used to clarify in reports
|
||||
-- for example, 'Check #1234' as the payment name.
|
||||
`name` VARCHAR(80) DEFAULT NULL,
|
||||
@@ -1095,7 +1109,7 @@ CREATE TABLE `pmgr_entries` (
|
||||
-- can add new types. If so, they will also have to
|
||||
-- specify the required data1/2/3/4 fields.
|
||||
-- For now, this will work.
|
||||
`monetary_type` ENUM('CASH',
|
||||
`type` ENUM('CASH',
|
||||
'CHECK',
|
||||
'MONEYORDER',
|
||||
'ACH',
|
||||
@@ -1121,48 +1135,13 @@ CREATE TABLE `pmgr_entries` (
|
||||
`data3` VARCHAR(80) DEFAULT NULL,
|
||||
`data4` VARCHAR(80) DEFAULT NULL,
|
||||
|
||||
`comment` VARCHAR(255) DEFAULT NULL,
|
||||
|
||||
PRIMARY KEY (`id`)
|
||||
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
|
||||
|
||||
|
||||
-- ----------------------------------------------------------------------
|
||||
-- ----------------------------------------------------------------------
|
||||
-- TABLE pmgr_reconciliations
|
||||
|
||||
DROP TABLE IF EXISTS `pmgr_reconciliations`;
|
||||
CREATE TABLE `pmgr_reconciliations` (
|
||||
`id` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
|
||||
|
||||
`debit_entry_id` INT(10) UNSIGNED NOT NULL,
|
||||
`credit_entry_id` INT(10) UNSIGNED NOT NULL,
|
||||
`amount` FLOAT(12,2) NOT NULL,
|
||||
|
||||
PRIMARY KEY (`id`)
|
||||
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
|
||||
|
||||
|
||||
-- ----------------------------------------------------------------------
|
||||
-- ----------------------------------------------------------------------
|
||||
-- TABLE pmgr_double_entries
|
||||
|
||||
DROP TABLE IF EXISTS `pmgr_double_entries`;
|
||||
CREATE TABLE `pmgr_double_entries` (
|
||||
`id` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
|
||||
|
||||
`transaction_id` INT(10) UNSIGNED DEFAULT NULL,
|
||||
|
||||
-- Effective date is when the charge/payment/transfer actually
|
||||
-- takes effect (since it may not be at the time of the transaction).
|
||||
`effective_date` DATE DEFAULT NULL, -- first day
|
||||
|
||||
`customer_id` INT(10) UNSIGNED DEFAULT NULL,
|
||||
`lease_id` INT(10) UNSIGNED DEFAULT NULL,
|
||||
|
||||
`debit_ledger_id` INT(10) UNSIGNED NOT NULL,
|
||||
`credit_ledger_id` INT(10) UNSIGNED NOT NULL,
|
||||
`amount` FLOAT(12,2) NOT NULL,
|
||||
-- The ledger entry this physical payment applies to
|
||||
`ledger_entry_id` INT(10) UNSIGNED NOT NULL,
|
||||
-- The deposit that included these monies
|
||||
`deposit_entry_id` INT(10) UNSIGNED DEFAULT NULL,
|
||||
-- The NSF entry, should this come back from the bank.
|
||||
`nsf_ledger_entry_id` INT(10) UNSIGNED DEFAULT NULL,
|
||||
|
||||
`comment` VARCHAR(255) DEFAULT NULL,
|
||||
|
||||
@@ -1172,193 +1151,33 @@ CREATE TABLE `pmgr_double_entries` (
|
||||
|
||||
-- ----------------------------------------------------------------------
|
||||
-- ----------------------------------------------------------------------
|
||||
-- TABLE pmgr_charges_payments
|
||||
-- TABLE pmgr_deposits
|
||||
|
||||
DROP TABLE IF EXISTS `pmgr_charges_payments`;
|
||||
CREATE TABLE `pmgr_charges_payments` (
|
||||
DROP TABLE IF EXISTS `pmgr_deposits`;
|
||||
CREATE TABLE `pmgr_deposits` (
|
||||
`id` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
|
||||
|
||||
-- Mark which charge the payment reconciles, and how much was applied
|
||||
`charge_entry_id` INT(10) UNSIGNED NOT NULL,
|
||||
`payment_entry_id` INT(10) UNSIGNED NOT NULL,
|
||||
`transaction_id` INT(10) UNSIGNED NOT NULL,
|
||||
|
||||
-- The account/ledger of the entry
|
||||
`account_id` INT(10) UNSIGNED NOT NULL,
|
||||
`ledger_id` INT(10) UNSIGNED NOT NULL,
|
||||
|
||||
-- For convenience. Should always be DEBIT (unless we
|
||||
-- decide to credit NSF instead of a negative debit).
|
||||
`crdr` ENUM('DEBIT')
|
||||
NOT NULL DEFAULT 'DEBIT',
|
||||
|
||||
`amount` FLOAT(12,2) NOT NULL,
|
||||
|
||||
`comment` VARCHAR(255) DEFAULT NULL,
|
||||
|
||||
PRIMARY KEY (`id`)
|
||||
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
|
||||
|
||||
|
||||
|
||||
|
||||
-- -- ----------------------------------------------------------------------
|
||||
-- -- ----------------------------------------------------------------------
|
||||
-- -- TABLE pmgr_folders
|
||||
-- --
|
||||
-- -- It's a dumb name, but at the moment, it's how I'm thinking about
|
||||
-- -- this all. In the generic, a purchase begins with a purchase order
|
||||
-- -- from the customer. When you receive it, you grab a new manilla
|
||||
-- -- folder, drop the purchase order in, and start making the widgets.
|
||||
-- -- when their ready, you ship them with invoice, and drop a copy of
|
||||
-- -- the invoice in the folder. When they pay, you generate a receipt,
|
||||
-- -- and drop a copy in the folder. If the check bounces, you note
|
||||
-- -- that in the folder, and generate a new NSF fee invoice (which gets
|
||||
-- -- put into its OWN new folder). When they pay again, you generate
|
||||
-- -- another receipt and put it into the folder, and this process could
|
||||
-- -- repeat until the invoice finally gets paid, or you write it off as
|
||||
-- -- a bad debt, which would be noted, of course, in the folder.
|
||||
|
||||
-- DROP TABLE IF EXISTS `pmgr_folders`;
|
||||
-- CREATE TABLE `pmgr_folders` (
|
||||
-- `id` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
|
||||
-- `stamp` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
|
||||
-- `comment` VARCHAR(255) DEFAULT NULL,
|
||||
|
||||
-- `customer_id` INT(10) UNSIGNED DEFAULT NULL,
|
||||
-- `lease_id` INT(10) UNSIGNED DEFAULT NULL,
|
||||
|
||||
-- PRIMARY KEY (`id`)
|
||||
-- ) ENGINE=MyISAM DEFAULT CHARSET=utf8;
|
||||
|
||||
|
||||
-- -- ----------------------------------------------------------------------
|
||||
-- -- ----------------------------------------------------------------------
|
||||
-- -- TABLE pmgr_invoices
|
||||
|
||||
-- DROP TABLE IF EXISTS `pmgr_invoices`;
|
||||
-- CREATE TABLE `pmgr_invoices` (
|
||||
-- `id` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
|
||||
|
||||
-- `stamp` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
|
||||
|
||||
-- -- amount is for convenience. It can always be calculated from
|
||||
-- -- the attached ledger entries (and therefore will need to be
|
||||
-- -- updated if they should change in any way).
|
||||
-- `amount` FLOAT(12,2) DEFAULT NULL,
|
||||
|
||||
-- -- `customer_id` INT(10) UNSIGNED DEFAULT NULL,
|
||||
-- -- `lease_id` INT(10) UNSIGNED DEFAULT NULL,
|
||||
|
||||
-- -- `folder_id` INT(10) UNSIGNED NOT NULL,
|
||||
|
||||
-- `comment` VARCHAR(255) DEFAULT NULL,
|
||||
|
||||
-- PRIMARY KEY (`id`)
|
||||
-- ) ENGINE=MyISAM DEFAULT CHARSET=utf8;
|
||||
|
||||
|
||||
-- -- ----------------------------------------------------------------------
|
||||
-- -- ----------------------------------------------------------------------
|
||||
-- -- TABLE pmgr_charges
|
||||
|
||||
-- DROP TABLE IF EXISTS `pmgr_charges`;
|
||||
-- CREATE TABLE `pmgr_charges` (
|
||||
-- `id` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
|
||||
|
||||
-- -- Effective date is when the charge actually takes effect
|
||||
-- -- (since it may not be at the time of the invoice). Through
|
||||
-- -- date is used if/when a charge covers a certain time period,
|
||||
-- -- like rent. A security deposit, for example, would not use
|
||||
-- -- the through date.
|
||||
-- `effective_date` DATE DEFAULT NULL, -- first day
|
||||
-- `through_date` DATE DEFAULT NULL, -- last day
|
||||
-- `due_date` DATE DEFAULT NULL,
|
||||
|
||||
-- `customer_id` INT(10) UNSIGNED DEFAULT NULL,
|
||||
-- `lease_id` INT(10) UNSIGNED DEFAULT NULL,
|
||||
-- `amount` FLOAT(12,2) DEFAULT NULL,
|
||||
-- `comment` VARCHAR(255) DEFAULT NULL,
|
||||
|
||||
-- PRIMARY KEY (`id`)
|
||||
-- ) ENGINE=MyISAM DEFAULT CHARSET=utf8;
|
||||
|
||||
|
||||
-- -- ----------------------------------------------------------------------
|
||||
-- -- ----------------------------------------------------------------------
|
||||
-- -- TABLE pmgr_payments
|
||||
|
||||
-- DROP TABLE IF EXISTS `pmgr_payments`;
|
||||
-- CREATE TABLE `pmgr_payments` (
|
||||
-- `id` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
|
||||
|
||||
-- `stamp` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
|
||||
|
||||
-- -- Customer ID ensures that they payment doesn't get lost
|
||||
-- -- in the system if either a) it's a pre-payment, or
|
||||
-- -- b) the associated invoice is deleted.
|
||||
-- `customer_id` INT(10) UNSIGNED DEFAULT NULL,
|
||||
-- `amount` FLOAT(12,2) DEFAULT NULL,
|
||||
|
||||
-- -- name may (or may not) be used to clarify in reports
|
||||
-- -- for example, 'Check #1234' as the payment name.
|
||||
-- `name` VARCHAR(80) DEFAULT NULL,
|
||||
|
||||
-- -- REVISIT <AP>: 20090716
|
||||
-- -- Type may needs to be another table, so that the user
|
||||
-- -- can add new types. If so, they will also have to
|
||||
-- -- specify the required data1/2/3/4 fields.
|
||||
-- -- For now, this will work.
|
||||
-- `type` ENUM('CASH',
|
||||
-- 'CHECK',
|
||||
-- 'MONEYORDER',
|
||||
-- 'ACH',
|
||||
-- 'DEBITCARD',
|
||||
-- 'CREDITCARD')
|
||||
-- DEFAULT NULL,
|
||||
|
||||
-- -- REVISIT <AP>: 20090605
|
||||
-- -- Check Number;
|
||||
-- -- Routing Number, Account Number;
|
||||
-- -- Card Number, Expiration Date; CVV2 Code
|
||||
-- -- etc.
|
||||
-- -- REVISIT <AP> 20090630
|
||||
-- -- I _think_ that CVV2 is NEVER supposed to
|
||||
-- -- be stored ANYWHERE. Merchants agree to
|
||||
-- -- use it only to verify the transaction and
|
||||
-- -- then leave no record of it, so that even
|
||||
-- -- if their security is compromised, no one
|
||||
-- -- will know the CVV2 code unless they are
|
||||
-- -- in physical possession of the card.
|
||||
-- `data1` VARCHAR(80) DEFAULT NULL,
|
||||
-- `data2` VARCHAR(80) DEFAULT NULL,
|
||||
-- `data3` VARCHAR(80) DEFAULT NULL,
|
||||
-- `data4` VARCHAR(80) DEFAULT NULL,
|
||||
|
||||
-- `comment` VARCHAR(255) DEFAULT NULL,
|
||||
|
||||
-- PRIMARY KEY (`id`)
|
||||
-- ) ENGINE=MyISAM DEFAULT CHARSET=utf8;
|
||||
|
||||
|
||||
-- -- ----------------------------------------------------------------------
|
||||
-- -- ----------------------------------------------------------------------
|
||||
-- -- TABLE pmgr_transfers
|
||||
|
||||
-- DROP TABLE IF EXISTS `pmgr_transfers`;
|
||||
-- CREATE TABLE `pmgr_transfers` (
|
||||
-- `id` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
|
||||
|
||||
-- -- Effective date is when the charge actually takes effect
|
||||
-- -- (since it may not be at the time of the invoice). Through
|
||||
-- -- date is used if/when a charge covers a certain time period,
|
||||
-- -- like rent. A security deposit, for example, would not use
|
||||
-- -- the through date.
|
||||
-- `effective_date` DATE DEFAULT NULL, -- first day
|
||||
-- `through_date` DATE DEFAULT NULL, -- last day
|
||||
-- `due_date` DATE DEFAULT NULL,
|
||||
|
||||
-- `customer_id` INT(10) UNSIGNED DEFAULT NULL,
|
||||
-- `lease_id` INT(10) UNSIGNED DEFAULT NULL,
|
||||
-- `amount` FLOAT(12,2) DEFAULT NULL,
|
||||
-- `comment` VARCHAR(255) DEFAULT NULL,
|
||||
|
||||
-- PRIMARY KEY (`id`)
|
||||
-- ) ENGINE=MyISAM DEFAULT CHARSET=utf8;
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
-- ######################################################################
|
||||
-- ######################################################################
|
||||
-- ######################################################################
|
||||
|
||||
Reference in New Issue
Block a user