1 Reply Latest reply on Oct 4, 2012 12:34 PM by mikebeargie

    Filemaker and Bookkeeping


      Dear all


      Im building database with an finance part.

      it will include accounting income and outcome, as well as expense planing (expected income

      and expected expenditure)

      It is also needed to correlate planing transaction with the real one. Im suspecting situation,

      when expected income will be splited into several payments.

      System should help my customer to shift expected outcomes to keep shaky finance balance.

      I hope, that some of you had faced similar questions .

      Im realizing that my questions is quite global, but any thoughts and advices are wellcome!


      My questions is:


      - should I use one table to expected and real transactions and just use flag of it adoption, or better to separate planing payments with real ones ?

      - how to correlate one expected income with several payments ?

      - I heard about good practice to duplicate records (for example all records in one table and separate table for debit and credit for double audit) What is your thoughts ?

      - may be you have good links to web sites or forum or may be books, that describes possible architecture solutions, based on FileMaker similar to my needs ?

      (plz excuse for my English)

        • 1. Re: Filemaker and Bookkeeping

          I've had some experience with this kind of stuff. Normally the answers to your questions are decided by the accountant that is involved with the system.


          In my systems:

          1) Only real transactions are stored in a transactions table, if there is a queue or temp table, it is a copy and has "make real transaction" scripts to copy it over when it turns into a real transaction.


          2) Usually several payments corresponding to one item indicates some sort of Invoice. IE I have an InvoiceID that has been paid with PaymentID from three transactions. Invoices are in their own table and Payments are in their own table.


          3) Another thing you need to consider is conditional record locking. Most accountants will want a way to "close" out a set of transactions so they can not be modified by anyone in the system. If you have record locking, usually accountants do not need a separate table for auditing.


          Some other tips:

          -Make sure to have creation timestamp/account and modification timestamp/account fields that can not be edited for security purposes.

          -Make sure your server/host has a backup strategy that meets your (or your clients') needs.

          -Check out some "finance" verticals on the filemaker site: