Conference iosg::all-in-1_v30

1210.0. "Design suggestions needed ASAP" by GANTRY::HULL (Digital Services Delivery - Motown) Mon Aug 10 1992 20:10

My customer, Ford Motor, has an electronic Travel Expense Form that was coded 
by Digital about 4 years ago.  The TER form is a 2-screen 132-col FMS form set 
with almost the 255 field limit on it.  The application uses a custom DSAB 
called REPORT as it's data type, and each TER is actually a MAIL message.  
Action routine scripts are set up in the FORMAT record to handle editing, 
reading, printing.  Output is custom-coded Postscript with all field values 
merged into the output.

Ford has now come out with a new TER form, totally different than the old one, 
and the old one will become obsolete on Sept 15th.  No old forms will be 
accepted after that.

The unique DSAB implemented in V1 is neat, but it creates support and 
upgradability major issues later on (like now!).  The ability to mail a full 
TER is a major design requirement.  The current forms also perform currency 
rate conversions (mix'n'match on all applicable fields) for something like 
8-10 different currencies.

We are trying to design a new replacement application, but the new printed 
form has over 350 fields on it.  We are looking for suggestions on how to get 
to a Version 2 here in the most reasonable way.

The two major issues we see are:

	1.  Keeping the mailable TER functionality intact.

	2.  Having a clean design that (if possible) is more easily maintained 
        without needing special DSABs, etc.

I remember the old ASSETS kit called 'MAILABLE FORMS' that was actually
quite  simple in design and was easy to implement.  The mail message body
was  actually a script that would load all the fields in the form using 
GET calls.  It required no data file at all, since the data was stored as 
script assignment statements (GET F$0001 = 'xyz').  Anyone still have that
kit  around for evaluation purposes?

I also contacted the author of the Digital EXPENSE program to see how he 
wrote that - its over 6000 lines of 3GL code using BASIC, MACRO and SMG 
calls.  Yucchhh.

My customer is leaning toward using multiple formsets mapping to the same 
datafile with different sub-keys and different record maps, keeping the record 
lengths identical, etc.

We would welcome any suggestions from the rest of the A1 application-writing 
community.  We have to start work ASAP on this to meet the deadline.

Regards,

	Al

    Al,
    
    Having a soft spot in my heart (and head?) for FMCC after dedicating 2+
    years of my life there, thought I would lay out a thought.  Are they
    really set on using this new TER form?  Would they perhaps consider the
    ALL-IN-1 Travel/Authorization/Expense subsystem?  To find out more
    about that system, please contact Mary Raczkowski @ DTN 264-3753 (MKO).
    
    fwiw
    Jon

Hi Jon -

To begin with, this is a different Ford site - about 1 mi south of FMCC -
its the Electronics Lab Division where the Electronic Engine Controls are
designed.  Anyway...

We don't have the luxury of having them change their mind - this is a Ford
corporate-wide paper form that "was reviewed by over 30 committees" etc etc
to meet all needs.  Our application has nothing to do with them - we just
have had an electronic version of the TER for a long time as a convenience
to users.

Keep those ideas flowing, though!!

Regards,
	Al

    
    Al,
    
    The ASSET 'MAILABLE FORMS' was created for ALL-IN-1 V2.2. I think there
    might have been a version for V2.3, but I'm not sure. It never was
    updated (made available) for V2.4. It's also not available from the
    European ASSETS library any longer.
    
    However, you might want to contact EADC::MAINTAINER and ask them, as
    (according to very reliable sources here) the package might be on a
    backup tape.
    
    Ciao,
    
    	Simon

    'Used to be in v2.3 /v2.4 days that you could exceed the 255 field 
    limitation by not compliling the forms (can you spell S__L__O__W ?)
    I assume the workaround still can be done with v3.0.
    
    If you have to - you have to.  Create a separate forms lib and just 
    put that formset into it alone.  Compile the rest of your forms in the
    other form libs as normal.  The users just might be able to live with it.  
    I have old notes in previous conferences regarding this very same 
    problem - if you care to search for them.  Best of luck...
                                                                        Rick