We are testing Kinetic 2025.2.5 and I get an error when running the MRP

It’s in the log file for the scheduler. Anyone know where I can start to look ? It seems like the ‘a.m.’ at the end is the problem because it should probably be AM but I don’t know where to find that value in the database?

15:54:19 System.FormatException: The string ‘2025-06-05 12:00:00 a.m.’ was not recognized as a valid DateTime. There is an unknown word starting at index ‘20’.
at System.DateTimeParse.Parse(ReadOnlySpan1 s, DateTimeFormatInfo dtfi, DateTimeStyles styles) at System.Convert.ToDateTime(String value) at Erp.Internal.MR.MRPLib.GetJobQueue(Int64 pTaskNum, String pName, String pProcessor, Int32 pNum, String pMsg, String& pJobNum, String& pPlant, String& pPartNum, String& pType, Int32& pPriFactor, Nullable1& pReqDate, Int32& pReqTime, Int32& pLevel, Boolean& pMethod, Decimal& pSeq, Boolean& pSchedDir, Boolean& pFirm, Boolean& pReNum, Boolean& pSched, String& pStatus, Int32& pSubLLC) in C:_releases\ERP\ERP12.1.100.0\Source\Server\Internal\MR\MRPLib\MRPLib.cs:line 1747
at Erp.Internal.MR.MrpExpSched.main_block(Int64 instance_TaskNum, Boolean netchg, String IP_plantList, Nullable1 cutoff_date, Boolean from_autopur, String logfile, Int32 loglevel, Int32 logtype, Boolean finiteLoad, Boolean ignoreConst, Boolean allowHistDate, Boolean usePrepTime, Boolean useKitTime, Boolean runPegging, Boolean runConPur, Nullable1 Sched_startDate, String ShipViaDefault, String compBuyerID, Int32 ForeDaysB, Int32 ForeDaysA, String v_defaultSchedCode, String extComp, String PlantSelected, String plantprefixlist, String pReqType, Int32 processNum, String purDir, Boolean whatif, String procSource, Decimal GSStartTime, Boolean delaySched, Boolean recyclejobs, Boolean rcSchedGetDetails, Boolean includePCParts, Boolean useQuoteBOM, Boolean multiJob, Boolean multiJobIgnoreLocks, Boolean multiJobMinimizeWIP, Boolean useLotExpiration) in C:_releases\ERP\ERP12.1.100.0\Source\Server\Internal\MR\MrpExpSched\MrpExpSched.cs:line 3027
at Erp.Internal.MR.MrpExpSched.RunMrpExpSched(Int64 instance_TaskNum, Boolean netchg, String IP_plantList, Nullable1 cutoff_date, Boolean from_autopur, String logfile, Int32 loglevel, Int32 logtype, Boolean finiteLoad, Boolean ignoreConst, Boolean allowHistDate, Boolean usePrepTime, Boolean useKitTime, Boolean runPegging, Boolean runConPur, Nullable1 Sched_startDate, String ShipViaDefault, String compBuyerID, Int32 ForeDaysB, Int32 ForeDaysA, String v_defaultSchedCode, String extComp, String PlantSelected, String plantprefixlist, String pReqType, Int32 processNum, String purDir, Boolean whatif, String procSource, Decimal GSStartTime, Boolean delaySched, Boolean recyclejobs, Boolean rcSchedGetDetails, Boolean includePCParts, Boolean useQuoteBOM, Boolean multiJob, Boolean multiJobIgnoreLocks, Boolean multiJobMinimizeWIP, Boolean useLotExpiration) in C:_releases\ERP\ERP12.1.100.0\Source\Server\Internal\MR\MrpExpSched\MrpExpSched.cs:line 1058
at Erp.Internal.MR.MrpExpSched.RunSubProcess(List`1 Parameters) in C:_releases\ERP\ERP12.1.100.0\Source\Server\Internal\MR\MrpExpSched\MrpExpSched.cs:line 788

1 Like

Here’s a screenshot from a task in our agent…try changing to uppercase AM with no dots and saving the task.

1 Like

The process is not running on a schedule for the test that I’m doing. I’m using the Schedule = ‘Now’ like this:

OK, so not running on scheduler…just a realtime run (with recurring not checked) and then clicking the gear icon to submit. Seems odd. I don’t think we fill in a cutoff date on ours but you might want to try one.

I’ll try this

Right now, I’m testing the User Account field for ‘Format Culture’. It’s English (Canada) for me and that’s what makes the a.m. or p.m. at the end. If I set it to English (United States), I see AM or PM

I’ll log both and see if I see the error on both run. Will get back here with the results

You may be on to something there - if it was run under user A and culture English/CA, then run the next time under user B and culture English/US…maybe that’s why it’s getting wonky while trying to update the Last Run value.

BTW, there’s a third option under each user…“invariant”…no idea how that works.
image

I didn’t know about that option but I’ll look into it. Ultimately, we have a generic account run those big processes so if there is a way to not break anything with updates, it would be way better

Last run name shows user ID of TASK. Try setting your profile to match what’s set up on TASK and rerun. And if that run does work, we found a heck of a glitch…essentially not able to run MRP (and heaven knows what else) under a multilingual scenario.

The Last Run is because it’s the date we copied the Production database to our Testing environment ! That account also has English (Canada)

I just finished my 3 tests (Well 2 are finished but the other one I see what I needed to see)

1st Row: English (United States)
2nd Row: Invariant Language
3rd Row: English (Canada)

Both row 2 and 3 are stuck at the job scheduling and it takes hours until I have to force the row to be cancelled via the database

The 1st row, however, finished the scheduling subprocess and is now processing the parts. Not sure if someone else can do a test but it seems like the MRP job scheduling is not working in other format culture following the update (2025.2.5)

So it’s working now? If so, that’s good to hear…

I sent my message too fast by error but just edit the answer. I guess I have a workaround but definitely problematic in my opinion if things like format culture creates errors down the line

Would love to know if it happens to other people !

Yeah, having to play with the format culture just to get MRP to run is…problematic to say the least. I don’t think that’s the only spot where the Last Run thing comes into play either. If I remember correctly, COS/WIP Capture also tracks the Last Run user/date…so there may be others.

1 Like