1) Remember, this is a "pull" transaction, so you'll need to be logged into the target client when executing SCC1.
2) Make sure the source form is in "Active" status.
3) You may wish to specify the transport task linked to the form (and not the overall transport request) in SCC1; that way, you can ignore the task checkbox option.
4) If you get a cryptic error message – or a "form not found" message – when trying to bring up the form in the target client, check your settings and try using SCC1 again. In my experience, the error should vanish the next time around.
5) If all else fails, and there seems to be a corrupted version of the form hopelessly stuck in the target client, obtain the needed permissions to have the form deleted in – and ONLY in – the target client; then start the SCC1 process again.
6) The above applies to SAPscript forms only; Smart Forms are client-independent so SCC1 is not required.
Another caveat: Often, the development client used where forms are tested is not the same client where the forms are changed. Thus, there may be a need for frequent use of SCC1 as the form is refined. That being the case, note the default transport number which appears each time you call up this transaction. It might not be the last one you entered, but rather the last one entered by another user.
I know it sounds strange, but I have seen this happen in an R/3 Enterprise environment before. I am not sure if it is a feature or a bug! So, if you get into the rhythm of frequent trips to SCC1, it is possible to accidentally pull in the wrong object by accepting the default entry there. It may not happen to you, but I thought I'd mention it just in case.
This was first published in December 2005