Client dependent SCRIPT transporting to QA systems?

Hi,
We hv clients like below,
clinet_gold (100- Gold clinet)
clinet_EU for Europe region
clinet_US for US region.
We hv a Z_Script_Invoice, meant (developed and using) for Europe region i.e. in clinet_EU
We r supposed to do changes (create TR/CR) only in clinet_gold (100- Gold clinet).
I got a requirement of fixing some issue in this script.
So, I made changes in the script in clinet_gold (100- Gold clinet), so TR/CR is created here in this client, fine.
Then, I logged in to clinet_EU>SE71->Menu->Utilities>COPY FROM CLIENT.......so, I entered the selection screen fields and OVER WRITTEN the existing script, so that, my changes are reflected, fine.
So, now, the created TR/CR is released to QA, so, pls. let me know,
1) Where and Where I can see my changes in QA boxes? in perspective of clinet_gold_QA, clinet_EU_QA?
2) Or by default this TR/CR will get imported in ALL test (QA) systems?
Thank you

HI
you should not do client_eu->se71.......
You should go to client_eu
execute the transaction scc1
and provide the transport request number which u have create for changes for script in client_gold.
and check the check box immediately
this will bring the changes from clent client_gold to client_eu.
se71->goto->copy from clients is used when we create new script from already existing.
hope this works for you.
all the best.

Similar Messages

Urgent:Why Script is cliend dependant and smartform is not client dependant

Hi all,
Can any one pls tell me why script is client dependent and smartform is not client dependant.
Please give some real time examples in brief
regards
tapu

Hi
DIFFERENCE BETWEEN SMARTFORMS AND SAPSCRIPTS ARE:
1. script is client dependent one while smartform is client independent.
2. In scripts we have to write print program while in smart forms it is not necessary.
3. In scripts we can print background logo while in smartforms we cant print background logo
4. In scripts we have 99 main windows while in smartforms we have only 1 main window.
5. In scripts we should write paragraph format otherwise we cant execute program while in smartforms no need to create paragraph formats .
6. In scripts we can print the text in only two character formats.
while in smartforms we can do with more.
7. In scripts we dont have line types while in smartforms we have linetypes.
8.Multiple page formats are possible in smartforms which is not the case in SAPScripts
9.It is possible to have a smartform without a main window .
10.Labels cannot be created in smartforms.
11.Routines can be written in smartforms tool.
12.Smartforms generates a function module when activated.
SAPscript technology is based on a mainframe product from the 1980s, while Smart Forms have only been around since (roughly) 2001. With that sort of time gap, there are bound to be significant differences between the two tools. Client dependence is a fundamental one. Although SAPscript has had some incremental improvements over time, its forms have always been -- under the hood -- relatively ...
also refer
difference between smartforms and scripts
Diff betwen Scripts & smartforms
advantages of smartforms over scripts
Whenever a smartform is created, a funciton module gets generated. So, we can access the smartform in different clients. But in case of scripts, it is not so.. So, scripts are client dependent.
Smart Forms are implemented using the Function Module SSF*, and all the logic lies in the FM. Function Modules are client independent objects, so Smart forms are also client independent
SAP Scripts are the Layout Forms that you design and there are aviable in the client in which you have created them, for making them available you have to copy across the clients.
Because, Sapscripts are saved in ITF format as text in client dependant tables STXH and STXL. smartforms are not saved in client dependant tables and visible across clients.
SAPscript technology is based on a mainframe product from the 1980s, while Smart Forms have only been around since (roughly) 2001. With that sort of time gap, there are bound to be significant differences between the two tools. As you have noted correctly, client dependence is a fundamental one.
Although SAPscript has had some incremental improvements over time, its forms have always been -- under the hood -- relatively passive objects, with minimal embedded logic. These forms were designed to be driven and controlled by ABAP programs, much in the way ABAP programs read in database tables to produce reports; if you ever download a SAPscript form (e.g., via utility program RSTXSCRP), and look at the portable text file it produces you'll see what I mean. Many text objects (e.g., invoice header texts) are bound directly to documents which are client-dependent, so it makes sense for these text objects to also be client-dependent. From a complexity standpoint, SAPscript forms are close enough to these text objects where I can see how it made sense at the time to make them client-dependent too.
Conversely, a Smart Form is significantly more robust and complex. For instance, it can contain program nodes and nested tables with patterns. When a Smart Form is compiled, it generates an ABAP function module and these are always client-independent. This is appropriate, given that this form has more in common with an ABAP program than its predecessor. For instance, when a print program calls a Smart Form, the form itself takes over to produce output, without any further direction from the print program. In fact, the join is so seamless that I often find myself using a Smart Form's Initialization section for logic to handle any data gathering not handled by the print program. I would never even think to attempt this with SAPscript.
I suspect several factors figured into SAP's decision to make Smart Forms client-independent, including customer feedback. There are significant advantages to client-independence. For instance, a change made in one development client happens immediately across all development clients. Among other things, this means we don't have to waste time figuring which client contains the most recent version -- they all do! In addition, transporting Smart Forms is easier, since we can safely bundle them together in the same transport as their client-independent print programs (no worry about mixing client-dependent and independent objects).
Reward points for useful Answers
Regards
Anji

