Application Information Document (AID) Heinz SAP...

HJ Heinz SAP SD – AID

Application Information Document (AID)

Heinz SAP SD

Version 2.0

Owner IBM UK Limited

Name Designation Signature & Date

Prepared by

Amended by

Shweta Gupta

John P Lingam

IBM SAP SD Consultant

IBM SAP SD Consultant

Concurred by Sofie Lilja IBM GBS SAP Consultant

Approved by Richard Knee HJHeinz UK & Ireland Application Development Manager

Copy Number: 01

IBM Application Services Page 1 of 53


REVIEW AND APPROVALS

This SAP SD – ECS Application Information Document has been reviewed and approved by the required parties.

Date Andy Scott

IBM Delivery Representative

Date John Lingam

IBM Production Support Representative

Date IBM India Representative

Date SQA Representative

Date Peter J Robinson

IBM Migration Project Manager



Revision History:

Version No.

Issue Date Description of Changes

Location/Para/Page/Sec. No.

Author:

1.0 30.06.2006Initial Release

ALL Shweta Gupta

2.0 10.01.2007 Updated to reflect additional entries to support Phase 2a.

5.1>2>Company Code to Plant Assignment &Shipping Point.

5.1>4>Sales Org,Dis Channel & Plant Assignment.

5.4.2>5.A>PAL Config1.Doc.

5.6>2.A>Intercompany Billing1.Doc

John Paul Lingam



Table of Contents

1 OBJECTIVES .................................................................................................52 APPLICATION OVERVIEW .......................................................................53 TERMINOLOGY AND ACRONYMS .........................................................74 APPLICATION PLATFORM......................................................................8

4.1 PHYSICAL ENVIRONMENT..................................................................................................8Picking from Kitt green – In Kitt green, from sales order creation till invoicing complete process done manually......................................................................................................................................................19

T-CODE USED ZSD_ORDERLAYER..........................................................................44 ..........................................................................................................................................45



1 OBJECTIVES

The objective of the Application Information Document (AID) is to provide members of the delivery team with an overview of the SAP SD applications. The AID describes the function of the application, the structure of the applications, the application configuration and the technical environment. This document will refer to any existing related documentation.

The AID will be used in conjunction with the Application Support Control Plan (ASCP) to support the application.

The delivery team will keep the AID current throughout the life of the SAP SD applications.

2 APPLICATION OVERVIEW

SD Applications are used for the following activities

S.No SD Functionality

1 Maintain Enterprise structure ( from SD perspective)

2 Customer Master Data Creation

3 Maintain Master Data of the existing Heinz customer and any changes in account group

4 Basic functions in Sales (Configuration)(Pricing determination, Partner, Output, Text, ATP/TOR, PP, Incompletion, Credit Management, Material Determination, Product Allocation)

5 Sales configurations (Sales doc. Types/item categories/schedule line categories/Maintain copy control)

6 Logistics Execution (Shipping/ Transportations-Routes)

7 Billing (Inter company billing/Del related billing/ Order related



SD Processes

No. SD Functionality

1 Sales Order Processing- EDI, Telesales, Fax

2 Interfaces ( WMS, GENTRAN, MANUGISTIC, ICS )

2 Exports & Affiliates

3 Inter Company Sales

4 Delivery processing (Interface to WMS)

5 Special sales, Samples sales, Charity & donations, Destruction orders, Short dated stock sales

6 Uplift/Returns

7 Credit (Value & Quantity) / Debit (Value & Quantity)

8 Invoicing



3 TERMINOLOGY AND ACRONYMS

Acronyms and terminology specifically used in this document are described below. Other acronyms commonly used can be found in the ASCP.

No. Terminology / Acronyms

Meaning

1 AID Application Information Document

2 ASCP Application Support Control Plan

3 SD Sales & Distribution

4 NDC National Distribution Centre (Win canton)

5 KG Kittgreen

6 SOP Sales Order Processing

7 WMS Warehouse Management System

8 PP Product Proposal

9 PPP Product Proposal Procedure

10 EDI Electronic Data Interchange

11 PA Product Allocation

12 MDR Master Data Repository

13 POD Proof of Delivery

14 PAR Product at Risk

15 SAC Strategic Automatic Cut

16 ATP Available to Promise

17 SCR System Change Request

18 CRFS Change Request for Approved Functional Specification.



4 APPLICATION PLATFORM

4.1 Physical Environment

a) Development Server

b) Quality Sever (HRQ/HRS)

c) & Production Server

4.2 Operational Environment

SAP Application Server Client

Sandbox HRY 015

Development HRY 025

Development Test HRY 045

Quality HRQ 100

Quality Testing Server

HRS 305

Production HRP 200

5 CONFIGURATIONS, PROCESSES & INTERFACES



5.1 ENTERPRISE STRUCTURE:

Brief introduction of Enterprise structure:

H J Heinz Co Ltd (Selling in Manufacturing) is defined as Company code 3030. Heinz currently has a number of locations, where product is produced, stored or distributed from. Within SAP each location is termed as Plant. Heinz has two main plants apart from others. Kitt green (KG 3005) and other owned by Wincanton (NDC 3006).Kitt green is manufacturing plant (35000 Pallets/day) and it has warehouse as well. While NDC is not a manufacturing plant, it acts as warehouse for Heinz. It’s storing capacity 80,000 pallets. Most of the deliveries took place from Win canton (NDC) only.

Other plants are as follows:

1) Hayes Park (3007) – Its not selling plant, used by Finance. Its set up as plant for Credits/Debits/ Accruals etc.

2) T Guy (3520), IBL Cold stores (3519) & 3518 – Reworking areas

3) Kammac Plant – 3111 (Reworking)

4) Liam Caroll – 3532 (Ireland (Sales Org. 3001/3002, Company code 3260))

Distribution Channel: There are four different means of doing business (Distribution goods)

1) Retail – 10

2) Food Service- 50

