The requirement request function was developed to clearly and quickly report a specific requirement within the organisation. Consolidated to the right product and documenting who needs which product, in what quantity and when. With the transparency that we were able to make a statement about which values, products and quantities were then requested and also handed over by which user in which period (optionally with project reference).

In our setup, regardless of whether we have already made the investment to cover the demand or still have to do so, i.e. whether we can fulfil the demand from current stock or not.

The requirement request can be made because our employees need work equipment to fulfil their tasks or to report a requirement from different areas in the company to the central purchasing department or warehouse. Sometimes companies decide to enter requirements manually in order to minimise costs and increase transparency. Our model works regardless of whether you keep stock, no stock or anything in between.

What is my requirement, what product do I need?

This can be accessed in the mobile application (Scopevisio app or browser view) or by calling up the requirement request in the organisation. Here, all employees can quickly and easily select which product is required and in what quantity from a list of products.

In the organisation, specific products and articles can be designated for this purpose, thus ensuring consolidation on these permitted products. Technically, the right product can be selected from a list of products (with optional display of images) or by scanning a stored product barcode.

This is not the case for product requests that fall outside the authorised products. This request can be sent to the organisation in order to manually assign the request to an existing product or to create a new product.

After selecting the product and quantity, I can assign these to a project and thus ensure which project is to be assigned to this request.

Once the goods receipt has been processed, the products and items are available from stock. Here, the allocation to the individual requirements can be carried out in the same way as picking, in an orderly, routine process, so that it is always clear which requirement request has already been fulfilled, partially fulfilled or not yet fulfilled. Communication about "when will I receive my remaining delivery" is rendered obsolete by this guided process.

With this basic routine of moving all products from incoming goods to the warehouse, we create the possibility of running through the entire process as quickly as possible, with no queries or ambiguities hindering or slowing down the routine.

All posting processes run fully automatically in the background so that it is always possible to trace who requests what, releases what, receives what from the warehouse or orders what. Throughput times can be output via reporting and serve as the basis for measures to improve process speed.

We also clarify the question of who has actually withdrawn/consumed the product, i.e. resolve the gap in time, location and/or personnel between ordering from the supplier and the moment of consumption. This opens up opportunities to organise inventory management in the warehouse differently: Inventories become less time-consuming and stock limits on products can generate order suggestions that help to prevent a product from being out of stock or insufficiently stocked. In addition, we can centrally answer the question: when should we consume which products before we exceed a best-before date?

Intervention in the purchase requisition: A purchase requisition submitted by a user can be changed by the user, who has the right to manage internal requisitions, after approval and before (partial) picking. Products can be changed, quantities changed, products added or removed. To do this, open the relevant requirement request and use the Add and Remove buttons to control which items need to be removed or added. Please do not just enter a product number here, but confirm the product selection with a tab or mouse click so that the product name, unit and price are also adopted, otherwise it will not be possible to save.

Here we organise the mapping of the structure of responsibilities for an assortment to be defined, which these colleagues are allowed to request. In the basic setup, we want the person responsible for the department to make the request. If you want to proceed differently from an organisational point of view, you can make all employees in the department responsible for the requests. This screen is used to allocate who can request which product.

We distinguish between the standard group, for example, if there is only to be one range of requisitions, then this is sufficient and applies to the entire company.

In addition, further groups can be named individually, product ranges defined and members authorised.

The group settings can relate to different warehouses and locations, all products can be permitted or prohibited by setting and the question of the release of an internal requirement can be set here.

If we want to assign a cost centre to a purchase requisition, this is possible via the organisational chart system. By displaying the company structure in the organisation chart and assigning cost centres (first entry) to jobs and/or employees, this information can be passed on and thus appears in the journal for transfer to financial accounting.

In the internal requirements groups, we select a new group, assign it to a corresponding organisational unit and immediately receive the employees of the jobs in the organisation chart as members of the group.

Here we use the lowest node of an organisation chart, which can contain several jobs and employees.

To do this, please create a job in the organisation and add an employee. We normally manage the cost centre at the position in the organisation; the assignment of an employee to the position has organisational reasons in this case.

When creating the structure in the organisation chart, please consider which areas are to be managed by which persons/users.

The organisation chart uses the cost centre split system here; we only use the first valid entry for the requirement request, i.e. no cost centre split.

In order for individual employees to be assigned as members of a specific group, the user must be created as a contact in the administration.

Groups can be assigned to an organisational unit (from the organisation chart) and thus automatically manage the cost centre/cost unit and employees assigned to the organisational unit.

We now have the option of storing a cost centre. Which of these is addressed depends on the role of the group members in the group. If they are set as group leaders, the cost centre is taken from the assigned organisational unit. For the role of member, the information is taken from the job of the individual user.

Example: I assign the organisational unit Sales East to a group, make both employees group leaders, then all movements of goods run to the cost centre of Sales East. If I declare them to be members of the group, then the movements run to the cost centres of both units.

Notes: If a user is in several groups, he can see all the products for which he is authorised in total. If there are several entries for the same product that regulate the quantity and or margin, the lowest value applies here.

Requested products that are created from the requirement request are automatically transferred to the standard group.

The use of the requirement request depends on the right of the internal request, which is currently also linked to the mobile warehouse application, i.e. the menu items Warehouse Management: Picking and Inventory

This can be organised in a material group (advantage: no extension is required if the material group is assigned additional products, these are automatically included in this request group)

We can assign a price model, internal price and an internal margin (internal margin is used to display the handling costs) via the merchandise group settings.

The product is always requested in the base unit.

Under the group settings, different locations can be addressed and the setting for the use of a release, in the delivery state we always set an automatic release.

In the standard group, for example, we allow all products for all employees, which enables quick and easy data management if we do not need to differentiate between groups.

The delivery status of the standard group is set to Allow all, in the overview in front of it you will find the settings that display the option Block all.

This means that we have to create individual groups in order to be able to control them in Portfolio.

Basically, the requirement request is used to display an individual requirement for products in order to be able to track who needed which product and when. In this way, we primarily support internal communication for the clear identification of a product, quantities and the associated goods values. Or the question: who needed which product, when, in what quantity and value, and who received it.

We find different approaches in different areas to visualise the actual consumption or dispatch from the main warehouse. If we do not document any further work steps that affect the warehouse stock after picking with the withdrawal from the main warehouse, the current basic setup applies with a so-called consumption fiction with withdrawal from the main warehouse, even if the product is still in your company and therefore in your area of availability.

If this is not sufficient for you and you would like us to document the withdrawal from the main warehouse to another outlet or location as a stock transfer so that we can show the correct stock level there via cash registers or other consumption documentation, then use the stock transfer rules.

Here we can determine that certain groups of the requirement request, or within these only certain groups of goods, should result in a stock transfer to a specific location. We document these in the journal accordingly in the picking process with details of the target location and can thus carry out an inventory at the target location, as well as connect external systems to track stock movements at all times.