Requirements - Purchase Order Processing (PO)

Requirements-Purchase Order Processing (PO)
1.1 General requirements
(a)	A Company intended to introduce a Purchase Order Processing system to increase control over the ordering of goods and services. The system will also be used to record and report on a wide variety of committed expenditure and is expected to integrate with:
	a job/project costing system,
	the purchase ledger,
	the general ledger.
(b)	Orders will be placed through the raising of authorised purchase order documentation. Initially, orders will need to be entered manually.
(c)	It is intended that the system will be integrated with a computerised stock system and the availability of a stock module should be stated.
(d)	The stock system will create purchase order recommendations based on re-order levels, re-order quantities and lead times.
(e)	Order recommendations will be reviewed visually and either confirmed, amended or deleted. Remaining orders will then be actioned and printed.
(f)	Each order line in the system will carry a status indicator to assist in monitoring progress, for example goods awaiting delivery, part delivery, goods received but not invoiced, invoices awaiting approval.
(g)	Purchase orders will remain on the system until the user indicates that each order line is complete and the corresponding invoice has been authorised. Orders may be deemed complete before the full order quantity is received.
(h)	There will be links to the following systems:
	purchase ledger, for posting of authorised invoices,
	job costing, for posting of the cost of issues,
	stock control, for generation of purchase orders and receipt of ordered goods.
1.2 Data input
(a)	Purchase orders for stock items will mainly be created from the stock module as described above.
(b)	Purchase orders may also be input manually. These will cover non-stock items and orders overriding the normal stock replenishment system.
(c)	Manual orders will require free type facility for item descriptions and a facility to enter the total value of the order.
(d)	Each order record will contain space for the user to free type notes on the progress of the order.
(e)	Goods received will be matched with the order on one of the following fields:
	order number,
	supplier code,
	product code,
	alpha search on supplier name.
(f)	The quantity received will be entered against each order line. If this quantity is less than the quantity ordered, the user must indicate whether the rest of the order line is to follow or if the order is to be cleared. The order line will be marked as
(g)	Purchase invoices will be matched with orders and the value of goods and VAT entered. The order will be marked as invoiced not authorised.
(h)	When invoices are authorised they will be posted automatically to the purchase ledger, and relevant journals for goods value and VAT will be posted to the general ledger.
(i)	Goods received will be posted to the stock system. Goods values from purchase invoices will update the item value in the stock system.
(j)	The system will allow users to enter additional lines such as expected freight and duty for each order.
1.3 Data stored
(a)	For each order the following data will be held:
	a six digit order number,
	supplier code,
	supplier name,
	address,
	date ordered,
	supplier reference,
	total net value,
	total VAT,
	order status.
(b)	For each order line the following data will be held:
	line number,
	product code,
	product description,
	unit of measure,
	order quantity,
	received quantity,
	due date,
	line status,
	unit cost,
	line value.
1.4 Data output
1.4.1	Enquiries
(a)	Screen enquiries will be required on purchase orders.
(b)	Access routes for screen enquiries will include:
	order number,
	product code,
	supplier code,
	due date,
	alpha search on product or supplier, description
1.4.2	Documents and reports
(a)	Purchase orders will be printed by the system.
(b)	It will be possible to produce summarized and detailed value reports on purchase orders in the system by order status and due date.
1.4.3	Accruals
(a)	Accruals will be calculated for goods received not invoiced and for freight and duty charges not paid.
(b)	The accrual will be posted to an account in the general ledger, automatically reversing at the start of the next period.

Requirements - Sales Order Processing (SO)

Sales Order Processing (SO)
1.1 General requirements
(a)	The following order types will be supported:
	quotation,
	proforma,
	repeat order,
	back order,
	forward order,
	order with call-offs,
	direct invoice/credit note.
(b)	The following data will be stored for each customer:
	customer code,
	customer name,
	customer VAT registration number,
	customer type (category),
	five line invoice address plus postcode (many per customer with one default address),
	country code of customer,
	five line delivery address plus postcode and country (many per invoice address with one default address),
	country code for delivery address,
	default delivery warehouse,
	sales representative,
	telephone number,
	fax number,
	telex number,
	payment terms,
	delivery instructions (per delivery address).
