Epicor needs to extend classic support to slow thier roll like MSFT does win10 cuz win11.
I mean they broke this:
the close btn on the app used primarily to close rougue apps which been there since win3.1 or forever geesh.
Vibe coding and layoffs for the win!
PRB UPDATE:
Problem has been updated by: Development Notes
Problem PRB0307320 have been updated:
Fixed in Release have been updated to: 2026.1,
Aparently they want it to break production for ALL USA customers since 2025.2.5 rolls out on-cadence Nov 14.
Josh, the dev team is working on making sure that this issue is resolved for the .5 patch release… but they had a question for your specific case. We are wondering if you actually have the USA CSF on your system enabled. The issue is that if you do, you SHOULD be seeing this USA tab on supplier entry. That would not be a bug. Maybe you just noticed it? the screen is required for you to set the 1099 flag and other required fields if you are in the USA.
Hey thanks for the note. I did notice the USA CSF was indeed enabled but the thing is we didn’t enable it to my knowledge.
It’s possible it was always enabled and I didn’t before notice the USA panel, but the required field error seems definately related to the .5 update because we’ve not DMT’d these fields before and we were certainly able to Add/Edit Suppliers before pilot was updated to .5
I would assume my DMT would have failed had they been required.
If it helps, our specific case is a tad cloudly since our timeline is compressed into a single week:
I could research our exact dates and patch levels but all signs seem to point to the fields becoming required beyond our control. Please correct me if wrong or more info is needed.
Plus @cory.davis reported the same in this thread.
PS - FWIW, we are still onboarding so Live is empty. Live also has USA CSF enabled. Our prior refresh from Live to Pilot was in September timeframe. There is a slight possibility that #2 & #3 above were so close that the Supplier error was present but unnoticed in between but we’re thinking that highly unlikely - we’d have to research the timing details futher to know for sure. In other words, USA CSF it was for sure enabled when Supplier DMTs ran. Not for sure whether error started with .5 update, but seems most likely and corroborated by at least one other whos circumstances may be less cloudy than ours.
I’m thinking USA panel has beeen there unoticed since whenever it was recently introduced (says preview on my Live env) but the probkem is this new field (as of 2025.2.5) shouldn’t be enabled let alone required for Suppliers not marked 1099:
Green: Pilot 2025.2.5
Red: Live 2025.1.11
Also still wonder how this issue passed QA.
You are absolutly correct. I am not excusing this, but thought I would add some color to how something like this gets past QA.
BASE CODE goes through our normal QA process testing before and after the code is changed to make sure we didnt miss something.
But then we also have the CSF development team who does additional work that needs to be applied to the base code. This application layer is applied to based on which country the customers are part of. If you are in Germany, you get the German CSF. in USA you get the USA CSF, etc… Back in the olden days, the USA CSF was part of core, but has since be separated because people in germany dont need 1099 functionality…
So… for electronic filing of 1099 there is a type field that must be populated in order to check the type boxes on the 1099 and the CSF team took care of the problem, adding this new SUB Type field. Since it is Required (per IRS Rules) they marked the field as required. I dont have total proof on this, but in the attempt to be transparent here, it would appear that they only tested to make sure that the field was required. They missed testing with the 1099 checkbox = false. YES, there was an error in the fact that it is only required if the 1099 checkbox is true… (This was BUG #1 - being fixed hopefully for the .5 release).
BUT there was a second “bug” in the fact that on a customer who is upgrading from a database with 1099 true, and SubType = blank, the system didn’t allow you to save without populating this field. This is not really a problem when adding new suppliers, because you would find this out as you save.
We are working on making this HARD ERROR changed to a WARNING instead of a hard stop. I have also requsted that the warning message that is displayed be more descriptive of what is needed.
But note that this does not fix the entire problem with your data. If you have a bunch of suppliers with a 1099 true, then you will still need to populate the SubType field, as this is requried by the IRS… if you submit 1099s without this, they may reject them (according to what I read last night). So… while this second “bug” is hopefully being tweaked, you still have work to do with any 1099 suppliers.
At this point, you should also probably create a BAQ Search or QuickSearch or an updatable dashboard to find all 1099=true supplier with blank SubTypes and populate them with a valid subtype.
Thanks for your deatiled reply I really appreciate it.
Don’t make me go read IRS docs 
but shouldn’t there be a default subtype? Or at least some notice going out (a while ago since we’re 8 days out) to all USA epicor customers that they MUST PREPARE TO VISIT EVERY 1099 Supplier in their database upon .5 update?
Thanks again.
nope.. no such thing. you need to set the subtype based on who the supplier is and the type of business is involved. there is no right answer we could generically apply.
‘< Unknown >’ sounds generic enough to me. Let accounting deal with it before yearend while the rest of us conduct operations unaffected.
I suppose as long as you’re warning and not hard stopping every US buyer from editing a 1099 supplier I guess it’s just an unneccessary anoyance and maybe that’s the best we can expect.
Thanks again Mr. Shoemaker for your attention to this matter.
More PRB Updated today. 
Current State: In Progress
2025-11-06 07:21:39 -Development Notes
Development Task TASK7458300 had notes added:
Problem PRB0307320 have been updated:
Fixed in Release have been updated to: 2026.1,
2025-11-06 07:19:00 -Development Notes
Development Task TASK7458300 had notes added:
Problem PRB0307320 have been updated:
PD State have been updated to: In Release Planning
Fixed in Release have been updated to: 12.2.100
2025-11-06 05:11:13 -Development Notes
Development Task TASK7458300 had notes added:
Problem PRB0307320 have been updated:
Fixed in Release have been updated to: 2026.1,
2025-11-06 05:08:06 -Development Notes
Development Task TASK7458300 had notes added:
Problem PRB0307320 have been updated:
PD State have been updated to: In Progress
Fixed in Release have been updated to: 12.2.100
2025-11-06 04:51:09 -Development Notes
Development Task TASK7458300 had notes added:
Problem PRB0307320 have been updated:
Fixed in Release have been updated to: 2026.1,
could be that the PRB is not yet updated… i just received confirmation today that the fix for this will be in the .5 release.
2025.2.5 ?
(post deleted by author)
I get this problem with some suppliers on PILOT (2025.2.5). I see is that some suppliers have a default TIN Type of EIN, which then causes the prompt for a sub-type, whereas other suppliers have a blank TIN Type and those suppliers do not get this error.
The TIN Type is also showing in Classic, so its real data; but since the 1099 flag is unchecked, there is no validation error on the sub-type in Classic.
I assume the default value of the TIN Type is related to some differences in defaults which changed over time when setting up new suppliers?
TIN Type. Values are 1 for EIN, 2 for SSNs, ITINs, and ATINs and 0 if type of TIN is not terminable.
Since TIN Type is an NVARCHAR, setting it to “-blank-” or “0” for non-1099 suppliers using DMT probably would suffice.
EDIT: DMT’ing TIN Type to “-blank-” worked. Using “0” did not; apparently, an “-unknown-” TIN type is still prompting for a TIN sub-type. In any case, DMT cannot resolve the problem when creating a new supplier - it still requires the workaround.
