Comment 3 for bug 689868

Hello,

Thanks for your answer.

I'll test it like this BUT I'm not sure it'll be absolutely satisfying:
I had simplified my structure for the example, but it merely looks like this:

A
  B
  C
    D
      E
        F
        G
        H
      I
    J
      K
      L
  M

So A must be "phantom" so that it considers C's BoM, then probably C must be phantom to consider D's & J's BoMs, and D must be phantom to consider E's BoM...
I'm afraid of the side-effects of phantom-BoMs, I don't want at once thousands of procurements of things that aren't ready to buy or produce now, to be accepted at once in one single procurement order because of phantom BoMs.

Clearer explained: I want to be able to accept C's procurement order when B is ready.
With phantom Boms quite everywhere,
- instead of 1 procurement order for B, C & M,
- I'll have one for B, F, G, H, I, K, L, M,
am I right?
With all difficulty to clearly see where all these procurements come from or belong to (caus all our A, A', A'', A''' and so on products use the same components).

So it seems really strange to me that I have to simulate phantoms where I don't need phantoms according to my process, just for a cost report to function properly.

So I quite disagree with you, I think it quite looks like a bug.
How do you explain that the report "Bom structure" IS ABLE to recursively find the boms of the components (pic 1 of the attachment),
And that the report "product cost structure" IS NOT ABLE to do the same? There's no phantom BoM in either case... (pic 2)

So I would be grateful if you admitted to reconsider this:
** Changed in: openobject-addons
       Status: New => Invalid