From ADempiere
Jump to: navigation, search
This Wiki is read-only for reference purposes to avoid broken links.

Table of Contents{{#if: Functionality| | Functionality }}{{#if: | | [[{{{3}}}]] }}{{#if: | | [[{{{4}}}]] }}{{#if: | | [[{{{5}}}]] }} | Request{{#if: Resource Assignment Dialog| | Resource Assignment Dialog }} ⇒

The Request system is equivalent to a ticket or case. It is a way to record and respond to internal and external interactions with business partners. As a communications tool, the Request system will help your team deliver superior customer service.


Icon: Icon Request24.png
Menu: →Check Requests }}{{#if: | → }}{{#if: | → }}
Short Cut: none
Note.gif Note:

You can also access the Request system from the Main Panel by clicking the button labeled "Icon Request24.png Request: #" at the bottom of the screen.


In a data Window, the Request icon is active only if a record is displayed.

Requests must involve Business Partners.


A Request is the ADempiere equivalent of a Ticket or a Case. It is a record that is created either by:

  • a customer typing something in the website or
  • an employee directly creating the record (maybe as a result of a phone call) or
  • an email being received at a particular email address.

The Request is routed to a person or group of persons having a particular Role. Each stage in the life of the Request is logged with History records. The Request Processor will automatically create reminders and escalate to Management based on user-defined rules for that Request Type.

Creating and Opening Requests

From the Main Panel, clicking the Check Request button will open all requests that involve your logon user ID. If there are no requests active for you, a new Request record will be displayed.

In other windows, clicking the Check Request icon (Icon Request24.png) in the tool bar or selecting Go{{#if: Check Requests | →Check Requests }}{{#if: | → }}{{#if: | → }} in the menu cause a small pop-up menu to appear as shown below. The pop-up will give you the option, depending on the requests that exist, of creating a new request, opening just the active requests or all requests. Clicking on one of the pop-up entries will open the {{#if: |{{{2}}}|Request }} Window.


Request Popup.png


The request is typically specific to a single record in a particular table but they can be cross-referenced against one or more of the following tables:

  • User or SalesRep
  • Business Partner
  • Order
  • Invoice
  • Payment
  • Product
  • Project
  • Campaign
  • Asset
  • Shipments/Receipts
  • RMAs
  • Requests (to link related requests)

When a new request is created, it will automatically set these references based on the initial table. As well, the following special conditions apply:

  • if the initial table includes a reference to a Business Partner (C_BPartner_ID) the Business Partner field will be filled accordingly in the new request;
  • if the request is created from an Order Line, then the request will reference the parent Order;
  • if the initial table is the Request table, a new request will be created with the same Business Partner and the field Related Request referencing the initial Request.

{{#if: |{{{2}}}|Request }} Window

The {{#if: |{{{2}}}|Request }} Window is quite busy. Click the link to see an image and a description of the fields.

Key to the processing of the request are the following fields:

  • Due Type - The due date for a Request is set in the Date next action field. Requests, if not due, are Scheduled. When the Date next action is reached and the due date tolerance is not past, they are Due. When the tolerance is exceeded, they are Overdue.
  • Request Type - see the {{#if: Request Type|Request Type|RequestType }} Window for details. The Request Type sets due date tolerance and the actions to take when Requests are due or overdue. It is also where the default settings for the request are determined. The Request Type has a flag to set automatic creation of Bill of Material (BOM) change requests - also known as Engineering Change Requests (ECRs).
  • Status - see the {{#if: Request Status|Request Status|RequestStatus }} Window for details. The Status is a list of status entries that are either open or closed and which can be updated manually or automatically based on time. For example, the open status "Waiting on the Customer" could automatically change to the closed status "Closed" after a timeout delay.

Request Processing

The {{#if: Request Processor|Request Processor|RequestProcessor }} Window defines a Request Processor service which runs on the server. The task of the processor is to:

  • Check the request for consistency and assign the appropriate sales rep or person responsible.
  • Check the status of the requests and change the status based on due times.
  • Check the Date next action of the request and take action based on the due date such as send e-mail notices and change the Due Type accordingly. If the request is overdue, e-mails alerts will be sent to the manager (as determined in the {{#if: |{{{2}}}|Role }} Window) of the sales rep or person responsible. If there is no manager defined, it will send an e-mail to the manager of the Request Processor.
  • If the Request Type has the Create Change Request control checked, the Request Processor will check the Request Group and set the Request Change Notice and/or BOM & Formula fields to match the Request Group settings.

Request E-mail

Note.gif Note:

The automatic reading and parsing of e-mails into requests is not fully functional. There is a process called Request Email Processor that can be tested. This process could eventually be added to the Scheduler or integrated into the Request Processor.

Request notices sent as e-mail messages include the following information:

  • The messages associated with the keys "Request", "RequestDue", "RequestAlert", "RequestInactive", "RequestEscalate" suitably translated to the default language of the Client that owns the Request Processor. See the System Admin {{#if: |{{{2}}}|Message }} Window for more information.
  • The Request Summary field of the request.

Tracking and Managing Requests

The default Garden World client includes a few Performance Measures which calculate the number of open requests or total request of a particular type. These performance measures can be used to track the amount, quality (as in never late) and speed of response to customer requests. See Performance Measurement for more information.

In the Menu Tree, under Partner Relations{{#if: Request |  » Request }}{{#if: |  »  }}{{#if: |  »  }}{{#if: |  »  }}, you will find a number of windows that support and manage requests. Specifically, the {{#if: Request (all)|Request (all)|Request(all) }} Window provides the details of all requests. You will also find a process which will create invoices based on the information in the requests and another process which will re-open closed requests.

See also

For Developers

The software that controls this dialog is found in

  • base/src
  • client/src


Some of the descriptive wording originated in a document from Adaxa.