Order

Order

Description

When creating an order, great care must be taken to ensure that it is also created cleanly. This means, among other things, that an order of the type OWNER'S REQUIREMENT also absolutely needs a cost centre so that the type is completely "pronounced" and the corresponding costs can also be assigned accordingly.

ATTENTION!
Own use:
Goods that are ordered as own requirements do not end up in the warehouse or in customer provision! They are only to be used for actual own requirements (office supplies, swivel chairs)!
Customer requirements:
It is essential to specify a predecessor, i.e. a cost unit, so that the costs are also allocated accordingly. A purchase order is only created in full, i.e. receives the status triggered, when these conditions have been met.

If these conditions are not met, the order can neither be processed in subsequent documents nor printed.

Functionality

• Vendor purity
• Determination of the supplier
• Document preferences
  
• Input window
  • Quick maintenance of order prices
• List window
• Selection window
• Options window
• Document preset window
• Create order(s)

Vendor purity

Each purchase order that is generated is supplier-pure. This means the following in detail:

1. A purchase order is to be created from several different items,
   for example, from the stock and requirements list or the approved requisitions.
   
   The following happens:
   The user is asked whether an order with x items is to be created. If this question is answered with "Yes", ClassiX® sorts the items to be ordered according to the main suppliers (see Determining the supplier). Then a purchase order with the corresponding items is generated for each main supplier. The various contact persons (schedulers) are not yet taken into account. If more than one order is generated (= more than one supplier), a message is displayed showing the number of orders created and their numbers. If an order does not have a supplier, this is also displayed with the number of the order.
   
2. An order is open and several items are to be entered in a new order.
   
   There is a warning that an order is already open and you are asked whether a new order should be created anyway. If this question is answered with "Yes", ClassiX® behaves as in point 1.
   
3. An order is open and should be extended.
   
   If the question whether order no. xxx is to be extended is answered with "Yes", ClassiX® sorts the items according to the main supplier. The main supplier of the item to be inserted is then compared with the suppliers of the order. If the suppliers are identical, the item is added. If the suppliers are different, then a new order is created. The positions that then follow are dealt with in point 1: A purchase order is created for each new supplier.
   Note: In this case, if the supplier of one of the following items is identical to the original supplier, a new purchase order is still created because the currently opened purchase order is no longer the one to which it was originally intended to be added.
4. No purchase order is open and the "Extend Purchase Order" button is pressed.
   
   In this case ClassiX® behaves as if the "Create new order" button (item 1) was pressed.

Note: If orders are created "by hand", supplier purity cannot be guaranteed. In this case, the user himself is responsible for the purity of the order!

Determining the supplier

When orders are created automatically, the principle is usually to determine the A supplier as the supplier from whom orders are to be placed.

In detail, the following steps are used to try to determine a supplier. If a step delivers a supplier, this supplier is included in the order and the following steps are no longer taken into account.

1. If the order is placed from an enquiry, the supplier of the enquiry is taken over.
2. If the order is placed from the worklist, the supplier of the routing is taken over.
3. If the predecessor is a requisition that does not define an additional requirement and the part was defined as a part to be provided, then the supplier is taken from the BOM predecessor.
4. If an A-supplier is defined for the part, this is taken over. (rule case)
5. The supplier of the predecessor is taken over if no part was defined. (e.g. for text articles, the supplier defined in the requisition).
6. The supplier is attempted to be determined from the attributes of the predecessor. (HW database)
7. The supplier of the predecessor is taken over if it was defined here.

Document settings

The presetting of the voucher runs in three stages.

The first stage here is the initialisation of the mask without an order. This step is very straightforward, as all fields are cleared and only the logged-in user is set as the processor.

The second stage is the creation of the order by saving the order for the first time. Here, the standard document settings are used, which can be stored for the user, the user's cost centre or the client. This could be, for example, the cover letter or standard conditions of the client.
It should be mentioned that fields which are filled are not overwritten. For example, if the field "1st signature" was set before the first saving, it will not be overwritten by the value of the field "1st signature" of the document settings.

