sample software package enhancement specification

*** Company Name ***

Item Pricing

Functional Specification

Document ID: *** Doc ID ***Version/Release: 1.0

*** Date ***

Copyright

Copyright © *** Date *** , *** Company Name *** This document is unpublished and the foregoing notice is affixed to protect *** Company Name *** in the event of inadvertent publication.

All rights reserved. No part of this document may be reproduced in any form, including photocopying or transmission electronically to any computer, without prior written consent of *** Company Name *** . The information contained in this document is confidential and proprietary to *** Company Name *** and may not be used or disclosed except as expressly authorized in writing by *** Company Name ***.

Trademarks

None.

Other product names mentioned in this document may be trademarks or registered trademarks of their respective companies and are hereby acknowledged.

Revision History

Version/Release Date Description of Revisions

Superseded Deliverables

This document/release supersedes the following deliverables.

Document ID Version/Release

Description

None.

Page i

Table of Contents

1. INTRODUCTION.........................................................................................................................................................

1.1. Scope and Objectives..............................................................................................................................................1.2. Out of Scope Items..................................................................................................................................................1.3. Short-Term Improvements.......................................................................................................................................1.4. Assumptions............................................................................................................................................................

2. APPLICATION MODEL.............................................................................................................................................

2.1. Functional Design Overview...................................................................................................................................2.2. Logical Process Model............................................................................................................................................

2.2.1. On-line Price Entry..........................................................................................................................................2.2.1.1. Customer Deal Add/Update Screen.............................................................................................................................

2.2.1.1.1. Procedural Overview..........................................................................................................................................2.2.1.1.2. Field Definitions.................................................................................................................................................2.2.1.1.3. Processing Logic.................................................................................................................................................2.2.1.1.4. Error Processing/Messages.................................................................................................................................

2.2.1.2. Price Schedule Add/Update Screen.............................................................................................................................2.2.1.2.1. Procedural Overview..........................................................................................................................................2.2.1.2.2. Field Definitions.................................................................................................................................................2.2.1.2.3. Processing Logic.................................................................................................................................................2.2.1.2.4. Error Processing/Messages.................................................................................................................................

2.2.1.3. Broker Deal Screen.....................................................................................................................................................2.2.1.3.1. Field Definitions.................................................................................................................................................2.2.1.3.2. Processing Logic.................................................................................................................................................2.2.1.3.3. Error Processing/Messages.................................................................................................................................

2.2.1.4. Market Add/Update Screen.........................................................................................................................................2.2.1.4.1. Field Definitions.................................................................................................................................................2.2.1.4.2. Processing Logic.................................................................................................................................................2.2.1.4.3. Error Processing/Messages.................................................................................................................................

2.2.1.5. Price Range Add/Update Screen.................................................................................................................................2.2.1.5.1. Field Definitions.................................................................................................................................................2.2.1.5.2. Processing Logic.................................................................................................................................................2.2.1.5.3. Error Processing/Messages.................................................................................................................................

2.2.1.6. Absorbed Charges Add/Update Screen........................................................................................................................2.2.1.6.1. Field Definitions.................................................................................................................................................2.2.1.6.2. Processing Logic.................................................................................................................................................2.2.1.6.3. Error Processing/Messages.................................................................................................................................

2.2.1.7. Product Components Add/Update Screen....................................................................................................................2.2.1.7.1. Field Definitions.................................................................................................................................................2.2.1.7.2. Processing Logic.................................................................................................................................................2.2.1.7.3. Error Processing/Messages.................................................................................................................................

2.2.1.8. Price Testing Screen...................................................................................................................................................2.2.1.8.1. Field Definitions.................................................................................................................................................2.2.1.8.2. Processing Logic.................................................................................................................................................2.2.1.8.3. Error Processing/Messages.................................................................................................................................

2.2.2. Batch Pricing Engine.......................................................................................................................................2.2.2.1. Procedural Overview..................................................................................................................................................2.2.2.2. Processing Logic........................................................................................................................................................

2.2.2.2.1. Error Processing/Messages.................................................................................................................................2.2.3. Menu Navigation..............................................................................................................................................

2.2.3.1. Object Menu...............................................................................................................................................................2.2.3.2. Edit Menu...................................................................................................................................................................2.2.3.3. Report Menu...............................................................................................................................................................2.2.3.4. Action Menu...............................................................................................................................................................

3. BUSINESS TRANSACTIONS......................................................................................................................................

3.1. Summary.................................................................................................................................................................

Page ii

4. LOGICAL DATA MODEL..........................................................................................................................................

4.1. Entity-Relationship Diagram...................................................................................................................................4.1.1. Entity Descriptions...........................................................................................................................................

4.1.1.1. OP_ORDR_HDR........................................................................................................................................................4.1.1.2. OP_ORDR_DTL.........................................................................................................................................................4.1.1.3. OP_CUST_MST.........................................................................................................................................................4.1.1.4. IC_ITEM_MST..........................................................................................................................................................4.1.1.5. SY_USER_FLD..........................................................................................................................................................4.1.1.6. PR_CUSTOMER_DEAL............................................................................................................................................4.1.1.7. PR_SCHEDULE.........................................................................................................................................................4.1.1.8. PR_BROKER.............................................................................................................................................................4.1.1.9. PR_MARKET.............................................................................................................................................................4.1.1.10. PR_PRICE_RANGE.................................................................................................................................................4.1.1.11. PR_ABSORBED_CHARGES...................................................................................................................................4.1.1.12. PR_ITEM_COMPONENTS......................................................................................................................................

5. REPORTS.....................................................................................................................................................................

5.1. Pricing Engine Error Report....................................................................................................................................5.2. Customer Deal Listing.............................................................................................................................................5.3. Price Schedule Listing.............................................................................................................................................5.4. Market Listing.........................................................................................................................................................5.5. Broker Listing.........................................................................................................................................................5.6. Absorbed Charges Listing........................................................................................................................................5.7. Product Component Listing.....................................................................................................................................

6. SECURITY....................................................................................................................................................................

7. CONVERSION PROCEDURES..................................................................................................................................

8. DESIGN CONSIDERATIONS.....................................................................................................................................

9. IMPLEMENTATION CONSIDERATIONS...............................................................................................................

9.1. Hardware/System Software Requirements...............................................................................................................9.2. Training Requirements............................................................................................................................................

Page iii

1. INTRODUCTION

1.1. Scope and Objectives

The Functional Specification defines the logical processing specifications, user interface design, and reports required to perform pricing on sales orders. This Functional Specification is based on the Item Pricing - Requirement Definition (Pricereq.doc) document updated as of *** Date ***. The Functional Specification is used as a logical (or external design) of the pricing application. A Technical Specification will be developed to complete the technical (or internal logic) design of the module. This intent of this document is to inform the users of the planned design for their approval and to provide the technical programming staff a *** Company Name *** approved specification for the technical design. Coding of the Pricing Application will begin after the Technical Specification is reviewed and approved by *** Company Name ***.

This application is intended to be a replacement for the Manufacturing Accounting pricing programs in use today in the legacy IBM environment.

1.2. Out of Scope Items

Listed below are items which will not be included as a design requirement in this document. However, they may be included in the requirements for other applications.

This application will not price orders automatically upon entry of the order. This requirement is deferred per direction from *** Company Name *** Information Services. The reason for this is that the initial and on-going cost of modifying the GEMMS software becomes prohibitive and may void *** Company Name ***’s warranty with Oracle.

There will be no mass update capabilities for changing prices in mass in this release of this application. This has been deferred so that it may be added later.

This application does not include pricing for paying *** Company Name ***’s Producers for the raw milk that it uses in its manufacturing processes. It also will not be used to price any Raw Milk products with the exception of cream and condensed products.

The application will not be used for re-pricing order for the purposes of returned items. All returns will be handled via Oracle Financials A/R.

This application will not handle volume discounts/rebates based on the total order or sales volume with a customer. This requirement is planned to be handled in Oracle A/R invoicing.

1.3. Short-Term Improvements

The following describes things that could be done to speed up the delivery of the software for use by the various *** Company Name *** departments.

Both Southern and North Central Regions could use the GEMMS Sales Order system "as is", if they are willing to enter prices manually using the price override feature for Date of Order sales. For Date Of Ship and Date Of Manufacture products, prices can be entered at billing time into Oracle A/R. Moisture Premium and Cream/Condensed would be calculated manually. The benefit of this interim approach is that *** Company Name ***

Page 1

would not have to wait for the pricing module to be completed to use the majority of GEMMS functions/features.

Broker Commissions will not be automatically entered into the *** Company Name *** Accounting systems.

1.4. Assumptions

These assumptions have been used as the basis of the design for this pricing application. They are critical to the design and may change the scope, schedule, or budget of the application if changed.

Both SR and NC Marketing must document their customers deals and pricing schedules in preparation for testing and conversion into the new application system.

*** Company Name *** will perform the system testing (test plans / scenarios), development of pricing departmental procedures, training and support the application during testing.

All prices set-up based on the Ship-To address in GEMMS.

This pricing application will be run in a batch mode (just like the previous pricing application) to update sales orders that have been shipped prior to passing the shipped orders to Oracle A/R for invoicing.

Broker Commissions and other Absorbed Charges will not be automatically entered into the *** Company Name *** Accounting systems. Reports will be generated to list those totals for entry and management reporting. No history of these charges are to be kept in pricing tables.

Development of reports is primarily a *** Company Name *** responsibility. 8 reports will be designed for this application.

Order line items can have other Ship-to locations, but the Bill-to location is the same as on the Order Header.

Orders may have multiple shipment drops on the same order, but the billing address will be the same for the many ship locations.

*** Company Name *** has available Oracle Forms versions 3.0/4.5, Oracle Reports versions 2.0/2.5, and DBMS 7.1.6.

*** Company Name *** has available the following languages HP C++ version B.10.20.00, HP COBOL/UX version B.11.25, and HP xdb Debugger for C++ and COBOL.

When deleting records they will be logically deleted, not physically. Records will never be really deleted, unless of course *** Company Name *** writes a program to delete these records.

A locking mechanism will be used to prevent multiple updates from occurring at the same time.

A single order is used for one shipment and creates one invoice. The order will be for one (business) product line type (e.g., cheese vs. NFDM vs. Cream/Condensed vs. Butter).

Page 2

Order sales volume discounts will be calculated manually and entered as a line item on the sales order using non-inventory items in the Item Master "e.g., Discounts".

Page 3

2. APPLICATION MODEL

2.1. Functional Design Overview

The application will provide for the entry of pricing parameters (deals/schedules) via an on-line screen. The pricing parameters will be stored in a set of Oracle relational tables (external to GEMMS) that will be used to calculate and update the GEMMS Sales Orders. The deal/schedule and the special market date will be entered on the sales order prior to pricing the order.

A batch pricing application will be run to update the GEMMS Sales Order Detail table with the item prices. The batch pricing routine will price sales orders after lots have been selected so that the exact pounds/units shipped are used by the pricing engine to calculate the item’s price. It will be run just prior to running the Oracle A/R - Auto Invoice function which pull orders to be invoiced.

The functional design of the pricing application system is an on-line entry and batch update design that populates the existing GEMMS sales order tables (not the GEMMS pricing tables). This pricing application will replace the existing functionality used today within the Manufacturing Accounting System (program CB335) for billing. The system flow is as follows:

