T.R | Title | User | Personal Name | Date | Lines |
---|
48.1 | Accessing AMPS | MOEUR7::CUSSELL | | Mon Dec 12 1994 09:34 | 11 |
| Lois
If we are to use the AMPS data file instead of the PPCS service can
multiple installations (ie multiple nodes) of an application access
the one AMPS file?
How much space would a local AMPS data file occupy?
Regards,
Geoff Cussell
BOPS Development Evry France 7858 2381
|
48.2 | Ship-To parameter | MOEUR7::CUSSELL | | Tue Dec 13 1994 05:15 | 9 |
|
Lois,
Can you please give examples and the source of values for the 7
character SHIP_TO field passed as the fourth parameter to the
TPAS_CALC_TRNSFR_PRC module?
Regards,
Geoff Cussell
|
48.3 | Size of AMP2 initial feed/dailt feed/final size | AWARD::MAGNI | IM&T - 223-9837 | Tue Dec 13 1994 11:01 | 57 |
| >>>> How much space would a local AMPS data file occupy?
I have calculated the size of the AMPs feed intial load as a basis for you to
do some real evalutation.
If sites opt to use PPCS, which is the CPRS$DB Client/Server software,
they can expect a 0.5 to 8 second delay for each part depending on the
network.
ATTACHMENT: AMPs size
AMPs is the APPIX MASTER PARTS system that takes the Corporate CPRS$DB in RDB
format and makes the data available for sites in an RMS format. The software
to create and keep the loacal AMPs file updated is available through the WW
Parts and Products Reference IM&T by sending a request for AMPs to QCA_ADMIN.
The user can request all parts or a part class or group of parts class. The
initial creation can be quite large depending on the request. Updates are sent
out M-F and run from 1000 to 10,000 blocks depending on the days activity. The
end of / beginning of a fiscal month or year have the larger update files.
Rough sizes for the initial AMPs feed are as follows:
ALL PARTS - 1090 K blocks
Part Class - Size in K blocks Part Class - Size in K blocks
------------------------------ ------------------------------
" " 220 I* 0
1* 53 J* 0.005
2* 77 K* 0.005
3* 23 L* 0.006
4* 7 M* 0.3
5* 20 N* 0.044
6* .6 O* 0
7* 80 P* 0.03
8* 5.5 Q* 300
9* 48 R* 1
A* 84.5 S* 7
B* 60 T* 0.006
C* 7.5 U* 0.015
D* 11 V* 0.006
E* 18 W* 0.019
F* 92 X* 0.1
G* 0.005 Y* 4
H* 0.027 Z* 0.15
Example: If a site is requesting the part classes Q* AND S* then the
initial load file would be 307 K blocks (300K + 7K). The
Mon thru Fri files will still be the same as above and only
the part clases requested would be taken off the feed files
and stored in the local AMP file.
|
48.4 | SHIP/BILL TO/FROM data examples | AWARD::MAGNI | IM&T - 223-9837 | Tue Dec 13 1994 11:18 | 56 |
| Geoff,
>> Can you please give examples and the source of values for the 7
>> character SHIP_TO field passed as the fourth parameter to the
>> TPAS_CALC_TRNSFR_PRC module?
If the SHIP_BILL_TO_TYPE_CD is 'S' then
The data is the Corporate Stockroom Numbers from Corporate
Cost Accounting, found on the
TPAS$STKRM_DB.STOCKROOM_TABLE.STK_STOCKROOM_NUMBER
SHIP_BILL_TO would be 871
973
974 ...
If the SHIP_BILL_TO_TYPE_CD is 'P' then
The data is the Corporate Plant Nmemonics from Corporate
Cost Accounting, found on the
TPAS$DB.TRNSFR_AREA_TABLE.PLNT_MNEMNC
SHIP_BILL_TO would be PA
AY
RE ...
If the SHIP_BILL_TO_TYPE_CD is 'T' then
The data is the Corporate Tax Transfer Areas from Corporate
Tax, found on the TPAS$DB.TRNSFR_AREA_TABLE.TRNSFR_PRC_AREA_CD
SHIP_BILL_TO would be FGO
AYO
CRE
USS
PLS ...
If the SHIP_BILL_TO_TYPE_CD is 'B' then
The data is the Corporate Subsidiary Billing Code from
the IRF (XP0101.0AM) file.
It is found on the TPAS$DB.TRNSFR_AREA_TABLE.SUBSID_BILLG_CD
SHIP_BILL_TO would be 0002485
0002601
0002602
0002456 ...
We take feeds from the sources to validate/store the data in the TPAS
databases. The TRNSFR_PRC_AREA_CD is not feed but loaded manually by
Tax as the TPAS$DB is the source for that data.
The Stockroom and Plant Mnemonics are used more for Mfg to Mfg
transfers. I would expect BOPS, being used in the subsidiaries,
would use the Subsidiary Billing Codes.
Regards,
Lois
|
48.5 | Errors Returned | MOEUR8::CUSSELL | | Tue Dec 20 1994 09:11 | 18 |
|
Lois,
There are three error-related fields returned from
TPAS_CALC_TRNSFR_PRC ie
TPAS_RCV_ERROR_MESSAGE,
TPAS_RCV_SQLERR,
and TPAS_RCV_VMS_ERROR
Are these the ones we should be checking following a call to
TPAS_CALC_TRNSFR_PRC?
Can you please describe (or point us to the relevant documentation)
the error statuses/messages returned by TPAS_CALC_TRNSFR_PRC and how they
should be handled by the calling process?
Regards,
Geoff
|
48.6 | Error List in User Documentation | AWARD::MAGNI | IM&T - 223-9837 | Tue Dec 20 1994 15:06 | 43 |
|
TPAS_RCV_ERROR_MESSAGE
is an 80 character field with the following format:
FACILITY_MSG X(7) = '%APPIX-'
STATUS_CODE X(1) = 'F' Fatal
'W' Warning
'I' Informational
'S' Success
ERROR_MESSAGE X(72) = '-' and the error text
TPAS_RCV_SQLERR
is the actual SQLCODE, S9(9) COMP, error when a fatal error is
returned for an SQL call.
TPAS_RCV_VMS_ERROR
is the actual VMS Longword Error, S9(9) COMP. This is returned
for any fatal error other than SQL.
In the TPAS User Documentation, appendix A, is a listing of the
TPAS_RCV_ERROR_MESSAGEs. Check the STATUS_CODE for 'F'. Look through the
appendix and decide what your program should do when the different 'F'
errors are returned. Under TPAS I, each site handled the errors in different
ways that were appropriate to their business.
When a 'F', fatal, error is returned no transfer price is returned.
Warning and Informational errors just indicate that something different
from the normal route of Transfer Price calculation occured, but a
transfer price has been returned.
The SQLERR and VMS_ERROR were added in for TPAS II as some of the TPAS I
sites wanted the actual error code and not the TPAS Translated code.
The two logicals, TPAS$DISPLAY_I_ERRORS and TPAS$DISPLAY_W_ERRORS, will
direct the TPAS_CALC_TRNSFR_PRC program to display all the Informational
and Warning errors, if they are set to 'Y'. Most sites set these to 'N'
when they run in production so the user or .LOG is not bogged down with
this information.
|
48.7 | TPAS Install Q's, and an AMP2 Q. | TROOA::BCAMERON | Bob Cameron, Dtn 631-7431, I like my New PC | Wed Jan 11 1995 13:30 | 42 |
| Hi Lois,
I have decided to choose the notes for communication, since this may be of
interest to other sites.
As an aside, We are a first time user of TPAS, although our Canadian
Manufacturing group separately runs TPAS I at this time. Our Manufacturing
group will be upgrading to TPAS II. We are separately installing TPAS II,
strictly for the MFG to Sales Sub type transfers.
Q1. On install of the TPAS II kit a couple of problems were of note.
- The identifier owning the files in the TPAS sub-directories
after install, retain the original identifier from the source
account of the kit.
- There are no ACL's on the files.
Can you give us what the expected owner should be, Ie. Our TPAS Admin
account? or other. What is the ACL assignments for each file.
Did we do something wrong in the install, or is there a problem
in the kit? If so, can the kit be corrected? Do you have a
command stream handy that will assign the ACL's?
Q2. As noted above, we are a site interested in only the MFG to Sales
transfers at this time. Our source of Transfer Price will be from
the NOR database. It seems to us, a bit excessive to be relying
on the AMP2 database for obtaining what we need, which is just a
Product type. Is it possible, or can you make plans for in the
future, to separate this requirement away from the AMP2 database
for those transfers that are relying on the NOR database for the
remaining Part information? Note, In the meantime. we are currently
looking at way to reduce the parts on our AMP2 file by Part Class, and
will consider remote access to our MFG AMP2 file, but this is a less
likely an option.
Thanks in advance for your reply,
Bob C
|
48.8 | I had the same problems, and more! | FUTURS::TON | | Thu Jan 12 1995 04:58 | 13 |
| Hi Bob,
I had these exact same problems a bit over a months ago, and, as you are about
to discover, many more. There are many areas where the TPAS kit and TPAS itself
breaches DEC STD 095. I raised these issues with Lois at the time.
A status update on what is being done about these issues was requested a couple
of days ago, and I will forward the reply to you (or post it here) when we
recieve it.
George Ton
TOLAS Development.
|
48.9 | New kit 23 Jan | FUTURS::TON | | Mon Jan 16 1995 11:31 | 3 |
| Although I was not party to it, I have been told that in the telecon of 12th Jan
a new kit with DEC STD 095 fixes will be made available 23 Jan.
|
48.10 | that's my target date | AWARD::MAGNI | IM&T - 223-9837 | Tue Jan 17 1995 10:18 | 5 |
| George,
That's right - I am working to get there.
Lois
|