Modern UI – Field from Secondary Customization Project Not Rendering After Extended Field (AR101000, 25R2)

Hi ​@srinivasaraokota90 
Try removing the exceeding qp-fieldset with the modify property from Project-SRK200. Since you only need to attach the field, you just need to:

<template>
   <field name="UsrSRKTestField" after="#SRK100_BaseFields [name='UsrSRKTestCard']"></field>     
</template>

<template>
   <field name="UsrSRKTestField" after="#SRK100_BaseFields [name='UsrSRKTestCard']"></field>     
</template>

​@aleksandrsechin Thank for your time and suggestions.
I tried this approach earlier, but it was not working.
Again I tried but getting below error, while publishing package with above code.

ts-loader: Using ts-patch/compiler@5.5.2. This version may or may not be compatible with ts-loader.
[21:37:31.379]: [36mIn HTML extension 'D:\AcumaticaERP\25R2_MUI\FrontendSources\screen\src\customizationScreens\Company\screens\AR\AR101000\extensions\AR101000_SRK200Base.html' for screen 'AR101000' child node 'FIELD' has AFTER attribute with '#SRK100_BaseFields [name='UsrSRKTestCard']', but screen HTML doesn't contain any elements that satisfies such querySelector

How are your TS files named? Files referencing other files must come alphabetically after the referenced file in order for the referenced file to be compiled first (and therefore contain the referenced fields).

I have tested the approach where I try to refer to items defined in the 1st extension from the 2nd extension. It seems that during the build process, it only searches in the core files, not in custom files. This means there is no way to directly customize custom items — or it requires some special approach that I was not able to find in the documentation.

This is definitely not the case. Acumatica itself uses extensions extensively (sorry 😏) as part of the ‘core’ product (ie CR303000/extensions/CR303000_General.html]) but you will receive build errors if the files are not named appropriately, as I mentioned above.

I agree that Acumatica uses extensions extensively.  The issue though is in a customization project that attempts to extend an update from another customization project.  There is no visibility to the 1st custom extension.

I tried doing this with an extension of a a core file in Acumatica’s base install.  The 1st extension works.  Then I tried to extend my own (first) custom extension which then causes error messages at build.  For simplicity sake, let’s assume the files/classes are AR101000, AR101000_Brian01, and AR101000_Brian02.  If AR101000_Brian02 needs to extend something in AR101000_Brian01, it cannot see Brian01 at compile time.

I can work around the issue by making independent extensions that create their own containers at render, but that means adding settings from multiple packages into AR101000 result in a lot of containers instead of making 1 custom fieldset on the screen and adding all the fields of various packages to the one defined fieldset in the base customization.  This only works if I am extending an existing screen in the base install.  I can’t do this if my screen itself is custom because, again, it doesn’t exist yet as it doesn’t seem to be combining all the .html and .ts files of all customization packages into a single folder before attempting to build.

Thinking that surely the Modern UI editor inside Customization Project Editor would be smart enough to handle it, I tried to handle my extension from there.  It ended up importing from my published tenant path (...FrontendSources\screen\src\customizationScreens\TestCompany\screens\...) which is deleted during publish and would not exist.  Interestingly enough, this is the error that is thrown.

[2025-11-26 02:34:50.831] Compiling frontend in D:\Acumatica ERP\DEV-25R2\Site\FrontendSources\screen
[2025-11-26 02:36:52.739] System.IO.IOException: The directory is not empty.

   at System.IO.Directory.DeleteHelper(String fullPath, String userPath, Boolean recursive, Boolean throwOnTopLevelDirectoryNotFound, WIN32_FIND_DATA& data)
   at System.IO.Directory.Delete(String fullPath, String userPath, Boolean recursive, Boolean checkHost)
   at Customization.FrontendCompiler.RemoveNewUIFiles(ICustomizationLogger logger, String physicalSitePath)
   at Customization.FrontendCompiler.Compile(String tenantId, String[] screens)
   at Customization.CstWebsiteStorage.PublishWebsiteFiles(CstDocument doc, PXPublishOptions opt, ICustomizationLogger logger)
   at Customization.CstWebsiteStorage.UpdateCustomization(CstDocCollection merged, String login, ICustomizationLogger logger, PXPublishOptions options)
   at PX.Web.Customization.Controls.Publish.DoPublish(Int32 hashCode, HttpResponse response)

