"1) So let's say my customer sends me a disk of their standard parts, which have already been logged into SmarTeam. These parts all have a ST log number listed in the Custom Properties box. So I use these parts on my job and send the job back. When my customer goes to log the job into ST, why can't ST read the Custom Properties and recognize that the file is already in its vault?"
It's kind of difficult to explain this but I will try. If the parts that your customer sends you truly are standard library parts that YOU NEVER MODIFY (EVER) then in theory the way that SolidWorks works it shouldn't be a problem. However when the customer goes to save your work into SmarTeam what the software is doing is generating meta-data that "lives" on the database which in turn actually tells the software what files are used where (i.e. the database kind of manages the files).
When someone is working in SmarTeam and wants to use a library component (e.g. a standard fastener) they use SmarTeam to track the file down and insert the instances (copies of files in the vault) into the design layout/assembly. At the same time this is happening SmarTeam is updating its database so that it reflects what's happening in the design layout/assembly. It doesn't really have to do with custom properties (which CAN contain a copy of certain database info) when the files go back in under the scenario that you're working in. Your customer saves your work into SmarTeam (which generates the meta-data). Whether you used their standard files or not SmarTeam doesn't know anything about this which is why it generates new numbers everytime you send something back to your customer and they put it into SmarTeam.
Actually, it occurs to me that (at least as I recall it) even simply checking the files out might not be good enough. I wouldn't be surprised if SmarTeam tried simply generating new numbers even if you tried doing it as I originally suggested. As I indicated it's been some time since I last used SmarTeam extensively so I'm somewhat out of practice. I'd suggest that you attempt a dry run test.
"2) My customer uses these same std parts in house so doesn't leaving them checked out make them unaccesable to other users there?"
No, because other users can access copies of any files in the vault. It's important to understand that files in the vault never actually LEAVE the vault but are actually copied out (first to a temporary directory, then to the person's "work" directory). The database just informs other users that someone has something checked out and that they can't MODIFY that file. They can, however have a copy of the file (which is read-only and can't be checked back in to the vault and possibly overwrite the original - this is another subject though).
"3) I do not know which of their std parts I will be using on any particular job until I am into the job, and even then I may add more of subtract more. So it is not very practical to have him check out any part I could possibly use."
This is why I mentioned that it's best to work within the SmarTeam environment. Unfortunately what you've described is also a consequence of working outside of your customers' SmarTeam system. The system is setup so that it manages virtually every aspect of the file management process. To make it work correctly you really need access to the system or someone working with your customer who's a guru with knowledge of how to work SmarTeam inside and out (I'm not under the impression that someone like this is currently available to you).
"4) What if my customer gave me a disk of all of their std parts that have been logged into ST. Then when I send him the finished job, what if he looks to see all of the parts that I used, then checks all of those out of his library? Dumps my job into his work directory, then checks them all in that way? Is that feasible? Easier maybe?"
This is worth a shot. Based on the new info you've given me, it sounds more practical for how you're working with your customer in any case. As I suggested earlier in this reply give that a dry run a see how it works (if it works, keep your fingers crossed).
"Am I missing something? I don't really see the benefits of using ST. I just have all of my files in organized directories and everything seems to work fine..."
I have no doubt that your method does indeed work fine but I'm under the impression that you're working a smaller group in a company that doesn't have need for a widespread dissemination of SolidWorks design data and the like (my group works in a similar fashion to what you describe). SmarTeam is used in situations where data needs to be available on a widespread basis (sometimes not very practical to do in a smaller group) or where design data needs to be vaulted and more tightly controlled (shared folders might work in some cases but in other cases the brass of a particular company just isn't comfortable with that method).
FYI I was asked a couple of years ago to find a method of working that minimized the SmarTeam software's grasp on the file management aspects to simplify things and never really came up with anything acceptable to my overlords. Hence, we suspended our installation and I wrote some custom software which manages our design files/data in a more streamlined fashion. You might want to ask your customer whether or not they evaluated a package called PDMWorks which allows for a bit more flexibility (by my reckoning) than SmarTeam. It doesn't have the ability to manage other types of documents (at least not that I'm currently aware of) such as Word, Excel, AutoCAD, etc.
The bottom line is that SmarTeam is complex software (regardless of how they try to sell it off as being otherwise) with a pretty good-sized learning curve.
Hope that helps,
Chris Gervais
Mechanical Designer
American Superconductor
