PROCUREMENT FLOW

Demand Registration

• Various departments enter their demands for different products based on consumption pattern, current product availability, forecasts and budget constraints.
• Multiple level of approval is needed within that Department based on Value, Jurisdiction and Other Parameters.

Demand Aggregation

• At CPD, Demands from various Departments are aggregated and further reworked and refined based on Overall Budget, Forecasts and Needs of other Departments and Availability of Products.
• Multiple level of Approval is needed based on Value, Jurisdiction and Other Parameters.
• This is supported by Aggregation Module.

Purchasing

• Once Demand is frozen, CPD will go for purchasing of these products.
• In our product, we support Direct Purchase Method. Provision to connect to Tender-Wizard for procuring these products through Tender Process.
• Purchase Order Tracking and Amendments are important activities that are supported.
• We support split shipments.
• This is supported by Putrchase Order Module

GRNs [Goods Receipts Notes]

• When the Supplier shipment hits the store there is a way of receiving this shipment against the PO released earlier.
• This module will support partial shipments as well as multiple shipments. It also supports Single Shipment against multiple P.Os.
• This module will perform reconciliation against POs and generate open PO positions.
• Multiple level of approval is provided within that Department based on Value, Jurisdiction and Other Parameters.

Quality Checks

• Samples of the received product will be taken for quality checks and inspection. This module will support QC related comments and option to segregate received inventory as firsts, seconds and rejects.
• At the end of this exercise, reconciliation will be done against suppler invoice and flag the same for payments.
• Based on department indents, received inventory can be reserved against those departments. This way that inventory can not be "stolen" by other departments.
• Multiple level of approval is provided within that Department based on Value, Jurisdiction and Other Parameters.
• This is supported by QC Module

Payments: Supplier Payments Generation will be made based on Funds Availability, aging of A/P items etc..Once the payment is released, a Payment Voucher will be generated to be sent to Bank/Cash Department. This is supported by Payment Module.

Indenting: When the Departments want the items, they would raise an Indent on the Store. Based on items needed, they would have an approval process.

Dispatch: Central Store would dispatch indented items against department indents if those items are reserved against that Department. Otherwise a higher approval will be needed to make the dispatch. We support Partial and Multiple Dispatches against same Indent.

Receipts: Departments when they receive the items they indented, they would do receipt of the same against Original Indent. This would close the Indent loop.

Transfer Request: When the Departments want certain items, they can inquire the availability of these items across the entire organization. If it is available in the store attached to that department, then they would create an indent on that store requesting those items. When those items are not available in the attached store but they are available in some other stores of the organization, then that Department would create a Transfer Request to the Central Authority requesting them to procure these items for them from those stores. Hence, the Transfer Request Module.

Transfer Advise: Central authority, after verifying sanctity of the Transfer Request, would send a Transfer Advise to that Store (which has the items in Store) requesting them to dispatch those items to requesting Department.

Dispatch: That store would dispatch advised items to the Intended Department.

Receipts: Departments when they receive the items they requested, would do receipt of the same against Transfer Request. This would close the transfer loop.

Repair Out: When stores want the items to be repaired, they would select the workshop and send items to that workshop with problem description and repair schedule.

Repair In: This is the Receipt Module for the "Repaired" items from workshop. Based on inspection, these items can be classified as firsts, seconds or condemned. This module would reconcile received items against workshop invoice and flag them to be released to Accounts department for payments.

Payments: Workshop payments generation will be made based on Funds Availability, Aging of A/P items etc..Once the payment is released, a Payment Voucher will be generated to be sent to Bank/Cash Department.

INVENTORY FLOW

Inventory Adjustments: : This module, under controlled environments, supports adjustments to on hand inventory. This will help in accounting for lost and founds and write offs.

Inventory Transfer: three kinds of inventory transfers can happen within a store:

• Identity change: This is because inventory is coded wrong and it's identity needs to be changed to show proper item code
• Status change. From Firsts to Seconds or Condemned etc..
• Reserve/Unreserve, Allow capability to reserve inventory against a Department and also unreserved the same if needed.
• Location change: Inventory may be moved from one location to another within that store. This will help tracking that inventory by location.

Physical Inventory

• This module supports Physical Inventory Counting Process, Reconciliation of Counts against Perpetual Inventory, and Final Overlay of Perpetual by Physical Counts.
• This module will also interface with Auditing Module and Financial Systems.

Costing: This module supports inventory costing using various methodologies like last shipment cost, average cost, rolling weighted average cost etc..Idea is to do inventory costing at any point in time. This will interface to GL system.

Perpetual Inventory Inquiry

• By stores
• By status
• Reserved inventory
• Estimation of consumption
• Average cost
• Inventory costs
• Inventory availability by time period.