Scrap - Output/Consumption Journal vs Production Journal

holzschuhholzschuh Member Posts: 19
Confused as to how scrap is to be handled using Output Journal and Consumption Journal versus the Production Journal.

Released Prod Order is for Item A for 700 pieces. Shop floor says they made 700 good pieces and 50 scrap pieces. Made an Output Journal, Output Quantity 700 and Scrap Quantity 50.
The Prod Order Stats show that the Expected Costs are based on 700 pieces. Go into Consumption Journal, Calc Consumption based on the Output of Item A and it generates detail lines for the Items consumed based on 750. Post and now the Prod Order Stats show the Actual Costs based on 750.. this is all good.
Using the Production Journal option, the Prod Order shows the requirement of 700 and the Prod Journal shows Consumption based on the 700. I can enter Output of 700 and scrap of 50 but the Consumption quantities are still based on 700. If I change the Prod Order requirements to 750 (so Consumption is based on 750 not 700) then I loose the ability to track Expected Costs to Actual Costs.

I'm obviously missing something?!!! anyones assistance is appreciated !!!
thanx

Comments

  • cernstcernst Member Posts: 280
    I assume that you have flushing method set to manual on the item card for the components. That means that you manually should enter the consumed quantity for the components. However in the consumption journal you have av function that helps you calculate the consumed quantity. You don't have that function in the production journal so that won't work.

    If you don't want to enter consumtion quantity manually you could use flushing method backward and maybe also routing link code to link components on the BOM to an operation in the routing. If you do that then components will be consumed automatically based upon output quantity and scrap quantity regardless of wheter you use output journal or production journal.
    _____________________
    NAV Freelance Consultant
  • AdamRoueAdamRoue Member Posts: 1,283
    In the consumption journal you have the choice to calculate based on actual or expected quantity. Therefore in your example your actual output is 750 as you have completed 700 and scrapped 50. If you choose expected it is based upon 700, actual will be 750. You do not get this choice in the "quicker/simpler" production journal where the expected quantity is always used as a basis because the consumption and output is presented at once.

    I would however say that you should not worry about the statistics screen. These are notoriously unreliable in NAV and this is one of them in different versions with different scenarios. Ultimately it is the final cost on the item ledger entry after the adjsut cost is run that is key, and if your consumption reflects the actual components consumed then this will be correct.
    The art of teaching is clarity and the art of learning is to listen
  • holzschuhholzschuh Member Posts: 19
    Thank you both for your timely responses !!!!!!!! The flushing method is manual and they don't want to change that. Your statement that the "quicker/simpler" Production Journal method is based on the Expected Qty makes sense now. However, the Production Dept sees the Production Journal (seeing/working with all Consumption/Output details on 1 screen) as a huge advantage over two "entry screens".
    Not being an expert in NAV, what are your thoughts on us having the logic in the Production Journal modified (a new function) so that the generated Consumption quantities could be recalculated after the user has added a Scrap Qty.
    IE. Expected Output of 700 and Consumption Items all based on 700.... user adds Scrap of 50...new function recalcs Consumption based on Expected 700 plus Scrap of 50 ?

    Thanx
  • AdamRoueAdamRoue Member Posts: 1,283
    Don't get me wrong, I always use the production journal :D It is just in cases where you start to make 700 and make 700 and scrap 50 it fails slightly on the calculation of the consumption.

    I am not a developer, but as it is all on one screen you will have difficulty in the calculation. The separation of the journals makes it easy. You would have to do this in two stages in the production journal as well, posting consumption after output, otherwise what can it calculate on? I have no issues in changing the logic from the expected quantity to the actual quantity on the production journal, but it might be more complex than we think, so see what happens when you run it past a developer.
    The art of teaching is clarity and the art of learning is to listen
  • holzschuhholzschuh Member Posts: 19
    Hi .... still confused ... if the Production Journal is based on Expected Output, which generates the Consumption quantity values .... then what is the purpose of having a Scrap entry field on the journal? We can't predetermine any constant Scrap quantity or percentage ... so keying in a scrap qty when it happens is all we have. I can't find any MS Dynamics NAV documentation that explains "how to scrap" using Production Journals. There wasn't anything stating that the Production Journal functionality was "less" or "lacking" or even different than the Consumption / Output Journals.
    Still looking for a detailed explanation regarding the entry of Scrap using the Production Journals.
    Thanx in advance !!!!!!
  • AdamRoueAdamRoue Member Posts: 1,283
    The scrap records the scrap, but you are doing it in a way that the journal does not like as you are over producing.

    If you started with 700 and at op 2 10 were scrapped you would have 690 complete and 10 in scrap, and so on. Then the costing is still based upon the final amount.

    In your situation the final steps are slightly irrelevant as you manually consume, so you are telling hte system what you use. It maybe an issue if you backflushed in the reporting manner you have as the consumption would be 700 not the 750. However MS will say how can you consume for 750 when you start with 700, and if this is process related they would tell you to use the appropriate add on tools or set you process in an appropriate manner.
    The art of teaching is clarity and the art of learning is to listen
  • dmitripdmitrip Member Posts: 44
    Scrap qty is posted just for the informational purpose and doesn't have any impact on GL.
    The reason is simply because it can be handled differently depending on the process. What is the scrap in this case? Is it counted and kept on inventory? Or it simply a scrap that you need to count just to calculate the effectiveness of your machines.
  • holzschuhholzschuh Member Posts: 19
    Hi ... I'll try to explain in more detail....
    Released Prod Order is for 700 good pieces. The piece is stamped from a coil of steel and nuts are welded on all by robots in 1 line. For many reasons that can not be predicted, there will be scrap. Press, die, robot, material, human etc. problems. The shop floor will continue to run the operation until the 700 good pieces are created. The Tally sheet at end of shift says ... asked for 700, made 700, consumed 750 nuts and equivalent steel... scrapped 50 "good pieces".
    Doing an Output Journal of 50 scrap and 700 good pieces and then generating a corresponding Consumption Journal... I can see detail records in the Item Ledger showing 1 record for consuming 700 nuts and a 2nd record for consuming 50 nuts (scrap) ... In Table 5407 Prod Order Components, I can see the expected Quantities (700) for the consumed Items along with the actual Quantities consumed (750). All this gives us good info to analyze scrap created, scrap generated (the extra pieces consumed to make the 700), by machine/item etc. etc. This detail is also good when the nut is used on many other finished Items and you are tracking down the extra consumption to a specific Item/Machine/Process.

    Using the Production Journal, everything is based on the "expected". I fudged the expected to 750, entered 50 scrap... In looking at the Item Ledger Entries, the Production Journal process acts very much differently than the "output/consumption" process (not noted anywhere by NAV)... the detail entries show 1 record for the consumption of 750 and 1 for the output of 750. This lack of detail (as created by using Output/Consumption journals) is a major short coming / difference. So as people have said, there is a difference to how the two journal processes "act", how they keep detailed records and how they denote scrap. I would have thought that this major difference would have been documented.... ah well .....

    We need the look a feel of the Production Journal (showing consumption and output) but with the logic of the Output/Consumption Journal in keeping detail records. From the Item Ledger Entries and Capacity Entries we should be able to do scrap analysis..... ah customization....

    FYI Details looked at: dumped Tables 5405, 5406, 5407, 5832 and by Prod Order... Item Ledger Entries, Capacity Entries and Value Entries.

    Dave
  • holzschuhholzschuh Member Posts: 19
    Have spent a lot of time testing / documenting how NAV processes:
    A) manual scrap and Item % Scrap using A1) Output Journal and Consumption Journal with option Actual and A2) Output Journal and Consumption Journal with option Expected.
    B) Production Journal where Consumption includes manual Scap (not using Item % Scrap)
    C) Production Journal where Consumption is based on Qty plus Item % Scrap
    D) how NAV handles, reports and defines Expected Cost and Actual Cost when doing Production Order Stats in all the above cases ....

    Warning... make sure you understand each method before picking one to use.... also check the quantities being posted to the Capacity Ledger... also check if scrap is properly being reported in the Capacity Ledger when using the Item % Scrap.... you may find some "things" that will need to be changed to meet "manufacturing" requirements ....

    Poor NAV documentation... !!! all done whining ...
Sign In or Register to comment.