| Jean-Hugues, Barbara,
Please find answers to your questions below. I have highlighted my answers with
'>'. If further clarity is needed let me know.
regards,
Lois
1 - I do not have the TPAS II documentation which allows us to
Finalise the BOPS/TPAS II interface agreement.
I propose to send you a draft interface agreement based on
TPAS I, that you will update with TPAS II enhancements.
This will then become the basis of my development.
> By an interface agreement do you mean the level of support
> that the APPIX organization will provide ? If so we provide
> support 5d by 8h, although the APPIX Hotline will take the
> calls 7d by 24h and will try there best to help.
> If you mean the data sent between your application code
> and TPAS these are listed in the TPAS Functional Design
> AWARD::TPAS$PUBLIC:TPAS_II_FUNC_DESIGN.PS.
2 - I do understand that TPAS II kit is not yet completed.
When will it be available for us to test it with BOPS?
3 - My goal being to unit test the TPAS II interface in August,
a quick answer to -2- is more than welcome.
> Our current schedule is as follows:
> Complete Coding: July
> Integrated Testing: August
> Alpha Testing at a site: September
> Beta Testing at a site: October/November
> Live Implementation: January
>
> Once Alpha testing is complete I can make available a VMSInstall
> kit for sites to start their coding. Although the sites will have
> to keep in mind if any changes occur during Beta testing then
> the new kit must be installed. This does not sound as bad as it
> seems as the data elements being sent back and forth will be the
> same. The only potential changes will be in the library and only
> require re-compile/re-links.
4 - My group being not involved in TPAS II implementation, I
would like to know who (in Europe) is responsible for
TPAS implementation.
> I am not sure I understand the question here. All sites that
> are integrating TPAS II into their application code are
> responsible for the implementation.
5 - Can you answer the set of questions of Barbara Saywell,
who needs a few clarifications in order to do the point -1-.
> see below
1. 'We do NOT need to write a TPAS_LOCAL_GET_COST if we always pass
the Standard Cost in the TPAS_CALC_TRNSFR_PRC call'. Right or wrong?
> The answer is 'RIGHT'. At the installation site a logical
> is set to say whether the Local Std Cost will be sent in or not.
> If the Local Std Cost is sent in then TPAS will not make a call
> to TPAS_GET_LOCAL_COST, so you won't have to write this.
2. In Appendix G (Sent Data) of the Draft Func Spec for TPAS 2,
Local Std Cost & Ship Type are not mentioned. I assume this is an
oversight?
> Pull the TPAS II Functional DESIGN Specification from
> AWARD::TPAS$PUBLIC:TPAS_II_FUNC_DESIGN.PS
> This document is the IM&T software design document and will
> have much more detail in it.
3. Should one refer to TPAS II or TPAS 2 for the upcoming new version?
(Seems to vary)
> I have been referring to the software as TPAS II so as not to
> confuse the software release version number with the software
> name. TPAS is currently at version 2.1 when TPAS II is release
> the software will be TPAS V3.0
4. What do we have to do to get ship/bill-from & -to stockrooms &
sites set up in TPAS?
> You will need to send in the BILL_FROM and BILL_TO data in as either
> a Stockroom Number, Plant Mnemonic, Transfer Area Code or Subsidiary
> Billing Code format. The system logicals or data elements sent in
> will let the software know how to translate the data element into
> the TRANSFER_AREA_CODE.
5. The Excluded database - have I got the right idea about it? I think
that certain 'fatal' errors returned from TPAS_CALC_TRNSFR_PRC
(such as DSCNTSELECTNOF, PTICMMSELECT) should be handled by BOPS
as follows:
a) Use the old (current) method of calculating MTP for that
part
b) Report somewhere (on a listing perhaps, or a mail message to
a BOPS Administrator) that this has happened
c) Users then use this report/mail/whatever as a trigger to
'manually' update the TPAS$XCLDD_DB via the DECforms
interface. (We may include access to this as a menu option
within BOPS).
> You are correct in that if a discount record or pricing record
> cannot be found on the TPAS$DB the software will look on the
> TPAS$XCLDD_DB. If a record cannot be found on the database then the
> errors are returned. At that point the site user can run
> TPAS_XCLDD.EXE to create a discount or pricing record. The when TPAS
> is run again then TPAS$XCLDD_DB database will be used.
> When TPAS_XCLDD.EXE is run and a record is created or updated on
> TPAS$XCLDD_DB then a mail message is sent to Corporate Tax and
> anyone else found in the TPAS_XCLDD.DIS distribution list.
> This is done so that Corporate Tax can add the records to the
> TPAS$DB for use worldwide.
6. I have been wondering why the TPAS I kit has to be obtained from
ACADMY::QCA_ADMIN, rather than being available from Release
Management?
> As the software was developed by the APPIX organization we followed
> the APPIX Organization release management process. Although the
> TPAS name is registered with Spitbrook Product Management.
7. How much disk space does TPAS II and its databases require? (not
including AMP2).
> The TPAS Kit is less than 10K blocks.
> The TPAS$DB is less than 1300 blocks
> The TPAS$STKRM_DB is less than 1300 blocks
> The TPAS$NOR$DB will be around 300K blocks (will have more feel on
> this in August)
8. Re the timing of database updates (Note 32) - what is the current
mechanism, if any, for us to know that the updates are ready to
be pulled? Mail messages? Or do we just have to go by the most
recent times announced in the notes conference? (i.e. TPAS$DB last
fiscal Thursday after 4:00 EST, TPAS$STKRM_DB last fiscal Saturday
after 21:00 EST)?
We would like to be able to automate the updates in response to some
sort of trigger, perhaps a mail message.
> The current production schedule is:
> The last fiscal Thursday of the month a TPAS RBR file is created.
> The last Fiscal Saturday of the month a TPAS Stockroom file is
> created.
> Although additional files can be created throughout the month.
>
> We supply two command streams to pull the TPAS$DB and TPAS$STKRM_DB
> RBR files. These command streams look into an area on ACADMY and
> check the serial number. If the serial number is greater than the
> last serial number pulled the RBR file is copied.
> These command streams can be put into daily production if you want.
> Also, a mail message is sent out every time a new RBR file is created.
9. Can I get a 'test' copy of TPAS I & AMP2 for us to play with,
without doing an APPIX registration form etc?
> Both have to be obtained through the APPIX Registration.
> When you get the AMP2 put it into production right away, you
> don't want to re-install this.
Again, if further clarity is needed let me know.
Regards,
Lois
|
| Hello Lois,
I was hoping understand the details of implementation of the TPAS II
software, with respect to development of our Local Canadian site
transaction interfaces for MFG to Sales transfers. I had heard that a
test version of the TPAS II software will be available sometime in
September. Currently we have been planning to install the test software
on a development system late September in preparation of testing our
local changes in October. (Note, this is separate from the Canadian MFG
TPAS I upgrade to TPAS II).
- We noticed in the last reply that an install kit would not be
available until October. Should we instead plan on October for
our development system install, or can we (should we?) get a version
we can install sooner with least the local Price Calc components?
thanks in advance,
Bob Cameron
|
| Bob,
Check out note 41.3
As you see the software has not been at a pilot site yet. Until that time
I will not release the software. You should plan on October. We will keep
everyone posted.
> - We noticed in the last reply that an install kit would not be
> available until October. Should we instead plan on October for
> our development system install, or can we (should we?) get a version
> we can install sooner with least the local Price Calc components?
Regards,
Lois
|