8 Answers

• 00

  

  spaco (Author)10/23/23, 6:18 PM

  By the way, the phenomenon described above does not only occur in the context of sales order costing, but also in a "normal" material costing (CK11N): In the "classic" IDES client 800, the multi-level BOM is correctly exploded and costed, whereas in the IDES customizing client, in which I move for certain reasons, despite IMHO the same initial data, the assemblies - as a result of a "raw material costing" - are valuated with their standard price, i.e. not recosted.
  I remain perplexed, but will research further and check the identity of the initial data and settings for the umpteenth time.
  Best regards
  Ulrich

  report
• 00

  

  Martin Munzel 10/23/23, 6:18 PM

  Hello Ulrich,
  please check if the checkmark "do not cost" is set in the material master of the assemblies in the view "Costing 1". If yes, remove it and check "Costing with quantity structure" instead.
  Best regards,
  Martin
  ----------------
  Martin Munzel
  SAP consultant, trainer, author http://www.martin-munzel.com

  report
• 00

  

  spaco (Author)10/23/23, 6:18 PM

  Hello Martin,
  thanks for your feedback and first of all all all the best for 2014 - even if the year is soon over :-)
  I'm afraid it's not that simple, unfortunately, because the assembly materials all have the "With quantity structure" checkbox set and the "do not calculate" unchecked.
  I also wanted to have attached a PDF document to my contribution here for a long time, which makes the problem a little less abstract, but unfortunately I had to fight with impaired internet access for the last few days. Since it now works again, I hope to be able to upload said document here tonight.
  First of all, I would like to inform you that the costing log of the top material for the four assembly materials shows the message CK776, according to which no valid source of supply can be found for the materials. However, this only happens in the client that is causing me problems, in the "normal" IDES client 800 the BOMs for the assemblies are exploded and costed "as usual".
  Somehow / somewhere the system in the "crooked" client apparently interprets the assembly materials as purchased parts, but I can't find the place where this could be. I once got to know the CK776 when (purchase) materials with source list requirement were created in the material master and then the source list was not properly maintained, but that is not the case here either, since the assemblies are "actually" created as "typical" in-house production materials (not even procurement type X, but a "clear" E).
  Best regards
  Ulrich

  report
• 00

  

  Martin Munzel 10/23/23, 6:18 PM

  Hello Ulrich,
  Happy new year to you too! And still takes a while until it's over again ;)
  Is then maybe something wrong with the valuation variant? Which strategy is set for the valuation of material costs?
  Greetings, Martin
  ----------------
  Martin Munzel
  SAP consultant, trainer, author http://www.martin-munzel.com

  report
• 00

  

  spaco (Author)10/23/23, 6:18 PM

  In the valuation variant, I could not recognize any differences between the two clients.
  As I said, I will make my research results available as a PDF file this evening, so that you can see my thought processes and the data constellation a bit more clearly.
  Best regards
  Ulrich

  report
• 00

  

  spaco (Author)10/23/23, 6:18 PM

  I would have liked to do it, but in the meantime in the used system / client it is already so far that the call of the transaction SPRO leads to a runtime error.
  Best regards
  Ulrich
  

  Last edited 12.01.14 13:54

  report
• 00

  

  spaco (Author)10/23/23, 6:18 PM

  As some may still darkly remember, I wanted to provide another doc of "my" calculation problem in client A. Here you go (see attachment)
  Best regards
  Ulrich

  report
• 00

  

  broink 10/23/23, 6:18 PM

  Hello all,
  this is already quite an old topic, but I would still like to explain for colleagues with similar problems, what was the reason for us in a similar case (but in CK11N):
  We had inconsistencies in the dispost levels (MARA-DISST).
  In our case this could be solved with the report RDISCALC. We have partly recursive BOMs in use.
  SAP support had initially called note 1931291, but due to the wrong recursive stülis, these reports always came after 10 s to the abort. For others, however, these reports might be helpful....
  VG
  B

  report