What will be the diff.between Custiomizing(C),Client dependent(E) in BSI System

HI Experts,Can you just clarify in this two components or table names used how it wil be helpful to us. When we have to use these two in updation of taxation updates(TUB)-Tax Updations Bulletin.
So, please give me clarity about these two.
Thanks&Regards
Rajeshwari

Hi
Customizing entries are those which are created by customer himself not delivered via TUBS.If the tables where you have created custom entries are having any new table delivered care must be taken not to import the whole cumulative transport which will then overwrite your custom entries. Custom entries ware not in client 000 they only reside in your development system
Easiet way to decide if a table is client dependent or client independent is to check if it has client as one of the kep field.If it has then it is a client dependent else it is client independent
Hope this makes sense
Regards
Ajay

Transport client dependent table and data

Hi,
How do you add a client dependent table and the entries inside to a transport?
Please help.
Thanks,
John
Edited by: Alvaro Tejada Galindo on Feb 20, 2008 4:33 PM

Hi there!!!
go to Txn SE09, create a request type "Workbench Request".
1 . Go to the Sub task, select the 'Objects' Tab.
2. Enter the Program ID - R3TR
 Object - TABU
 Object Name - (Your Required Table Name)
3. Now Press the Function Button on the right, Enter the Table Key, which is nothing but the value of the primary key fields of row to be sent, typed as one.
eq. to send material number 1 from MARA in client 100, following would be the table key:
100000000000000000001
where first 3 characters are for the client
and the remaining 18 characters are for the material number.
Another simple method would be to-
1. execute Txn se16 and display the required Table Contents.
2. Select the rows to be sent, by selecting the check boxes corresponding to those rows, and then selecting the Menu Option
Menu->Table Entry -> Transport Entries.
3. Create a request.
 the enties would be included in the request.
Hope This solves your Problem. <REMOVED BY MODERATOR>
Edited by: Alvaro Tejada Galindo on Feb 20, 2008 4:34 PM

Why SAP Script client-dependent but Smartform is client independent

Hi All,
What are the fundamental reasons for justifying that SAP Script is client-dependent but Smartform is client independent ???
Regards
jaman

hi,
why script is client dependent?
the reason is:
in script, to display some table data, we use text elements, where the text elements access the dictionary tables data. there the table from which we are fetching data, that may be a client dependent table, so first the text elements became client dependent. as script use text elements, script also became client dependent.
hope u got the point. to b simple, the text elements r client dependent, there fore scripts also became client dependent.
smartforms are client independent. bcoz it doesnt use any text elements. it will be executed through a function module, as you know function modules are client independent, the smartform also became client independent.
hope ur clear, if any doubts, plz post them back.
reward if helpful.

Why SAP Script is said to be client dependent

Hi friends,
Can you tell me Why SAP Script is said to be client dependent .
please let me know it
Thank you

Hi,
Please go through this link,
http://searchsap.techtarget.com/expert/KnowledgebaseAnswer/0,289625,sid21_gci1190925,00.html
Hope this will give you a clear idea.
Feel free to revert back.
--Ragu

Why SAP script is client dependent ?

why SAP script is client dependent ?

Hi,
By design, SAP script is a word processing tool which displays data on the form with the help of text elements where the logic of those is written in the print program and Forms were designed to be driven from print program, hence are often termed as client dependent. Smart forms are client independent. Bcoz it doesnu2019t use any text elements. It will be executed through a function module. When a print program calls a Smart Form, the form itself takes over to produce output, without any further direction from print program.
Pelase reward if useful.
Bye

What makes scripts client dependent

Hi all can anyone clarify me on waht makes scripts client dependent smart forms client independent.
Is the graphic that we do in in SE78 client independent or client dependent.
please reply..
Thanks & Regards,
Saroja.

