Month plus format

[BobNTN]

So if I open say, the customer form thru a button, the user closes/exits by way of the 'Red X', it won't necessarily close and go back to the form with the button ?

 

[pbaldy]

Generally focus would go back to the form that opened it. Bob's point was that the original form will not close itself just because you opened another. You can have any number of forms open simultaneously.

 

[boblarson]

Sometimes, depending on the situation, I will open a lot of forms in dialog mode so that you cannot move off of it until closed. In that case you can force going to a certain form if you open each as acDialog and then it will need to be closed by the person in the order in which they were opened.

 

[BobNTN]

Cool
Thanks, both of you.

I'm just about there with this db.

I still haven't quite figured out how I'm going to do the Pastdue and Balance. My sister said she has customers calling all the time asking their balance, etc.
So that puts me back to thinking of adjusting 'on the fly' when each check is input, but that involves more code than I want to do.

There are no examples of 'how' that I can find to help decide.

 

[burrcm]

Glad it's working. I used [MyDate] as the date reference rather than Date() just so you could specify a particular date in the [MyDate] textbox and prepare the accounts - say you wanted to get ahead and prepare some for the following period, but if automatic is good for you, then all is well.

Chris B

 

[pbaldy]

I've got a couple of AR applications and an inventory application. I do not try to store balance, past due, quantity on hand, etc. I calculate them on the fly. Aged receivables (30-60-90 days), account balances, etc can all be calculated from transactions. In your case, if they call asking for balances all the time I'd create a query that calculated the balance by customer, and base a form or report on it. You can restrict it to the one customer that's calling with the wherecondition argument of OpenForm.

 

[BobNTN]

That's pretty much what I had intended to do based on your previous advice.
Then I remembered that I had also planned to do a routine to purge payment data past 18 months or so, since, in her present DOS program, that is the table that grows so much and fast.
But on the other hand, the payments table in this app will only have 3 fields so it really shouldn't grow in such a way. Huh ?
If so, I will stay with figuring out the queries.

 

[klynch0803]

By reading all your notes and comments it doesnt sound like the table you are discussing will grow very quickly at all. Also historical data is great for business trends etc.

 

[pbaldy]

I'd probably still go the same way. If you decide to purge data, you could create a balance forward type entry. For instance, if you were going to purge 2007, create an entry on 1/1/08 that was the sum of activity previous to that date, then purge the data. That way your queries all still work; you just lose aging and specific transaction detail (which is what would keep me from purging unless it was really necessary).

 

[BobNTN]

I agree. If 3 fields of about 12000 inputs a year doesn't grow drastically, I'll stay with the queries.

Now, the process of that I'm stressing with.
I figure Pastdue is the balance minus the check amount until the balance is debited with the monthly charge. Then the balance is the balance but the Pastdue is what it was before the debit and will have to be cleared when a payment is received and also applied to the balance. But wait. Pastdue doesn't exist until after the due date!
But the good thing is all are due on the 15th of the month and I won't debit the accounts until prior to printing invoices.

You see what I'm getting a headache over.
If I get all the PD, Due, debit, and Bal figured out, this baby is almost finished except a few minor tweakings.