Custom Transaction Type Statuses Overview
As described in Statuses for a Custom Transaction Type, there are many advantages to creating statuses. However, before you create statuses, you should review the following:
When Statuses Exist, All Instances Must Have a Status
When you create statuses for a transaction type, you also create a requirement that every instance of the transaction type have a status.
Because every transaction instance must have a status, you may want to consider how statuses should be assigned to transaction instances, both at the time they are created and at other key points. You have the following choices:
-
You can expose the Status field on the transaction instance form. With this approach, a user entering or editing the transaction in the UI can manually assign a status to the instance. For more details on this choice, see Displaying or Hiding the Status Field for a Custom Transaction Type.
-
You can create a workflow or SuiteScript that sets the status. For details, see Referencing Custom Transaction Type Status in a Workflow.
You can also use a combination of these approaches. However, be aware that it is preferable to have some method of assigning statuses, particularly to new transaction instances. If you do not actively assign a status to a new transaction instance, the system automatically assigns a status. Specifically, the system assigns the first status that was created.
There is only one exception to the rule that every transaction must have a status. If instances of the transaction were entered before the statuses were created, these instances have an undefined status. They retain their undefined status unless they are opened for editing and a user saves changes. At this point, a status is assigned.
When Statuses Exist, the Posting Body Field is Ignored
The Statuses subtab includes a Posting box, situated above the Statuses sublist. This box indicates whether instances of the transaction post – but only if no statuses exist for the transaction type.
If statuses are defined for the transaction type, the system ignores the Posting box. In this case, for each transaction, the system uses the Posting value associated with the appropriate status. These values are shown in the Posting column.
There is only one exception to this rule. If a transaction was entered before the statuses were created, in general, the posting status depends on the value of the body field. However, if the transaction is opened or edited following the creation of the statuses and then saved, a status is assigned to the transaction. After that, the system uses the Posting value associated with the status.
Statuses Are User-Facing, Even When the Status Field is Hidden
Users can see the status of a transaction instance by referring to a label displayed in the upper left corner of the page. This label is displayed both when the transaction instance is in edit mode and in view mode.
Although you can hide the Status field, you cannot hide the status label. For this reason, the status names you choose should be appropriate for viewing by anyone with permission to view the transaction instances.