[2025-11-26 02:36:52.739] An error has occurred. Please report this error to the technical support and attach the information provided above.

I have a ticket open with Acumatica asking how we are supposed to be able to layer customization projects for this scenario, but no answer yet.  I can do additional testing if you see what I’m missing.

Here’s a proof-of-concept:

NOTE: I realized during write-up that this is not actually an example which extends the TypeScript of the first package by the second. I’m not sure if it proves what I was saying or not.

Customization 1 (adds ‘Active Services’ field):

TypeScript (screens/CR/CR303000/extensions/CR303000_Details.ts):

import { CR303000, BAccountHeader } from "src/screens/CR/CR303000/CR303000";
import { LocationInfo } from "../../common/tabs/tab-details/tab-details";

import {
	PXFieldState,
    PXFieldOptions,
	createSingle,
	viewInfo,
} from "client-controls";

export interface CR303000_Details extends CR303000 { }
export class CR303000_Details {
    @viewInfo({ containerName: "Details" })
    DefaultLocation = createSingle(LocationInfo);

}

HTML (screens/CR/CR303000/extensions/CR303000_Details.html):

<template>
    <field name="DefaultLocation.XServices" after="#fsHeader_A [name='Status']"></field>
</template>

Customization 2 (adds ‘Text Op-in’ field):

HTML (screens/CR/CR303000/extensions/CR303000_Details_Test.html):

<template>
    <field name="DefaultLocation.XTextOptIn" after="#fsHeader_A [name='DefaultLocation.XServices']"></field>
</template>

Both customizations published:

Here’s a proof-of-concept:

NOTE: I realized during write-up that this is not actually an example which extends the TypeScript of the first package by the second. I’m not sure if it proves what I was saying or not.

Customization 1 (adds ‘Active Services’ field):

TypeScript (screens/CR/CR303000/extensions/CR303000_Details.ts):

import { CR303000, BAccountHeader } from "src/screens/CR/CR303000/CR303000";
import { LocationInfo } from "../../common/tabs/tab-details/tab-details";

import {
	PXFieldState,
    PXFieldOptions,
	createSingle,
	viewInfo,
} from "client-controls";

export interface CR303000_Details extends CR303000 { }
export class CR303000_Details {
    @viewInfo({ containerName: "Details" })
    DefaultLocation = createSingle(LocationInfo);

}

HTML (screens/CR/CR303000/extensions/CR303000_Details.html):

<template>
    <field name="DefaultLocation.XServices" after="#fsHeader_A [name='Status']"></field>
</template>

 

Customization 2 (adds ‘Text Op-in’ field):

HTML (screens/CR/CR303000/extensions/CR303000_Details_Test.html):

<template>
    <field name="DefaultLocation.XTextOptIn" after="#fsHeader_A [name='DefaultLocation.XServices']"></field>
</template>

 

Both customizations published:

 

Where did you define XTextOptIn in a .ts file to make it accessible by the .html?

It’s in the view defined by the first package.

Since 2023, I have been defining every field I want to expose in the DAC to the html via a class in a .ts file.  Are you telling me that isn’t necessary?

No, not at all. Simply that the TS file is defined in the first package. I didn’t include it, but it’s just a normal TS file. I realized after I had spent a bunch of time formatting the example that the second package doesn’t extend the first’s TS file. It just uses a field from it.

I apparently don’t have any examples at the moment of accomplishing this exact thing, although I find it VERY hard to believe it’s not possible.

Ok.  So every field I want to use in any package built on the first customization needs the class of the .ts file to include the file whether it exists or not (i.e. 2nd customization may or may not be published) instead of including the new fields of the 2nd customization within THAT package - I think.  That makes my brain hurt!  But I can try that. It goes against everything in me to define a field that isn’t part of a customization.  In webforms, defining the field that doesn’t exist results in SQL errors, but I believe typescript is more forgiving… but also a major shift in thinking.

I can’t test that out right now, but I’ll try to test it later this afternoon and let you know how it goes.

I don’t know. I think you should be able to extend the class from the first TS in the second TS and use it. But like I said, I guess I haven’t actually accomplished that.