durette,

I not sure why not, but what I would try is to check what happens if the shop order is updated. Be it only to set a value and reset it to the original value. Maybe that would trigger the creation of shop_order_cft.

Steve

There is a similar thread, but from a different point of view related to this. 

https://community.ifs.com/technology-all-about-the-nuts-and-bolts-that-make-it-work-50/custom-fields-and-standard-fields-in-the-same-event-2036?postid=7865#post7865

Debug shows that the cft doesn’t get created initially on the record until something is entered in the first custom field for that view, so maybe that is why when the order is created as pegged there is no way to pick up the custom field default.

BEGIN 
&AO.SHOP_ORD_CFP.Cf_Modify__(:p0 , :p1 , :p2 , :p3 , :p4 ); 
EXCEPTION 
WHEN &AO.Error_SYS.Err_Security_Checkpoint THEN 
raise; 
WHEN OTHERS THEN 
rollback; 
raise; 
END;

I suppose that a second update will be necessary to force in a value and the out of box pegged order creation isn’t setup to handle it.

For what it’s worth, if you create a shop order from the application, the application calls CF_NEW__ with action 'PREPARE' to pre-populate the values before the user even starts typing.

True, but if you carry the Shop Order all the way to saved and planned and don’t put anything into those fields, the cft record doesn’t get created.  I didn’t see it created until I actually entered a value, but I didn’t try changing the default on the custom field either.  Probably another case of multiple ways IFS does the same thing and not consistent between them.

In our DEV environment, I found that setting a non-null default value forces it to create a CFT record when you save in the GUI, but that still doesn’t work when the shop order comes from a released customer order.

Better to check the debug console and see what calls are done, and script the code with the same sequence. If it still doesn’t work (can’t think of a reason why), a sure way of getting it done is by triggering a background job using a custom event that updates the field in the background.

The issue described is a limitation of the customisation functionality. 

Whenever an item is system generated IFS doesn't consider any custom fields. If we think about how IFS processes items in the background they are essentially API calls to the specific function responsible for creating the item.  However, the application front end has an added layer of logic and several API calls can be made as typically seen in the debug console. 

You may be able to trigger an event to populate the said field.

It’s unfortunate that SHOP_ORD_CFP.CF_NEW__ accepts an OBJID instead of an OBJKEY. It has to read SHOP_ORD_TAB to convert that OBJID into an OBJKEY, which means you get a trigger mutation error if you want this to fire on a new record of SHOP_ORD_TAB. If it had accepted an OBJKEY, I could just pass &NEW.ROWKEY and create the CFT record with no trouble at all.

I considered an INSERT on the CFT, but I didn’t want to leave myself in a situation where new fields aren’t defaulted according to the configuration. It’s better to let the application regenerate the CFP whenever a field definition changes.

Every time I encounter this situation, I create yet another background job to update the record in the background. I was hoping there was a better way. It sounds like there isn’t.

A technique I’ve observed is to trigger on the ‘history’ table, rather than use a background job, and perform the update. Look for the ‘Shop order created’ History Log Action Text (Logical Unit: ShopOrderHistory) to get your ShopOrd value and insert the CFT row?