[ECC 6.0] Workflow fails at switch step when logistics invoice header text is 'R', but not when it is 'r' or 'Really strange'

Tue May 13 23:42:59 EDT 2008

Hello Kjetil,

I can recommend replication followed by simplification, it's solved
many a problem for me!

I tried reconstructing your situation as closely as possible but it
always worked. The only way I could get "Error when starting a SWITCH
branch" was by deliberately supplying an erroneous attribute name. How
"R" could be treated differently from "r" I can only speculate -
perhaps they were supplied by slightly though significantly different
routes.

If you ever manage to replicate, please let me know what the answer was.

Rick Bakker
Hanabi Technology

On 5/12/08, Kjetil Kilhavn <kjetil.kilhavn at bluec.no> wrote:
> On Sunday 11 May 2008 03:29:50 Rick Bakker wrote:
> > Hello,
> >
> > Were you able to replicate this problem in a simplified version of the
> > workflow and/or the object?
> No, my focus was on trying to get rid of the problem, so I never tried
> replicating it. Having that problem two places just did not appeal to me :-)
>
> > Can you remember exactly which conditions you had in the switch and
> > what the data types of all the relevant fields were?
> I don't even need to remember since the condition is exactly the same as the
> one used in the condition step I now use (which works perfectly as far as I
> can tell). The condition was/is:
> &IncomingInvoice.ZMarkedAsInterestInvoice& = X
>
> ZMarkedAsInterestInvoice is defined as single-line virtual parameter with
> reference to ZM0_WF_INVOICEVERIFICATION-BOOLEAN (type BOOLE_D).
>
> > I tried to replicate your error messages but all I achieved was having
> > the workflow consistently choose the wrong path - by not doing a
> > SWC_GET_PROPERTY SELF in the GET_PROPERTY of the virtual attribute.
> > I assume you thought of that.
> Thanks for trying to figure this one out.
>
> If you forgot to retrieve the header text, then I never had that problem. If
> there are some other problems related to virtual attributes relying on other
> virtual attributes I may have the problem.
>
> The odd thing is of course that my problem was NOT that the solution behaved
> incorrectly in the sense that the incorrect path was selected, but that there
> was an ERROR sometimes when it should select the correct path, and that this
> error depended on whether the document header text was in UPPER or lower case
> or contained more than one character.
>
> The code for virtual attribute ZMarkedAsInterestInvoice is as follows:
> get_property zmarkedasinterestinvoice changing container.
> * 2004-08-23, e-kkilhavn (Kjetil Kilhavn, Blue Consulting AS)
> * Check if header text indicates that this is interest (starts with R)
> DATA: l_bktxt TYPE rbkp-bktxt.
>
> "Get header text, check first character
> swc_get_property self 'ZDocumentHeaderText'
>                      l_bktxt.
> SHIFT l_bktxt LEFT DELETING LEADING space.
> IF l_bktxt(1) = 'R'
> OR l_bktxt(1) = 'r'.
>  object-zmarkedasinterestinvoice = 'X'.
> ELSE.
>  CLEAR object-zmarkedasinterestinvoice.
> ENDIF.
>
> swc_set_element container 'ZMarkedAsInterestInvoice'
>                          object-zmarkedasinterestinvoice.
> end_property.
>
>
> ZDocumentHeaderText is defined as single-line database parameter with
> reference to RBKP-BKTXT.
>
> > Rick Bakker
> > Hanabi Technology
> >
> > On 5/9/08, Kjetil Kilhavn <kjetil.kilhavn at bluec.no> wrote:
> > > Ready for the strangest problem I have ever encountered? I've actually
> > > given up this one, but it should be usable as weekend amusement I think.
> > >
> > > I've made a custom workflow for handling parked logistics invoices (don't
> > > need advice about how this is a bad idea - I know). Anyway, an issue came
> > > up for invoices for late payment interest (or Rente (either
> > > forsinkelsesrente or morarente) as it is called in Norway). Handling
> > > these invoices were a problem, so we needed to identify them and have a
> > > separate branch in the workflow.
> > >
> > > Simple solutions are the best often, so it was suggested that an R would
> > > be put in the header text instead of the normal <purchase order
> > > number>/<contact person> header text - or at least preceding it.
> > >
> > > Very well, I created a virtual attribute (boolean) to have something I
> > > could use in my conditions. This virtual attribute retrieves the header
> > > text, which had already been added as an attribute, and checks if the
> > > first non-space character is either 'R' or 'r'. If it is, my new
> > > attribute is set to X, otherwise cleared (set to space). So far all is
> > > well.
> > >
> > > I inserted a switch (expecting more special cases to come along) in the
> > > workflow. In the switch I check my attribute, and if it is X the outcome
> > > for late payment interest invoices is selected, otherwise the default
> > > outcome is selected. So far all is still well.
> > >
> > > The funny thing is, if I park an invoice where the header text is 'R' the
> > > virtual attribute seems to be set correctly when I test the BOR object
> > > type, but the workflow fails (status ERROR) with two error messages in
> > > the log: WL/821 (Work item nnn: Object FLOWITEM method EXECUTE can not be
> > > executed) SWP/103 (Error when starting a SWITCH branch)
> > >
> > > If, on the other hand, the header text is 'r' the virtual attribute seems
> > > to be set correctly, and the workflow functions as expected. If I have
> > > parked the invoice with header text 'R', I can later change it to e.g.
> > > 'Rente' and use transaction SWPR to kick the stopped workflow back into
> > > action.
> > >
> > > I would love to see an explanation for this behaviour, but I don't expect
> > > one.
> > >
> > > In a final act of desperation I substituted a condition for the switch,
> > > and that solved the problem - but I am still wondering why UPPER and
> > > lower case in a header text which was not referenced either in the switch
> > > or in the steps following the outcome would make a difference.
> > >
> > > Have a good weekend :-)
> > > --
> > > Kjetil Kilhavn (+47 40220607)
> > > Blue Consulting AS (http://www.bluec.no/)
> > > _______________________________________________
> > > SAP-WUG mailing list
> > > SAP-WUG at mit.edu
> > > http://mailman.mit.edu/mailman/listinfo/sap-wug
> >
> > _______________________________________________
> > SAP-WUG mailing list
> > SAP-WUG at mit.edu
> > http://mailman.mit.edu/mailman/listinfo/sap-wug
>
>
>
> --
> Kjetil Kilhavn (+47 40220607)
> Blue Consulting AS (http://www.bluec.no/)
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
>