Page 4

2.2. Logical Process Model

This section provides a description of the logical structure and function of the Item Pricing application. The functional decomposition below defines the breakdown of the functions of the application. The pricing application is composed of two main functions - On-line Price Entry and Batch Price Engine. This is not to be confused with the Sales Order Entry which is separate. The diagram below defines the functions necessary to set-up a deal or schedule’s item prices.

2.2.1. On-line Price Entry

Used to define a customer’s deal or schedule, markets, price ranges, charges, components, and brokers deals used to calculate the price for a specific sales order line item. Any and all of

Page 5

these screens may be used to define pricing. This application has been design to allow maximum flexibility for the diverse pricing methods that each *** Company Name *** region employs to calculate a single item price. The purposes of the primary screens are listed below.

Price Testing Facility

Used to Test the Deals or Schedules that have been set-up. It is a test facility for testing to see if the correct price was calculated by the pricing application before it is used on real sales orders. This test facility basically sums up what was entered and displays the item price on the Price Testing Screen.

Customer Deals (overages)

Used to enter and maintain a customer’s deals. This is where deals would be entered into the pricing application. Each deal may include the Mkt. Bill Basis, Market, Items, Price Ranges, Absorbed Charges, Billing Method Code (for moisture premium), and Product Component Billing. These items included in the deal are associated with the items on the deal. A deal may use a schedule to obtain the price for an item on the sales order if it is not on the deal. Each customer must have a Deal and a price for the items on the deal (overage).

Price Schedules (overages)

Used to enter and maintain a price schedule. This is where schedules would be entered into the pricing application. Each schedule may include the Mkt. Bill Basis, Market, Items, Price Ranges, Absorbed Charges, Billing Method Code (for moisture premium), and Product Component Billing. These items included in the schedule are associated with the items on the schedule.

Broker Deal

Used to enter and maintain a deal with a broker. This data is associated to the deal. Each broker is related to a specific customer and has an identified list of products that broker commissions are calculated on. The brokerage is associated to the deal items. This is optional.

Market

Used to enter and maintain market data used by the deal or schedule. This data used by the deal or schedule to calculate the market component of the overall price. The market is identified by a market code and keeps period by period lists of the market price, price per UOM, and its effective date. This is optional.

Price Range

Used to enter and maintain prices range for the deal or schedule. This is the definition of the price breaks given for higher quantity volume purchases. The price range provides the overage of the products and allows quantity breaks to be entered at defined levels. The defined breaks will have a price differential that will be added to the price if it applies. These price differentials can be positive or negative. The negative differential will provide a discount for defined breaks above a specified purchase level. This is optional.

Absorbed Charges

Page 6

Used to enter and maintain charges which will be absorbed into the item price. This is used by the deal or schedule. These are the charges that will be paid for by *** Company Name *** and included in the price for a product. They do not include charges that the customer will pay for. The charges that a customer will pay for are handled as a separate line item on the sales order. This is optional.

Component Pricing

Used to enter and maintain the special product components that will be used to price specific items. These components are for such products as cream and condensed where prices are based off of how much butterfat or solids non-fat a product may have. For example, butterfat is measured in percent by a quality test and recorded with the data about the manufactured lot. This percentage is multiplied by the product pounds ordered/shipped giving the butterfat pounds. The butterfat pounds are in turn multiplied by the price per pound giving the item price for the order. This is optional.

Page 7

2.2.1.1. Customer Deal Add/Update Screen

1 2 3 4 5 6 7 812345678901234567890123456789012345678901234567890123456789012345678901234567890

Customer Deal Add/Update ScreenObject Edit View Report Action Help Menu=F1

(Update)Deal Number: D00000001 COMERCIALIZADORA DEALOrganization: 02 Southern RegionCustomer #: 19660 COMERCIALIZADORAMkt. Bill Basis: O Order DateEffective Date: Strt: 11/22/1996 End: 12/31/1996

Market: CWHEY 00.2011 LB Strt: 11/25/199 End: 12/01/1996Item #: 5000000 WHEY, NON HYG SPRAY DRIED, , 25KG 00.0050 LB

500K000 WHEY, NON HYG SPRAY DRIED, , 25KG BAG 00.0052 LB503K000 WHEY, NON HYG SPRAY DRIED, HF, 25KG 00.0054 LB510K000 WHEY, PROTEIN CONC, FOOD GRADE, 25KG BAG 00.0055 LB5230000 WHEY, SPRAY DRIED,ANIMAL FEED , 250LB BBL 00.0250 BBL

Price Schedule #: 00000001 Whey Price SchedulePrice Range #: 00000001 QUANTITY BREAKS FOR NFDM PRODUCTSAbsorbed Charge #: 00000001 STANDARD CHARGES FOR NFDM PRODUCTSBroker #: 12345678 ABC Brokerage InternationalBilling Meth. Code: Premium %: 39Component Billing NRemarks:Instructions:

Changed: Schulbas 11/25/1996 10:15:31Message Line12345678901234567890123456789012345678901234567890123456789012345678901234567890

1 2 3 4 5 6 7 8

Purpose: For entry of a customer’s deal. Many deals may be entered for that customer, but only one may be used to price a specific sales order’s items.

Legend: Fields in Italics are enterable fields; Bold fields are descriptive fields; Non-bold fields are display fields

NOTE: Data represented on this screen is for purposes of illustrating pricing functionality and will not represent all pricing scenarios. Also, this screen may be modified during actual development to accommodate a more efficient design.

2.2.1.1.1. Procedural Overview

The following procedure flow describes the steps involved in completing the definition of a deal with a customer. It illustrates all the decision points required for the deal definition.

Page 8

2.2.1.1.2. Field Definitions

Page 9

The following fields will be used by the program that processes the data on the screen.

Deal Number - is the auto-generated number for each of the deals entered.Organization - is the number of the *** Company Name *** Organization that the sales order will be generated by. It is the same as the GEMMS Organizations. The same GEMMS tables will be used to validate this number.Customer # - is the GEMM customer number and description.Mkt. Bill Basis - is the basis (order, ship or manufacture date) that pricing will use to find the correct effective dated period within the market.Effective Date - is the date that this record begins and ends its effectively.Price Schedule # - is the number of the price schedule that applies to this specific deal.Market - is the name of the market which applies to this schedule.Items # - is the scrollable list of the items and their overage that apply to this schedule. As many items as needed can be entered. There is no restriction to how many may be entered. The items are GEMMS item numbers and descriptions coming from GEMMS tables.Price Range # - is the number of the price range with applies to this deal.Absorbed Charge # - is the list of charges which apply to this specific deal.Broker # - is the number of the broker that applies to this deal.Billing Meth. Code - specifies the method for calculating the moisture premium and its calculation percentage denominator.Component Billing - is the field that specifies whether there will be pricing for product components.Remarks - is the field that contains any remarks that should be put on the sales order/invoice.Instructions - is the free form text field that contains instructions for how the prices were set-up.Changed - contains the user id and the date and time that the change to the record took place. This field is display only. It uses the user's id and the system date and time for its source.Message Line - is the line that messages will be displayed in, if there are any.

2.2.1.1.3. Processing Logic

The following logic will be used by the program that processes the data on the deal screen.

1) Enter deal number and description. If existing deal number is entered, then display deal description and all deal information. Validate deal number against deal table.

2) Enter Organization number, validate organization number against GEMMS organization table, and display organization name.

3) Enter customer number, validate customer number against GEMMS customer table, and display customer bill-to name

4) Enter mkt. bill basis, validate mkt. bill basis code as being O (date of order) S (date of ship) M (date of manufacture), and display mkt. bill basis description for selected code.

5) Enter effective date, validate effective date as being greater than today’s date. Do not allow entry/change of past effective dated periods.

6) Enter price schedule number, validate price schedule number against price schedule table, and display price schedule description.

7) Enter market, validate market name against the market table, and display market price, unit of measure and effective dates.

8) Enter item number, validate item numbers against the GEMMS Item Master table, and display item descriptions, enter unit price and price UOM. Continue to enter all items on deal until complete.

Page 10

9) Enter price range #, validate price range number against the price range table, and display price range description.

10) Enter absorbed charge number, validate absorbed charge number against the absorbed charge table, and display absorbed charge description.

11) Enter broker number, validate broker number against the broker table, and display broker number description.

12) Enter billing method code (moisture premium calculation method), validate billing method code against the billing method code table. Enter premium, validate premium between a valid range of values.

13) Enter component billing, validate as Y (yes) or N (no).14) Enter remarks, no validation.15) Enter instructions, no validation. 16) Display the logon id, date, and time of who entered or last changed the information.

2.2.1.1.4. Error Processing/Messages

The following messages will be displayed by the program that processes the data on the screen. The following error messages will be displayed whenever the logic fails. The numbers correspond to the previous logic section.

1) INVALID DEAL NUMBER.2) INVALID ORGANIZATION NUMBER.3) INVALID CUSTOMER NUMBER.4) INVALID MKTT BILL BASIS.5) INVALID EFFECTIVE DATE MUST BE GREATER THAN TODAY’S DATE.6) INVALID PRICE SCHEDULE NUMBER.7) INVALID MARKET NAME.8) INVALID ITEM NUMBER.9) INVALID PRICE RANGE NUMBER.10) INVALID ABSORBED CHARGE NUMBER.11) INVALID BROKER NUMBER.12) INVALID BILLING METHOD CODE MUST BE BETWEEN A VALID RANGE.

2.2.1.2.

Page 11

Price Schedule Add/Update Screen

1 2 3 4 5 6 7 812345678901234567890123456789012345678901234567890123456789012345678901234567890

Price Schedule Add/Update ScreenObject Edit View Report Action Help Menu=F1

(Update)Price Schedule # S0000001 Whey Price ScheduleOrganization: 02 Southern RegionMkt. Bill Basis: O Order DateEffective Date: Strt: 11/231996 End: 12/31/1999 Inactive: N

Market: CWHEY 00.2011 LB Strt: 11/25/199 End: 12/01/1996Item #: 5000000 WHEY, NON HYG SPRAY DRIED, , 25KG 00.0051 LB

500K000 WHEY, NON HYG SPRAY DRIED, , 25KG BAG 00.0053 LB503K000 WHEY, NON HYG SPRAY DRIED, HF, 25KG 00.0055 LB510K000 WHEY, PROTEIN CONC, FOOD GRADE, 25KG BAG 00.0060 LB5230000 WHEY, SPRAY DRIED,ANIMAL FEED , 250LB BBL 00.0300 BBL

Price Range #:Absorbed Charge #:Components NMoisture Premium Factor: 61Remarks:Instructions:


1 2 3 4 5 6 7 8

Purpose: For entry of the price schedule that may apply to one or many customers. The intent of a price schedule is that it is a general price list for many customers. It allows the entry of many items as necessary.



2.2.1.2.1. Procedural Overview

Page 12

The following procedure flow describes the steps involved in completing the definition of a schedule for use by the many customers that it may be applied to. It illustrates all the decision points required for the schedule definition.

Page 13



