I believe you'll need to aggregate the AMOUNT column on the report, right? If so, Attribute Views won't work. You'll get wrong results.
Also, if that table is very large, I would not recommend doing self joins. Performance will suffer.
Based on the example you provided, you have a parent-child hierarchy embedded in a fact table, but you only want records for the leaf nodes of your hierarchy.
Not sure if Data Services is part of your landscape, but assuming it is, this is what I would recommend:
1) Move the hierarchy into it's own table.
2) Maintain leaf nodes in your fact table for the join.
3) Create an Attribute View and model the parent-child hierarchy.
4) Join to fact table in an Analytic View.
5) Use any front-end tool that consumes via MDX, such as Analysis for Office, to flatten out the hierarchy on-the-fly.
A bit more clumsy is to flatten out the hierarchy yourself in a separate table, join on leaf nodes, and then you can model for any client without the need for MDX's hierarchy support.
Should help all of your performance issues.
(Not a BW guy so I just read "table" from your discussion - not sure how much flexibility you have in creating new target table structures to do what I recommended)