Transport Legs and route stages

Hello experts!
I'll try to explain the task using an example....
- we've a sales order with tow items, the fist one from PLANT 1 (delivery 1)and the second one from PLANT 2 (delivery 2).
- we've a stock transfer order, with supplier the PLANT 1 and destination PLANT 2 (delivery 3).
And we have to planificate the shipment in both plant BUT the shipment to the customer is from the PLANT 2:
Transport 1 (from plant 1):
- delivery 3
- Delivery 1 (from plant 1 to plant 2)
Transport 2: (from plant 2):
- Delivery 2
- Delivery 1 (second leg??
Question: I don't khow how to configurate the route from plant 1 to plant 2 for the customer: route with stages? or shipment types with different leg indicator???
Do you know a similar situation???
Thanks in advance.

Dear C. Bristol,
In the example related by you, as per my understanding, there are 2 events which will trigger (If STO Process is followed from Plant 1 to Plant 2), as the order is from same customer & from SAP & Customer Viewpoint, both line items will be delivered from Plant 2.
Event 1 will be STO from Plant 1 to Plant 2
Event 2 will be from Plant 2 to Customer.
Event 1 & Event 2 are 2 separate transaction in SAP, the first being STO & second being end customer sale. If the 2 events are to be automated as single event, in that case it is a work around & will require Abap development.
Hope the above information is useful for you.
Regards,
Rajesh Banka

Similar Messages

Routes and Route Stages

Hi
I have created a route in config.
However it does not allow me to enter any information in the route stages. when I click on that the route stages screen comes but it is greyed out.
Is there another way of maintaining the route stages?
Thanks
Vinesh

ROUTE DETERMINATION
Step: 6 - Define Transportation Zone
Path: Sprou2014Logistics Executionu2014Transportationu2014Basic Transportation Function---Routesu2014Route Determinationu2014Define Transportation Zone.
Step: 7 - Maintain County and Transportation Zone for Shipping Point.
Path: Under the Same Menu path--- Maintain County and Transportation Zone for Shipping Point.
Select the Shipping point and enter the Country and Transportation Zone
Step: 8 - Define Transportation Groups.
Path: Under the Same Menu path---Define Transportation Groups
Step: 9 - Maintain Route Determination
Path: Under the Same Menu path--Maintain Route Determination.
Go to Customer master data.
In Address of General data. Enter the Transportation Zone id. and save
You will get the route.
The system takes into account the following 4 conditions for determining the Route u2013
a. The country and the Departure Zone of the shipping point +
b. Shipping Conditions agreed in the sales document type or with the sold to party +
c. Transportation Group assigned to the material +
d. The country & Transportation Zone of the ship to party (in CMR)
Route can be manually overwritten during a sales order processing. You can re-determine the route in the outbound delivery based on weight (weight group) provided it is allowed in the configuration of the delivery type.
Scheduling takes into account the following times u2013
a. Transit Time +
b. Loading Time +
c. Pick/Pack Time +
d. Transportation Lead/Planning Time.
The loading time and pick/pack time come from the shipping point whereas the transit time and transportation lead time come from the route.
The system performs backward scheduling first to confirm the required quantity checking the material availability on the material availability date. If the material availability date or the transportation planning date falls before the order date, the system automatically carries out forward scheduling and will propose a future date. A delivery type can be customized to carry out rescheduling if required during the delivery processing.
Regards,
Raj

Transportation Group and Shipping condition fields in Route determination

Hello Guys,
Please, I heard that if I leave Transportation Group and Shipping conditions field empty Route determination would consider whatever value I put in Material/Custumer Master.
But the determination just happen if I put the exact value in either the determination and the Material Master for Transportation Group field for example.
Have you ever determined Routes leaving the fields empty?
Thank you,
Regards,

Hi,
Those fields Transportation Group and Shipping conditions available in Route Determination are essential to trigger the correct route in Sales Order level.
If blank the available routes need to be picked manually at Sales Order level.
Kindly check .
Regards,
SRK

SD transportation and Route mate

Hi,
what is the purpose of SD transportation and route mate ?
Regards

Hi..
chek this link..Mr.Rakesh's reply..
Re: sap sd Transportation
Reg,
JJ

Route Stage data in Route determination

Hello Gurus,
We have scenario where in route defnition is not required. I am using the route just to have transportation implemented so I can use the shipment document.
I cannot maintain the route stage information Service Agent, shipping type, Distance, duration etc as all these are decided on the fly at the time of dispatch based on the weight volume of the material available for dispatch.
I get the message "Route 000001 has no valid legs" when I enter into the shipment, as I have not maintained the complete route information.
We have different phases in Shipment like Planning, Loading Start, Loading End.. could anyone plzzz explain me the use of these phases in shipment processing. Is it mandatory to maintain all these??
rgds,
Pavan P.

Hi Pavan,
Go to Transportation in the IMG there you go to Detail screen of the shipment type, in the detail screen of the shipment type there are fields called Adopt Route and Determine legs based on these fileds the legs (stages) will be dtermined in the shipment document.
Go through this link it is having details about automatic leg determination and manual stages creation in the shipment document.
http://help.sap.com/saphelp_47x200/helpdata/en/d5/2285347860ea35e10000009b38f83b/frameset.htm
For One more doubt.
You fallow these steps
-->You create condition table with the fields Shipment type you can get the shipment cost based on the shipment type.
I-->n the condition type you select calculation.type as 'R' Distence dependent assign the access sequence.
-->You Maintain the condition record for that in TK11.
-->Maintain pricing procedure and determine the procedure in the IMG.
You can get the simulation of the shipping cost at order level with out hitting the G/L account.Based on this you can select cheaper one.
Shipment Cost Information in the Order
As the shipment costs can make up a large proportion of the total cost of a product it is important and therefore recommended that you have a rough idea of the shipment costs when the order is created. As in normal situations no deliveries, shipments or shipment cost documents exist at this point, simulated versions of these can be "created" in the background to enable you to calculate shipment costs on the basis of these documents.
This means that you can estimate shipment costs. When you make the appropriate setting it is also possible to implement several calculations at the same time, in order, for example, to determine whether transport by lorry or by train would be cheaper or how much more it would cost to send by express delivery rather than by standard transport.
Integration
Shipment cost information is called up in SD order processing but uses the transportation and shipment cost processing functions.
Prerequisites
Shipment cost information in the order can only be used if the control parameters and master data for transportation and shipment cost processing have been maintained.
Features
To calculate shipment costs in the order you can define profiles for shipment cost information. The profile for shipment cost information contains default values for shipment cost information in the order, for example, the transportation planning point, transportation type and the shipment pricing procedure. The profile for shipment cost information is assigned to a sales document type (when defining the sales document types in Customizing for Sales and Distribution). If you do not want to carry out comparisons between the calculation methods, but just want to receive an estimated value for the shipment costs, then use the details from the profile for shipment cost information (transportation planning point, transport type, pricing procedure) and the data from the order (forwarding agent, route) for calculating shipment costs and the related simulated creation of transports.
-->If you do not assign a profile to the sales document type, you can also enter the transportation planning point, shipment type and service agent in the order.
To carry out a comparison of different calculation methods, you can assign one or more shipment planning profiles to a profile for shipment cost information. This planning profile is used to create shipments in collective processing, in order to store specific selection variants and data, which should always be used, in the memory. A planning profile determines how deliveries should be put together with shipments and which data should be put in the shipment documents. You can assign various planning profiles to the profile for shipment cost information, in order, for example, to compare whether it is cheaper to transport by train or by lorry. It is also possible to assign a planning profile for creating transportation chains.
If you begin the calculation of shipment costs in the sales document, the data that is used to simulate the putting together of the two types of transportation, is the data which is saved in the order and in the shipment costs profile, which is assigned to the corresponding sales document type. If the planning profile is assigned to the shipment cost type, this data is also used for the parallel calculation of shipment costs, so that it is possible to compare different transportation options.
Calling up Shipment Cost Information in the Order
Procedure
Choose Logistics ® Sales and distribution ® Sales.
Choose Order ® Create.
Enter all the data from your order and save the document.
Call up the document again by choosing Order ® Change.
In the order, choose Details ® Shipment cost information.
You reach the screen where the planning profiles are listed. In the first line, you always have the planning profile . In this line you see the default values from the shipment cost profile that is assigned to the respective sales document type.
If you have not assigned a shipment cost profile to the sales document type, now enter the missing data for Transportation planning point, shipment type, and service provider.
If you have assigned a shipment cost profile to the sales document type, and there are shipment planning profiles assigned to this shipment cost profile, then the system will list all the shipment planning profiles that are assigned to the shipment cost profile.
Choose Execute.
Result
In the column Net value, you see the values calculated by the system. If several planning profiles are assigned, you can have the system make comparisons. In the log, you can display the details of the simulated shipments. If you have problems with the calculations, you can check the reasons listed on the log.
I hope it will help you
Regards,
Murali.

Use the Transit Times of route stages ?

Hello. I would like to now if I somehow can use the transit time of the route stages instead of the header route transit time to reflect correct ATP. Current SAP is 4.7.
Business Scenario behind my request is mainly for Ocean Liner Shipments:
For Liner shipments most of the times there are fixed sailing Days ( i.e. every Friday ).
Here I use a route with two stages:
Shipping point to port of depature
Port of depature to final destination port.
As a possible solution I thought to use a Transportation connection point in between which should reflect the waiting time at the port having a factory calendar behind. But during first testing I recognized that any time specific date in the route stages are not take into calculation when creating a sales order ?
Help please !
Thanks
Joerg

I think the sales order picks up the time and dates from header of the route and applies stages and leg determination during shipment creation depending upon your shipment doc. type settings, hence, I think doesnt add stage values during order creation.
If I understand the problem right, perhaps a user exit or something can help you get the days to next Friday to add to the transportation lead time and get to the right dates. Check if this idea can help.

SHIPMENT AND ROUTE

hi all,
please send me the documentation for shipment and route customization document with screen shots . very argent plz
please forward document to this mail id [email protected]
will be rewarded full points.

Hi,
ROUTE DETERMINATION
Route can be determined in sales order with the help of 5 parameters: depart country, shipping conditions in customer master record, transportation group in material master, destination country, and weight group.
Weight group plays a vital role. The purpose of route determination is like in scenario's where company will ship goods to the customer in various ways not only that it has optional of having n number of routes select the best one & based on his customer priority (time & money.) for sending samples company will go for air, for delivering ordered goods it can go for different mode of transportation & routes.
Route Determination:
Departure country zone (Shipping Point) +destination country zone (Ship to Party) +shipping condition (CMR or Sales Doc Header Partners + Transportation Group (Material Master) +Weight Group (Optional) = Route. (0VRF)
Plant determination in the sales order: System will search first for Customer material Info Record, if it is not maintained there it will check for customer master record, if it is not maintained here also system will search for material master record...
Configuration part:
SPRO > Routes Basic shipping functions  Shipping -LE -
Define Routes:
Define mode of transportation
Define shipping types.
Assign shipping types to mode of transportation.
Define Routes and Stages
Maintain Stages For All Routes
Route Determination:
Define Transportation Zones
Maintain Country And Transportation Zone For Shipping Point
Define Transportation Groups
Define Weight Groups
Maintain Route Determination in the combination of
a) Departure country/Departure Zone - maintained in shipping point configuration
b) Shipping condition from the sales order
c) Transportation planning group maintained in General/Plant view of material master.
d) Destination country/Transportation zone maintained in General view -Address of Customer master of Ship to Party
SHIPPING PROCESS:
Shipping is an important part of the logistics chain in which guaranteed customer service and distribution planning support play major roles.
In shipping processing, all delivery procedure decisions can be made at the start of the process by
Taking into account general business agreements with your customer
Recording special material requests
Defining shipping conditions in the sales order
, the outbound delivery supports all shipping activities including picking, packing, transportation and goods issue. During the outbound delivery process, shipping-planning information is recorded, status of shipping activities is monitored and data accumulated during shipping processing is documented. When the outbound delivery is created, the shipping activities, such as picking or delivery scheduling, are initiated, and data that is generated during shipping processing is included in the delivery.
Range of Functions
An outbound delivery can be created as follows:
With reference to a sales order
With reference to a stock transport order
With reference to a subcontract order
With reference to a project
Without any reference
Depending on your requirements, you can create outbound deliveries automatically using worklists, or manually. You can make agreements with your customers for complete and partial deliveries and for order combinations. Outbound deliveries can be combined to form a single group of deliveries.
As soon as the material availability date or the transportation scheduling date for a schedule line is reached, the schedule line becomes due for shipping. When you create an outbound deliver, you initiate shipping activities such as picking and transportation scheduling.
A delivery is processed through one shipping point. Which shipping point carries out the processing for a delivery can be determined automatically during order processing or you can specify it manually in the order.
The system carries out the following activities when an outbound delivery is created:
Checks the order and materials to make sure the outbound delivery is possible (for example, it checks for delivery blocks or incompleteness)
Determines the delivery quantity of an item and checks the availability of the material
Calculates the weight and volume of the delivery
Calculates work expenditure
Packs the outbound delivery according to the reference order
Checks the delivery situation of the order and any partial delivery agreements
Redetermines the route
Adds information relevant for export
Checks delivery scheduling and changes deadlines (if necessary)
Assigns a picking location
Carries out batch determination (if material is to be handled in batches)
Creates an inspection lot if the material must pass a quality check
Updates sales order data and changes order status
A shipping point can be determined for each order item. How the shipping point is determined depends on three factors:
The shipping conditions from the customer master record (Shipping screen)
For example, it might have been agreed with the customer that the goods are to be delivered as soon as possible.
The loading group from the material master record (Sales/Plant Data screen)
You could, for example, specify a loading group that defines that the goods must always be loaded with a crane or a forklift.
The delivering plant
A route can be determined for every order item. Determining the route in the sales order depends on the following factors:
Country and departure zone of the shipping point
Shipping condition from the sales order
For example, it might have been agreed with the customer that the goods are to be delivered as soon as possible.
Transportation group from the material master record (Sales/Plant Data screen)
You can use the transportation group to group together goods with the same characteristics (for example, bulky goods or goods that must be transported in refrigerated trucks).
Country and transportation zone of the ship-to party (Control screen in the customer master record)
You can create a single outbound delivery for exactly one order, if you know the order number. Only the order items from this order that are due for shipment will be included in the delivery. You can make changes to the shipping data, if necessary.
Procedure
To create an individual outbound delivery, proceed as follows:
From shipping, choose Outbound Delivery ® Create ® Single Document ® With Reference to Sales Order.
The initial screen for creating outbound deliveries appears.
Enter the appropriate shipping point.
Specify the selection date.
You can only deliver schedule lines whose material availability date or transportation scheduling date is the same as or falls before the selection date.
The current date is proposed by the system as the selection date.
If you only want to deliver some of the order items, specify the appropriate item numbers in the from item and to item fields.
Select Enter.
Please Reward If Really helpful,
Thanks and Regards,
Sateesh.Kandula