3) Export- 60

4) Affliate-99

Common distribution Channel: For distribution Channel 10, referencing is 10 hence master data for pricing can be created with 10. While “50” is referencing 10.

For “60” & “99” Customer /Material Records are different, no sharing.

Division: Dummy Division “00” – Not applicableSales Office: Not usedSales Group: Not used

PLEASE REFER THE PPT FILE BELOW AND REFER TO HEINZ ASCENDANT>CONFIG TREE> SAP R/3 FOR ANY CHANGES



1) FI ORGANIZATION STRUCTURE:

2) COMPANY CODE TO PLANT & PLANT TO SHIPPING POINT ASSIGNMENT :Error! Not a valid link.


E n t e r p r i s e S t r u c t u r e

C r e d i t C o n t r o lA r e a3 0 0 3

C o m p a n y c o d e3 0 3 0

3 0 0 0C o n t r o l l i n g A r e a

0 0 0 1O p e r a t i n g C o n c e r n


Plants Shipping Points 3005 Kitt Green (Huk) 3005 Kitt Green (Huk) 3006 NDC (HUK) 3006 NDC (HUK) 3007 Hayes Park 3007 Hayes Park 3009 Kendel (HUK) 3009 Kendel (HUK) 3023 Telford (HUK) 3023 Telford (HUK) 3024 Aston (HUK) 3024 Aston (HUK) 3027 Worcester (HUK) 3027 Worcester (HUK) 3111 Kammac Plc (HUK) 3111 Kammac Plc (HUK) 3115 RW Warrens (HUK) 3115 RW Warrens (HUK) 3117 Advanced Inspection Services 3117 Advanced Inspection Services 3118 LPS Reworker (HUK) 3118 LPS Reworker (HUK) 3119 AHC Reworker (HUK) 3119 AHC Reworker (HUK) 3134 Princes Manufacturing Ltd (HUK) 3134 Princes Manufacturing Ltd (HUK) 3501 Boughey (HUK) 3501 Boughey (HUK) 3504 Amoy Docks (HUK) 3504 Amoy Docks (HUK) 3518 Grocontinental (HUK) 3518 Grocontinental (HUK) 3519 IBL Cold Stores (HUK) 3519 IBL Cold Stores (HUK) 3520 T Guy (HUK) 3520 T Guy (HUK)

COMPANY CODE 3030

3528 Orion Express Services 3528 Orion Express Services

3001 Erin Foods Ltd 3001 Erin Foods Ltd 3002 H.J.Heinz Company (Ireland) 3002 H.J.Heinz Company (Ireland) 3003 Ireland South 3003 Ireland South 3004 Ireland North 3004 Ireland North

COMPANY CODE 3260

3532 Liam Carroll Refridgerated Ltd 3532 Liam Carroll Refridgerated Ltd

3) SALES ORGANIZATION STRUCTURE:


D i v i s i o nN o t A p p l i c a b l e

0 0

D i s t r i b u t i o n c h a n n e lE x p o r t

6 0


0 0

D i s t r i b u t i o n C h a n n e lA f f i l i a t e s

9 9


0 0

D i s t r i b u t i o n C h a n n e lF o o d S e r v i c e

5 0


0 0

D i s t r i b u t i o n C h a n n e lH o m e T r a d e

1 0

S a l e s O r g a n a i z a t i o n3 0 3 0

C o m p a n y C o d e3 0 3 0


4) SALES ORGANISATION, DISTRIBUTION CHANNEL & PLANT ASSIGNMENT:


Company Code

3030

Sales Organaization

3030

Distribution channel

Export

60

Distribution Channel

Affiliates

99


Food Service

50


Home Trade

10Plants

3005,3006,3007,3009

3111,3118,3119,3023

3520,3530,3531,3534,3535

Plants

3005,3006,3007,3009

3111,3118,3119,3023

3520,3530,3531,3534,3535

Plants

3005,3006,3007,3009

3111,3118,3119,3023

3520,3530,3531,3534,3535

Plants

3005,3006,3007,3009

3111,3118,3119,3023

3520,3530,3531,3534,3535


