1) Objective
a. To ensure network security and password protection
b. To ensure adequate safeguards to the usage of assets and data records
c. To ensure proper authorization of transaction and activities
d. To ensure segregation of Duties

2) Scope
The security policy covers all the ERP application modules, which we are currently using, including:
– Purchasing
– Inventory
– Manufacturing
– Sales
– Account Receivable
– Account Payable
– General Ledger
– System Control

3) Access Control
3.1) Security at UNIX level
All Users of the ERP system are defined that they log directly into ERP and are prevented by definitions in PROGRESS/Oracle security from exiting to UNIX. It is standard ERP practice when installation to setup the users, who directly go from the login screen to the ERP application.

3.2) Security at PROGRESS/Oracle level
Enquiry and report programs are only be available as compiled programs and we consider that no end user enquiry editing function should be available on production machines. In this context, programs should always be recompiled when they are transferred from test to production machines. Test should not be mixed in the same physical machine as production.
The PROGRESS/Oracle EDITOR gives the possibility to use PROGRESS/Oracle HELP to access the Data Dictionary and to exit into native UNIX. This can be prevented by adjusting the standard Progress/Oracle program (help.p).
To prevent Users from exiting from ERP to UNIX or starting ERP programs directly from the EDITOR, PROGRESS/Oracle should be started with the keyword startup option ( -k).

3.3) Security at ERP level
The main function here is Menu security. It is possible to define passwords per user id and/or group id. This allows effective definition of separation of function for each menu option.
Compulsory periodical password change is carried out by the system.
ERP also provides field protection. In this way, within a specific menu screen, individual fields can be restricted to specific user-ids. While all users who can access the menu can see all fields, only those permitted can change the values in the fields. Moreover, it is also possible to define entity protection for entities in the General Ledger and thus restrict which Userids are permitted to generate bookings for a specific entity.
Lastly, Progress/Oracle Editor security can be defined using menu security maintenance.

3.4) Transaction recovery, File Locking and Concurrent update
PROGRESS/Oracle provides a high degree of transaction recovery. If the basic structure of unit of work is maintained after customization, we are satisfied that ERP has effective automatic error recovery and database integrity functions. The before image log allows all failed transactions to be effectively automatically backed out in the event of program ABEND or hardware failure.
To effective recovery from severe hardware failure, we select to use the disk mirroring approach.

4) Security Control of ERP varies modules
4.1) Purchasing Module
4.1.1) Overview
The Purchasing modules make use of common database files for physical and financial inventory entries. The inventory movements are posted to the Inventory database in the same unit of work as the financial transaction being processed. For example receipt records and physical inventory receipts are posted together to the relevant databases.
ERP gives several alternatives to generate purchase planning: 1) requirements generated by MRP/DRP run, 2) requirements automatically generated by a sales order and 3) manual requisition. ERP provides several action messages if expected actions do not take place as scheduled. Moreover, ERP is dependent on the buyer to review and approve the proposals sent by MRP or DRP (Company NSO transshipment function).

4.1.2) Control
The key record in the control of the Purchase order process is the Purchase Order itself. This cannot be deleted once it is sent to the supplier until it has passed through all the status stages. Procedure staff that places PO should not allowed to perform goods receipt, which is normally perform by warehouse staff. “Purchase Order Receipt” only allows inventory to be posted to available inventory where there is an authorized Purchase Order. Also, the invoice of the supplier for which goods have been received should be authorized for payment by procurement staff.

4.2) Manufacturing Module
4.2.1) Overview
The Manufacturing module makes use of common database files for physical and financial inventory entries. The inventory movements are posted to the Inventory database in the same unit of work as the financial transaction being processed. For example receipt records and physical inventory receipts are posted together to the relevant databases.
We used it to keep trace of the whole work order operation cycle, including order creation, order release, material pick, material issued, wip status, material completed and reject status, order close.

4.2.2) Control
From the control point of view, only authorized person is allowed to create and release a work order. Production operation only allow to perform operation move, feedback transaction and cannot perform the adjustment, which is perform by supervisor level of production staff. The goods receipt transaction is performed by OQC only. All the stock location for production operation should be separated from the warehouse location. Finally, the material scrap and reject can only be performed as having properly approval per operation procedure. WO deletion should also be done by Production with properly approval or acknowledgment to Logistics and FnA Dept.

