Conference acadmy::tpas_notes

Could you give me some more information on SPEEDWAY and VDD please.  What are
these products ?  Do we need to install these products separately from the 
rest of the kits?   Is there any documentation on them?

VDD is VAX Data Distributor. This tool may be used in the software
to update the RDB data bases from the EWIS organization to the Site. We are
currently testing the use of VDD vs RMU/Load-Unload and comparing the 
difference in response and CPU time. The size of the databases being 
transfered to sites will be small and may not warrent the added overhead of 
VDD. Once the figures are in the final decision will be made as to which way
to distribute the databases.

As for Speedway, this is a client/server product that is used as the basis 
for the EWIS PPCS (Part and Product Client Server) software. You will not
need to install Speedway, but you will need to install the PPCS software
if your site chooses to have the option of using Client/Server to the APPIX
database. This installation takes approximately 5 minutes, 2500 blocks for
installation and 500 blocks after installation.

You should have received, or seen in note 14, the information regarding
how to obtain both the PPCS software as well as the AMP2 feed.

    1. PART NOT ON APPIX
    --------------------
    
    Ayr may possibly have parts on their local database that do not yet
    appear on Appix. Some European specific parts, for example, may be
    updated locally to support receipts/shipments of new products, but the
    process of getting the product details from Product Management in
    Europe to Appix via the relevant Engineering group in the US can be
    time consuming. We then have a timing gap and may ship new product not
    on Appix.
    
    We therefore need the facility to allow us to look-up the LOCAL
    database for std.cost, MLP, part type, etc. for parts NOT FOUND in
    Appix, prior to running the TPAS logic.
    
                                                       Regards,
    
                                                       Alan Martin (AYO) 

    PRICING LOGIC : DEFAULT FOR EXCEPTIONS
    --------------------------------------
    
    Although it is expected that the Corporate TPAS Database will contain
    the pricing calculation for ALL part-class/part-type combinations
    (where no MLP is available), there may still be circumstances where a
    part-class/part type string is not catered for in this logic.
    
    According to the functional spec, a "pricing-discount omission table"
    will be updated manually for parts in this category, and a mail message
    sent to Corporate Tax showing the modifications made.
    
    The assumption here is that the person entering the part number into
    TPAS will be able to modify the tables to allow a rogue part to be
    priced , after it has been rejected.
    
    This person, however, will NOT have the necessary background to make
    this fix, and in any case Corporate Tax would need to ratify any
    changes prior to including it in the TPAS logic.
    
    We would much rather have the opportunity for the pricing logic to call
    some form of DEFAULT LOGIC that would use a simple algorithm to price
    parts in this category and allow estimated prices to be established and
    invoiced. This default logic could be locally developed, but it would
    be more appropriate for it to be consistent company-wide.
    
    An example of this simplified logic would be :
    
    If Part-Class = 13 thru 17 use Std Cost.
    If Part-Class = 50 thru 70 use Std Cost x 3.
    .... Etc.
    
    All others use Std. x 4.
    
    If these estimates were flagged on a daily exception report, we could
    make the necessary manual adjustments to the resultant billings later,
    once the correct pricing logic was established via Corporate Tax.
    
                                                            Regards,
    
                                                          Alan Martin (AYO)
    

I have the following questions regarding the TPAS module:

1. In case of an error, will the error code that is returned by TPAS indicate
   what type of error has occurred (e.g. 'Part not found on AMPS2') ?

2. The documentation states that

	* VDD is used for the monthly update of the site
	  TPAS tables 
	* The site itself should start this process.

  I thought that VDD was purely a 'push' mechanism to update a target Rdb
  database. How will this be done?
  Furthermore, will the pure changes to the tables be available in a structured
  format?

Regars,

Eric.
    