3030 HJHEINZ CO LTD3030 HJHEINZ CO LTD3030 HJHEINZ CO LTD3030 HJHEINZ CO LTD 10 Retail 50 Food Service 60 Export 99 Affiliate 3005 Kitt Green (HUK) 3005 Kitt Green (HUK) 3005 Kitt Green (HUK) 3005 Kitt Green (HUK) 3006 NDC (HUK) 3006 NDC (HUK) 3006 NDC (HUK) 3006 NDC (HUK) 3007 Hayes Park 3007 Hayes Park 3007 Hayes Park 3007 Hayes Park 3009 Kendal (HUK) 3009 Kendal (HUK) 3009 Kendal (HUK) 3009 Kendal (HUK) 3023 Telford (HUK) 3023 Telford (HUK) 3023 Telford (HUK) 3023 Telford (HUK) 3024 Aston (HUK) 3024 Aston (HUK) 3024 Aston (HUK) 3024 Aston (HUK) 3027 Worcester (HUK) 3027 Worcester (HUK) 3027 Worcester (HUK) 3027 Worcester (HUK) 3111 Kammac Plc (HUK) 3111 Kammac Plc (HUK) 3111 Kammac Plc (HUK) 3111 Kammac Plc (HUK) 3115 RW Warrens (HUK) 3115 RW Warrens (HUK) 3115 RW Warrens (HUK) 3115 RW Warrens (HUK) 3117 Advanced Inspection Services 3117 Advanced Inspection Services 3117 Advanced Inspection Services 3117 Advanced Inspection Services 3118 LPS Reworker (HUK) 3118 LPS Reworker (HUK) 3118 LPS Reworker (HUK) 3118 LPS Reworker (HUK) 3119 AHC Reworker (HUK) 3119 AHC Reworker (HUK) 3119 AHC Reworker (HUK) 3119 AHC Reworker (HUK) 3134 Princes Manufacturing Ltd (HUK 3134 Princes Manufacturing Ltd (HUK 3134 Princes Manufacturing Ltd (HUK 3134 Princes Manufacturing Ltd (HUK 3501 Boughey (HUK) 3501 Boughey (HUK) 3501 Boughey (HUK) 3501 Boughey (HUK) 3504 Amoy Docks (HUK) 3504 Amoy Docks (HUK) 3504 Amoy Docks (HUK) 3504 Amoy Docks (HUK) 3520 T Guy (HUK) 3520 T Guy (HUK) 3520 T Guy (HUK) 3518 Grocontinental (HUK) 3528 Orion Express Services 3528 Orion Express Services 3528 Orion Express Services 3519 IBL Cold Stores (HUK) 3529 Heinz (Park Royal) 3529 Heinz (Park Royal) 3529 Heinz (Park Royal) 3520 T Guy (HUK) 3530 QK Meats Ltd 3530 QK Meats Ltd 3530 QK Meats Ltd 3528 Orion Express Services 3531 Great Harwood Food Products 3531 Great Harwood Food Products 3531 Great Harwood Food Products 3529 Heinz (Park Royal) 3534 Afon Tinplate 3534 Afon Tinplate 3534 Afon Tinplate 3530 QK Meats Ltd 3535 Liverpool Docks 3535 Liverpool Docks 3535 Liverpool Docks 3531 Great Harwood Food Products 3999 Rework Plant (HUK) 3999 Rework Plant (HUK) 3999 Rework Plant (HUK) 3533 Wincanton (Northen Ireland)

3534 Afon Tinplate 3535 Liverpool Docks 3999 Rework Plant (HUK)

5.2 BUSINESS PARTNER

1) Define hierarchy types: only Hierarchy type “A” is used currently.



2) Account group assignment for customer hierarchy type A

3) Sales area assignment: this configuration allows you to determine whether a sales area uses its own customer hierarchies or shares one with another sales areas.



A few more assignments are:

4) Assign hierarchy type for Pricing by Sales Document:





REFER TO HEINZ ASCENDANT>CONFIG TREE>SAP R/3 FOR ANY CHANGES



5.3) Sales Order Processing

In Heinz OAK, there will always be one delivery against Sales Orders. Partial deliveries are not allowed. Putting the flag of ‘Complete Delivery’ in Customer Master Data and at Sales Orders controls it.

HEINZ OAK SALES ORDER PROCESSING:

5.3.2 Picking/PGI Process from Kittgreen/NDC in SAP



Picking from Kitt green – In Kitt green, from sales order creation till invoicing complete process done manually.

1) Create Sales Order (Order Acknowledgement sent to Payer by ZBA1 output type and ZBA2 output type to LSP ( Websphere))

2) Create Delivery with ref to Sales Order (ZLD2 output type for printing Shipping notification)

3) Use MB52 /MMBE to get the Batch number for EPN.

4) Put Batch number against EPN in delivery

5) Create Transfer Order (Picking)

6) Confirm T.O (Confirm Internally), Get the Handling Unit from T-code ZHUMO. (To find empty Handling unit always put ‘LGER’ status, and put Material number, Plant, Batch number in Contents tab.)

7) Put the Handling Unit (Storage Unit) in T.O, confirm it and save T.O

7) After picking, do PGI and use T-code VLPOD for POD (Proof of delivery).

8) Create Invoice. (ZRD2 sent the output to EDI Customer, ZRD3 out put type prints the output)

Picking from NDC: In NDC, Sales Order creation/Delivery creation is manual. While picking and PGI is automatic

1) Create Sales Order – Order Acknowledgment sent to Payer (ZBA2 output type to LSP customer & ZBA1 output type to) and Export Order /Affiliates Order goes to SPEX (SPEX is legacy system for exports maintained owned by Heinz) (ZSPX-Output type)

2) Create Delivery with ref to Order – Delivery (Shipping notification) goes to WEBSPHERE (through EDI medium). ZLR1, ZLR2, and ZLR3 &ZLR4 print uplift notes.

3) WEBSPHERE picks the delivery, do the picking (Packing in empty Handling units) and PGI the deliveries.

4) Invoicing in SAP. (ZRD0 sent the output to EDI Customer, ZRD1 output type prints the Invoice.

REFER TO HEINZ ASCENDANT>CONFIG TREE>SAPR/3 FOR ANY CHANGES

5.3.3 EDI Order Processing:



5.3.4 Normal Order Processing: EDI orders are processed automatically while other than EDI; all orders are entered manually into SAP. These orders are received via FAX, Phone, e-mail and post.

1) Sales Documents Types:

a) ZORS - Standard Order

b) ZAFF - Affiliate Order

c) ZCH - Charity & Donations

d) ZDE - Destruction Order

e) ZSPC- Special Sales

f) ZSD – Short Dated Stock

g) ZEXP - Exports

h) ZSAM - Samples

i) ZSEM – Semi Finished Sales

j) ZRE1 –Returns (Del Based)

k) ZCOS – Cost center sales (its in testing currently in HRY)

l) ZCR – Credit Memo Request

m) ZCRQ- Crédit Mémo Quantity

n) ZDR - Débit Memo Request

o) ZDRQ – Debit Memo Quantity

p) ZSSD – Sample Short Dated


Inbound EDI Order Processing


Sales Process Flows:



ZCOS

Sales to cost centers ZCOS

ZCOS ZB12 For batch Split ZLF8

ZSSD

Sample Short Dated ZSSD

ZSSD ZBA0 for Batch Split ZLF0 ZSSD ZF21 ZSAM01

5.3.4:A.)The detailed document flows including the item categories , schedule line categories, movement types, delivery types, delivery item categories, billing types, billing item