Price Schedule # - is the auto-generated number for each of the schedules entered.Organization - is the number of the *** Company Name *** organization that the sales order will be generated by. It is the same as the GEMMS Organizations. The same GEMMS tables will be used to validate this number.Mkt. Bill Basis - is the basis (order, ship or manufacture date) that pricing will use to find the correct effective dated period within the market.Effective Date - is the date that this record begins and ends its effectively.Market - is the name of the market which applies to this scheduleItems # - is the scrollable list of the items and their overage that apply to this schedule. As many items as needed can be entered. There is no restriction to how many may be entered. The items are GEMMS item numbers and descriptions coming from GEMMS tables.Price Range # - is the number of the price range with applies to this schedule.Absorbed Charge # - is the list of charges which apply to this specific schedule.Billing Meth. Code - specifies the method for calculating the moisture premium and its calculation percentage denominator.Remarks - is the field that contains any remarks that should be put on the sales order/invoice.Instructions - is the free form text field that contains instructions for how the prices were set-up.Changed - contains the user id and the date and time that the change to the record took place. This field is display only. It uses the user's id and the system date and time for its source.Message Line - is the line that messages will be displayed in, if there are any.


The following logic will be used by the program that processes the data on the schedule screen.

1) Enter schedule number and description. If existing schedule number is entered, then display schedule description and all schedule information. Validate schedule number against schedule table.

2) Enter organization number, validate organization number against GEMMS organization table, and display organization name.

3) Enter mkt. bill basis, validate mkt. bill basis code as being O (date of order) S (date of ship) M (date of manufacture), and display mkt. bill basis description for selected code.


5) Enter market, validate market name against the market table, and display market price, unit of measure and effective dates.

6) Enter item number, validate item numbers against the GEMMS Item Master table, and display item descriptions, enter unit price and price UOM. Continue to enter all items on deal until complete.

7) Enter price range #, validate price range number against the price range table, and display price range description.

8) Enter absorbed charge number, validate absorbed charge number against the absorbed charge table, and display absorbed charge description.

Page 14

9) Enter billing method code (moisture premium calculation method), validate billing method code against the billing method code table. Enter premium, validate premium between a valid range of values.

10) Enter component billing, validate as Y (yes) or N (no).11) Enter remarks, no validation.12) Enter instructions, no validation.13) Display the logon id, date, and time of who entered or last changed the information.


The following messages will be displayed by the program that processes the data on the schedule screen. The following error messages will be displayed whenever the logic fails. The numbers correspond to the previous logic section.

1) INVALID SCHEDULE NUMBER.2) INVALID ORGANIZATION NUMBER.3) INVALID MKTT BILL BASIS.4) INVALID EFFECTIVE DATE MUST BE GREATER THAN TODAY’S DATE.5) INVALID MARKET NAME.6) INVALID ITEM NUMBER.7) INVALID PRICE RANGE NUMBER.8) INVALID ABSORBED CHARGE NUMBER.9) INVALID COMPONENT CODE.10) INVALID BILLING METHOD CODE OR PERCENT, MUST BE BETWEEN A VALID

RANGE.

2.2.1.3.

Page 15

Broker Deal Screen

1 2 3 4 5 6 7 812345678901234567890123456789012345678901234567890123456789012345678901234567890

Broker Deal Add/Edit ScreenObject Edit View Report Action Help Menu=F1

(Update)Organization: 02 Southern RegionBroker #: 12345678 ABC Brokerage InternationalCustomer #: 19660 COMERCIALIZADORAEffective Date Start: 11/22/1996 End: 12/31/1996

Item # Description Price Per Price or %209K000 WHEY, EXGR LOW HEAT USDA CERT LB 00.0055500K000 WHEY, NON HYG SPRAY DRIED, , 25KG LB 00.0050512K000 WHEY, PROTEIN CONC, AMIMAL GRADE LB 00.0040


1 2 3 4 5 6 7 8

Purpose: For entry of the Brokers and the customers that their deals are for. It allows the scrollable entry of as many items as necessary for that broker.





Page 16

Organization - is the number of the *** Company Name *** organization that the sales order will be generated by. It is the same as the GEMMS Organizations. The same GEMMS tables will be used to validate this number.Broker # - is the auto-generated number for each of the schedules entered.Customer # - is the GEMMS customer number. It will use the GEMMS Effective Date - is the date that this record begins and ends its effectively.Items # - is the scrollable list of the items and their overage that apply to this schedule. As many items as needed can be entered. There is no restriction to how many may be entered. The items are GEMMS item numbers and descriptions coming from GEMMS tables.Changed - contains the user id and the date and time that the change to the record took place. This field is display only. It uses the user's id and the system date and time for its source.Message Line - is the line that messages will be displayed in, if there are any.


The following logic will be used by the program that processes the data on the broker screen.


2) Enter broker number and description. If existing broker number is entered, then display broker description and all broker information. Validate broker number against broker table.



5) Enter item number, validate item numbers against the GEMMS Item Master table, and display item descriptions, enter price UOM and unit price. Continue to enter all items on broker deal until complete.

6) Display the logon id, date, and time of who entered or last changed the information.


The following messages will be displayed by the program that processes the data on the broker screen. The following error messages will be displayed whenever the logic fails. The numbers correspond to the previous logic section.

1) INVALID ORGANIZATION NUMBER.2) INVALID BROKER NUMBER.3) INVALID CUSTOMER NUMBER.4) INVALID EFFECTIVE DATE MUST BE GREATER THAN TODAY’S DATE.5) INVALID ITEM NUMBER.

2.2.1.4.

Page 17

Market Add/Update Screen

1 2 3 4 5 6 7 812345678901234567890123456789012345678901234567890123456789012345678901234567890

Weekly Market Codes/Price Maintenance ScreenObject Edit View Report Action Help Menu=F1

(Update)Organization: 02 Desc: Southern RegionMarket Code: CWHEY Desc: Central Whey Market

Mkt. Price Price Per Market Date-Strt/End00.2011 LB 11/25/1996 12/01/199600.2013 LB 11/18/1996 11/24/199600.2014 LB 11/11/1996 11/17/199600.2010 LB 11/04/1996 11/10/199600.2011 LB 10/28/1996 11/03/199600.2018 LB 10/21/1996 10/27/199600.2019 LB 10/14/1996 10/20/199600.2017 LB 10/07/1996 10/13/199600.2015 LB 09/30/1996 10/06/199600.2011 LB 09/23/1996 09/29/199600.2013 LB 09/16/1996 09/22/199600.2011 LB 09/09/1996 09/15/199600.2021 LB 09/02/1996 09/08/1996


1 2 3 4 5 6 7 8

Purpose: For the entry of the Markets effective for a specific period or duration. This list will scroll up and down for as many periods that have been entered.





Page 18

Organization - is the number of the *** Company Name *** organization that the sales order will be generated by. It is the same as the GEMMS Organizations. The same GEMMS tables will be used to validate this number.Market - is the name and the description of the market which applies to this schedule.Mkt. Price - is the current price offered by the market for the effective market date entered.Price Per - is the unit of measure of the market.Market Date-Strt/End - is the effective date of the market. It is the date it begins and the date it ends. These must be current.Changed - contains the user id and the date and time that the change to the record took place. This field is display only. It uses the user's id and the system date and time for its source.Message Line - is the line that messages will be displayed in, if there are any.


The following logic will be used by the program that processes the data on the weekly market codes screen.1) Enter organization number, validate organization number against GEMMS organization table, and

display organization name.2) Enter market code and description. If there is an existing market name validate against the market

table, and display market description, market price, unit of measure and effective dates.3) Enter market price.4) Enter Price Per (the unit of measure that the market is quoted in).5) Enter effective date, validate effective date as being greater than today’s date. Do not allow

entry/change of past effective dated periods.



1) INVALID ORGANIZATION NUMBER.2) INVALID MARKET NAME.

5) INVALID EFFECTIVE DATE MUST BE GREATER THAN TODAY’S DATE.

2.2.1.5.

Page 19

Price Range Add/Update Screen

1 2 3 4 5 6 7 812345678901234567890123456789012345678901234567890123456789012345678901234567890

Price Range Add/Update ScreenObject Edit View Report Action Help Menu=F1

(Update)Organization: 02 Southern RegionRange #: 00000001 Desc: QUANTITY BREAKS FOR NFDM PRODUCTSEffective Date - Strt: 11/22/1996 End: 12/31/1996

Overage: Break Qty Price Differential (add-on)1 00.0050

10000 00.000050000 -00.0010


1 2 3 4 5 6 7 8

Purpose: For the entry of price ranges (price breaks) that the deal or schedule will offer. One or many price ranges may be entered. If there is only one price and no breaks then enter the price as break qty of 1 and price differential (overage) of X.





Page 20

Organization - is the number of the *** Company Name *** organization that the sales order will be generated by. It is the same as the GEMMS Organizations. The same GEMMS tables will be used to validate this number.Range # - is the price break range number for each of the ranges entered.Effective Date - is the date that this record begins and ends its effectively.Overage - defines the Break Qty and the Price Differential or add-on to the deal or schedule. The Break Qty is the quantity break based on the quantity of the goods ordered (not shipped). The Price Differential is the amount added or subtracted from the deal or schedule price. The Price Differential is based on the quantity ordered.Changed - contains the user id and the date and time that the change to the record took place. This field is display only. It uses the user's id and the system date and time for its source.Message Line - is the line that messages will be displayed in, if there are any.


The following logic will be used by the program that processes the data on the screen.


2) Enter range #, validate price range number against the price range table. If it already exists then display price range description and all price range data.


4) Enter Break Qty and Price Differential (add-on price). Continue until there are no more.5) Display the logon id, date, and time of who entered or last changed the information.



1) INVALID ORGANIZATION NUMBER.2) INVALID PRICE RANGE NUMBER.3) INVALID EFFECTIVE DATE MUST BE GREATER THAN TODAY’S DATE.

2.2.1.6.

Page 21

Absorbed Charges Add/Update Screen

1 2 3 4 5 6 7 812345678901234567890123456789012345678901234567890123456789012345678901234567890

Absorbed Charge List Add/Update ScreenObject Edit View Report Action Help Menu=F1

(Update)Absorbed Charges: 00000001 STANDARD CHARGES FOR NFDM PRODUCTSOrganization: 02 Southern RegionEffective Date Strt: 11/22/1996 End: 12/31/1996

Absorbed Charges Price Price PerPromotion -00.0002 LBPallets 00.0036 LBFreight 00.0014 LBSpoilage 00.0000 LBOther 00.0000 LB


1 2 3 4 5 6 7 8

Purpose: For entry of the charges which will be absorbed into the item price. These charges will be included in the price of an item. This is not the same as a sales order line item charge ("Freight) that a customer would pay *** Company Name *** for.





Page 22

Absorbed Charges - is the number and description of the list of charges which relate to the particular deal or schedule.Organization - is the number of the *** Company Name *** organization that the sales order will be generated by. It is the same as the GEMMS Organizations. The same GEMMS tables will be used to validate this number.Effective Date - is the date that this record begins and ends its effectively.Absorbed Charges - include the Price and the unit of measure that the charges are based on. The price is the price of the charge and the unit of measure is the unit that the charge will be calculated in.Changed - contains the user id and the date and time that the change to the record took place. This field is display only. It uses the user's id and the system date and time for its source.Message Line - is the line that messages will be displayed in, if there are any.



1) Enter absorbed charges number and description. If existing absorbed charges number is entered, then display absorbed charges description and all absorbed charges information. Validate absorbed charges number against absorbed charges table.



