Query regarding Opened/Closed GL periods

Question

Hello Gurus,
ive got an issue, when using 0FIGL_C01 Cube.
The query ive created balances on cumulative balance (as key figure) and GL account names (as hierarchy).
Now i want to show the data of cumulative balance regarding closed periods.
I.e. if we have current April month the balance should be 0, but all other in the past January, February, March should be displayed.
How it is possible to do this?
Ive tryed to create a calculated key figure, whith code something like:
IF debit and credit == 0 then Cummulative balance=0 else Cumulative balance.
It works fine but it shows also the postings of current period, which isnt realy closed.
Tried to search the indicators of FI open/closed periods, but the only thing i found is S_ALR_87003642 - Open and Close Posting Periods transaction showing Company code, GL account ranges and from to period data.
What could be the sollution for this? Should i create new DS for the mensioned TC and then to create a multicube or perhaps is a better and faster way in doing it?
Thanks a lot in advice
Laurynas Prikockis

Answer 1

Hi Shrikant,
>
Shrikant Varma wrote:
> Yes, I could consider using belnr selection to reduce the size of the selection. This will again be a selection more
> based on knowledge of application(of course with fine tuning of packet size).
>  But then this approach will not be as efficient and as easy as letting database take control of the iteration of this
> huge dataset - as is intended by the use of cursors with the help of packet size.
>
I'm not sure what you mean here: "let the database contorl the iteration of this huge dataset - with cursors".
Generally speaking you have 2 options when it comes to parallel processing:
Parallelize processes in the ABAP stack. These processes access different, non-overlaping, parts of your restult set
in parallel. Using the BELNR could be an approach to build different, non-overlapping paackages.
Database side parallelization. This is possible for every action that uses multiblock I/O (full table scans and index fast full scans) and for partitioned segments. For non-partitioned segments and single block I/O database side parallelization is not possible.
So, generally speaking, you have 3 options:
1.) parallelize in ABAP and build idependent packages
2.) force the DB to do multiblock I/O (full table scan, index fast full scan) in parallel
3.) partition your table and indexes.
I think (it's just my opinion) for an ERP (not BW / BI) system
- option 3 is not a good option for OLTP systems (several reasons). I see it very, very, very rarely or close to never in OLTP systems
- option 2 may read (much) more data then you would need to read, although a very efficient I/O method would be used (multibock I/O)
- option 1 requires programming in ABAP but will read exactly the data you need to read and can be controlled very well in the ABAP stack (parallel single block I/O will be used)
In alamost all cases (that are similar to your case) i have see option 1 was used.
Kind regards,
Hermann