categories, storage locations, financial postings and material types are shown in the AID1.xl. For detailed information at a glance is given for any further information related to any document type in particular has to be referred in Shared Drive:SAP UK>CONFIGURATION DOCUMENTATION>SOP>PROCESS FLOWS AND USAGE.PPT.

AID 1.xls

REFER TO HEINZ ASCENDANT>CONFIG TREE > SAPR/3FOR ANY CHANGES

5.3.5 Details regarding Schedule Line Category:



ZSSD & ZBA0 ZZ-919Sample Short dated incliding batch Split

ZCOS & ZB12 ZG-917Sales to Cost centers including batch Split



REFER TO HEINZ ASCENDANT>CONFIG TREE > SAP R/3 FOR ANY CHANGES

5.3.6 Inter-company Sales: The Customer Orders stock from the Sales Organization (3001/3002), which belongs to Heinz Ireland (3260). The Sales Organization then creates the Sales Order but the delivering plant (3005 Kitt green or 3006 NDC) belongs to Heinz UK ( 3030). Goods are shipped from plant 3006 or 3006 to Irish customer.

The Sales Org. (3001/3002) is defined as customer (101) in SAP invoices the customer (F2 invoice type) for the Materials purchased. The system then automatically creates an inter-company-billing document at the same time as the customer’s billing document is created. This Inter company invoice is sent from the delivering plant to the selling sales organization. This is defined as an INTER COMPANY SALES TRANSACTIONExternal Sales are booked in company code 3260. While company code 3030 booked the Inter company sales.



Please refer to GDA document in Heinz Ascendant.

5.4 Basic functions

5.4.1) Pricing: Pricing Procedures are in used:

ZSTD01 Pricing Procedure: ZPR0 (Heinz List Price) is mandatory Price condition that is always picked up from record.

In SAP system only List Prices (ZPR0) are being maintained rest other discounts/deductions etc come from UNIVERSALL (MEI/TFM). Refer the attached diagram of Interface of MEI with SAP and others.

New Mark up Pricing condition for Affiliates ZPRM


TFM Interface


The fields showing the Value per case (ZPR0) and Mark up per case (ZPRM) should always show per 1, to all three SPEX interfaces. Even it has set up a price per 1000. In that case the calculation will divide by it by 1000 in order to get the correct value in the interface.

Inter company Price condition PI01 is also mandatory. But as the requirement 22 attached to it that takes care that it is mandatory only during Inter company sales.

PRICING PROCEDURE DETERMINATION



REFER TO HEINZ ASCENDANT>CONFIG TREE FOR FURTHER DETAILS (CONDITION TYPES ETC) AND ANY CHANGES

5.4.2 Availability Check and TOR:

1) Requirement Class:

2) Requirement type:

3) Requirement types are attached to require Item Categories and procedure for each schedule line category is defined.



5) Availability Check: Checking groups

Checking groups are assigned to Material Type ‘ZFIN’ against each plant.

Controls of ATP check against Z1 with checking rule 03: Checking rule defines the procedure to be used for ATP check. In SD checking rules are specified internally within the system.



For each requirement class procedure for ATP is defined. Then for each schedule line category also ATP procedure is defined. Final control is from Requirement class while it can be fine tuned at Schedule line level.

5) Availability Check against Product allocation: It allows allocating and controlling goods in short supply early on. During Order Processing, an availability check carried out against product allocations. The result of this check informs whether an order requirement can be confirmed according to product allocated to the customer. More details can be taken from Heinz ascendant. For quick reference document below is attached.



5.A) The standard product allocation functionality already set up in SAP does not totally fulfil the requirements of the business. An alternative approach based on statistical pricing conditions and user exit upon order save has therefore been defined and will be specified in this document. This is fixed under the GAP0035. More details can be taken from Heinz ascendant. For quick reference PAL Config1 is attached.

In the standard Product allocation it has shown only the configuration settings , whereas the Product Allocation Involved in GAP 0035 is what presently used and all the documentation amendments are made with respect to GAP0035 and User exits which are Used in the process.

PAL Config GAP0035.doc

For any reference to issues related to Product allocation Please refer Product allocation with GAP0035

Product allocation is required to work only for UK customer not for Ireland. Presently PAL procedure is general, not specific to any plant or sales organization. Therefore for Materials that are common between UK and Ireland customers, PAL procedures have been setups for both Ireland and UK. Please refer to GAP1081 for further details. This GAP has been raised and yet to be approved.

REFER TO HEINZ ASCENDANT>CONFIG TREE> SAP R/3 FOR FURTHER DETAILS AND ANY CHANGES

5.4.3 Setting required for Dynamic Product Proposal


Product Proposal

PAL Config


Please refer to GDA document in Heinz Ascendant. For quick reference document is attached but for any changes refer to ascendant.

5.4.4 Credit Management

1) Credit Groups

2) Credit Group is then assigned to Sales Document types and delivery types

For further details of Credit Control settings please refer to Heinz Ascendant

FOR OTHER BASIC FUNCTIONS (OUTPUT CONTROL, INCOMPLETION, TEXT CONTROL, ATP BASED ON PRODUCT ALLOCATION) PLEASE REFER TO HEINZ ASCENDANT> CONFIG TREE

5.5 Logistics Execution

1) Shipping Points: 3005(Kitt green), 3006 (NDC) & 3111 (Kammac) are main shipping points for selling. Mostly others are used for FI purpose or reworking.

Shipping points for the plants 3017 ,3028 &3029 are 3017, 3028 and 3029 respectively.



2) Delivery Scheduling: Delivery scheduling takes Pick/Pack times, Loading Times into account. These times are dependent on the Shipping Point that is responsible for delivering the order item. For Kitt green (3005) Factory Calendar is GB and Pick/Pack time, Load time is 0. As Factory Calendar is GB hence good issue is not possible in weekends (Saturday/Sunday). In case of 3006, factory calendar used is ‘W8’ which means goods can be issued even on weekends.

