You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A client of ours has been testing their environment after an upgrade from Dynamics NAV 2017 to Business Central 25.2 (on-prem) and they are experiencing problems trying to edit Job Task records that have been created by copying an existing project.
The error occurs due to a check that requires the field Qty. Picked of all corresponding Job Planning Lines to be 0. After some investigation, I've found that when creating the planning lines, the procedure CopyJobPlanningLines of the codeunit Copy Job (1006) resets a number of different fields - except some like Qty. Picked.
I can't say we are working with a clean slate here - there have been a number of modifications to the warehouse logic, and this client has worked with these changes for years before I've gotten involved, so I'm assuming an unmodified environment wouldn't run into the same issues.
But before I modify the CopyJobPlanningLines procedure, I want to understand why the standard code doesn't reset the field in question and if I am potentially adding a new error with the change.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
A client of ours has been testing their environment after an upgrade from Dynamics NAV 2017 to Business Central 25.2 (on-prem) and they are experiencing problems trying to edit
Job Taskrecords that have been created by copying an existing project.The error occurs due to a check that requires the field
Qty. Pickedof all corresponding Job Planning Lines to be0. After some investigation, I've found that when creating the planning lines, the procedureCopyJobPlanningLinesof the codeunitCopy Job (1006)resets a number of different fields - except some likeQty. Picked.I can't say we are working with a clean slate here - there have been a number of modifications to the warehouse logic, and this client has worked with these changes for years before I've gotten involved, so I'm assuming an unmodified environment wouldn't run into the same issues.
But before I modify the
CopyJobPlanningLinesprocedure, I want to understand why the standard code doesn't reset the field in question and if I am potentially adding a new error with the change.Beta Was this translation helpful? Give feedback.
All reactions