FAS Internals Overview

Schema

• Getting a printed schema listing
• On-line schema listings
• Conceptual Data Model (future)
• Who's going to win (on-line and CDM)

Linkage between files

• Common key fields
• Primary key fields
• Indices to figure who defines what

Index efficiancy

• All files except calendar linked by fiscal year
• Always use fiscal year to bracket queries
• For best performance, use indices only
• Always use all components upto and including the component you want

Common threads

• never cross a fiscal year
• all dates (except voiding & invoice dates) *MUST* be within the bounds of the fiscal year the record is attached to
• All transactions in ancillary systems (AP/AR/RC/DS) are reflected in GL
• On transactions in GL are used for account balance calcs
• transactions (GL/AP/AR/DS/RC) are only partially deleted when the user picks 'DELETE'. The xx-tran record is kept (though cleared) and tran-deleted is set. This is so that there are never holes in transaction numbers (which would make auditors cranky).
• Summary transactions for AP/AR/RC/DS are amalgams of all unposted transactional activity for a given month for the subsystem.

Overview of files

• fas-prof
  • Only one per system
  • Controls when things are encumbered
  • defines 'budget usage flags for reports
  • tracks the last deposit # used
  • Set the name of the receipt printer
  • track last auto-assigned invoice #
  • controls if discounts are enabled
  • pretty much set it and forget it
• period
  • One per fiscal year
  • defines start/stop of fiscal year
  • defines length & # of periods in each fiscal year
  • tracks status of periods