Plant 3029 & 3028 has warehouse managed storage locations. In Plant

3029 finished products, uncrowned & Transfer intermediates are warehouse managed. In Plant 3028 WM is used for raw material handling only.

For STO’s:

Intercompany STO’s takes place automatically between the plants:Aston to Kit green, Aston to NDC , Aston to Telford , Aston to WorcestorWorcestor to Boughey (man)Worcester to Telford, Worcestor to Kitt green, Worcestor to NDC (auto).Telford to NDC (auto)For Sales Orders:To affiliate customers:Worcestor, Aston, Telford through sales area 3030/99/00To Export Orders:Worcestor through sales area 3030/60/00

3) Delivery types and Item categories: As explained in section 5.3.4

As here Warehouse Management and Batch Splitting are extensively used hence delivery processing requires WM knowledge that can be received from WM AID documents and also the process flow is explained in section 5.3.

FOR OTHER BASIC FUNCTIONS (OUTPUT CONTROL, INCOMPLETION, TEXT CONTROL, FOREIGN TRADE DATA ETC) PLEASE REFER TO HEINZ ASCENDANT> CONFIG TREE> SAPR/3



5.6 BILLING

Before creation of Invoice, proof of delivery (VLPOD) is must. Unless customer receives the goods, Invoicing is not allowed.

1) Billing Types: For standard sales order processing invoice type F2 is used. Other Invoice types are:



FOR MORE DETAILS OF BASIC FUNCTIONS (OUTPUT TYPES AND COPY CONTROL ETC) PLEASE REFER TO HEINZ ASCENDANT> CONFIG TREE> SAP R/3

2) Inter company Billing:

2.A) The Updations reflecting additional entries to support phase 2a are enclosed in Intercompany Billing1.Doc.

Apart from the userexits reg GAP1207 , GAP1207 remaining all are the extension of plants.

I intercompany Billing1.doc

FOR MORE DETAILS OF INTER COMPANY BILLING PLEASE REFER TO HEINZ ASCENDANT> CONFIG TREE> SAP R/3, FOR QUICK REFERENCE DOCUMENT IS ATTACHED ABOVE.

5.7 GAPS working while processing ZORS Order type:


Intercompany Billing


1) GAP0035: ZSD_ORDER_CHECKS: This is a report displaying the entire checks take place through this user exit.

A number of checks are carried out when saving a sales order both in order create (VA01) and order change (VA02). This will be obtained via sales order user exit code. They work for both EDI and manually created Sales Orders.The following order checks are carried out:1) All order lines have same shipping point2) Minimum order size is fulfilled (controlled by entries maintained in ZSD_SIZEVAL

table)3) Maximum weight is not exceeded (controlled by entries maintained in

ZSD_SIZEVAL table)4) Maximum number of pallets are not exceeded ((controlled by entries maintained in

ZSD_SIZEVAL table)5) All order lines contains full layers (check condition ZLYR at Condition tab at item

level in Sales Order. It should always be in whole number. )6) All order lines contains full pallets (check condition ZPAL at Condition tab at item

level in Sales Order. It should always be in whole number.)7) No duplicate EPNs exists on order8) The purchase order number is not a duplicate9) The requested delivery date is valid10) All lines are totally confirmed on requested date (ATP Issue /ZPAL)11) No EPNs marked as Product at Risk (ZPAR)12) No EPNs marked for Strategic Automatic Cut (ZSAC)13) The check is active according to the table ZSD_T_UE_ACTIVE for Product

Allocation.

For 1, 11, 9 & 7- these checks are taken place only during ORDER CREATION. Result of that Order gets blocked saying ‘Failed Order Checks. The result of check 12 “No EPNs marked for Strategic Automatic Cut” will influence the other checks since it result in rejected items. Check 12 therefore needs to take place before the other checks.

There are two scenarios where user exit does not take place:1) When Order is incomplete. (Incomplete order has an entry in table VBUV, user exit

check the entry here, if sales order exist, GAP0035 does not trigger else it works)2) If there is a delivery block Z2 in sales order due to Pallet discrepancy. It’s the result of

GAP0015. If there is any other block setup, GAP0035 will work.

Activation Table for Sales Order User Exits: ZSD_T_UE_ACTIVE

When order gets created through EDI and get hold on credit check due to exceeding credit exposure, in such case GAP0035 get by-passed if the transaction is not VA01 or VA02. Since credit release happens in VKM1 or VKM3 the code is not triggered. This has the result that the order does not have block Z3 and that report ZSD_ORDER_CHECKS does not have X in column for ATP failure. This logic has been amended now.



2) GAP0015: Sourcing & Splitting: Automatic Determination of Default Delivery PlantThis GAP0015 required determining default delivery plant in sales order based on following criteria:1) Customer2) Plant3) Product4) Quantity5) Weight6) Number of PalletsIf a sales order is placed for a combination of full pallets AND the product is made at KG AND it is > 18 pallets OR > 12 tonnes AND the customer is defined as accepting goods from Kitt Green, then the plant should be defaulted to Kitt Green, otherwise it should be the NDC.If the customer has correct attribute (KNVV-PRAT4) (It means Customer can take the goods from Kitt Green) and Product has also correct attribute (MVKE-PRAT5) then if other criteria like more than 18 no. Of pallets, Gross weight of order more than 12 tonnes, then this GAP015 gets triggered.

Above flow chart taken from functional Specification of GAP0015 from share drive.



3) GAP0031: Requested Delivery Date and Time

While creating Sales Order, it is a requirement to enter the customer delivery date and time in range. It’s not feasible in SAP standard hence two new fields are created for the date & time range. These fields would be appended to the Order Entry Header Table VBAK and would appear on the Additional data A tab.

A requirement (903) in Delivery copy control allowed to copy requested delivery dates and time from Sales Order in Delivery header that creates Event with the requested delivery date and time range. These dates then get copied from Delivery document to POD document. And if there is any discrepancy found in dates POD it can be overwritten manually in POD document.

