abijah/pmgr
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Modified tenders to use a tender_type_id, not only for the ability to dynamically add types later, but primarily so that a type could be associated with an account, instead of hardcoding it in the application. With this, I changed several of the account field names, but they shouldn't be in too heavy use in the application.

Browse Source 
git-svn-id: file:///svn-source/pmgr/branches/yafr_20090716@376 97e9348a-65ac-dc4b-aefc-98561f571b83
This commit is contained in:
abijah
2009-07-24 01:43:41 +00:00
parent c73016ecf2
commit e739282d17
2 changed files with 162 additions and 70 deletions
Download Patch File Download Diff File Expand all files Collapse all files

103
db/schema.sql
View File

@@ -842,12 +842,11 @@ CREATE TABLE `pmgr_accounts` (
-- For LIABILITY, EQUITY, and INCOME, the opposite
-- is true, with reconciliations posted, under
-- normal circumstances, when a debit occurs.
`trackable` TINYINT(1) UNSIGNED NOT NULL DEFAULT 1,
`tillable` TINYINT(1) UNSIGNED NOT NULL DEFAULT 0, -- Does manager collect by hand?
`depositable` TINYINT(1) UNSIGNED NOT NULL DEFAULT 0, -- Does this account receive deposits?
`chargeable` TINYINT(1) UNSIGNED NOT NULL DEFAULT 0, -- Can be used for charges?
`payable` TINYINT(1) UNSIGNED NOT NULL DEFAULT 0, -- Can be used for payments?
`refundable` TINYINT(1) UNSIGNED NOT NULL DEFAULT 0, -- Can be used for refunds?
-- `trackable` TINYINT(1) UNSIGNED NOT NULL DEFAULT 1,
`deposits` TINYINT(1) UNSIGNED NOT NULL DEFAULT 0, -- Can be used for deposits?
`charges` TINYINT(1) UNSIGNED NOT NULL DEFAULT 0, -- Can be used for charges?
`payments` TINYINT(1) UNSIGNED NOT NULL DEFAULT 0, -- Can be used for payments?
`refunds` TINYINT(1) UNSIGNED NOT NULL DEFAULT 0, -- Can be used for refunds?
-- Security Level
`level` INT UNSIGNED DEFAULT 10,
@@ -874,33 +873,34 @@ INSERT INTO `pmgr_accounts` (`type`, `name`)
-- us identify how serious the NSF situation is.
('ASSET', 'NSF' ),
('LIABILITY', 'A/P' );
INSERT INTO `pmgr_accounts` (`type`, `name`, `tillable`, `payable`, `refundable`)
INSERT INTO `pmgr_accounts` (`type`, `name`, `payments`, `refunds`)
VALUES
('ASSET', 'Cash', 1, 1, 1),
('ASSET', 'Check', 1, 1, 0),
('ASSET', 'Money Order', 1, 1, 0),
('ASSET', 'ACH', 0, 1, 0),
('EXPENSE', 'Concession', 0, 1, 0);
INSERT INTO `pmgr_accounts` (`type`, `name`, `refundable`, `depositable`)
('ASSET', 'Cash', 1, 1),
('ASSET', 'Check', 1, 0),
('ASSET', 'Money Order', 1, 0),
('ASSET', 'ACH', 1, 0),
('ASSET', 'Closing', 0, 0), -- REVISIT <AP>: Temporary
('EXPENSE', 'Concession', 1, 0);
INSERT INTO `pmgr_accounts` (`type`, `name`, `refunds`, `deposits`)
VALUES
-- REVISIT <AP>: 20090710 : We probably don't really want petty cash depositable.
-- This is just for testing our deposit code
('ASSET', 'Petty Cash', 1, 1);
INSERT INTO `pmgr_accounts` (`type`, `name`, `chargeable`, `trackable`)
INSERT INTO `pmgr_accounts` (`type`, `name`, `charges`)
VALUES
('LIABILITY', 'Tax', 1, 1),
('LIABILITY', 'Security Deposit', 1, 1),
('INCOME', 'Rent', 1, 0),
('INCOME', 'Late Charge', 1, 0),
('INCOME', 'NSF Charge', 1, 0),
('INCOME', 'Damage', 1, 0);
INSERT INTO `pmgr_accounts` (`type`, `name`, `depositable`, `refundable`, `trackable`)
('LIABILITY', 'Tax', 1),
('LIABILITY', 'Security Deposit', 1),
('INCOME', 'Rent', 1),
('INCOME', 'Late Charge', 1),
('INCOME', 'NSF Charge', 1),
('INCOME', 'Damage', 1);
INSERT INTO `pmgr_accounts` (`type`, `name`, `deposits`, `refunds`)
VALUES
('ASSET', 'Bank', 1, 1, 0);
INSERT INTO `pmgr_accounts` (`type`, `name`, `trackable`)
('ASSET', 'Bank', 1, 1);
INSERT INTO `pmgr_accounts` (`type`, `name`)
VALUES
('EXPENSE', 'Bad Debt', 0),
('EXPENSE', 'Maintenance', 0);
('EXPENSE', 'Bad Debt' ),
('EXPENSE', 'Maintenance' );
UNLOCK TABLES;
@@ -1113,6 +1113,45 @@ CREATE TABLE `pmgr_statement_entries` (
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
-- ----------------------------------------------------------------------
-- ----------------------------------------------------------------------
-- TABLE pmgr_tender_types
DROP TABLE IF EXISTS `pmgr_tender_types`;
CREATE TABLE `pmgr_tender_types` (
`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 legal tender name.
`name` VARCHAR(80) NOT NULL,
-- Does this form of legal tender actually change hands?
-- If so, then it's tillable. Examples include cash,
-- checks, and money orders. Things that are not tillable
-- include credit cards, debit cards, and ACH transfers.
`tillable` TINYINT(1) UNSIGNED NOT NULL DEFAULT 1,
-- How many data fields are required/used by this type.
-- Not the most robust of solutions, especially since
-- it requires (or strongly implicates) that all fields
-- be of the same type (ugh). A more complete solution
-- would be for each type to have its own table of data
-- and to have that table specified here. However, this
-- is MUCH simpler, and works for now.
`data_fields` SMALLINT UNSIGNED NOT NULL DEFAULT 0,
-- When we accept legal tender of this form, where does
-- it go? Each type of legal tender can specify an
-- account, either distinct or non-distinct from others
`account_id` INT(10) UNSIGNED NOT NULL,
`comment` VARCHAR(255) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
-- ----------------------------------------------------------------------
-- ----------------------------------------------------------------------
-- TABLE pmgr_tenders
@@ -1125,18 +1164,8 @@ CREATE TABLE `pmgr_tenders` (
-- for example, 'Check #1234' as the legal tender 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,
-- The type of this legal tender
`tender_type_id` INT(10) UNSIGNED DEFAULT NULL,
-- REVISIT <AP>: 20090605
-- Check Number;