Introduction

Module: Orders is intended for documenting actions accompanying the sales/purchase process. It is particularly applicable to entities that, when trading, must register incoming orders and conduct formal negotiations with the customer.

Advantages of using the module: Orders are particularly evident when considering the three ways of selling.

In the first, direct sales, the customer makes a purchase by receiving an invoice, making a payment or obtaining a deferred payment. This type of sales requires an “invoice-centric” system, meaning one that allows for quick invoicing, suggesting default prices, discount levels and conditions, and due payments. The aforementioned functions are excellently performed by the module: Sales, and the use of the module: Orders, in this case, is not necessary.

The second method is based on supplying specific goods to regular customers according to their orders. Such customers usually have specific conditions under which they make purchases. In this type of sales, the element of negotiation is rather absent, hence the use of the module: Orders, is necessary only when there is a need to register orders coming from customers.

It should be noted that if registered documents entered into Comarch ERP XL system are to serve only for reservation of goods for a particular customer (reservation size, delivery time, volume of goods ordered from the supplier), it may be sufficient to use the function: Bookings, in the module: Sales.

A third way of selling is negotiated selling. This is often the case when the goods sold are of a non-standard nature, for example goods available in selected options or consisting of selected (at the customer’s request) modules, or when sellers participate in tenders. The making of the sale is then preceded by negotiations.

The following stages can be distinguished in such a sales process:

The presented way of conducting sales does not always include all the mentioned stages. The above is only an example; depending on the needs, the sale process may take different forms of implementation.

Module: Orders is an excellent tool for efficiently documenting the activities described in the third way of conducting sales. It can register these activities in the presented order, but it can also be used in the process of sales made without a customer enquiry or offer. Due to its multi-functionality, it meets the requirements of all users for whom the element of order registration or conducting negotiations is essential in their business. It should also be noted that it serves the sales process as much as the purchasing process.

Description

Work with the following module: Orders, reflects the sales process, including sending enquiries to the seller, as well as submitting offers and orders. By enabling the generation of commercial documents from orders, it comprehensively covers this way of trading.

Sequence of actions

The documentation of activities may be done in chronological order, as follows:

In practice, it is possible to omit some of these steps. For example: it is not necessary to send a request for quotation to generate an offer, and it is not necessary to prepare an offer in advance to place an order. Please note, however, that the issuance of a commercial document can only be made from an order which has been registered in the system and confirmed.

Duality of purchase and sales orders

Module: Orders is built symmetrically. This means that to all sales documents created while working with the module: Orders, analogous documents can be assigned, but related to the purchase process.

This duality can be noticed when the following window is opened: Orders list. The horizontal tabs in this window divide the list into documents related to sales – tab: Sales orders list and with purchases – tab: Purchase orders list. On the other hand, the side tabs are common for sales documents and purchase documents and define their type (request for quotation, offer or order). From a sales order the user can prepare a purchase order (for a supplier).

As a result of preparing (generating) a purchase order, the goods items and traits on the document are rewritten from the sales order. This function shall shorten the time spent by the User on the purchase order preparation.

It should be noted that the reverse document generation is possible, meaning a purchase order can be used to prepare a sales order.

Offer variants

Offer variants means that any number of offers may be prepared for a single request for quotation. This is possible if the request for quotation concerns items which, for various reasons, need to be separated. In such a situation, it is possible to derive offers for each of the items separately from one request for quotation.

The user wants to present the buyer with several offers to choose from. Different offers for the same goods are prepared from a single request for quotation.

Bookings

In Comarch ERP XL system it is possible to reserve ordered goods. There are two types of bookings:

When generating commercial/warehouse documents, booked resources will be taken from orders.

Reservation on resources

Reservation on resources consists in binding reservations to resources in warehouses and thus blocking the linked resources. Resources are booked automatically or by indicating a resource by the operator. One reservation can be associated with one supply and warehouse. One order item may generate multiple reservations. From the order item, the assignment of supplies to the reservation can be made, changed and deleted.

