Hi Bryan,
This is a good question. In theory, you should be able to code this "mass transaction indicator" systematically on the basis of specific TCODEs.
For example, say that transaction TX99 corresponds to a user marking "delivery complete" on a PO which then triggers the setting of "final invoice indicator" automatically. In SQL, you could write something like this:
-- In the "Set Final Invoice Indicator" activity:
CASE
WHEN CDPOS.FNAME = '{{Final Invoice Indicator Field}}' AND CDPOS.TABNAME = '{{Final Invoice Indicator Table}}'
THEN CASE
WHEN CDHDR.TCODE = 'TX99'
THEN 'R'
ELSE USR02.USTYP
END
WHEN ...
WHEN ...
END AS USER_TYPE
Do note - to make sure that this approach works in an exhaustive manner - that you will have to work with the business users to understand all of the possible fields which can be updated in certain situations within a given transaction.
Hope this helps!
Hi Brian,
to my understanding, the Mass transaction qualifier is checking for a single activity performed by the same user within a timeframe of a couple of seconds, 10 being the default proposed. For each activity in the selection, it will indeed change the user type 'A' (manual user) to 'R' which is a Celonis value. This would be the case for example when a user performs manual mass PO output with transaction ME9F and select multiple POs before executing; or if there is a batch job that is executed at night under the name of of end user to process POs based on criteria's.
The reasoning behind is that for specific activities, it is physically not possible for a human being to perform them within x seconds by executing the PO output one by one or opening each document separately. And if you need to calculate Automation rate, then having those activities with User type 'A' would not reflect reality. OK, you still have a manual activity to start ME9F, select a set of POs and execute the output, but it is a one shot that counts for nothing in your automation rate calculation.
So you then also need to filter those 'R' users out. I usually modify the statement WHEN USER_TYPE ='B' THEN 1.0, by WHEN USER_TYPE != 'A' THEN 1.0 so that all system user types from SAP (B, S, ...) and Celonis (R) are taken into account to calculate the rate, not forgetting to add WHEN ISNULL(USER_TYPE) = 1 THEN NULL so that activities which are more 'status' related are not taken into account (mostly in AP: 'Vendor creates invoice', or 'Due Date Passed')
If you currently see user type 'R' for those 2 activities you mention, then the first one must have been executed in mass by the user or a job and the second one being the consequence of the first one will also have a very short time difference between two occurrences.
If the first one should be identified as a manual activity although a set of POs is handle in a very short period of time, you can either force a filter out of the related activities by adding ACTIVITY_EN NOT IN ('AAA', 'BBB') to the WHERE clause; or after the transformation was executed, add a piece of code to reprocess the 'R' into 'A' for the selected activities with ACTIVITY_EN IN ('AAA', 'BBB') in the WHERE clause.
And as Greg wrote, if you want to define that a specific activity executed by a defined transaction is of type 'R', then use the relevant parameters in the CASE WHEN statement. I personally used it in AP process for activity 'Clear Invoice with Payment Run': payment run list preparation is a manual activity, but execution of the clearing is automated.
kind regards
Marc
