Enqueue Errors - ECC 6.0 (Responding to events in a timely manner)
Catherall, Andy
andy.m.catherall at cadbury.com
Fri Jun 18 10:21:19 EDT 2010
All
I now have an important update with respect to how to get workflows with
forks/parallel sections to respond to events in a timely manner.
Background, in brief:
1) When using the 'standard' locking mechanism provided in workflow
these days, you can't expect a parallel branch to react to an event
ASAP, as one of the other branches may be in progress and may have
locked out the entire workflow. The event will be put into a holding
pattern and ignored by the workflow until some indeterminate future
time. This can be a problem if you would like to ensure that the
workflow instance does not continue to process along a path that is no
longer valid.
2) It is possible to modify the locking mechanism so that you can select
more 'appropriate' locking behaviour for your needs (see note 1122756
https://service.sap.com/sap/support/notes/1122756). I was making use of
L3 so that if a document was modified, my workflow responded to that
change immediately, and not only when RSWWERRE happened to run again.
However...
3) With this alternate locking mechanism, I found that my workflows were
continuing to spawn new work items even *after* the parent workflow
itself was at a complete state! This was deemed by the various powers as
being a 'bad thing'!
**NEWS**
========
OSS 1477088 (https://service.sap.com/sap/support/notes/1477088) has just
been released to resolve this problem. All should now be fine with
creating workflows that respond to events as if they were 'interrupts'
again.
For reasons I won't go into, I now no longer have access to an ECC6
environment to 'play' with. Therefore, I have not personally been able
to prove this fix. Hopefully, it will work for you!
Cheers
Andy
-----Original Message-----
From: sap-wug-bounces at MIT.EDU [mailto:sap-wug-bounces at MIT.EDU] On Behalf
Of Catherall, Andy
Sent: Wednesday 03 March 2010 10:20
To: SAP Workflow Users' Group
Subject: RE: RE: Enqueue Errors - ECC 6.0
Thanks Florin
I checked again, and can confirm that RSWWERRE is running in that
environment.
I understand that the 'open' work item cannot be influenced by the work
flow at that moment, though the fact that RSWWERRE did not subsequently
close the work item is odd. However, the fact that subsequent new work
items are free to be created, within the context of a COMPLETED
fork/workflow surprises me.
Across all my workflows, I cannot rely upon the termination even being
triggered at the moment a particular work item is in progress. The
'WAIT-FOR-EVENT' in the forks was supposed to ensure that the overall
process was subject to the appropriate event, and responded correctly to
it.
On the positive side, the L3 setting does seem to be getting me closer
to this functionality again.
Cheers
Andy
-----Original Message-----
From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf
Of Florin Wach
Sent: Tuesday 02 March 2010 10:14
To: SAP Workflow Users' Group
Subject: Re: RE: Enqueue Errors - ECC 6.0
yeah, I find these work items completed afterwards, when the report
RSWWERRE ran.
That behaviour seems to be typical, when using a parallel branch, where
on one thread a work items is in process (and currently locked by the
user) and the other thread ends the whole thing but cannot change the
workitem's status.
In such cases it's better to create a terminating event for the work
item, instead of ending it through a second brach.
Bw,
Florin
-------- Original-Nachricht --------
> Datum: Tue, 2 Mar 2010 02:59:19 -0700
> Von: "Catherall, Andy" <andy.m.catherall at cadbury.com>
> An: "SAP Workflow Users\' Group" <sap-wug at mit.edu>
> Betreff: RE: Enqueue Errors - ECC 6.0
> I have come up with an interesting problem whilst testing my L3 lock
> solution:
>
> Whilst my workflow has 'correctly' responded to the event... the
> WAIT-FOR-EVENT has fired, the fork and loops etc have ended. The
> workflow has been set to COMPLETED... but...
>
> I still have work items in a terminated branch of the terminated fork
> in a state of 'In process' - ok, in part, this is possible as I was
> executing the work item when the event was fired off. The workflow
> cannot end that work item...but of much greater concern, when I
> process these to completion, the workflow will spawn the next work
> item!!...and the next, and the next...
>
> In a COMPLETED fork. In a COMPLETED workflow.
>
> Anyone come across that before?
>
> An OSS is in progress.
>
> Thanks
> Andy
>
> ________________________________
>
> From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On
> Behalf Of Catherall, Andy
> Sent: Thursday 25 February 2010 17:44
> To: SAP Workflow Users' Group
> Subject: RE: Enqueue Errors - ECC 6.0
>
>
> All
>
> An update on an ancient thread.
>
> I had opportunity to talk to an SAP webflow developer the other week
> (ie someone who builds the actual webflow engine) and got some
> insights into the enqueue issue.
>
> To summarise my problem:
> In the move from 4.6c to ECC6, workflows appear to have lost a degree
> of their 'event handling' abilities. Yes, we can capture events all
> over the place now; and we can raise local events too.. but, the
> enhanced enqueing means that a workflow will not necessarily respond
> to that event at the time that it is raised.
> This might be due to the workflow being locked to activities going on
> in other branches of a fork, for example.
>
> Worse, it will not necessarily then respond to that event at the
> earliest possible opportunity after the event has been raised. You
> might expect that when the work item [that was locking the workflow]
> completed, the webflow engine would review the overall status of the
> workflow before the next step was started, and recognise that an
> applicable event had been received elsewhere in the workflow, and
> therefore not move on to the next step. But it does not do this.
>
> Instead, we have to wait for RSWWERRE to run, periodically, and try to
> re-present the event every so often. If the workflow is busy again,
> the event is put back on the queue for later. In the meantime, the
> rest of the workflow can merrily continue, oblivious to the event
> effectively knocking at its door.
>
> Instead of the workflow using the event as an interrupt, so that it
> responds in a timely manner to activities that are going on within the
> wider SAP system, the 'event' has become a rather ineffective,
> delayed, tool, which cannot be relied upon to ensure that
> no-longer-relevant steps are not shown to users.
>
> This particular issue was having quite an effect on a number of my
> workflows that rely upon events to guide their behaviour. Whilst I'm
> not out of the woods yet, I have made some progress.
>
> The lesson
> The lesson I received, then, was with respect to the various settings,
> on the 'Locking Properties' tab, on the 'Control' tab, of the 'Version
> Dependent' tab(!), of the workflow header. I have struggled to find
> information on what the various options do.
> The great lesson was that the 'old' 4.6c way of operating is
> effectively embodied in L3. This will cause the lock to be taken only
> at the point where the step is transitioning to or from the workflow -
> at the point where the containers are being updated, for example. This
> means that a wait-for-event step can now respond to the event, and can
> now updated the workflow that it lives in. It can now cause the fork &
> the workflow to complete! Fantastic.
>
> The L2 and L1 options are similar, but only cause the locks to be
> released during tasks of type W and B, as applicable.
>
> Testing continues, but I thought I'd share this.
>
> Thanks
> Andy
>
>
> ________________________________
>
> From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On
> Behalf Of Catherall, Andy M
> Sent: Friday 14 November 2008 15:47
> To: SAP Workflow Users' Group
> Subject: RE: Enqueue Errors - ECC 6.0
>
>
> Hi Sue
>
> Thanks for the info. Can I just check some aspects, as what I am
> seeing seems subtly different.
>
> 1) The main fork has a couple of dialog tasks. However, the other
> branch of the fork only has a 'wait-for-event' followed by a
> background-step, not a dialog task.
> 2) The error in the log is being reported against the 'wait for event'
> step. It is failing to complete due to us having a lock on the
workflow.
> 3) The next step to be created is the subsequent dialog step in the
> main fork. Following the thread below, we turned off 'Advance with
dialog'
> days ago.
> 4) Whilst the workflow at large, and even the WFE work item, do not go
> into error, several moments (sometimes over an hour) later, the WFE
> finally completes and the fork terminates. We suspect the 'reprocess
> errored workitems' job, but the varying delay has us confused.
>
> We've run several tests around this, and it seems to be consistently
> the case that a 'wait for event' cannot respond to an event if a user
> happens to still be in the work item (which, as this is now a racing
> issue, may well be the case).
>
> This seems to be a major flaw, but I guess there must be some
> alternative approach, as the community at large does not appear to be
> making much noise about this. Are we being forced down the route of
> capturing events at the WF header level? Does this even work, if the
> workflow is still locked anyway?
>
> Our next test is to see if the WFE completes when it is the only task
> in a subflow (and that subflow positioned in place of the WFE in the
fork).
> It seems rather bizarre if this approach works!
>
>
> Thanks for any advice anyone can give, and have a good weekend!
>
> Cheers
> Andy
>
> ________________________________
>
> From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On
> Behalf Of Sue Doughty
> Sent: Wednesday 12 November 2008 14:44
> To: SAP Workflow Users' Group
> Subject: RE: Enqueue Errors - ECC 6.0
>
>
>
> Hi Andy,
>
>
>
> You can only have one dialog task in one path of a fork. What we had
> to do was to create sub-workflows for all but one of the dialog tasks
> in the fork. That was a big project to go into all workflows and make
> that change.
>
>
>
> The waiting on events in parallel forks will work....you just cannot
> have a dialog task under the wait step. If you make your dialog task
> underneath the event a sub-workflow, then your events will work fine.
>
>
>
> SAP was adamant that it was working as designed and would not consider
> modifying it.
>
>
>
> Regards,
>
> Sue T. Doughty
>
> SAP Workflow Specialist
>
> Old Dominion Freight Line, Inc.
>
> 500 Old Dominion Way
>
> Thomasville, NC 27360
>
> Phone: (336) 822-5189
>
> Toll Free (800 ) 432-6335, ext. 5189
>
> Email: sue.doughty at odfl.com
>
> ________________________________
>
> From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On
> Behalf Of Catherall, Andy M
> Sent: Wednesday, November 12, 2008 6:36 AM
> To: SAP Workflow Users' Group
> Subject: RE: Enqueue Errors - ECC 6.0
>
>
>
> All
>
>
>
> Context
>
> -----------
>
> We have recently started making changes to a workflow in ECC6. The
> original design existed in our 4.6c system and has worked for years.
> As the SAP instance was upgraded, the workflow remained. We have then
> copied this workflow in ECC6, and are developing on the copy. The
> workflow handles parked MM invoices.
>
>
>
> Issue
>
> --------
>
> This workflow has a main fork, and two parallel forks. These parallel
> forks handle the BUS2081-POSTED and BUS2081-DELETED events. The main
> fork allows the user the opportunity to resolve the issues with the
> invoice and Post it (if complete) or save it (if still awaiting more
> information). There is an 'advance with dialog' step immediately after
> the invoice edit step, which raises a pop-up to confirm with the user
> that they *did* mean "save", didn't they...?
>
>
>
> Of course, if they selected "POST", we are expecting the posted event
> to be raised (which it is), and for the other fork of the workflow to
> kick in (as it used to do), and for some tidy-up and completion to
> occur (which is not happening due to the locked workflow), and hence
> for our main fork to be terminated as the workflow ends (but, as it is
> not ending, the main fork continues...).
>
>
>
> Based on the conversations below, it sounds like there is a
> fundamental design paradigm shift - we can't have parallel forks
> waiting to respond to event based on the users' actions, because the
> main fork will have locked the workflow anyway. I take it this can't
> also be true for the 'new' header-level event handling??
>
>
>
> Given that the discussion below occured several months ago, has the
> debate or approach moved on? Is there now an updated view regarding
> 'best practice' design for this sort of functionality?
>
>
>
> Many thanks
>
> Andy
>
> ________________________________
>
> From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On
> Behalf Of Sue Doughty
> Sent: Tuesday 25 March 2008 13:07
> To: SAP Workflow Users' Group
> Subject: RE: Enqueue Errors - ECC 6.0
>
> We are on ECC 6.0. I have a new issue with the Enqueue errors.
>
>
>
> We have workflows using Webservice to pass around a form via workflow
> for approval and processing. After the form has been processed, I
> have a notification fork which sends a workflow (via a sub-workflow)
> with a copy of the form that certain departments need to view - it
> could be one or up to four sub-workflows. Also in the fork is a
> background process (via a sub-workflow) that checks the TOA01 table
> (via a method in the
> BUS1065 BO) to insure that the image was stored with the employee
> record. The first step waits for 30 seconds and then checks every 10
> minutes for 30 minutes before sending a notification to the Workflow
> group if it fails to find it.
>
>
>
> The problem is that as soon as the sub-workflow for the checking of
> the
> TOA01 table starts, all of the other sub-workflows in the fork will
> not continue until that sub-workflow finishes. I get an error that
> the work item number of the main workflow (top level) is locked by
> user WF-BATCH (enqueue error).
>
>
>
> I thought that as long as I was executing sub-workflows, I would not
> get the enqueue errors. Am I missing something?
>
>
>
> Regards,
>
> Sue T. Doughty
>
> SAP Workflow Specialist
>
> Old Dominion Freight Line, Inc.
>
> 500 Old Dominion Way
>
> Thomasville, NC 27360
>
> Phone: (336) 822-5189
>
> Toll Free (800 ) 432-6335, ext. 5189
>
> Email: sue.doughty at odfl.com
>
> ________________________________
>
> From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On
> Behalf Of Sue Doughty
> Sent: Tuesday, October 23, 2007 10:11 AM
> To: SAP Workflow Users' Group
> Subject: RE: Enqueue Errors - ECC 6.0
>
>
>
> Hi Mike,
>
> I've moved two of the three decisions and the call to PA40 into a sub
> workflow and now all three branches of the fork can now be completed.
>
> I replied back to OSS stating that I felt like it was not working
> correctly and this is their response.....they will NOT do anything
> about it and suggested, as you did, to do sub workflows:
>
> thank for your response as well, and of course your valuable input
>
> is always appreciated. Nevertheless we have now reached a level,
>
> where you put into question the fundamental design / architecture
>
> of the workflow runtime system.
>
> An important feature of the workflow runtime system are so-called
>
> "synchronous process chains" (advance with dialog), i.e. if there
>
> is a sequence of dialog steps to be processed by the same user,
>
> they are executed as one chain without going to the inbox in between.
>
> A pre-requiste for this is the lock on the father workflow during
>
> the entire process chain.
>
> workflow F_______________________________
>
> ^ | ^ | ^
>
> | | | | |
>
> task ___W1___| v___W2___| v___W2___|
>
> ----------------------------------------------> time
>
> In your case there are two of such process chains, which collide
>
> because they are in parallel branches of a fork.
>
> I talked again to my boss, who is not only development manager
>
> but in this case also the responsible developer. He definitely
>
> sees no room for tolerance here.
>
> On the other side there should be a workaround by embedding the
>
> individual branches into subflows, because only the direct father
>
> and not the top-level workflow is locked. Hope this helps.
>
> Mike, I really appreciate your help in this!!
>
> Regards,
>
> Sue T. Doughty
>
> SAP Workflow Specialist
>
> OLD DOMINION FREIGHT LINE, INC.
>
> 500 Old Dominion Way, Thomasville, NC 27360
>
> Toll Free :(800)432-6335, ext.5189
>
> Phone :(336)822-5189 Fax :(336)822-5149
>
> sue.doughty at odfl.com
>
> -----Original Message-----
> From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On
> Behalf Of Mike Pokraka
> Sent: Tuesday, October 23, 2007 9:47 AM
> To: SAP Workflow Users' Group
> Subject: RE: Enqueue Errors - ECC 6.0
>
> OK, as I understand it:
>
> User A in one branch executes a decision and is advanced to the next
> step,
>
> which is a transaction.
>
> Before user A completes the txn, user B executes a decision in another
>
> branch followed by another unrelated action. This fails because user A
> has
>
> locked the WF.
>
> If I've understood this correctly then I'd call that a big fat bug. I
>
> would suggest replicating this in a test WF in it's simplest form -
> does
>
> it do the same without the decisions (i.e. just two PA40's in parallel
>
> branches)? What if you use transactions other than PA40 in both
> branches?
>
> Simplify as far as possible and send it back to OSS. (and let us know
> the
>
> outcome).
>
> Cheers,
>
> Mike
>
>
>
> On Tue, October 23, 2007 12:36 pm, Sue Doughty wrote:
>
> > Hi Mike,
>
> >
>
> > Thanks for your response.
>
> >
>
> > It is a standard call to PA40.
>
> >
>
> > Hi Mike,
>
> >
>
> > Thank you for your response.
>
> >
>
> > It is a standard call to PA40.
>
> >
>
> > I agree...a task should NOT lock the TOP level workflow.
>
> >
>
> > I did what you said and got the PA40 up and then tried to execute
>
> > another branch doing something different. It still locks the
> > workflow
>
> > at the top level.
>
> >
>
> > I will try moving the decisions out into the sub workflow and see if
>
> > that changes things.
>
> >
>
> > Regards,
>
> > Sue T. Doughty
>
> > SAP Workflow Specialist
>
> > OLD DOMINION FREIGHT LINE, INC.
>
> > 500 Old Dominion Way, Thomasville, NC 27360
>
> > Toll Free :(800)432-6335, ext.5189
>
> > Phone :(336)822-5189 Fax :(336)822-5149
>
> > sue.doughty at odfl.com
>
> > -----Original Message-----
>
> > From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On
> Behalf
>
> > Of Mike Pokraka
>
> > Sent: Tuesday, October 23, 2007 4:46 AM
>
> > To: SAP Workflow Users' Group
>
> > Subject: RE: Enqueue Errors - ECC 6.0
>
> >
>
> > Hi Sue,
>
> >
>
> > OK, so that changes the picture a little. Regarding subWF, you
> > should
>
> > try
>
> > putting the entire user dialog chain into the subwf - i.e. the
> decision
>
> > and the PA40.
>
> >
>
> > I've had similar probs where a lock would cause a similar error and
> the
>
> > error monitoring job would pick it up - as per the OSS response.
> However
>
> > I
>
> > am also not convinced this is right. Is this s standard "Call
>
> > transaction
>
> > PA40" type of method or does the code do something strange?
>
> >
>
> > A task should NOT lock the top level workflow. That defeats the
> > whole
>
> > point of parallel execution. Yes there can problems if you and up
> > with
>
> > two
>
> > branches joining at the same time and racing for the next step but a
> WF
>
> > should definitively be able to execute two steps in parallel
> > otherwise
>
> > we
>
> > can all go home. Here's another test: when one user locks PA40, try
> > to
>
> > execute something else in the other branch after the decision - or a
>
> > PA40
>
> > on a different employee - in other words something that works. If
> > that
>
> > also fails then I say it's rubbish design that needs to be fixed.
>
> >
>
> > Cheers,
>
> > Mike
>
> >
>
> >
>
> > On Mon, October 22, 2007 9:10 pm, Sue Doughty wrote:
>
> >> Hi Mike,
>
> >>
>
> >> I changed the PA40s to subworkflows.
>
> >>
>
> >> I executed the workflow again and tried to execute the decision
> >> tasks
>
> >> (which call the PA40 subworkflow).
>
> >>
>
> >> It is still giving me an enqueue error on the Decision step at the
>
> >> INSTANCE level if more than one fork is executed at a time. It
> >> seems
>
> >> like it is telling me that only one path of the fork can be
> >> executed
>
> > at
>
> >> a time. If two people try to execute two different paths, it will
> get
>
> > a
>
> >> locking error. It is two difference paths of a fork and two
> >> separate
>
> >> decision steps.
>
> >>
>
> >> This can't be the way it is supposed to work!
>
> >>
>
> >> Regards,
>
> >> Sue T. Doughty
>
> >> SAP Workflow Specialist
>
> >> OLD DOMINION FREIGHT LINE, INC.
>
> >> 500 Old Dominion Way, Thomasville, NC 27360
>
> >> Toll Free :(800)432-6335, ext.5189
>
> >> Phone :(336)822-5189 Fax :(336)822-5149
>
> >> sue.doughty at odfl.com
>
> >>
>
> >> -----Original Message-----
>
> >> From: Sue Doughty
>
> >> Sent: Monday, October 22, 2007 11:28 AM
>
> >> To: 'SAP Workflow Users' Group'
>
> >> Subject: RE: Enqueue Errors - ECC 6.0
>
> >>
>
> >> Hi Mike,
>
> >>
>
> >> Thanks for responding.
>
> >>
>
> >> There is a decision task. They can click to print forms or if they
>
> > want
>
> >> to do the action in PA40, they click "Execute Payroll (or whatever)
>
> >> followup action". The task that gets executed is a call to PA40.
>
> >>
>
> >>
>
> >> Regards,
>
> >> Sue T. Doughty
>
> >> SAP Workflow Specialist
>
> >> OLD DOMINION FREIGHT LINE, INC.
>
> >> 500 Old Dominion Way, Thomasville, NC 27360
>
> >> Toll Free :(800)432-6335, ext.5189
>
> >> Phone :(336)822-5189 Fax :(336)822-5149
>
> >> sue.doughty at odfl.com
>
> >>
>
> >> -----Original Message-----
>
> >> From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On
>
> > Behalf
>
> >> Of Mike Pokraka
>
> >> Sent: Monday, October 22, 2007 9:39 AM
>
> >> To: SAP Workflow Users' Group
>
> >> Subject: Re: Enqueue Errors - ECC 6.0
>
> >>
>
> >> Hmmm, my first thougt was that this is complete nonsense from OSS.
>
> >> Then I notice that they talk about a decision task. So, now I think
>
> >> we're
>
> >> missing a piece of info here - is this a decision or a PA40?
>
> >>
>
> >> A possible workaround may be to put the PA40's into a subWF. It may
>
> > only
>
> >> lock the subworkflow. On the other hand it may also be a case of
>
> >> rejecting
>
> >> SAP's response - depending on this mystery decision task that is
> PA40.
>
> >>
>
> >> Cheers,
>
> >> Mike
>
> >>
>
> >>
>
> >> On Mon, October 22, 2007 1:26 pm, Sue Doughty wrote:
>
> >>> We are in the process of upgrading from 4.7 to ECC 6.0.
>
> >>>
>
> >>>
>
> >>>
>
> >>> We have a New Hire workflow that has a fork with three branches.
>
> > Each
>
> >>> branch goes to a different department and they all have a work
> >>> item
>
> >> that
>
> >>> executes PA40 where they execute a specific action for the
employee.
>
> >>>
>
> >>>
>
> >>>
>
> >>> In 4.7, if two departments happened to hit the same employee at
> >>> the
>
> >> same
>
> >>> time, the second department trying to execute the work item would
> get
>
> >> an
>
> >>> error in PA40 - Employee is being processed by ######. They would
>
> >>> cancel out and come back later. The work item would remain in
> >>> their
>
> >>> in-box.
>
> >>>
>
> >>>
>
> >>>
>
> >>>
>
> >>> In ECC 6.0, the workflow gets an ENQUEUE error - Error when
> >>> loading
>
> >>> component: Work item 000000638111 locked (action FIND_FLOWITEM)
> >>> and
>
> >> then
>
> >>> Work item 000000638111 locked by user E050889 (enqueue error)
> (action
>
> >>> FIND_BY_WIID_BY_WFM)
>
> >>>
>
> >>>
>
> >>> The error is referencing the Workflow INSTANCE, not the work item
>
> >> being
>
> >>> executed. The work item for the second user is then set to
> >>> Complete
>
> > -
>
> >>> it never takes them to PA40. They have no way of going back in
> later
>
> >>> and executing the action.
>
> >>>
>
> >>>
>
> >>>
>
> >>> I opened a note with SAP and was told that it is working as
> designed.
>
> >>> See SAP's response below:
>
> >>>
>
> >>>
>
> >>>
>
> >>> Here the lock did not occur during work item execution, but after
>
> >>> execution during
>
> >>> the so-called "callback", because the corresponding workflow
> >>> (father
>
> >>> work item) was locked. In such a case the work item (user
> >>> decision)
>
> >>> is COMPLETED and the workflow is suspended. Especially the
> >>> so-called
>
> >>> "synchronous process chain" (advance with dialog) is interrupted
>
> >>> unless SWWERRE puts the subsequent work item (PA40) into the inbox
>
> >>> of the user concerned.
>
> >>>
>
> >>> According to our development manager this works as designed.
>
> >>>
>
> >>>
>
> >>>
>
> >>>
>
> >>>
>
> >>> I am at a loss as to how to fix this problem. I don't want to
> >>> take
>
> >> out
>
> >>> the fork and have the departments execute the PA40 action one
> >>> after
>
> >> the
>
> >>> other. This would lengthen the time the workflow takes to get
>
> > someone
>
> >>> hired and I don't know which department I would do first....they
> >>> all
>
> >> do
>
> >>> things in their own time.
>
> >>>
>
> >>>
>
> >>>
>
> >>> Has anyone else encountered this problem? Does anyone have any
>
> >>> suggestions?
>
> >>>
>
> >>>
>
> >>>
>
> >>> Any help would be greatly appreciated.
>
> >>>
>
> >>>
>
> >>>
>
> >>> Regards,
>
> >>>
>
> >>> Sue T. Doughty
>
> >>> SAP Workflow Specialist
>
> >>>
>
> >>> OLD DOMINION FREIGHT LINE, INC.
>
> >>>
>
> >>> 500 Old Dominion Way, Thomasville, NC 27360
>
> >>>
>
> >>> Toll Free :(800)432-6335, ext.5189
>
> >>> Phone :(336)822-5189 Fax :(336)822-5149
>
> >>> sue.doughty at odfl.com
>
> >>>
>
> >>>
>
> >>>
>
> >>>
>
> >>>
>
> >>> ****************************
>
> >>> CONFIDENTIALITY NOTICE: The information contained in this message
> may
>
> >> be
>
> >>> confidential, privileged, proprietary, or otherwise legally exempt
>
> >> from
>
> >>> disclosure. If the reader of this message is not the intended
>
> >> recipient,
>
> >>> or an employee or agent responsible for delivering this message to
>
> > the
>
> >>> intended recipient, you are hereby notified that you are not
>
> >> authorized to
>
> >>> read, print, retain, copy or disseminate this message, any part of
>
> > it,
>
> >> or
>
> >>> any attachments. If you have received this message in error,
> >>> please
>
> >> delete
>
> >>> this message and any attachments from your system without reading
> the
>
> >>> content and notify the sender immediately of the inadvertent
>
> >> transmission.
>
> >>> Thank you for your cooperation.
>
> >>>
>
> >>> _______________________________________________
>
> >>> SAP-WUG mailing list
>
> >>> SAP-WUG at mit.edu
>
> >>> http://mailman.mit.edu/mailman/listinfo/sap-wug
>
> >>>
>
> >>
>
> >>
>
> >> --
>
> >> Mike Pokraka
>
> >> Senior Consultant
>
> >> Workflow Connections
>
> >> Mobile: +44(0)7786 910855
>
> >>
>
> >> _______________________________________________
>
> >> SAP-WUG mailing list
>
> >> SAP-WUG at mit.edu
>
> >> http://mailman.mit.edu/mailman/listinfo/sap-wug
>
> >>
>
> >>
>
> >> ****************************
>
> >> CONFIDENTIALITY NOTICE: The information contained in this message
> >> may
>
> > be
>
> >> confidential, privileged, proprietary, or otherwise legally exempt
>
> > from
>
> >> disclosure. If the reader of this message is not the intended
>
> > recipient,
>
> >> or an employee or agent responsible for delivering this message to
> the
>
> >> intended recipient, you are hereby notified that you are not
>
> > authorized to
>
> >> read, print, retain, copy or disseminate this message, any part of
> it,
>
> > or
>
> >> any attachments. If you have received this message in error, please
>
> > delete
>
> >> this message and any attachments from your system without reading
> >> the
>
> >> content and notify the sender immediately of the inadvertent
>
> > transmission.
>
> >> Thank you for your cooperation.
>
> >>
>
> >> _______________________________________________
>
> >> SAP-WUG mailing list
>
> >> SAP-WUG at mit.edu
>
> >> http://mailman.mit.edu/mailman/listinfo/sap-wug
>
> >>
>
> >
>
> >
>
> > --
>
> > Mike Pokraka
>
> > Senior Consultant
>
> > Workflow Connections
>
> > Mobile: +44(0)7786 910855
>
> >
>
> > _______________________________________________
>
> > SAP-WUG mailing list
>
> > SAP-WUG at mit.edu
>
> > http://mailman.mit.edu/mailman/listinfo/sap-wug
>
> >
>
> >
>
> > ****************************
>
> > CONFIDENTIALITY NOTICE: The information contained in this message
> > may
> be
>
> > confidential, privileged, proprietary, or otherwise legally exempt
> from
>
> > disclosure. If the reader of this message is not the intended
> recipient,
>
> > or an employee or agent responsible for delivering this message to
> > the
>
> > intended recipient, you are hereby notified that you are not
> authorized to
>
> > read, print, retain, copy or disseminate this message, any part of
> > it,
> or
>
> > any attachments. If you have received this message in error, please
> delete
>
> > this message and any attachments from your system without reading
> > the
>
> > content and notify the sender immediately of the inadvertent
> transmission.
>
> > Thank you for your cooperation.
>
> >
>
> > _______________________________________________
>
> > SAP-WUG mailing list
>
> > SAP-WUG at mit.edu
>
> > http://mailman.mit.edu/mailman/listinfo/sap-wug
>
> >
>
>
>
> --
>
> Mike Pokraka
>
> Senior Consultant
>
> Workflow Connections
>
> Mobile: +44(0)7786 910855
>
> _______________________________________________
>
> SAP-WUG mailing list
>
> SAP-WUG at mit.edu
>
> http://mailman.mit.edu/mailman/listinfo/sap-wug
>
> ****************************
> CONFIDENTIALITY NOTICE: The information contained in this message may
> be confidential, privileged, proprietary, or otherwise legally exempt
> from disclosure. If the reader of this message is not the intended
> recipient, or an employee or agent responsible for delivering this
> message to the intended recipient, you are hereby notified that you
> are not authorized to read, print, retain, copy or disseminate this
> message, any part of it, or any attachments. If you have received this
> message in error, please delete this message and any attachments from
> your system without reading the content and notify the sender
> immediately of the inadvertent transmission. Thank you for your
cooperation.
>
> ****************************
> CONFIDENTIALITY NOTICE: The information contained in this message may
> be confidential, privileged, proprietary, or otherwise legally exempt
> from disclosure. If the reader of this message is not the intended
> recipient, or an employee or agent responsible for delivering this
> message to the intended recipient, you are hereby notified that you
> are not authorized to read, print, retain, copy or disseminate this
> message, any part of it, or any attachments. If you have received this
> message in error, please delete this message and any attachments from
> your system without reading the content and notify the sender
> immediately of the inadvertent transmission. Thank you for your
cooperation.
>
>
>
> Cadbury Cocoa Partnership - a historic alliance to secure the future
> of cocoa farming. Visit www.cadbury.com <http://www.cadbury.com/> to
> learn more
>
>
>
> Please support our Purple Goes Green commitments and consider the
> environment before you print this email
>
>
>
> -----------------------------------------
>
>
>
> This email (including any attachment) is confidential and may contain
> privileged information. If you are not the intended recipient or
> receive it in error, you may not use, distribute, disclose or copy any
> of the information contained within it and it may be unlawful to do
> so. If you are not the intended recipient please notify us immediately
> by returning this email to us at mailerror at csplc.com
> <mailto:mailerror at csplc.com> and destroy all copies.
>
> Any views expressed by individuals within this email do not
> necessarily reflect the views of Cadbury Holdings Ltd or any of its
> subsidiaries or affiliates. This email does not constitute a binding
> offer, acceptance, amendment, waiver or other agreement, or create any
> obligation whatsoever, unless such intention is clearly stated in the
> body of the email. Whilst we have taken reasonable steps to ensure
> that this email and any attachments are free from viruses, recipients
> are advised to subject this email to their own virus checking, in
> keeping with good computing practice. We accept no liability for any
> damage sustained as a result of any viruses. Please note that email
> received by Cadbury Holdings Ltd or its subsidiaries or affiliates may
> be monitored in accordance with applicable law.
>
> This email originates from Cadbury Holdings Ltd ("Cadbury") or Cadbury
> UK ("Cadbury UK") as the case may be.
>
> Cadbury Holdings Ltd: registered in England and Wales, registered no.
> 52457
> Registered address: Cadbury House, Sanderson Road, Uxbridge, Middlesex
> UB8 1DH United Kingdom.
>
> Telephone: +44 (0) 1895-615000 Fax: +44 (0) 1895-615001
>
>
>
> Cadbury UK: a partnership of Cadbury UK Ltd, Trebor Bassett Ltd and
> The Old Leo Company Ltd each of which is registered in England and
Wales.
>
> Principal trading address: Cadbury House, Sanderson Road, Uxbridge,
> Middlesex UB8 1DH United Kingdom.
>
> Telephone: +44 (0) 1895-615000 Fax: +44 (0) 1895-615001
>
>
>
> -----------------------------------------
>
_______________________________________________
SAP-WUG mailing list
SAP-WUG at mit.edu
http://mailman.mit.edu/mailman/listinfo/sap-wug
The Cadbury Cocoa Partnership is working to secure the future of cocoa
farming around the world. Cadbury Dairy Milk bars are now Fairtrade
certified in the UK and Ireland. Visit http://www.cadbury.com/ to learn
more.
Be part of our "Purple Goes Green" commitments and don't print this
email.
-----------------------------------------
This email (including any attachment) is confidential and may contain
privileged information and is intended for the use of the individual(s)
to whom it is addressed. If you are not the intended recipient or
receive it in error, you may not use, distribute, disclose or copy any
of the information contained within it and it may be unlawful to do so.
If you are not the intended recipient please notify us immediately by
returning this email to us at mailto:mailerror at cadbury.com and destroy
all copies.
Any views expressed by individuals within this email do not necessarily
reflect the views of Cadbury Holdings Ltd or any of its subsidiaries or
affiliates. This email does not constitute a binding offer, acceptance,
amendment, waiver or other agreement, or create any obligation
whatsoever, unless such intention is clearly stated in the body of the
email. Whilst we have taken reasonable steps to ensure that this email
and any attachments are free from viruses, recipients are advised to
subject this email to their own virus checking, in keeping with good
computing practice. We accept no liability for any damage sustained as a
result of any viruses. Please note that email received by Cadbury
Holdings Ltd or its subsidiaries or affiliates may be monitored in
accordance with applicable law.
This email originates from Cadbury Holdings Ltd ("Cadbury") or Cadbury
UK ("Cadbury UK") as the case may be.
Cadbury Holdings Ltd: registered in England and Wales, registered no.
52457 Registered office address: Cadbury House, Sanderson Road,
Uxbridge, Middlesex, UB8 1DH United Kingdom. Telephone: +44 (0)1895
615000 Fax:+44 (0)1895 615001
Cadbury UK: a partnership of Cadbury UK Ltd, Trebor Bassett Ltd and The
Old Leo Company Ltd. each of which is registered in England and Wales.
Principal trading address: Cadbury House, Sanderson Road, Uxbridge,
Middlesex, UB8 1DH United Kingdom. Telephone: +44 (0)1895 615000
Fax:+44 (0)1895 615001
-----------------------------------------
_______________________________________________
SAP-WUG mailing list
SAP-WUG at mit.edu
http://mailman.mit.edu/mailman/listinfo/sap-wug
More information about the SAP-WUG
mailing list