cancel
Showing results for 
Search instead for 
Did you mean: 

BIC Processing File name generated is not always correct for ORDERS05 IDoc pairing for PO PDFs OB16

Ellen_A_Barry
Star Contributor
Star Contributor

SAP  PO process generates Message output for both a PDF and an Idoc.  The file name sent to BIC is normally in this format:

4500770917             0005070364-942ce267-5311-4a48-828a-6f76c0b7cd6a

BUT on occasion the format comes in without the PO id from TOA01 as : -3b500fb4-a909-4cae-9565-b908bb19df51

 

These entries fail to process.  Is there a know issue/resolution for this?  The BIC MRG doesn't indicated where/how the file name is generated.

 

OB 16 and moving to Foundation EP3.

 

If anyone has advice or guidance on information would be appreciated.

 

Thanks,

Ellie Barry

Dawn Food Products, Inc.

1 ACCEPTED ANSWER

Ellen_A_Barry
Star Contributor
Star Contributor

Ron, 

 

I finally reviewed all the SAP files and OnBase data.  It appears everything works correctly even when the file name does not contain the PO Number + unique ID.  I just needed a refresher as I hadn't walked thorough the entire IDoc and SAP tables in quite some time.  The issue appeared to be a set of Idoc MIRO entries sent to processing that was not part of config and it was cluttering up the folder.  The SAP team realized they had not reconfigured the filter for the Idoc for the new user ID associated.  Since that filter was put back in place, it appears all POs are being processed as expected.

View answer in original post

4 REPLIES 4

Ron_Simko
Star Contributor
Star Contributor

Hi Ellen,


The file name is created using the configuration of the IDOC mapping in the BIC configuration module and can be found in the config.xml file located in the archivelink folder (typically C:\inetpub\wwwroot\ArchiveLink).  In your case it is taking the business object ID off of the IDOC, followed by 20 spaces, followed by the result of query to the NAST table to get the OPTARCNR field of the message created by the pdf file creation.  This value will ultimately match the OBJECT_ID in the TOA01 table.  The IDOCs without the proper file name won't process because the BIC processor first checks to make sure that value exists in the TOA01 table (makes sure a link is created on that document).

 

As to why you don't see that value in the file name, there could be a couple reasons.... perhaps something wrong with the IDOC (less likely), such as the field BELNR isn't populated (that makes up the 4500770917 part of the example you gave).  The other is that the pdf wasn't created / the NAST entry doesn't exist or exist as the config expects (that is the 0005070364 part of the example you gave)... That query is typically the BELNR from the IDOC (field NAST-OBJKY) plus the message type of the pdf configured in tcode: NACE  (field NAST-KSCHL).

 

The only other potential issue that came to mind was an issue that was fixed in build 16.0.0.6.  If you are on an earlier build, please let me know and I can go into more detail.

 

Please feel free to follow up with any questions or clarifications. 

 

Here is an example of a typical PO idoc configuration as a reference taken from the config.xml file....

 

7e9c3c1c9fa449ddaf5ca1a5377cac45

Ellen_A_Barry
Star Contributor
Star Contributor

Thanks Ron, I will dig into this a bit further - BELNR is set to the PO on all these mis-named files.  Also a Purchase Order document exists in workflow to pair to for indexing.    TOA01 contains the entry, and that is as far as I got.  I will check the other files that you mentioned. This is a random issue as the PO Idocs get processed when the name string is correct.  

 

Appreciate the details and will get back on this tomorrow!

 

Ellen_A_Barry
Star Contributor
Star Contributor

Ron, 

 

I finally reviewed all the SAP files and OnBase data.  It appears everything works correctly even when the file name does not contain the PO Number + unique ID.  I just needed a refresher as I hadn't walked thorough the entire IDoc and SAP tables in quite some time.  The issue appeared to be a set of Idoc MIRO entries sent to processing that was not part of config and it was cluttering up the folder.  The SAP team realized they had not reconfigured the filter for the Idoc for the new user ID associated.  Since that filter was put back in place, it appears all POs are being processed as expected.

Awesome.  Thank you for the update, Ellen!

Getting started

Find what you came for

We want to make your experience in Hyland Connect as valuable as possible, so we put together some helpful links.