Transport layer and transport package

I have a fundamental query on transport package and layer.
Objects are classified in packages depending on the project and put in $TMP or test package else they are local ? Only objects belonging to a transport package can be transported , others are not ? How transport package is defined ? All objects must be a part of transport package else can not be transported ?
ABout transport layer, I understand this is used to define which path objects will take during transport particularly when there are multiple transport routes. But what are the advantages of it ? How we can define it (trx code/menu path) ?
Is it mandatory to use transport package and layers ?

Hi Mike,
Just to clarify a few basic concepts:
A transport package (formerly called a "development class", a term you may still encounter) groups related development objects. Whenever you create a new development object (table, program, ...) you have to assign it to a package; the object is then placed into a transport request. Alternatively you can indicate it is a local object (its package is then "$TMP") but such an object is non-transportable.
A transport layer identifies the route that transportable devmt objects must follow. Typically in your system you will have two layers: a layer usually called Zxxx (with xxx = SID of your development system) is used for your own developments. Another layer called "SAP" is used for transporting SAP objects, for example changes to standard SAP code implemented via transaction SNOTE and recorded in repairs. Without the "SAP" layer in place, repairs would be non-transportable.
Each transport package belongs to a layer. You assign the layer when you create a new package in transaction SE80. You can change the layer later on, but this is rarely needed and can cause quite a few side-effects. SAP objects always have layer "SAP". The layers themselves are managed in STMS, under "Transport Routes".
Hope this clarifies things,
Rgds, Mark

