About Trades and Assets

Trades are, arguably, the most important information in SalesConnect for most operators, after the connectionsConnections are entities; they're the different types of companies and individuals you may need to track. SalesConnect is set up to display information about the types of connections you care about, based on the roles to which you are assigned. you track. Assets are another critical piece of the puzzle that is understanding total business. Most trades and assets get into SalesConnect by means of a highly validated import operation that's applied to separate asset and transaction feeds. Typically, each time that import operation is completed, trade and asset data is summarized in many different ways. Many different views of trade, asset, and summary data are updated and made available to you in SalesConnect.

How Trades and Assets from Feeds Get Into Your SalesConnect

Proprietary processes are used to manage validating and importing data from transaction and asset feed files into SalesConnect. The figure below shows at a high level what happens as trades or assets from feeds are moved into your SalesConnect.

In UDS SalesConnect
	Authorized operators may be able to use the Feed Repository to upload feed files to your SalesConnect. See Using the Feed Repository for more on using this tool. Your SalesConnect teamA team is a contact connection, though it is really a group of individuals working together to achieve a common sales goal; a team may include reps and rep partnerships from the office with which the team is associated, but it can also office contacts and non-producing reps who support team sales efforts. picks up appropriate uploaded files to load to UDS SalesConnect for initial handling.
	Once the necessary file is in place, a systematic resolution cycle is started, via a SalesPage Express message. The systematic resolution cycle attempts to validate the data in the incoming feed, matching key fields to existing data in UDS SalesConnect. Processing tries to link each incoming trade or asset to the appropriate connections (firms, officesAn office is a connection in the intermediary business hierarchy, an organization subordinate to a broker/dealer firm. Offices are also sometimes referred to as "branches'; institutional firms have branches in SalesConnect. An office is affiliated with a single broker/dealer firm, and may have one or more reps directly affiliated with it. An office may have associated office contacts, as well. Possibly the most critical information you can track for offices are aliases, also known as trading IDs. Aliases are the IDs that associate transactions with each office. If you need to write queries or reports: The primary data for offices is stored in the Office table. Information about office trading IDs is stored in the Office Alias table., repsA rep is perhaps the most important contact connection in the intermediary business hierarchy. Each rep is an individual who sells funds and is affiliated with an office (and through the office, with a broker/dealer firm). Reps may also be referred to as "financial advisors." Possibly the most critical information you can track for reps are aliases, also known as trading IDs. Aliases are the IDs that associate transactions and assets with each rep. If you need to write queries or reports: The primary data for reps is stored in the Contact and Rep Profile tables. The Rep Alias table stores trading IDs associated with reps., partnershipsA partnership is a contact connection in the intermediary business hierarchy, though it is really a name for a group of reps working together to sell one or more products. A partnership, sometimes called a rep partnership, is treated as a special type of rep: this means that most of the tools for working with reps may be used to work with partnerships as well. Most views of transactions associated with an individual rep generally don't include transactions or parts of transactions that the rep may have cleared as part of a partnership. Instead, these kinds of trades are listed only for the rep partnership. Each member's portion of rep partnership sales data is always based on the percentages currently assigned to each member; no long-term historical information about percentages is maintained. SalesConnect does not store any calculated trade or asset values based on rep partnerships. If you need to write queries or reports: The primary data for partnerships is stored in the Contact, Rep Partnership, and Rep Profile tables. The Rep Alias table stores trading IDs associated with partnerships as well as reps.) through their aliases. Processing also tries to match other data on the incoming record to data in UDS SalesConnect based on rules for that type of data. These additional validation checks include transaction and social codes as well as other data that has been identified as important for the types of records involved.
	In addition to validating incoming trade and asset data, systematic processing also writes all of that data to an appropriate archive in UDS SalesConnect. This archive serves as both a record of all received data and a location in which any data that cannot yet be fully validated and transformed can be flagged with specific errors found during validation.
	Any trades or assets that were not flagged for exclusion are tagged for appropriate next steps: If the trades or assets are fully validated—that is, if they passed all validation checks in UDS SalesConnect—they are tagged for copying to the appropriate feed archive in your SalesConnect. Trades or assets that pass all validation checks in UDS SalesConnect still need to be evaluated for other validation checks in your SalesConnect system; some checks can only occur in your system. See the next table, In Your SalesConnect, for next steps. If the trades or assets are not fully validated—that is, if they failed at least one validation check in UDS SalesConnect—they are tagged as needing repair. See the next row for the next step.
	Trades or assets flagged as needing repair are shown in the UDS resolution queue ("errors") pages, which provide tools for reviewing the errors, repairing or adding data to fix those errors, and requesting reprocessing.
	UDS operators work to repair the data conditions or add the data necessary to repair the errors noted on the trades and assets received in the feed file. When they are ready, they can request reprocessing to attempt once again to validate the records that were tagged with errors. Reprocessing is also scheduled to occur at regular intervals, so that repaired records will be rechecked. See Repair aka "Manual Resolution" for more information.
	When a systematic resolution reprocessing cycle is started (via a SalesPage Express message), records in the UDS SalesConnect trades or assets archives are again checked to see if they can be validated. The same validation checks are made that were attempted during processing, but now those checks are run against repaired records in the archive rather than against a temporary storage location for the records in the feed file. Only a single error is shown at a time for any record; repairing one error and reprocessing the record may result in the record failing with another error or passing all validation checks. If the trades or assets are fully UDS-validated—that is, if they passed all validation checks in UDS SalesConnect—they are tagged for copying to the appropriate feed archive in your SalesConnect. See the next table, In Your SalesConnect, for next steps. Some records resolved by UDS may move to your SalesConnect with a specialA special is a kind of variable you may be able to specify as a value to use in a query criterion or in other places in SalesConnect. Some specials are Current Date/Time, End of Day, and Start of Year; these specials all refer to specific dates and/or times, while other specials may return other data. When the query or other item using a special is processed, the special returns the current value that the special represents. status indicating that they are dependent on a client sync from UDS. Such records will be resolved as soon as the client sync can be processed successfully in your SalesConnect. If the trades or assets are not fully validated—that is, if they failed at least one validation check in UDS SalesConnect—they are tagged as needing repair again. See the previous row describing the UDS resolution queue interface.

 

In Your SalesConnect
	Your trade and asset data—already validated against data in UDS SalesConnect to the extent possible—is written to the appropriate archive in your SalesConnect system. This archive serves as both a record of all received data and a location in which any data that cannot yet be fully validated and transformed can be flagged with specific errors.
	A systematic resolution cycle is started, via a SalesPage Express message; this occurs regularly on a scheduled basis, though authorized operators may request reprocessing to initiate this operation, too. The systematic resolution cycle attempts to validate the data in the archive, matching key fields to existing data in your SalesConnect system. Processing tries to link each incoming trade or asset to the appropriate connections (firms, offices, reps, partnerships) through their aliases. UDS may have also passed needed connections/entities and aliases to your SalesConnect system to ensure that the trades or assets can pass these validation checks. Processing also tries to match other data on the archive records to data in your SalesConnect system, based on rules established for that type of data. These additional validation checks may include transaction and social codes as well as other codes and data that has been identified as important for the types of records involved.
	Any trades or assets that were not flagged for exclusion are tagged for appropriate next steps: If the trades or assets are fully validated—that is, if they passed all validation checks in your SalesConnect—they are used to create official trade or asset records in SalesConnect. See the final row in this table for more information. If the trades or assets are not fully validated—that is, if they failed at least one validation check in either UDS SalesConnect or your SalesConnect—they are tagged as needing repair. See the next row for the next step.
	Trades or assets flagged as needing repair are shown in the resolution queue ("errors") pages in your SalesConnect application. These pages provide tools for reviewing the errors, repairing or adding data to fix those errors, and requesting reprocessing.
	Designated operators work to repair the data conditions or add the data necessary to repair the errors noted on the archived trades and assets. When they are ready, they can request reprocessing to attempt once again to validate the records that were tagged with errors. Reprocessing is also scheduled to occur at regular intervals, so that repaired records will be rechecked. See Repair aka "Manual Resolution" for more detailed information.
	When a systematic resolution reprocessing cycle is started (via a SalesPage Express message), records in trades or assets archives are again checked to see if they can be validated. The same validation checks are made that were attempted during the initial pass. As in UDS SalesConnect, only a single error is shown at a time for any record; repairing one error and reprocessing the record may result in the record failing with another error or passing all validation checks. If the trades or assets are fully validated—that is, if they passed all validation checks in your SalesConnect—they are used to create official trade or asset records in SalesConnect. See the next (and final) row in this table for more information. If the trades or assets are not fully validated—that is, if they failed at least one validation check in your SalesConnect system—they are tagged as needing repair again. See the previous row describing your SalesConnect resolution queue interfaces.
	Once archive records pass all validation checks, the now-resolved archive records are copied and transformed by systematic processing or reprocessing to create the appropriate transaction and asset records for the authoritative versions of transaction and asset data in your SalesConnect. All validated trades go to Transaction History, the repository of record for trade data. All current assets go to Current Assets, the repository of record for the latest asset data. In some cases, data may be written to other tables as well. Creation of authoritative transaction and asset records often involves transforming some of the received data to different formats so that SalesConnect can provide a single, consistent data set. Transformations range from making certain numbers positive or negative to providing descriptive values for received codes. Only this authoritative transaction and asset data is used in summarization, reporting, and review tools in SalesConnect; after trades have been added to Transaction History and current assets have been added to Current Assets, other operations update the summary data throughout SalesConnect, so that you always have access to the best possible numbers. Imported and successfully validated data may be made available in outbound feed files that can be downloaded from the Feed Repository and imported into another system. See Using the Feed Repository for steps for downloading (and uploading) files.

Defining Processing Validations and Transformations

Built-in definitions specific to each type of data received (such as transactions or assets) define and order many of the specific default validation checks that are used during systematic processing. For instance, all trades and assets are checked to see if they can be linked to existing connections/entities in SalesConnect. Definitions also detail how to transform validated archive data into authoritative trades and assets in your SalesConnect. While you cannot change these built-in definitions, SalesConnect does include several tools you can use to change some of the specific validations and transformations performed in your SalesConnect system: remap firmA broker/dealer firm (or broker dealer or broker-dealer) is a connection associated with intermediary business, typically a top-level organization in this hierarchy. Broker/dealer firms are also sometimes referred to as just "firms" or "brokers" or "dealers" or "financial institutions." Each broker/dealer firm may have one or more offices affiliated with it, and through these offices, reps may also be affiliated with it. A broker/dealer firm may have associated firm contacts, as well. Possibly the most critical information you can track for broker/dealer firms are aliases, also known as trading IDs. Aliases are the IDs that associate transactions with each broker/dealer firm. If you need to write queries or reports: The primary data for broker/dealer firms is stored in the Firm table. The Firm Alias table stores trading IDs associated with broker/dealer firms. values for firm and office aliases; filter rulesA filter rule defines a data condition to be checked on incoming transactions or assets during systematic resolution; it is used to determine whether matching transactions or assets are marked for exclusion from SalesConnect, marked as pass-through, or marked as no sales (values associated with the records should be disregarded in SalesConnect reporting and summarization). Filter rules may be applied to trading aliases and to a number of other types of data as well, including entries defined in some resolution lists. Resolution rulesets are another way to define rules that affect systematic resolution., transaction account labelsA label is like a tag, a convenient way for you to mark records so that you can easily find and work with them later. Most labels are tagged to key connections. For instance, you could create a label called "Top Reps," and then assign this label to the top-producing reps with which you work. Since you can search for connections with a particular label assigned to them, you can easily retrieve the list of reps who have been assigned this label. However, you can also define transaction account labels that may be systematically applied to the transactions and assets imported to SalesConnect, so that it's easy to find and work with those transactions and assets later., transaction account rules, and transaction definitionsBy default, when transactions are added to SalesConnect, they are assigned a territory for each territory category in use; the territory values are copied from the connection (usually a rep or partnership) associated with the transaction. If there is no associated rep or partnership, the transaction gets its territory value from the associated office. Transaction definitions allow you to further refine a trade's territory assignments during systematic resolution. Transaction definitions are associated with an individual territory category. They determine whether or not a particular trade gets the territory assignment (in that category) of the associated connection, based on additional data in the trade. If you use transaction definitions, you must ensure that they include criteria for all circumstances under which you want a specific territory to be assigned to incoming trades.. These tools let you identify specific trades or assets that you want systematic processing to handle differently during validation or to transform in specific ways when creating final transaction and asset records in SalesConnect.Let's take a closer look at each of these.

Filter Rules

Filter rules are the simplest type of evaluation for incoming transactions and assets that you can define. They are also one of the oldest; while they're still supported, we recommend that, if possible, you use transaction account rules instead, so that it's easier to see most of the rules affecting handling of your transactions and assets in one place.

Filter rules may be set for trading aliases and for a number of other types of data as well, including the entries in most resolution listsA resolution list is a list of valid values for a particular field (property) related to resolving transactions or assets in SalesConnect. That is, a resolution list is a special type of validation list; entries in many resolution lists not only define valid field entries, but also may define filter rules that determine how incoming transactions and assets are handled in SalesConnect.. During systematic resolution, each transaction and/or asset (you can choose to which the rule applies) that has the associated characteristics is essentially flagged for one of these states, the one that you selected for the rule:

• Exclusion from SalesConnect
• Pass-Through, meaning that it need only be matched to the appropriate office or firm, but not to the responsible rep or partnership
• No Sales, meaning that values associated with these records should be disregarded in SalesConnect reporting and summarization.

The figure below shows how these filter rule states affect the handling of a trade; assets to which filter rules apply are handled similarly.

In the past, most simple filter rules were defined as part of managing resolution lists; for many of these lists, you could set individual filter rules for transactions and/or assets on the values defined for the list. Filter rules related to firm, office, and rep aliases were defined as part of managing those aliases in SalesConnect. You can still use these tools to work with filter rules, but since transaction account rules also allow you to define filter rules on all of these criteriaIn a query, a criterion is a single point of comparison. For instance, one criterion in a query might be reps in the state of Michigan. Query and search criteria are based on properties in the primary SalesConnect objects associated with the type of connection or other record which the query or search finds., again, we recommend that you them instead, so that more of your handling rules may be viewed in a single interface. See Transaction Account Rules for more information.

As with labels for connections, you create a list of labels that are meaningful for you. You then choose the records to which those labels will be applied. In the case of transaction account labels, you do this by defining a transaction account rule that applies each label to incoming trades and/or assets , during systematic resolution, when they have specific characteristics. Transaction account labels are defined using the Resolution List Editor, but applied with a transaction account rule. See Maintaining Resolution Lists for general instructions for defining these labels. Read the next section to learn more about transaction account rules.

Transaction Account Rules

Transaction account rules are a powerful option for evaluating the characteristics of transactions or assets during systematic processing, and then changing handling for them or changing the data that will be written for them in the authoritative transactions and assets in SalesConnect. These rules can:

• Use more complex selection criteria than that for simple filter rules but apply the same kinds of exclusions, pass-throughs, and no-sales handling to the selected trades or assets
• Apply transaction account labels to the selected trades or assets
• Change the transaction code and transaction suffix on selected trades or assets
• Change the firm/office/rep trading IDs assigned to selected trades or assets.

See Maintaining Transaction Account Rules for instructions.

Transaction Definitions for Territory Categories

By default, when a trade is added to SalesConnect, it is assigned to a territoryIn a territory category, you can define as many named territories as you need to identify sales responsibilities. Territories are often divided geographically, and can include whole countries, states or provinces, or even ZIP/postal code ranges. Other criteria can be included for each territory, such as firm association or channel/subchannel definitions. If needed, you can filter offices, reps, partnerships, and teams to which a territory will apply by their firm association alone. Each territory can have one or more operators assigned to it; after territory assignments are set, permissions can be set to control the level of access each operator has to data (such as viewing or editing), based on his or her territory assignments. in each territory categoryA territory category represents one set of distinct territories that you need to maintain at the same time. A single territory category may not reflect how your sales force is distributed, so you can define up to fifteen (15) different territory categories in SalesConnect; however, only one version in each territory category can be current at any given time. Categories can represent particular lines of business (such as wirehouses or banks) or product lines (such as mutual funds or annuities), or any other meaningful division for which you need to support distinct sets of territories. Categories include as many named territories as you need to identify sales responsibilities. Named territories are often geographical in nature, but can also include channel/subchannel definitions and firm associations. Applicability also affects office and rep/partnership/team territory assignments: if a territory category is applicable to a firm, then entities associated with that firm can be assigned to territories in that category; but if the category is not applicable to a firm, then associated entities are not assigned to a defined territory in it, but are instead flagged "Not Applicable" for the category. that is applicable for the firm with which it's associated. Usually, a trade's territory assignmentsOnce a set of territories within a particular territory category version has been made current in SalesConnect, those territories will be assigned to appropriate connections (offices, reps, rep partnerships, teams, and even plan sponsors, if appropriate). Territory assignments are based on the criteria in the territory category definitions, on firm applicability, and on whether an entity is locked or not. In SalesConnect, territory locks always override systematic territory assignments. Firm associations can be set at the territory definition level; separately, territory categories can be set to be applicable to particular firms. These settings are very different from each other, but both firm associations and territory category applicability affect territory assignments for entities. are derived from the lowest level connection associated with the trade; that is, if the trade has been associated to an alias for a rep or partnership, the trade is assigned each of the territories currently associated with that rep or partnership. If the trade has been flagged for pass-through (by means of a filter rule, transaction account rule, or as part of manual error repair), the trade is associated with an office but not a rep, so the trade is instead assigned each of the territories currently associated with that office. See Territory Assignments for Transactions to learn more about these assignments.

Transaction definitions allow you to further refine a trade's territory assignments during systematic resolution. Transaction definitions are associated with an individual territory category. They allow you to add additional data checks that determine whether or not a particular trade gets the territory assignment (in that category) of the associated connection.

See Transaction Definitions (part of Territory Assignments) to learn more about how you can use these definitions to change the territory assignments for trades during systematic resolution.

You can also change territory assignments for existing transactions, if necessary. See Changing Territory Assignments for Trades for the most straightforward way of doing this. However, you can also change transactions' territory assignments as part of changing the office and/or rep associated with transactions. See Moving Trades for more information.

Repair aka "Manual Resolution"

Though systematic processing is often able to immediately validate (resolve) incoming transactions and assets, some incoming records cannot be immediately validated. Those records are flagged with errors in the feed archive, and assigned operators need to repair those error conditions. This is often called manual resolution, though technically, operators are really only adding missing data or connecting records to appropriate data already in SalesConnect, and then running those records through systematic processing again (called "reprocessing").

Repairing records may involve adding new transaction codes or similar validation data, when the error indicates that such data could not be found in SalesConnect. See Maintaining Resolution Lists for more about how to add new codes. Many times, the trade firm, trade office, or trade rep (trading IDs) on an incoming trade record cannot be matched to trading IDs for connections in SalesConnect, so repairing those records may also involve adding new firm, office, or rep connections and/or trading IDs as new and necessary records. Sometimes, repairing a record involves determining that the trade firm, trade office, or trade rep data on that record is just wrong, and what's really needed is to match that record to a different set of trading IDs in SalesConnect. See Handling Trade and Asset Archive Errors for more on these tasks and the options that are available.

After resolution operators have added the necessary data to repair or resolve errors, reprocessing runs on records in the archive, to attempt to validate both new and repaired records so that it can be processed into appropriate authoritative repositories in SalesConnect. Reprocessing is a regularly scheduled process, usually overnight after feeds have been received, but assigned operators may also be able to request earlier reprocessing for individual feeds when it's necessary. See Requesting Reprocessing for instructions.

Sometimes a record repaired for one error condition fails reprocessing with a different error. When that happens, those repairing records will need to handle the new error condition appropriately, and then see if another round of reprocessing can successfully resolve the record into SalesConnect.

Trade and Asset Summarization

SalesConnect provides several ways for you to see summary data for trades and assets, so that you can focus on the numbers that are most important to you and the work you need to do. Here are some of the places that summary data may often be found:

• Your dashboardThe dashboard is the first page you see when you log into SalesConnect. It provides an overview of summary information related to trades and assets.
• Several tabs on detail pages for firms, offices, reps, partnerships and teams: Profile, Funds, Business Review, and Sales Summary
• The Sales by Fund page; see Track sales by fund for more information.
• The Wholesalers page; see Track sales by wholesaler for more information.
• QueriesA query is a special type of saved search for connections or other data in SalesConnect, created with a SalesConnect query tool rather than a standard search page. When you create a query, you select query criteria based on familiar field names from the interface; the criteria you specify are transformed behind the scenes into the appropriate SQL statements. and reports based on summary objectsIn object-oriented programming, an object is a software bundle of related attributes (properties) and behavior (methods). Software objects are often used to model the real-world objects that you find in everyday life. Often, you can think of an object as roughly equivalent to a table in a database, though the object has additional logic attached to it. For example, one type of "object" in the real world and in a SalesConnect application is a person, known in SalesConnect as a contact or connection. Each contact has many properties, such as a name and birth date; in SalesConnect, these are properties of the object Contact. In the real world, each contact also has many behaviors; in software such as SalesConnect, you are typically interested only in recording or managing certain types of behavior for Contact instances. Objects in SalesConnect are logically named entities mapped to Java classes: objects are the instantiations of classes. So, the class for the Contact object includes methods for setting and retrieving key properties for Contact entities, such as the contact's name. An object may call its own methods, or it may call another object's methods that are visible to it. In SalesConnect, the properties for objects defined for an application project are most typically mapped to specific database table columns..

How is all of that summary data provided? Some of it is calculated on the fly, based on data primarily in Transaction History and/or Current Assets, but most of it comes from stored summaries in SalesConnect. Why use stored summaries? They provide data to you more quickly and with less system impact than summaries built on demand. Constant, on-the-fly calculations consume server resources in a way that accessing stored summary data doesn't. So, a number of summarization tasks are typically run after scheduled processing, so that numbers in these stored summaries can be updated with information about the latest trades and assets.