hi,
in scripts we can use graphics but in smartforms we can create color ones also.....n even background is pssible...
in sap scripts multiple layouts is not pssible whereas its possible in smartforms....even we can have more than one main window in smartform but in scripts ...a form can ahve only one main window.....
background is not possible in scripts whereas it is possible in smartforms...
these r things tht makes scripts client dependent...
if u feel its a worthy answer then dont forget to reward with points...
with regards,
madhuri.

Why SAP Script are Client Dependent, Smartforms are client-independent.

why SAP Script are Client Dependent,Smartforms are client-independent.
Edited by: Srinivasa Reddy Ariga on Oct 27, 2008 12:28 PM
Edited by: Srinivasa Reddy Ariga on Oct 27, 2008 12:49 PM

Before you do anything else, read this: Welcome and Rules of Engagement
Google is your friend. Try keywords smartforms client dependent Next time - search first and ask second.
oh, and it helps to get the correct forum...

Client dependent vs client independent

Hi,
CASE-1 :
there are two clients using one Application
Server .
q1) Are scripts and smartforms client-dependent/independent.
CASE-2 :
There are two clients using different Application Servers
q1) Are scripts and smartforms client-dependent/independent.
if smartforms are client independent so why am not able to see it
from dev to qat without trasporting smartform.
as we know smart forms are client independent so under what condition i can see my smartforms in another client without transporting to other client.
please help me out.

Scripts are always client dependant and Smart forms are
client independant.
You will be able to see your smartforms in all the clients in the same application server.
For examples in DEV system there might be three clients
100, 300, 500. So you will be able to see ur smartforms in
all the three clients.
But in order to see SapScripts you will have to transport the form from each client to another.
To see the smartform in you QA server which is a different appplication serer you will have to transport objects.
Regards,
Sudhir Atluru
Reward points for helpfull answers

Use of client dependent tables

Hi Gurus,
I have read many threads on difference between client dependent and independent data/objects etc.
But, someone tell me please, wheat exactly the 'Use or Advantage' of client dependent tables/data.
Thanks in advance.
V