Issue with Transporting Trans and Comm Structure

Hi Experts,
Recently we moved an Infosource ( with Transfer structure and Comm stucture) from D to Q. After movement we checked teh Transport log and we see a warning that says
" R3TRROUT458SEFRDF2PUBJRIZGZAOPSNB not found, object also deleted in target system"
From teh object name it appears like a routine. But how do we know the actual name of the routine so that we can see in find out and compare betwn systems.
Thanks
DVMC

Hi,
If you want to find the objects using only technical name, use the table TADIR.
In your case execute this table and give the technical name
'458SEFRDF2PUBJRIZGZAOPSNB' (Removed R3TR and ROUT).
Then you can get the routine details.
Regards,
Vivek V

Transport planning and shipping condition

What is the meaning of transport planning and shipping condition,
Please explani

<b>Shipping Conditions (VSBED):</b>
General shipping strategy for the delivery of goods from the vendor to the customer.
You can define shipping conditions in your system which corresponds to the requirements of your company. You can specify a shipping condition in the customer master and in the vendor master.
The loading group, the plant and the shipping condition determine the shipping point that will be proposed by the system.
Apart from the country and the geographical region of the shipping point, the ship-to party and the transportation group, the shipping condition determines the route that the system proposes in the order for the delivery of the goods. In the delivery, the route proposal also takes the weight group into account.
<b>Transportation Planning:</b>
Transportation Planning is part of the Transportation Planning/Vehicle Scheduling (TP/VS) application and is used for medium to long-term planning. It enables the transportation planner to optimally distribute the available capacities for trucks, trains, ships, and planes. The aim of Transportation Planning is to load capacities in the most efficient way and reduce costs. Most customers currently rely entirely on external shipping companies to carry out an optimal transportation of goods, which means that punctual and cost-effective deliveries are a high priority.
Regards,
AK
reward points if helpful

Transport classes and programs to another server

Except for transport routing and charm copy function, do we have other ways to do so?
for example copy or so forth.
best regards,
Blake Le

