Skip to Content

(1) Report Requirement Gathering Document              

  • Which includes users/clients requirement, scope, purpose, their already developed report dumps to understand the requirements.
  • This document help report developer to understand the actual requirements. In this report user specified formulas and functional requirements are mentioned, so that whoever is going to develop a report need to ask to users/clients for requirements. (at some point)
  • In this document a developer mostly covers the information which is received from users/clients.
  • A report developer has to understand the business and functionality.
  • If the requirement gathering is not done properly/completely, all the hierarchy phases given below stay incomplete, until and unless requirements are complete.
  • Source of requirements includes
    • Customers
    • Users
    • Administrators and maintenance staff
    • Domain Experts
    • Analysts

(2) Report Layout Document

  • This document contains layout of a report. Once requirement is closed then developer starts to make layout for a report with some technical information like user prompts, input controls, alerts etc.
  • This layout document sends to clients/users for verification/acceptance. After acceptance of layout, based on this layout document developer can start development for this report.

[ Report Development Phase ]

(3) Report Design Document

  • This document contains all technical details. E.g. details of data providers, object mappings, list of dimensions and key figures used in report, list of merged dimensions, alerts, filters, variables, conditions, formatting, block header, section details etc….
  • After developing a report and checking with all formatting and data, now you have to transfer your report in Quality System to validate with the data. For that you need to make a document called Report Transport Document to track records for each request.

(4) Report Transport Document (QA)

  • This document contains manually maintained request number, to keep record for each request in QA.
  • After transferring this report in quality, now it is time to validate this report with BEx.

(5) Validation Sheet

  • Take a dump of a report from Quality.
  • Take a dump of a BEx from Quality.
  • Now check key figures, calculated key figures with BEx and make a sheet.
  • If report is validated, then it is ready to move to Production system

(6) Report Transport Document (PROD)

  • This document contains manually maintained request number, to keep record for each request in PROD.

Thanks & Regards,

-Harshil J Joshi

SAP BW/BO

Scenario Considered:

BEx –> Universe –> Web I Report

To report this post you need to login first.

14 Comments

You must be Logged on to comment or reply to a post.

  1. Former Member

    Hi Harshil,

    I have an issue with Report bursting..
    Please help me in this issue ASAP.

    We bursting a webi report according to plant,its working fine.
    But some times some plant users getting empty documents due to those plants not having data.
    Now the users doesn’t want empty document when that particular plant not having the data,they want when the plant have data..

    Please help me out with this issue..

    Thanks,
    Jonathan

    (0) 
    1. Harshil Joshi Post author

      Hi Jonathan,

      You can set filter those plant which are having NULL values means at Universe/BEx level you can set PLANT <> NULL, then at report level you will be having only those PLANTS which are having values rest will not be populated. Hope this helps!!

      (0) 

Leave a Reply