Enhancement Definition Document (EDD)

Functional Specifications - Enhancement

Enhancement Definition Document (EDD)

Document Identifier:

OTC_XXXXXXX_FS_XMLDocument History

Document Location

This is a snapshot of an on-line document. Paper copies are valid only on the day they are printed. Refer to the author if you are in any doubt about the currency of this document.

Project History

Project CodeSD4 Change No.SD4 WO No

(#) (Change Number)(Work Order Number)

Revision History

Revision NumberRevision DateSummary of ChangesRevised By

1.014.mar.2014CreationJoao Bueno

Approvals

This document requires the following approvals:

NameTitleDate

(Date)

Distribution

This document has been distributed to:

NameTitle

Table of Contents

41.0 Document Overview

41.1 Purpose

41.2 Overview

72.0 Object Information

73.0 Functional Design Specification

73.1 Overview / Justification

83.2 Functional Requirements

213.2.1 Program Type: (Program)

213.2.2 Program Type Dialog Program.

223.2.3 Program Type Custom Tables

234.0 Enhancement Specific Risks & Constraints

234.1 Scope Consideration

234.2 Dependencies

234.3 Cutover Considerations

234.4 Legacy System Adaptations

244.5 Common Design & Re-use Analysis

244.6 Security Requirements

244.7 Assumptions/Notes

245.0 Business Test Conditions

255.1 Normal Processing Provide test cases / conditions to test the program

255.2 Error Processing Provide error handling test cases / conditions to test the program

256.0 Issues

256.1 Issue Processing Provide Issue ticket number with issue and solution description

1.0 Document Overview

1.1 Purpose

The Enhancement Definition Document (EDD) document is intended to capture the functional level details according to the business needs. These details are then represented in the Technical Design Document (TDD).

Notes:

The Process team owns this functional specification and is responsible for the accurate completion of its contents. It is assumed that the Process Team will obtain the necessary guidance from other teams to complete the document.

Once this document is in approved status it is not to be changed or updated without appropriate change control procedures and technical team concurrence.

1.2 Overview

As per legal requirement from the Brazilian authorities Kraft Foods Brazil needs to issue legal electronic invoices called NF-e (Nota Fiscal Electronica) to accompany each material movements performed. To be allowed to issue a NF-e, Mondelez will first need to send an XML file containing all NF-e data to SEFAZ (Government Authorities). Then SEFAZ will check the information of the XML file sent and will answer the approval request authorizing or not Mondelez to issue the NF-e. The whole process is represented below:

XML - ENHANCEMENTS The objective of this functional specification is to provide logic for Enhancements to be implemented in the XML.1) Include the TAG < infCpl >, in XML and send to this TAG all information of ADITTIONAL DATA contained in DANFE. Legal information of SEFAZ Guide:

EXAMPLE:DANFE Additional Data

In this example, the TAG < infCpl > dever ficar como abaixo:

Example of NEoGrid XML, with TAG

Check if the program logic is being done entirely within SmartForms and copied to the DANFE, or if the program logic, call functions to mount these messages within the SmartForms, thus mapping all descriptive of the field, whether Standard or developed. The forms used for this operations is YOTC_DANFE, as below

2) Send batch information on TAG . Every NFe own issued (NFe issued by MDLZ and sent to the GRC) should perform this concatenation. This information is already on the DANFE and must be copied to the XML, as example below:

DANFE Material Data

XML - Without Batch information (current situation)

XML proposed scenario

The forms used for this operations is YOTC_DANFE, as below

2.0 Object Information

M = Mandatory field

Object ID MObject Description MNFe XML adjustment

Prepared By MJoao BuenoDate M15.Mar.2014

Functional Team MOTCFunctional Owner M(Team member)

Functional Owner

Phone #Functional owner Contact Email ID

Release

SAP Dev. Analyst M(TDD developer)SAP DA E-Mail ID M

SAP Dev. Analyst Phone # MSAP Dev. Analyst Location M

Approvals MNameRoleDate

3.0 Functional Design Specification

No fields should be left blank please enter NONE where not applicable!3.1 Overview / Justification

Priority FORMCHECKBOX High/mandatory FORMCHECKBOX Medium/recommended FORMCHECKBOX Low/optional

Justification on why standard SAP is not sufficient to attend FCI determinationThis required provide a treatment in the XML and DANFE , to guarantee determination of NT005_2012 ( Brazilian Tax Law ).It is also necessary to assure that al Eletronic Notas Fiscais specifics will be treated by while extracting data from SAP to the XML file and DANFE.

