Does anyone know what the difference is between a “Base Extension” and a “Customization”?
I did a search for the phrase, “Base Extension” in the “Epicor ICE 3.2 Customization User Guide 10.2.200” and within the entire 958 pages of that document, only the following excerpt existed:
The Available Layers section displays all the existing Localizations, Base Extensions, Customizations, and Personalizations for the current program. You select items in this section to work on them. In this example, the NoCounterSalesAlt customization is selected.
This doesn’t really tell me anything about the nature, purpose, or fundamentals of a Base Extension.
Lastly, why would I not be able to delete/remove a base extension that appears to be added in by someone on our team and not part of out-of-the-box functionality (I can delete customizations, but not base extensions - at least in the one case I’m looking at)?
Thank you for taking the time to set me straight on this topic.
There are a number of layers - some are now obsolete but might still be utilized by intrepid CSG coders or Partners. The majority of the layers have a defined load sequence and Parent.
Base Extensions - first layer - This layer was designed to be used by Epicor development but has since been used by CSG and Partners. This is often used by Epicor to make a “tracker” from a data entry form. Parent is the UI itself and Base Extensions are not company specific.
Productization - second layer - This layer was also designed to be used by Epicor development and is now considered obsolete. Remember the good old days of Vantage 8 and Vista? Vista was a slimmed down version of Vantage and it was generally slimmed down by removing and moving controls using the Productization layer. Parent is the UI or the Base Extension. Loads based on the “Product” code (which used to be VN and VS and is now EP) and are not company specific.
Product Extension - third layer - This is another Epicor Development layer - it is to Productization what Base Extensions are to the Base. Used to further refine a Productization definition generally for Trackers. Parent is the UI, Base Extension, or Productization otherwise uses Productization load rules.
Verticalization - fourth layer - This layer was designed to be used by Partners or CSG. Implementation logic is a little odd and this layer is not as useful as it could be. I believe this loads against a Parent layer (not 100% sure) and it loads based on the presence of a Verticalization code in the DB and is not company specific (this is where the logic is a little odd as it really should be company specific).
Localization - fifth layer but with special rules - this layer was designed to be used by the Epicor Country Specific Functionality (CSF) developers. Unlike the previous layers, this layer does not have the concept of a “parent” layer so will load against a UI regardless of the presence or absence of any lower levels. Loads based on the CSF and/or Country Group Code (CGC) assigned to the Company. Original idea was that a Localization “package” could be made up of Localizations specific to a CSF (Finland) and also to a group of Countries (Scandinavia). Load Logic looks for CSF Localization and if not found, looks for the CGC Localization. The CGC code capability has never been used.
Customization - sixth layer - designed to be used by the Epicor Customers. Parent is the layer in play when the Customization is created. Can be company specific.
Personalization - final layer - designed to be used by the individual end users. Parent is the layer in play when the Personalization is created. Company specific.
Maybe this needs a new topic, but could your comment “implementation logic is a little odd” be behind our troubles with a form that has a CSG verticalization? This was provided for us to cover some removed functionality in the transfer from 10.1 to 10.2, and since then we have never been able to get any customization to reliably appear for that particular screen.
Thank you, gentlemen, for the insight. In my case, the Base Extension appears to be what @Rich had described earlier as “used by Epicor to make a ‘tracker’ from a data entry form”, which may explain why I cannot simply delete it outright.
Thanks for the extra details, @hkeric.wci. Looks like my earlier assumption was incorrect. The base extension, in my case, is the “PartDisplay” BE on the Part Maintenance form (shown above in your list of BEs). So, it appears that this is an out-of-the-box configuration on that form (and hence, cannot be removed).
Bill, that’s correct. Part Display is an out-of-box tracker that mimics the look of Part Entry. Whereas Part Tracker has a few more tabs and more information.
We recently upgraded from 10.1.500.10 to 10.2.200.15. We previously used a context menu based on CustCnt.Name that included a menu item for Customer Contact Entry. Now, if that context menu item is selected, the application throws the following message:
Based on what I’ve learned from this thread, I am now concluding that Customer Contact Entry (Erp.UI.App.CustomerEntry.ContactEntryForm, perhaps?) was simply a base extension that was removed by Epicor sometime after 10.1.500.10. Could someone confirm that my conclusion is logical? And if it is, can someone tell me where in release/update documentation this type of change can be found?
