SAP R/3 v. 3.1 plan settings for workflows (transport problems)

[Kjetil Kilhavn]

We have experienced a strange problem which perhaps someone can shed a little
light on. Sorry about the length of this message, but we have found out some
more while I have been writing.
 
Some workflows we have developed exists in the development system's PLOGI table
with two plan entries. This is the case our production line development system
(maintenance) as well as in the version development system. One entry has plan
version '01', 'Current plan' (our active plan), and one entry has plan version
'.:', 'never use'. In the maintenance development there are fewer than 90
entries in PLOGI with plan '.:' and more than 300 with plan version '01'. In the
production environment the corresponding numbers are 60 and 1.678. (Objects with
type either 'T', 'TS', 'WF' or 'TS'.)
 
One of our workflows transported fine into the test systems, but for various
reasons a "collection transport" was needed to move it from test to production,
instead of exporting from the development system as normal. This failed, and our
people who work with transports were able to trace this to the fact that there
was only one object in the test system, the object with plan version '01', while
the transport looked for an object with plan version '.:' which it thus did not
find. This is how we found out that there are two plan version entries in the
development system. As far as we can understand from looking at transport object
lists and the PLOGI table entries for other workflows which have been
transported the normal situation is that the '.:' plan version of the objects
exists in the development system along with a '01' version, while the target
systems only contain a '01' plan version.
 
>From the SAP online help it seems that the workflow objects automagically are
created in the active plan version, so what's with the '.:' version? I am not
able to find out if it is something specific to my company (Statoil) or a SAP
standard. The latter seems more likely, though, since I don't think we would go
a lot of trouble to make something like this for transport purposes, _and_ since
the '.:' plan version seems to exist in all version (available in PLOGI value
list). However, one never knows. There is a possibility to copy objects from one
plan version to another, and Statoil could of course have made a fancy system to
automate this after the transports have gone through. However, as I said, I
don't think this is likely.
 
Creating a new workflow while monitoring PLOGI, this is what I found out. As
soon as the multistep task is saved an entry shows up in PLOGI, for the active
plan version. I continued to add a workflow definition, activate this
definition, define triggering event and binding. No change, there was still only
one entry in PLOGI. Then I assigned the task to a transport, and that was when a
new entry showed up in PLOGI with plan version '.:'. The transport object list
included (as usual) the '.:' version and not the '01' version.
 
Any volunteers?
--
Kjetil Kilhavn
 
-------------------------------------------------------------------
The information contained in this message may be CONFIDENTIAL and is intended
for the addressee only. Any unauthorised use, dissemination of the information
or copying of this message is prohibited. If you are not the addressee, please
notify the sender immediately by return e-mail and delete this message.
Thank you.