Hi Blake
SAP R/3 Correction and Transport System
Operating system level files in the transport process:
The SAP C program TP, requires a special file structure for the transport process. The file system is operating system dependent. TP uses a transport directory or file system, which is called /usr/sap/trans.
The /usr/sap/trans file system is generally NFS mounted form the development system to other systems unless a system is defined as a single system in the CTS pipeline. All the sub directories should have <SID>adm as the owner and sapsys as the group; and proper read, write and execute access should be given to owner and the group. The TP imports are always performed by <SID>adm.
The following are the subdirectories in /usr/sap/trans:
/data
/cofiles
/bin
/log
/actlog
/buffer
/sapnames
/tmp
/usr/sap/trans/data: holds the data of transport objects after they are released . The example of a data file is R904073.DEV. The extension DEV means the data file was released from the DEV or development system.
/usr/sap/trans/cofiles: The cofiles directory holds the command files for all change requests. These files are like a command or control files used to import the data files. The common directory for CTS system is /usr/sap/trans. After a change request is released from the source system , the data is exported immediately to the file system of the operating system. The SAP transport utility TP uses the cofile to transport a data file. The example of a file in cofiles directory is K904073.DEV.
/usr/sap/trans/bin: holds the most important file TPPARAM in the CTS system. TPPARAM file has all the information about the CTS systems in the CTS pipeline. TPPARAM file is the parameter file for the transport program TP and it is the common file for all the systems in the CTS pipeline. As you know already that /usr/sap/trans should be NFS mounted to all the systems in a CTS pipeline, TP program has access to the TPPARAM file from all the systems. The following is an example of typical TPPARAM file for five SAP systems in the CTS pipeline:
#@(#) TPPARAM.sap 20.6 SAP 95/03/28
Template of TPPARAM for UNIX #
First we specify global values for some parameters, #
later the system specific incarnation of special parameters #
global Parameters #
transdir = /usr/sap/trans/
dbname = $(system)
alllog = ALOG$(syear)$(yweek)
syslog = SLOG$(syear)$(yweek).$(system)
System spezific Parameters #
Beispiel T11 #
DEV/dbname = DEV
DEV/dbhost = sap9f
DEV/r3transpath = /usr/sap/DEV/SYS/exe/run/R3trans
QAS/dbname = QAS
QAS/dbhost = sap8f
QAS/r3transpath = /usr/sap/QAS/SYS/exe/run/R3trans
TRN/dbname = TRN
TRN/dbhost = sap17
TRN/r3transpath = /usr/sap/TRN/SYS/exe/run/R3trans
PRE/dbname = PRE
PRE/dbhost = sap19f
PRE/r3transpath = /usr/sap/PRE/SYS/exe/run/R3trans
PRD/dbname = PRD
PRD/dbhost = sap18f
PRD/r3transpath = /usr/sap/PRD/SYS/exe/run/R3trans
/usr/sap/trans/log: holds the entire log files, trace files and statistics for the CTS system. When the user goes to SE09 (workbench organizer) or SE10 (customizing organizer) transaction and opens the log for a transport, the log file for that transport will be read from /usr/sap/trans/log directory. Each change request should have a log file. Examples of log files are DEVG904073.QAS, DEVI904073.QAS and DEVV904073.QAS. The name of a log file consists of the names of the change request, the executed step, and the system in which the step was executed:
<source system><action><6 digits>.<target system>
Now we can analyze the above example DEVG904073. QAS. The <source system> = DEV, <action> = G or report and screen generation, <6 digits> = 904073 (these six digits numbers are exactly the same number as the six digits of the transport) and the <target system> = QAS
Possible values for <action> are:
A: Dictionary activation
D: Import of application-defined objects
E: R3trans export
G: Report and screen generation
H: R3trans dictionary import
I: R3trans main import
L: R3trans import of the command files
M: Activation of the enqueue modules
P: Test import
R: Execution of reports after put (XPRA)
T: R3trans import of table entries
V: Set version flag
X: Export of application-defined objects.
/usr/sap/trans/actlog: holds action log files. The example of an action file is DEVZ902690.DEV. The following are the contents of the file:
1 ETK220 u201C==================================================u201D u201C=================
=============================
1 ETK191 u201C04/30/1998u2033 Action log for request/task: u201CDEVK902690u2033
1 ETK220 u201C==================================================u201D u201C=================
=============================
1 ETK185 u201C04/30/1998 18:02:32u2033 u201CMOHASX01u2033 has reincluded the request/task
4 EPU120 Timeu2026 u201C18:02:32u2033 Run timeu2026 u201C00:00:00u2033
1 ETK193 u201C04/30/1998 18:02:33u2033 u201CMOHASX01u2033 owner, linked by u201CMOHASX01u2033 to u201CDEVK902691u2033
4 EPU120 Timeu2026 u201C18:02:33u2033 Run timeu2026 u201C00:00:00u2033
1 ETK190 u201C05/04/1998 11:02:40u2033 u201CMOHASX01u2033 has locked and released the request/task
1 ETK194 u201C05/04/1998 11:02:40u2033 **************** End of log *******************
4 EPU120 Timeu2026 u201C11:02:40u2033 Run timeu2026 u201C00:00:09u2033
~
~u201DDEVZ902690.DEVu201D 10 lines, 783 characters
/usr/sap/trans/buffer: transport buffer of the target systems; contains control information on which requests are to be imported into which systems and in what order the imports must occur. The /usr/sap/trans/buffer will have a directory for each system in the CTS pipeline. For example the buffer file for DEV system is /usr/sap/trans/buffer/DEV.
/usr/sap/trans/sapnames: holds information pertaining to transport requests for each system user. There are files for each user who released change requests from the system.
/usr/sap/trans/tmp: holds information about temporary data and log files. While the transport is occurring the Basis administrator can find a file that is related to the transport in the tmp directory; that file shows the exact status if the transport (What objects are being imported at that time).
Important SAP delivery class and table types and tables in the CTS process:
Delivery class
The delivery class defines who (i.e. the SAP system itself or the customer) is responsible for maintaining the table contents. In addition the delivery class controls how the table behaves in a client copy and an upgrade. For example when you select a SAP defined profiles to perform a client copy, certain tables are selected according to their delivery class. DD02L table can show what delevery class a table belongs to.
The following delivery classes exist:
A: Application table.
C: Customizing table, maintenance by customer only.
L: Table for storing temporary data.
G: Customizing table, entries protected against overwriting.
E: Control table.
S: System table, maintenance only by SAP.
W: System table, contents can be transported via own TR objects.
Table type
The table type defines whether a physical table exists for the logical table description defined in the ABAP/4 Dictionary and how the table is stored on the database.
The following are different table types in SAP:
Transparent Tables
There is a physical table on the database for each transparent table. The names of the physical table and the logical table definition in the ABAP/4 Dictionary are same. For every transparent table in SAP, there is a table in database. The business and application data are stored in transparent tables.
Structure
No data records exist on the database for a structure. Structures are used for the interface definition between programs or between screens and programs.
Append Structure
An Append structure defines a subset of fields which belong to another table or structure but which are treated as a separate object in the correction management. Append structures are used to support modifications.
The following table types are used for internal purposes, for example to store control data or for continuous texts:
Pooled table
Pooled tables can be used to store control data (e.g. screen sequences, program parameters or temporary data). Several pooled tables can be combined to form a table pool. The table pool corresponds to a physical table on the database in which all the records of the allocated-pooled tables are stored.
Cluster table
Cluster tables contain continuous text, for example documentation. Several cluster tables can be combined to form a table cluster. Several logical lines of different tables are combined to form a physical record in this table type. This permits object-by-object storage or object-by-object access. In order to combine tables in clusters, at least part of the keys must agree. Several cluster tables are stored in one corresponding table on the database.
Tables in CTS process:
TRBAT and TRJOB:
TRJOB and TRBAT are the major tables in the CTS process. After TP program has sent the event to the r3 system, RDDIMPDP checks table TRBAT in the target system to find out if there is an action to be performed. Mass activation, distribution, or table conversions are the examples of actions. If there is action to be performed, RDDIMPDP starts the appropriate program in the background task. RDDIMPDP then reschedules itself.
By checking table TRJOB, RDDIMPDP automatically recognizes if a previous step was aborted, and restarts this step. For each transport request , TP program inserts an entry into table TRBAT. If the return code 9999 in this table then the step is waiting to be performed. Return code 8888 indicates that the step is active and currently being processed. A return code of 12 or less indicates that the step is finished. In addition, TP inserts a header entry to let the RDDIMPDP program know to start processing. The column return code will therefore contain a B for begin. When RDDIMPDP is started, it sets the header entry to R(un), and starts the required program. When all the necessary actions are performed for all the transport requests, the column return code contains all the return codes received, and the column TIMESTAMP contains the finishing time. The header entry is set to F(inished). TP monitors the entries in TRBAT and TRJOB tables. When the header entry in TRBAT is set to finished. The entry in TRJOB is deleted.
Transport Tables SE06
TDEVC - Development classes
TASYS - Details of the delivery. Systems in the group that should automatically receive requests, have to be specified in table TASYS.
TSYST - The transport layers will be assigned to the integration systems. ( Define all systems)
TWSYS - Consolidation routes ( define consolidation path)
DEVL - Transport layers are defined here
In u201CConfiguring the CTS systemu201D section, We will learn more about the transport tables in SE06 transaction
Programs in the CTS process:
In the CTS table section we learned about the RDDIMPDP program. RDDIMPDP program needs to be scheduled in all the clients in an instance. It is recommended to schedule the RDDIMPDP as event driven.
RDDPUTPP and RDDNEWPP programs can be used to schedule RDDIMPDP program in the background.
The ABAP/4 programs that RDDIMPDP starts are determined by the transport step to be executed that is entered in the function field of table TRBAT.
Function Job Name Description of transport Steps
J RDDMASGL Activation of ABAP/4 dictionary objects
M RDDMASGL Activation of match codes and lock objects
S RDDDISOL Analysis of database objects to be converted
N RDDGENOL Conversion of database objects
Y RDDGENOL Conversion of matchcode tables
X RDDDICOL Export of AD0 objects
D RDDDIC1L Import of AD0 objects
E RDDVERSE Version management update during export
V RDDVERSL Version management update during import
R RDDEXECL Execution of programs for post - import processing
G RDDDIC3L Generation of ABAP/4 programs and screens
Version Management:
One of the important features of Workbench Organizer is Version Management. This feature works for all the development objects. Using the version management feature the users can compare and retrieve previous versions of objects.
Version management provides for comparisons, restore of previous versions, documentation of changes and assistance in the adjustment of data after upgrading to a new release. With the release of a change request, version maintenance is automatically recorded for each object. If an object in the system has been changed N times, it will have N delta versions and one active version. To display version management, for ABAPs use transaction SE38 and for tables, domains and data elements use SE11. The path to follow is Utilities -> Display version. Using version management the users can view existing version for previously created ABAP code, make changes to the code, compare code versions and restore original version of the code. Now the users will be restore previous versions without cut and paste steps of the past.
TP and R3trans program:
The basis administrator uses TP program to transport SAP objects from one system to another. TP is a C program delivered by SAP that runs independently of the R/3 system. TP program uses the appropriate files located in a common transport directory /usr/sap/trans. TP starts C programs, ABAP/4 programs and special operating system commands to its job. R3trans is one of the most important utility program called by TP. Before using the TP program, the basis administrator needs to make sure that the CTS system is setup properly and the right version of TP is running in the system. The TP program is located in the run time directory /usr/sap/<SID>/SYS/exe/run directory. It is automatically copied in the install process. A global parameter file TPPARAM that contains the databases of the different target systems and other information for the transport process controls TP. The global parameter file determines which R3trans is used for each system. If the parameter r3transpath is not defined properly then no export and import can be done. The basis administrator should make sure that the default value u201Cr3transpathu201D is properly defined. Later in this chapter we will learn more about TP and R3trans; also we are going to see how they are used.
Configuring the TPPARAM file:
Each time TP is started, it must know the location of the global parameter file. As we have seen before TPPARAM file should be in directory /usr/sap/trans/bin. The parameters in TPPARAM can either global (valid for each and every system in the cts pipeline) or local to one system. Th parameters are either operating system dependant (these parameters preceded by a keyword corresponding to the specific operating system) or database dependant (contain a keyword corresponding to a specific database system).
The global parameter file provides variables that can be used for defining parameters. The variables can be defined in format: $(xyz). The brackets can be substituted with the u201C\u201D-character if required.
The following pre-defined variables are available for the global parameter file:
$(cpu1): The CPU name can be sun or as4 for example. In heterogeneous networks this variable is very important.
$(cpu2): Acronym for the name of the operating system. The example for this variable can be
hp-ux, or sunos . This is an operating system specific variable.
$(dname): Used for the day of the week (SUN,MON,u2026.).
$(mday): Used for the day of the current month (01-31).
$(mname): Used for the name of the month (JANu2026DEC).
$(mon): Used for the Month (01-12).
$(system): R/3 System name.
$(wday): Day of the week (00-06, Sunday=00, Monday=01, Tuesday=02 and so on).
$(yday): Day of the current year (001-366). Using the number any day of the year can be chosen.
$(year): Year (Example:1998 or 1999).
$(syear): Short form of the year (two positions).
$(yweek): Calendar week (00-53). The first week begins with the first Sunday of the year.
For the database connection:
The transport environment also needs parameters to connect to the R/3 System database. As we know already the every instance in the R/3 CTS pipeline has its own database, therefore specific parameters should be defined for each database system. From dbtype parameter of RSPARAM file, TP program identifies the database system.
The two parameters u201Cdbnameu201D and u201Cdbhostu201D are required for ORACLE databases.
DBHOST: is the name of the computer on which the database processes execute. TCP/IP name of the host if NT is being used.
DBNAME: is the name of the database instance.
As of Release 3.0E, two new parameters have been introduced.
DBLOGICALNAME: The default value is $(system). The logical name that was used to install the database.
DBCONFPATH: The default value is $(transdir).
The parameters u201Cdbnameu201D and u201Cdbhostu201D are also used for INFORMIX databases in an installation:
DBHOST: Same as Oracle.
DBNAME: Name of the database instance, uppercase and lowercase are distinguished here.
INFORMIXDIR : u201C/informix/<SAPSID>u201D is the default value. Defines the directory namewhere the database software can be found.
INFORMIXSQLHOSTS: u201C$(informixdir)/etc/sqlhosts[.tli|.soc]u201Cis default value under Unix. The name of the SQLhosts file with its complete path is defined with this parameter.
INFORMIX_SERVER: u201C$(dbhost)$(dbname)shmu201D is the default value. The name of the database server may be specified for a local connect.
INFORMIX_SERVERALIAS: u201C$(dbhost)$(dbname)tcpu201Dis the default vlue. The name of the database server can be specified for a remote connect.
For Microsoft SQL Server database the two parameters u201Cdbnameu201D and u201Cdbhostu201D are also required. DBHOST: The TCP/IP name of the host on which the database is running.
DBNAME: The database instance name.
For DB2 in AS/400 only u201Cdbhostu201D is required.
DBHOST: System name of the host on which the database is running.
If theu201DOptiConnectu201D is used, the following line should be specified:
OPTICONNECT 1
For DB2/ AIX
The two parameters u201Cdbnameu201D and u201Cdbhostu201D are required
DBHOST: The host on which the database processes are running. It is the TCP/IP name of the host for Windows NT (As we have seen in the earlier examples).
DBNAME: Database instance name.
The DB2 for AIX Client Application Enabler Software must also be installed on the host on which tp is running.
ALLLOG: u201CALOGu201D $(syear) $(yweek)u201Dis the default value. This variable can be used in TPPARAM file to specify the name of a file in which tp stores information about every transport step carried out for a change request anywhere in the transport process. The file always resides in the log directory.
SYSLOG: u201CSLOG $(syear) $(yweek).$(system)u201D is the default value. This variable can be used to name a file in which tp stores information about the progress of import actions in a certain R/3 System. The file does not store information for any particular change request. The file always resides in the log directory.
tp_VERSION: Zero is the default value. If this parameter is set to not equal to zero, a lower version of tp may not work with this TPPARAM file. If the default value (zero) is set, the parameter has no affect.
STOPONERROR: (Numeric value) The default value is 9. When STOPONERROR is set to zero, tp is never stopped in the middle of an u201Cimportu201D or u201Cputu201D call. When STOPONERROR is set to a value greater than zero, tp stops as soon as a change request generates a return code that is equal to or greater than this value (The numeric value of the STOPONERROR parameter is stored in the variable BADRC). Change requests, which still have to be processed for the current step, are first completed. A u201CSYNCMARKu201D in the buffer of the R/3 System involved, sets a limit here. tp divides the value of this parameter between two internal variables. STOPONERROR itself is treated as a boolean variable that determines whether tp should be stopped, if the return code is too high.
REPEATONERROR (Numeric value too): The default value is 9. The REPEATONERROR parameter is similar to STOPONERROR. The difference is, REPEATONERROR specifies the return code up to which a change request is considered to be successfully processed. Return codes less than REPEATONERROR are accepted as u201Cin Orderu201D. Change requests that were not processed successfully stay in the buffer.
NEW_SAPNAMES: Default value is u201CFALSEu201D. A file is created for each user of the R/3 System group in the u201Csapnamesu201D subdirectory of the transport directory. Except some of the operating system,the name of the user is the name of the file. It is very important to remember hat the special characters or length of the file name could cause problems. If all the R/3 Systems in the transport group have at least Release level 3.0.; TP program is efficient to handle this problem. The user names are modified to create file names that are valid in all operating systems and the real user names are stored in a corresponding file.
Though we have seen so many parameters, for the minimum configuration the following two parameters are very important.
TRANSDIR: specifies the name of the common transport directory. The following is a typical example from TPPARAM of Unix as we have seen before.
transdir = /usr/sap/trans/
DBHOST: contains the name of the database host. In Windows NT environment, this is the TCP/IP host name. The following is an example in Unix:
DEV/dbname = DEV
DEV/dbhost = sap9f
DEV/r3transpath = /usr/sap/DEV/SYS/exe/run/R3trans
For TP, to control u2018Start and Stopu2019 command files and database in R/3 the following important parameters are specified in TPPARAM:
Parameters for the tp Function u201CPUTu201D: LOCK_EU (boolean) default value is u201CTRUEu201D. Though from version 3.1 onward the tp put command is used seldom in cts process still it is important to know how this parameter works. When u201Ctp putu201D is used, it changes the system change option . If the parameter is set to u201CFALSEu201D nothing gets changed. If the parameter is set to u201CTRUEu201D, the system change option is set to u201CObjects cannot be changedu201D at the beginning of the call, and gets changed back to its previous value at the end of the call. The u201Ctp putu201D command will give the exact status of the locking mechanism.
LOCKUSER (used as boolean value): Default value is u201CTRUEu201D. This parameter is about the user login while tp put call is executed. If this parameter is set to u201CFALSEu201D, no locking mechanism for the users takes affect. If this parameter is defined as u201CTRUEu201D then a character is set in the database level; so only DDIC and SAP* can log on to the system. Users that have already logged on are not affected (this is a reason for activating the parameters STARTSAP and STOPSAP). The charactertor is removed at the end of the call, and all the users can log on to the SAP R/3 System again.
STARTSAP: Default value is u201D u201C.or u201CPROMPTu201D for Windows NT . This parameter is used by TP to start an R/3 System. It is not necessary for the clients to make tp start and stop R/3 system..
STOPSAP: Default value is u201D u201Cor u201CPROMPTu201D for Windows NT. TP uses this parameter to stop an R/3 System.
STARTDB: Default value is u201D u201C. TP uses the value of this parameter to start the database of an R/3 System.
The parameter is not active under Windows NT.
STOPDB: Default value is u201D u201C. TP uses the value of this parameter to stop the database of an R/3 System.
This parameter is not active under Windows NT.
The above parameters in UNIX can be used as following:
STARTSAP = startsap R3
STOPSAP = stopsap R3
STARTDB = startsap db
STOPDB = stopsap db
In Windows NT:
STARTSAP =
$(SAPGLOBALHOST)\sapmnt\$(system)\sys\exe\run\startsap.exe
R3 <SID> <HOST NAME> <START PROFILE>
STOPSAP =
$(SAPGLOBALHOST)\sapmnt\$(system)\sys\exe\run\stopsap.exe
R3 <SID> <HOST NAME> <INSTANCE> <PROFILE PATH + Instance profile>
The parameters STARTDB and STOPDB are not active under Windows NT.
Parameters for the tp function u201CCLEAROLDu201D
DATALIFETIME (Numeric): Default value is u201C200u2033. When the data file has reached a minimum age, it is moved to the subdirectory old data with tp check. tp clearold all. The life span of the data files in the data sub directory can be set in days with this all, parameter.
OLDDATALIFETIME (Numeric): Default value is u201C365u2033. When a file located in the olddata subdirectory is no longer needed for further actions of the transport system and has reached a minimum age, it is removed with tp check.all, tp clearold all. The minimum age in days can be set with this parameter.
COFILELIFETIME (Numeric): Default value is u201C365u2033. This parameter is used just like DATALIFETIME parameter.
LOGLIFETIME (Numeric): Default value is u201C200u2033. This parameter applies to the life span of the log files. When the log files in log subdirectory is no longer needed for the transport system and has reached a minimum age, it is deleted with the calls tp check.all, tp clearold all. The minimum age in days can be defined with this parameter.
The Three Key Utilities of the CTS system (TP, R3trans and R3chop):
TP: Earlier in this chapter we have seen the objectives of TP. The TP transport control program is a utility program that helps the user to transport objects from one system to another. TP program is the front-end for the utility R3trans. TP stands for u201CTransports and Putsu201D. To make the TP work successfully the CTS system needs to be correctly configured. The following steps are very important for TP to run properly.
The transport directory /usr/sap/trans must be installed and NFS mounted to all the systems in the CTS pipe line.
RDDIMPDP program must be running (event driven is recommended) in each client. RDDIMPDP can be scheduled in the background by executing RDDNEWPP or RDDPUTPP. Use the tp checkimpdp <sap sid> command in /usr/sap/trans/bin directory as <sid>adm user to check RDDIMPDP program.
Use the tp connect <sap sid> command in /usr/sap/trans/bin directory to see whether the tp program is connecting to the database successfully or not. To run TP command the user has to logon as <sid>adm in source or target system.
The R/3 Systems in the CTS pipeline must have different names.
The Global CTS Parameter File TPPARAM must be correctly configured.
The source system (for the export) and target system ( for the import) must have at least two background work processes. TP always schedules the C class job, so if all the background jobs are defined as A class job then there will be problems in transport steps.
Important Tips :.It is always better to have the up to date TP version installed in your system. A user can ftp a current version of TP from SAPSERV4 of SAP. Though R3trans and other utility programs can be used to do the transport, it is recommended to use TP whenever possible for the following reasons..
The exports and imports are done separately using TP program. For example: when a transport is released from the system, the objects are exported from the source database to the operating system and then the import phase starts to transport those objects to the target system.
TP takes care of the order of the objects. The order, that was followed to export the objects; the same order will be followed to import them to the target database.
The TP command processes all change requests or transports in the SAP system buffer that have not yet been imported successfully. All the import steps are executed automatically after TP calls R3trans program to execute the following necessary steps:
Dictionary Import: ABAP/4 dictionary objects will be imported in this step.
Dictionary Activation: Name tabs or runtime descriptions will be written inactively. The R/3 system keeps running until the activation phase is complete. The enqueue modules are the exceptions in the running phase. After the activation of new dictionary structure the new actions are decided to get the runtime objects to the target system.
Structure conversion: If necessary the table structure is changed in this phase.
Move Nametabs: The new ABAP/4 Dictionary runtime objects which were inactive up to now are moved into the active runtime environment in this process. The database structures are adjusted accordingly. From the first step to the Main import step inconsistencies can occur to the R/3 system. After the main import phase all the inconsistency ca be solved.
Main import with R3trans: All the data are imported completely and the system comes to a consistent state.
Activation of enqueue-objects: The enqueue-objects cannot be activated in the same way as the objects of the ABAP/4 Dictionary, so they have to be activated after the main import in this step. They are then used directly in the running system.
Structure Conversion of match codes, Import application defined objects, versioning and execution of user defined activities are some of the steps after activation of enqueue-objects. The next step is generation of ABAP/4 programs and screens, where all the programs and screens associated with the change request are generated. When all the import steps are completed successfully, the transport request is removed from the import buffer.
It is recommended by SAP to schedule regular periods for imports into the target system (e.g. daily, weekly or monthly). Shorter periods between imports are not advisable. The transport to production should not be done in the off hours when the users are not working
TP can be started with different parameters. The u201Ctp helpu201D command can help user to generate a short description about the use of the command.
The following are the some important commands of TP:
For export:
tp export <change request>: The complete objects in the request from the source system will be transported. This command also used by SAP System when it releases a request.
tp r3e <change request>: R3trans export of one transport request.
tp sde <change request>: Application defined objects in one transport request can be exported.
tp tst <change request> <SAP system >: The test import for transport request can be done using this command.
tp createinfo <change request>: This command creates a information file that is automatically done during the export.
tp verse <request>: This command creates version creates versions of the objects in the specified request.
To Check the transport buffer, global parameter file and change requests:
tp showbuffer <sid>: Shows all the change requests ready to be imported to the target system.
tp count <sid>: Using this command users can find out the number of requests in the buffer waiting for import.
tp go <sid>: This command shows the environment variables needed for the connection to the database of the <sid> or target system.
tp showparams <sid>: All the values of modifiable tp parameters in the global parameter file. The default value is shown for parameters that have not been set explicitly.
To import the change requests or transports:
tp addtobuffer <request>.<sid>: If a change request is not in the buffer then this command is used to add it to the buffer, before the import step starts.
tp import all <sid>: This command imports all the change requests from the buffer to the target system.
tp put <sid>: The objective of this command is same as u201Ctp import all <sid>u201D, but this command locks the system. This command also starts and stops the SAP system, if the parameters startsap and stopsap parameters are not set to u201D u201C.
tp import <change request> <sid>: To import a single request from the source system to target system.
tp r3h <change request>| all <sid>: Using this command user can import the dictionary structures of one transport or all the transport from the buffer.
tp act <change request>|all <sid>: This command activates all the dictionary objects in the change request.
tp r3i <change request> | all <sid>: This command imports everything but dictionary structures of one.
tp sdi <change request>|all <sid>: Import application-defined objects.
tp gen <change request>|all <sid>: Screen and reports are generated using this command.
tp mvntabs <sid>: All inactive nametabs will be activated with this command.
tp mea <change request>|all <sid>: This command will activate the enqueue modules in the change request.
When you call this command, note the resulting changes to the import sequence.
Additional tp utility options:
tp check <sid>|all (data|cofiles|log|sapnames|verbose): User uses this command to find all the files in the transport directory that are not waiting for imports and they have exceeded the minimum time specified using the COFILELIFETIME, LOGFILELIFETIME, OLDDATALIFETIME and DATALIFETIME parameters of TPPARAM file.
tp delfrombuffer <request>.<sid>: This command removes a single change request from the buffer. In case of TMS, the request will be deleted from the import queue.
tp setstopmark <sid>: A flag is set to the list of requests ready for import into the target system. When the user uses the command tp import all <sapsid> and tp put <sapsid>, the requests in front of this mark are only processed. After all the requests in front of the mark have been imported successfully, the mark is deleted.
tp delstopmark <sid>: This command deletes the stop mark from the buffer if it exists.
tp cleanbuffer <sapsid>: Removes all the change requests from the buffer that are ready for the import into the target system.
tp locksys <sid>: This command locks the system for all the users except SAP* and DDIC. The users that have already logged on are not affected by the call.
tp unlocksys <sid>: This command unlocks the system for all the users.
tp lock_eu <sid>: This command sets the system change option to u201Csystem can not be changedu201D tmporarily.
tp unlock_eu <sid>: This command unlocks the system for all the changes.
tp backupall <sid>: This command starts a complete backup using R3trans command. It uses /usr/sap/trans/backup directory for the backup.
tp backup delta <sid>: Uses R3trans for a delta backup into /usr/sap/trans/backup directory.
tp sapstart <sid>: To start the R/3 system.
tp stopsap <sid>: To stop the R/3 system.
tp dbstart <sid>: To start the database.
tp dbstop <sid>: To stop the database.
Unconditional modes for TP: Unconditional modes are used with the TP program and these modes are intended for the special actions needed in the transport steps. Using unconditional mode user can manipulate the rules defined by the workbench organizer. The unconditional mode should be used when needed, otherwise it might create problems for the R/3 system database. Unconditional mode is used after the letter u201CUu201D in the TP command. Unconditional mode can be a digit between 0 to 9 and each has a meaning to it. The following is a example of a import having unconditional mode.
tp import devk903456 qas client100 U12468
0: Called a overtaker; change request can be imported from buffer without deleting it and then uncoditional mode 1 is used to allow another import in the correct location.
1: If U1 is used with the export then it ignores the correct status of the command file; and if it is used with import then it lets the user import the same change request again.
2: When used with tp export, it dictates the program to not to expand the selection with TRDIR brackets. If used in tp import phase, it overwrites the originals.
3: When used with tp import, it overwrites the system-dependant objects.
5: During the import to the consolidation system it permits the source systems other than the integration system.
6: When used in import phase, it helps to overwrite objects in unconfirmed repairs.
8: During import phase it ignores the limitations caused by the table classification.
9: During import it ignores that the system is locked for this kind of transport.
R3trans: TP uses R3trans program to transport data from one system to another in the CTS pipeline. efficient basis administrator can use R3trans directly to export and import data from and into any SAP systems. Using this utility transport between different database and operating system can e done without any problems. Different versions of R3trans are fully compatible with each other and can be used for export and import. The basis administrator has to be careful using R3trans for different release levels of R/3 software; logical inconsistency might occur if the up to date R3trans is not used for the current version of R/3 system.
The syntax for using the control file is following:
R3trans [<options>] <control file> (several options used at the same time; at least one option must be there)
For example: R3trans u2013u 1 u2013w test.log test
In the above example a unconditional mode is used, a log file u201Ctest.logu201D file is used to get the log result and a control file u201Ctestu201D, where the instructions are given for the R3trans to follow. The user needs to logon as <sid>adm to execute R3trans.
The following options are available for the R3trans program:
R3trans -d : This command is used to check the database connection .
R3trans -u <int>: Unconditional mode can be used as we have seen in the above example.
R3trans -v : This is used for verbose mode. It writes additional details to the log file
R3trans -i <file>: This command directly imports data from data file without a control file.
R3trans -l <file>: This provides output of a table of contents to the log file.
R3trans -n : This option provides a brief information about new features of R3trans.
R3trans u2013t: This option is used for the test mode. All modifications in the database are rolled back.
R3trans -c <f1> [<f2>]: This command is used for conversion. The <f1> file will be copied to <f2> file after executing a character set conversion to the local character set.
Important tips: Do not confuse the backup taken using R3trans with database backup. The backups taken using R3trans are logical backups of objects. In case something happens to the SAP system these backups can not be used for recovery. R3trans backups can be only used to restore a copy of a particular object that has been damaged or lost by the user.
R3trans -w <file>: As we have seen in the above example this option can be used to write to a log file. If no file is mentioned then trans.log is default directory for the log.
R3trans also can be used for the database backup.
R3trans u2013ba: This command is used for a complete backup. we will see in the next paragraph how to use
the control file for the backup.
R3trans u2013bd: This command is used for a delta backup if the user does not want a complete backup.
R3trans u2013bi: This option will display backup information.
The following are some of the examples of control files:
We have already learned how to use a command for the logical backup of the objects in the database. To get a complete backup the following example control file can be used.
backup all
file = /usr/sap/trans/backall
The option u201Cfile = u2026u201D is the name of the directory into which the data files are to be written. If you are taking a complete backup of DEV system then the backup file is going to look like u201CDEV.A000.bcku201D the next complete
Reward if useful
Regards
divya

