Recording/Reporting Actual Component Scrap from Production
-
Recording/Reporting Actual Component Scrap from Production
Posted by Lewis Rosenberg on July 18, 2018 at 5:53 pm-
?Is anyone recording and reporting on ACTUAL component scrap from production orders? We’re looking for a way to do this.
The best suggestion I have seen so far comes from Olof Simren’s blog: Scrap In Production.
In section “Posting of Consumption with Scrap” of his blog, he suggests adding the REASON CODE field to the Consumption Journal page (it is an available field, but it is not available on the page). Consumption entries can then be enetered with a reason code (ex: “Actual” or “Scrap”) and then entries can be reported on or filtered based on the reason code in the VALUE ENTRIES (but, unfortunately not in the Item Ledger Entries).
Any other ideas?
——————————
Lewis Rosenberg
IT Manager
Mars Fishcare
Chalfont PANAVUG Board of Advisors, Programming
NAVUG Programming Committee
NAVUG Membership Committee
—————————— -
Jeffrey Mantz
MemberJuly 19, 2018 at 8:07 AM
I am working on this as well. My plan is to try taking the finished qty and qty per for each component to calculate what the expected consumption is. Then calculate the actual consumption postings for each line and compare. I plan to try this in Jet. We fairly recently just switched to NAV so other reports have taken priority but I should be getting to this soon.The idea of adding a reason code should work just fine, but I hope I don’t have to go that route as it is just another step for the user. Most everything we do is lot tracked so they already have lots of entries.
——————————
Jeffrey Mantz
Zefon International
——————————
——————————————- -
? I might give that Jet Report a try, but ultimately, I don’t think that’s what my team members are looking for. By entering the actual consumption quantity and actual scrap quantity, they can also measure that agains the standards set up in the BOM.
You make a good point about the additional entries in a lot controlled environment. The extra entries are not fun for those doing the data entry, especially when you have to drill down to another page for item tracking entries, but this does appear like it will give us the data we want to report on:
——————————
Lewis Rosenberg
IT Manager
Mars Fishcare
Chalfont PANAVUG Board of Advisors, Programming
NAVUG Programming Committee
NAVUG Membership Committee
——————————
——————————————- -
Jeffrey Mantz
MemberJuly 23, 2018 at 11:13 AM
Since my other post I did create a scrap report in Jet. When doing so I found our environment is likely much different than others, so the way I built the report may not work for everyone.
In our case, we are adjusting the components list on the order with scrap percentages and at the same time entering our tracking information. This is before posting the consumption, and after we know what the final output quantity will be. We are using backflushing on everything thus once we get to posting the consumption it just posts right through.
Because of the way we are doing this is it very easy to compare Finished Qty * Qty Per on the BOM with the quantity on the Component Line of the order. We get the benefit of the scrap percentage field as well.
I understand most people do not process it this way, but for various reasons it works well for us.
?
——————————
Jeffrey Mantz
Zefon International
——————————
——————————————- -
Franz Kalchmair
MemberJuly 19, 2018 at 9:59 AM
you could add field “reason code” to tab. item ledger entry and fill the field in cu 22 fct. InitItemLedgEntry.
you could maybe also add shortcut dim. 3 and 4 to the table for additional filter/analyse options.——————————
Franz Kalchmair
Microsoft MVP
Senior Consultant
Austria, Europe
——————————
——————————————- -
Kevin Fons
MemberJuly 20, 2018 at 9:31 AM
I have done a very similar report for a couple customers comparing the expected and actual consumptions, but without a reason code. The suggestions above for adding the reason code should work.
This is very easy to do with an SSRS Report or with Jet and possibly even with Power BI.
Doing it as a NAV RDLC report can be a bit clunky.——————————
Kevin Fons
Senior Application Consultant
Innovia Consulting
Windsor WI
——————————
——————————————- -
I’m curious about this because I’ve been thinking of creating a “Standard” Extension for this purpose as it seems to come up often.
One approach that I thought of was a collection page where you would record actual consumption and quantity output, which would sit in a queue for review.
Then someone would review this queue on a review screen (maybe just the consumption journal) where it would split that actual consumption between expected (calculated consumption) and the difference. The supervisor could add a reason code to the excess and post it.
Alternatively you could configure it with a default reason code and just let it post through.
Comparing the Actual used to the Expected Output and then adding 2 lines to consumption “auto-magically” would make reporting on it much easier, and give you the future ability to start analyzing the causes of your scrap.
I’d love to hear people’s opinions.
-Rob
——————————
Robert Jolliffe MCSE, MCS – NAV Manufacturing Expert
President
Sabre Limited
Cambridge
robert@sabrelimited.com
http://www.sabrelimited.com
——————————
——————————————-
Lewis Rosenberg replied 6 years, 5 months ago 1 Member · 0 Replies -
-
0 Replies
Sorry, there were no replies found.
The discussion ‘Recording/Reporting Actual Component Scrap from Production’ is closed to new replies.