The booked resource will be unavailable before the expiry date of the booking, for any operations other than the execution of the given booking.

A reservation on resources has priority over a reservation on quantity, meaning over a reservation without assigned resources.

While making a reservation on a resource, the correspondence between the traits on the document for which the reservation is generated and the traits on the resources that will be covered by the reservation is controlled. However, it is possible to link the booking to a resource that has a different trait than the product on the document.

In the reservation, it is possible to define activation and execution dates. If the user sets the execution date to unspecified then the activation date shall also change to No restriction.

Reservation on quantity

Reservations on quantity do not have assigned resources. Their order of execution is determined by priorities. If a higher-priority reservation exists in the system, a reservation with a lower priority will only be accepted for execution if, after this operation, there is still sufficient stock to complete the reservation with a higher priority.

Reservations on unconfirmed orders

When adding an item to an unconfirmed SO, the system shall immediately create the relevant booking(s). This behaviour of the system is determined by the parameter in the ZS document definition->Other tab: “Reservations on unconfirmed SO”. When editing the item, the system will modify the related reservations accordingly, meaning in the case of quantity reduction the rules for the modification of reservations will be followed as in the case of quantity reduction on a confirmed SO item, meaning: the quantity in related reservations will be reduced accordingly, while the reservations without resources will be processed first, and then – the ones with resources. In both cases the order will be: priority (from the lowest), execution date (from the latest), expiry date (from the lowest), consecutive number (from the highest).

In the case of increasing the quantity on an item, the system behaviour depends on the parameter in the document definition “Reserve resources” according to the following rules, if: the above mentioned parameter:

The aforementioned rule applies both when increasing the quantity on confirmed and unconfirmed SO.

Reservations may be modified as a result of changing the goods on the SO item that is after:

Changing the class/trait value on an unconfirmed order item

After changing the class/trait value on an item of an unconfirmed order, the system will delete the existing resource reservations, on non-resource reservations it will change the trait, finally it will generate a reservation, if necessary.

Changing warehouse on an unconfirmed order item

If the change of the warehouse on the order item consists in indicating a specific warehouse, then the system will leave unchanged those reservations for which this warehouse is set, in the case of a warehouse incompatibility, the system will disconnect the resource from the reservation, change the warehouse on it, and then maintain or remove the association of the reservation with the BST, depending on whether there is a warehouse on the BST that matches the reservation warehouse.

In case of change of the warehouse to the value <all>, the system will keep resource reservations, regardless of the warehouse on those reservations, and on non-resource reservations it will set the warehouse to the <all> option. This will maintain the links between the booking and the BST.

Changes to unconfirmed SO header and reservations

Changes made to the header of an unconfirmed SO that has reservations are reflected on those reservations, and these changes are: change of contractor, change of order owner, change of warehouse on the document, change of dates on the document, change of reservation priority, activation of the “reserve resources” function.

If the change of the warehouse in the header does not result in a change of the warehouse in the SO items (the operator gives a negative answer to the question that appears), then no changes are made in the reservations.

If the change of the warehouse on the header results in a change of the warehouse on the SO items, then for each SO element an operation is performed as in the case of a manual change of the warehouse on the item. History of goods/contractor/Bookings

On the list of bookings it is possible to distinguish by colour bookings related to an unconfirmed SO according to the following rules:

Change of the rules of “opening” an order

In connection with the possibility of registering SO in such a way that an unconfirmed order creates bookings, the action of “opening” an order, that is reversing it to the status of an unconfirmed order, has been modified. So far this operation always resulted in deleting the booking, now the system will not delete bookings from an order which was registered in the “generate a booking on an unconfirmed order” mode. In the case of an order registered in the previous mode, the reservations will be deleted.

Assigning resources for booking

On the operator’s card there is “Allocating accepted resources to reservations” parameter that determines whether the operator will be able to allocate resources to reservations when approving revenue documents.