Transport Layers and sharing of transport directories

Hello Experts,
We are on R/3 4.7 Enterprise extension set 1.10 with oracle 9i .
In a three tier architecture in R/3 with development , quality and production , how do we assign transport layers and how many transport layers do we need at the time of TMS configuration ?
Secondly in our R/3 three tier landscape , we hv transport directories (trans ) on every system on all the three systems ,then how are they shared with each other , i mean on wt basis do they recognise each other and transport continues frm DEV to QUA and then to production
Requested to revert at earliest as this is very urgent . points guaranteed .
Regards,
Somya

Hi ,
1) sap and Zdev are transport layers....which will be assigned by default when you configure TMS.
what does SAP and ZDEV do ?you can take it like this..standard programs..will go through sap...and customized like (Z or Y programs )will go thorough Zdev path.
the program routing is taken care automatically..(just for your info)
you never need to define transport layer between QA and PRD unless you want add one more Sandbox system for more quality testing..(normally in 3 system landscape you dont configure transport layers between QA and PRD
2) as of now in your scenerio ..its not being shared..
if you plan your DEV as transport domain controller..then in QAS system execute STMS-->system Overview >QAS double click>Communication (change transport domain to Domain controller transport domain) and also transport tool >transdir>(should poing to
<domain controller>\sapmnt\trans)
save the changes..
on the domain controller . in TMS you will see a system waiting for inclusion onto domain ..approve that..and follow the same procedure to add PRD system also..
then all the systems will share the same transport directory..
(Caution: once you setup the landscape like this ..changes to any system using STMS like QAS and DEV has to be done only on Domain controller.)
Cheers
Kamal

