The JE Header with Details form requires a form that can maintain Parent and Child records; the place to start is to create a "base class" that can handle this type of setup ... eg. maintain parent and child records; perform a cascading delete; sum child to parent.

The Parent-Child form is used in a lot of situations: Purchase Order, Sales Order, Work Order, ...

Once you have a Parent-Child form, subclass that form to make it application specific ... different input controls, validation rules, ... and supplying properties such as parent table name, child table name, relation, etc.

In the case of the JE forms, the General Journal is the most basic; the GJ could subclass the basic parent-child form, and then the GJ could form the basis for the other JE types (AR, AP, Cash Receipts, Cash Payments, Fixed Asset Journal, etc).

In summary, once you have created a General Journal form, any extra code (and controls) that might be required to support another type of Journal should be put into a new (sub)class.

In the end, you wind up with some 5 "physical" forms that are all going against the same "JE Document" tables; the forms simply have their own "view" (or filter) based on document type ("AR", "AP", etc).

In general, Users usually input "batches" of each Journal type at any given time (based on responsibility) and appreciate JE forms that are tailored to the task at hand instead of having one "super form".

>I agree with your statements and had decided on a similar layout of header and detail records for GL transactions as the most appropriate method of doing the work.
>
>I really like your idea of the "Journal Entry Class" with subclasses. I had not thought of it, but I am going to work on that! Have you created such a class? Any suggestions?