Available only on particular types of Data objects: Currency, Numeric and Percent. May be True or False; but defaults to False. The ‘suppress line if zero’ property in the Bill Designer is an important part of good bill format design. This property has been enhanced since Juris version 2.1 to provide you with more flexibility than in previous versions.
What is the ‘Suppress Line if Zero’ [SLZ] Function?
When a field in a Bill’s Design is set to ‘suppress line if zero,’ then that field [and every field on the same row as that SLZ field] will be suppressed when the prebill or final bill are printed. The fields in the row and the height of that row will be suppressed; When the bill prints, it will be as if that row never existed. This function comes in handy when a bill’s design may include a value that might not be applicable to all clients or matters, like Discount Applied, Prepaid Remaining Balance, etc.
What is the difference in the SLZ Function in Juris 2.05 and earlier to Juris 2.1?
The SLZ functionality was very rudimentary in Juris versions 2.05 and earlier. In those versions of Juris, a row’s height was fixed and could not be changed by the user. When SLZ was used, the system knew to suppress any field that had the same top position as the SLZ field. The standard row was suppressed as well.
Juris 2.1 has been enhanced to allow for much more flexible and dynamic suppression field and row control as determined by the user at design time. The new functionality offers greater design flexibility, and this flexibility necessitates that certain considerations be taken into account in the format design.
How does the SLZ Function work in Juris 2.1?
In Juris 2.1 a suppression row is not limited to only those controls whose top position matched the SLZ control; rather, the suppression row is now defined as any control that intersects with the SLZ control. The net affect of this enhancement is that you can now suppress multiple rows with one SLZ control. Please see the examples below to better illustrate this point.
Is there an easy way to identify the 'suppression row'?
Yes. The control fields that are set to cause suppression will be identified with a red flag.
When one of these fields is selected, the fields to be included in that suppression row will be identified by a series of gray, diagonal lines.
Example 1: In the example below, the fields A, B, C & D are all separate fields (i.e., the fields do not overlap, nor do the field borders touch each other.) The suppression field (SLZ) intersects only the B field. The fields in gray are the fields that will be suppressed, and the dotted line shows the row height that has been determined to be suppressed when the SLZ field = 0. The results for this example are desirable. The Fields that are being suppressed are the correct fields, and the row height determined to be suppressed causes the fields below the SLZ row to be moved to the correct location with respect to the fields above the SLZ row.
Example 2: In the following example, the fields A, B, C & D are all separate fields and the SLZ field intersects both the B & C fields. The fields in gray are the fields that will be suppressed, and the dotted line shows the row height that has been determined to be suppressed when the SLZ field = 0. Notice that due to the fact that fields B & C both intersect with the SLZ field they will both be suppressed along with the SLZ field when SLZ=0. Also, the system determined that field D is the first field below SLZ when calculating row height, which is correct.
Example 3: This example is more complicated than the previous examples, but it is meant to illustrate a potential pitfall that may occur with the SLZ function. As you can see, the SLZ field intersects with the fields D & F; and the row height is determined by beginning at the top of field D and ending just above the top of field G. However, the field B is located in a precarious position. It does not intersect with the SLZ field, so it will not be suppressed, but the B field does overlap the row height area that is set to be suppressed.
The results for the above example are not desirable. Juris 2.1 offers the flexibility of overlapping rows, and it is perfectly acceptable to design a format with overlapping rows and fields. However, that functionality does not perform harmoniously in conjunction with the ‘suppress line if zero’ function. When the SLZ function is used, overlapping fields and rows should be avoided in that area. Below are several options of how to redesign the Example 3 to promote improved functionality. OPTIONAL SOLUTIONS: Option 1, Option 2 and Option 3 below.
Option 1
Option 2
Option 3
These are only a few of the possible options for functional design. In all of these options, in order to restore functionality, row overlapping was removed. The only exception was in Option 3c. Row overlap was allowed with field B and field F because neither field B nor field F had any row overlap with any field that was not being suppressed by the same SLZ control.
More Suppress Line if Zero Examples
The following examples illustrate when and how a user might use the SLZ function in a real format design. In this section we will cover:
- Using multiple SLZ fields
- Using hidden SLZ fields
- Using one SLZ field to suppress multiple rows
Balance forward information is the ideal area to describe the potential for dynamic design control using the ‘suppress line if zero’ function. Many firms would like to include balance forward and payment information on a bill, but only when that information is applicable for that bill. The following scenarios describe in detail how the ideas of using multiple suppression fields, using hidden suppression fields, and using one suppression field to suppress multiple rows can all be used most efficiently.
DESIGN 1
Example: The example below represents the design of the Balance Forward section of a bill format. The field in gray has the SLZ property set equal to true; so when the gray field is equal to zero, then all fields intersecting that field will be suppressed. The gray Balance Forward field has a dotted line instead of a solid line, indicating that this is a hidden field (Visible=False) that will not print regardless of the value of the field.
POTENTIAL OUTPUT
Example: When the bill has a BalanceForward of zero, then all four rows will be suppressed. The example below illustrates the printed output when the bill has a balance forward with adjustments and payments applied:
In the case where there is a balance forward only, with no payments or adjustments, this output will be generated:
This example illustrates that the client has an outstanding balance from the previous bill; and alerts the client that no payments have been received up to the current bill date. If a full payment had been received, the output may look like this:
DESIGN 2
Example: Some firms may not want to see the balance forward section when the Balance Forward is equal to zero OR when Net Balance Forward value is equal to zero.
In that case, an additional, hidden SLZ field would need to be added as shown in the bill design example shown in Design 3.
Design 3
Example: Assume that the firm also wishes for the adjustments line to be suppressed when zero in the example shown in Design 2. The large suppression fields will have to be replaced with multiple, single-row suppression fields. This will prevent an overlap which was discussed in earlier. The example below shows how to use multiple suppression fields suppressing individual lines.
Potential Output
Example: The Net Balance Forward (NBF) and Balance Forward (BF) fields were made to one row high, then that field was copied to each row that might need to be suppressed. The Adjustments Applied field was also set to Suppress when zero. This means that when there are no adjustments.
OR
Balance forward from last bill $950.00
Payments applied since last bill -800.00
Net balance forward $150.00
SPECIAL CONSIDERATION, PAYMENTS APPLIED FIELD
In each of the scenarios described in this section, the Payments Applied field has not been used as a SLZ field. Why not? As always, it is a matter of preference. It may be better to NOT suppress the Payments Applied field when it is equal to zero. Example A does not set Payments Applied to suppress when zero and Example B does.
Example A
Example B
Without a field to add or subtract from the Balance Forward row, the total Net Balance Forward row makes less sense. Compare Example A to Example B. Example B looks more logical when printed, and also has the added benefit of showing the client that no payments have been received since the last bill.