Copy Controls within SD

What Are Copy Controls?

Copy Controls are short programs that are used when copying from one document
to another. They consist of programs known as routines that inform the system how
the data is to be copied from the source document to the target document.
The standard system already contains a number of these routines. However, it is
possible to generate additional routines to fulfil business requirements not reached
within the standard delivered system.

You can use an existing SD document as the basis for creating a subsequent
document; for example, when creating a sales order with reference to a quotation.
In this case the system can copy all the data or only certain data from the quotation
into the sales order. Which fields are to be copied from the source document
(quotation) depends on how the copy controls have been configured.

Where are they found?

The Copy Controls are configured within the IMG. They can be located through the
following menu paths:

 Sales and Distribution -> Sales -> Maintain copy control for sales documents, or
 Sales and Distribution -> Shipping -> Specify copy control for deliveries, or
 Sales and Distribution -> Billing -> Billing Documents -> Maintain copy control for
billing
 Or alternatively, they can be accessed directly by using the following transaction
codes:

 VTAA - control for copying from sales order to sales order

 VTLA - control for copying from sales order to delivery
 VTAF - control for copying from billing doc to sales order
 VTFA - control for copying from sales order to billing doc
 VTFL - control for copying from delivery to billing doc
 VTFF - control for copying from billing doc to billing doc

How do they work?

Copy controls are setup at three levels of the sales order; Header level, Item level
and Schedule line level. The Schedule line level is only relevant when copying from
sales order to sales order or from billing doc to sales order.
The Header Copy Routines are used to copy data from the Header of the Source
document to the Header of the Target document. A number of copy routines are
required; one for General Header data, one for Partner data, etc.

It is possible to view the source code for each routine by using the F4 help function.
Highlight the appropriate routine and press the ‘source text’ (F5) button to display
the code through the ABAP editor.
Copy controls for the item level can be accessed by opening the ‘Item’ folder in the
dialog structure and selecting an item category from the’ Display View “Item”:
 Overview’ screen. Again there are several routines used here for the item level copy
controls. F1 help can be utilized to get a better understanding on how each routine
is employed.
It is worth noting, if there is a proposed item category on the target sales doc type,
then this will be the item category in the target sales document. However, if the
field is left blank, then the system will use the customer defined configuration in
transaction VOV4 to determine the appropriate item category.

In addition to the copy routines there are a number of check box controls; for
example ‘Complete reference’ at header level and ‘Copy quantity’ at Item level. F1
can again be used here to add further insight into the role of each of these fields.
At the lowest level, the Schedule Line copy control routines can be accessed by
double clicking on the ‘Schedule Line’ folder in the dialog structure when the
appropriate Item category has been selected. The schedule line routines work
similar to the header and item category routines detailed previously.

Reference Status
Documents that have been copied are assigned an updated reference status in the
copied item.
An item can have the following status:

 Not relevant – the item is not relevant for copying

 Not referenced - The item has not yet been copied.
 Partially referenced - The entire item quantity was not copied.
 Fully referenced - The entire item quantity has been copied or the entire item
quantity has not been copied, but the item cannot be referenced further.

To display the reference status:

 Selecting Header -> Status for the status of the entire document. (Field VBUK-
RFSTK)
 Selecting Item -> Status for the status of the line item. (Field VBUP-RFSTA

What Fields are being copied?

Note that there are several copy routines at each level of the customizing, header,
item and schedule line.

Finding out which fields are being copied can be achieved by examining the source
code in the ABAP Editor - transaction code SE38.

SAP Memory:
ABAP MEMORY AND SAP MEMORY :
CURR_TB TYPE STANDARD TABLE OF ZII_TCURT WITH HEADER LINE.
EXPORT CURR_TAB TO MEMORY ID 'CTAB'.
IMPORT CURR_TAB TO CURR_TB FROM MEMORY ID 'CTAB'.
ABAP MEMORY-It uses export and import parameters when an active internal
session calls another internal session within a single main session .
SAP MEMORY- It uses set and get parameters to pass the data from one main
session to another main session.
SET PARAMETER ID <pid> FIELD <f>.
GET PARAMETER ID <pid> FIELD <f>.
SAP memory is a memory area to which all main sessions within a SAPgui have
access. You can use SAP memory either to pass data from one program to another
within a session, or to pass data from one session to another. Application programs
that use SAP memory must do so using SPA/GPA parameters (also known as
SET/GET parameters). These parameters can be set either for a particular user or
for a particular program using the SET PARAMETER statement. Other ABAP
programs can then retrieve the set parameters using the GET PARAMETER
statement. The most frequent use of SPA/GPA parameters is to fill input fields on
screens

ABAP memory is a memory area that all ABAP programs within the same internal
session can access using the EXPORT and IMPORT statements. Data within this area
remains intact during a whole sequence of program calls. To pass data
to a program which you are calling, the data needs to be placed in ABAP memory
before the call is made. The internal session of the called program then replaces
that of the calling program. The program called can then read from the ABAP
memory. If control is then returned to the program which made the initial call, the
same process operates in reverse.
External session: - when user logs on to R/3 system, the system Creates a new
terminal session called external session. E.g. System Session.
Internal session: - created by calling a transaction (with CALL TRANSACTION), a
dialog module (with CALL DIALOG) or a report (with SUBMIT or RETURN).
In general each user can open up to six R/3 windows in a single SAPgui session.
Each of these windows corresponds to a session on the application server with its
own area of shared memory.
The first application program that you start in a session opens an internal session
within the main session. The internal session has a memory area that contains the
ABAP program and its associated data. When the program calls external routines
(methods, subroutines or function modules) their main program and working data
are also loaded into the memory area of the internal session.
Only one internal session is ever active. If the active application program calls a
further application program, the system opens another internal session. Here, there
are two possible cases: If the second program does not return control to the calling
program when it has finished running, the called program replaces the calling
program in the internal session. The contents of the memory of the calling program
are deleted. If the second program does return control to the calling program when
it has finished running, the session of the called program is not deleted. Instead, it
becomes inactive, and its memory contents are placed on a stack.

The memory area of each session contains an area called ABAP memory. ABAP
memory is available to all internal sessions. ABAP programs can use the EXPORT
and IMPORT statements to access it. Data within this area remains intact during a
whole sequence of program calls. To pass data to a program which you are calling,
the data needs to be placed in ABAP memory before the call is made. The internal
session of the called program then replaces that of the calling program. The
program called can then read from the ABAP memory. If control is then returned to
the program which made the initial call, the same process operates in reverse.

All ABAP programs can also access the SAP memory. This is a memory area to which
all sessions within a SAPgui have access. You can use SAP memory either to pass
data from one program to another within a session, or to pass data from one
session to another. Application programs that use SAP memory must do so using
SPA/GPA parameters (also known as SET/GET parameters). These parameters are
often used to preassign values to input fields. You can set them individually for
users, or globally according to the flow of an application program. SAP memory is
the only connection between the different sessions within a SAPgui.

>>>>>>>