HI,
The use of client dependent tables is that if data in one table of a particular client is updated then that data wont be seen in any other clent it provides a security to the data we retrict users with their authorizations in differen clients
When you log on to an SAP System, you log on to a particular client of this system. Any activities you carry out in the system are always carried out in one client. When you plan your SAP system landscape, you must consider which clients you need for which activities.
By assigning activities to be performed in a client, you give each client a particular role. This section describes the most important client roles.
Since you need to adapt the SAP software for your own business needs, each SAP system landscape requires a client where Customizing settings, and possibly ABAP Workbench developments, can be made. This client is known as the Customizing and development client, or Customizing client for short. The abbreviation CUST is used for this client.
Before you can use the Customizing settings and Workbench developments productively, you need to test them extensively for errors. Any faulty settings can seriously disrupt productive operations, and at worst, lead to the loss of productive data. The integrated nature of the various SAP applications means that there are many dependencies between the different Customizing settings. Even an experienced Customizing developer may not discover these dependencies immediately. The correctness of the settings can only be guaranteed with extensive testing. The client where these tests are made is the Quality Assurance Client, QTST for short.
A separate client is required for productive use of the SAP System. So that this client can be used without disruption, it is essential that no Customizing settings or Workbench developments are made here, and also that no tests are carried out. This client is known as the Production Client, PROD for short.
These three clients, CUST, QTST and PROD, are the central clients that exist in every system landscape. Standard system landscapes have precisely one client for each of these client roles.
We recommend that you make all your Customizing settings in a single Customizing client, and then use the CTS to transport them to the other clients.
We also recommend that you do not make any Customizing settings or Workbench developments in the quality assurance or production clients. You can make sure of this by making appropriate client settings.
In addition to the central clients, you can also set up other clients for other tasks. However, you must remember that each extra client takes up additional system resources (main memory and database space). They also need to be administrated. For example, you need to set up and administrate access authorization for the users, and also distribute any changes to other clients with the CTS. You must weigh up the advantages and disadvantages of setting up other clients.
Examples of other client roles are:
Development test client (TEST): Developers can use this client to test their Customizing settings and Workbench developments, before they release their change requests. In this client the developers can create test application data for realistic tests. If they discover errors, they can remove them in the Customizing client. A development test client is always set up in the same SAP System as the Customizing client. This means that any changes that are made to cross-client data in the Customizing client are also immediately visible in the development test client. Changes to client-specific data are copied from the Customizing client to the development test client using a special client copy function. The client copy function uses the unreleased change requests from the Customizing client to do this. The development test client is set so that you cannot make changes to Customizing data and Repository objects.
Prototype or sandbox client (SAND): You can use this client to test any client-specific Customizing settings if you are not sure whether you want to use them in this form. Any settings that you want to keep are then entered in the Customizing client. To prevent conflicts between the prototype client settings and real settings in the Customizing client, you cannot make changes to cross-client Customizing data and Repository objects in the prototype client. The CTS does not record changes made to client-specific Customizing data, and does not transport them from the prototype client. You can make sure of this by making appropriate client settings.
Training client (TRNG): To prepare end users for new functions that are to be transported into the production client, you can set up a training client. The users can use the new functions in this client with specially created application data. This client is set so that you cannot make changes to Customizing data and Repository objects.'''
plzz reward if this information is usefull to u plaa dont forget to reward

SAP "Z" Script Transport from DEV -- TO-- QTY Server

Experts....
We have created a Z SAP Script. in DEVELOPMENT CLIENT : 100
We have successfully transported the changes from DEVELOPMENT CLIENT to UNIT TESTING CLIENT 120 in the same system thru SCC1.
UNIT TESTING RESULTS are OK, and our DEVELOPER has given a request to import into production.
But we imported the request, But changes are not reflecting in QUALITY.
I found below thread but i failed to understand...the last steps...
Can any one please help in this regard.
SAP Script transport issue
Rgds

Finally.....We could able to close this....
Weunderstood....to do inital fill in target client we do it from "000" clinet to "XXX" target clinet
once it is available ..the rest all goes with CLASSIC TRANSPORT APPROACH.
Not sure why the inital Transport request with changed did nor worked.
With the help of ABAP Expert...we just reactivated the in SE71 and added into request
imported the request into Quality & Worked..
When the inital fill is completed for SAP Standard ,
the rest of changes to is managed thru SAP Classic Transport Method.
For "Z" script..even no where connected with "000" client.
As we fixed with above assumptions...we conclude as above....
i request any expert to correct us if our assumptions in wrong direction.
Rgds

Client dependent and client independent in ALE

I am going through pdf learning of an ALE scenario,i couldnot get wat is meant by client Independent and client dependent.
How can i conclude
Create message type (WE81){color:green} Client independent {color}
To create a new message type, follow these next few steps:
u2022 Enter transaction WE81 (ALE -> Extensions -> IDoc types -> Maintain message type for intermed. Structure -> Create logical message type)
u2022 Choose Create logical message type by double clicking on it
u2022 Click on change icon to enter change mode
u2022 Click on New entries to add a new type
u2022 Enter the required message type, in our case it is ZINVRV and an appropriate description
u2022 Save and exit.
Your message type has now been created. The next step will be to link it to the IDoc.
2.2.1. Link message to IDoc type (WE82 & BD69) {color:green} Client independent {color}
To link the message type to the IDoc type follow these next few steps:
u2022 Enter transaction WE82 (ALE -> Extensions -> IDoc types -> Maintain message type for intermed. Structure -> EDI: Message Types and Assignment to IDoc Types)
u2022 Click on change icon to enter change mode
u2022 Click on New entries to create the link
u2022 Enter the message type ZINVRV and the BasicIDoc type as ZINVRV01
u2022 Save and exit
u2022 Enter transaction BD69 (ALE -> Extensions -> IDoc types -> Maintain message type for intermed. Structure -> Assign message type to IDoc for ALE)
u2022 Click on change icon to enter change mode
u2022 Click on New entries to create the link
u2022 Enter the message type ZINVRV and the BasicIDoc type as ZINVRV01
u2022 Save and exit
Your IDoc is now linked to your message type. We still need to link object types and add the message to the model before we can use the message.
2.2.2. Maintain object type for message type (BD59) Client independent
The ALE objects are used to create links between IDocs and applications objects, to control the serialisation, to filter messages in the customer model and to use listings.
For our own message type and IDoc you must maintain object types for the links.
If you want to check the serialisation for the message type, then you must maintain object types for the serialisation. If no serialisation object has been maintained for a given message type, then the serialisation will not be checked for this message type.
To add an object type to our message type, follow these next few steps:
u2022 Enter transaction BD59 (ALE -> Extensions -> ALE object maintenance -> Maintain object types)
DOC NAME: ALE_SCENARIO_DEVELOPMENT_PROCEDURE
Version 1 Page 6 of 16
ALE Scenario Development Guide
u2022 Type in your message type ZINVRV and press enter
u2022 Click on New entries
u2022 Enter your object type, LIFNR (We need to use the vendor as a filter object), the segment name where LIFNR resides, Z1INVRV, a number 1 for the sequence followed by the actual field name LIFNR
u2022 Save and exit.
You have now created an object that weu2019ll use as a filter object in the customer model to direct the flow of messages to the various logical systems based on the vendors in the filter of the message type ZINVRV.
We now need to add our new message type to the distribution model.
2.3. Configuring the Distribution Model
This task is performed on your ALE reference client.
2.3.1. Manual Configuration (BD64) {color:green} Client dependent {color}
To manually configure the customer distribution model, read the ALE configuration procedure, and follow these steps:
u2022 Perform the Maintain customer distribution model directly function. (ALE -> Distribution customer model -> Maintain customer distribution model directly)
u2022 Specify the customer model you want to maintain and the logical system that is to be the sender of the messages OR create a new model. (Create model ALE with logical system ALELS1C400)
u2022 Choose the receiving systems to which the sending system must forward message type ZINVRV to.
u2022 For each receiving logical system allocate the message type necessary for communication to the receiving systems as per ALE configuration procedure.
u2022 Create filter objects (in our case LIFNR as the object type with the associated vendor number, 0000018001 with leading zeros, in the object area) for the message types.
u2022 Save the entries.
Refer my query within color:green
Edited by: aditya sharma on Jul 14, 2010 12:57 PM
Edited by: aditya sharma on Jul 14, 2010 1:01 PM

A client is an independent business unit within an R/3 System, Data in the R/3 are classified as cleint-Dependent and client-independent.
Client-independent data such as ABAP Programs, R/3 repository objects throught the entire system. Other data is client-dependent. meaning, it can be viewed from one client. Cleint-dependent data includes customizing application and user data.
Eg.
Scripts are client dependent, means the changes done to SAP scripts in particular client will not be reflected in other client.
Smartforms are client independent, means changes done in one client will be reflected in all the clients.
Server : ECC6
Client : 100 , 200 , 300 , 400
Now suppose you have developed report in DV server client 100.
Then you will be able to see that in all clients.
Hence this is called as client independent. You can change anywhere and changes will be reflected to all ...
Now suppose you have developed a script in DV client 100.
You will not be able to see that in client 200 or 300 or 400 unless ytou copy that from client since it is client dependent.

Hi abapers doubt in client dependent and independent

i am having a doubt could you please explain me
i created a dependent table using mandt in client 100(development).
if transfered this table to quality 110(quality). it is possible access data?
when i see development 100 it's having data but i can't find any records in quality it's not showing the records.
how we can see data in quality110 , if table is dependent.

Hi Sayeed,
Data in the table will only we transported accross a system landscape if you have marked the recording routine in your development system.
Regards,
John.

List of client dependant and independent

Hi All,
Can any one let me knw the list of objects which are client dependent and which are not.
Thanks,
Vibha

Hello Vibha
The following list shows the client-dependent repository objects:
LIMU     FSEL     Field Selection
LIMU     VARI     Report Program System Variant
R3TR     COC1     CO: Cost Centers
R3TR     COC2     CO: Activity Types
R3TR     FORM     SAPscript form
R3TR     LODS     HRDSYS: Logical information object client-dep. table E SYST
R3TR     PCYS     HR: Transport standard personnel calculation rules
R3TR     PHDS     HRDSYS: physical information object client-dep. table E SYST
R3TR     SBNL     Logical Information Object for BDS
R3TR     SBNP     Logical Information Object for BDS
R3TR     SBNR     BDS: Relationship Between Information Objects
R3TR     SBPL     Logical Information Object for BDS: Bid Invitation
R3TR     SBPP     Physical Information Object for BDS
R3TR     SBPR     BDS: Relationship Between Information Objects
R3TR     SBRL     Logical Information Object for BDS
R3TR     SBRP     Physical Information Object
R3TR     SBRR     BDS: Relationship Between Information Objects
R3TR     SBSL     Logical Information Object for BDS
R3TR     SBSP     Physical Information Object
R3TR     SBSR     BDS: Relationship Between Information Objects
R3TR     SBTL     Logical Information Object for BDS
R3TR     SBTP     Physical Information Object
R3TR     SBTR     BDS: Relationship Between Information Objects
R3TR     SBWL     Logical information object for BDS
R3TR     SBWP     Logical information object for BDS
R3TR     SBWR     BDS: Relationship between information objects
R3TR     SRHL     SRM: Hierarchical Lists
R3TR     SRLD     Language-Dependent Client-Specific Retrieval Index Objekt
R3TR     STYL     SAPscript Style
In contrast to client-independent repository objects which can be imported into any client these objects must be transported into their specific target client.
Regards
Uwe

Client dependent SCRIPT transporting to QA systems?

Similar Messages

Maybe you are looking for