What would be better: additional check function module calls, additional SWEC entries, or ‘the third way’?

[Kjetil Kilhavn]

I ran into a sort of philosophical question as part of a problem (OK, 
/challenge/), and would appreciate your thoughts on the issue.

I need to start a workflow for control of cost and account assignment when a 
purchase order does not have a release strategy. This is because my 
recommendation of not having release strategies when the purchaser can approve 
the purchase order (it is just an extra step for them) was accepted. Nothing 
beats creating trouble for myself...

I created two new SWEC entries, one for EINKBELEG on Create and one for 
EINKBELEG on Change. For both I set a custom event, and added a field 
restriction to create the event only when PROCSTAT got the value 02. I used * 
as the old value for the on Change event and have tried with both * and no 
value for the on Create event.

The event is only created on change. I have found out why, it is because there 
is no change document position data for the creation, and so the field 
restriction will never be matched. Bummer, but at least it made me think 
through the options again, and I realised there is a third option...

I have at least three options:
1) Use a simple on Create SWEC entry and a check function module in the event 
linkage. Reuse the check function module in an event linkage for the existing 
on Change SWEC entry that triggers BUS2012 Changed for every change. 
Summary: Fewer SWEC entries, but additional check function module calls.

2) Use a simple on Create SWEC entry and a check function module in the event 
linkage. Keep the on Change SWEC entry which works as desired.
Summary: Mix and match solution seems less elegant.

3) Use two simple SWEC entries and implement function modules to determine the 
event ID(s). Create specific events for the various purposes. I suppose this 
means I will be implementing my own “field restrictions” check.
Summary: Minimum number of SWEC entries, minimum number of events created.

The third option seems tempting at the moment. The design is in some ways 
better (specific events), events created ‘only’ when relevant.
Currently there are quite a few events in the event log which fail the check 
function module because the generic events are used for things that don't 
occur frequently.
The only disadvantage is that the setup is slightly more hidden - you have to 
check the function module to see the events that possibly gets created. 
On the other hand, this configuration is not something you would ask an end 
user to do - so if the function module has a decent documentation it should 
not be a problem.

So, would anyone like to share their thoughts, and options 4 to 99 :-)
-- 
Kjetil Kilhavn / Vettug AS (http://www.vettug.no)