4.3) Inventory Module
4.3.1) Overview
The Inventory module, in common with the other modules that can generate inventory movements, uses the common inventory file in the total Progress database. The Financial posting generated from any inventory movements is posted to the journal in the same unit of work as the physical movement occurs.
This integration ensures that inventory movements are consistently posted both physically and financially.
ERP has provided several inventory transactions, each transaction has effect on cost updates, sales history, purchasing and supplier performance- and manufacturing- history is recorded correctly.
Most inventory movement types are pre-booked so that the transaction is controlled and authorized before any physical movement can occur. The exception, as usual, is goods received where the principal control is the existence of an authorized order.
4.3.2) Cycle Counting
On setting up inventory control file, a tolerance may be specified per ABC class. This value is used to compare quantities in inventory database with quantity in physical warehouse. All the “Cycle Count Results Entry” should be processed according to cycle count procedure.

4.3.3) Control
While the system makes full use of the integrity features of PROGRESS and of various status flags to control completeness of the goods movement cycle, there is no specific total proof of this completeness. However, a report is prepared which proves the net movement of each item with the inventory master (i.e., net transaction amount or difference between opening & closing inventory).

4.4) Sales Module
4.4.1) Overview
The sales module uses the common inventory database. All physical movements of goods are posted in the same unit of work as the financial transactions are written to the journal or the control is exercised by means of status flags, i.e., ordered, allocated, picked, shipped, invoiced, posted.
4.4.2) Pricing
The selling Price table is setup by FnA staff only, and it will be auto-captured during invoicing. Moreover, it is impossible to change the price on invoice during pick/pack/shipment/invoice posting.

4.4.3) Receipts, Sales order returns
Menu selection 3.10 is not be used for SO return, but menu 7.9.15 “Sales order shipment” with a negative quantity be used as an alternative to generate a Credit Note for the customer and to update inventory back. 7.12.13.

4.5) Accounts Payable/Receivable Modules
4.5.1) Credit Limits
Credit limits and terms are assigned to customers/suppliers. Those default values can be override on sales/purchase orders based on operation need. A warning is displayed when orders exceed allowed credit limits. When a sales/purchase order is put on hold, the operator can process any transaction until release the credit limit by FnA. “Credit limit = 0” is a default setting. Unless reset, it will not permit a transaction.
4.5.2) Integration Controls
The invoice process creates a batch of invoice journal vouchers as a controlled transaction that simultaneously updates the order and invoice status flag.
Invoice posting to the general ledger uses a review / authorization transaction that releases the journal vouchers for posting. There should be a supervisory review to ensure the release process takes place at correct intervals.
For manually generated invoices a batch total may be used on data entry as a control point to each group of invoices. A warning is displayed if the total entered does not match the control total. This warning does not oblige the clerk to change any data. However, it signifies an error.
4.5.3) Credit/Debt Collection
The credit/debt collection functions of ERP are primitive and, for example, are not designed to make sure that the right collection procedures are followed. Cost of credit and comparative credit period for main competitors should be covered by clerical control.

4.6) General Ledger
4.6.1) Overview
General Ledger transactions are either entered locally or posted from other module such as inventory, purchase, sales, AP and AP. Unposted transactions will be posted if MfgPro recognizes the transactions as completed. After posted/verify/confirm all the transaction, the calendar period will be closed in order to restrict any further transaction input.
4.6.2) Control
To ensure audit trail completeness, changes to unposted transactions should be made by entering additional journal transactions.
Total controls should be used on entering GL transactions (The sum of debit entries is compared with the transaction total calculated by ERP).
Where journal vouchers have been created by ERP sub systems such as Inventory, Invoicing etc. they can be amended by the menu 25.13.1 “Standard Transaction Maintenance.” Given the internal control benefits of integration we consider this transaction should be protected and only used in exceptional circumstances, particularly as there is no Audit Trail provided.

4.7) EDI Control
Transmission of EDI data is managed by sub-menu 35, which has a proper authorization restriction on using this sub-menu.

4.8) System Control
4.8.1) Control File
The setup of the system is highly dependent on several system parameter tables; and the configuration of modules implemented is defined in the control table.
Control files are used to set up ERP: they defined for each module how processing takes place and how it is integrated with other modules. As values don’t have (and should not) been changed after implementation, we restrict all users to access via password security.
Module control file:
– customers, – suppliers,
– salespersons, – MRP/DRP,
– employees, – Work Orders,
– taxes, – Shop Floor Control,
– inventory controls, – sales orders/Invoices
– purchasing, – Accounts Receivable,
– Accounts Payable, – General Ledger,

5) System Development and Maintenance
Refer to document “Software Change Procedure” and file “Migration.doc” for “ERP Program Migration Procedure”.

6) Disaster Continuity & Backup Management
Refer to document file “Disaster.doc” for “ERP Disaster Recover Plan” and file “Data Protection Policy.doc” for Backup Management.