Acumatica Vendor Management — Field-Level Extensions

Vendor management extensions mirror customer management ones structurally — same shared BAccount base, same "which level does this field belong at" question — but the customizations that actually get requested skew toward compliance and risk tracking rather than pricing, since that's where vendor-side pain usually shows up.

Core DACs and screens

Vendor extends BAccount, maintained on the Vendors screen (AP303000) through VendorMaint, with VendorClass providing class-level defaults (terms, 1099 settings, GL accounts). Vendor-linked purchase and payment history lives on POOrder and APInvoice/APPayment respectively, which is where most vendor scorecard or compliance customizations pull their data from.

Extension points

Field-level extensions — a custom compliance certification date, an insurance expiration tracked on the vendor record, a risk category — are standard PXCacheExtension<Vendor> work. As with customers, decide deliberately whether a new field belongs at the Vendor level or the shared BAccount level, particularly for anything that might also be relevant when the same business account is also a customer.

A realistic scenario: compliance expiration gate

A common vendor management customization: block releasing a PO to a vendor whose required insurance certificate or compliance document has expired, unless an authorized user overrides it with a documented reason.

public class VendorMaint_ComplianceExt : PXCacheExtension<Vendor>
{
    [PXDBDate]
    [PXUIField(DisplayName = "Insurance Expiration")]
    public DateTime? InsuranceExpirationDate { get; set; }
    public abstract class insuranceExpirationDate : PX.Data.BQL.BqlDateTime.Field<insuranceExpirationDate> { }
}

public class POOrderEntry_ComplianceGate_Extension : PXGraphExtension<POOrderEntry>
{
    public PXAction<POOrder> release;

    [PXOverride]
    public void Release(List<POOrder> list, Action<List<POOrder>> baseMethod)
    {
        POOrder order = Base.Document.Current;
        Vendor vendor = PXSelect<Vendor,
            Where<Vendor.bAccountID, Equal<Required<Vendor.bAccountID>>>>
            .Select(Base, order?.VendorID).RowCast<Vendor>().FirstOrDefault();

        var ext = PXCache<Vendor>.GetExtension<VendorMaint_ComplianceExt>(vendor);
        if (ext?.InsuranceExpirationDate < DateTime.Today && !HasOverrideAuthorization())
        {
            throw new PXSetPropertyException("This vendor's insurance certificate has expired. A compliance override is required to release this PO.", PXErrorLevel.Error);
        }

        baseMethod(list);
    }
}

Requiring explicit override authorization rather than just a warning keeps the control meaningful — a warning that buyers learn to click through within a week provides no actual compliance protection, while a hard stop with a logged override at least creates an auditable exception trail.

Vendor scoring and shared data with PO

Vendor scorecard logic (covered in more depth in the PO extension patterns post) reads historical PO and receipt data — when building vendor-level compliance or scoring fields, coordinate with whatever PO-side scorecard logic already exists so the two don't compute overlapping or contradictory risk signals from the same underlying data.

Testing considerations

Test the override flow explicitly, including who is authorized to grant it and whether that authorization is itself logged — compliance customizations are frequently audited later, and "we added a hard stop" is a weaker answer than "we added a hard stop with a logged, restricted override" when someone asks how an expired-certificate vendor still got a PO released.

Wrapping up

Vendor management customizations are structurally similar to customer ones but oriented around compliance and risk rather than credit and pricing. Turn compliance dates into enforced validation rather than passive fields, and make any override path auditable from the start rather than retrofitting logging after an audit asks for it.