Anyone else confused by QM status management?

[Michael Pokraka]

Thanks Heinz, atleast I'm not the only one going mad.
 
On a different note, I've now hit a chicken and egg situ: if I fix it one
way I break the other and vice versa. It's a bit late in the game to star=
t
create custom events (the SAP ones are in the functional spec and it's a
pharmaceutical environment - that means change is bad, very bad, very lon=
g,
ugly, too much paperwork and meetings).
 
Does anyone have an elegant way to filter only one event out of a possibl=
e
three? I have a seemingly random set of events which can trigger a flow, =
but
only one flow should be triggered. So if two events happen only one flow
should start.
 
Just to make it interesting, there can be previous active instances of th=
e
flow which should be there, so a delay in one event and then looking for
other flow instances is not the answer.
 
I can think of a few ugly ideas involving check functions that communicat=
e
with each other and/or custom tables... but I'm sure I've done or seen
something simpler. Yes I am being a bit lazy and my excuse is that my bra=
in
is fried at the moment.
 
Any other ideas appreciated
Cheers
Mike
 
 
Schmidinger, Heinz (Unaxis IT BZ) wrote:
> I can add an other kombination:
>
> If you create a notification and add e.g. an order directly out of the
> notification (IW51), Event 'CREATE' is not fired, instead 'INPROCESS' i=
s
> fired.
>
> I have reported it to OSS 2 years ago but after discussions with SAP ab=
out
> these inconsistencies I have creted my own events, because SAP is not
> willing to clear these inconstensies.
>
> -----Urspr=FCngliche Nachricht-----
> Von: SAP Workflow [mailto:Owner-SAP-WUG at MITVMA.MIT.EDU]Im Auftrag von
> Michael Pokraka
> Gesendet am: Mittwoch, 24. November 2004 12:27
> An: SAP-WUG at MITVMA.MIT.EDU
> Betreff: Anyone else confused by QM status management?
>
> Greetings all,
> I'm just wondering if I'm the only one confused by the SAP standard
> status/event settings around notifications?
>
> Completing a notification and putting it back into process raises an
> INPROCESSAGAIN. Rejecting a notification and putting it back into proce=
ss
> raises both a CREATED and INPROCESSAGAIN event. Deleting it and putting=
 it
> back into process only raises an INPROCESS. Other combinations raise
> INPROCESSAGAIN and INPROCESS, or some other random sets of events.
>
> The basic problem seems to be that some events are raised directly in t=
he
> code and others via status management (And a few custom events for good
> measure, including changedocuments). There just seems to be some
> inconsistency and I'm getting tired of catering for all the bizarre
> combinations of actions our functional folks can think up to produce a =
new
> set of event/status combinations for the same basic process.
>
> I suppose it's more of a rant/discussion rather than a problem, but put=
ting
> in the fourth 'special case' fix for inconsistent events within the sta=
ndard
> is getting tedious. At least it's made for some interesting debugging a=
nd a
> lot of headscratching.
>
> Cheers
> Mike
>
>