Set Design Question

[jwolfe11]

I've been trying to accomplish something for the last few weeks and I've finally given up.

I am creating a payment routine with the following design:

Payment_header
||
=====>Invoice_header
||
=======>Payment_details

What I am trying to accomplish is the following:

A form where the customer can input the Payment Header such as customer name, check #, amount of payment, etc...

Once the customer name is input the browse would populate with invoices that are still a receivable. I want a field in that browse where you can apply the payment.

I attached a screen shot from Quickbooks that does this (not plagiarizing). My form doesn't look like this but this is what I'd like to accomplish. Does anyone have any ideas?

[forskare]

Re: Set Design Question

Jeffrey,

It sounds like you have fields in the Payment Header that should be in another table. Whenever I am in a quandary about design, I look a AlphaSports or one of the other examples which Alpha has generously provided. In AlphaSports you will see what you want to do or something very similar.

Another option for you is to list the tables and the fields. It is important to have certain fields in certain tables.

kenn

[Al Buchholz]

Re: Set Design Question

Duplicating functionality like QuickBooks can be difficult.

Either the set design needs to be appropriate, or you may need to build an xdialog and control more of the processing rather than using the normal Alpha model.

In this case, the set might be more appropriate to be:

payment_header
===>
Invoice_header
---->
payment_details.. (there is only one payment record added per invoice...) and you are only adding a payment_detail record....

I haven't duplicated QB's processing but have done somethings close to it....

Have fun and good luck...

[MoGrace]

Re: Set Design Question

I tried this too, but the QB embedded browse is not like the Alpha browse. If you notice when you view an old payment record you can still see the invoices that were paid at that time. So it seems to be a combination of tables where only currently unpaid invoices and the selected invoices will appear there. A flag may be controlling the current unpaid invoices, but how they get what is perhaps a 2nd temp table to appear with them is a mystery.

Addendum:
You could use 2 browses and select the unpaid invoices from one then use a button script to copy them to another table that links only to this payment.
And if the payment record is unselected, then it could undo the action and change the flag in the first table to show it again. Hmmm...now I want to try it out.

[Peter.Greulich]

Re: Set Design Question

I do something similar to Al, but slightly different:

payment_header
===>
payment_details
---->
Invoice_header

The payment_details + Invoice_header are a view in a grid (or could be a browse). The payment_details has a lookup field for the invoice_no which links to the Invoice_header table. The idea is that a payment may cover more than one invoice.

You could also do something different, where the child invoices are automatically filtered on the customer name/id, where balance>0.