4) GAP0040: RFT – ZSD_CUT Report

A user exit code is coded to capture changes to the sales order requested quantity. Whenever there is any change in Sales Order quantity, user has to assign a reason (referred to as “cut type”). The capturing of the changes and the cut type will be obtained via sales order user exit. The changes will be captured in a newly created table (ZSD_CUT).Following types of CUT are being maintained:

- ZZ02 Customer Amendment- ZZ03 Expected Cut - ZZ04 EDI Material Error- ZZ05 Order Split Amendment- ZZ06 Substitution- ZZ07 Planned Cut- ZZ08 Product at Risk- ZZ09 Customer Cancellation

ZSD_CUT report can be displayed and Cut type can be changed to apply explicit cut type (referred as cut reason code). Quantity changes in delivery get stored in same table. This will either be done upon despatch via manual entry and goods issue posting or via the interface sent back from the LSP. User exit code will capture the manual changes. The interface



captures changes made by the LSP. In both cases the information get stored into the same table used for order quantity changes. Any changes in quantities during POD also get stored in table ZSD_CUT. (POD User Exit) Multiple codes can be captured both on lines containing a batch also on batch split lines. Within one batch split lines multiples codes can occur.

ZSD_CUT report is very useful and required for business. For EDI Inbound Orders from Gentran, this report required to get the details of Cut type ‘ZZ01-Not on buying list’ and ‘ZZ04- EDI Material Error’. On daily basis this report is run to get the details of any changes in order quantity.

Interface changes: Any changes stored in failed Idocs will not be recorded in table. Therefore its must to correct the failed Idoc first to get the incorporated in ZSD_CUT report. The logic of user exit never gets triggered when good issue is triggered by the interface.

ZSD_T_UE_QTY_CHG: Cut history Table.

ZSD-CUT report is used to produce report in Business Warehouse in detail and in BW they will also have a 1-2-2 mapping with departmental responsibility.

5) GAP0745: Requirement 900 against condition type ZNCD in Pricing Procedure ZSTD01

This Gap is all about using requirement 900 against condition type ZNCD, which controls that this condition type is getting populated in Sales Order only when Order type is ZSPC (Special sales). As same pricing procedure is used by other order types.

6) GAP0240 &GAP1038: Availability check according to Storage Location Level.

This GAP takes care of automatic population of default storage location at sales order point which cause the availability check at storage location level. It is determined according to sales order type, sales area and plant. It’s always possible to change storage location manually. For default storage location table maintained is ZSD_T_UE_CONV

GAP 1038:User Exit ATP00001 updated with logic to say that when a delivery is created (with or without ATP check) then any subsequent changes to the delivery only triggers an ATP check that is considering stock available. This user exit switch off the ATP while PGI is happening. As physically, stock is available and loaded into the truck also. To avoid Idoc failure during pick/confirm and PGI stage, it is must. Heinz business is continuously running business, where the requirements are to made fast and goods delivery time is maximum 3 days for normal orders and 2/3 weeks for exports. Therefore this logic has been designed and implemented.

Table ZSD_T_GI_ATP is used to control this GAP and this is where the entries for the delivery type are entered.

7) GAP0714: Interface from SAP to ICS NETCENTER.



NETCENTER is a Heinz owned CRM package used by WINCANTON customer services. It holds contact details of customer, product and vendor master data. It also holds the information of any order amendments, stocks, returns, claims, uplifts etc. The interface directly feed into the Net enter with the order and WMS information, while the majority of the customer bible information will be entered directly into new functionality within Net enter that will allow manual system entry & editing.

T-code used: ZICS_ORDERS (It’s scheduled to run in every 15-30 minutes)

Batch Job run in system is: HUK_ORDERS_TO_ICS

8) GAP0276: Report for handling outstanding pickups

ZSD_ORDSTS: The program for this report is ZSD_ORDER_STATUS. This report tells the details of documents status at various stages.Following status have been included:

1) Delivery status ( ,A,B,C) (_ Not relevant, A-Not yet processed, B-Partially Processed, C-Completely Processed)

2) AOD status ( ,A,B,C)3) POD status ( ,A,B,C)4) Billing status ( ,A,B,C)

This report is used by OAK and Ireland (3rd Party Orders) both.

9) GAP0706: Orders to SPEX



Order information is sent to the third party export system SPEX. This include export and affiliate orders as well as credit, debit and return orders.

Data from SAP is converted into XML files and sent to SAP. The information from SAP therefore only needs to be transmitted into the XML adaptor.The XML adaptor is built to receive standard IDOC outputs and it is distribution channel and order type specific. Only export and affiliates customers are interfaced to SPEX. These are identified with sales organisation 3030 and distribution channel (60 (export) & (99) (affiliates)). All sales orders for these sales channels are interfaced. This include following order types:

1) ZEXP – Export orders2) ZAFF – Affiliate orders

E) ZSAM – Sample orders4) ZRE1 – Return orders5) ZCR – Credit memo request6) ZCRQ – Credit memo quantity7) ZDR – Debit memo request8) ZDRQ – Debit memo quantity

The IDOC output trigger automatically upon order creates and order change using output control. Incomplete orders are not interfaced to SPEX. The output type is called ZSPX. The standard sales order IDOC type ORDERS05 is used as a reference.

Order Header Data held in IDOC segment: Z1E1EDK01Order Item Date held in IDOC segment: Z1E1EDP01Extension for pricing header data hold in segment: Z1E1EDK05Extension for Foreign Trade Header Information held in segment Z1E1EDK29Extension for foreign trade items held in segment Z1E1EDP28Extension for material master data held in segment Z1E1EDPM1Extension for address data held in segment Z1E1EDKA1

10) GAP0707: Interface SAP delivery to SPEX

Delivery information sent to SPEX for exports and affiliates customer. This includes both outgoing and return deliveries.

