Yes, what you show is exactly what we would like to do.

As you know we have been storing these different hour types as columns in a transaction table. That practice made me think of them as attributes of an object, which they really aren't. In reality they are more like detail lines in an invoice. A big difference. Proof that semantics affect the way you think about reality !

Thank you for helping me think this through.

Alex

>Off the top of my head and again with little understanding of the application:
>

>Table: HoursType
>Id   Type
>1    Sunday regular
>2    Sunday day OT
>3    Sunday night OT
>
>Table: Hours
>Id   EmployeeId   HoursTypeId   Hours   Income
>1    12           1             8.00    40.00
>2    12           2             0.75     7.50
>3    43           1             4.50    25.00 
>

>
>The HoursType table has columns that affect the business logic but without a better understanding of that, I don't know what that would be.
>
>I think you're going about this backwards. Define the Ux for the functionality first. What the data looks like behind that is secondary.
>
>>Hi Craig, Sorry for this long post, which is meant to clarify the previous one.
>>
>>1) Here is a description of a transaction table that we use in our VFP product. Below I explain how we want to do it differently in the new project.
>>* Beside ID, foreign keys, and other such fields, the transaction table has many fields of two general types: hours worked and income received.
>>* The hours worked fit into different types. Just as examples: Sunday regular time, Sunday day overtime, Sunday night overtime, Sunday day overtime with surcharge1, Sunday day overtime with surcharge2, etc, etc, etc.
>>* The income types follow a similar variety of types.
>>* These income and time categories need to be kept separate because thay have many different business rules regarding how they are paid, what taxes are they subject to, do they accumulate for severance, and a long etcetera.
>>* Here is the description of our current transaction table, just to show the immense number of fields that it has, and that continue increasing
>>CREATE TABLE pling FREE (FREE (NPLA N(5,0),NTRA N(8,0),CCODEMP C(6),CCODSUC C(3),CCODDEP C(6),CCODDIV C(6),CCODHOR C(6),CCODCCO C(6),CCODPRO C(8),CCODSPR C(10),NORDENPLA N(5,0),NSALHORA N(10,6),NSALHORA1 N(10,6),NCOMISHORA N(10,6),NHR N(6,2),NHRFER N(6,2),NHRDOM N(6,2),NHRDOMREG N(6,2),NHRJORMIX N(6,2),NHRJORNOC N(6,2),NHRDIALIB N(6,2),NHSD N(6,2),NHSM N(6,2),NHSN N(6,2),NHSDR N(6,2),NHSMR N(6,2),NHSNR N(6,2),NHSDD N(6,2),NHSMD N(6,2),NHSND N(6,2),NHSDDR N(6,2),NHSMDR N(6,2),NHSNDR N(6,2),NHSDF N(6,2),NHSMF N(6,2),NHSNF N(6,2),NHSDFR N(6,2),NHSMFR N(6,2),NHSNFR N(6,2),NHSOBACUM N(5,2),NHTP N(5,2),NHTNP N(5,2),NHAJ N(6,2),NHANJ N(6,2),NHCM N(6,2),NHCMDISPON N(6,2),NDIFREDOND N(4,2),NHAJUSTE N(6,2),NSALHAJUST N(8,2),NTHORASREG N(6,2),NTHORASST N(6,2),NSALREG N(8,2),NSALSOB N(8,2),NCOMIS N(8,2),NBONO N(8,2),NBONO2 N(8,2),NBONO3 N(8,2),NBONO4 N(8,2),NBONO5 N(8,2),NBONIF N(10,2),NGRATIF N(10,2),NNAVIDAD N(10,2),NOTROSING N(8,2),NOTROSIN2 N(8,2),NOTROSIN3 N(8,2),NOTROSINX N(8,2),NLICMAT N(8,2),NLICRP N(8,2),NLICENF N(8,2),NBONOXIII N(8,2),NAJUSTE N(8,2),NSALBRU N(8,2),NTACUVAC N(10,2),NVAC N(8,2),NDIASVAC N(3,0),NTACUXIII N(8,2),NPACUXIII N(8,2),NXIII N(8,2),NPARTIC N(10,2),NINDEM N(10,2),NINDEMREC N(10,2),NPRIMA N(10,2),N6PORC N(8,2),NPREAVISO N(8,2),NBONOASIS N(8,2),NTRANSP N(8,2),NVIATICO N(8,2),NTACUGRVAC N(8,2),NTACUGRXII N(8,2),NPACUGRXII N(8,2),NGASTOREP N(8,2),NGRVAC N(8,2),NGRXIII N(8,2),NOTROSGTO N(8,2),NOTROSGT2 N(8,2),NOTROSGT3 N(8,2),NOTROSGT4 N(8,2),NOTROSGT5 N(8,2),NADELANTO N(8,2),NTNOGRAV N(8,2),NTPAGSS N(8,2),NSS N(8,2),NTPAGSE N(8,2),NSE N(8,2),NTPAGISR N(10,2),CMETODOISR C(1),NISRFIJO N(8,2),NISRADIC N(8,2),NISR N(8,2),NTPAGRP N(8,2),NSALNETO N(8,2),LDESCONTAR L,NDEDUCC N(1,0),NTFONJUB N(8,2),NTFONCES N(8,2),NTDED N(8,2),NTDEDLEGA N(8,2),NTNETO N(8,2),CPERIODO C(6),NESPECIE1 N(8,2),NESPECIE2 N(8,2),NESPECIE3 N(8,2),NESPCOMB N(8,2),NDIETA N(8,2),CMETCAPHRS C(15),LCALCAT L,LIMPORTAR L,LCALCULOS L,LPOSTEADO L,LCHEQUEIMP L,LEFECTIVO L,CFORMAPAGO C(1),LCANCELADA L,NEXTRA0 N(10,2),NEXTRA1 N(10,2),NEXTRA2 N(10,2),NEXTRA3 N(10,2),NEXTRA4 N(10,2),NEXTRA5 N(10,2),NEXTRA6 N(10,2),NEXTRA7 N(10,2),NEXTRA8 N(10,2),NEXTRA9 N(10,2),CSTATUS C(3),CSEMAFING C(8),LGRVACPISR L,LGRVACPSS L,LGRVACPSE L,LGRXIIIPIS L,LGRXIIIPSS L,NTGASGRAV N(8,2),NTNOGRAV2 N(8,2),NTPAGSSXII N(9,2),NDONAC N(8,2))
>>
>>2) I want to replace this structure by just a few tables:
>>Table pling with fields global to the transaction
>>Table pling_detail, an Entity-Attribute-Value table with a record for each non zero money or time value
>>Table Attributes, a table that describes all possible attribute types, with the corresponding business rules
>>
>>3) At run time I would like all values related to the transaction to appear as fields in a view or as properties of a BusinessObject
>>I'd like the framework to facilitate this arrangement so it would be trivial to add a new time or income field
>>If the new app were written in VFP I could write the necessary code, but since it will be unfamiliar language I'm looking for help from the framework
>>
>>I don't know is the problem is is any clearer now.
>>
>>Thanks for the help.
>>
>>Alex
>>