The third stage is to select the supplier. Here, for example, predefined fields such as vendor (specification in the vendor master) or address (P.O. Box address before street address) are filled. In addition, the standard document settings of the supplier are taken over. If, for example, another creditor or another address was selected in these document settings, the field is overwritten.
If a cover letter or footer text is taken over via the document settings, the old text module is replaced.

Input window

This window is used to maintain orders. You can select an order by entering the desired number in the Number field and confirming with RETURN. If you want to call up the list window, you can select the menu item "Search".

Toolbar

Icon	Description
	Create new order
	Save order
	Delete order
	Print order
	Print, Fax, Email. Before printing, the plausibility checks mentioned below are carried out. If there are still failed plausibility checks, the order cannot be printed. When printing purchase orders, a check is automatically made as to whether own provisions for the purchase order must also be printed.
	Display document history
	Create/edit notes
	Edit distribution list
	View approved requisitions
	Insert text modules
	Show dispo movements
	Opens the supplier agreement of the selected order item or delivery schedule from the list, for the order item of the item or the supplier that is selected on the order screen at that moment.
	Check plausibility: If an order item has been declared as a customer requirement but no order predecessor has been assigned, a message is displayed. Likewise, if no contact person has been specified on the order header. These plausibility checks are also carried out when the print dialogue is opened. If there are still failed checks, the order cannot be printed.
	There is the possibility to check via the order status list or the order header via this toolbar button whether different order items of the same variant parts with different attributes can be combined and thus a quantity discount can be knocked out of the price tables. This is possible if the attributes necessary for the price tables of the order prices are the same for all these actually differently marked variant parts. The corrected prices can then be applied to the order items after viewing them via a results window.
	Generate own provision for all/for the selected delivery schedule lines. The system checks whether own provisions have already been made for the delivery schedules. This function only takes into account parts with the logistics indicator "purchased part with own provision". For this purpose, an in-house provision bill of materials must be stored in the supplier agreement, for whose items the in-house provisions are then created here.
	Call up the copy buffer. The order items (or the delivery schedule lines) of the current order are displayed directly in the copy buffer. The copy buffer enables the order items to be dropped into the item list of another order, creating a copy of the item there. Dropping into the same order is not possible; for this purpose, the menu item "Duplicate" can be called up. Only order items of the type warehouse requirement and cost centre requirement can be copied. When dropping an order item, the supplier is taken over if no supplier has yet been selected in the order. An item cannot be inserted if the old order and the new order have different suppliers.

The order texts for the document footer can optionally be entered as text or as a Word document and combined with text modules.

The window is closed without saving changes. If you want to save the changes, you must press the "OK" button.

Quick maintenance of order prices

The window is closed without saving changes. If you want to save the changes, you must press the "OK" button.

List window

Toolbar	Icon
	new.png
	open.png
	delete.png
	CX_PRINTER_hardcopy.png
	CX_PRINTER.png
	tree.png
	pinned.png
	copytoclipboard.png

Copy all orders to the clipboard

Search for note

The window is closed.

Selection window

Search for note

The selection is cancelled.

This window is used to set the document default settings for purchase orders. The document presettings can be assigned to a user, a cost centre or the client, as well as to a partner role, for example.

sensible

Generate order(s)

If this option is set, the cost price of the order item is taken over as the order price and thus overwrites the supplier's standard order price.

Option window

Adopts the default settings as they were at initialisation, before they may have been changed by the editor.

When creating purchase orders from requisitions, it is mandatory to create a separate purchase order for each sales or production order.

Options are adopted

• Related topics
• Requirement request
• Demand requirement
• Purchase requisition
• Purchase requisition
• Order item
• Blanket order (call-off order)
• Blanket order (call-off order)
• Stock account
• Parts master
• Part master
• Purchasing overview

Goods receipt