• acct
  • Both general and detail accounts
  • Detail accounts are linked to general accounts
  • Detail accounts are only ones transactions occur against
  • General accounts are for maintaining the account structure
  • Never modify the account figures or account #
  • Use do-appl.p, do-enc.p & do-budg.p to update figures only
  • period counters are months in fiscal year (i.e. 1 = june)
  • xTD figures are usually 'unhelpful' (i.e. don't use them)
  • user fields can be used for anything (FAS ignores them)
• acct-class
  • Allows arbitrary accounts to be grouped under a common name
  • This record only defines the account class name
  • Use for reporting and security
• acct-class-acct
  • Lists each account tied to a given account class
  • Accounts can only be used once per acct-class
• acct-class-user
  • Used for account class based security
  • If user has no entries here, they have free reign over the system
  • one entry for each user and each acct-class the user is allowed access to
• bank-acct
  • Defines a specific bank
  • bank account defines account #, name, check printer and last check #
  • once a transaction belongs to a bank account, it cannot be moved
• cash-acct
  • Lists accounts that represent cash balances
  • Each cash account is tied to a bank account
  • Many cash accounts can be tied to a single bank account
  • Only one bank account per cash account
  • cash accounts have related AP and AR accounts used for 'interim' amounts
  • Interims are usually unprint disbursements, undeposited receipts and open invoices (AP and AR).
• fund
  • One per fund on system
  • Defines fund purpose
  • Also controls inter-fund xfer accounts
  • Has net income & beginning balance accounts
• group-def
  • Defines accounts types (expense, liability, revenue, etc)
  • Controls account balance type (debit/credit)
  • Controls order when multiple groups appear on report
  • Can define other account types, but we don't support it
• level-desc
  • Describes names of each level (or cluster) of an account #
  • One per level, per account group (ref: group-def)
  • level len is not currently used but will be soon
• level-item
  • Describes a value for a level of a account group (for example level 2 of an expense account is 1240 - salaries)
  • Use for notating reports that support collapsing data into summary levels (trial balance, balance sheet, etc)
  • Will be the way we replace general accounts in the future
• entity
  • One place for vendors and source
  • FAS really doesn't care if a vendor or source
  • the 'is-vendor' flag is for generalizations only (no effect on which programs it can be used in)
  • Never modify figures directly
  • use do-src.p and do-vend.p to update counters
  • linked directly to ent-calendar files
  • period counters are months in fiscal year (i.e. 1 = June)
• ent-calendar
  • keeps calendar based figures for entities
  • period fields match months in year (i.e. xxx[1] = january)
• ent-class
  • Allows creation of vendor/source classes
  • Used only in entity maintenance and a few reports
  • not too exciting
• check-run
  • used to create arbitrary 'batch' numbers
  • Allows multiple runs of AP to be online at the same time without having all of them print at once
  • dates are optional
  • people just don't use this enough!!
• ap-tran/ar-tran
  • header records for transactions affecting AP/AR invoices
  • transactions affect invoices - they *are not* invoices
  • contain transaction date, vendor, PO/BO number
  • tran-deleted used to keep holes out of transaction listing
  • tran-posted just means tran can't be changed (never set this flag except via the AP/AR poster programs!!)
  • tran-num assigned when transaction is saved
  • transaction #'s assigned from protected journals (AP/ARTRAN)
  • GL summary data kept in protected GL journal (AP/ARSUMM)
• ap-line/ar-line
  • the individual account lines making up a AP/AR transaction
  • Each contains an account and a AP/AR account
  • AP/AR accounts come from cash-acct definitions only
  • Setting an AP/AR account implies the future cash-acct to be used for the invoice in disbursements/receipts
  • seq-num is 'line #' in transaction
  • All account activity auto-reflect in GL by maint
  • these lines actually never affect account balances (though they do have a role in entity balances)
  • never fiddle with these figures or accounts outside of AP/AR maint (ref summary transactions).
• invoice
  • Created by AP/AR/RC/DS maintenances
  • Can be for just tracking an 'immediate' invoice (DS/RC) or an open invoice (AP/AR) or both.
  • contains vendor, PO/BO, invoice date, discount date due date, etc
  • invoice-payable used to select payable vs. receivable invoices
  • invoice-open flag cleared when invoice amount = amount paid
• inv-line
  • created only by AP/AR maintenance
  • invoices created in DS/RC maints are immediatley paid and don't have inv-lines created
  • paid off via DS/RC maint
  • track amount on line and amount paid
• journal
  • Creation of 'journals' or related collections of GL transactions
  • protected journals cannot be worked on by a user (for FAS internal use)
  • journal track last transaction # assigned
  • transaction numbers are reset at start of new year
• gl-tran
  • header for a GL transaction
  • contains date, description and journal of a transaction
  • reversing transactions aren't too useful because they only reverse when closing/opening periods (and no one does that till end of year). Can only reverse in current fiscal year
  • summary transaction are created/maintained by other subsystems that feed into GL (i.e. DS/RC/AP/AR).
  • Users cannot create summary transactions
  • Posted transactions can't be changed. That is the only special bit about them
  • tran-num assigned directly from journal file
• gl-line
  • One line per account of the GL transaction
  • include account, description and a credit *OR* a debit (never both!!)
  • transactions *MUST* be balanced as a whole (credits == debits)
  • transactions *MUST* be balanced within each fund (credits of each fund in transaction == debits)
  • seq-num is 'line#' within transaction (cannot be holes)
• ds-tran
  • One record per transaction
  • Transaction becomes check record when printed
  • transaction header holds total amount, vendor, bank account check run and mailing address
  • tran-num assigned when saved from protected DSTRAN journal
  • GL activity stored in protected DSSUMM journal
• ds-desc
  • should be 'ds-invoice'
  • one line per invoice/PO paid
  • Used to track PO, invoice, description, amount to pay and discount
  • Invoice date and description not stored here, they are pulled and maintained from the invoice file
  • each ds-desc line refers to 1 invoice and 1 PO (optionally)
  • disc-amount/disc-applied are amount of possible discount and amount of actual discount taken
  • desc-amount is amount being paid on this line before any discount is taken. This amount is used to reduce encumberances on PO's and AP invoices.
  • desc-num is the 'line#' of the invoice in the transaction
  • desc-type indicates what type of payment

    AP - paying an AP invoice off

    PO - paying a PO off directly (i.e. not via an AP invoice)

    GL - check written write off accounts, no existing invoice or PO used.

• ds-line
  • each ds-line is an account detail
  • contains an account to debit and a cash account
  • cash accounts must be from same bank-id as in ds-tran records
  • ds-line's are associated with ds-desc via the desc-num
  • seq-num is a 'line#' within a given desc-num (so a transaction could have >1 line with seq-num 1, but they wouldn't have the same desc-num)
  • ds-line amounts are 'discounted' amounts
• rc-tran/rc-desc/rc-line
  • very similar to ds-tran/ds-desc/ds-line
  • Use RCTRAN journal for tran #'s
  • Use RCSUMM journal for GL summary transaction
  • rc-desc.receipt-type can be 'AR', 'GL' or 'BO'

    AR - receipting from an AR invoice

    BO - receipting from a bill

    GL - receipting directly to GL accounts

  • no bank-id in rc-tran, bank-ID set implicitly by each rc-line
  • a rc-tran can have cash-acct's from multiple bank-acct's
  • no discount support (not needed)
• po-group
  • Defines a PO Group
  • each PO group has a PO format, po printing module, preferences, etc
  • PO's can report to a 'master' PO group.
  • master PO groups are used to keep track of last PO # assigned
• po-tran
  • One per PO transaction/PO
  • Unapproved PO's may not encumber accounts (see fas-prof)
  • Unprinted PO's have a PO # of 'TMPxxx'
  • PO #'s are assigned when printed.
  • auto-close PO's close when they are both fully paid and all items are received.
  • PO's can't be printed until approved
  • Each PO is associated with a PO group
  • tran-num is not used (yet)
• po-desc
  • Each entry is a 'description' of an item
  • these are used for the textual portion of the PO printer
  • unit/extended prices are used based on the quantity (if quantity is 0, then only the 'extended price' is available. If quantity >0, then only unit price is editable (the extended price is computed).
  • Total of po-desc records must agree PO total
  • You don't need any po-desc records for a PO that won't be printed (i.e. tracking the PO's on the computer but typing them by hand).
• po-line
  • One entry for each account that will be charged
  • unless RC/DS-line records, these are not directly related to the po-desc record, only to the po-tran record
  • total of all lines must match PO total and total of po-desc records (if any)
  • accounts can only be used once per PO
  • a po-line will encumber the account if
    1. the PO is approved
    2. the PO is not approved, but fas-prof.always-encumber is set
  • po-lines track amount paid on each line

FAS future

• General accounts will disappear (level-items will take their place)
• replicated key value (acct-num, ent-id, bank-id, etc) will be replaced with hidden keys (allows easy renaming)
• one summary transaction per DS/RC/AP/AR transaction for easier auditing/tracking
• Interyear invoice support
• interyear PO/BO support

Last Updated on July 26, 1995