Wednesday, March 30, 2011

CRM

INSTALL BASE ALL MAIN TABLES

Instance
Records the Item Instance Details of an IB instance
Table: CSI_ITEM_INSTANCES
Transaction
Install Base Transaction Log
Table: CSI_TRANSACTIONS
Csi_transactions
Transaction_id
Transaction_type_id
Csi_txn_types
Transaction_type_id
Csi_item_instances_h
Instance_history_id
Instance_id
Transaction_id
Csi_item_instances
Instance_id
Inventory_item_id
Serial_number
Instance_status_id
Location_id
Instance Relationship
Defines the instance to instance relationships
Table: CSI_II_RELATIONSHIPS
Csi_item_instances
Instance_id
Csi_ii_relationships
Relationship_id
Subject_id
Relationship_type_code
Object_id
Csi_ii_relation_types
Relationship_type_code
Csi_ii_relationships_h
Relationship_history_id
Relationship_id
Transaction_Id
Csi_transactions
Transaction_id
Instance Party relationship
Defines the relationship between Instance and party
Table: CSI_II_PARTIES
Instance Party accounts
Defines the Instance to account (party account) association
Table: CSI_IP_ACCOUNTS
Csi_item_instances
Instance_id
Csi_ip_accounts_h
Ip_account_history_id
Ip_account_id
Transaction_id
Csi_ip_accounts
Ip_account_id
Instance_party_id
Party_account_id
Csi_i_parties
Instance_party_id
Relationship_type_code
Instance_id
Party_id
Csi_transactions
Transaction_id
Csi_i_parties_h
Instance_party_history_id
Instance_party_id
Transaction_id
API's


CSI_ITEM_INSTANCE_PUB
Create Item Instance
Update Item Instance
Expire Item Instance
Get Item Instance
Get Item Instance Details
Copy Item Instance
CSI_II_RELATIONSHIPS_PUB
Create Relationship
Update Relationship
Expire Relationship
CSI_SYSTEMS_PUB
Create System
Update System
Expire System
Get System

CRM CONTRACTS TABLES INFO

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

CRM PROFILE VALUES

OKC: View Contracts By Organization
OKS: Contact Center Date Range
OKS: Intangible Subscription Method
OKS: Transfer Party Relationship
OKS: Update Contract with Install Base Quantity
OKS: Warranty Consolidation
OKS: Full Credit for Product Return
OKS: Transfer Status
OKS: Credit Card Display Privileges
OKS: Intangible Subscription Pricing Method
OKS: Minimum Service Duration
OKS: Reprice Warning Message
OKS: Enable Negative Invoicing
OKS: Usage Billing Calculation
OKS: Payment Method for AR Interface
OKS: Default Order Type for Subscriptions
OKS: Category for Order Management Originated Contracts
OKS: Raise Credit Memo for Install Base Transactions
OKS: Notify User of Install Base Integration Notifications
OKS: Vendor Contact Role
OKS: Credit Card Validation Level
OKS: Credit Card Minimum Authorized Amount
OKS: Use Advanced Pricing for Manual Adjustment
OKS: Notify Contract Administrator
OKS: Notify Sales Administrator
OKS: Revenue Type for Sales Credits
OKS: Revenue Type Distribution for Sales Credit
OKS: Default Sales Person for Renewal
OKS: Use Territories to Default Sales Person
OKS: Wallet Path

IB TABLES

CSI_ITEM_INSTANCES

CSI_ITEM_INSTANCES_H

CSI_TRANSATIONS

CSI_TXN_TYPES

CSI_II_REALATIONSSHIPS

CSI_II_RALATION_TYPES

CSI_II_REALATIONSSHIPS_H

CSI_I_PARTIES

CSI_IP_ACCOUNTS

CSI_IP_ACCOUNTS_H

CSI_I_PARTIES_H

CSI_SYSTEMS_B

CSI_INSTANCE_STATUSES


Core Contracts

OKC_K_HEADERS_B

OKC_K_LINES_B

OKC_K_ITEMS

OKC_K_SALES_CREDITS

OKC_ROLES_B

OKC_PARTY_ROLES

OKC_STATUSES_B

OKC_ITEM_PARTYS_B

OKC_CONTACTS

OKC_RULES_B_AS

OKC_K_PARTY_ROLES_B

OKC_PRICE_ADJUSTMENTS

Service Contracts

OKS_K_HEADERS_B

OKS_K_LINES_B

OKS_K_ORDER_DETAILS

OKS_K_SALES_CREDITS

Service Billing

OKS_BILLRATE_SCHEDULES

OKS_BILL_CONT_LINES

OKS_BILL_SUB_LINES

OKS_BILL_SUB_LINES_DTLS

OKS_BILL_TRANSACTIONS

OKS_BILL_TXN_LINES


TCA

HZ_PARTIES

HZ_LOCATIONS

HZ_PARTY_SITES

HZ_PARTY_SITE_USES

HZ_PARTY_RELATIONSHIPS

HZ_CUST_ACCOUNTS

HZ_CUST_ACCOUNT_ROLES

HZ_ROLE_RESPONSIBILITY

HZ_CUST_ACCT_SITES_ALL

HZ_CUST_SITE_USES_ALL

HZ_CONTACT_POINTS

HZ_CUST_CONTACT_PONTS

HZ_ORG_CONTACTS

HZ_ORG_CONTAC_ROLES


0 comments:

About This Blog

  © Blogger templates The Professional Template by Ourblogtemplates.com 2008

Back to TOP