4) Enter absorbed charge description, enter unit price and price UOM. Continue to enter all absorbed charges until complete.

5) Display the logon id, date, and time of who entered or last changed the information.



1) INVALID ABSORBED CHARGES NUMBER.2) INVALID ORGANIZATION NUMBER.3) INVALID EFFECTIVE DATE MUST BE GREATER THAN TODAY’S DATE.

2.2.1.7.

Page 23

Product Components Add/Update Screen

1 2 3 4 5 6 7 812345678901234567890123456789012345678901234567890123456789012345678901234567890

Components Add/Update ScreenObject Edit View Report Action Help Menu=F1

(Update)Organization: 02 Southern RegionItem #: 000000031 BLENDCustomer #:Effective Date Start: 11/22/1996 End: 12/31/1996

Component Name Price Price PerSOLIDS NON-FAT 1.35 SNLBBUTTER FAT 1.57 BFLB


1 2 3 4 5 6 7 8

Purpose: For entry of components and the unit of measure that these components will use to calculate the item price. Multiple components may be entered for a single item.



Possible Component Names: WheyCream Permeate Sweet Protein Degrade SkimCondensed Blend

Page 24

Regular Butterfat Whey Solids Non-Fat


Organization - is the number of the *** Company Name *** organization that the sales order will be generated by. It is the same as the GEMMS Organizations. The same GEMMS tables will be used to validate this number.Items # - is the scrollable list of the items and their overage that apply to this schedule. As many items as needed can be entered. There is no restriction to how many may be entered. The items are GEMMS item numbers and descriptions coming from GEMMS tables.Customer #: is the customer who might have a special deal with *** Company Name ***.Effective Date - is the date that this record begins and ends its effectively.Component Name - include the Price and the unit of measure that the charges are based on. The price is the price of the charge and the unit of measure is the unit that the charge will be calculated in.Changed - contains the user id and the date and time that the change to the record took place. This field is display only. It uses the user's id and the system date and time for its source.Message Line - is the line that messages will be displayed in, if there are any.




2) Enter item number, validate item numbers against the GEMMS Item Master table, and display item descriptions.



5) Enter component Name, Price, and Price Per. Validate Price Per as either SNLB or BFLB.6) Display the logon id, date, and time of who entered or last changed the information.



1) INVALID ORGANIZATION NUMBER.2) INVALID ITEM NUMBER.3) INVALID CUSTOMER NUMBER.4) INVALID EFFECTIVE DATE MUST BE GREATER THAN TODAY’S DATE.5) INVALID PRICE PER CODE MUST BE SNLB OR BFLB.

2.2.1.8.

Page 25

Price Testing Screen

1 2 3 4 5 6 7 812345678901234567890123456789012345678901234567890123456789012345678901234567890

Price Test ScreenObject Edit View Report Action Help Menu=F1

(Update)Organization: 02 Southern RegionCustomer #: 19660 COMERCIALIZADORAItem #: 500K000 WHEY, NON HYG SPRAY DRIED, , 25KGDeal Number: 00000001 COMERCIALIZADORA DEAL

Qty Ship Per Mkt. Date Moisture BF SNFOrder Entry: 100000 EA 12/20/96 39

Pricing Components UsedMarket: CENTRAL WHEY 00.2011 LB Market Bill Basis OPrice Schedule: 00.0050 LBPrice Range: 00.0000 LBAbsorbed Charges: 00.0048 LBMoisture Factor: 61 00.0000 LBBrokerage: 00.0050 LBComponents: 00.0000Total Calculated Item Price: 00.2159 LB


1 2 3 4 5 6 7 8

Purpose: For testing the deal or schedule that has been set-up. The item price will be calculated just as it would for a customer’s sales order.




Organization - is the number of the *** Company Name *** organization that the sales order will be generated by. It is the same as the GEMMS Organizations. The same GEMMS tables will be used to validate this number.Customer # - is the GEMM customer number and description.Item # - is the items and their overage that apply to this deal or schedule.

Page 26

Deal Number - is the entered number for deal to be tested.Order Entry - includes the Qty, Ship Per, Moisture, BF, SNF. The Qty is the quantity to be tested. Moisture is the moisture percentage of the quality test of the product. The BF is the butter fat percentage of the quality test. The SNF is the solids non-fat percentage of the quality test of the product.Market - is the name of the market which applies to this schedule.Mkt. Bill Basis - is the basis (order, ship or manufacture date) that pricing will use to find the correct effective dated period within the market.Price Schedule # - is the number of the price schedule that applies to this specific deal.Price Range # - is the number of the price range with applies to this deal.Absorbed Charge # - is the list of charges which apply to this specific deal.Moisture - is the moisture percentage of the quality test. This is a test percentage and price only.Broker # - is the number of the broker that applies to this deal.Billing Meth. Code - specifies the method for calculating the moisture premium and its calculation percentage denominator.Component Billing - is the field that specifies whether there will be pricing for product components.Remarks - is the field that contains any remarks that should be put on the sales order/invoice.Instructions - is the free form text field that contains instructions for how the prices were set-up.Changed - contains the user id and the date and time that the change to the record took place. This field is display only. It uses the user's id and the system date and time for its source.Message Line - is the line that messages will be displayed in, if there are any.





3) Enter item number, validate item numbers against the GEMMS Item Master table, and display item descriptions.

4) Enter deal number and description. If existing deal number is entered, then display deal description and all deal information. Validate deal number against deal table.


6) Display market price, unit of measure and effective dates.7) Display mkt. bill basis description for selected code.8) Display price schedule number, validate price schedule number against price schedule table, and

display price schedule description.9) Display appropriate price range price.10) Display absorbed charge total (rolled-up) price.11) Display billing method total price.12) Display total broker item charge price.13) Display component billing total item price.14) Total up and display all the pricing components.15) Display the logon id, date, and time of who entered or last changed the information.

Page 27



1) INVALID ORGANIZATION NUMBER.2) INVALID CUSTOMER NUMBER.3) INVALID ITEM NUMBER.4) INVALID DEAL NUMBER.5) INVALID EFFECTIVE DATE MUST BE GREATER THAN TODAY’S DATE.6) INVALID BILLING METHOD CODE MUST BE BETWEEN A VALID RANGE.

2.2.2.

Page 28

Batch Pricing Engine

The batch pricing engine calculates the sales order item prices based on the pricing parameters entered via the On-line Price Entry Screens.

2.2.2.1. Procedural Overview

The general flow used in calculating the item price for a single line item on an order is: Read Sales Order Get Customer Deal or Get Price Schedule off of sales order in User Defined Class 1 Get Special Market Date off of sales order in User Defined Class 2, if applicable Get Market, if applicable Get Price Range If sales order item not found in deal, Get Price Schedule Get Absorbed Charges, if applicable Calculate Moisture Premium, if applicable Get Product Component Pricing, if applicable Get Broker Commission, if applicable Sum up pricing components and update sales order with item price

2.2.2.2. Processing Logic

The following logic will be used by the pricing engine program. This logic begins when an entered order has a deal or schedule defined for it and it will be run after the order has been shipped. The pricing will occur before the order is selected for invoicing by the Oracle Accounts Receivable AutoInvoicing function. Therefore, all orders presented to A/R for invoicing will already have all the items priced according to the pricing specifications entered by the *** Company Name *** user department into the pricing application. This means that prices should not have to be manipulated at invoicing time, unless there was a user error or programmatic error introduced into the pricing application. Refer to the diagram in Section 2.1 for an illustration of when the pricing will be performed.

1) On the sales order user defined fields, get the deal/schedule number and search the deal first and then the schedule next to validate and get the deal/schedule. The pricing engine will use any number which is valid for a deal or schedule. On the sales order user defined fields, get the special market date. The special market date is used in place of the Date of Order, Date of Ship, or Date of Manufacture in determining which market to use.

2) If it is a Deal, then the deal is summed up for the item number being priced. The Price Engine works in the same manner that the Price Test screen works. Both the deal and the schedule contain the same information (except broker) and function the same manner. For the purposes of explaining the logic, we will use a deal to explain the process.

A) Get the Deal data: read the Organization to verify that it applies to the order being processed, validate the Customer # corresponds to the order being processed, and validate the Effective Date: Start End. The Order Date from the sales order must fall within the Effective Dates of the Deal else a error message will be printed on the Pricing Error Report and this Sales Order will not be priced. The error must be corrected before the Pricing Engine is run again.

Page 29

B) Get the Market data for the deal: The market code is used to look up the market data. The market data is validated using the Mkt Effective Date. The effective date must be current else an error will be generated. This means that the Market effective date using the Mkt. Bill Basis specified in that deal for that customer must find a current Market record. If the Mkt. Bill Basis is "O" then use the Order date from the Sales Order. If the Mkt. Bill Basis is "S" then use the Ship Date from the Sales Order to look up the market. If the Mkt. Bill Basis is "M" use the date that the product was manufactured to look up the market. The date of manufacture will be parsed out of the product Lot Date. Parsing of the date is the only way that the true Date Of Manufacture can be determined.

C) If there are Items entered in the deal, get the appropriate items. There is usually one but there may be more than one. Items in a deal are optional. A deal does not have to have any items and can refer to a price schedule for its items.

D) If there is a Price Schedule entered in the deal, then look up in the price schedule of the item to be priced. This look-up follows the same logic as this Deal look-up. It will go through the same steps as the deal. The rationale for the Price Schedule is that only some of the items on the deal are specially priced for the customer. All other items will be priced using the Price Schedule. A price schedule provides general prices for many customers. If the price is found in the Price Schedule then the processing stops for this item. It does not go past this point in the logic. If a price is not found in the schedule then an error message is written and pricing of this sales order stops.

E) If there are Price Ranges entered in deal, get the price ranges that correspond to those items in the deal. Price Ranges are not optional at least one must be entered. The Price Range represents the Overage added to the market price.

F) If there are Absorbed charges entered in deal, get the charges to be absorbed. Absorbed Charges are optional.

G) If the Broker is entered in the deal, get the appropriate item. Brokerage is optional. Brokerage can be calculated per the contractual terms with the broker. Brokerage can be calculated as a percentage or per product unit of measure. There can be ranges (price break) of Brokerage paid.

H) If the Billing Method Code is in the deal, look up the appropriate billing method and calculate the premium. This only applies to products where a moisture premium is payable (e.g., bulk cheese products).

I) If the Components are entered in the deal, calculate the component lbs per the UOM and use that to multiple times the component unit price. This only applies to products where component pricing is used (e.g., cream and condensed products). This is calculated by taking the component test percentage times the product pounds to give the component pounds. This data will have to be stored in the database to be later for later invoicing.

J) Sum up all pricing components and put the total item price in the Sales Order Detail for that item.


Page 30


1) INVALID DEAL NUMBER.2) INVALID ORGANIZATION NUMBER.3) INVALID CUSTOMER NUMBER.4) INVALID MKTT BILL BASIS.5) INVALID EFFECTIVE DATE MUST BE GREATER THAN TODAY’S DATE.6) INVALID PRICE SCHEDULE NUMBER.7) INVALID MARKET NAME.8) INVALID ITEM NUMBER.9) INVALID PRICE RANGE NUMBER.10) INVALID ABSORBED CHARGE NUMBER.11) INVALID BROKER NUMBER.12) INVALID BILLING METHOD CODE MUST BE BETWEEN 60 TO 70 PERCENT.

