sale Table (13)

Sales For every Sale record edited through the SuperOffice GUI, a copy of the current version of the record will be saved in the SaleHist table. This also applies to editing done through the SaleModel COM interface, but not to editing done through the OLE DB Provider or other channels.

Fields

NameDescriptionTypeNull
sale_idPrimary keyPK
associate_idOwning associateFK associate
group_idxOwner’s group whn sale was createdFK UserGroup
contact_idOptional contact referenceFK contact
person_idOptional person referenceFK person
registeredRegistered dateUtcDateTime
saledate(expected / lost / won) sales dateDateTime
amountTotal sale amountDouble
probability_idxPointer to probability list valueFK Prob
appointment_idFor future useFK appointment
text_idOptional long descriptionFK text
project_idOptional project referenceFK project
earningEarning on saleDouble
earning_percentEarning as percent of totalDouble
userdef_idUser-defined fields referenceFK udsalesmall
userdef2_idUser-defined fields referenceFK udsalelarge
headingSale heading (short description?)String(219)
credited_idWho is to be credited for the saleFK Credited
source_idSource of orderFK Source
reason_idWhy we lost itFK Reason
comptr_idCompetitorFK Comptr
currency_idCurrency of saleFK Currency
probabilityActual probability, may differ from the one in the listUShort
statusStatus: 1 = open, 2 = sold, 3 = lost, 4 = stalledEnum SaleStatus
doneDone (0=don’t know, 1 = No, 2=Yes)Enum SaleDone
number1Alphanumeric user fieldString(49)
visibilityObsolete, but still maintained denormalization of visibleforUShort
sourceFor future integration use; source of recordUShort
registered_associate_idRegistered by whomFK associate
updatedLast updatedUtcDateTime
updated_associate_idLast updated by whomFK associate
updatedCountNumber of updates made to this recordUShort
activeLinksNumber of active links to documents and suchUInt
saleType_idLink to list, sale type (big sale, small sale, no-process sale, …)FK SaleType
postitText_idPaperclip textFK text
reasonStalled_idIf the status is stalled, it should be commented hereFK ReasonStalled
reopenDateDate the sale is to be reopened; valid only for status=stalled. Not necessarily the same as the nextDueDate.DateTime
nextDueDateNext due date, this is a denormalization of ‘closest future activity date, or most recent if no future activities’. Maintained by the system, but very convenient for searching.DateTime
nddAppointment_idID, can be 0, of the appointment that “caused” the nextDueDateFK appointment
reasonSold_idReason why we made the saleFK ReasonSold
saleTypeCat_idCategory of sale type, slaved from saletypeFK SaleTypeCat
activeErpLinksThe number of Erp Sync connections this record is synced with; count of the ErpExternalKey+ErpInternalKey relationsInt
created_by_workflow_idThe workflow this sale was created byFK workflow

sale table relationship diagram

Values for the 'done' field in the sale table

| done | ID | Comment | |---|---|---| | Unknown | 0 | Sale Done/Not done state is unknown | | NotDone |  1 | Sale is not done | | Done | 2 | Sale is done |

Value for the 'status' field in the sale table

| status | ID | Comment | |---|---|---| | Unknown | 0 | Sale status is unknown | | Open | 1 | Sale is open | | Sold | 2 | Sale has been sold (green $ in GUI) | | Lost | 3 | Sale has been lost (red $ in GUI) | | Stalled | 4 | Sale has been stalled, or "parked", awaiting further developments | | SaintAll | 1000 | 'All' choice for Saint. This is NOT an acceptable value for a sale, but is used by the Saint system for indexing all sales |

Indexes

FieldsTypesDescription
sale_idPKClustered, Unique
contact_idFKIndex
person_idFKIndex
saledateDateTimeIndex
project_idFKIndex
userdef_idFKIndex
userdef2_idFKIndex
headingString(219)Index
statusEnumIndex
doneEnumIndex
number1String(49)Index
sourceUShortIndex
associate_id, done, saledateFK, Enum, DateTimeIndex
contact_id, saledate, associate_idFK, DateTime, FKIndex
project_id, saledate, associate_idFK, DateTime, FKIndex
created_by_workflow_idFKIndex

Relationships

TableDescription
appointmentTasks, appointments, followups, phone calls; and documents (document_id != 0). An appointment always has a corresponding record in VisibleFor specifying who may see this.
associateEmployees, resources and other users - except for External persons
chat_sessionThis table contains chat sessions.
ComptrComptr list table. List of all possible competitors (sale).
contactCompanies and Organizations.
CreditedCredited list table. List of who is to be credited for the sale.
CurrencyCurrency list table
email_itemEmail data
personPersons
ProbProb list table. Probability, used in sales .
projectProjects
QuoteQuote root level, at most one per Sale, always connected to one Sale
ReasonReason list table. Why we lost the sale (list)
ReasonSoldWhy was the sale marked as sold (why did we succeed)
ReasonStalledWhy was the sale marked as stalled
SaleHistMirror image of the Sale table, providing a full transaction history. Every time you edit a sale, the current record of the sale is also saved here.
SaleStakeholderStakeholders in the sale, very similar to project members
SaleTypeType of sale - large solution, incremental, whatever fits the organization
SaleTypeCatCategory for sale type
SourceSource list table. Source for sale (list)
textLong text fields from all over the system
ticketThis table contains the tickets (requests) of the system. Its purpose should be evident.
udsalelargeUser-defined fields
udsalesmallUser-defined fields
UserGroupSecondary user groups
VisibleForVisible for rights, who may see this appointment/document, sale, salehist or selection
workflowSuperOffice specific info about a workflow

Replication Flags

  • Area Management controlled table. Contents replicated to satellites and traveller databases.
  • Replicate changes UP from satellites and travellers back to central.
  • Copy to satellite and travel prototypes.
  • Cache table during filtering.

Security Flags

  • Sentry controls access to items in this table using user’s Role and data rights matrix.
  • Visibility controlled via matching VisibleFor row.