Maximo Open Forum

There are three relationships out of the box, though only 2 that are most likely relevant (one is for consignment which most customers don't utilize). If you're looking for details about the company assigned as the primary vendor, you can utilize:

VENDOR.CUSTOMERNUM

If you want the manufacturer associated to the primary vendor you can utilize:

MANUFACTURER.CUSTOMERNUM

If you wanted to display this in the INVVENDOR table for each one of the vendors you can use the same relationship names as above. 

There are three relationships out of the box, though only 2 that are most likely relevant (one is for consignment which most customers don't utilize). If you're looking for details about the company assigned as the primary vendor, you can utilize:

VENDOR.CUSTOMERNUM

If you want the manufacturer associated to the primary vendor you can utilize:

MANUFACTURER.CUSTOMERNUM

If you wanted to display this in the INVVENDOR table for each one of the vendors you can use the same relationship names as above. 

There are three relationships out of the box, though only 2 that are most likely relevant (one is for consignment which most customers don't utilize). If you're looking for details about the company assigned as the primary vendor, you can utilize:

VENDOR.CUSTOMERNUM

If you want the manufacturer associated to the primary vendor you can utilize:

MANUFACTURER.CUSTOMERNUM

If you wanted to display this in the INVVENDOR table for each one of the vendors you can use the same relationship names as above. 

When you call RELATIONSHIP.ATTRIBUTE you're opening the relationship to the child table. IE in this case, when you call VENDOR.CUSTOMERNUM you are opening a relationship from INVENTORY to COMPANIES based on the vendor & orgid attributes on INVENTORY matching to the COMPANY & ORGID on the COMPANIES table. You should not get an invalid binding if you use VENDOR.CUSTOMERNUM, provided that CUSTOMERNUM is on the COMPANIES table.

I would not add a domain to this field just to support a lookup for utilizing in the advanced search. What I would suggest is utilizing the VENDOR.COMPANY field and utilizing a lookup there that includes the CUSTOMERNUM attribute. That would allow you to search in the lookup to filter for companies with that CUSTOMERNUM

There are three relationships out of the box, though only 2 that are most likely relevant (one is for consignment which most customers don't utilize). If you're looking for details about the company assigned as the primary vendor, you can utilize:

VENDOR.CUSTOMERNUM

If you want the manufacturer associated to the primary vendor you can utilize:

MANUFACTURER.CUSTOMERNUM

If you wanted to display this in the INVVENDOR table for each one of the vendors you can use the same relationship names as above. 

When you call RELATIONSHIP.ATTRIBUTE you're opening the relationship to the child table. IE in this case, when you call VENDOR.CUSTOMERNUM you are opening a relationship from INVENTORY to COMPANIES based on the vendor & orgid attributes on INVENTORY matching to the COMPANY & ORGID on the COMPANIES table. You should not get an invalid binding if you use VENDOR.CUSTOMERNUM, provided that CUSTOMERNUM is on the COMPANIES table.

I would not add a domain to this field just to support a lookup for utilizing in the advanced search. What I would suggest is utilizing the VENDOR.COMPANY field and utilizing a lookup there that includes the CUSTOMERNUM attribute. That would allow you to search in the lookup to filter for companies with that CUSTOMERNUM

There are three relationships out of the box, though only 2 that are most likely relevant (one is for consignment which most customers don't utilize). If you're looking for details about the company assigned as the primary vendor, you can utilize:

VENDOR.CUSTOMERNUM

If you want the manufacturer associated to the primary vendor you can utilize:

MANUFACTURER.CUSTOMERNUM

If you wanted to display this in the INVVENDOR table for each one of the vendors you can use the same relationship names as above. 

Based on what you've described, this field is free text on a company record, correct? If that's the case, you can't use a lookup on this attribute as it is today and I wouldn't recommend modifying it to support a lookup. Domains, java classes with getList, retrieve list automation scripts, etc. are the critical plumbing that makes lookups possible. Without one of them on your field you can't utilize lookups and it doesn't make sense to add them to an attribute where you aren't restricting the data.

What you can do is display the VENDOR or MANUFACTURER attribute instead of your VENDOR.CUSTOMERNUM attribute. The VENDOR & MANUFACTURER attributes support a lookup against the company table. I mistakenly typed VENDOR.COMPANY in my earlier reply but you can't use that and wouldn't want to use that from a search performance perspective. These attributes already exist out of the box in the Advanced Search dialog.

Lookups exist in the LIBRARY.XML or LOOKUPS.XML and are not dot notation based. If you go into Application Designer and choose Export System XML from the Select Action menu you'll be presented the option to export these two system XMLs. The one most relevant to what you want to do out of the box is in the LOOKUPS and the lookup is called COMPANIES (id="COMPANIES"). This is what we display in a lot of places inside of Maximo.

If you modify this lookup or clone this lookup (copy and paste that lookup and change the IDs to make them unique) and add in your CUSTOMERNUM attribute you'll allow the user to filter for COMPANY records that have the CUSTOMERNUM you want. They then can select them from the dialog to return the COMPANY attribute to the VENDOR/MANUFACTURER field (or anywhere else in Maximo that lookup is referenced) and be able to filter it. 

When you call RELATIONSHIP.ATTRIBUTE you're opening the relationship to the child table. IE in this case, when you call VENDOR.CUSTOMERNUM you are opening a relationship from INVENTORY to COMPANIES based on the vendor & orgid attributes on INVENTORY matching to the COMPANY & ORGID on the COMPANIES table. You should not get an invalid binding if you use VENDOR.CUSTOMERNUM, provided that CUSTOMERNUM is on the COMPANIES table.

I would not add a domain to this field just to support a lookup for utilizing in the advanced search. What I would suggest is utilizing the VENDOR.COMPANY field and utilizing a lookup there that includes the CUSTOMERNUM attribute. That would allow you to search in the lookup to filter for companies with that CUSTOMERNUM

There are three relationships out of the box, though only 2 that are most likely relevant (one is for consignment which most customers don't utilize). If you're looking for details about the company assigned as the primary vendor, you can utilize:

VENDOR.CUSTOMERNUM

If you want the manufacturer associated to the primary vendor you can utilize:

MANUFACTURER.CUSTOMERNUM

If you wanted to display this in the INVVENDOR table for each one of the vendors you can use the same relationship names as above. 

Based on what you've described, this field is free text on a company record, correct? If that's the case, you can't use a lookup on this attribute as it is today and I wouldn't recommend modifying it to support a lookup. Domains, java classes with getList, retrieve list automation scripts, etc. are the critical plumbing that makes lookups possible. Without one of them on your field you can't utilize lookups and it doesn't make sense to add them to an attribute where you aren't restricting the data.

What you can do is display the VENDOR or MANUFACTURER attribute instead of your VENDOR.CUSTOMERNUM attribute. The VENDOR & MANUFACTURER attributes support a lookup against the company table. I mistakenly typed VENDOR.COMPANY in my earlier reply but you can't use that and wouldn't want to use that from a search performance perspective. These attributes already exist out of the box in the Advanced Search dialog.

Lookups exist in the LIBRARY.XML or LOOKUPS.XML and are not dot notation based. If you go into Application Designer and choose Export System XML from the Select Action menu you'll be presented the option to export these two system XMLs. The one most relevant to what you want to do out of the box is in the LOOKUPS and the lookup is called COMPANIES (id="COMPANIES"). This is what we display in a lot of places inside of Maximo.

If you modify this lookup or clone this lookup (copy and paste that lookup and change the IDs to make them unique) and add in your CUSTOMERNUM attribute you'll allow the user to filter for COMPANY records that have the CUSTOMERNUM you want. They then can select them from the dialog to return the COMPANY attribute to the VENDOR/MANUFACTURER field (or anywhere else in Maximo that lookup is referenced) and be able to filter it. 

When you call RELATIONSHIP.ATTRIBUTE you're opening the relationship to the child table. IE in this case, when you call VENDOR.CUSTOMERNUM you are opening a relationship from INVENTORY to COMPANIES based on the vendor & orgid attributes on INVENTORY matching to the COMPANY & ORGID on the COMPANIES table. You should not get an invalid binding if you use VENDOR.CUSTOMERNUM, provided that CUSTOMERNUM is on the COMPANIES table.

I would not add a domain to this field just to support a lookup for utilizing in the advanced search. What I would suggest is utilizing the VENDOR.COMPANY field and utilizing a lookup there that includes the CUSTOMERNUM attribute. That would allow you to search in the lookup to filter for companies with that CUSTOMERNUM

There are three relationships out of the box, though only 2 that are most likely relevant (one is for consignment which most customers don't utilize). If you're looking for details about the company assigned as the primary vendor, you can utilize:

VENDOR.CUSTOMERNUM

If you want the manufacturer associated to the primary vendor you can utilize:

MANUFACTURER.CUSTOMERNUM

If you wanted to display this in the INVVENDOR table for each one of the vendors you can use the same relationship names as above.