Skip to main content

Cross-Validation Rules


A key flexfield can perform automatic cross-validation of segment values according to rules your organization defines when you customize the key flexfield. You can use cross-validation to closely control the creation of new key flexfield combinations, and you can maintain a consistent and logical set of key flexfield combinations that you need to run your organization.
What is Cross-Validation?
Cross-validation (also known as cross-segment validation) controls the combinations of values you can create when you enter values for key flexfields. A cross-validation rule defines whether a value of a particular segment can be combined with specific values of other segments. Cross-validation is different from segment validation, which controls the values you can enter for a particular segment.
You use cross-validation rules to prevent the creation of combinations that should never exist (combinations with values that should not coexist in the same combination). For example, if your organization manufactures both computer equipment and vehicles such as trucks, you might want to prevent the creation of "hybrid" part numbers for objects such as "truck keyboards" or "CPU headlights".

As another example, if you use the Accounting Flexfield, you may decide that all revenue accounts must have a department. Therefore, all your "revenue" account values (such as all values between 4000 and 5999) must have a corresponding department value other than 000 (which means "non-specific").
For example, suppose you have an Accounting Flexfield where you have a Company or Organization segment with two possible values, 01 and 02. You also have a Natural Account segment, with many possible values, but your company policy requires that Company or Organization 01 uses the natural account values 001 to 499 and Company or Organization 02 uses the natural account values 500 to 999. You can create cross-validation rules to ensure that users cannot create a GL account with combinations of values such as 02-342 or 01-750, for example.

Comments

Post a Comment

Popular posts from this blog

Applying Prepayments to Invoices

You can apply the available amount of Item type distributions from a Temporary type prepayment to one or more invoices to offset the amount you pay on the invoice(s). If you entered the prepayment as a Permanent type and want to apply it, you can query the prepayment in the Invoices window and change the Prepayment Type to Temporary. If you use Automatic Offsets then your setting for the Prevent Prepayment Application Across Balancing Segments Payables option controls whether you can apply a prepayment to an invoice or expense report with a different balancing segment. Prerequisites The invoice type is Standard, Mixed, or Expense Report. Today's date is on or after the Settlement Date of the prepayment. The invoice date is on or after the date of the prepayment. The prepayment is type Temporary, fully paid, validated, not cancelled, has no active holds, and has not already been fully applied. The prepayment has the same supplier, invoice currency and payment currenc
1 comment
Read more

Application Utilities Lookups and Application Object Library Lookups

Maintain existing and define additional Lookups for your shared Lookup types. You can define up to 250 Lookups for each Lookup type. Each Lookup has a code and a meaning. For example, Lookup type YES_NO has a code Y with meaning Yes, and a code N with a meaning No. Note: In Releases 11.0 and earlier, there were two Lookup features, Special Lookups and Common Lookups. These two features have been merged into one. The new consolidated Lookups feature has Lookups maintained in this form. If you make changes to a Lookup, users must log out then log back on before your changes take effect. Lookups Block Type Query the type of your Lookup. You can define a maximum of 250 Lookups for a single type. User Name The user name is used by loader programs. Application Query the application associated with your Lookup type. Description If you use windows specialized for a particular Lookup type, the window uses this description in the window title. Access Level The access level restricts changes that
1 comment
Read more

Matching Prepayments to Purchase Orders

You can match a prepayment to a purchase order or receipt. The accounting entries for Item distributions on a matched prepayment typically debit a prepayment account that Payables provides. However, during prepayment entry you can override any account that Payables defaults or builds. Payables does not create an encumbrance entry for the prepaid amount when a prepayment is matched to a purchase order. The match is treated like a reservation of the quantity billed. Payables does not calculate the invoice price variance or exchange rate variance at this point. Furthermore, you cannot change the unit price during the prepayment match to purchase order. A final match to the purchase order is not allowed either. When the matched prepayment is applied to an invoice, Payables reverses the matched quantity on the prepayment to reflect the balance of the total quantity matched. The following example illustrates a prepayment application to a purchase order: You contract to attend a $5,000 trade
Post a Comment
Read more