2.2.3. Menu Navigation

The following screens illustrate the series of menus used to traverse the pricing application screens. The pricing application is designed to provide "fast track" type access to other pricing screens via the object menu. The edit menu will provide access to standard edit functions. Action will provide access to pricing orders, re-pricing orders and testing the pricing set-up for specific deal/schedule items.

Security access to these pricing screens are governed by the same access permissions that the GEMMS Sales Order Screen has since the Pricing Application will be attached to the GEMMS Sales Order menu and shares the same permissions. The set-up of deals and schedules is restricted to those organizations who have access for entry of Sales Orders.

2.2.3.1. Object Menu

1 2 3 4 5 6 7 812345678901234567890123456789012345678901234567890123456789012345678901234567890

"From any" ScreenObject Edit Report Action Menu=F1Customer DealPrice ScheduleBrokerMarketPrice RangeAbsorbed ChargesComponent

Quit …CTRL X

Page 31


1 2 3 4 5 6 7 8

Purpose: This is the main menu of the Pricing Application. It provides a pathway to other pricing application functions. The object menu allows access to other pricing functions/menus defined below:

Customer Deal - takes the user of the system to the customer deal entry/update screen. Price Schedule - takes the user to the price schedule entry/update screen. Broker - takes the user of the system to the broker entry/update screen. Market - takes the user of the system to the market entry/update screen. Price Range - takes the user of the system to the price range entry/update screen. Absorbed Charges - takes the user of the system to the charges entry/update screen. Component - takes the user of the system to the component entry/update screen. Quit …CTRL X - takes the user out of the pricing screens.

NOTE: The "From any" Screen at the top of each navigation menu means that from any screen these functions will be available. Each screen will have these functions and these functions will be access via the title bar at the top by pressing F1.

2.2.3.2.

Page 32

Edit Menu

1 2 3 4 5 6 7 812345678901234567890123456789012345678901234567890123456789012345678901234567890

"From any" ScreenObject Edit Report Action Menu=F1

New F3 (Update)Save F10Lookup F6Search F7Copy F9Delete PF14


1 2 3 4 5 6 7 8

Purpose: The edit menu provides edit functions to the screen that is in use. The edit menu allows access to other pricing functions/menus defined below:

New F3 - creates a new record Save F10 - saves a record Lookup F6 - pops up a look up screen for the selected field Search F7 - searches for an existing record Copy F9 - copies an existing record Delete PF14 - deletes a specified record


Page 33

2.2.3.3.

Page 34

Report Menu

1 2 3 4 5 6 7 812345678901234567890123456789012345678901234567890123456789012345678901234567890


Reports > (Update)Pricing Engine Error ReportPrice Schedule ListingBroker ListingProduct Component ListingCustomer Deal ListingMarket ListingAbsorbed Charges Listing


1 2 3 4 5 6 7 8

Purpose: The Report menu will provide direct access to the reports available within the pricing application. This menu will allow "on demand" printing of the reports directly by the users of the system. The edit menu allows access to other pricing functions/menus defined below:

Reports Pricing Engine Error Report Customer Deal Listing Price Schedule Listing Market Listing Broker Listing Absorbed Charges Listing Product Component Listing


2.2.3.4.Page 35

Action Menu

1 2 3 4 5 6 7 812345678901234567890123456789012345678901234567890123456789012345678901234567890


Test Pricing (Update)Run PricingRe-Price OrdersCancel Pricing


1 2 3 4 5 6 7 8

Purpose: The Action menu will execute specific pricing actions for use after the pricing has been defined for current sales orders that need pricing. The action menu allows access to other pricing functions defined below:

Test Pricing - to test the pricing set-up on real sales orders. It runs a simulated pricing run without updating any of the sales order. It will however generate a Pricing Error report. This is similar to a running a Trial Balance Report in general ledger.

Run Pricing - schedules the pricing engine run at a later time. It will price all sales orders which have a deal or schedule defined to them in the user defined field on the Sales Order Screen.

Re-Price - immediately runs the pricing engine for a specific set of orders. Cancel Pricing - cancels the previously scheduled pricing engine run.


Page 36

3.

Page 37

BUSINESS TRANSACTIONS

3.1. Summary

The following summary represents all the transactions that the pricing application should be able to handle. The products correspond to one of the product descriptions.

NR SR Market Cust. Date Order Priced Components Price Calculated on PricingProd. Grp

Prod. Grp

Product Group Description Price Based On Overage Prev. Week

Order Ship Manuf Eaches Prod LBS

BF LBS

SNF LBS

Moist. Prem.

%

UOM

11 Cream Chicago Butter 135% of Mktt

X X LBS

13 Whey Cream Chicago Butter 118% of Mktt

X X LBS

14 18% Cream Blend X X X CWT

17 Buttermilk Powder Central States Market

No X X X LBS

18 Skim Milk Unknown Unknown X X CWT

21 Condensed Skim Unknown X LBS

22 Condensed Whey Dry Whey Market

<.04> X X LBS

23 Sweetened Condensed Skim Milk Unknown X CWT

24 Buttermilk Condensed Unknown X LBS

25 Condensed Whey Permeate Unknown X LBS

28 Whole Milk Condensed Sweetened Unknown X CWT

29 Whole Condensed Lactose Sweet-HFHL-SCWM 251

X CWT

30 Whole Condensed Unknown X CWT

31 Blend Unknown X X LBS

34 HF Whole Condensed Lactose

Unknown X CWT

1XXX 1XX Barrel or Block Cheese Green Bay Cheese

Yes X X Yes LBS

2XXX 2XX NFDM Central States Market

No X X X LBS

4XXX 4XX Butter Chicago Butter Yes X X X X LBS

5XXX 5XX Whey Central States Market

No X X X LBS

7XX Other Yes X X LBS

7XXX Not Used

Aseptic Cheese X EA/CS

3XXX Not Used

Instant Milk

Page 38

4.

LOGICAL DATA MODEL

4.1. Entity-Relationship Diagram

The Entity Relationship Diagram defines the data required to support Item Pricing. Entities are things that the business requires data to be stored on. This is a high level logical model meaning it is the way that the users see the requirements and not specifically how the application will access the data. The diagram includes relationships between entities and they are represented by the lines between the boxes. The E-R model includes the following:

4.1.1. Entity Descriptions

The follow GEMMS tables and Pricing specific entities will be used to calculate item prices.

4.1.1.1. OP_ORDR_HDR

Description: Order header. Header table for orders and quotes.Primary Key: OP_ORDR_HDR_PK

Page 39

Column Name Data Type Len Dec Null DescriptionORDER_TYPE NUMBER 5 N Current value is 1.ORDER_NO VARCHAR2 32 N Document order number (unique within

an organization).RELEASE_NO NUMBER 5 N For future use. 0 unless multi-header

order (e.g., blanket).ORDER_ID NUMBER 10 N Surrogate key.ORGN_CODE VARCHAR2 4 N In sy_orgn_mst. Determines co_code.BILLCUST_ID NUMBER 10 N In op_cust_mst where bill_ind=1.SHIPCUST_ID NUMBER 10 N In op_cust_mst where ship_ind=1.SHIPADDR_ID NUMBER 10 N In sy_addr_mst.SHIP_MTHD VARCHAR2 4 N Default ship method in op_ship_mth.SHIPPER_CODE VARCHAR2 4 N Default shipper in op_ship_mst.CUSTPO_NO VARCHAR2 32 N Customer purchase order number.SLSREP_CODE VARCHAR2 8 N In op_cust_mst or op_slsr_mst.COMMISSION_CODE VARCHAR2 8 N In op_cust_mst or op_comm_cds.BILLING_CURRENCY VARCHAR2 4 N Currency in which the customer is billed.FROM_WHSE VARCHAR2 4 N In ic_whse_mst.TO_WHSE VARCHAR2 4 N Not used at this time. In ic_whse_mst,

cnsignmnts, intraco only.FOB_CODE VARCHAR2 4 N In op_fobc_mst.TERMS_CODE VARCHAR2 4 N In op_term_mst.FRTBILL_MTHD VARCHAR2 4 N In op_frgt_mth.ORDER_COMMENT VARCHAR2 70 N User entered comment.REGISTERED_IND NUMBER 5 N Not currently used.PRINT_COUNT NUMBER 5 N Print_count is incremented when the sales

confirmation report is sent to a printer.COMPLETED_IND NUMBER 5 N 0=order open; 1=order closed if

release=0; -1=order cancelled, not set to 1 at this time.

ORDER_STATUS NUMBER 5 N User defined status code.DATE_PRINTED DATE N Last date that the order confirmation was

printed.HOLDREAS_CODE VARCHAR2 4 N In op_hold_cds.HOLD_EXPIRATION DATE N Date when the hold code expires.QUOTE_EXPIRATION DATE N Reserved for future use.ORDER_DATE DATE N Date when the order was placed.REQUESTED_SHIPDATE DATE N Date that the order was requested to be

shipped.PROMISED_SHIPDATE DATE N Date when the order was promised to the

customer.SCHED_SHIPDATE DATE N Scheduled ship date and is used as a date

for pending inventory transactions.REQUIRED_DLVDATE DATE N Date required by the customer.IN_USE NUMBER 10 N Standard: 0=available. If > 0 then

session_id of locking user.DATE_ADDED DATE N Standard: Date-time row created.DATE_MODIFIED DATE N Standard: Date-time row last changed.ADDED_BY VARCHAR2 4 N Standard: Op_code of user creating row.MODIFIED_BY VARCHAR2 4 N Standard: Op_code of user last changing

row.TEXT_CODE NUMBER 10 N In op_text_tbl if >0.DELETE_MARK NUMBER 5 N Not used at this time.USER_CLASS1 VARCHAR2 16 N Standard: User definable field.USER_CLASS2 VARCHAR2 16 N Standard: User definable field.

Page 40

USER_CLASS3 VARCHAR2 16 N Standard: User definable field.USER_CLASS4 VARCHAR2 16 N Standard: User definable field.USER_CLASS5 VARCHAR2 16 N Standard: User definable field.USER_CLASS6 VARCHAR2 16 N Standard: User definable field.TOTAL_OPEN_AMOUNT NUMBER N When the order is placed the open (non-

shipped) amount of the order is added to this field. When the order is shipped this field is decremented.

4.1.1.2. OP_ORDR_DTL

Description: Order detail lines for orders, invoices, and bills of lading.Index: OP_ORDR_DTLI0 NOT UNIQUE

Column Name Data Type Len Dec Null DescriptionORDER_ID NUMBER 10 N In op_ordr_hdr.LINE_NO NUMBER 5 N Order line number.LINE_ID NUMBER 10 N Sub line_no unique within table.

Surrogate key to this table.INVOICE_ID NUMBER 10 N In op_invc_mst.INVOICELINE_NO NUMBER 5 N Line number on invoice.BOL_ID NUMBER 10 N In op_bill_lad.BOLLINE_NO NUMBER 5 N Line number on shipment.RETURN_ID NUMBER 10 N For future use. In op_rtrn_mst.ITEM_ID NUMBER 10 N In ic_item_mst.GENERIC_ID NUMBER 10 N In op_gnrc_itm. Can be customer item.

