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're 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 about 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's best to have some method of assigning statuses, particularly to new transaction instances. If you don't actively assign a status to a new transaction instance, the system automatically assigns one. Specifically, the system assigns the first status that was created.
There's only one exception to the rule that every transaction must have a status. If instances of a transaction were created before statuses were set up, they have an undefined status. They keep this undefined status unless someone edits and saves the transaction. At that 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's 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.
Note that you can hide the Status field but not the status label. Choose status names carefully, as they'll be visible to all users with permission to view transaction instances.