Re: Table design question for exist program

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Ok I would also have the transaction number in that table as well. I would
need away to tie a particular rent to a given rent payment. Hope that makes
sense to you.

--

Joe Cilinceon


mnature wrote:
> Yes, I did misunderstand. I would suggest placing those two fields
> in a separate table, linked to the LedgerID field. The reason for
> that, is that those fields are not required for every ledger
> transaction. This way, the fields are used only when necessary.
> This also simplifies creating queries, forms and reports, since the
> ledger transactions associated with this particular table would be
> the ones that indicate paying rent.
>
> "Joe Cilinceon" wrote:
>
>> Thanks for responding mnature but I think you misunderstood what I
>> was asking. The Ledger Table is already linked to 2 other tables
>> that handle the Payments (we accept multiple payments such as a
>> single payment made by check and cash). This also uses a lookup
>> table with payment type. I also have a Charges Table that has what
>> you suggest. It also has a lookup table for it as you describe. The
>> question I have is the 2 fields in the Ledger Table called PaidFrom
>> and PaidThru. These 2 fields are used in a query that does the math
>> to find out the balance due at any given month. Now a transaction is
>> created every time we take money regardless of what it pays. So not
>> every transaction would have the 2 dates filled in. I was just
>> wondering if I should move these 2 fields to some other table or
>> just leave them there.
>>
>> --
>>
>> Joe Cilinceon
>>
>> mnature wrote:
>>> You could set up a new table, such as "Charge Type Table," which
>>> would be an itemization of what the charge applies to (such as
>>> rental, lock purchase, damage deposit, etc.). It would have a
>>> ChargeTypeID as the key, and the ChargeName (text field) where you
>>> have all the different types of charges. This would serve several
>>> purposes. It would simplify making an entry, since you could use
>>> the information in the ChargeName field as a pull-down menu, and it
>>> would also allow you to split out the different types of charges
>>> that you make during a month, making it easier to see what has been
>>> paid towards rentals. You would add the ChargeTypeID to your
>>> LedgerTable, and link the two tables in your relationship chart.
>>>
>>> "Joe Cilinceon" wrote:
>>>
>>>> I've been using a application I've developed over the last year to
>>>> run a self storage business. I'm in the process of fixing some
>>>> design flaws in the Ledger areas of the program and could use some
>>>> advise here. Please don't tell me to purchase an off the shelf
>>>> accounting package. Now with that said here is what I need. I'm
>>>> splitting one of the tables into smaller tables that will link
>>>> together. The table my question pertains too is as follows:
>>>>
>>>> LEDGER table
>>>> [LedgerID] ties record to a lease (tenant & unit)
>>>> [Transaction] unique number that ties to Table.Payments and
>>>> Table.Charges. [PaymentDate]
>>>> [PaymentAmount] total moneys collected for this transaction (we
>>>> accept split payments cash, check, credit card etc.)
>>>> .... Now the next 2 fields is what I need advise on
>>>> [PaidFrom]
>>>> [PaidThru]
>>>>
>>>> Now both the PaidFrom and PaidThru dates would be blank (Null),
>>>> unless they are paying enough to move the rent forward at least 1
>>>> full month, which in the case 90% of the time. However there are
>>>> other charges that don't effect these dates such as buying a lock
>>>> or paying a fee of some kind. I was looking for advise on how to
>>>> handle these 2 fields, either leave like they are or make still
>>>> another table with Transaction and the 2 paid fields. What would
>>>> be the advantages to this if any. Oh and this to fields are used
>>>> to base a Balance Due query on for each open account.
>>>>
>>>> --
>>>> Thanks
>>>>
>>>> Joe Cilinceon



.

Relevant Pages

  • Re: Table design question for exist program
    ... those fields are not required for every ledger transaction. ... > Payments (we accept multiple payments such as a single payment made by check ... >> have all the different types of charges. ...
    (microsoft.public.access.tablesdbdesign)
  • Re: Question about Cascade in Relationships
    ... > Well, you are deleting a transaction, but it isn't the primary Table ... Oh and the Delect cascade would be from the Ledger> Payments and Ledger> ... Charges Not from Leases> Ledger so if I'm understanding you correctly it ...
    (microsoft.public.access.gettingstarted)
  • Question about an Array in a form
    ... What I working on is a payment posting form. ... Ledger ... Transaction ...
    (microsoft.public.access.formscoding)
  • Re: A Builders Terms & Conditions
    ... The Customer accepts liability for the safe custody of materials ... collectors fees incurred in obtaining the said payment. ... 8.Interest Charges On Overdue Accounts ...
    (uk.legal)
  • A Builders Terms & Conditions
    ... The Customer accepts liability for the safe custody of materials ... collectors fees incurred in obtaining the said payment. ... 8.Interest Charges On Overdue Accounts ...
    (uk.legal)