Home / Educational Content / JD Edwards / Innocor’s Implementation of JD Edwards Requisition Self-Service

Innocor’s Implementation of JD Edwards Requisition Self-Service

Senior Business Analyst at Innocor Inc., Michael C. Johnson, shared how Innocor implemented JD Edwards Requisition Self-Service and utilizes it within the organization. Innocor is a leader in consumer specialty foam products and polyurethane foam for their commercial customers. Their customers include major bedding retailers, furniture, auto, and other manufacturers. They have 22 plants in the United States and an annual revenue of roughly $1 billion.

Drivers for JDE Implementation

Innocor was facing several purchasing issues between the 22 different plants. Some of the purchasing pains that there were dealing with included:

  • Purchases being done outside of JD Edwards
  • Purchases being done with manual Purchase Orders or no Purchase Orders at all
  • Plants doing independent purchases
  • Inaccurate GL coding for non-inventory purchases
  • Lack of management approvals for purchases
  • Not having a clear idea of the spend details
  • No centralized procurement controls
  • Invoices showing up in Accounts Payable with no Purchase Order

Solutions: Requisition Self-Service and More

To remedy this situation, Innocor developed several purchasing solutions for the issues that they were facing. One solution was to establish Corporate Procurement Policies, which stated that all purchases moving forward would require requisitions/Purchase Orders unless otherwise approved by management. This also meant that purchases would require manager review and approval based on spend limits.

Another solution was to expand the company’s use of JD Edwards Procurement in two areas—JDE MRP application and Requisition Self-Service. The JDE MRP application is used for production-related purchases, and Requisition Self-Service is used for expenses and non-production inventory purchases. Within Requisition Self-Service, Innocor also chose to leverage the Commodity Based Purchasing feature. This feature lets you divide the items that you buy into different spend categories.

Other solutions included leveraging the electronic Approval Workflow with the mobile functionality, automating GL coding for expense requisitions, and improving the spend reporting.

Requisition Self-Service Configurations

Innocor had to establish several RSS configurations. When setting up RSS, they had to look into doc types and next numbers, Commodity Structure and DMAAI setup, Programs and Versions, Process Flow, and RSS Approvals and Workflows.

Requisitions require doc types and next numbers. A separate doc type must be used for each type of requisition to be created. The four types of requisitions that Innocor utilized RSS for included inventory, expense, service, and blanket.

The Commodity Structure is used to classify expenditures. It can also denote tangible product or service requisition categories, provide a user with common items and suppliers to use in requisitions, and use GL Class Codes to assist with GL Account mapping. It will default predefined information to requisitions. The menu path for Commodity Structure is G43E31.

Innocor uses DMAAI 4318 to map Expense Commodities to GL Accounts. It will default the department business unit from the requisition. Having DMAAI set up has eliminated over 90 percent of GL coding errors on Purchase Orders at Innocor.

Innocor has different versions of requisitions that can be used. For example, users can enter a standard Requisition Entry, an Expense Requisition, a Requisition Request for Blanket PO, etc. Each version is assigned a version number in addition to the title. If users need a PO immediately, they can send their requisition through the Requisition Expeditor (P5543060—Innocor’s custom version of P43E060). If not, it can be run through the Batch Requisition Consolidation application (R43E060) that Innocor runs overnight.

The first step in the process flow for requisitions at Innocor is to enter the requisition request for purchase. From there, it moves to management review and approval. If the request is denied, it moves back to the first step to be revised and resubmitted. If it is approved, it moves on and the requisition is expedited (which will generate a Purchase Order). Once the Purchase Order is received, you will go through Voucher Match and ultimately receive the vendor payment.

When using RSS, you’ll also need to establish Approvals and Workflows. There are different Approval Authority levels. You can have approval go to a single employee, an employee group, business unit, commodity, or a combination of the options. To find the Approval Authority Constants, where you can manage constants, follow Menu Path G43E41. You can set up mailing lists for approvals and use the Approval Mailing Distribution application (P02150) to send approvals out to mailing lists. You can link these contacts to RSS through the RSS Approval Distribution Lists application (P43E09A) through Menu Path G43E31.

Once you have that set up, you have to activate the Workflow Approval Process through the Process Master application (K43E08). To find it, follow Menu Path G02 on FAT Client.

Entering A Requisition

Once you have everything set up, the final step is to actually enter a requisition. At Innocor, there is an EnterpriseOne page that contains the different types of requisitions that they handle. This is where you would go to enter a requisition. Once you have filled out the requisition information, click the “Add to Cart” button. If you are satisfied with your requisition, you can then submit it and send it through the approval process. The approver will get an email notifying them that approval is requested for a requisition. They can drill into the requisition to review it, approve it, or decline it.

Once a requisition is approved, it goes to the Requisition Expeditor (P5543060—Innocor’s custom version of P43E060). It will then be expedited to a Purchase Order. Once a Purchase Order is created, you will see a button that says, “Dispatch Orders.” Innocor developed some customization behind it, so when the user clicks the button, the system will automatically print the PO and change the status of the PO to “Printed.” It is a permanent action that cannot be undone. From there, you’ll need to review the generated Purchase Order.