Only deliveries for export and affiliate customers should be interfaced to SPEX. These are identified with sales organisation 3030 and distribution channel 60 (export) or 99 (affiliate). All deliveries for these channels should be interfaced. This includes the following delivery types:ZLF1 – Sample deliveries

ZLF2 – Export deliveries



ZLF3 – Affiliate deliveries

ZLR – Return deliveriesThe IDOC output gets trigger automatically upon goods issue using output control. The interface triggered both when the goods issue manually triggered and when it done by the interface from the LSP. The standard delivery IDOC type DELVRY03 is used.

11) GAP0708: Interface SAP Invoice to SPEX.

Invoice information sent to SPEX for exports and affiliates customer. This includes all kinds of invoices delivery related as well as credit, debit, and return invoicesOnly invoices for export and affiliate customers are interfaced to SPEX. These are identified with sales organisation 3030 and distribution channel 60 (export) or 99 (affiliate). All invoices for these sales channels are interfaced. This includes the following invoice types:

F) F2 – InvoiceG) ZF21 – Sample invoiceH) ZRE – Return invoiceI) G2 – Credit memoJ) L2 – Debit memo

Since the account document number is used as the invoice number, the interface never gets trigger if the account document has not yet been created for the invoice. The IDOC output gets trigger automatically as soon as the document has been released to accounting. This can be achieved with standard SAP output requirements.

Only one invoice ever sent to SPEX. The user should never make any changes to the invoice in SAP and there is therefore no need to send updated data. The IDOC logic is therefore gets issued and IDOC from an invoice automatically only once. The user can resend the IDOC if necessary.

Batch job run to transfer files to SPEX: ZSD_FILES_TO_SPEXBatch job name: HUK_FILES_TO_SPEX

Please refer the diagram below:



K) GAP0783: Formula for PAL:

Requirement for customer number to be masked during updates to the Logistics Information System (PAL Info Structures) has been achieved by creating a new data requirement within LIS.

Using T-code MC1D has created a new requirement 900. Code logic says that: There is a check of Customer against planning hierarchy. If the customer is a part of the hierarchy, figures are attributed to that customer in the Logistics Information System and relevant info structure. If the customer is not listed, the masking code kicks in and the customer is recorded with the masking character established in creating the info structure and planning hierarchy. In this instance, it is ‘+’.

13 GAP0901: ZSD_SUBS (Substitution Report):

A new report ZSD_SUBS has been generated, which captured the details from VB12/VB13. As from VB12/VB13 (Display condition records) we cannot get the details of materials that are being substituted in.This report works for following condition type:

1) Z0012) ZSAC3) ZPAR



L) GAP0942: Report for case per three layers ( used by WINCANTON)

T-CODE used ZSD_ORDERLAYER

This report gives the following details:

1 Customer Name2 Order Date3 Delivery Date4 Order numbers (Customer Order no & Heinz Order no. (sales order))5 Customer number6 Product Code7 Product Description 8 Cases per pallet9 Cases per Layer10 Cases order11 Cases per 3 layer12 Odd cases13 Number of layers

15) GAP0943: Despatch Report

T-CODE : ZSD_DESPATCH

This report provides details of despatched orders: From this report, one can find the discrepancies between despatched quantity and ordered quantity

It gives following details:

1) Delivery’s Item no.

2) Material (EPN)

3) Description of Material

4) Batch code

5) Origin



16) GAP0744: Billing Date & Pricing date :

This GAP tells about the determination of Billing & Pricing dates based on settings within the customer master and the POD relevance of item category.

M) Billing copying routing 901(Delivery to Invoice) has been amended with logic saying:

a) If the customer is marked as POD relevant and item category is POD relevant, billing date is replaced with the POD date.

b) If the customer is POD relevant and item category is not POD relevant,Then GI dates are used as billing date.

c) If the item category is POD relevant, but the customer is not, then the Billing date is Good Issue date.

B) Pricing date: To change pricing date in billing, following logic has been build:In Customer Master data> Extras> Additional Data> Customer Group1If customer group set as ‘o’, it is Order related pricing and if it set as ‘d’, it is delivery related pricing. Only exception here is customer is POD relevant and item category is POD relevant, then the pricing date is set to the POD date.

For Export and Affiliates, item category will never be POD relevant hence even if accidentally customer is created as POD relevant, billing date will be Post goods Issue date only.

17) GAP0759 Interfaces – Actual Shipment to MERCIA

MERCIA requires an extract of data from SAP at the end of each period to show in weekly buckets what has been good issued against sales orders from warehouse. To meet this requirement, an interface is designed which provides a record for each EPN, for each key Account for each week within period. It provide what has been shipped against a customer order rather than what has been against POD (What the customer was promised that is important for forecasting purposes).

This interface is scheduled to run at the end of each fiscal monthly period. The logic of the interface select all those deliveries that have been good issued in the period that has just finished.

T-code used for Mercia extract: Z_EXT_MERCIA



18) GAP0749: Pricing Procedure Determination for document type (ZCR or ZDR)

When creating a pricing adjustment debit or credit (ZCR or ZDR). It is required that SAP determines the pricing procedure so that manually adjustable condition types are available so that manually adjustable condition types are available. The standard Pricing Procedure (ZSTD01-Heinz standard pricing procedure) has been amended so that it is not possible to change the values for SOX reason. Key users only create pricing adjustments and manual pricing is allowed in order to correct pricing errors.

Code has been written that allows the new pricing procedure (ZPCR01) to be determined when creating a ZCR or ZDR with reference to an invoice. It’s working for both Irish Orders and UK orders.

19) GAP1033 ZSD_VA05 Product Supply Report:

A new report has been created which is based upon transaction VA05.

This report details the confirmed and unconfirmed quantities of materials per plant and multiple sales org.

This report is similar to VA05 and this report contains extra functionality as listed below:1) Display column for credit check status and have ability to filter out the credit check status.2) Display column for any products which are on product allocation and have the ability to filter out those items on allocation.