0if no generic item.LINE_DESC VARCHAR2 70 N Defaults from ic_item_mst but may be

overridden by user.LINE_COMMENT VARCHAR2 70 N User entered commentORDER_QTY1 NUMBER N Order quantity in any unit of measure.

Must have conversion.ORDER_QTY2 NUMBER N Not defined.ORDER_UM1 VARCHAR2 4 N Unit of measure for order quantity,

shipquantity, and bill quantity.ORDER_UM2 VARCHAR2 4 N If dualum_ind in ic_item_mst=1.SHIPADDR_ID NUMBER 10 N Different address, same shipto.

Defaultsfrom header ship-to.SHIPCUST_ID NUMBER 10 N Overrides op_ordr_hdr.SHIPPER_CODE VARCHAR2 4 N From op_cust_shp. Overrides

op_ordr_hdr.SHIP_MTHD VARCHAR2 4 N From op_cust_shp. Overrides

op_ordr_hdr.TO_WHSE VARCHAR2 4 N For future use. Intra co shipments and

consignments only.FROM_WHSE VARCHAR2 4 N Required. Overrides op_ordr_hdr. In

ic_whse_mst.FOB_CODE VARCHAR2 4 N In op_fobc_mst. Overrides op_ordr_hdr.SHIP_QTY1 NUMBER N Quantity shipped or to be shipped. In

order_um1.SHIP_QTY2 NUMBER N If dualum_ind in ic_item_mst=1.NET_WT NUMBER N Weight of product not including shipping

container.TARE_WT NUMBER N Weight of containers.

Page 41

PALLET_WT NUMBER N Pallet weight.SHIPWT_UM VARCHAR2 4 N Shipping weight UOM. Defaults from ldb

variable op$shipwt_um.FRTBILL_MTHD VARCHAR2 4 N In op_frgt_mth. Overrides op_ordr_hdr.FRTBILL_WT NUMBER N Weight for freight billing purposes.SHIP_VOLUME NUMBER N Computed by converting ship_qty1 to

shipvolume_um.SHIPVOLUME_UM VARCHAR2 4 N Defaults from ldb variable

op$shipvol_um.NET_FREIGHT NUMBER N Amount allocated to billing for this line.SHIP_STATUS NUMBER 5 N 0=not shipped;10=picked;

20=shipped/released.BILL_QTY NUMBER N Product quantity customer pays for in

order_um1.BASE_PRICE NUMBER N Price from pricing table in order_um1.NET_PRICE NUMBER N Actual unit price (order_um1).EXTENDED_PRICE NUMBER N Qty*net_price.PRICE_UM VARCHAR2 4 N Unit of measure for price.BILLING_CURRENCY VARCHAR2 4 N Currency in which customer is billed.BASE_CURRENCY VARCHAR2 4 N In gl_curr_mst.EXCHANGE_RATE NUMBER N Rate for conversion to cust currency.TERMS_CODE VARCHAR2 4 N In op_term_mst. Overrides op_ordr_hdr.REQUESTED_SHIPDATE DATE N Date that the customer requested

shipment of the order line.PROMISED_SHIPDATE DATE N Overrides requested.SCHED_SHIPDATE DATE N Overrides promised. Used as trans_date

for pending inv transactions (ic_tran_pnd).

ACTUAL_SHIPDATE DATE N Date of shipment. Required in shipping.REQUIRED_DLVDATE DATE N Required delivery date.ACTUAL_DLVDATE DATE N Actual delivery date. Reserved for future

use.BASE_COST NUMBER N Not used.FRT_COST NUMBER N Not used.QC_GRADE_WANTED VARCHAR2 4 N In qc_grad_mst. Optional from order

entry.COMPLETED_IND NUMBER 5 N 0=open order; 1=completed order; -

1=cancelled order.SLSREP_CODE VARCHAR2 8 N In op_slsr_mst. Overrides op_ordr_hdr.COMMISSION_CODE VARCHAR2 8 N In op_comm_cds. Overrides op_ordr_hdr.NET_COMMISSION NUMBER N Not used.NET_TAX NUMBER N Sum of tax for this line. Detail in

op_invc_chg table.BACKORDREAS_CODE VARCHAR2 4 N Backorder reason code from sy_reas_cds

when line is a backorder.BATCH_ID NUMBER 10 N Not used at this time. Batch producing for

this order.HOLDREAS_CODE VARCHAR2 4 N In op_hold_cds.HOLD_EXPIRATION DATE N Date when the hold code expires.QUOTE_EXPIRATION DATE N Not used at this time.QUOTEORDLINE_ID NUMBER 10 N Not used at this time.USER_CLASS1 VARCHAR2 16 N Standard: User definable field.USER_CLASS2 VARCHAR2 16 N Standard: User definable field.USER_CLASS3 VARCHAR2 16 N Standard: User definable field.

Page 42

ALLOC_IND NUMBER 5 N 0=inventory not allocated for line; 1=inventory allocated for line.

GL_POSTED_IND NUMBER 10 N Indicates if this shipment line has been posted to the mfg controller subsidiary ledger. 0 - shipment line has been posted; 1 - line has not been posted

DATE_ADDED DATE N Standard: Date-time row created.DATE_MODIFIED DATE N Standard: Date-time row last changed.ADDED_BY VARCHAR2 4 N Standard: Op_code of user creating row.MODIFIED_BY VARCHAR2 4 N Standard: Op_code of user last changing

row.DELETE_MARK NUMBER 5 N Standard: 0=Active record (default);

1=Marked for (logical) deletion.TRANS_CNT NUMBER 10 N Standard: Program flag to control locking.TEXT_CODE NUMBER 10 N Standard: Defined in op_text_tbl if value

> 0EXPORTED_DATE DATE N Date when the shipment line was

exported to oracle financials a/r system. Defaults to sy min date.

SYSTEM_PRICE NUMBER N The price obtained for the line from the pricing tables, taking into account, the item, customer, warehouse, qc grade, price classes and order quantity. Converted to order_um1 and billing_currency on the line.

PRICEREAS_CODE VARCHAR2 4 N Reason code for manual override of a price.

PRICEFF_ID NUMBER N Fk to op_prce_eff. Price effectivity used to create the price

4.1.1.3. OP_CUST_MST

Description: Order processing customer master. Stores customer information.Primary Key: OP_CUST_MST_PK1. CUST_NO

Column Name Data Type Len Dec Null DescriptionCUST_ID NUMBER 10 N Surrogate cust_vend in sy_surg_ctl.CUST_NO VARCHAR2 32 N User's customer number.CUSTSORT_NO VARCHAR2 16 N User defined alternate sort order.CUST_NAME VARCHAR2 40 N Name of the customer. Entered by the

user.PHONE_NO VARCHAR2 20 N Customer telephone numberFAX_NO VARCHAR2 20 N Fax numberTELEX_NO VARCHAR2 20 N Telex numberALTCUST_NO VARCHAR2 32 N Not validated/customer use.ADDR_ID NUMBER 10 N In sy_addr_mst. If >0 used as the default

shipping address.MAILADDR_ID NUMBER 10 N In sy_addr_mst. If >0 used as default

address in invoices.TERMS_CODE VARCHAR2 4 N In op_term_mst.TERMS_VARY NUMBER 5 N 0=credit terms do not vary; 1=credit

terms can vary.FOB_CODE VARCHAR2 4 N In op_fobc_mst.SLSREP_CODE VARCHAR2 8 N In op_slsr_mst.COMMISSION_CODE VARCHAR2 8 N Commission group in op_comm_cds.

Page 43

BACKORDER_IND NUMBER 5 N 0=customer does not accept backorders; 1#name?

STMT_IND NUMBER 5 N Reserved for future use.SVCCHG_IND NUMBER 5 N Reserved for future useINACTIVE_IND NUMBER 5 N 0=active customer; 1=inactive customer.BILL_IND NUMBER 5 N 0=not a billing customer; 1=billing

customer.SHIP_IND NUMBER 5 N 0=not ship-to customer; 1=ship-to

customer.CUST_TYPE NUMBER 5 N Internal consignment customer. Defaults

to 0.SIC_CODE VARCHAR2 8 N Not validated.FROM_WHSE VARCHAR2 4 N Preferred by customer in ic_whse_mst.TO_WHSE VARCHAR2 4 N Consignment, transfer warehouse in

ic_whse_mst. Used only if a consignment customer has been indicated. Reserved for future use.

SPLC_CODE VARCHAR2 16 N Industry standard point location code. Not validated.

FRTBILL_MTHD VARCHAR2 4 N In op_frgt_mth.CREDIT_LIMIT NUMBER N Not validated.PRICECUST_ID NUMBER 10 N Price info from pricecust used for pricing.

Defaults to itself.CUST_TERRITORY VARCHAR2 8 N Not validated.CUST_CURRENCY VARCHAR2 4 N In gl_curr_mst.CUST_CLASS VARCHAR2 8 N In op_cust_cls.CUSTTRADE_CLASS VARCHAR2 8 N In op_ctrd_cls.CUSTGL_CLASS VARCHAR2 8 N Fk to op_cgld_clsTAXLOC_CODE VARCHAR2 10 N Tax location code from tx_tloc_cds that

indicates tax location of customer.TAXCALC_CODE VARCHAR2 4 N Tax calculation indicator used for

customer. Overrides default tax calculation.

USER_CLASS1 VARCHAR2 16 N Standard: User definable field.USER_CLASS2 VARCHAR2 16 N Standard: User definable field.USER_CLASS3 VARCHAR2 16 N Standard: User definable field.USER_CLASS4 VARCHAR2 16 N Standard: User definable field.USER_CLASS5 VARCHAR2 16 N Standard: User definable field.USER_CLASS6 VARCHAR2 16 N Standard: User definable field.DATE_ADDED DATE N Standard: Date-time row created.DATE_MODIFIED DATE N Standard: Date-time row last changed.ADDED_BY VARCHAR2 4 N Standard: Op_code of user creating row.MODIFIED_BY VARCHAR2 4 N Standard: Op_code of user last changing

row.TRANS_CNT NUMBER 10 N Standard: Program flag to control locking.DELETE_MARK NUMBER 5 N Standard: 0=Active record (default);

1=Marked for (logical) deletion.TEXT_CODE NUMBER 10 N In op_text_tbl if >0.OPEN_BALANCE NUMBER N Contains the current open balance (value

of unshipped orders). This amount is updated during order entry and shipping for use in credit checking under oracle financials. Value is incremented for new open orders and decremented when an order line is shipped.

CUSTPRICE_CLASS VARCHAR2 8 N Fk to op_cprc_cls.

Page 44

4.1.1.4. IC_ITEM_MST

Description: Item master. Define items.Primary Key: IC_ITEM_MST_PK

Column Name Data Type Len Dec Null DescriptionITEM_ID NUMBER 10 N Surrogate key for the item.ITEM_NO VARCHAR2 32 N Name of the item.ITEM_DESC1 VARCHAR2 70 N Short description of the item that is

displayed during the item look up.ITEM_DESC2 VARCHAR2 70 N Short description of the item that is not