The Price Type Indicator mentioned in the Functional Spec. as output from TPAS 
is no longer included as an output field of the TPAS_CALC_TRNSFR_PRC Process in
the Functional Design.  Is this no longer being provided by TPAS?

                                  Regards 
                                      Christine McLaughlan (AYO IM&T)

    Hello Alan,
    
    Confirming our discussion earlier this week with you and the European
    Product Reference folks, whereever possible we would like to try to
    determine what missing part numbers are based on addressable sourcing 
    problems versus what set of missing part numbers are based on previous 
    business decisions not to add these parts to APPIX and whether or not
    these decisions bear review.  
    
    In our discussions, we talked about parts that were delayed but would 
    ultimately be placed on APPIX (a timing impact) as well as parts 
    that would ultimately be placed on APPIX but would have no MLP 
    since APPIX currently has no MLP feed from Europe for European 
    only parts. (APPIX receives only MLP from DSPS.) We also talked
    about parts that never make it to APPIX.  
    
    Clearly, the first two problems require different resolutions.  In
    the first case, we agreed that this is a business issue within Europe
    as it is the European approval process involved here.  I believe that
    the European Product Info Center (EPIC) are the appropriate folks to
    work this with as well as the Chief Engineer's office. We certainly
    rely on them as well as the plants to help us understand and work
    product reference issues, TPAS and otherwise.   I believe EPIC
    and CEO's office (the ultimate source for part number issuance) are 
    in close contact and are addressing part of the issue now.  EPIC also
    supports the process followed to get approval for European part numers
    before they can be added to MIFBOM, one of the primary part number
    reference files in Europe.  
    
    In addition, EPIC has spent considerable time working with the relavent 
    European Part Number sourcing groups, outlining the new rules EMPRS, 
    the new European Product Reference System, will follow relative to 
    adding parts and handling standard cost and MLP for these groups, 
    e.g., EIC's, TREG, ILO, part class E0, European Special Part Numbers 
    (ESPN's)... EMPRS has a target readiness date for the new fiscal year.
    We are looking into how and under what conditions would it makes sense
    to employ those rules within the APPIX environment and expect to
    continue these discussions with EPIC and the appropriate business
    groups until we have come to closure. 
    
    The issue which we feel requires immediate attention and understanding
    on our part are those part numbers which TREG currently, and ILO in
    the future, have determined must always have an MLP and/or standard
    cost different from the values provided by corporate sources. TPAS's
    current design would not accommodate these numbers.  We anticipate
    working closely with FYO and ILO to understand the issues and options
    involved here.
    
    Additionally, TAX is addressing a potential default processing for 
    missing parts.
    
    It's also worth noting that TPAS #2 will have additional part number 
    issues as we begin to evaluate how to deal, for instance, with part
    numbers created in the subs for customer shipments to facilitate
    special part packaging.
    
    So, all in all, there has been considerable activity in the missing
    part area.  We will continue to work on an acceptable resolution. Our 
    concern is that we all agree to the options which allow the sites to 
    ship orders on time, but with a predictable (and reproduceable!) 
    base and transfer price. 
    
    I'm sorry I cannot give you a more difinitive answer, but we have not
    completed our discussion yet.
    
    If others have additional information to share, we would appreciate
    your response to this reply.
    
    Margaret Rosene
    
                   

    
    
    
    Hello,
    
       I hope I have put this note in the right place.
    
       My question is :
        How does the user input to  the discount /pricing exception table?
        Through SQL??  This means user got to learn how to use SQL. 
        Or is there other way ??
        
    
    Rgds,
     Yan Noi
    
    
    

Yan Noi,

The XCLDD module will take care of the updating front end for the 
TPAS$XCLDD_DB. You will find it in the kit. We are still working
on the documentation. This will be done when the final testing of 
the module is done. In the mean time - if your logicals are set 
correctly, then by running TPAS$ROOT:[EXE]TPAS_XCLDD you can add 
records to TPAS$XCLDD_DB via DECforms. There is help available in the 
DECforms screens to assist the users in entering correct data.

So no knowledge of SQL is needed.
Regards,
Lois

    Rosene/Lois,
    
    We are wondering why parts which have not been found in the AMPS2 satelite
    file will force the TPAS logic to exit. We expected that in case of a
    part not found, the local get part would be used to provide the part
    information needed to get a transfer price calculated by TPAS logic
    rulings.  
    
    The PARTNOF error was not described on the list of TPAS error messages.
    Could you please provide us with an up to date TPAS error listing?
    
    Regards Rinus

Rinus,

  The business (Corporate Tax abd Finance) decided in the functional
  design that if the part was not found on the APPIX Master Parts file then
  the product should not be shipping via TPAS. That is why the big drive for 
  reconcilliation. I will let Margaret, Eammon and Barbara Willfand (Corp Tax)
  answer in more detail as to why the business choose this route. 

  As for the error listing -  The complete listing can be found in the
  back of the TPAS_USER_DOC.PS. This is included in the V1.0 kit as well
  as able to be pull from AWARD::TPAS$PUBLIC:TPAS_USER_DOC.PS

Lois