Automated Interface with SW BOM

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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Kman wrote:

<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.
--
Remove my extraneous mandibular appendages to reply via e-mail.


Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
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

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
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

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Kman wrote:

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)
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
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
snipped-for-privacy@peoplepc.com (Kman) wrote in message

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here. All logos and trade names are the property of their respective owners.