• Technical documentation
• Overview
• Extend order process
• Implementation

• • Order base module
  • Order editing module

Order selection module

Purchase orders can be generated from approved requisitions or entered manually.

Overview

purcorde.bmp (8118 byte)

Extend order process

Interface definition:

[NULL/CX_PURCHASE_ORDER] [Vector/Collection/Object] [sender (optional)] SendMsg(APPEND:PURCHASE_ORDER)

The APPEND_PURCHASE_ORDER message expects the following parameters:

second parameter:

The second parameter passed is either the previous transaction, a CX_ITEM, a transient CX_ITEM container containing the quantity to be ordered and the date on which to order.

When expanding orders open in the background from the "approved requisitions" list, the requisition unit is ignored!

First step CreateUnsortedVector:

This macro creates a vector from transient containers.

For each object passed, this first calls the macro CheckPurchaseAtCall, which looks for a frame order for that part.

If a framework order is found, this part is not included in the unsorted vector. If no framework order has been found, a transient container is created by the macro CreateContainer, which is then also included in the unsorted vector.

CreateContainer:

Depending on the type of object passed, a transient container is created that contains all the information necessary to create an order item:
Container.supplier = Supplier
Container.quantity = order quantity
Container.purchase.date = on this date should be ordered
Container.itemPointer = CX_ITEM of the part to be ordered(not order item role!)

CheckPurchaseAtCall:

The purchase order account of the transferred part or the part of the transferred transaction is determined and checked for the type blanket purchase order.

If no framework order is found, FALSE is left on the stack and the macro is terminated.

If there is a blanket order, the macro SendPurchaseOrder is called with the transaction found, which immediately extends the order. A TRUE is left on the stack after the blanket order has been extended.

AppendPurchaseAtCall:

The framework order is called for editing, a transient container is created via the macro CreateContainer and this is sent with the framework order via the message APPEND_PURCHASE_ORDER_ITEM to extend the framework order.

ChecksPurchaseItemCasts:

After creating the unsorted vector, all required order item roles are checked. If one is not present, the entire routine is aborted and the user is prompted to enter the order data.

SplitVectorIntoSuppliers:

The unsorted vector is traversed and all suppliers occurring in it are stored in another vector.

This is now traversed so that all the following steps are performed for each supplier occurring in the vector.

If a supplier appears on the first order item to be created, or if this is different from the order to be extended, the order to be extended is reset to ZERO and a new one is created. Only if the item to be created really matches the purchase order to be extended will it be extended.

So in case the order does not have a supplier, the macro FillVectorWithoutSupplier is called first, which writes all entries into a result vector for which no supplier was found.

If all entries without suppliers were found, the macro CreatePurchaseOrderAndAppendItems , whose function will be discussed later, is called.

Then the macro FillVectorWithSupplier is called, which first checks whether a supplier has been entered on the order to be extended. If yes, then exactly this supplier is searched for in the vector and first written into the result vector. Then all other previously determined suppliers are searched for and the matching entries are saved in the result vector.

After all entries for a supplier have been collected, this vector with the associated supplier is passed to the macro CreatePurchaseOrderAndAppendItems.

CreatePurchaseOrderAndAppendItems:

The supplier of the order to be extended is compared with the transferred supplier. If this is the same, this order is sent together with the vector of sorted containers via the message APPEND_PURCHASE_ORDER_ITEMS.

If the supplier is different, a new order is generated and sent with the vector.

After the order items have been created, the complete order is recalculated. This saves a lot of time when creating several order items per order.

The uniqueID of the order is stored in a string, which is output as a summary at the end. This happens in the macro CountPurchaseOrders.

Order base module

Module name

purcorde.mod

Classes

CX_PURCHASE_ORDER

Security

Order editing module

Module name

purcoedt.mod

Classes

CX_PURCHASE_ORDER

Security

Order selection module

Module name

purcosel.mod

Classes

CX_PURCHASE_ORDER

Security