Automated Interface with SW BOM

Discussion in 'SolidWorks' started by Kman, Jul 20, 2003.

  1. Kman

    Kman Guest

    We are seeking a process to link SolidWorks BOM to a MRP type
    application "Visual Manufacturing" by Lilly Software. Is anyone using
    Visual Manufacturing and SolidWorks applications together?

    Interface Requirements:
    Create a SolidWorks BOM and click a button on menu to automatically
    upload data into Visual Manufacturing. Automated tasks include: SW BOM
    data to create part maintenance records and part numbers, verify the
    correct information is present and entered according to company
    defined syntax, re-run the interface to add additional BOM items to
    Visual Maintenance records as necessary.

    I would like to talk with anyone that has successfully implemented SW
    BOM to Visual.

    Kman
     
    Kman, Jul 20, 2003
    #1
  2. Kman

    Jim Sculley Guest

    <soapbox>
    Wouldn't it be easier to simple enter the information into the MRP
    system directly? With a good MRP system, the SW BOM is no longer
    needed. The BOM in the MRP is the master document. The SW assemblies
    should be built using items from the MRP system, not the other way around.
    </soapbox>

    Jim S.
     
    Jim Sculley, Jul 20, 2003
    #2
  3. Take a look at "ToolWorks BOM Export" http://www.toolworks.info. This
    product exports custom property information from your SolidWorks Assembly to
    a comma-seperated format. Could be usefull for you.

    Best regards
    Jess G. Frandsen
    SDH Development
    http://www.toolworks.info
     
    Jess G. Frandsen, Jul 20, 2003
    #3
  4. Kman

    Kman Guest

    Hi Jim,

    We use custom properties to further define parts, assemblies and to
    populate the BOM. SolidWorks has already performed the work for us and
    now it's just a matter of transfering this information to another
    application.

    Our present procedure is to create a SW BOM (stand alone). Forward the
    SolidWorks BOM to manufacturing for manual entry into MRP. The
    information has now been handled twice and no connectivity.
    Eventually, the MRP and SW BOM don't match due to input and update
    errors. The extra handling operation adds unnecessary labor.

    Our shop prefers to receive the BOM on the assembly print. We used to
    have seperate BOM sheets that accompanied the assembly prints to shop
    floor. To often the marked up shop assembly prints came back without
    the BOMs.

    Our goal is to reduce complexity and minimize potential errors.

    Ken
     
    Kman, Jul 26, 2003
    #4
  5. I haven't worked with SolidWorks but I've been a user of Vmfg for 4
    years. I converted all of our bom/routings into Vmfg's multilevel
    masters and then wrote our MRP software. First and foremost Vmfg
    doesn't have standalone routing and BOM structures. The first step is
    to create a work order header record. (i.e. parent part) Next at least
    one operation record must be created before any components can be
    added. There are various bells and whistles in support of their finite
    scheduler that you may/may not want to consider. If you use multilevel
    work orders it requires some effort to clean up low level code to
    correctly allocate replenishments in a MRP implementation. If you have
    any specific questions feel free to contact me.

    Brian Wirthlin
    Seiler Instrument Company
    314 968 2282 (x360)
     
    Brian Wirthlin, Aug 1, 2003
    #5
  6. Kman

    Len K. Mar Guest

    Hi,

    I am working with four clients to try and tie SW to various MRP/ERP
    programs. We are looking at a fifth client who is using Visual
    Manufacturing but have not implemented as of yet.

    Each of the other users have different systems but their requirements
    parallel yours almost word for word.

    We will be using DBWorks (from Mechsoft)set up almost identical
    systems for each user. The primary difference will be the flat
    importaion file used by each MRP system. DBWorks has a lot of very
    nice built in features that make it suitable for this type of
    application. One of them is an ODBC interface that allows the user to
    tie in DBWorks metadata with external data sources. An example of this
    feature would be to populate a purchased part (SW model) supplier
    metadata field with a drop down list of approved suppliers obtained
    from MRP system. Other examples include "unit of measure", finishes,
    make/buy flags, costs, etc...

    DBWorks has the capability to "tag" various metadata fields to ensure
    they are filled out prior to releasing an assembly/part. This feature
    will be used to ensure MRP data fields needed to create an Item Master
    are filled in correctly prior to generating and pushing data to MRP
    system.

    Caveats:

    The purpose of the SW/DBWorks/MRP interface is to use the parent/child
    relationship of a SW assembly (Engineering BOM) to directly create a
    master Manufacturing BOM. i.e. eliminate dual entry of items and
    associated chance of date entry errors.

    SW library items are referenced to the MRP system to ensure they are
    valid items (i.e. Manufacturing as obsoleted the part/assembly). No
    attempt is made to override the Engineering Item supplier with the
    Manufacturing supplier (i.e. Engineering prototype suppliers differ
    from manufacturing suppliers -- prototypes require parts yesterday and
    you will pay for it accordingly in order to get the delivery.
    Manufacturing suppliers have greater lead times which means they can
    order the parts in when needed - at a lower cost). The next time you
    drag and drop the part for a prototype (SW library part)you want the
    engineering supplier - not the manufacturing supplier.

    Creation of SW parts and assemblies use valid MRP values to populate
    DBWworks metadata (i.e. valid data entry through the use of listboxes
    and comboboxes -- thereby eliminating invalid data entry.

    DBWorks is used to ensure MRP required data is filled out prior to
    releasing top end assembly (it will list metadata fields that need to
    be addressed with a bright red background colour).

    Once Master Manufacturing BOM is created the Engineering BOM is used
    for reference purposes only. Released products (manufacturing ) drive
    engineering change orders. Updating master BOMs through DBWorks/SW is
    not advised once product is released to manufacturing. (Note - during
    developemnt this would be okay since a gate reveiw should catch any
    obsolete parts/assemblies not being used in production version). YOur
    original post included adding parts to a finished product -- but no
    mention is made of those items you have removed.

    Bi-directional capability between SW/DBworks & MRP system should be
    avoided (other than populating metadata listboxes in DBWorks).
    Engineering BOMs and Production BOMs are like apples and oranges. Both
    fruits (BOMs) but with different requirements.

    Creating Production BOM's using flat file imports by-passes the checks
    and balances of the MRP system. (i.e. systems used to ensure manual
    creation of valid master BOM when using MRP data entry fields). Like a
    computer registry you better understand your MRP system 100% prior to
    altering it at the database level. This is ESPECIALLY TRUE on the
    accounting side where prototype builds are treated differently than
    production work orders. You do not want to be backing out of accounts
    after a month or year end has been done. Tax credits, expensing out
    the prototype, having a client want to buy your prototype, etc... all
    have serious accounting ramifications.

    Ensure the SW/DBWorks data used to create your item masters has been
    checked and verified (use SQL calls to MRP item master) prior to
    importing into an MRP system. Cross referencing using more than one
    system to "self check" is highly recommended. It goes without saying
    that you should limit the access to the programs that will be used to
    generate and import the raw data to your MRP system (Will be using
    DBWorks administrative set-up to control who has access to the
    template and script files).



    Hope this has been helpful.

    Cheers,

    Len K. Mar, P.Eng.
    E-data Solutions
     
    Len K. Mar, Aug 3, 2003
    #6
Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.