Everest: Freight/Shipping Line (e.g., “SH”) Missing on Invoice When Converting Sales Order → Sales Invoice

Solution

1) Confirm the shipped-quantity conversion preference

Navigate to:

File → Setup → Preferences → Flow Control → All → Miscellaneous → Others → Others 1

Locate the checkbox:

“Set the quantity shipped value to zero when converting the sales order to sales invoice (force you to enter the quantity shipped)”

2) Understand the two possible behaviors (and why “SH” may be missing)

• If the checkbox is checked (force shipped qty = 0):
  • Everest forces Shipped Qty = 0 on all lines during conversion.
  • Shipped quantities must be entered manually.
  • Non-inventory freight lines (e.g., “SH”) may have no supported way to pre-populate shipped qty, so they remain at 0 and are not invoiced.
• If the checkbox is unchecked:
  • Everest populates shipped qty using Committed quantity (if any is committed), otherwise it can use Ordered quantity when nothing is committed.
  • This can allow freight/non-inventory lines to carry over (because they often have an ordered quantity).
  • Risk: uncommitted inventoried items may be invoiced (billing items that have not shipped), unless you commit inventory first.

3) Validate your scenario (committed vs uncommitted lines, backorders)

This behavior commonly appears during backorder invoicing and scenarios where:

• Some inventoried items are committed while others are uncommitted.
• The shipped-qty-to-zero preference is enabled (freight/non-inventory lines stay at shipped qty = 0 and do not invoice).
• The shipped-qty-to-zero preference is disabled (uncommitted inventoried lines may invoice using ordered qty).

Important: Engineering has indicated this is expected behavior driven by configuration/data differences (not a software defect), so aligning settings and processes across environments is key.

Diagnose Environment Differences (Production vs Test)

If Production and Test behave differently even on the same Everest version (for example, 8.0.26.890), compare configuration and data between environments.

1) Compare the division flag in the database (DIVISION.INVDEFQTYZ)

Run the following in both environments:

SELECT INVDEFQTYZ FROM DIVISION;

Notes from investigation:

• 'T' and 'F' represent different default shipped-quantity behaviors during conversion.
• A mismatch between environments can explain why freight carries over in one environment but not the other.
• Example environment difference observed: Production = 'T', Test = 'F'.

2) Compare add-ins

Collect and compare the add-in lists in both environments:

Utility → Add-in Manager

Differences in installed/enabled add-ins can contribute to differences in behavior during conversion.

3) Compare stock area / location configuration (if applicable)

Run in both environments (use your real department codes/filters as needed):

SELECT DEP_CODE, AREA_SI_T, OTHER_STKAREA
FROM DEPART;
/* Add an appropriate WHERE clause for the department(s) you are testing */

Workarounds / Mitigations

No single customer-validated fix was confirmed in the documented investigation. The following mitigations were discussed to address the two main risks (missing freight vs invoicing unshipped goods):

• Make the freight item inventory-type (non-stock / non-priced) instead of non-inventory
  • This allows the freight line to participate more consistently in commit/shipped quantity handling so it can be invoiced when shipped quantities are applied.
• Process control: commit all shippable inventory lines before conversion
  • If the shipped-qty-to-zero preference is unchecked, committing inventory reduces the risk of invoicing uncommitted lines.
• SDK-based automation (advanced): toggle DIVISION.INVDEFQTYZ during conversion and explicitly set shipped quantities
  • Approach discussed: temporarily toggle DIVISION.INVDEFQTYZ during conversion, explicitly set shipped qty values (including freight), then revert the flag.
  • This is typically used when you need predictable, automated shipped-qty behavior for both inventory and non-inventory lines.