Conference acadmy::tpas_notes

    I don't have any answers to your questions but I would also like to
    know them
    since Ayr are currently doing the programming for TPAS.

    Another point I would like to make is that the Part Number which is passed
    to the Local Get Part should be the same one that was input to TPAS
    rather than the DEC Standard 12 Formatted part.  I see the process as:

     1.MAXCIM Format of Part Number passed to TPAS

     2.Part Number converted through DECSTD 12 Parser Software

     3.Call TPAS_GET_PART with DEC STD 12 Format part as input and if
       failure call TPAS_GET_XCPTN_PART and local code passing MAXCIM Format of
       Part Number as input.

    In Ayr I believe the MAXCIM Format to be the Unaligned Part which is
    produced by the Parser so this could possibly be used as input to
    TPAS_GET_XCPTN_PART but using the original Part Number entered would ensure
    that we had the right one.

    Is this acceptable to the TPAS team and other Implementation Sites?

                                Regards
                                     Christine McLaughlan (AYO IM&T)

>    Another point I would like to make is that the Part Number which is passed
>    to the Local Get Part should be the same one that was input to TPAS
>    rather than the DEC Standard 12 Formatted part.

    I fully support this statement!

Regards,
    Andr� van 't Hoog (F&D IS, JGO)

The physical design document for the 'logi module' piece of the code 
has been released and is in TPAS$PUBLIC. This document should answer your
questions.

re: .0 -> The TPAS_GET_XCPTN code was remove from the functional design 
	  by the TPAS businees people here in Corp. Instead the parts
	  must be on APPIX. If the part on APPIX has a zero standard cost
	  the TPAS code will call to a local code to obtain the local
	  standard cost.

re: .1/.2 ->  The call to the local code, now TPAS_GET_LOCAL_COST, will
	  send the part number as received by the sites program. It will not
	  send the local code the parsed part number. 

    
    The Physical Design document specifies the TPAS_GET_LOCAL_COST should
    open the local file, get thencost and then close the file for each part
    number passed to it.  
    
    The time taken to do this for each part number could be quite a while
    especially if the client server is down and this module is called for
    all part numbers.
    
    Therefore, we are considering opening the local file (INCMS) in our
    top level module which calls TPAS which will open and close INCMS only
    once.
    
    Any comments around this suggestion!
    
    
    Regards
    Josephine (7823 3162)
                                 

Josephine,

   The TPAS_GET_LOCAL_COST will only be called if the part IS found
   on APPIX (via Client/server) or AMP2 (local APPIX file) AND is
   using standard cost to calculate the transfer price AND the APPIX/AMP2
   record has a standard cost of zero. 

   If the part is not found on APPIX or AMP2 the TPAS_CALC_TRNSFR_PRC
   returns a fatal error to the calling program.

   In TPAS_GET_LOCAL_COST, however you want to deal with opening and
   closing you data files is fine. The only this the TPAS_ZSC_PART cares
   about is the return of a standard cost.

Lois

    I have another question about TPAS_GET_LOCAL_COST. If it can't find the
    part number in the local parts file, should it return a standard cost
    of zero or is it possible to return something in the fields PART_NUMBER
    or STD_COST indicating that the part could not be found?

    Thanks and regards,
	Andr� van 't Hoog (F&D IS, JGO)

  Andr�,

  If your local parts file doesn't have a standard cost for the part
  then return zero. The TPAS_GET_ZSC program will send back the 
  approriate error message to let you know to populate your local database
  with the standard cost.

  Could you describe the situation that would occur when the part 
  you send into TPAS_CALC_TRNSFR_PRC cannot be found on your own database ?
  Would this be using MAXCIM, having the part on INPMS but not on INCMS.
  If so then, I would definately send back a zero standard cost. Then, when
  your local people go to enter the local standard cost they will find the 
  part not found and add it.

  Regards,
  Lois

    Lois,

    Thank you for your quick response. B.t.w, we are not using MAXCIM! Our
    local parts file is in a system called DMS (Distribution Management
    System).

    In theory it will never happen that we send a part number to TPAS which
    is not known in our own parts file (because it is impossible to enter
    an order with an unknown part number). Therefor in theory the 'local
    get part' can always find something in the local parts file. However, I
    want to be sure that if for some mysterious reason a part is sent to
    TPAS, which is unknown on our local parts file, the 'local get part'
    routine will actually send something back which can be handled properly
    by TPAS. Anyway, according to your statement the best thing to do is to
    let the 'local get part' module send back a standard cost of zero,
    which will cause the main TPAS module to return with an error to the
    calling program(?).

    Regards,
	Andr�

   Andr�

  �  by TPAS. Anyway, according to your statement the best thing to do is to
  �  let the 'local get part' module send back a standard cost of zero,
  �  which will cause the main TPAS module to return with an error to the
  �  calling program(?).

  It does send back a fatal error to the calling program

 %APPIX-F-STDCOSTNOF, STD COST is ZERO, Transfer Price cannot be calculated


 Then in your calling program capture this and exit appropriately.