Requirement notification or internal request

The requirement notification function was developed to clearly and quickly report a specific requirement within the organization. Consolidated to the right product and documents who needs what, in what quantity and when. 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 meet the demand from current stock or not.

The requisition can take place because our employees need work equipment to complete the tasks assigned 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 minimize costs and increase transparency. Our model works regardless of whether you have stock, no stock or anything in between.

First step: The first question our users ask:

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 requirements report in the organization. Here, all employees can quickly and easily select which product is required and in what quantity from a list of products.

In the organization, specific products and articles can be designated for this purpose and thus ensure 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.

However, the product request that is outside of the permitted products is different. This request can be sent to the organization in order to manually assign the request to an existing product or to create a new product.

Second step (option): a configurable release of an individual requirement notification.
Rules can be used to request the release of a purchase requisition. This takes place immediately after the requisition has been submitted for a request to the releaser defined in the organization chart. Only after release is the requisition reserved in the warehouse / taken into account in the order proposal. This system is intended to help you to ensure that individual exceptions only have an effect on stock and the order proposal once they have been released.
Third step (optional): processing the product request function. Here you can edit the list of requirement notifications in the client. We use the Incomplete requisition selector to identify the requisitions for which a desired product is referenced. Here, the view of the individual request helps to process the process: With appropriate product rules, we can create a new product from the requisition with just a few clicks. Replacing, changing quantities or rejecting is also possible here, but can be specified in more detail via rights.
Fourth step: the reservation of the entire requisition, analogous to the order routine and visible in the order control, which requisition we can execute completely, in parts or when in the future. All products and quantities not yet in stock are calculated and shown in the order proposal, without any further action.

After processing the goods receipt, the products and articles are available via 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 notification has already been fulfilled, partially fulfilled or not yet fulfilled. Communication about "when will I receive my remaining delivery" becomes obsolete thanks to this guided process.

With this basic routine of transferring all products from goods receipt to the warehouse, we create the possibility of going through the entire process as quickly as possible; no queries or ambiguities hinder or slow 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 organize 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 use which products before we exceed a best-before date?

Employees and departments

We use the organization chart to organize 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 organizational point of view, you can make all employees in the department responsible for the requests. This screen is used to assign who can request which product.

We differentiate between the standard group, for example, if there is only one type of requirement notification, then this is sufficient and applies to the entire company. In addition, there are other groups that can be individually named and authorized to any number of employees, which we store as such in the organization chart.

Select the appropriate organizational unit.

Example: You want the entire company to request IT equipment.

Then the group is: entire company, IT equipment, organizational unit: entire company.

Allowed elements of the group are the individual products, which are managed via Add and Remove.

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

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

The product is always requested in the base unit.

We manage cost centers in the organizational chart; by referencing the organizational chart in the organizational unit, we adopt these cost centers for the internal requests.

Cost centers: Maintain in the organization chart, at the department or at the position. The organization chart knows the cost centre split system here, we only use the first entry for the requirement report, i.e. no cost centre split.

Allow products

Via Internal products, individual products can be permitted or explicitly excluded for departments, even with the idea that I assign portfolio xx to department ID 30, for example, but product ID 100408 may not be requested in this department.