displayed during the item look up.ALT_ITEMA VARCHAR2 32 N Alternate name for the item.ALT_ITEMB VARCHAR2 32 N Second alternate name for the item.ITEM_UM VARCHAR2 4 N Uom of the item by which the inventory

balances are maintained.DUALUM_IND NUMBER 5 N Dual unit of measure indicator. 0=Single

UOM control, 1=Fixed relationship dual UOM control, 2=Variable relationship dual UOM control with default conversion displayed, 3= Variable relationship dual UOM control with default conversion not displayed.

ITEM_UM2 VARCHAR2 4 N Second UOM for in which inventory balances are maintained, for dual UOM items.

DEVIATION_LO NUMBER N Factor defining the allowable deviation below the standard conversion for dual UOM items w/ dualum_ind=2 or 3.

DEVIATION_HI NUMBER N Factor defining the allowable deviation above the standard conversion for dual UOM items w/dualum_ind=2 or.

LEVEL_CODE NUMBER 5 N Not currently used.LOT_CTL NUMBER 5 N Lot control indicator. 0=Not lot

controlled, 1=Lot controlled.LOT_INDIVISIBLE NUMBER 5 N Indivisible indicator. 0=Lots are not

indivisible (can be split), 1=Lots are indivisible (cannot be split).

SUBLOT_CTL NUMBER 5 N Sublot control indicator. 0=Not sublot controlled, 1=Sublot controlled. Used only if lot_ctl =1.

LOCT_CTL NUMBER 5 N Location control indicator. 0=Not location controlled, 1=Location controlled.

NONINV_IND NUMBER 5 N Noninventory indicator. 0=Not a noninventory item (inventory balances are maintained), 1=Noninventory item (inventory balances are not maintained).

MATCH_TYPE NUMBER 5 N Type of invoice matching done. Blank=No matching, 2=Two way matching, 3=Three way matching.

INACTIVE_IND NUMBER 5 N Inactive indicator. 0=Active, 1=Inactive.INV_TYPE VARCHAR2 4 N Inventory type. User defined.SHELF_LIFE NUMBER N Shelf life. This number of days is added

to lots of grade controlled items to calculate the expiration date.

Page 45

RETEST_INTERVAL NUMBER N Number of days specifying how often grade controlled items should be retested.

ITEM_ABCCODE VARCHAR2 4 N ABC code for the item.GL_CLASS VARCHAR2 8 N GL class for an item.INV_CLASS VARCHAR2 8 N Inventory class for an item.SALES_CLASS VARCHAR2 8 N Sales class for an item.SHIP_CLASS VARCHAR2 8 N Ship class for an item.FRT_CLASS VARCHAR2 8 N Freight class for an item.PRICE_CLASS VARCHAR2 8 N Price class for an item.STORAGE_CLASS VARCHAR2 8 N Storage class for an item.PURCH_CLASS VARCHAR2 8 N Purchase class for an item.TAX_CLASS VARCHAR2 8 N Tax class for an item.CUSTOMS_CLASS VARCHAR2 8 N Customs class for an item.ALLOC_CLASS VARCHAR2 8 N Allocation class for an item. Used for

auto-allocation.PLANNING_CLASS VARCHAR2 8 N Planning class for an item. Used for MPS

and MRP reporting.ITEMCOST_CLASS VARCHAR2 8 N Cost class for an item.COST_MTHD_CODE VARCHAR2 4 N Not currently used.UPC_CODE VARCHAR2 16 N Not currently used.USER_CLASS1 VARCHAR2 16 N Standard: User definable field.USER_CLASS2 VARCHAR2 16 N Standard: User definable field.USER_CLASS3 VARCHAR2 16 N Standard: User definable field.USER_CLASS4 VARCHAR2 16 N Standard: User definable field.USER_CLASS5 VARCHAR2 16 N Standard: User definable field.USER_CLASS6 VARCHAR2 16 N Standard: User definable field.GRADE_CTL NUMBER 5 N Grade control indicator. 0=Not grade

controlled, 1=Grade controlled.STATUS_CTL NUMBER 5 N Status control indicator. 0=Not status

controlled, 1=Status controlled.QC_GRADE VARCHAR2 4 N Default grade, for lots of grade controlled

items.LOT_STATUS VARCHAR2 4 N Default status, for lots of status controlled

items.BULK_ID NUMBER 10 N Not currently used.PKG_ID NUMBER 10 N Not currently used.QCITEM_ID NUMBER 10 N QC reference item.QCHOLD_RES_CODE VARCHAR2 4 N QC hold reason code.EXPACTION_CODE VARCHAR2 4 N Code for action to take when a lot

expires.FILL_QTY NUMBER N Not currently used.FILL_UM VARCHAR2 4 N Not currently used.EXPACTION_INTERVAL NUMBER N Interval between time lot expires and time

expaction_code action should be taken.PHANTOM_TYPE NUMBER 5 N Not currently used.WHSE_ITEM_ID NUMBER 10 N For sharing a common ps_whse_eff row.EXPERIMENTAL_IND NUMBER 5 N Experimental indicator. 0=Unrestricted

use item (not experimental); 1=Experimental item (cannot be used in FM or PM).

EXPORTED_DATE DATE N Date the item was exported to Oracle Financials.


row.

Page 46

TRANS_CNT NUMBER 10 N Standard: Program flag to control locking.DELETE_MARK NUMBER 5 N Standard: 0=Active record (default);

1=Marked for (logical) deletion.TEXT_CODE NUMBER 10 N Standard: Defined in ic_text_tbl if value

> 0SEQ_DPND_CLASS VARCHAR2 8 N Sequence dependent class.

4.1.1.5. SY_USER_FLD

Description: User definable field definition. Definefield titles and validation method for user defined fields.Primary Key: SY_USER_FLD_PK

Column Name Data Type Len Dec Null DescriptionTABLE_NAME VARCHAR2 32 N Table name containing user defined

fields.FIELD_NAME VARCHAR2 32 N User defined field.FIELD_TITLE VARCHAR2 16 N Title of the user defined field on the form.DATA_REQUIRED NUMBER 5 N 1=field requires data; 0=no field does not

require data.UPPER_ONLY NUMBER 5 N 1=yes field values should be in upper case

only; 0=no field values should not be in upper case only.

VALIDATION_IND NUMBER 5 N Type of validation on the screen.CLOW_VALUE VARCHAR2 16 N Character field low value if the validation

method is a range.CHIGH_VALUE VARCHAR2 16 N Character field high value if the

validation method is a range.FLOW_VALUE NUMBER N Float low value for range validation.FHIGH_VALUE NUMBER N Float high value for range validation.FLOAT_MASK VARCHAR2 16 N Decimal precision with which a floating

point number is to be displayed in user defined field.


row.TRANS_CNT NUMBER 10 N Standard: Program flag to control locking.TEXT_CODE NUMBER 10 N Standard: Defined in sy_text_tbl if value

> 0

4.1.1.6. PR_CUSTOMER_DEAL

Description: Defines the pricing parameters for a Customer Deal. Deals are used to define the special pricing for a specific customer.

Primary Key: PR_DEAL_CODEPR_ORG_CODEPD_CUST_NOPD_CUST_DEAL_EDTE-STRPD_CUST_DEAL_EDTE-END

Column Name Data Type Len Dec Null DescriptionPD_DEAL_CODE VARCHAR2 8 N Deal CodePD_ORG_CODE VARCHAR2 8 N Organization CodePD_CUST_NO VARCHAR2 32 N Customer number

Page 47

PD_CUST_DESC VARCHAR2 30 N Customer DescriptionPD_MKTT_BILL_BASIS VARCHAR2 1 N Date used to select from the

PD_MARKETPD_CUST_DEAL_EDTE-STR DATE 10 N Date the record becomes effectivePD_CUST_DEAL_EDTE-END DATE 10 N Date the record becomes obsoletePD_PRICE_SCHEDULE VARCHAR2 8 N Price Schedule CodePD_PRICE_SCHED_DESC VARCHAR2 30 N Price Schedule DescriptionPD_MARKET VARCHAR2 8 N Market CodePD_MARKET_DESC VARCHAR2 30 N Market Code DescriptionPD_ITEM_NO VARCHAR2 8 N Item Code.PD_ITEM_PRICE VARCHAR2 7 N Item Price.PD_ITEM_PRICE_UOM VARCHAR2 4 N Item Price Unit of Measurement.PD_PRICE_RANGE VARCHAR2 8 N Price Range CodePD_PRICE_RANGE_DESC VARCHAR2 30 N Price Range DescriptionPD_ABSORB_CHG VARCHAR2 8 N Absorbed Charges CodePD_ABSORB_CHG_DESC VARCHAR2 30 N Absorbed Charges DescriptionPD_BROKER CODE VARCHAR2 8 N Broker CodePD_BROKER CODE_DESC VARCHAR2 30 N Broker Code DescriptionPD_BILL_METH_CODE VARCHAR2 4 N Billing Method (for Moisture Premium

Calculation)PD_BILL_METH_PREM VARCHAR2 2 N Billing Method Percentage (for Moisture

Premium Calculation)PD_COMP_BILL_FLAG VARCHAR2 1 N Flag To Check For ComponentsPD_REMARKS VARCHAR2 70 N Remarks FieldPD_INSTRUCTION VARCHAR2 70 N Instructions FieldPD_DATE_ADDED DATE N Standard: Date-time row created.PD_DATE_MODIFIED DATE N Standard: Date-time row last changed.PD_ADDED_BY VARCHAR2 4 N Standard: Op_code of user creating row.PD_MODIFIED_BY VARCHAR2 4 N Standard: Op_code of user last changing

row.

4.1.1.7. PR_SCHEDULE

Description: Defines the pricing parameters for a Price Schedule. Schedules are used to define the general pricing for a many customers.

Primary Key: PR_SCHEDULE_CODEPR_ORG_CODEPS_SCH_EDTE- STRPS_SCH_EDTE-END

Column Name Data Type Len Dec Null DescriptionPS_SCHEDULE_CODE VARCHAR2 8 N Schedule CodePS_PRICE_SCHED_DESC VARCHAR2 30 N Price Schedule DescriptionPS_ORG_CODE VARCHAR2 8 N Organization CodePS_MKTT_BILL_BASIS VARCHAR2 1 N Date used to select from the

PS_SCHEDULEPS_SCH_EDTE-STR DATE 10 N Date the record becomes effectivePS_SCH_EDTE-END DATE 10 N Date the record becomes obsoletePS_MKT VARCHAR2 8 N Market CodePS_MKT_DESC VARCHAR2 30 N Market Code DescriptionPS_MKT_PRCE VARCHAR2 6 N Market PricePS_MKT_UOM VARCHAR2 4 N Market Price UOMPS_MKT_EFF_STRT VARCHAR2 8 N Market Price Effective Date StartPS_MKT_EFF_END VARCHAR2 8 N Market Price Effective Date EndPS_ITEM_NO VARCHAR2 8 N Item Code.PS_ITEM_DESC VARCHAR2 30 N Item Price Description.

Page 48

