OKC_ASSENTS
Indicates if an Operation is to be performed for a Subclass of Contract while in a Status
Assent works with Operations (OKC_OPERATIONS_B), Status (OKC_STATUSES_B), and Subclass (OKC_SUBCLASSES_B) to allow flexibility as to what operations can be performed on a different types of Contracts in different statuses.
Subclasses define different types of Contracts (see OKC_SUBCLASSES_B for more information).
Statuses define different states a Contract may be in (see OKC_STATUSES_B for more information).
Operations define different operations a user, or the application may perform on or because of the Contract (see OKC_OPERATIONS_B for more information).
Assent is at the intersection of all three, defining if a specific Operation is allowed or disallowed for a Subclass of Contract while it has a specific Status.
For example, assume that for an implementation we have defined the Status 'Bill Hold'. If the ALLOWED_YN column is set to 'N' for the Operation 'Bill' for the Subclass 'Service' for the Status 'Bill Hold', then billing will not to be performed for 'Service' contracts in the 'Bill Hold' status.
ID Unique identifier for assent defined..
STS_CODE Status for which this assent is defined
OPN_CODE Operation for this assent is defined
STE_CODE Status type for which this assent is defined
SCS_CODE Subclass for which this assent is defined.
OKC_OPERATIONS_B
Set of processes performed by the application to, or as a result of, a contract.
OKC_OPERATIONS defines a set of processes performed by the application to, or as a result of, a contract.
Some operations may be performed on the contract, such as update on line or update via change request. Others are performed as the result of a contract line, such as entitle or bill.
Along with OKC_ASSENTS, this provides information to the application as to what it can do and what it should allow the user to do.
CODE CODE for operations defined at contract header/contract line level.
OPN_TYPE Type of operation (contract or line).
OBJECT_VERSION_NUMBER Sequential number set at 1 on insert and incremented on update. Used by APIs to ensure current record is passed.
OKC_STATUSES_B
User defined values that define a contract's status.
STATUS is a user defined value that defines a contract's status.
Each user-defined status must be in one of six STATUS TYPES, which are seeded values in FND_LOOKUPS. The six status types are:
Entered
Cancelled
Active
Hold
Expired
Terminated
Within each status type, users may define as many statuses as they need. Along with OPERATIONS, SUBCLASS, and ASSENT, status helps drive what the system can or cannot do and what the system allows users to do. For example, it may be allowed to delete a contract in a Cancelled status but not in an Active status.
CODE Status code as defined in FND_LOOKUP_VALUES.
STE_CODE Status Type to which this Status Code belongs to. For example, Status Type "ENTERED'' can have ''ENTERED'', ''SUBMITTED FOR APPROVAL'' as status codes.
DEFAULT_YN Indicates if a status code is the default status code for the given status type.
START_DATE The beginning of the active period, one second after midnight on the date indicated.
END_DATE The end of the active period, one second before midnight on the date indicated.
OKC_PROCESS_DEFS_B
This table stores information of PL/SQL processes or workflows within the application which are used as OUTCOME, CONTRACT PROCESS, QA PROCESS, or FUNCTION in a CONDITION LINE.
This table stores information of PL/SQL processes or workflows registered with the application to be used as OUTCOME, CONTRACT PROCESS, QA PROCESS, or FUNCTION in a CONDITION LINE. Along with OKC_PROCESS_DEF_PARMS, this table provides the information necessary for the application to invoke the process or workflow. The usage of these processes is recorded in OKC_OUTCOMES, OKC_K_PROCESSES, OKC_CONDITION_LINES, and OKC_QA_LIST_PROCESSES.
ID System generated Unique Identifier. Generated from sequence 'OKC_PROCESS_DEFS_S1'. Also the Primary key for the table.
PDF_TYPE Process definition type. Valid values are ALERT, SCRIPT, PPS, WPS.
OBJECT_VERSION_NUMBER Sequential number set at 1 on insert and incremented on update. Used by APIs to ensure current record is passed.
CREATED_BY Standard Who column.
USAGE Usage of Process Definition. Valid values are Approve, Auto Numbering, Approve Change Request, Function, Outcome and Quality Assurance. Refers to LOOKUP_CODE in FND_LOOKUPS where LOOKUP_TYPE= 'OKC_PROCESS_USAGE_TYPES'.
NAME
OKC_QA_CHECK_LISTS_B
Associates a list of quality assurance processes with a specific contract or contract template
Provides a "header" that associates a list of quality assurance processes with a specific contract or contract template.
Because it can take a long time to collect and enter the information about a contract, it is not possible to enforce all data integrity rules or business rules during data entry. The purpose of the QA check list is to assemble a set of routines (defined in OKC_PROCESS_DEFS) that will run against the contract to validate that all such rules have been met. Rules about required data integrity are "hardcoded", and are always run. Others are intended to be supplied by the client as independent routines assembled into the check list.
OKS_BILLING_PROFILES_B
Contains profile information for a customer.
This table holds Billing profile information for a customer. Billing profiles include Information about customer account, customer billing address, invoicing rule, accounting rule, billing level, billing type, billing interval, interface offset and invoiving offset. This table is populated through Billing Profile setup UI. Users can use the billing profile to overwrite any existing line level billing schedule information on the contract authoring form by selecting it in the Cascade Attributes form. Upon renewal, users can also default billing profile information onto the contract by associate a billing profile template to a customer in the Global Contract Defaults form.
OKS_SERV_AVAILS
Stores availability information for a service.
This table stores information about general service availability for service item and populated through the header part of Service Availability setup UI. This table is closely related to the table OKS_SERV_AVAIL_EXCEPTS where the exception of service availability is stored. These two tables are combined together to get the information of available services for service programs, warranties, and extended warranties. Service Availability inclusion and exclusion rules are honored while selling services in upstream applications like quoting, Order Management. When user enters a service item, by default generally available check box if checked for party and product and on saving the default entry, two records are saved in this table meaning service is generally available for party and product. User can specify affectivity of this service availability also by entering values in START_DATE_ACTIVE and END_DATE_ACTIVE columns. If generally available check box is unchecked for party or customer, general_yn flag will be set to 'N' meaning service is not available generally for party or product.
ID Internal Unique Identifier.
OBJECT1_ID1 Item id used for service.
OBJECT1_ID2 Not used.
JTOT_OBJECT1_CODE Foreign key to JTF_OBJECTS_B. JTF Object code identifying the OKX view for service item. Identifies the Source Object (Table/View/Object) that contains the item.
OKS_COV_TYPES_B
Contains the coverage type code and importance of each coverage type.
OKS_COV_TYPES_B is populated by Coverage Types setup form. This table contains the coverage type and importance level definition. E.g., G (Gold), S (Silver) and B (Bronze). The Coverage types defined here are used in the Coverage form.
CODE Unique Identifier code for records in OKS_COV_TYPES_B
IMPORTANCE_LEVEL Importance level associated to the Coverage type. Used by Service Application to prioritize their task or service.
ENABLED_FLAG Flag to indicate that the coverage type record is enabled to be used
START_DATE_ACTIVE Specifies the date when the coverage type is allowed to be used
END_DATE_ACTIVE Specifies the date when the coverage type is no longer effective
No comments:
Post a Comment