I guess to a large extent they are want you want them to be.  In general we think of parts as physical things represented in PLM that are used to manufacture our products. We include software within parts which while you could reasonably argue are not physical but is required to produce a functional product.  Again for us Documents is where we collect our product design collateral. Beyond the specifications that describe fit form function of the physical parts there are lost of documentation required/produced that are abstracted from articulating the physical item. Here I am referring to thing like product requirements, test plans and reports, simulation output, product architectures. All vital to understanding the evolution of product, but not essential in describing the physical product.

Not a black and white topic, I am sure other swill offer a different opinion.

The easy answer is that due to the way the system is built, providing two separate classes offers the ability for the business to create two completely independent and unique page two attributes.  That is most likely the biggest difference you will find.

If you are seeking how to define a part versus a document… this is a bit more tricky but you can do it by looking at what goes into your product… any physically defined item or IP is most likely a part whereas supporting documents or procedures will be documents.

Both are great answers and absolutely correct.  I think we all know that it can be a bit tricky to get a solid grasp on what the various classes should/shouldn’t be used for – especially when you are new to Agile.
I like to break it down as simple as possible for users when it comes to determining whether an Item should be set up as a Part or a Document.

– Part: Any item with an associated cost that is ordered/shipped, OR is ‘part’ of what is ordered/shipped, OR is included with what is being ordered/shipped.

– Document: Internal documentation that may or may not be related to Products/Parts.  Procedural documents (SOPs), Manufacturing Processes, Employee Guides, etc. 

Keep in mind that users often refer to file attachments as ‘documents’ and files can be attached to both Part and Document objects.  This only adds to the confusion and its better to clear up the terminology as soon as possible. If you have a file (i.e. a product specification, engineering drawing, etc) that controls a specific Product/Part – it can often make more sense to simply attach the file directly to the Part record instead of creating a separate Document object. 

This is all very high-level and there are always exceptions. I’d be happy to discuss in more detail if you’d like.

Best of Luck!