Old Notes to Update
Status Level ID (SLID)¶
Comprised of 3 components using floating numeric field type of 3 decimal places.
|99||Starting level 10-99|
|999||Mid level 100-999|
|9999||Base level 1000-9999|
Status Level Attributes¶
|00||Any||Any user has access.|
|01||Group||Only group member have access.|
|02||User||After owner complete change to group.|
|00||Ready||Record becomes part of normal system.|
|01||Progress||In progress becoming ready.|
|02||New||After saving change to incomplete/complete.|
|00||Write||Changes can be made.|
|01||Readonly||No changes can be made.|
|02||Write Once||After saving change to readonly.|
|01||Temporary||After 30 days change to hidden or purge.|
|02||Hidden/Purge||After 90 days purge.|
This scenario assumes 1000 is a sales lead that turns into a 1100 which is a client. The stages show the work flow from loading a new lead to archiving the client that is no longer being served.
The format is SLID-SA where SA represents all (3) Status Attributes together as one number.
- New leads imported (slid=20) from a file to be checked before made available for assignment to sales team.
- Permissions (sla_own=1,sla_ready=1) is owner (not available to sales
team until verified import successful.
- If import batch has errors, delete and reimport.
- If records are ready change (sla_read=0) use button option that automatically updates imported batch to new leads ready (slid=100,sla_ready=1,sla_own=0,sla_life=0). The leads are temporary and any leads that are not updated within 60 days will automatically revert back to unassigned (slid=100).
- Sales team manager assigns leads (slid=1000,sla_own=1) to people on the sales team. Each lead can only be seen or updated by the sales person or administrator. The sla_ready remains 1 because it is a new lead to the sales person.
- The sales person updates the lead (sla_ready=0). The temporary status (sla_lif) of the lead is changed to permanent (sla_life=null).
- Multiple follow-ups are made until the lead is ready (sla_readyy=null) for an appointment (slid=1070).
Recording changed to history is critical to any system. The method used is understood by the following examples.
Lead to Client¶
The lead (1000) becomes a client when the sale (1090) is made. When the slid changes from 1000 to 1090, an unconfirmed (10901) record is created in history containing additional information from the file. Upon confirmation the all information is correct, the unconfirmed (10901) record becomes confirmed (109011) and the history data cannot be changed.
While the record remains in the 1090 status, any referencing of the record will cause the system to look for the (109011,10901) and return the first match. If 109011 is returned, the record is readonly unless the status changes. If 10901 is returned, the record can be updated and confirmed.
If the status changes while the history record is unconfirmed, the unconfirmed record remains in history and a new history record is created, also unconfirmed.
Unconfirmed history records are just previously entered information. The most recent changes while in that status. The are not counted as history in reports and are not visible on embedded tables.
Confirmed history records all have 11 following the status code.
- Status Menu
- Simple way to change status without buttons or questions.
- Limited to allowable status codes based on current status and/or user rights.
- Usually set in a Mode screen with related fields to the status.
- Change of Status (onchange event)
- By changing the status and reloading the form, the system attempts to link that status to history.
- History records use the same status code followed by 1’s. A
status code 1000 may have:
- 10001 (unconfirmed, updating information)
- 100011 (confirmed, used as current information)
- 1000111 (archived information)
- The sytem always pulls the lowest number first when on a mode form for that status code. Other forms will only link to 100011 records. Archive records will only apear in embedded history tables.
Status Level Activity Timeline (SLAT)¶
The status codes in an SLAT table are:
|99991||resume||User must complete record|
|9999||history||Last record reflects current status|
New records are added using the ~~newrecord=unbound switch parameter.
$this->form2 = $this->createForm($this->form2q, $keys, [ 'slat' => [ 'bind' => $this->form1->key, 'dbk' => 'key', 'resume' => true, 'history' => true ], 'insert' => [ 'dbt' => $key->dbt, 'map' => [ 'acct2' => branch()->pro->swacct, 'entry' => ['NOW'], 'updated' => ['NOW'], 'expires' => ['NOW', 30], 'initials' => user_initials(), 'reg_id' => vnix::$user->id ], ], ]);
The keys to bind the activity timeline to.
The field name in history that links to the bind form key
The field that if it changes should trigger a new history record. Default is the main form slid (dbs).
resume = true¶
If exists, open the SLID1 record.
Do not create a new record if exists or does not exist.
resume = false¶
Do no load previous SLID1 record if exists.
history = true¶
Load history if it exists. Does not affect creating records.
history = false¶
Do not load history records. Does not affect creating records.