How to show code description for customized scalar field from SOShipmentCarrierData?

Hello and thank you for the quick response.
This solution does get me pointed in the right direction. A PXStringList is what I need, though hard-coding the values doesn’t feel like the best solution. I would prefer if the values were sourced from SOShipmentCarrierData.externalStatus, so that any changes in future updates would be included; This list doesn’t even cover all current possible values, excluding ‘X’. Is there a way to populate the string lists from the definition of the original value that the Scalar is reflecting?

My pleasure, yeah the AI tool is great but not perfect.  The more specific we are with it, the better it gets.  Try this and let me know if it gets you closer to what you are looking for:

That’s a great follow-up — and you are absolutely right to want to avoid hard-coding values in [PXStringList]. Here’s the full answer, based strictly on Acumatica’s documented customization practices:

✅ Objective:

Display friendly labels for values in a [PXDBScalar] field that pulls externalStatus (e.g., 'C', 'S', 'N', 'X') without hardcoding those values in a [PXStringList].

🚫 Limitation:

Acumatica does not support dynamically populating [PXStringList] from another table at runtime.

As of current framework limitations (including in 2024 R2), [PXStringList] requires compile-time, hard-coded definitions.

✅ What You Can Do (Documented Workarounds)

🔹 Option 1: Use a PXStringList with Constants Class (Best Practice)

This is the recommended Acumatica pattern, seen in native DACs like ARInvoice, SOOrder, etc.:

public static class CarrierStatuses

{

    public class completed : PX.Data.BQL.BqlString.Constant<completed> { public completed() : base("C") { } }

    public class workbench : PX.Data.BQL.BqlString.Constant<workbench> { public workbench() : base("S") { } }

    public class notSubmitted : PX.Data.BQL.BqlString.Constant<notSubmitted> { public notSubmitted() : base("N") { } }

    public class error : PX.Data.BQL.BqlString.Constant<error> { public error() : base("X") { } }

    public const string Completed = "C";

    public const string Workbench = "S";

    public const string NotSubmitted = "N";

    public const string Error = "X";

}

Then apply:

[PXString(1)]

[PXDBScalar(typeof(SearchFor<SOShipmentCarrierData.externalStatus>.

    In<SelectFrom<SOShipmentCarrierData>.

    Where<SOShipmentCarrierData.shipmentNbr.IsEqual<SOShipment.shipmentNbr>>>))]

[PXStringList(

    new[] {

        CarrierStatuses.Completed,

        CarrierStatuses.Workbench,

        CarrierStatuses.NotSubmitted,

        CarrierStatuses.Error

    },

    new[] {

        "Completed",

        "Workbench Processing",

        "Not Submitted",

        "Error"

    })]

[PXUIField(DisplayName = "Pacejet Status", Enabled = false)]

public virtual string UsrCarrierStatus { get; set; }

✅ This pattern is documented and follows Acumatica’s best practices for:

• Type safety
• Localizability
• Consistency with other native enum-like values

🔹 Option 2: Use a Selector (Advanced & Dynamic)

If you want true dynamic value resolution from SOShipmentCarrierData definitions:

1. Create a custom table or view that holds:
   • StatusCode (e.g., 'C', 'S')
   • Description (e.g., 'Completed', etc.)
2. Use [PXSelector] on the scalar field:

[PXSelector(

    typeof(Search<CarrierStatusLookup.statusCode>),

    typeof(CarrierStatusLookup.description),

    SubstituteKey = typeof(CarrierStatusLookup.description),

    DescriptionField = typeof(CarrierStatusLookup.description)

)]

This requires you to populate that lookup table either manually or via import scenario — it’s more work but gives true flexibility.

🔹 Option 3: Create a UI-only Bound Field for Display

If the scalar field must remain raw ('C', 'S', etc.), you can create a UI-only unbound field to display the description:

[PXString]

[PXUIField(DisplayName = "Status Description", Enabled = false)]

public virtual string UsrCarrierStatusDesc

{

    get

    {

        switch (UsrCarrierStatus)

        {

            case "C": return "Completed";

            case "S": return "Workbench Processing";

            case "N": return "Not Submitted";

            case "X": return "Error";

            default: return "Unknown";

        }

    }

}

This field can be used purely for display, while keeping the original scalar untouched.

🧠 ERP Pro Tips

💡 Tip for Localizability: [PXStringList] with constants allows future localization via the translation dictionary.

💡 Tip for Extensibility: If Pacejet or external integrations add more status codes, you can safely extend the constants and string list without needing to rebuild the whole framework.

✅ Final Recommendation

What’s the DAC definition of the field you’re pulling?  If it is a PXStringList itself, then you can check it’s definition to see if the list is coded into the attribute or if the list is a separate object. If the latter is the case, then you can use the same definition in your field attributes.

See, that’s the thing ​@Django, I can’t find any access to the definition of this DAC. I know that I’m new to these deeper levels of customizing, so I might just not know the proper place to look. The DAC Schema browser for PX.ExernalCarriersHelper.SOShipmentCarrierData doesn’t have the Source Code link, investigating the field on the Shipments tab and doing Actions > View Data Class Source yields nothing as well. After upgrading to 24r2 (24r1 specifically) PaceJet integration became part of Acumatica instead of being a customization, so it isn’t there either.

There isn’t a large issue with writing out these values for now, so perhaps this is something I will be able to solve with more experience and make airtight in the future.

Ah - that can be a challenge.

If you’re working in Visual Studio, it might be able to bust that open using reflection/decompiling to help.

Otherwise I might suggest that you hard code it for now and maybe send a support request to see if support can send you the DAC setup for that field or the whole DAC. The second AI offering above is close. When they’re done right your

[PXStringList(...)]

turns into 

[CarrierStatuses.List]

and then you’re future proofed.