Different calendars for route stages? Is it possible?

HI,
Is it possible to set up 2 different calendars for this same route?
I made a route with 2 different route stages. Each of stages have different calendars. Unfortunatelly system is not checking those calendars..... System always take route calendar...
My client is shipping materials from the shipping point to the end customer each Monday and Thursday. Materials are shipped first to the main office and after that are shipped to the end customer (each Tuesday and Friday form the main office).
I made a route which has 2 different route stages: Stage 1 u2013 To Office, and stage 2 u2013 to the end customer. Each of stages have different calendar.On the sales order document system is checking only one calendar (route calendar). My client would like to see when the material will be received by the end customer, examle: You make sales order on Sunday, so it means that materials will be shipped from the shipping point on mondey, and will be received by the end customer on Tuesday.
Does anyone know the answer?
Best regards,
/Maciej K.

Hi,
Why do you need to keep calendar assigned at route level here? Did you try removing calendar from the route and leaving it only at stage level?
Regards,
Dominik Modrzejewski

Routes and Routes Determination

Hello All,
I m basically a technical person and i m doing recording for routes and routes determination.
I am facing one problem.
while executing transaction 0vtc in one system , while saving data its asking for transport request.
and when i execute the same transaction in IDES system , and when i save data it does not ask for the transport request.
Is there any config for that?
Please help me out...its required asap..
thanks,
jigs
Helpful ans will be rewarded.