The following parameter has been made available on the definition of revenue documents: Assign created resources for booking.

In the definition of those revenue documents where the parameter “Assign created resources to bookings” was checked, the operator will be able to select the parameter “Manual assignment” or “Propose quantity”. If the parameter is checked, then after the approval of the given document a form will appear allowing to change the proposed by the system “association” of the resources created with the given document with particular bookings. In this form, the system displays in a tree form: the individual commodities with a specific trait, those accepted into a given warehouse, and under each of them a list of reservations with which the accepted resource can be associated. By default, the order of the bookings and the quantity proposed to be associated from those bookings follows the existing rules for automatically linking bookings to the incoming resource that is the bookings will be ordered by priority, execution date, expiry date and creation date of the booking. The “Propose quantity” parameter can be edited if the “Manual assignment” parameter is checked.

As of XL 2018.1 version, if the operator closes this window without saving, such an operation will be interpreted as a complete cancellation of the allocation of resources to the reservation, of which the User will be warned with the message: “Resources will not be assigned. Do you want to close the window without saving nevertheless?”. Option YES – the function of binding resources to the reservation will not be triggered, no matter what quantities have been set in the column “Quantity to be assigned”, and the window will be closed, option NO – the window will be opened.

Until version 2018.1, when saving a form, the system assigned individual resources to a booking, with the assignment being made in a quantity consistent with the quantity set in the “Quantity to be assigned” column for each booking.

If the above-mentioned parameter “Manual assignment” was unchecked or the operator did not have the right (the parameter on the operator’s card “Allocating accepted resources to reservations” is unchecked), and in the document definition the parameter “Assign created resources to bookings” was enabled, then the system would bind the resources to the reservations without displaying an additional window.

The operator could change the order of bookings by sorting them by individual columns. They could also change the proposed quantity to be linked manually, using the edit-in-place method on this column, or by selecting one of the resource allocation options: by priority (the existing automatic allocation method), by order in the list (for example the operator sorted the bookings by one of the criteria, e.g. date of creation of the booking, and then selected this option. In this way, the system assigned resources to individual bookings in an amount consistent with the quantity in those bookings until the resource was exhausted),
or “proportionally” (the system distributed the resource in proportion to the unbound quantity for individual bookings).

The system enables the checking/unchecking of records specific to particular “groups” of resources, because the operations consisting in the change of the method of resource allocation between bookings can be performed according to particular resources and all bookings connected to them. It is not possible to check/uncheck only some reservations from a given group; that is if the user selects a particular record, all bookings that are linked to it will be selected, and if the user unchecks a particular record, all linked bookings will be deselected.

As of version 2018.1, the System’s behaviour in this regard is dependent on the “Propose quantity” parameter on the document definition. If this parameter is checked, then the System will propose, as before, quantities according to the given criterion, while if it is unchecked, no quantities will be proposed (the System will set 0.0000 as the quantity to be related on all reservations).

The above-mentioned window presents bookings which meet the following conditions:

Conditions for the sequence of SO-PO-POR/PI documents:

Conditions that must be met when linking resources to a specific reservation:

Grouping of bookings on the form for allocating resources between bookings:

If there are bookings for the given commodity and warehouse with a specific trait, then the above-mentioned bookings without the trait (but for the given commodity and warehouse) shall be linked to the group for the given commodity/warehouse for which the “resource group” with the highest, non-zero “quantity that may be booked” exists

If the above-mentioned reservations do not exist, or a “non-zero” resource group does not exist, then such a reservation shall be included in a separate group: commodity/“empty” trait/warehouse.

In the case of reservations for warehouse <all>, reservations shall be verified as follows if:

When “attaching” a reservation to the group <commodity/trait/warehouse<all>, the reservation owner will be checked, and “separate groups” will be created for different owners of those reservations if:

As of version 2016.0, the [Recalculate elements of unconfirmed ZS] parameter has been introduced. The parameter has been introduced for the functionality of promotion for a specific delivery of goods. If this parameter is checked, for each booking indicating an unconfirmed order from which the delivery is detached, the given order item will be recalculated, irrespective of the defined promotion for a specific product delivery.

The resource allocation functionality is also available for multiple identified orders at the same time. After marking specific SO documents on the list of sales orders, we can use the option in the context menu: Reserve resources. Then, the following window will appear: Assign resources for booking.

The functionality is available for indicated sales orders and internal orders.

Changes in binding resources to reservations

In version 2017.1, changes have been made to improve the functionality of automatically binding commodity resources to reservations. These changes concern both the rules for creating links between source orders/commissions and the orders/commissions generated for them and the rules for “honouring” such links in the resource reservation binding functions.

Taking into account the status of a linked order in the resource reservation function

During automatic resource binding, the System honours the links created as a result of generating an order/commission for a specific purchase sales order/commission. This means that only the deliveries established by the revenue document implementing that purchase order will be automatically assigned to the booking of that sales order. This rule has been extended in version 2017.1 to include verification of the status of such a resulting purchase order. Namely, if the order has the status of completed, closed or cancelled order, then the link to such order is ignored, as such order/commission status means that it will no longer be processed, hence the sales booking cannot “wait” for its processing. For sales reservations linked to such orders, the binding of resources follows the general rules.

The rule described above applies to the following operations:

The window of manual binding opened with the option “Reserve resources” from the list of SO/IO

The operation of linking the resources with the identified SO/IO operates independently of the parameter “Assign resources…” and refers to all the resources of the goods, not accepted by the specific document type, while the “Propose quantity” parameter automatically separates the accepted resources and specific document types.

In the case of the operation of linking resources with specific orders, the rule of default setting by the System of the “Quantity to be assigned” for individual reservations has been maintained.

The window of manual binding opened secondary to the revenue document

In the window opened with the “Distribute resources…” operation from the list of revenue documents the System presents a window identical to the one used during the approval of the given revenue document, except that it additionally presents those resource bookings which are linked to the deliveries created by this document (so that they can be unlinked here and linked to other bookings). A rule has been adopted according to which the System continues to propose Quantity to be assigned for bookings according to the existing rules, regardless of the Manual assignment parameter.

Skipping items linked when generating documents from BST

Previously, when generating orders/commissions from the Balance of goods (BST), the System always created links (ZamZamLinki) of generated items with all items that were indicated by non-resource BST sales reservations, including those for which the order/commission was already generated, either via previous BST or directly from these orders/commissions. Such a rule causes that in the situation when purchase orders are executed according to a different order than the order of generated orders, the created resources are assigned to different bookings than the User expects. In addition, for many Users the creation and presentation of all the links is illegible; the User does not always know which PO is waiting for a given SO. To avoid the above-mentioned inconveniences, an optional rule has been introduced, according to which when creating links with PO/IO/AJ/JO generated from BST, the System omits those source items of sales reservations that already have “their” orders/commissions for which they are waiting, that is for which a relevant ZamZamLink record already exists indicating an order/commission, the status of which indicates that it will still be executed.

The System’s behaviour with regard to the creation of links as above depends on the setting of the parameter “Skip already linked items” on the BST document, determined by default based on its definition.

If this parameter is disabled, the System will create links between the generated order/commission and all source items as before. Enabling it means that the System will create links only with those elements, which do not have such links yet.

Copying of orders links during their correction

Until now, when correcting an order, the information about related source or result orders/commissions was lost. As of version 2017.1 of the System, these links are copied to the correction. So, if a purchase order was generated from a sales order and then this sales order is corrected, then the order-correction will still be linked to the aforementioned purchase order. A similar rule shall also apply to a correction of a purchase order or an internal order generated for a sales order, internal order or work order. The copying of links allows efficient automatic linking of resources accepted in the execution of result orders, also in cases when they or their source orders have been corrected in the meantime.