Functional Specification Invoice

[Former Member]

Hi Guru's

Any Bady Could u Pls Send Functional Specification For Invoice With Tax.

My Mail ID is ksrmurthysap@gmail.com

Regards

Sriram

[Former Member]

Dear Sriram,

You would design the selection screen as per your requirement.

Selection Range for Customer Number, Invoice Number, Invoice Date etc.

Validation Logic. Logic to fetch the data.

Also, you would decide on the output format (what are all the fields to be displayed in the output).

Tables involved:

KNVI Customer Master Tax Indicator

KNVL Customer Master Licenses

VBRK Billing Document: Header Data

VBRL Sales Document: Invoice List

VBRP Billing Document: Item Data

VRKPA Sales Index: Bills by Partner Functions

VRPMA SD Index: Billing Items per Material

KNA1 General Data in Customer Master

KNB1 Customer Master (Company Code)

KNC1 Customer master (transaction figures)

Functional specification: The Functional Specification is a comprehensive document created after the Software Requirements Document. It provides more details on selected items originally described in the Software Requirements Template. Elsewhre organizations combine these two documents into a single document.

Functional specs is like a templeate document, hence it will be same whether it is AR or AP or CCA. Basically functional specs is a document which explains the requirements with technical details, so that technical consultant or any other person can read and understand what is the background of the report or an extension done in SAP.

The Functional Specification describes the features of the desired functinality. It describes the product's features as seen by the stake holders,and contains the technical information and the data needed for the design and developement.

The functional specs should have the following details:

Background: Information why this report is required and Business process involved in that.

Selection Parameters: This should what fields should be selection fields, which are optional and which are mandatory etc.

Layout of the report: What information is required in the output of the report. This should also indicate the technical names - Table and field names from where the data needs to be fetched.

Detailed Description: This should explain the logic of the report - what calculations needs to be done etc.

The Functional Specification defines what the functionality will be of a particulat area that is to be precise a transaction in SAP terminology.

It also contains the data regarding change history, if any.

Functional Spec is mainly prepared for the purpose of developing the new reports (this happens only when SAP standard report not achieve the client purpose) using the ABAP Program. for ABAPers you need to give the details of the Tables , Fields and the logic how to pick the value and get the report.

Visit the following links:

http://www.sap-img.com/general/what-are-functional-specification-in-sap.htm

http://www.epri.com/eprisoftware/processguide/funcspec.html

Regards,

Naveen.

[Former Member]

Functional Spec : Its a document written by the functional guy to communicate to the abaper, to say what developement needs to be carried out and what are the tables and fields involved. The basic reason for a functional spec would be that of a documentation and reference and importantly the technical guys wouldnt really know the business process but only the tables and fields involved. So the functional guy communicates the business requirement in technical way through a functional spec. Features of a Func. spec would be that it will have a version number which would change depending on the modifications made to that particular object there after. There would be a pseudo logic which outlines what needs to be done for data extraction, tables and fields to be used, validations, testin info .,

http://sap-img.com/general/what-are-functional-specification-in-sap.htm

To Identify Table & Fields & the table links:

http://www.sap-img.com/

Topic: Free ABAP eBook Download

SAP MM, SD, FI, PS, PP, PM, HR, System Tables

Regards,

Rajesh Banka

Reward suitable points.

• How to give points: Mark your thread as a question while creating it. In the answers you get, you can assign the points by clicking on the stars to the left. You also get a point yourself for rewarding (one per thread).

[Former Member]

A functional specification (or sometimes functional specifications) is a formal document used to describe in detail for software developers a product's intended capabilities, appearance, and interactions with users. The functional specification is a kind of guideline and continuing reference point as the developers write the programming code. (At least one major product development group used a "Write the manual first" approach. Before the product existed, they wrote the user's guide for a word processing system, then declared that the user's guide was the functional specification. The developers were challenged to create a product that matched what the user's guide described.) Typically, the functional specification for an application program with a series of interactive windows and dialogs with a user would show the visual appearance of the user interface and describe each of the possible user input actions and the program response actions. A functional specification may also contain formal descriptions of user tasks, dependencies on other products, and usability criteria. Many companies have a guide for developers that describes what topics any product's functional specification should contain.

For a sense of where the functional specification fits into the development process, here are a typical series of steps in developing a software product:

Requirements. This is a formal statement of what the product planners informed by their knowledge of the marketplace and specific input from existing or potential customers believe is needed for a new product or a new version of an existing product. Requirements are usually expressed in terms of narrative statements and in a relatively general way.

Objectives. Objectives are written by product designers in response to the Requirements. They describe in a more specific way what the product will look like. Objectives may describe architectures, protocols, and standards to which the product will conform. Measurable objectives are those that set some criteria by which the end product can be judged. Measurability can be in terms of some index of customer satisfaction or in terms of capabilities and task times. Objectives must recognize time and resource constraints. The development schedule is often part or a corollary of the Objectives.

Functional specification. The functional specification (usually functional spec or just spec for short) is the formal response to the objectives. It describes all external user and programming interfaces that the product must support.

Design change requests. Throughout the development process, as the need for change to the functional specification is recognized, a formal change is described in a design change request.

Logic specification. The structure of the programming (for example, major groups of code modules that support a similar function), individual code modules and their relationships, and the data parameters that they pass to each other may be described in a formal document called a logic specification. The logic specification describes internal interfaces and is for use only by the developers, testers, and, later, to some extent, the programmers that service the product and provide code fixes to the field.

User documentation. In general, all of the preceding documents (except the logic specification) are used as source material for the technical manuals and online information (such as help pages) that are prepared for the product's users.

Test plan. Most development groups have a formal test plan that describes test cases that will exercise the programming that is written. Testing is done at the module (or unit) level, at the component level, and at the system level in context with other products. This can be thought of as alpha testing. The plan may also allow for beta test. Some companies provide an early version of the product to a selected group of customers for testing in a "real world" situation.

The final product. Ideally, the final product is a complete implementation of the functional specification and design change requests, some of which may result from formal testing and beta testing.

The cycle is then repeated for the next version of the product, beginning with a new Requirements statement, which ideally uses feedback from customers about the current product to determine what customers need or want next.

Most software makers adhere to a formal development process similar to the one described above. The hardware development process is similar but includes some additional considerations for the outsourcing of parts and verification of the manufacturing process itself.

Regards,

Rajesh Banka