Skip to main content

 Hello,

 

We are having an issue with request creation and bill to place ID’s.  When creating a new Request, we select a product that has a aproduct.place_id] “Located at” place ID and a different iproduct.place_id_owned_by]“Owned by” place id. 

 

After the product is selected the system copies the tplace.place_id] “Located at” place ID into both the erequest.place_id]”Place ID” and then the place_xref ‘Place Bill to’ to the request.place_ID_to_bill] “Bill to Place”

 

This relationship appears to be driven by the FSM Metadata for ‘Request’ in its Default Def.  

 

Is there a way to change the base line mapping to pull from product?

What is the recommended solution?

 

Thanks,

Dan

 

 

 

Product Selection
Request Result
Product Record
FSM Default mapping
place information

 

You can create a custom Metadata for REQUEST Table. Then according to your requirement, create the Relation Map record and the Default Def record. In Custom Metadata, you can provide whatever the Primary Table, Related Table, Primary Column Name, Related Column Name and build the relationship as you wish. In the Default Def, you have to provide the DB Table and the Column, that you need to access the value. This Custom Metadata will override the FSM metadata and will satisfy your requirement.

Randika,

 

Thank you for the response, that sounds like a great solution.  We were unsure if the custom Metadata being in direct conflict with the primary Metadata would cause an issue.  Is it safe to assume that custom metadata will over ride the base line relationships as a rule of thumb?

 

 

Hi @MKNDANIEL,

You may create a custom metadata for request table defining all the table column relationships. I have attached a different example, but hope it may help you to get an idea about metadata defining according to your requirement.

 

If you create custom metadata, it will override FSM metadata. Hope this helps. Thank you.

Kind Regards,

Kalpani

Normally custom metadata will override the base line relationships. But it’s better you try this in DEV environment first. Additionally, I have provided here some information regarding the Custom Metadata.

You can also specify your own metadata to override certain properties of supplied metadata, new field labels and descriptions, or completely new screens that can replace screens that we supply.

There are two categories of metadata that you cannot override:

  • You cannot change the column type.
  • If a column value is required, you cannot make it optional.

About Table Relationships -> Metadata defines the relationship between a table and any child tables. For example, the request_unit table is defined by us as a child of the request table, using the request ID as the key column that links the two tables together.

You can create your own relationships as well, specifying the tables and the key columns that link the two together.

At times you want to display information that is not directly related to a table. In that circumstance, you can use an intermediary table to link all three together.

IFS Field Service Management (FSM) uses metadata to describe tables and the columns on those tables. FSM has complete metadata but sometimes you need to override the supplied metadata. Other times you need to define your own metadata for user‐defined fields or for extension tables.

FSM metadata can be viewed on the FSM Metadata screen and you can create your own metadata on the Custom Metadata screen. You can override many metadata values on FSM, for example restricting a 128‐character column to 12 characters, but some metadata you cannot override. Following is a list of circumstances where your ability to override FSM metadata is restricted.

  • In database—some FSM fields do not appear in the database. You cannot override this value.
  • Is key—you cannot change the key values of FSM tables.
  • Is required—you can change a column to required, but you cannot change a required column to optional.
  • Is read‐only—you can change a column to read‐only but you cannot change a read‐only column to editable.
  • Maximum number of characters—you can reduce the maximum number of characters in a column, but you cannot increase it
  • Maximum number of decimals—you can specify the number of decimals, but you cannot specify more than ten.
  • Maximum value—you can decrease the maximum value allowed in a column, but you cannot increase it.
  • Minimum value—you can increase the minimum value allowed in a column, but you cannot decrease it.
  • The only restrictions on user‐defined fields are the basic types of numeric and date and time. Within these limits, you can define any metadata you want.
  • Metadata also defines relationships between tables on FSM.

Hi @MKNDANIEL,

In addition to Randika’s explanation, you can refer this attached document which is a part of FSM reference guide to get more information about custom metadata and set up. Hope this helps. Thank you.

 

Kind Regards,

Kalpani

Terms & ConditionsCookie settings