IBY_VALIDATION_SETS_B_

IBY_VALIDATION_SETS stores links to payment validations. These validations must be performed before submitting transactions to a payment system. Validations may be required for many reasons, including bank account restrictions or the countries, currencies, or payment systems involved in a transaction. Payment validations are currently implemented in code, rather than in meta data. Thus, each validation in this table should be accompanied by a pointer to the code in which the validation is implemented. Validations can be further defined by specifying the entity with which they are associated. This determines when the validation should take place. Payment method validations are done immediately when a calling application submits a payment process request to Oracle Payments, and in some cases earlier as well. Other validations are done later, after Oracle Payments assigns the appropriate entities, such as payment format, to the payment. This division is done in the IBY_VAL_ASSIGNMENTS table.

Details

• Schema: FUSION

• Object owner: IBY

• Object type: TABLE

• Tablespace: REFERENCE

Primary Key

Name	Columns
IBY_VALIDATION_SETS_B_PK_	LAST_UPDATE_DATE, LAST_UPDATED_BY, VALIDATION_SET_CODE

Columns

Name	Datatype	Length	Precision	Not-null	Comments
VALIDATION_SET_CODE	VARCHAR2	30		Yes	User-entered primary key.
VALIDATION_LEVEL_CODE	VARCHAR2	30			Level at which this validation should apply. Values, from the IBY_VALIDATION_LEVELS lookup, include DOCUMENT, PAYMENT, and INSTRUCTION
VALIDATION_CODE_PACKAGE	VARCHAR2	255			Package where the validation is defined; in PL/SQL this corresponds to a package name, in Java a class name
VALIDATION_CODE_ENTRY_POINT	VARCHAR2	255			Entry point of the code that implements the validation set. For example, this could be in the form of a PL/SQL package and procedure, or a Java class and method.
VALIDATION_CODE_LANGUAGE	VARCHAR2	30			Language of the code that implements the validation set. Possible values are PLSQL and JAVA.
CREATED_BY	VARCHAR2	64			Who column: indicates the user who created the row.
CREATION_DATE	TIMESTAMP				Who column: indicates the date and time of the creation of the row.
LAST_UPDATED_BY	VARCHAR2	64		Yes	Who column: indicates the user who last updated the row.
LAST_UPDATE_DATE	TIMESTAMP			Yes	Who column: indicates the date and time of the last update of the row.
LAST_UPDATE_LOGIN	VARCHAR2	32			Who column: indicates the session login associated to the user who last updated the row.
OBJECT_VERSION_NUMBER	NUMBER		9		Used to implement optimistic locking. This number is incremented every time that the row is updated. The number is compared at the start and end of a transaction to detect whether another session has updated the row since it was queried.
PAYMENT_FLOW	VARCHAR2	30			Specifies funds capture or disbursement flow. Values taken from lookup: IBY_PAYMENT_FLOW
SEED_DATA_SOURCE	VARCHAR2	512			Source of seed data record. A value of 'BULK_SEED_DATA_SCRIPT' indicates that record was bulk loaded. Otherwise, specifies the name of the seed data file.
AUDIT_ACTION_TYPE_	VARCHAR2	10			Action Type - have values like INSERT, UPDATE and DELETE.
AUDIT_CHANGE_BIT_MAP_	VARCHAR2	1000			Used to store a bit map of 1s and 0s for each column in the table.
AUDIT_IMPERSONATOR_	VARCHAR2	64			Original Impersonator User.

Indexes

Index	Uniqueness	Tablespace	Columns
IBY_VALIDATION_SETS_BN1_	Non Unique	Default	VALIDATION_SET_CODE, LAST_UPDATE_DATE
IBY_VALIDATION_SETS_B_VSCID_U_	Unique	Default	LAST_UPDATE_DATE, LAST_UPDATED_BY, VALIDATION_SET_CODE