Client Script Debugged Part 2: Field Not Triggering on Auto-Populate

When building NetSuite Client Scripts, you expect the fieldChanged event to run whenever a field value changes. But here’s the catch — if the field is auto-populated by sourcing, your code might never run.

This is a sneaky issue I ran into while working on a real client project involving invoices. Let’s dive in.

The Real Scenario

I had a requirement:

On an invoice, whenever the Terms field changes, automatically update the Due Date based on the invoice date and payment terms.

It worked fine when a user manually selected a term from the dropdown. But the moment they selected a Customer — which auto-populates the Terms field from the customer record — my script didn’t run.

Why?
Because fieldChanged fires only when the user manually changes a field. Auto-populated values (via sourcing) are ignored.

What Was Happening

• Invoice Date: 05 Aug 2025

• Customer: “ABC Retailers” (default Terms = Net 30)

• Terms field auto-filled with Net 30

• Expected: Due Date should be set to 04 Sep 2025 immediately.

• Actual: Due Date stayed empty until the user touched the Terms field manually.

The Fix – Use postSourcing

NetSuite provides another Client Script event — postSourcing — which triggers after a field is auto-populated via sourcing.

So, I updated my script to listen for the Terms field in both fieldChanged and postSourcing.

/**
 * @NApiVersion 2.x
 * @NScriptType ClientScript
 */
define(['N/search'], function (search) {

    function fieldChanged(context) {
        if (context.fieldId === 'terms') {
            updateDueDate(context.currentRecord);
        }
    }

    function postSourcing(context) {
        if (context.fieldId === 'terms') {
            updateDueDate(context.currentRecord);
        }
    }

    function calculateDueDate(currentRecordObj) {
        var termsId = currentRecordObj.getValue('terms');
        var invoiceDate = currentRecordObj.getValue('trandate');

        if (!termsId || !invoiceDate) return;

        try {

            var daysToAdd = search.lookupFields({
                type: search.Type.TERM,
                id: termsId,
                columns: ['daysuntilnetdue']
            })['daysuntilnetdue'];

            // Some terms may not have 'daysuntilnetdue', handle custom logic here
            if (daysToAdd) {
                var dueDate = new Date(invoiceDate);
                dueDate.setDate(dueDate.getDate() + parseInt(daysToAdd));

                currentRecordObj.setValue({fieldId: 'duedate', value: dueDate});
            } else {
                // Optional: For highly custom terms
                console.log('Custom term detected');
            }

        } catch (e) {
            console.log('Error calculating due date: ' + e.message);
        }
    }

    return {
        fieldChanged: fieldChanged,
        postSourcing: postSourcing
    };

});

Key Points

• fieldChanged → Fires on manual changes

• postSourcing → Fires after NetSuite auto-populates a field value

• Combine both for fields that may be updated by either user action or sourcing

• Always test by both:

  • Manually changing the field

  • Triggering sourcing (e.g., changing Customer to auto-fill Terms)

Final Takeaway

Relying only on fieldChanged can make your script blind to auto-filled values. Using postSourcing ensures your logic runs no matter how the field gets its value — and saves you from those “Why isn’t it running?” headaches.

---

🔍 Client Script Debugged — Real Fixes from the Field

💡 This blog series dives into actual NetSuite client script issues I’ve encountered, how I solved them, and what you can learn from them.

📌 Tip: Bookmark this series to follow along as I share more real-world fixes with problem breakdowns, working code, and developer insights.