Dear Vixens and Reynards:
I am going to try grids again. It occurred to me that I could
have stated things better in my previous post. I left out details
that, on further thinking, I decided I had better mention. I also
wrote of a few other minor areas, too, that I would like to address.
The App
-------
My existing app is a client billing system. The VFP version
(version 2) is about fifteen years old and going strong. I wrote it
when I knew a lot less about relational theory. Sometimes, I cringe
a bit at some of the design. It does, however, in practice, work quite well.
Boss Breaks Paradigms
---------------------
My boss has a way of breaking paradigms. I have never gotten
into a framework, because he has this way of asking for things that
though innocent-appearing can sometime require extensive
programming. (It has not happen lately, but when it does, it can be
nasty.) Since I have rolled my own for the most part, this means
that some of my code would probably be classified as downright primitive.
I do not use data sessions, binding to tables, or even a
database container.
Validation is done by the app. More on this later.
The app is single-user with provision for the master
workstation to read from and write to other workstations. (My boss
said that it would not have to be multi-user. I confirmed it with
him multiple times. He asked about it years later. Go figure.)
Complexities
------------
The invoicing is rather involved. Two central examples:
WFC:
An individual thing that can be billed is called a Work
Function Code (WFC). For a given WFC, there is not just one
rate. There is the bare rate (when no other rate applies) which
applies unless overridden. A client may have a client WFC, and there
can be contract WFCs (which override the client WFC) for certain
types of work for a client. Selecting the correct WFC is important.
WCC:
A client will typically have multiple work orders. How these
are selected for a given work entry is by date, client code, and Work
Classification Code (WCC). A WCC is type of work being done (e.g.
MSH: Miscellaneous Shipping & Handling, FUL: order fulfillment).
If a client starts having a lot of FUL work, we might create an
FUL work order. Any previous work entries in the time period can be
refigured and will be slotted under the new work order.
Similarly, if the FUL work order for a client were to be
deleted, the work entries can be refigured and will be slotted under
the alternative WCC for FUL (which is MSH).
Similarly, a client could have its FUL work billed twice
monthly. This involves simply adjusting the existing work order to
one-halfof the month, adding another work order for the remainder of
the month, and then refiguring.
When work orders are generated for the next month, they take
the pattern of the previous month.
We have clients of different sizes so the above dynamicness is
useful. A smaller client will be billed under only a few work
orders. A larger client will have various areas broken out into
their own work orders. None of this has any impact on the people
doing DE since this has to do with billing, not DE. For example, a
DE person can enter a FUL transaction and not need to know whether
there actually is a FUL work order or whether the entry will be under
the MSH work order.
Editing
-------
We bill 1st-15th (smaller billing) and full month (larger
billing). There are also special projects which are handled
individually. Data comes from DE in the system but also from data
imported from outside support systems. This data has to agree. The
process of reconciling this all is called "editing".
This is a major part of why I want to use grids. Prior to the
editing, transactions have been considered individually for the most
part. Now, they have to be cross-checked. (For example, a day's
orders for a client may show 23 packages prepared. If the shipping
log shows only 22, then the discrepancy has to be accounted for. It
might be that the last package was shipped the next day. It might be
that the DE person misread the production sheet.)
Editing involves scrolling through the work entries and seeing
that they agree and adjusting as necessary. Other adjustments can
also be made. For example, if there is an E-mail storm about a
certain topic, we will typically not charge for any E-mails after the
first two or three.
To edit, the operator needs to be able to see many transactions
at once. Currently, the system uses grids and does not have much
error checking. If I use grids instead, I want full error checking.
Browses
-------
See also Editing.
There are close to 30 browses. Few have error checking. This
is fairly safe since only people doing billing have occasion to go
into browse. Nonetheless, this is a weak part of the system.
Validation
----------
1) Validation is done at the app level. I do not use a database
container. This had advantages earlier because of data being taken
offsite, but I am willing to change this.
*** If validation in grids working depends on using a DBC, I
need to know this. ***
I would prefer to get all of my validation in one place, but
there is the problem of the user interface. As I see it, I would
still have to duplicate my validation. Is there a fairly easy
solution? My form validation code is fairly standardised so changing
it wholesale might not be the problem it might be. If I do redo
validation handling, I would like the validation to not be
duplicated. (My forms should be able to pick up the error on each field.)
2) Validation is at the field level and the row level. Any new
validation scheme must respect this.
3) Validation is using .valid(). I would like to change this to
.LostFocus(). What are the ins and outs?
Not Totally Relational
----------------------
I wanted uniqueness for all keys, but I got overridden by my
boss. Two main tables are not unique for all key. They do have
chunks. These chunks are processed that way. I doubt I can change
things at this point without lots of violence to the system. I do
not think it is worth it.
Closing
-------
I hope that I have not buried you and that I have not left out
anything critical. In summary, this system "just growed" in some
respects, is mature and works, but could stand some work.
This system has to continue operating as changes are made. I
am currently only working ten hours per week on this. This means
that changes should be gradual or at the least, not interfere with
use until they are finally activated. (My boss might ask for a
change while I am in the middle of these changes, and I need to be
able to accommodate this.)
Your thoughts?
Sincerely,
Gene Wirchenko
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message: http://leafe.com/archives/byMID/profox/
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
