How Parties Relate to Each Other

Divisions, organizations, and accounts are instances of the Organization party type.
A division, internal or partner, is also an organization if its internal organization flag is TRUE (INT_ORG_FLG = "Y") and it has an associated S_BU record.
Every division is associated with one organization: either itself or the closest ancestor division that is also an organization.
Every position is associated with a division. The position is then also automatically associated with one organization: the organization with which the division is associated.
Persons (contacts), users, employees, partner users are instances of the Person party type.
Typically, you associate each employee and partner user with one or more positions. The employee or partner user has only one active position at one time. The employee or partner user is automatically associated with one division and one organization at a time—the division and organization associated with the active position.

CAUTION: Merging employee records is not recommended. You can disrupt party relationships to a significant extent and get unexpected results.
For purposes of granting visibility to data, associations of parties of type Person with other types of parties are stored using the S_PARTY_PER table. For example, accounts are associated with contacts, users are associated with positions, and so on. A user associated with a position can see data for accounts or opportunities assigned to the position (when this is the active position). Relationships stored in S_PARTY_REL also affect data routing for mobile users.
For purposes of storing ad hoc, informational relationships between parties, such associations are stored using the S_PARTY_REL table. For example, a company and its accounting firm might both be stored as accounts. Assuming that your application provides the capability to define this relationship, it can be stored in the S_PARTY_REL table.

Comments

Darren Demers said…
Every position is associated with a division. The position is then also automatically associated with one organization: the organization with which the division is associated.
stitching unit , ladies tailor , custom tailor , tailor near me , tailor shop , Online Tailor Shop , tailoring company
5 November 2019 at 08:09
Post a Comment

Popular posts from this blog

Creating SearchSpecs in Siebel

Not too sure if you ever faced it, but at one time I found it really difficult to build siebel searchspecs. I had to copy already built searchspecs and manipulate it to cater to my needs.. :). However recently I figured out it's not that difficult to build these specs. In general if you are not using a process property (in a workflow) or a function (like LookupValue) searchspec is pretty straight forward. The below is an example. '[Status]='"In Progress"' (In progress within double quotes and the whole statement within single quotes, the vice versa is also okay, but make sure you use one particular quotes within the statement) If you need two fields in the searchspec and it will look like below: '[Status]="In Progress" and [Type]="Administrative"' and so on and so forth. Simple right. Now comes the little difficult part, when you have a process property or a function, e.g. '[Status]="In Progress" and [Type]="...
Read more

To make the MVG Field/Applet Read only based on the particular field value in the Parent BC

Example, Account is the Parent BC and CUT Address is the Child BC. If the Account Status field is “Inactive”, the Address MVG Field should become read-only. Configuration: In Parent BC, Create a calculated field as follows Field Name: CalAddrReadOnly Value: IIF([Status]="Inactive", "Y", "N") In Child BC - User Properties, create one record with the following values: Name: Parent Read Only Field Value: Account. CalAddrReadOnly *from TIP of the Day by Anil S Kumar, IBM
Read more

Siebel 8.1 weird WF validation error

We got the below error message while validating a workflow in Siebel 8.1 Validation failed for the workflow process 'XYZ' for the branch 'Connector 33' The 'WF Branch Criteria Value' - field such as LO_.. or HI_.. for the respective data type is null or empty. Solution: Run the sql below with the source as workflow row id, you will see all the branch conditions in your workflow. Pick the one which has the same name as the error message, isolate the wf step (you can modify this sql to get that) and then delete and re-add the condition step. SELECT WFBRANCRIT . ROW_ID , WFBRANCRIT . NAME , WFBRANCRIT . BRANCH_ID FROM SIEBEL . S_WFR_PROC WF , SIEBEL . S_WFR_STP WFSTEP , SIEBEL . S_WFR_STP_BRNCH WFSTPBRANCH , SIEBEL . S_WFR_PROC_FLOW WFSTEPCON , SIEBEL . S_WFR_COND_CRIT WFBRANCRIT WHERE WF . ROW_ID = WFSTEP . PROCESS_ID (+) AND WFSTEP . ROW_ID = WFSTPBRANCH . STEP_ID (+) AND WFSTPBRANCH . ROW_ID = WFSTEPCON . FOR_BRNCH_ID (+) AND WFSTPBRANCH...
Read more