Maximo Open Forum

 View Only

 Custom lookup is not working.

  • Customizations
Axel Alamilla's profile image
Axel Alamilla posted 12-18-2025 20:30

Hi, has someone tried to configure a custom lookup all from the lookup XML of the system? Giving you some context, I need to autofill the ORDERUNIT field in the wpmaterial section inside the workorder app, and the client doesn't want me to use an automation script because they have so many of them. As far as I know, the only other way to address this is with a crossover domain, but they already have a table domain related to the itemnum field in the WPMATERIAL table. I was planning to quit this table domain and construct the lookup from the lookup XML as follows:

<table id="itemmr" inputmode="readonly" selectmode="single" mboname="INVENTORY" whereclause="category='STK' and status='ACTIVE' and siteid in (select storeroomsite from maxuser where userid=:USER) and location=:location">
		<tablebody displayrowsperpage="20" filterable="true" filterexpanded="true" id="itemmr_lookup_tablebody">
			<tablecol dataattribute="itemnum" id="itemmr_lookup_tablebody_col_2" mxevent="selectrecord" mxevent_desc="Ir para %1" sortable="true" type="link"/>
			<tablecol dataattribute="ITEM.description" id="itemmr_lookup_tablebody_col_3" mxevent="selectrecord" mxevent_desc="Ir para %1" sortable="true" type="link"/>
			<tablecol dataattribute="location" id="itemmr_lookup_tablebody_col_4" mxevent="selectrecord" mxevent_desc="Ir para %1" sortable="true" type="link"/>
			<tablecol dataattribute="ITEM.commoditygroup" id="itemmr_lookup_tablebody_col_5" mxevent="selectrecord" mxevent_desc="Ir para %1" sortable="true" type="link"/>
		</tablebody>
	</table>

But when executing in the workorder app, it retrieves nothing, even when the location field is filled. I don't know if I'm doing something wrong or if it isn't possible to use the bind variables in this kind of context. 

Please give me your advice

Steven Shull's profile image
Steven Shull posted 12-19-2025 08:55

When you use mboname, you're indicating to the framework that it doesn't have a parent object which means bind variables like :location cannot be fulfilled. Your :USER would be OK because that's a special variable the framework that doesn't depend on coming from the parent. But anything from the record in question would not be fulfilled. You could create a relationship on WPMATERIAL (or WPITEM since any views can utilize a relationship defined on the table) and reference that relationship instead. That would allow you to use the bind variables.

However, it's important to understand that a lookup is a classic UI only mechanism. A table domain normally adds a validation layer that you would be removing. By moving this where clause to the lookup, this would allow users to type values that violate your criteria. And would not apply to the new UI frameworks nor integrations. 

The good news is that a crossover domain extends a table domain, so you really only need a crossover domain (no need to change the lookup). You have the same validation where clause & list where clause that you would have on a table domain with the added benefit of being able to define fields to carry over.  

Axel Alamilla's profile image
Axel Alamilla posted 12-19-2025 11:43

Hi @Steven Shull,

Many thanks for your answer. I'm trying to address this by using a crossover domain as you suggested, but even when the lookup works as in the table domain, it doesn't set the selected value in the field as it does in the table domain. Am I missing any configuration? 

In the past, when I created crossover domains, I assumed they functioned as a type of trigger that required an action to take effect. Could it be the reason why it is not working?

Steven Shull's profile image
Steven Shull posted 12-19-2025 13:26

Sorry, I assumed the java class on the ITEMNUM field was against INVENTORY since that you were using in your lookup but it's actually against ITEM, not INVENTORY. I don't agree with changing the object using the table domain nor crossover domain because you run the risk that the lookup map is adjusted to copy something from item that doesn't exist on inventory and fails. For example, if HS&E has a field on item that needs to crossover to the WPMATERIAL, but you have changed the get list to INVENTORY, it will now fail.

Taking a step back trying to understand the request, the order unit on WPMATERIAL is intentionally left null (and set to null by Maximo if a value exists) when a storeroom is referenced. The assumption is that the stock exists in the storeroom and if not, the inventory reorder will determine what to use for the PR/PO. Order unit can vary based on the vendor utilized to do the reorder where you may buy in boxes of 12 on Amazon but boxes of 36 at Costco. The reason order unit exists in WPMATERIAL is to support the direct issue scenario where storerooms are bypassed and a PR is created for the work order.

Setting values in out of the box fields that are intended to be null and are read-only to prevent users from putting in a value is problematic. You could force it via an automation script, but may break something else in the future. If they want to know what the order unit is in the storeroom, I'd display that on screen via a relationship rather than trying to copy it over. 

Related Content