BurtWilkins.jpg

Burton Wilkins is a Key 

.Net Programmer / Analyst

Spinkey.gif (42892 bytes)

PaladinSide.gif (20149 bytes)


Prior      Home

Accounts Payable (May 79 - Jan 92)

ftpanim.gif (2907 bytes)

ap.gif (390691 bytes)

This Accounts Payable system was one of a series of legacy systems created by Burton Wilkins while he owned and operated B&W Computer, Ltd. in Ottawa, Canada.   This system was sold as a turnkey systems, packaged with other standard systems of Mr. Wilkins creation to clients along with customized programming for their company's specific needs.   Beyond the initial sale, Mr. Wilkins maintained and updated these systems year by year at his hourly rate, and continued to offer customized programming to his established customer base.  

Features

This turnkey system provided for the following business features:

  • Accounts Payable Entry, A/P Check Writing, Manual or Direct Check writing, Printing and Register, Recurring Payment Processing.
  • Interactive Turnkey data base system.
  • Multi-terminal time-sharing support.
  • Limitless capacity:  Supported one to 10,000 companies, and a million A/P Transactions.
  • Checks for all companies were written on a common bank account.  Funds to cover each companies' checks were transferred to this bank account.  Consequently, only one set of check forms was required, and only one bank account had to be reconciled, instead of many, each month.
  • Check-writing update A/P instantly.
  • Data files never needed reorganization.
  • Direct interfacing to B&W General Ledger.

Menu Options

  • Accounts Payable Entry:  A/P entries directly updated G/L with up to a thousand distributions.  A/P entries were postable to current, or next G/L period.  Beyond invoice number, A/P entries consisted of an invoice date, amount, optional discount, and due date.
  • Print A/P Edit Report.
  • Edit-Print-Cancel A/P Entries:  Used to call up A/P entries.  It had an option to printout A/P entries and its G/L Distributions, change A/P entry's due date, and cancel or reverse an entry.
  • Print A/P Post Report.
  • A/P Vendor Aging:  A/P entries were aged based upon due date:  30, 60, 90+ days or whatever the user entered.  The aging optionally included detail, or vendor summary balances.
  • A/P Company-Vendor Aging:  This aging was the same as the previous aging, but with the ability to specify a range of companies.
  • A/P Automatic Debit Application:  This option would apply unapplied debit memos within a range of vendors against the oldest POs, or where the debit memo and the PO amount were equal.
  • A/P Cash Requirements List:  This report would produce a list of those vendors and POs that were due for payment, minus any discounts that were still due.  This process was especially mindful never to miss a discount, but if there was no discount or if the discount was past then to only pay POs at the very maximum days possible under each vendor's unique terms.
  • A/P Auto-Pay:  This process followed the same logic as the preceding A/P Cash Requirements List. Only that in this case instead of creating a report. this process actually made check entries according to the parameters entered as if they had otherwise been made by Checkbook Entries.   For companies which received vendor discounts, this process alone produced such income from discounts that in some companies it's savings paid the salaries of the entire office staff.    Having an automatic check writing process as this, reduced Accounts Payable office staff drastically.
  • Checkbook Entries:  The user could either enter an existing vendor number, or manually enter a vendor name and address for check payment.  If a check number was entered, the process concluded that a manual check was already drafted and no physical check was to  be thereafter generated.  If no check number was entered, the process concluded that no prior manual check had been created, later issued check a check number, and would print the check.   The process enabled the entry of interest to a vendor to be added  to the A/P check, or discounts taken.
  • Check Edit Report:  The report optionally displayed to the screen or to the printer, showing check distributions.  Up to 7 check entries would be batched for the same vendor if in the same currency.  Pre-written checks were not batched.  A preliminary check register was produced sequenced by company, vendor, and then check.
  • Cancel Pre-Posted Checks:  Any check found on the Check Edit Report could be cancelled (erased), prior to check printing.
  • Post and Print Checks:  This process would first print a Check Register similar to the Check Edit Report.  Next, the process would print an A/P Deposit Report highlighting total checks drafted by company.  Last, the process would print check entries, if warranted, on checks.  Each company had its own check numbers issued sequentially.
  • Open Bank Report:  This optionally displayed to either the monitor or printer for company range detailing outstanding checks and deposits.
  • Checkbook Reconciliation:  This process was used to mark off cancelled checks and bank deposit records.  If a cancelled check was in a foreign currency, the process allowed for the distribution of the exchange difference to the G/L.
  • Recurring Payment Entry:  This process stored recurring payments (Ex:  rents, leases, term payments,...) with G/L distributions for periodic check printing.
  • Recurring Payment Edit List: This report either to the monitor or the printer detailed by company, and vendor those recurring payments that were due for posting.
  • Recurring Payment Post:  Recurring payments were selectively posted to the check file, for eventual processing as checks.
  • Vendor File Maintenance:   This maintenance enabled users to add, change, or delete vendors to the vendor file.  Fields provided for included check printing and purchase order name, address, city, state.  Additional fields allowed for phone number, contact, minimum days to pay A/P,  maximum days to pay A/P, vendor currency, discount percent, minimum PO weight, and cancellation lead time.
  • Numeric Vendor Report:   Vendor keys were numbers.   This report either to the monitor or to the printer displayed vendor names and addresses in numeric order.
  • Alpha Vendor Report:  If the user was unsure of the vendor's number, finding that vendor in a numerically ordered report was tedious.   This report was ordered alphabetically by the vendor's name.
  • Vendor Label Print.
  • Post Receiving Cost Adjustments:  This process was included only with installations using the B&W Purchase Order system.  When items were received on a P/O, an A/P entry was created using current costs.   Sometimes such costs were not accurate, or there were additional costs, and usually the relevant invoice didn't arrive until after receiving.   The process allowed the user to update an A/P entry, distribute additional costs among inventory items to keep "FIFO" accurate, and sent those additional costs to the G/L.

Requirements

This software system required the following:

  • Hardware:                            IBM 486 PC or clone, or Digital VAX.
  • Operating System:             MS-DOS, VAX-VMS, or TSX-32.
  • Prerequisite Systems:       B&W General Ledger system,  B&W Power Pack system.

This turnkey system was written as a package  in Dibol / DBL.


 
When you need a gun, what programmer do you call?  Burton Wilkins, "Have Gun - Will Travel"  Send mail to burton_wilkins@classicclasses.com with questions or comments about this web site.