Kevin is correct that the field can’t be disabled in the traditional sense, but there is a work-around to get what you are looking for.  
Also – It appears that you are only trying to “disable” the field for the Component Manufacturer subclass – which I would assume means you want it to still show up on the others.  Changing the name of the field would probably not be a good solution if this is the case as it would be renamed for all of them.

In order to hide the field from all subclasses – you would need to locate and modify any/all of the “Read” privilege masks which currently allow users to see this field.  Then simply remove the “DUNs” attribute from the ‘Applied to’ section. Also remove any “Display No Privilege Fields” privileges (if applicable) – otherwise they will still see the field itself, just not the populated values.

If you only want it hidden from a specific subclass, but visible in the rest (which might be more work than its worth) – you would need to create some new Criteria and Read privilege masks and only remove the field from the privileges that pertain to the Component Manufacturer subclass.

Nelly – There is a “Pending Changes” field/column available on the Affected Items tab.  If the affected item is on any other open changes – a dot is displayed in this column. You can click directly on this dot to go straight to the Affected Item’s ‘Changes’ Tab where the pending changes can be viewed.

If you want to handle this requirement through specific roles/privileges that only give the user access to specific Items – there has to be something consistent about the items against which criteria can be created (similar to what Carlos suggested above with the subclass)  If using subclass doesn’t work – you might use an item attribute to determine which items the user has access to.
For example – you could create a new “access control” page two (multilist) attribute that uses the Users or User Groups list.  Then create the appropriate Discovery/Read privileges using new criteria that checks if  “Access Control contains $User” 
This option would still require populating the field for the Parent item and its children, but is much less tedious as you can use the import tool to mass update the “Access Control” field for all of the required items with the appropriate user/user group.

If you want the event triggered when the user adds the Mfr Part to the Manufacturers tab – you should be able to accomplish this using the “Update Table” event type.

Alternately – don’t assign any roles directly to the user’s account that give them any Read-Part privileges.  Instead – navigate to the Part(s) that you want the user to be able to read and use Actions->Sharing in order to share one of your permanent roles for that part.  If you want the user to be able to access the BOM items as well – navigate to each of the child items and use Actions-> Sharing for those items as well.

Note – the role(s) you should “share” with them for these items are the roles that allow YOU to discover/read the items.  Even if those roles allow you to view more/all items – ‘sharing’ the role(s) from a Part’s Action menu  is not the same as  permanently adding the role to their user account.  It only gives the recipient access to the role(s) as it relates to that specific part.

You need to have the ‘FileLoad’ privilege associated to you user account in order to access it from the Tools menu in either client.  You will also need the same privileges that would allow you to modify the objects’ attachements directly in the Agile clients.

My best guess as to why the script isn’t working in all cases would be that it is looking for the latest released revision of the item to change the flags rather than the latest released ECO revision. This might explain why items that were last released on an SCO or MCO are not being updated correctly.  
Anything that is Revision Controlled can only be changed on the latest released ECO revision.  Take attachments, for example:  If I have appropriate privileges, I can modify attachments directly on a released item record. However, since attachments are revision controlled – If the item was last released on an MCO  – I cannot modify the attachments unless I change the rev drop-down to the latest ECO revision.

You will need to use the FileLoad tool for attachments rather than Import.  
First Import the items from excel to get them created/updated and then use FileLoad to mass upload the attachments to those items.  

This involves creating an index file in a particular format so the system knows where to locate the attachements, what type of attachment it is, and what Agile object/rev to attach it to.

The general File index structure is as follows:
ObjectType, PrimaryKey, SecondaryKey, Path/Filename, AttachType, Description,[attrib1,=”value1″,attrib2=”value2″…]<CR>
Example:
Item,P0001,,http://www.oracle.com,URL,Description=”Fileload,Test”,Text01=”Test_Fileload_Text”<CR>

I’d definitely recommend reading the Using FileLoad section in the “Agile PLM – Import/Export User Guide” thoroughly if you are not familiar with the process.  It is not overly complicated, but it does require some particular planning and preparation. 

It looks like you may just have a problem with the way your template is setup to handle the BOM & MFR data.  
The Item information doesn’t need to be repeated for each AML row.  Also – the first AML row can be on the same line as the Item Data and additional AML rows are only necessary for multiple AML entries.

See the attached file for what I believe to be the correct format (lower green section) for your sample upload data.
 I’d try the lower format and see if it works better for you.

Divakar – you shouldn’t have to create any new role or criteria for this.  You just need to select whatever role(s) it is that allows YOU to read that Part/BOM.  Even if the role is something like “Read Only – All Items”  sharing that role with another user will only give them access to the role for that specific part.