"No function module for process code .."

Bakker, Paul Paul.Bakker at qr.com.au
Mon May 10 18:47:36 EDT 2004


Hi Fred,
 
 Unfortunately RBDMANI has the same problem - it won't (re)process idocs
 
that have a process code for kicking off a workflow (instead of calling
an inbound function module).
 
 But now I've realized that my "problem" is more a minor inconvenience
than a real problem. In Production, you should NOT be able to reprocess=0D
an idoc that kicks off a workflow. Instead, the user should follow
through=0D
on the workflow that was started for that idoc. (Normally they won't
have
to, but if the idoc goes into error a workitem will be in their inbox).
 
 In a Test environment, however, this restriction is a pain: you can't=0D
use WE19 on idocs with these workflow process codes. But I can live with
that :-)
 
thanks for your help/bedankt voor de moeite!
Paul=0D
 
> -----Original Message-----
>> From: Kouw, FA - SPLXE [mailto:fa.kouw at td.klm.com]=0D
> Sent: Monday, 10 May 2004 17:50
> To: SAP-WUG at MITVMA.MIT.EDU
> Subject: Re: "No function module for process code .."
>=0D
>=0D
> Hi Paul,
>=0D
>> From the SAP application help, maybe this helps:
>=0D
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=0D
> Error Handling in ALE Inbound Processing
>=0D
> Any errors that occur during ALE processing are handled as follows:
>=0D
> The processing of the IDoc causing the error is terminated.
> An event is triggered. This event starts an error task (work=0D
> item): The employees responsible will find a work task in=0D
> their workflow inboxes. An error message is displayed when=0D
> the work task is processed. The error is corrected in another=0D
> window and the IDoc can then be resubmitted for processing.=0D
> If the error cannot be corrected, the IDoc can be marked for=0D
> deletion. Once the IDoc has been successfully posted, an=0D
> event is triggered that terminates the error task. The work=0D
> task then disappears from the inbox.
>=0D
> Reposting IDocs with Errors
>=0D
> If the processing of the inbound IDoc resulted in an error=0D
> (IDoc status 51 - "Application document not posted", or 63 -=0D
> "Error passing IDoc to application"), you can use the report=0D
> RBDMANI2 to resubmit the IDoc.
>=0D
> In this program you can select specific errors.
>=0D
> The program can also be scheduled as a periodic job to=0D
> collect IDocs that could not be posted because of a lock problem.
>=0D
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=0D
> Regards,
>=0D
> Fred Kouw
>=0D
>=0D
>=0D
>=0D
>=0D
>=0D
>=0D
> "Bakker, Paul" wrote:
>=0D
> > Hi,
> >
> >  I posted the following message earlier this year, but did=0D
> not receive=0D
> > any helpful replies (except to check BD67).
> >
> >  Unfortunately I then forgot about it, but the issue has=0D
> come back to=0D
> > bite us. Has anyone seen this error message before? How can I=0D
> > reprocess these idocs,
> > if not via BD87?
> >
> > thanks in advance for your help,
> > Paul
> >
> > -------------------------------------------
> >
> >
> > Howdy, and a happy new year..
> >
> > We're upgrading to 4.6C, and we have implemented a custom=0D
> workflow to
> >
> > process incoming ORDRSP (order response) idocs.
> >
> >
> >
> > The partner profile of these idocs specifies that they be=0D
> handled by a
> >
> > workflow (instead of the usual input function module). The process=0D
> > code
> >
> > for these idocs is 'ZRSP'.
> >
> >
> >
> > My problem is this: If one of these idocs goes into error, it seems
> >
> > that, *because it is linked to a workflow*, I am unable to
> >
> > reprocess it using BD87. The error message is:
> >
> >
> >
> > -------------
> >
> > No function module for input process code ZRSP
> >
> > Message no. B1 033
> >
> >
> >
> > Diagnosis
> >
> > The function module which performs application input for=0D
> input process
> >
> > code ZRSP could not be determined.
> >
> >
> >
> > Procedure
> >
> > Maintain ALE input methods.
> >
> > --------------
> >
> >
> >
> > Is BD87 really so inflexible as to assume that all idocs=0D
> are handled=0D
> > by
> >
> > function modules?
> >
> > Should I be using a different transaction to re-process these idocs?
> >
> >
> >
> > Or does SAP assume that all idocs linked to workflows will=0D
> never need
> >
> > BD87 reprocessing?
> >
> >
> >
> > thanks for your help!
> >
> > Paul Bakker
> >
> > Brisbane, Australia
> >
> >=0D
> **********************************************************************
> > This email and any files transmitted with it are confidential and=0D
> > intended solely for the use of the individual or entity to=0D
> whom they=0D
> > are addressed. If you have received this email in error=0D
> please notify=0D
> > the system manager of QR.
> >
> > This message has been scanned for the presence of computer=0D
> viruses. No=0D
> > warranty is given that this message upon its receipt is=0D
> virus free and=0D
> > no liability is accepted by the sender in this respect.
> >
> > This email is a message only; does not constitute advice and should=0D
> > not be relied upon as such.
> >=0D
> **********************************************************************
> >
> >=0D
> ______________________________________________________________________
> > ___________________
> > This inbound message from KPN has been checked for all=0D
> known viruses by KPN IV-Scan, powered by MessageLabs.
> > For further information visit: http://www.veiliginternet.nl
> >=0D
> ______________________________________________________________
> _______________________________
>=0D
>=0D
> Please visit http://www.klm-em.com for information about KLM=0D
> Engineering & Maintenance products and services.
>=0D
> **********************************************************************
> This e-mail and any attachment may contain confidential and=0D
> privileged material intended for the addressee only. If you=0D
> are not the addressee, you are notified that no part of the=0D
> e-mail or any attachment may be disclosed, copied or=0D
> distributed, and that any other action related to this e-mail=0D
> or attachment is strictly prohibited, and may be unlawful. If=0D
> you have received this e-mail by error, please notify the=0D
> sender immediately by return e-mail, and delete this message.=0D
> Koninklijke Luchtvaart Maatschappij NV (KLM), its=0D
> subsidiaries and/or its employees shall not be liable for the=0D
> incorrect or incomplete transmission of this e-mail or any=0D
> attachments, nor responsible for any delay in receipt.
> **********************************************************************
>=0D
> ______________________________________________________________
> _______________________________
> This outbound message from KPN has been checked for all known=0D
> viruses by KPN IV-Scan, powered by MessageLabs. For further=0D
> information visit: http://www.veiliginternet.nl=0D
> ______________________________________________________________
> _______________________________
>=0D
 
**********************************************************************
This email and any files transmitted with it are confidential and intended=
 solely for the use of the individual or entity to whom they are addressed.=
 If you have received this email in error please notify the system manager=
 of QR.
 
This message has been scanned for the presence of computer viruses. No=
 warranty is given that this message upon its receipt is
virus free and no liability is accepted by the sender in this respect.
 
This email is a message only; does not constitute advice and should not be=
 relied upon as such.
**********************************************************************
 


More information about the SAP-WUG mailing list