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?
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.
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.
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
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
Our goal is to reduce complexity and minimize potential errors.
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.
Seiler Instrument Company
314 968 2282 (x360)
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
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.
Len K. Mar, P.Eng.