3 Replies Latest reply on Feb 6, 2012 2:24 PM by Corey Hinman

    Using BOM export for ERP import (seeking Advanced user advice)

    Corey Hinman

      We are planning to export our BOM's in XML format for upload into Epicor 9 ERP. I have some ideas on the best way to accomplish this.

       

      1- Computed BOM. Easy right? A few issues. We have non-modeled items to include, such as adesives that don't exist in the CAD system, some of these items are "make-froms" which would carry another BOM with them.

       

      My solution for this is to create virtual documents with the sldprt extension, this way I can include variables such as supplier, supplier part number, unit of measure, etc that are used on all SW part files. This also would serve to create a "where used" on these virtual items.

       

      Virtual docs would be copied and pasted as reference onto the assembly in question, and then I would Save the BOM, deselect "as-built" and modify the quantities as needed.

       

      When the ECR was sent through the "approve" transition it would export the XML File.

       

      The BIG problem with this (internally) is that any ERP-only change (just affected virtual items) would require a revision to the Assembly Drawing. Why? Because the assembly (from which the BOM is generated) would need to be checked out in order to modify it, but it's in a protected "Release" state, so a new revision would be required.

       

      2- Named BOM BOMs could be saved as a named BOM and virtual parts could be manually entered. The downside being that the system will not remember line item entries when entering a new line in a different assembly, so a lot of rework. Also, the variables and where-used mentioned above would not exist.

       

      3- My solution: A combination of 1 & 2

      As in #1 above, virtual documents would be copied and pasted to the assembly file. A computed BOM would then be used to generate a named BOM. I could then modify the quantities as needed, but all the items would already exist in the BOM, no manual line entry.

       

      Variables, where used, history, etc are all maintained.

       

      The BIG advantage of this (I beleive) is that the named BOM could be checked in/out and revised independent of it's CAD Assy partner. A separate workflow would also allow for more flexibility.

       

      Have any of you done anything such as this with more than just CAD files?

        • Re: Using BOM export for ERP import (seeking Advanced user advice)
          Jim Sculley

          Corey Hinman wrote:

           

          We are planning to export our BOM's in XML format for upload into Epicor 9 ERP. I have some ideas on the best way to accomplish this.

           

          1- Computed BOM. Easy right? A few issues. We have non-modeled items to include, such as adesives that don't exist in the CAD system, some of these items are "make-froms" which would carry another BOM with them.

           

          My solution for this is to create virtual documents with the sldprt extension, this way I can include variables such as supplier, supplier part number, unit of measure, etc that are used on all SW part files. This also would serve to create a "where used" on these virtual items.

           

          Virtual docs would be copied and pasted as reference onto the assembly in question, and then I would Save the BOM, deselect "as-built" and modify the quantities as needed.

           

          When the ECR was sent through the "approve" transition it would export the XML File.

           

          The BIG problem with this (internally) is that any ERP-only change (just affected virtual items) would require a revision to the Assembly Drawing. Why? Because the assembly (from which the BOM is generated) would need to be checked out in order to modify it, but it's in a protected "Release" state, so a new revision would be required.

           

           

          We have a 'Non-Revision-Change' loop in our workflow that allows for document changes that do not represent true revisions.  For example, correcting a typographical error in a note.

           

          Jim S.