VI Export Chain

I can not find to much help on chaining export files together.  Pretty sure this is a simple fix but I am struggling to find it.   Trying to export Purchase Order information, header and details.  I have the fields selected that I want to export from the header (PO_PurchaseOrderHeader) but, how do I indicate which details I need?  I selected the PO# I want to export and chained the next export (PO_PurchaseOrderDetail) to the first.

I am missing something in the PO_PurchaseOrderDetail export that indicates it needs to export the information for the PO referenced in the PO_PurchaseOrderHeader export.

I selected the same PO# in the select tab on the second export as well.select.pdf

  • When using VI Export to export from tables that have Header and Detail tables, if you want the detail fields, you have to select the detail table when creating the export.  This will allow you to select fields from both the header and the detail.  You could also query what you need through ODBC from Access, Excel, or a custom crystal report added to the menu.  You might want to check the Business Insight Explorer views and see if one of the existing views can serve as a foundation for you to build your own view off of.  BIE views easily export to various formats and allow setting filters.

  • in reply to David Speck

    Well I should of been more specific, I am dealing with IIG matrix details.  I selected the details table to export and included all the header information I would need in the "data" tab (see attached).  I am now left with trying to figure out how to export the "ItemCode" details from the Purchase orders on the export.  I though I could just chain another export (see attached data) that would look for the item codes exported on the first export.  Seems like you should be able to tell the second export to only look for itemcodes exported?item code.pdf

  • in reply to jland47

    I'd avoid VI for something like this.  Using your favorite ODBC / external reporting tool to pull the data would be much easier.

  • in reply to Kevin M

    Kevin can you schedule an ODBC or it has to be run manually?

  • in reply to jland47

    There are a lot of ODBC tools that can be scheduled.  Sage Alerts and Workflow is going to be a common recommendation here, but I like a 3rd party tool called Visual Cut for things like this.  You design a Crystal Report, and VC allows you to set up automation through the Windows Task Scheduler.  Output to a file, email, SFTP... very flexible.

    I've also done VBScript extractions through ODBC, and such scripts can be scheduled as well.  It's all a matter of what tools you're comfortable working with.

  • in reply to Kevin M

    I've gotten somewhat comfortable with VI and thats why I was trying to do this there.  I know we have an ODBC connection pulling SO details but I was not a part of that setup.  So I am kind of going into the ODBC option blind.

  • in reply to jland47

    ODBC is not a program, it is a connection method.  Open Database Connectivity.  If you've ever queried Sage data using Excel, that's done using ODBC.  So is Crystal Reports.

    VI is the best / only way to import, and is fine for simple exports, but for any complex exports, using external tools can make things easier.

  • in reply to jland47

    Pulling purchase order information is no different than pulling sales order information. I would get with the people pulling sales order details and have then help you set up pulling purchase order information. 

  • in reply to jland47

    Each VI job runs in its own session and doesn't have access to anything a previously run job had access to, this would include things like filters applied on the Select tab, run time parameters, or records exported, even if the jobs are chained together. 

    As has been stated by myself and others, if there is advance criteria that needs to be applied or multiple tables are required, you'd be better off using one of the other methods mentioned. 

    However, to answer your original question, assuming you are using something on the Select tab on the first header job and assuming none of these are run time assigned, you could apply the same selections to the second detail job.  If you are using run time assigned criteria, in theory, you could use some advanced perform logic to read the appropriate data files to retrieve what was used for the first job but at this point you would just be making a new wheel when there are already perfectly functional wheels right beside you.