Those of you who run the QM module and are familiar with workflow probably know that there is a Business Object modelled on the QALS table - BUS2045. I was recently able to customize a delegation of this object and very quickly create a simple custom workflow triggered by the STAT35 column of QALS being set to 'X' by transaction QA11 when a usage decision of 'A' (accept) was made on an inspection lot. (There's a little more to this story involving the STAT19 column of QALS, but that's another story for another time, and it's really not an issue if you're willing to turn on the "doc history required" flag for all your matnr's.) But I didn't have the same luck with the next customer requirement - to automate usage decision-making without using the SAP program RQEVAI30 running like a UNIX daemon in background. The problem here is that this program uses some nasty nasty logic against the JEST table to see if an inspection lot is "ready" for an automated usage decision. And unfortunately, this logic is "work-flow" proof because the JEST table allows no change history to be written from it, and therefore no events to be triggered from it. On the other hand, there are two columns I could use in the QALS table to detect when there are no more open tasks against a lot, but the data elements for these columns don't support change history. Otherwise, I could create a custom event when these columns go to 0, do a start condition to check a couple of other things, and then trigger the usage decision method of BUS2045. So, I'm going to suggest to the customer that we do a minor modification to the data elements QOFFENLZMK and QOFFELZMK underlying QALS-OFFENNLZMK and QALS-OFFEN_LZMK so that change history on them is written. Then, I can generate a change object against these and "PROBABLY" find a custom exit in XQEE where I can stick the change object document write program to make sure that CDPOS winds up with the correct trace on these two columns. But the point of this blog is: as long as SAP makes RQEVAI30 available to its customers as a 1987 solution masquerading as a 2007 solution, what customers will pay for what my current customer is paying me to try to do here? (I'm lucky that this customer is forward-thinking enough NOT to want to adopt 1987 solutions for 2007 problems.) And as long as most customers won't pay to get out of the last century, they sure as heck ain't gonna get into the workflow way of thinking that's a natural prerequisite for development of a true Enterprise SOA mindset.