(c)	Stock will be held in multiple warehouses.
(d)	Each customer will allocated to a particular warehouse at delivery address level, and which can be over-ridden during order entry.
(e)	Each warehouse will have multiple bins, with some stock being at more than one bin location.
(f)	The system will maintain a customer/ product discount matrix.
(g)	The system will maintain a file of promotional prices, being customer/ product discount matrices for specific time periods.
(h)	It will be possible to override the prices displayed when the order is input.
(i)	It will be possible to override the line discount percentage when the order is input.
(j)	It will be possible to suppress printing the discount on invoices, i.e. show the net price only.
(k)	It will be possible to bar customers from buying certain product ranges (to prevent customers buying another customer's own brand goods).
(l)	An expected delivery date will be held for each order line.
(m)	It will be possible to add the following to invoices:
	free-type text,
	standard text,
	fixed charges,
	charges based on order value,
	charges based on order weight/ volume,
	non-stocked product lines,
	additional discount based on total value.
	basis of value,
	type of sale,
	mode of transport,
(n)	It will be possible to suppress the printing of the above.
(o)	It will be possible to suppress the printing of lines containing components on invoices.
(p)	Foreign currency will be supported by the system. The unit price will be converted to the foreign currency at the current exchange rate.
(q)	There will be no restriction on the number of lines on an order.
(r)	The field size for unit prices will be 999,999.99.
(s)	The field size for quantities will be 9,999,999.
(t)	Sales order processing will have links to the following systems:
	stock control, for the allocation of stock,
	sales ledger for posting invoices,
	project costing, for posting revenue,
	sales analysis,
	general ledger, for revenue (unless dealt with elsewhere in system).
1.2 Order input
(a)	Multiple order lines will be contained on a single screen.
(b)	To assist with input there will be an alphanumeric search facility on customer name.
(c)	To assist with input there will be an alphanumeric search facility on product description.
(d)	If it is possible to create a new customer record during order entry, their credit limit will default to zero.
(e)	During order entry it will be possible to make enquiries on customers and products.
(f)	The field for the customer's own order reference will be 30 alphanumeric characters and be printed on delivery notes and invoices.
(g)	There will be a field for comments on the order entry screen, but these will not appear on documents.
(h)	There will be an option to allocate less stock than is ordered even if there is stock available.
(i)	If a particular order line is out of stock, the system will offer:
	an alternative product,
	an alternative warehouse.
(j)	The system will allow for the allocation of stock that is not yet available, thus creating negative free stock.
(k)	If insufficient stock is available, there will be options to:
	back order the whole order line,
	allocate available stock and back order the remainder,
	allocate available stock and drop the remainder of the order line,
	drop the entire order line.
(l)	If an item is out of stock it will be possible to select an appropriate message to appear on output documents.
(m)	As order lines are input it will be possible to monitor the weight/volume of the order.
(n)	There will be a field for the input of delivery instructions. These may be customer delivery address specific.
(o)	It will be possible to combine multiple deliveries on one order.
(p)	The number of labels required for delivery documentation will be input at the end of the order.
(q)	User-defined analysis codes such as sales representative or customer type will be picked up at order entry time from the customer record, and applied to each order for sales analysis purposes.
(r)	During order input it will be possible to insert/amend/delete/add lines.
(s)	It will be possible to record item serial numbers against each order line after picking as a means of tracking individual stock items so that returns under warranty can be validated.
(t)	A customer record can be set to accept no new orders.
(u)	The order will be stopped at the start of the order entry if the outstanding balance and existing orders exceed the credit limit.
(v)	The order will be stopped if the outstanding balance, existing orders and the new order together exceed the credit limit.
(w)	Only the credit controller will be able to release stopped orders for further processing.
(x)	When credit notes are input, the operator will be able to select whether:
	stock quantities will be increased,
	stock quantities will not be increased.
(y)	Forward orders, repeat orders and call-offs will be automatically released as current orders based on due date.
(z)	Quotations and pro-formas will be converted to current orders when accepted.
(aa)	Back orders will be released when stock becomes available, using the following methods:
	manual on an order by order basis,
	automatically using customer priority, due date or order date,
	when a current order for the same customer is processed.
(ab)	It will be possible to put orders and order lines on hold to prevent further processing.
1.3 Sales order cycle
(a)	The following processing cycle will be followed, but may be customised if required:
	input/create the order,
	print acknowledgements where required,
	print picking lists,
	print delivery notes,
	print delivery labels,
	deliveries (or despatches) confirmed by calling up the order,
	print the invoices after confirmation,
	print specific invoices without confirmation stage (i.e. direct invoicing),
	post to sales ledger, general ledger and sales analysis files.
1.4 Data output
1.4.1 Enquiries
(a)	Screen enquiries will be made on orders by the following routes:
	by order number,
	by product line,
	by customer,
	by due date.
(b)	In each instance, enquiries may be restricted to individual or combinations of transactions.
(c)	It will be possible to enquire on the status of each order line as it passes through the system, and to review the documents printed to date.
1.4.2 Documents
(a)	The following user-definable documents will be printed by the system:
	quotations,
	proformas,
	acknowledgements,
	picking lists,
	despatch/delivery notes,
	labels,
	invoices,
	credit notes.
(b)	The delivery note reference will appear on labels.
(c)	Picking lists may be printed for single or multiple deliveries.
(d)	Picking lists will group stock requirements by product for multiple deliveries.
(e)	Picking lists will be printed for stock transfers and issues.
(f)	Picking lists will be printed at the relevant stock location.
(g)	Picking lists will be sorted by bin location.
(h)	Invoices will be printed with standard user-definable messages.
(i)	It will be possible to reprint all of a document print run, or ones for individual orders.
1.4.3 Reports
(a)	Outstanding order reports may be selected and sorted using the following fields:
	customer,
	product line,
	commodity code,
	product group,
	order type,
	order date,
	due date,
	warehouse,
	sales representative,
	order number,
	margin.
(b)	The information appearing on order reports will include:
	quantity - net mass, weight in kilogrammes,
	quantities - other units,
	gross sales values,
	net sales values.
(c)	The content of reports on orders will be user-defined and may be changed at run-time.

Requirements - Forecasting (FOR)

Requirements - Forecasting

Overview

Forecasts are generated to provide future sales projections in terms of dollars or units for product groups and individual line items. Forecast periods are usually monthly intervals for one to five years. Forecasting and Master Production Scheduling are frequently combined as one application due to the role which the sales forecast plays in deriving the master schedule.

The forecast results are usually modified by management to include factors which have not been allowed for in the computer program. This modified forecast provides the input to the MPS and is used to develop production requirements for each period. The forecast must be traced and compared with actual sales and revised periodically (at least yearly). In cases where the product sales are seasonal, the forecast will probably be smoothed into a balanced production plan which will provide the input for the master schedule.

Forecasts should be generated for finished good end items only and not for raw material and component parts. The demands for the latter are calculated through MRP.

Forecasting

• Enter and maintain historical sales data
• Order date
• items ordered
• quantity ordered
• date shipped
• dollar value of sale
• Develop periodic forecast accuracy measurements by comparing actual sales with the management forecast
• Provide upward and downward forecasting in order to explode a dollar and product group forecast down to the item number level or roll upward from the item number level to obtain product group and total dollar forecast.
• Provide alternate mathematical forecasting formulas:
• Moving average
• Exponential smoothing
• Arithmetic equation
• Trend
• Trend-seasonal
• Linear regression
• Leading indicators
• Plot forecast data graphically
• Compare forecast to budgets using:
• Average selling price
• Time phased future price
• Provide an unlimited forecast horizon
• Forecast in time periods that can vary in length
• Perform forecast simulation and "what-if" alternatives off-line and produce a hard copy without affecting original forecast
• Forecast new products which do not have historical data based on management input
• "Force" the totals at the item level to equal the product group forecast
• Automatically consume the forecast with actual customer orders in order to report on forecast accuracy and/or drive MRP process.
• Enter forecast data in dollars or units
• Manually override system calculated forecasts
• Maintain a history of frozen forecast revisions
• Calculate forecasts by:
• Constant annual amount
• Historical annual sales
• Historical with percentage increase
• Weighted average
• Single seasonality factor
• Multiple seasonality factor
• Single average
• Rolling average
• Weighted average
• Generate forecasts for:
• Customers
• Products
• Product Groups
• End Items
• User defined (e.g., divisions, product lines)
• Compute:
• Average selling price
• Time phased future prices
• Gross actual selling price
• Cost
• Forecast for non uniform time periods
• Maintain multiple forecast versions
• Track and maintain seasonality factors and formulas
• Modify historical data to minimize influence of price increases and promotions

Reports

• Forecast Tracking Report – Provides historical data on actual shipments and order bookings as compared to management forecasts
• Forecast Report – Generates forecast detail for each forecasted item by time period
• Management Forecast – Generates as a summary by product line and product group with monthly and yearly totals by product group and by period for the product line
• Period Summary Forecast – Forecasts by line item within product group for each period with summaries by period for the group and yearly for line items
• Marketing Management Summary – Forecast worksheets for revisions with the following data presented:
• Product group forecast for future periods
• Historical actual for the same periods in the previous year
• Mathematical model forecast as a basis of comparison
• Forecast Audit Summary – Automatically reports the forecast accuracy by summing the forecast items within each time period, calculates an error range and reporting them as a percent of the total items on a quarterly basis or the mean absolute deviation (MAD). Also shows exceptions based on user defined exception tolerances. The report provides an overall picture of general accuracy of forecast and the degree of significance in the errors.
• Forecast Simulation Reports – Produced as a result of forecast simulation processing. The principal output is the values of smoothing constants and historical trend data, and the resulting forecast in order to select the optimum set of smoothing constants.
• Item Demand and Forecast – Presents several years of historical data (userspecified) and the next twelve periods of forecast demand for each item. Typical data elements can include YTD totals, total yearly demand and period totals with comparisons by percent between items and their total product group
• Forecast Variances - Variance from original and revised forecasts
• Production Comparisons - Variances between actual sales, production and forecasts

Inquiry

• On-line display of forecast to actual sales for user specified period:
• Item
• Product group
• Feature/option group
• Sales region/territory/salesperson
• Customer/Customer Group

Interfaces

• Master Production Scheduling - Post sales forecast data for MPS.
• Material Requirements Planning – Feeds item dependent and independent demand (e.g., service parts)
• Cost Management - Receive product costs for calculating dollar forecasts
• Sales Analysis - Receive sales history to generate forecasts
• Audit Trails
• Track all changes to forecasts for a user specific time period