Hi
not sure if this would help. but going through some of the older posts here, here's something I gathered:-
++++++++++++++++++++++
It also depends on the client settings, which is done by the BASIS guys. If the client settings are done in such a way that system should not generate requests then it will not generate a request.
If the system is created as a Sandbox then also system will not ask for a request.
using the T codes SE01 where all the list can be viewed , then select the task or transport request click on the trucj button .
+++++++++++++++++++++
hope it's a start

The loading date, transportation date and planned date on the STO are the same as Delivery dates.

Hi,
We have created a Intra plant STO (plant to plant in the same company code). The planned delivery date is 4 days. So if I create a STO today (27th march), the delivery date is 31st march (excl Saturday and Sunday).
During delivery creation, the loading date, transportation date and planned date are also coming as 31st march. The route determination for the given shipping point and route shows 2 days for transit and 4 hours for pick pack. There is no loading time maintained for the given combination.
Can you please advice why are the dates coming the same as delivery date during delivery creation without considering the duration maintained in route determination ?
Thanks!!!
Anuja

Hi,
This is a standard behavior of SAP in case of Stock Transfer PO.
If you want that the delivery date of receiving plant be transferred to supplying plant, please use BADI MD_STOCK_TRANSFER.
Hope this helps.
Regards,
Prashant

Transport Legs and route stages

Similar Messages

Maybe you are looking for