Associated GAP Documents

Associated Process Definition Document

Dependent Developments / TransactionsSome parts of this functional depends on implementation os OSS notes related to NFe 2.00 standards.

Business Complexity FORMCHECKBOX High FORMCHECKBOX Medium FORMCHECKBOX Low

Program Type: FORMCHECKBOX Program FORMCHECKBOX Dialog FORMCHECKBOX User Exit FORMCHECKBOX Custom Tables

FORMCHECKBOX Third Party Application (e.g. tax software)

Triggered: FORMCHECKBOX Manually FORMCHECKBOX Scheduled Job

Frequency: FORMCHECKBOX On-demand FORMCHECKBOX Hourly FORMCHECKBOX Daily FORMCHECKBOX Weekly FORMCHECKBOX Monthly FORMCHECKBOX Quarterly FORMCHECKBOX Yearly FORMCHECKBOX Other - Specify

3.2 Functional Requirements

Purpose

SAP standard provides a program which extracts information to be sent to the Message System. With the information received, the Message System will generate the XML file that will be sent to SEFAZ.

For the information not taken by this standard program, SAP offers BAdI definition called CL_NFE_PRINT that can be implemented. Implementing this BAdI, data treatments could be properly defined.

Current functionality

Desired functionality

Business Logic Narrative Flow

Step 1

Step 2

Step 3

3.2.1 Program Type: (Program)

(If Applicable)

Inputs Selection Screen fields

NameTable Field/ Check box/ Radio buttonSelect-option (S) or Parameter (P)Comments (Range, Single/Multiple Selection, Patterns, Mandatory etc.)Default Value

S or P

3.2.2 Program Type Dialog Program.

(If Applicable)

High Level Details

Screen Object Type FORMCHECKBOX SAP GUI FORMCHECKBOX WEB

Screen #Description of screen purposeScreen trigger

SCREEN FLOW (include graphic of screen sequence, action/event that triggers the flow, and parameters passed)

Screen Layouts: (attach details of screen layouts)

Screen Field Mapping:

Screen #Field NameInput / Output/

Mandatory

/OptionalDefault valuesMatch codes/ LOV used

(if any)Other formatting/

logic requirements

(Optional) Online Help Requirements

Field NameF1 Help RequirementsF4 Help? (Y/N)

3.2.3 Program Type Custom Tables

(If Applicable)

High Level Details

Table Maintenance FORMCHECKBOX Yes FORMCHECKBOX No

Basic Information

Table type: FORMCHECKBOX Configuration FORMCHECKBOX Application

Field NameType

(Char/Num/Amount/Qty)LengthDescription

4.0 Enhancement Specific Risks & Constraints

This enhancement assumes that the NF-e data will be in the fields specified in this document. If the information necessary to generate the XML file is not informed in the fields listed here, the wrong data will be taken and sent to the Message System. Wrong information sent to SEFAZ could cause NF-e rejection.

4.1 Scope Consideration

This enhancement considers just the treatment of the fields listed here. The fields not considered in this document or the fields that should be filled as described in the topic Business Requirement for the SAP standard treatment will not be treated by this enhancement.

4.2 Dependencies

4.3 Cutover Considerations

< Time constraints to the business>

4.4 Legacy System Adaptations

Based on the data available in the legacy system compared to the data required by SAP, addition data elements may be required from the legacy source system. In addition to the integration specific requirements, this section outlines the changes that are required to SAP and the legacy system(s). (Please quote RFD or CR numbers where appropriate)

SAP

External system

4.5 Common Design & Re-use Analysis

4.6 Security Requirements

4.7 Assumptions/Notes

Detail other related information

X-reference any related issues documents

Attach any other relevant documents

5.0 Business Test Conditions

5.1 Normal Processing Provide test cases / conditions to test the program

IDDescription

1XML NFe

5.2 Error Processing Provide error handling test cases / conditions to test the program

IDDescription

1

2

3

4

Note: Test Data should be provided to support Business Conditions documented above. If required test data does not exist in the system by the time development is scheduled to begin, functional team must provide necessary test data for the development team.

6.0 Issues

6.1 Issue Processing Provide Issue ticket number with issue and solution description

Issue Ticket NumberIssue and Solution Description

1

2

3

NF-e Receiver

NF-e Issuer

2006 Kraft Foods Confidential and Proprietary Information. All rights reserved.

For internal use only11 of 14 pagesTemplate: ZEDD v2