1. Using Advanced Controls
  2. Best Practices for Transaction Model Development

Best Practices for Transaction Model Development

You may shorten the time required for model analysis by following best practices.

  • Consider making your first filter one that creates the smallest data set for subsequent filters to analyze. For example, your first filter might apply a relative value on a date attribute to select only the most recent month's worth of data.

  • Apply simple filters early in your model logic. For example, a model may analyze records of invoices, but include a simple filter that limits analysis to a specific set, such as those that haven't been canceled (Canceled Date attribute of the Payables Invoice business object is blank). Or it may establish thresholds (for example, an amount greater than a fixed value) or select transactions of a specific type.

  • The attribute for a simple filter may be available both in a delivered object and a user-defined object. If so, create two filters for your model, one for each object. For example, suppose you're creating a model, and it includes a filter that states "Payables Invoice.Amount is greater than 100." Suppose also that you created a user-defined object, called Specialty Invoice. It's developed from a data-set control based on the Payables Invoice object, and it includes the Amount attribute. You should include a second filter, "Specialty Invoice.Amount is greater than 100," in your model.

  • Function filters, or filters that apply a Related to condition to user-defined objects, are best applied after simple filters.

  • You may create more than one filter that uses an Equals condition to arrange records into groups. If the filters call the same business object, place them one after the other (if your model logic permits).

  • A filter may use a Similar (or Similar to) condition to establish groups of similar records. You can include more than one of these filters in a model. However, place them after other filters (if your model logic permits).

  • The language you select as you log on to Oracle Cloud becomes the "source language" for transaction models you create. For some business objects, attribute values are translated into multiple languages. So that models return appropriate results, make sure model filters that use translated objects search for attribute values in your source language. Or, whenever possible, use ID attributes in model filters, rather than corresponding name attributes.

    For example, the Business Operating Unit object is translated into multiple languages. A user working in Spanish creates a model with a filter that searches for unit names that contain "norte." Later, a user working in English copies the model as the basis of a new one. Unless that user changes "norte" to "north," the filter returns no results. As an alternative, the creator of either model could have searched for organization-ID values, which are the same in any language, rather than name values.

    To identify the source languages of the models you can access, select View > Columns in the Models page, and select the Source Language column.

  • Use a step process to develop models. Add a filter, save the model, and run it to confirm that results are as you expect. Then add another filter and test again. Continue until your model is fully developed. This greatly simplifies troubleshooting should the model return unexpected results.

  • Use a known data set to develop models. In addition to using the step process when designing models, consider restricting your data set by first adding a simple filter that selects a small set of known test data. For example, use conditions such as Equals, Contains, or Matches any of against attributes like invoice number, supplier name, or person name. This approach helps facilitate model-logic design and evaluate required filters.

  • Most patterns return graphical as well as tabular results. These patterns are for use only in models. Don't use them in a model that you intend to deploy as a control. There are two exceptions: The Normalize and Lexical Tokenization patterns don't produce graphs and so are appropriate for use in models that are to be deployed as controls.