HI
ATP-Server
An Available-To-Promise-Server provides all the data available throughout a company. When demand is increasing the system can define supply expectations and support their fulfillment.
As of Release 4.0A, the availability check can be carried out on a
dedicated application server, the ATP server. You can make the following
checks (basic methods):
o Check according to the ATP logic
o Check for planned independent requirements
o Check for allocations
The ATP server has a cross-transaction, global memory (shared
buffer),where ATP-relevant information, for example, requirement date,
requirement quantity and confirmed quantity of the database tables
RESB(Reservations/dependent requirements) and VBBE (Sales
Requirements:
Individual Records) is aggregated according to the date for one day at a
time. When you check material availability the system reads the data of
the two mentioned tables from the shared buffer instead of from The
database. This method of access considerably improves the performance. A
corresponding delta processing ensures data consistency between the
shared buffer and the database.
The ATP server is not a separate installation. As an application
servers, it is part of the used R/3 installation.
Installation and Sizing of the ATP server
Below we describe the necessary actions to install the ATP server
correctly. If you do not do this (standard system) then the check is
carried out without the use of the shared buffer, that is, the
system always reads the ATP-relevant data of database tables RESB and
VBBE from the database.
Changes to the system administration
Change the following SAP parameters:
o RFC address of the ATP server (parameter: rdisp/atp_server):
As
with the Enqueue server, you must enter the name of the application
server which is to be used as an ATP server (see Transaction SM51: SAP
server). This parameter must be displayed for all application servers, it
should be entered in the
default profile.
The following parameters are only important for the ATP
server, thus, you have to enter them into the instance profile of the ATP
server.
Size of the shared buffers (parameter:
rsdb/obj/buffersize):As a first approach you can estimate the size of the
shared buffer as follows: For each table (RESB and VBBE), client,
material, and plant, there is an object in the shared buffer. The size of
this object mainly depends on the number of the organizational
levels(storage locations, batches and MRP element indicators which are
stored in tables RESB and VBBE) and the number of the different
dates for each organizational level. For each organizational level
and date you need 25 byte.
Example for a VBBE object: 3 storage locations, no batch, 10 dates
For each storage location, 2 MRP elements: Sales orders and deliveries.
The result is (25 byte x. x 3 x 2 ) + (25 x 3 x 2) = 1650 byte
Storage requirement for this object. If 10000 combinations of material
and Plant should be buffered in the shared buffer, then 1650 byte x 10000
Are required. You must carry out a similar estimation for table RESB if
corresponding MRP items occur in the check according to scope of check.
In addition there is the administrative overhead for the shared buffer
and the object directory, which contains the objects. This factor largely
depends on the maximum number of stored objects (see below) and is in the
scale of 10%-20%.
o Max. number of stored objects (parameter:
rsdb/obj/max_objects):For this parameter you should choose a
value which is about twice as large as the number of ATP-relevant
client/material/plant combinations, if you want to carry out the
ATP check for both sales requirements and material reservations.
Message was edited by:
SHESAGIRI GEDILA
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.