I would put forward a couple of reasons that Hu notation is not needed and why I do not use it. 1) All the names I assign within my objects (properties, methods, fields, etc.) derive there name based on what the business owners call it in the real world if there is a corelation. As a developer I can only do my job well when I also understand the real world objects that my code represents. As such a new developer must obtain some level of this knowledge for the data types to be evident. The example of AccountNumber in above posts should be understood within the logical context of your system. If I call a variable accountNumber then likely I have some idea of what that account number is within the context of my system. Hu notation will not tell me anything more than the common business knowledge will. The reality is that if I name it strAccountNumber all I know is that it is a string of some length. I would not be able to know simply from the "str" if the business rules allow special characters, if the max length was 8 characters, etc. 2) Modern IDE's virtually remove the need for Hu notation. If the declaration of a variable is not in view and the data type is not apparent based on my knowledge of the business domain then (as a .NET developer) all I have to do is hover over the variable and the type is immediate shown thanks to intellisense.

Hmmmm....(the beginning programmer thinks) "to foo or not to foo?" ;P

Wauna, There is a ton that can be said about design and architecture and there is no way to fully answer you question here. That being said, after reading your summary a few things strike me. 1) Can you identify entities on the spreadsheet that are, or can be, represented by objects? If so, then you may need to rethink your architecture to leverage those objects instead of a spreadhseet. 2) Don't tie the UI for data entry to the layout of the report. Or perhaps a better way of saying this is, don't assume that the method off data entry must mirror the report layout or vis versa. A spreadhseet may not only not lend itself to easy validation in a web app, but it may not be the most optimal form of data entry for your end users. Just a few thoughts, take 'em or leave 'em, but there they are.