3) Display column for item category to show whether the line has been ZATP’d or not.4) Selection criteria based on multiple sales orgs . 1) to display column for credit check status and to have ability to filter out the credit check status.5) Report can be amended in such a way that open orders right up-to delivery PGI are displayed.

T-Code to be used: ZSD_VA05

For more detailed information refer to Heinz Ascendant.

Path to be followed in Heinz Ascendant: Login to HEINZASCENDANT site http://heinzascendant/ and got tab PORTAL> REPORT V2> REPORT>METHOD REPORT then select the document you are looking for. For various GAPS select GAP and then search accordingly. TPR or PIR can also be searched in same way.

6) FOREIGN TRADE/CUSTOMES:


Foriegn trade Data in SD

http://heinzascendant/


Please refer to Heinz Ascendant for details information:

Path as followed: Heinz Ascendant> Heinz> SAP R/3. For brief over view and quick reference following attached document can be used:

7) OPERATIONS:

7.1) A) Sales Team- Departmental structure (from SAP-SD perspective): This flow chart explains the Key User responsible for various processes in SD.



B)

Data Management Team

Mike O’Sullivan Simon Mullard

For Material Master For Customer Master

For any Master Data related problem, send the email to:

6) “UK DMO Trading Group” [email protected]

7) “UK Oak Data Team” [email protected]

C) For pricing related interface: From SAP to TFM/MEI- following person from Heinz will be responsible:

1) Dan Merryweather

2) Martin Travers.

Contact Details of Key Users mentioned above are:

Name of Responsible Person

E-Mail ID Contact No.

Andy short [email protected] +44 (0) 1472 365054

Chris Barrow [email protected] +44 (0) 1942 624203


DEPARTMENTAL STRUCTURE

SAM PRICE

Marketing

ManagerEXPORTS

CUSTOMER

SERVICE

RETURNS

SAMPLES

ORDERS

EDI PROCES

SINGNigel Baker Chris

BarrowDorothy Woods

Gail jonesChris

Carpenter

Julie Lamex

Tony Whalley

Christine Burton

mailto:[email protected]





Gail Jones [email protected]

Chris Carpenter [email protected]

Julie Lamex

Tony Whalley

Christine Burton [email protected]

Sam Price [email protected] +44 (0) 28 8 2315 +44 (0) 7736

Mike O”Sulivan [email protected] +44 (0) 208 82123 +44 (0) 7963 827

Nigel Baker [email protected] + 44 (0) 1942 65 222

Simon Mullard [email protected] +44 (0) 1942 695

Hazel Blackledge SCM team user for STO. (Stock Transport order)

[email protected] +44 (0) 1942 66 +44 (0) 7736 2

Jill Fenton (Maintaining Security/Authorizations)

[email protected]

Martin Trevers [email protected] +44 (0) +44 (

Dan Merryweather [email protected]

Dorothy woods [email protected] +44 (0) 12 4844

7.2 MONITORING :

Task Name Task Description Action Periodicity

Monitoring processes

Monitoring Remedy system every day to see the Requests assigned. If there will be any Issue, we will receive the mail in lotus notes.

Based on problem, we will advice user for apt action

Daily














Configuration

Make the necessary changes in the Dev. System and move them to Quality for User Testing. After User Acceptance move the same to Production. If its development, approval will be required from Work-stream Lead Sam Price

If an issue demands configuration changes, we will request for Transport Request from work stream lead Andy Short. Create SCR in Ascendant. As required

Development

Get the development changes to be done in development (HRY 025) and moved it to HRY045 for testing. If test passed move to HRS/HRQ and after passed test move it to HRP.

If an issue demands development, Work stream lead will get it approved from PLT and create CRFS in Ascendant.

Documentation

Required documentation in Remedy needs to be completed for moving the transport to HRQ/HRS and HRP systems (Remedy) and Closing the calls.

Put documents in place

As required

b) Security Requirements:

Access to following systems is required to support Heinz SAP SD system –

1. Access to IBM network2. TACACS login ID & Password to access Citrix and then Citrix Login ID and

Password to access Heinz e SNI desktop3. Login ID and Password to access Heinz Remedy System4. Heinz SAP HRY 025 system – Development system5. Heinz SAP HRY 045 system – Development System (Testing Client)6. Heinz SAP HRQ 100/HRS 305 system – Quality system (Testing) 7. Heinz SAP HRP 200 system – Production system

8) APPLICATION HISTORY:

8.1) TYPICAL PROBLEMS

Major Issues/PIRs Resolution Reference for Detailed Information

After delivery is created and GAP1038: Amendment in Refer to Heinz ascendant>



ATP check triggers saying no stock. Stock may be physically present but due to extensive use of non-ATP relevant item category ‘ZATP’, stock has been allocated against those orders.

ATP logic for any changes in deliveries.

User exit ATP0001 says after delivery creation, check the total stock and ignore sales and delivery requirements.

Heinz> GAP1038 and PIR0359, PIR0382

Order is created and goes to Credit Block. Credit block is removed from VKM3 and then it goes to WMS for load planning. When load Id comes back to Sales Order, Credit block again gets triggered.

GAP1035: change in Load ID should not trigger Credit Check

New Risk Category 002 (High Risk Sales Orders is created) which has setting of: ‘Number of days: 3’. This function is used for checking documents that have already been released by a credit representative, but that have subsequently been changed. The system does not carry out another credit check if changed value is not greater than value already approved. And current date is not greater than the original release date plus the number of days specified.

Refer to Heinz ascendant> Heinz> GAP1035 and PIR0256

FOR MORE INFORMATION REFER TO HEINZ ASCENDANT>PORTAL> REPORT Search for different documents (GAPS, PIRs)






Date post:	07-Mar-2018
Category:	Documents
Upload:	ngodan
View:	265 times
Download:	7 times