Only through official Epicor tools, of course. There may have been a few situations where I’ve had all my monitors covered in BAQ screens to make sure all the PCID tables, transactions, and PartBin match up correctly.
2 Likes
This should be fun…
Program Ice.Services.Lib.RunTask when executing task 287668 raised an unexpected exception with the following message: RunTask:
System.Data.Entity.Core.EntityCommandExecutionException: An error occurred while executing the command definition. See the inner exception for details.
---> System.Data.SqlClient.SqlException (0x80131904): The query processor ran out of internal resources and could not produce a query plan. This is a rare event and only expected for extremely complex queries or queries that reference a very large number of tables or partitions. Please simplify the query. If you believe you have received this message in error, contact Customer Support Services for more information.
at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction)
at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj, Boolean callerHasConnectionLock, Boolean asyncClose)
at System.Data.SqlClient.TdsParser.TryRun(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj, Boolean& dataReady)
at System.Data.SqlClient.SqlDataReader.TryConsumeMetaData()
at System.Data.SqlClient.SqlDataReader.get_MetaData()
at System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString)
at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async, Int32 timeout, Task& task, Boolean asyncWrite, SqlDataReader ds)
at System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior behavior)
at System.Data.Entity.Infrastructure.Interception.InternalDispatcher`1.Dispatch[TTarget,TInterceptionContext,TResult](TTarget target, Func`3 operation, TInterceptionContext interceptionContext, Action`3 executing, Action`3 executed)
at System.Data.Entity.Infrastructure.Interception.DbCommandDispatcher.Reader(DbCommand command, DbCommandInterceptionContext interceptionContext)
at System.Data.Entity.Core.EntityClient.Internal.EntityCommandDefinition.ExecuteStoreCommands(EntityCommand entityCommand, CommandBehavior behavior)
ClientConnectionId:e7553afb-099d-4701-a351-ac4c58deb6c9
Error Number:8623,State:1,Class:16
--- End of inner exception stack trace ---
at System.Data.Entity.Core.EntityClient.Internal.EntityCommandDefinition.ExecuteStoreCommands(EntityCommand entityCommand, CommandBehavior behavior)
at System.Data.Entity.Core.Objects.Internal.ObjectQueryExecutionPlan.Execute[TResultType](ObjectContext context, ObjectParameterCollection parameterValues)
at System.Data.Entity.Core.Objects.ObjectContext.ExecuteInTransaction[T](Func`1 func, IDbExecutionStrategy executionStrategy, Boolean startLocalTransaction, Boolean releaseConnectionOnSuccess)
at System.Data.Entity.Core.Objects.ObjectQuery`1.<>c__DisplayClass41_0.<GetResults>b__0()
at System.Data.Entity.Core.Objects.ObjectQuery`1.<System.Collections.Generic.IEnumerable<T>.GetEnumerator>b__31_0()
at System.Data.Entity.Internal.LazyEnumerator`1.MoveNext()
at System.Collections.Generic.List`1..ctor(IEnumerable`1 collection)
at System.Linq.Enumerable.ToList[TSource](IEnumerable`1 source)
at Erp.Internal.Conversion.FixBinsAllNew.createttPartBin(List`1 partList) in C:\_releases\ERP\ERP11.2.300.0\Source\Server\Internal\Conversions\FixBinsAllNew\FixBinsAllNew.cs:line 195
at Erp.Internal.Conversion.FixBinsAllNew.report(List`1 partList) in C:\_releases\ERP\ERP11.2.300.0\Source\Server\Internal\Conversions\FixBinsAllNew\FixBinsAllNew.cs:line 657
at Erp.Internal.Conversion.FixBinsAllNew.RunProcess(Int64 instanceTaskNum, String outputFileName) in C:\_releases\ERP\ERP11.2.300.0\Source\Server\Internal\Conversions\FixBinsAllNew\FixBinsAllNew.cs:line 163
at Ice.Core.TaskBase`1.StartProcess(Int64 instanceTaskNum, String outputFileName) in C:\_releases\ICE\ICE4.2.300.4\Source\Server\Internal\Lib\TaskLib\TaskBase\TaskBase.cs:line 81
at Ice.Hosting.TaskCaller.InnerExecuteTask(IceDataContext newContext) in C:\_releases\ICE\ICE4.2.300.4\Source\Server\Framework\Epicor.Ice\Hosting\TaskCaller\TaskCaller.cs:line 68
at Ice.Hosting.TaskCaller.ExecuteTask() in C:\_releases\ICE\ICE4.2.300.4\Source\Server\Framework\Epicor.Ice\Hosting\TaskCaller\TaskCaller.cs:line 59
at Ice.Hosting.TaskCaller.ExecuteTask(IceDataContext dataContext, Boolean suppressTransaction) in C:\_releases\ICE\ICE4.2.300.4\Source\Server\Framework\Epicor.Ice\Hosting\TaskCaller\TaskCaller.cs:line 39
at Ice.Services.Lib.RunTaskSvc.<>c__DisplayClass30_2.<InnerRunTask>b__1() in C:\_releases\ICE\ICE4.2.300.0\Source\Server\Services\Lib\RunTask\RunTask.cs:line 453
at Ice.Lib.RunTask.BpmFriendlyTaskLauncher.Run(String sessionIdPrefix, IceContext db, Action taskRunner) in C:\_releases\ICE\ICE4.2.300.0\Source\Server\Services\Lib\RunTask\BpmFriendlyTaskLauncher.cs:line 57
at Ice.Services.Lib.RunTaskSvc.InnerRunTask(Int64 ipTaskNum, Boolean suppressTransaction) in C:\_releases\ICE\ICE4.2.300.0\Source\Server\Services\Lib\RunTask\RunTask.cs:line 450
I’m guessing I’m going to need to run it with a set of parts at a time…
2 Likes
You blew it up.
2 Likes
That’s pretty much my standard response when someone requests something from me.
6 Likes
My standard response would be considered unacceptable in 99.5% of modern-day workspaces.
5 Likes
I was about to say, if they haven’t ran either of those fixes ever I would do it in a test environment to see the impact haha
1 Like
yes 29 on the selected date what date did you put ? it should run by the date so 13 off is your current assuming you selected different date to run the BAQ
For the selected date I had put in 10/1/24
what date format ? is this 10 Jan 2024 ? then i assume the stock 29 was on that date, any way you can use this part number and group all stock part transactions and calculate it up to this date, to confirm the BAQ method
I ran this last night. If I don’t select parts, it says all and runs through. It fixed 72 which seems low. If I hit the filter and select all the parts, it errors out.
So after running this, I tried @A.Baeisa 's query. I added PartBin to it and totaled that column and then added a bool to compare what PartBin had and what the query shows after adding up PartTran.
I still have 6 that don’t match. Any ideas?
No sorry, October 1, 2024. Was the current date when I entered it.
And today I’m running it for October 2, 2024 and still have 6 that don’t match
adding the Bin Id will cause an issue, the BAQ design to show total stock for all Bins, i run it in many companies in my environment and all ok, however for any part that you find discrepancy i would do as i suggested, i.e. group by transaction type and see which one is not considered in the BAQ, and let me know i might need to update it
Not using the bin ID. Combining just on part and summing the qty on hand by part not bin
Going to look through PartTran for those specific parts. If I find what the issue is and if it’s something needing changed on your BAQ, I’ll let you know but I’m guessing it’s something messed up in ours
1 Like
So looking at things, the first four on my list have ADJ-CST for the exact amount of the discrepancy so I’m guessing that’s it although you wouldn’t think that would take them out of inventory.
The other two I’m really confused on. 7008861 has a single part tran record which is a PUR-STK for 2 so it should be in inventory, but isn’t
The other one, 8014519 has 4 transactions, 1 MFG-STK for 1 which is what you are showing then 2 MFG-CUS: 2, 2, -2
By your math and mine, this should also add up to the 1 you are showing on your BAQ.
I’m reran th Refresh PartBin for just those two parts.
Processing Started: 10/02/24 10:39:16, UserID = TDray, Company = 1001, update mode.
No differences found.
Processing Completed: 10/02/24 10:39:16, UserID = TDray, Company = 1001, update mode.
Total parts processed = 2. Total PartTran records processed = 2.
Considering the second part had 4 transactions, it looks like the refresh is selective on which types of Transactions it checks as it didn’t run through the MFG-CUS (which should not affect inventory)
ADJ-CST has nothing to do with Qty on hand, but has a direct impact on Value - as money/cost- on Hand,
PUR-STK & MFG-STK are included in my designed sub-query calculated fields
MFG-CUS has got nothing to do with stock, it is from / To WIP to/from dispatched customer
While I absolutely agree with your assessment on how it should work, my part tran is looking differently.
8014519
Your BAQ shows 1 in inventory (which looks like it should be correct, partbin shows 0 in inventory)
7008661 has 1 transaction:
Your BAQ shows as 2 (which I would say has to be correct) and PartBin shows 0
7000620 your BAQ shows 16 my partbin shows 0
I would think the 16 is correct, but PartBin shows 0
Makes me really think I have something wrong in my system that the refresh isn’t catching but maybe I’m missing something.
you may check what trigger these transactions, i.e. ADJ-PUR is strange do you know what trigger it ? anyway on the last table only PUR-STK is effecting inventory quantity, the rest is not, however it might effect the inventory money value/cost as i explained but not the quantity, also PUR-UKN means the PO was for Non-Stock Part, so how come the part became Stock Part ? something is not correct on the process of using Epicor PO Vs Part Setup
I’ll look into ADJ-PUR.
I would agree that only PUR-STK should be affecting inventory, but then how is my PartBin record showing 0? It should be showing 16. I realize the rest shouldn’t but without them, how are we adding 16 to stock and coming up with a quantity of 0?
I had considered the possibility of a part changing from stock to nonstock as potentially causing some problems although I’m not sure how/why it would have been changed but I’ll investigate that as well.
Thank you very much for all your help. It is extremely appreciated.
1 Like
So it appears that the big problem was Qty Bearing being changed. I changed one of the questionable parts to Qty Bearing true and reran the refresh and it fixed it.
So ultimately, the fix was the refresh but changing Qty Bearing was required for me to fix it.
Marking this as the solution in case anyone comes along later so that they know to check the Qty Bearing flag as well.
2 Likes