Yes, at my old job all of the ECN's were in the EPDM vault and yes they can be tied/linked
to SW files as well. Plus the EPDM system can be set up to automatically pull ECN numbers
as well as the part numbers for your parts and assemblies.
I don't know anything about SAP, but where I am at now we use Vantage and have been told
by our VAR that EPDM can be integrated with that as well.
Hope this answers your question or helps you.
Thanks Scott, that answered my question.
One more question, does EPDM handle the actual text of the ECN or do you use Word etc?
No problem. Glad I could help.
No, you still have to do that in Word. It just keeps track of the files and filings
Actually you can use EPDM to add or update text in forms. I'm working on this right now. I've got it to update fields in the body of the ECN but it's not working with the header or the footer yet.
Here is a modified version of the macro in the solidworks manual I came across, which resolved a couple issues I had. The header gets updated and if you happen to use a table or text boxes this macro will get those to update as well
Dim myStoryRange As Range
For Each myStoryRange In ActiveDocument.StoryRanges
Do While Not (myStoryRange.NextStoryRange Is Nothing)
Set myStoryRange = myStoryRange.NextStoryRange
We have great success using Excel as the ECN form and I bi-directionall pass data to and from ePDM variables. I did not have much luck with Word.
I found an article in the knowledge base that had a macro to add to word that fixed that problem as far as filling out the form with transition commands and using the data card, but I haven't had any luck sending changes I make from the document to the data card.
In Word it only works one way.....change from ePDM to Word. There's no way I've found to make changes in Word propogate back to ePDM.
Basically oyu have form fields in Word linked to custom properties. For whatever reason, they do not update when the properties change so when ePDM changes the properties, the form fields that are linked to them don't reflect the changes unless you hit F9. The macro mentioned you can add so that it refreshes the document "On Open". Of course the problem we have with even is that is Microsoft turns off the macro launching by default to protect you against virus in Word VBA......you have to go into each machine and set the Trustcenter in Word to automatically run macros.
Many customer have created 'smart' Word or Excel documents for this purpose.
In Word documents, I've seen people map Word document properties to EPDM file card variables and then use fields within the Word document to read the values of the document properties to populate the text within the document. (you will need an autorefresh macro to refresh the contents on open).
This technique uses the features of Word.
To learn more about how this works, I suggest searching the Microsoft website for 'Exploring the Dynamic World of Word 2007'
Just another suggestion.
As we all understand the backend to every data card variable is a database record linked to an record in the document (real or virtual).
One concept would be to eliminate the need for word, excel, etc... complete and just use virtual documents to represent an ECN item. It could work with tall the same workflow requirement, etc that any other file item in the vault would and also doesn't require all the variable/property mapping.
Finally, for those that would require a printable document. Create a live reporting using Reporting Services, Access, Crystal, Excel, etc...
Whatever your reporting tool preference...
The word approach is really just translating information from the datacard anyway, so unless you have a need to have the word document filled out with information that wouldn't need to have tied to a datacard why not.
Just a thought!
We started to use an Excel file for the ECO object since that's what we used prior to PDM........then decided to just use a virtual document (cvd) since no one would be printing it anyway. And like you say, you could create a report or some other tool to display it in a printable format if that's required.
Here's the code I'm using in Word to auto update the fields on open:
Dim rngStory As Word.Range
Dim oShp As Word.Shape
'This updates all fields in the word file.
For Each rngStory In ActiveDocument.StoryRanges
On Error Resume Next
Select Case rngStory.StoryType
Case 6, 7, 8, 9, 10, 11
If rngStory.ShapeRange.Count > 0 Then
For Each oShp In rngStory.ShapeRange
If oShp.TextFrame.HasText Then
On Error GoTo 0
'Get next linked story (if any)
Set rngStory = rngStory.NextStoryRange
Loop Until rngStory Is Nothing
Private Sub Document_Open()
Call UpdateFields 'Call the update fields code.
So I get that you can push changes from word to the data card, but would switching my form to an excel document fix that? Unfortunatly switching to a virtual document won't work for us right now. Our documentation system is still in the stone age, we're still tracking part numbers with hand written log books so going completly digital is going to have to wait on some retirements.
I'm guesing you need to print the ECO form still?
You could link it in Excel......you have to created Named Cells and then link cutom properties tot he named cells. Then setup you ePDM mapping to link the ePDM variable to the Excel properties.
I''ve also seen examples where an xml or html file was used to have something for viewing purposes.
Yeah we're still paper slaves here.
Does excel allow you to update the form and have that populate the data card or is it one way like the word document?
First of all let me say this is just a way that I've found that you can have ECN's filled out, still be attached to the drawing file and continually updated and managed from PDM. What I did was to create a Standard Titleblock with all the information we need on our drawings, Then I created a separate template (Sheet Format Style) that works as the ECN form. On the ECN Sheet Format I designed it to look just like our actual Excel ECN form then I created my varibles for the ECN Form and made inputs in the data card for these varibles. That way you can fill out the data card when there are any changes and the variables will update automatically on the ECN Sheet or Sheets.
Now how you utilize this method it is to Create a New Sheet with your Drawing as normal but add another new sheet either the 2nd sheet or whatever sheet it may be if you have multiple sheet drawings. On the New sheet you added after your drawing sheet or sheets reload the new ECN Sheet Format that has all your varibles in it. Then save the file and check it back into PDM. You now Have your ECN controlled by PDM. By doing it this way the ECN stays with the drawing and is constantly updated.
Now the Pros and Cons of this method (These are just mine, your particular case may have more or less)
File is Constantly Updated when opened
Easily updated through PDM by checking file out then updating
It is Completely searchable through PDM
ECN Sheet shows up on Tabs in PDM
Easy to print from PDM by using Control P
Ability to manage Files and Changes
You don't have to worry about Microsoft Windows updates
You dont have to worry about what versions of Excel or Word files people in your office have
Coupled with edrawings anybody can view, print, markup or send files
No extra files to manage and make sure are updated!!!!
You have to create the variables (Think ahead when you create this I used a blank ECN and wrote my variables in the blanks spaces)
You have to design the Sheet Format to Match your ECN
So to answer the question "Can EPDM handles ECN's?" From my point of view Absolutely works wonderful
That's a very interesting idea, but we use a separate numbering system for our controlling documents (we call them DCRs for Document Change Request). It occurs to me that one could create a totally separate drawing file for each DCR using a separate Serial Number system and keep them in a separate folder so they could have their own data card and be easily differentiable within workflows. This would have the benefit of full bi-directional updating and maintaining a native SW file format.
Our real problem with many of these solutions, though, is that we control multiple documents with a single DCR form, so we need the ability to track and maintain a non-predetermined number of line items for each DCR. This can be done textually in a Word or Excel doc, but to maintain the relationships within PDM requires creating and maintaining references as well, and I haven't found a way to merge the two, such that creating a reference causes a line item to be added to the document, and vice versa. Short of serious custom programming, I think we'll have to muddle through the way we are for now.