Procurement settings

When importing orders: This setting determines the behaviour and process when importing orders via csv or electronic data formats and API. This allows us to speed up the process by providing information on product suppliers, i.e. which product we currently receive from which supplier at which price, under which GTIN/EAN or product number of the supplier. With the setting: Create, update, we keep our master data synchronised with that of the supplier and gain additional performance in the import process, as a product assigned once retains this assignment and gains data quality with further information and therefore does not have to be assigned in several orders.

Delivery postings require full order matching: This setting regulates the behaviour in the goods receipt process step: The order matching of the goods receipt means that a goods receipt must take place with a mandatory reference to orders and can therefore never take place without an order. In addition, the order quantity must always be matched in full when order matching is mandatory.

Product prices for deliveries: When the goods receipt is posted, we write an inventory price according to the selected valuation method and the existing master data. If there is no identical information in an order and in the product supplier entry, we use this setting to determine the source from which the stock price is to be calculated. We offer 2 options here: From the transaction data of the purchase order, or from the master data of the entries under product suppliers.

Supplier advisor: If there is a fixed desired contact person for your suppliers, through whom communication should take place and who should be referenced in documents such as purchase orders or similar, then one can be defined here in order to centralise external communication. If the individual user should always be listed as a reference in your company, please leave this entry blank.

Order BOM: The order BOM is a technical system that is central to the functionality of procurement. It is always generated when procurement is activated at the time the order is saved and contains the following information in particular:

Requested date: In contrast to the delivery date of an order, the requested date is not aimed at your customer, but primarily at you as an organisation. We understand the requested date as the date on which our customers regularly request the fulfilment of their orders and, in particular when using parts lists for the procurement of individual components, it is used to agree on a defined, clear date in communication with your suppliers. Use the default setting of: today, tomorrow etc. to pre-set the majority of orders to the correct date with minimal data maintenance. The date can still be adjusted at order level. The requested date is always included in all communication so that we endeavour to fulfil the requested date.

After updating parts lists: Parts lists for a defined product can be subject to general, dynamic or specific changes. How this change is to take effect is regulated in this setting. Starting from a defined product with a complete bill of materials, it may be necessary to adjust an individual item (because a product is not available, has a successor or because another one fits better) or to extend it because additional elements were required to finalise the bill of materials that were not previously known. We can handle this change in different ways: the automatic system offers the option of updating all orders accordingly, while the setting: update prices only, represents the other extreme and thus makes it possible to display products in different compositions on the same bill of materials.

When executing order control: This setting regulates the handling of entries for maximum stock levels. It is possible that the quantities of a product in orders are above the defined maximum stock level. The regulation of which entry has priority here follows this entry: with Ignore maximum limits we open up the possibility of fully covering your requirements from orders, even if the maximum limit could technically speak against it. The setting: Respect maximum limit reduces the order proposal in the requirement quantity to the maximum limit accordingly. Here we basically have to answer the following question: if the set maximum limits per product are of a technical nature (example: I can only store a certain amount of milk and butter, after which I run out of storage space and everything spoils), then we should respect the maximum limits. If we are not faced with such a problem, then the setting Ignore maximum limits is recommended in order to be able to fulfil all orders as quickly as possible.

Use future receipts: Affects the goods receipt and the corresponding posting of the stock. The setting No means that we post exactly the stock of the goods receipt with the posting date and this is immediately available for all orders, we calculate the planned date for the delivery of the order on exactly the delivery date. Under certain circumstances, this can lead to undesirable behaviour, as the goods are not yet available in the storage bin for order picking the second a goods receipt is deemed to have been posted. In terms of content, we can equate this function with an inbound warehouse lead time, for example, we close the goods receipt on day 1, set the future receipts to 2 days and thus have 2 days to move the goods to the storage location, the planned date of the order is pulled along accordingly. This system helps to structure your processes internally, instead of individual information on when goods have reached the storage location, to regulate the general structure via standard throughput times and possibly to bring these down to 1 day over time.

When picking is carried out: At this point we can control which events should happen. We can print a list, send a list by e-mail or both. This allows us to set the best procedure for you. We recommend printing a list centrally when using paper. If you use the warehouse app, please set 2Go: do nothing else. This system is related to the fact that we already debit the stock from the warehouse when picking is carried out.

Booking date of picking: In most cases, the booking date will be today, but if we want to start picking for the future, which is only to be executed later, we can set here, execute the picking that we have initiated today in x days.

Allow partial picking with quantities: In principle, we calculate all planning data, delivery options, etc. for the entire order, but show when we can deliver individual items in full. These are picked using the partial picking command. If we now wish to deliver in smaller units and not just pick an entire item, but a partial quantity of the item, then this setting must be set to yes. Please bear in mind that picking the quantities individually is much more expensive (internal costs) than delivering the entire order and carrying out partial picking as an exception.

Check picking: this command transfers the picking to the 2Go, warehouse app, but then above all changes the booking behaviour, see above from direct debiting with the picking command to the time at which the withdrawal is documented in the app.

Reservable product types: We distinguish between 4 different types of products in Scopevisio: Goods, Material, Right and Service. With this setting, we generate reservations for the corresponding product type for products that have a base unit. As a result, we also generate an order proposal. Take this into account in connection with the master data of products: which products should be reserved, for which products an order proposal should be generated and for which products this should not take place.