4 Replies Latest reply on Jun 7, 2010 3:34 PM by philmodjunk

    Payment instalments - lay-by - lay-away

    james.galmont

      Title

      Payment instalments - lay-by - lay-away

      Post

      I need some help with building in a multiple payments ( or lay-by / lay-away) feature into my  ‘point-of-sale’ database.

       

      The business flow is:

      Customers buy products, but sometimes they start with a deposit then pay off the balance in installments.

       

      Currently the database follows a standard table structure:

       

      CONTACTS

      SALES

      LINE ITEMS

      PRODUCTS

       

      Currently the SALES layout includes a portal for LINE ITEMS, which displays PRODUCT details and price etc.

      Each SALE can contain multiple (different) LINE ITEMS

       

      So far that is a pretty standard set-up.

       

      But it would be great for the solution to accommodate multiple payments, which reduce the ‘Balance Owing’ accordingly.

      -Each payment would need to print a separate receipt, which reflects the original SALE (i.e. Sale Date, Product(s), Sale Total etc.) but also includes the current date, current payment amount / installment, and the updated balance owing.

       

      Any advice would be greatly appreciated.

       

      (using Filemaker 10 Adv. Mac OS 10.6.3 - intermediate FM developer)

        • 1. Re: Payment instalments - lay-by - lay-away
          LaRetta_1

          It works well to enter your payments directly into your lineitems table.  In this way, one payment can be split against multiple sales and one sale can hold multiple payments.  Your receipt would be simply printing the sale (invoice) so the customer, at any given time, can see their purchase and any payments made against it.  Lineitems would also hold any credits or discounts.

          • 2. Re: Payment instalments - lay-by - lay-away
            philmodjunk

            Another option is to record payments in a separate payments table. If you link it to contacts, you'd be able to see all payments made by a given customer. If you link it to an invoice, you can see all payments made against that invoice (and you can do both if you want.)

            • 3. Re: Payment instalments - lay-by - lay-away
              LaRetta_1

              Most accounting firms require that payments received be applied to an invoice or be returned - never applied against a customer's account.  I realize that isn't specifically what is being discussed but I mention it because it is walking a fine line.

               

              Just to be safe, all Developers designing solutions which track customer/company money or salary/payroll are wise to establish firm protections for themselves and their employer.  Personally, I think payroll should be left to payroll companies ... it is easier and they track the proper regulations and withholding.  AR, on the other hand, can be handled as long as there are clear, written (and signed-off) requirements detailing every piece (posting to GL and freezing activity,aging, late payment fees, write-offs and deposits/returns.  When Inventory is added to the mix, it is one of the most complex design tasks you can take on.  I wish you well with it.

              • 4. Re: Payment instalments - lay-by - lay-away
                philmodjunk

                I agree LaRetta,

                 

                I would use a link between a customer table and a payment register as a means for seeing aggregrate totals not for entering data. (How much does this customer owe in total over all their invoices? etc.)