When doing a Great Plains manufacturing implementation, I’m often asked to import manufacturing bills of material from another system. Clients are sometimes very surprised to hear that GP does not have a built in BOM import tool. We do BOM imports using SQL inserts from Excel spreadsheets for clients during an implementation so some clients think that they should have a tool to import BOMs too.
I think there is a need for such a tool and we could develop one but there are some big issues for both the implementation team and the client. Let me try to explain.
There are 3 GP tables that hold BOM related data.
- BOM Header table
- BOM Detail table
- Reference designator table
The data in each of these tables has to be formatted and organized correctly. If not formatted and organized correctly, the import may not work or bad data may be imported. This leaves quite the liability for the implementation team and if users are not getting the results they expect, they do not have a useful tool.
The BOM Header table is fairly straight forward as the import would have to list only the finished good or subassemly items. Just think of the upper left quadrant of the GP Bill of Material Entry window.
The BOM Detail table is much more complex. Think of the right half of the Bill of Material Entry window. In order to get all the data imported correctly the source document would have to list each finished good and it’s components (including subassemblies) and each subassembly and it’s components. Each of these rows would have to include the correct position number and relationship to the appropriate subassembly and final assembly. This takes a long time to do. Try taking an indented BOM from another system, export it to Excel, and then put all the rows in the proper sequence and keep all the columns straight. It takes time to do this.
The formatting issue is worse for the reference designators. Most systems will export the reference desigators in one long string. GP requires that the string be broken into 21 character segments (including spaces and punctuation). I have had to format these strings into as many as 10, 21 character segments (a column for each one in Excel) and it takes a lot of time.
Users also have to know what the field values mean in these tables. For example what is a BOM Type = 1? What is a BOM Category of 2? SQL requires the use of numerics to identify these rather than ‘Phantom or Regular as you see on the front end. Did you also know that these two fields are flipped in the SQL tables? What the GP Bill of Material Entry window calls BOM Category is BOM Type in SQL.
Users also have to know the field formats that SQL uses and the field lengths. If you exceed the field length in your data source, you will not get the desired results in the front end.
In order to have an effective tool, you should validate the import with the Great Plains business logic. Do all the items exist in the Item Master, are the items setup in Item Engineering Data, are all the sites and work centers setup, does the BOM already exist, etc., etc., etc. The fact that Microsoft has not exposed a BOM API via eConnect would require complete reverse engineering or specialist Dexterity knowledge (to invoke manufacturing calls in the correct order). Business logic would also need to include handling of BOM revisions and revision levels.
So what am I trying to say here? It is my belief that using SQL imports for BOMs does not save users any time, really. By the time you get done with all the formatting, import verification, error correction, user acceptance and sign-off, you could have created these BOMs using the GP Bill of Material Entry functionality. Many BOMs are similar to each other in many organizations and the BOM Copy functionality saves users time and reduces errors.
It is fairly easy to create a SQL BOM import to get the data into GP manufacturing once you understand the table structure and have a basic understanding of SQL statements. The real issue is getting the data in the correct format for the import and then validating the data once it is in.
With the many BOM export formats being used today (single level, multilevel, CSV, XML, etc.) it is time consuming and costly to write interfaces for each. Custom adapters or complex mapping tools may be needed to handle these various formats. So it becomes a costly issue for the client or the partner.
With that said, there are some pretty nice tools available to import items and BOMs from CAD software such as Solid Works and Autocad. If clients are using these tools, we generally recommend they buy one of the integration tools that are available to export items and BOMS from the CAD software and import it to the GP item master and BOM tables. These integration tools act as a middleman and take the data from one system and format for GP.
I know that creating BOMs is no fun, but Great Plains functionality does a pretty good job entering BOMs and using business logic to validate the entry of BOM data. There just really are no shortcuts if you want accurate BOMs and manufacturing functionality. Manufacturing is complex because of all the inter-relationships involved. Everything (BOMs, routers, work centers, MO’s, picklists et. al.) works together and if business logic is not followed, it most likely will not and you will end up with a bad result. So take your time and do it right the first time.
