20 Replies Latest reply on Jul 6, 2016 10:37 AM by Craig Merrifield

    Enterprise PDM data - association to ERP data

    Craig Merrifield

      Hi folks,

       

      I'm looking for advice and to benefit from your experiences in relating data in PDM data to ERP system data.

       

      Quick history -

      I've not used Enterprise PDM before, but have served as a PDM admin for other like products at previous companies so PDM/PLM is not a new environment for me. I am scheduled for admin training next week from my VAR.

       

      Current state of PDM here -

      PDM was implemented years ago, but was run by admin that was not familiar with PDM concepts. It is in need of much clean up and restructuring. This leads to my current situation.

       

      My company is looking to build integration between our ERP system and PDM (and some other systems to follow). In the beginning, there was no connection between the SolidWorks file naming (or custom properties) and our ERP part numbering systems. This association is of critical importance to systems integration. To fix this, a project was started within the engineering team (prior to my arrival) which added a custom property field to our SolidWorks files (and thus PDM) to list the ERP part number. Due to acquisition of other companies and overlapping product lines, there are occasions where a SolidWorks file may associate to multiple ERP part numbers (to one specific configuration). We do use configurations frequently (for part families) and in this case there is a need to associate ERP part numbers to each configuration of the SolidWorks file. Unfortunately when this project began, the decision was made to populate the custom property for ERP part numbers only to the @ tab in PDM. This property was left blank in the configuration tabs. Multiple entries where simply separated by a comma and space.

       

      Proposed -

      In my opinion, this property field should be filled out in each configuration for proper management of the data in the PDM database. I've read some very helpful forum posts including EPDM Configurations and Properties , but most are not big fans of using configurations. Big fan or not, I have a significant number of files using them and will need to build a solution to accommodate them.

       

      I have upcoming projects which will rely on ERP numbers to acquire the correct SolidWorks part/assembly/drawing files. These projects include Engineering Change, New Product Creation, and Deviations (among others). These three will rely heavily on workflow and datacards. Each of these projects will begin with ERP part numbers as a starting point to begin workflows, which will need to cleanly and reliably tie to the correct files in PDM.

       

      Your advice -

      So my question is this, how are you all managing this information?

      Do you agree that in this situation, the best place for the ERP part number is in a custom property in the configuration tab of PDM?

      EDIT - Additionally, if I intend to keep the data in the configuration tab, should I use the @ tab at all?

       

      Thoughts and advice much appreciated.

        • Re: Enterprise PDM data - association to ERP data
          Stephen Lapic

          We have a similar yet different situation.  Our numbers are the same but our ERP only allows 40 characters for the description so I have two description lines - short and long.  The long is used in the title block, the short is mainly abbreviations, and both can be used for searching on the data card.

           

          We also have part families with many configurations.  Because of this almost all properties are in the configuration tabs and just a couple are in the custom tab.  It works out very well for us and none of the engineers have any problems with it.

          • Re: Enterprise PDM data - association to ERP data
            Flemming Nielsen

            Hi Craig,

            Searching for ERP and EPDM integration, I found your topic and just wanted to add my two cents.

            We have, and still have quite much confusion about the @ tab, but as we understand it now, it can be used for properties that applicable for all configurations in that part/assembly. However for us, and other companies I have worked in, configurations is to be avoided if possible.

            You will discover that you can't control each configurations versions and won't be able to separate revisions.

            So having a need for rev control, and a part changing in dimensions or tolerances, going with configurations is in my opinion a very bad direction.

              • Re: Enterprise PDM data - association to ERP data
                Stephen Lapic

                We maintain revision control by the revision of the drawings for each configuration, which is, of course, controlled by the workflow.

                 

                When you make changes to the model file you need to leave a comment that indicates which configuration you worked on.  We use numbers to differentiate configurations separated by a dash, ie -001 and -002, that way it is easy figure out which is which.  Each configuration also has their own description.

                 

                The drawings are linked to specific configurations.  We find it real easy to keep track what is what and when anything was revised on each configuration.  So as long as you have your process defined and a good workflow then using configurations can be an effective way of controlling a family of models.

                  • Re: Enterprise PDM data - association to ERP data
                    Craig Merrifield

                    Hi Stephen,

                     

                    Thanks for joining in again. The process you've outlined appears to be very well thought out. I'll be making some notes and may adopt some components of it. Our current process for documenting changes includes some similar elements, but does not capture the level of detail I feel is truly needed.

                     

                    What are your thoughts on my previous comment:   

                    "...since I'll be storing config specific data, should I bother with the @ tab at all? I seems cleaner/simpler to put the relevant data all on the config specific tabs and avoid use of the @ tab... My focus is proper management of the data so customizations can be made to PDM leveraging this data. I believe it will lead to cleaner programmatic searches if all data is stored together on the config tabs."

                      • Re: Enterprise PDM data - association to ERP data
                        Stephen Lapic

                        Craig;

                        I put the file number in the @ tab.  It's probably not needed but I like to see it there.  I also add a Description with just general information in it.  Can't be specific since that is in the configs.  Once again it is probably not needed.  If there is anything that is going to be consistent for this family then you can have it here.  For instance, if everything is going to be one material type then you can put it here.  Otherwise nothing needs to be in here since everything else would be configuration specific.

                          • Re: Enterprise PDM data - association to ERP data
                            Craig Merrifield

                            Stephen,

                             

                            Some of our files may have a common variable across configurations, but others may not. In an effort to be consistent, I'm thinking that all data gets stored in config specific tabs, but I do like your use of file number and basic/general description on the @ tab.

                             

                            I'm also trying to wrap my head around an idea that maybe each config would have a revision variable that only gets updated if that config is affected by a change. This would mean that the file revision and config revisions would be independent of each other...

                             

                            Another member made the following comment in the post EPDM Configurations and Properties

                            "...All values from the EPDM vault workflow are only placed in the @ tab.  Values put in with SolidWorks go into the config. specific tab.  SW copies @ tab values automatically if it is referenced in the configuration."

                             

                            I have not had time to investigate this, but it is logical that the workflow would not have direct access to one configuration's properties. Instead, it has access to the file as a whole and would thus would only update variables in the @ tab. Does this sound right?

                             

                            Thanks for your feedback!

                      • Re: Enterprise PDM data - association to ERP data
                        Craig Merrifield

                        Hi Flemming,

                         

                        Thank you for your reply.

                         

                        My understanding of the @ tab is in line with yours. My dilemma remains the same though in that I have inherited an environment where configurations have been used in a significant number of files. Knowing this, it has become clear that data needs to be stored at the configuration specific level in the models where configurations exist. The real question is, since I'll be storing config specific data, should I bother with the @ tab at all? I seems cleaner/simpler to put the relevant data all on the config specific tabs and avoid use of the @ tab... My focus is proper management of the data so customizations can be made to PDM leveraging this data. I believe it will lead to cleaner programmatic searches if all data is stored together on the config tabs.

                         

                        This is my current thought on the subject, but welcome comments and debate.

                         

                        I want to be careful not to turn this thread into a configurations vs no configurations debate, but I do believe that configurations are valuable tool in the design environment. Unfortunately, they undeniably create data management challenges. Either way, I need to accommodate them in my solution.

                         

                        Thanks again for your thoughts on the matter

                          • Re: Enterprise PDM data - association to ERP data
                            Flemming Nielsen

                            HI Craig,

                            Unless you have general/shared information to put on the @ tab, you can just ignore it. For us, not working with configurations, we try to ignore it and only use the default config tab. We do have configurations, but we use them only for illustrative purpose.

                            Configurations are fast and if you have well defined processes, I am sure they can be profitable for you.

                            Also not starting a pros/cons discussion, but using configurations in EPDM, you will notice the "Where used" and "Contains" tabs pretty much useless :-\

                              • Re: Enterprise PDM data - association to ERP data
                                Craig Merrifield

                                Hey Flemming,

                                 

                                I'm working on the "well defined process". I've found a number of discrepancies in the way that configs have been named and used. I'll be working to rectify this...

                                 

                                I'm curious about your comment: "...you will notice the "Where used" and "Contains" tabs pretty much useless..." I immediately starting reviewing functionality in these areas and initially I find no major hiccups with the way it handles the data. We include configuration name in the column sets for both Where Used and Contains, which I appears to feed back the correct information and I believe should allow me to acquire the information I need. Additionally, our convention is that the configuration names match our ERP part numbers (most of the time) and I intend to maintain that information at the configuration specific custom property level as well. If I've missed something significant, please share! My intention in this post is to get a well rounded education in the way my peers are managing data (and data issues).

                                 

                                Thank you!

                              • Re: Enterprise PDM data - association to ERP data
                                Flemming Nielsen

                                Hi Craig,

                                I'm far from being a PDM specialist, so I might be wrong here.

                                But if I go to "where used", and in version select "All versions", on a configured part, I will get a huge list of where my configured part is used. Here I'm unable to select a specific configuration.

                                For us this is a problem. We cant see what a change/revision of this part in a specific configuration, will impact.

                                  • Re: Enterprise PDM data - association to ERP data
                                    Craig Merrifield

                                    Hi Flemming,

                                     

                                    I finally got a break to return to the forums! I just took a look at the problem you outlined above and I see the dilemma. I'm not sure why they would limit the user by greying that out when going to "all versions". You could compile the info by going version to version and config to config and saving out to files, but that would quite the daunting and tedious task...

                                    It would seem that this information could be compiled using a custom query or programming. Unfortunately at this point, its a bit out of reach for me. If I come up with any other ideas related this, I'll be sure to post.

                                     

                                    Thanks for sharing!

                              • Re: Enterprise PDM data - association to ERP data
                                Steven Dod

                                We uses configuration specific properties on a limited basis.  We also needed to update the configuration specific properties to match our ERP.  I wound up writing a small utility program that takes the data from a spreadsheet and writes the data to the file properties.  Using the EPDM API you can batch write this information to the file specifying the configuration it goes to at the same time.  Part of the driving force behind this is we purchased a program called CADLink that connects our ERP (Epicor) to EPDM and the properties are based on the configuration specific properties so all of these needed to be updated.  If you are not comfortable writing programs yourself we have used a company called xLM Solutions that is very good.

                                 

                                Steve