PS_ITEM_PRICE VARCHAR2 7 N Item Price.PS_ITEM_PRICE_UOM VARCHAR2 4 N Item Price Unit of Measurement.PS_PRICE_RANGE VARCHAR2 8 N Price Range CodePS_PRICE_RANGE_DESC VARCHAR2 30 N Price Range DescriptionPS_ABSORB_CHG VARCHAR2 8 N Absorbed Charges CodePS_ABSORB_CHG_DESC VARCHAR2 30 N Absorbed Charges DescriptionPS_COMP_BILL_FLAG VARCHAR2 1 N Flag To Check For ComponentsPS_BILL_METH_CODE VARCHAR2 4 N Billing Method (for Moisture Premium

Calculation)PS_BILL_METH_PREM VARCHAR2 2 N Billing Method Percentage (for Moisture

Premium Calculation)PS_REMARKS VARCHAR2 70 N Remarks FieldPS_INSTRUCTION VARCHAR2 70 N Instructions FieldPS_DATE_ADDED DATE N Standard: Date-time row created.PS_DATE_MODIFIED DATE N Standard: Date-time row last changed.PS_ADDED_BY VARCHAR2 4 N Standard: Op_code of user creating row.PS_MODIFIED_BY VARCHAR2 4 N Standard: Op_code of user last changing

row.

4.1.1.8. PR_BROKER

Description: Defines the pricing parameters for a Market.Primary Key: BROK_CODE

PB_ORG_CODEPB_CUST_NOPB_BROK_EDTE-STRPB_BROK_EDTE-END

Column Name Data Type Len Dec Null DescriptionPB_ORG_CODE VARCHAR2 8 N Organization CodePB_BROK_CODE VARCHAR2 8 N Broker CodePB_CUST_NO VARCHAR2 32 N Customer numberPB_CUST_DESC VARCHAR2 30 N Customer DescriptionPB_BROK_EDTE-STR DATE 10 N Date the record becomes effectivePB_BROK_EDTE-END DATE 10 N Date the record becomes obsoletePB_ITEM_NO VARCHAR2 8 N Item Code.PB_ITEM_DESC VARCHAR2 30 N Item Price Description.PB_ITEM_PRICE_UOM VARCHAR2 4 N Item Price Unit of Measurement.PB_ITEM_PRICE_% VARCHAR2 7 N Item Price or percent.PB_DATE_ADDED DATE N Standard: Date-time row created.PB_DATE_MODIFIED DATE N Standard: Date-time row last changed.PB_ADDED_BY VARCHAR2 4 N Standard: Op_code of user creating row.PB_MODIFIED_BY VARCHAR2 4 N Standard: Op_code of user last changing

row.PB_TRANS_CNT NUMBER 10 N Standard: Program flag to control locking.

4.1.1.9. PR_MARKET

Description: Defines the pricing parameters for a Market.Primary Key: PM_ORG_CODE

PM_MKT_CODE

Column Name Data Type Len Dec Null DescriptionPM_ORG_CODE VARCHAR2 8 N Organization CodePM_MKT_CODE VARCHAR2 8 N Market CodePM_MKT_DESC VARCHAR2 30 N Market Code DescriptionPM_MKT_PRCE VARCHAR2 6 N Market Price

Page 49

PM_MKT_UOM VARCHAR2 4 N Market Price UOMPM_MKT_EFF_STRT VARCHAR2 8 N Market Price Effective Date StartPM_MKT_EFF_END VARCHAR2 8 N Market Price Effective Date EndPM_DATE_ADDED DATE N Standard: Date-time row created.PM_DATE_MODIFIED DATE N Standard: Date-time row last changed.PM_ADDED_BY VARCHAR2 4 N Standard: Op_code of user creating row.PM_MODIFIED_BY VARCHAR2 4 N Standard: Op_code of user last changing

row.

4.1.1.10. PR_PRICE_RANGE

Description: Defines the pricing parameters for a Market.Primary Key: PR_ RANG_CODE

PR_ORG_CODEPR_RANG _EDTE-STRPR_RANG _EDTE-END

Column Name Data Type Len Dec Null DescriptionPR_ORG_CODE VARCHAR2 8 N Organization CodePR_RANG_CODE VARCHAR2 8 N Range CodePR_RANG _EDTE-STR DATE 10 N Date the record becomes effectivePR_RANG _EDTE-END DATE 10 N Date the record becomes obsoletePR_BRK-QTY VARCHAR2 8 N Order Quantity that the break is on.PR_PRCE_DIFF VARCHAR2 6 N Price Differential add-on amount.PR_DATE_ADDED DATE N Standard: Date-time row created.PR_DATE_MODIFIED DATE N Standard: Date-time row last changed.PR_ADDED_BY VARCHAR2 4 N Standard: Op_code of user creating row.PR_MODIFIED_BY VARCHAR2 4 N Standard: Op_code of user last changing

row.

4.1.1.11. PR_ABSORBED_CHARGES

Description: Defines the pricing parameters for Absorbed Charges into the item price.Primary Key: PA_CHG_CODE

PA_ORG_CODEPA_CHG_EFF_STRTPA_CHG_EFF_END

Column Name Data Type Len Dec Null DescriptionPA_CHG_CODE VARCHAR2 8 N Absorbed Charge CodePA_CHG_DESC VARCHAR2 30 N Absorbed Charge DescriptionPA_ORG_CODE VARCHAR2 8 N Organization CodePA_CHG_EFF_STRT VARCHAR2 8 N Absorbed Charge Effective Date StartPA_CHG_EFF_END VARCHAR2 8 N Absorbed Charge Effective Date EndPA_CHG_DESC VARCHAR2 30 N Absorbed Charge DescriptionPA_CHG_PRCE VARCHAR2 6 N Absorbed Charge PricePA_CHG_UOM VARCHAR2 4 N Market Price UOMPA_DATE_ADDED DATE N Standard: Date-time row created.PA_DATE_MODIFIED DATE N Standard: Date-time row last changed.PA_ADDED_BY VARCHAR2 4 N Standard: Op_code of user creating row.PA_MODIFIED_BY VARCHAR2 4 N Standard: Op_code of user last changing

row.PA_TRANS_CNT NUMBER 10 N Standard: Program flag to control locking.

4.1.1.12. PR_ITEM_COMPONENTS

Description: Defines the pricing parameters for a Market.Primary Key: PC_ORG_CODE

Page 50

PC_ITEM_NOPC_CUST_NOPC_CMP_EFF_STRTPC_CMP_EFF_END

Column Name Data Type Len Dec Null DescriptionPC_ORG_CODE VARCHAR2 8 N Organization CodePC_ITEM_NO VARCHAR2 8 N Item Code.PC_ITEM_DESC VARCHAR2 30 N Item Price Description.PC_CUST_NO VARCHAR2 6 N Customer numberPC_CUST_DESC VARCHAR2 30 N Customer DescriptionPC_CMP_EFF_STRT VARCHAR2 8 N Absorbed Charge Effective Date StartPC_CMP_EFF_END VARCHAR2 8 N Absorbed Charge Effective Date EndPC_CMP_DESC VARCHAR2 30 N Absorbed Charge DescriptionPC_CMP_PRCE VARCHAR2 6 N Absorbed Charge PricePC_CMP_UOM VARCHAR2 4 N Absorbed Charge UOMPC_DATE_ADDED DATE N Standard: Date-time row created.PC_DATE_MODIFIED DATE N Standard: Date-time row last changed.PC_ADDED_BY VARCHAR2 4 N Standard: Op_code of user creating row.PC_MODIFIED_BY VARCHAR2 4 N Standard: Op_code of user last changing

row.

5.

REPORTS

The following reports are required. A Report Specification will be required before the report is written. The report specification defines the report layout and processing rules for the programmer to follow in developing the report.

5.1. Pricing Engine Error Report

This is a report of error encountered while running the pricing engine. It is sorted by sales order and customer name with all the data on the sales order and deal or schedule. It will be used to debug the problem encountered. The types of problems that this report may trap are where there is no deal or schedule defined for this customer’s item.

5.2. Customer Deal Listing

This is a listing of the customer deals. It is sorted by customer name and includes all the data on the deal. It lists the history of effective dated price changes as well.

5.3. Price Schedule Listing

This is a listing of the price schedules. It is sorted by price schedule name and includes all the date on the price schedule screen. It lists the history of effective dated price changes as well.

5.4. Market Listing

This is a listing of the markets. It is sorted by market name and includes all the date on the market screen. It lists the history of effective dated price changes as well.

Page 51

5.5. Broker Listing

This is a listing of the brokers. It is sorted by broker name by product line and includes all the date on the broker screen. It lists the history of effective dated price changes as well.

5.6. Absorbed Charges Listing

This is a listing of the absorbed charges. It is sorted by item number and includes all the date on the absorbed charges screen. It lists the history of effective dated price changes as well.

5.7. Product Component Listing

This is a listing of the product components that are used to price a specific product or item. It is sorted by item number and includes all the data on the product component screen. It lists the history of effective dated price changes as well.

Page 52

6. SECURITY

This section defines the application security mechanisms used to keep one GEMMS organization from using or defining pricing for another GEMMS organization. This will be primarily used to prevent one sales order location from entering or changing pricing parameters for another sales order location.

Application Security: Only authorized GEMMS users will have access to the Pricing Application. The security will be performed using GEMMS Application Security by attaching the Pricing Application to the GEMMS Sales Order Screen. Therefore only those who have access to the GEMMS Sales Order Screen will have access to the Pricing Application.

Organization: - the GEMMS organization for the user who defines the deal or schedule will be used to validate the entry and update of any of the pricing data. Each pricing screen has a field for Organization and that field will be filled automatically by Organization of the user who is attempting any entry to the pricing application. this will keep the user from entering pricing information for the wrong GEMMS organization.

Data Security will be handled by the Oracle DBMS by restricting access to the Pricing Tables to those with a need to know. The DBA will Grant access to the Pricing Tables as required with the appropriate authorizations.

Page 53

7. CONVERSION PROCEDURES

There will be no automated conversion procedures used to convert this application to production usage. All data will be entered manually according to the pricing sheets (and/or deal/schedules) defined for each customer.

In southern region, all the pricing sheets are on hard copy and will have to be manually entered. In north central region, all the pricing is in the existing MMIS. Although it is possible to convert the data it is not recommended because of the complexity of the conversion program exceeds the effort to re-enter the data. Re-entry of the data will provide *** Company Name *** the opportunity to rid itself of unneeded or obsolete data.

Page 54

8. DESIGN CONSIDERATIONS

The following sections provide the design considerations or constraints that will be used as a guideline for the Technical Design. In general, the only constraint is to conserve the project budget as much as possible. The system should be written in such a way as to not require software that the client does not have and to afford easy software maintenance of the system.

Page 55

9. IMPLEMENTATION CONSIDERATIONS

The following sections provide general requirements for the Pricing Application to be developed. These requirements include hardware/system software and training.

9.1. Hardware/System Software Requirements

At this time, this application is intended to be implemented on a HP9000 K400 running HPUX 10.01. The version of GEMMS is 3.21.13. The Oracle DBMS release is 7.1.6.X.

The pricing application will be written in Oracle Forms/Reports using PL/SQL. C++ exits may be used if necessary.

9.2. Training Requirements

The following defines each type of training, the duration, and the people required to attend. Basically, training on each of the pricing application functions need to be performed for both Southern Region and North Central Region Marketing Departments. At this time, definition of those persons has not been performed although it needs to.

Page 56

sample software package enhancement specification

Documents