Sales and Marketing#

Hierarchy management#

By using hierarchies, contacts, debtors and creditors can each be related to each other. Via views the relationship can be displayed top-down or button-up.

On both sides of the hierarchies, any number of entities can be related to each other.

In the following, accounts receivable hierarchies are discussed in detail.

Hierarchy types facility#

To be able to use hierarchies, the corresponding setup must be performed. If you get a message "Define at least one hierarchy type ..." when using hierarchies, proceed as follows:

To set up the necessary hierarchies, first call up the "Hierarchy types setup" via the application search.

Via "New" you can create a new hierarchy type using the table below:

Assign hierarchy#

To adjust the hierarchy of a customer, first call up the customer overview via the user search. Then select the desired customer and call up the customer card.

For setting a top-down hierarchy: From the ribbon, select Related - Customer - Hierarchy - Related Customers to access the Hierarchy Relationships card.

In the opened form, check if the hierarchy type filter is correct.

In the table, enter the customer number in the "Value" field or select from the list of customers by clicking [...].

Click in the next line and repeat the input to assign another relation.

For setting a bottom-up hierarchy: From the ribbon, select Belonging - Customer - Hierarchy - Belongs to Customers to access the Hierarchy Relationships card.

In the opened form, check if the hierarchy type filter is correct.

In the table, enter the customer number in the Value field or select from the list of customers by clicking [...].

Click in the next line and repeat the input to assign another relation.  

Show hierarchy#

To display the hierarchies of a customer, first open the desired customer cards. You can call up the hierarchy via the Ribbon - Belonging - Customer - Hierarchy Usage.

Select the method of use

• Associated records (top-down)
• Belongs to (Bottom-Up)

Then click Calculate.

The hierarchy is displayed

Via Manage -> Expand All/Collapse All, complex structures can be quickly displayed clearly.

Special notes#

Remarks for customers and articles can be marked as "Special note" via a code. In the sales documents, these remarks are then displayed directly in the info box.

Establishment#

In the Accounts Receivable & Sales setup, you can store a code on the "General" info tab in the "Code for special notes" field that distinguishes "special notes" from "normal" notes. It should be noted that this code can be stored differently for purchasing and sales notes and may result in a note being displayed only in the respective area.

The user can mark individual remark lines as special remarks for customers and items in their remarks in the default "Code" field by assigning the same code that is stored in the sales setup as "Code for special remarks".

Representation in processes#

Special notes are displayed in:

• Offer for sale,
• Sell order
• Sales invoice

The display is done in the infobox Sales document information of the document header for the special notes of the customers. The notes are displayed automatically whenever the customer is selected or when scrolling within the window between the documents.

The notes for articles are displayed in the Sales info box Document row information of the document rows. The display is automatic for the article used in the rows whenever the article is selected or when scrolling within the rows of the document.

Sales order types#

The variety of the kind of documents, in the sales, reaches from the offer production for new products or service, sales of rebuildings up to the spare part sales or service. In order to be able to assign the documents to all these variants, there is the "order type".

In KUMAVISION base (BOOSTER) you can manually define different order types and assign them in the documents quotation, order, delivery bill and invoice.

Sales order type setup#

To create a new sales order type, first call it up via the user search.

Then the sales order type overview opens, where you can use the "New" menu item to create and define a new order type using the table below.

Assigning dimensions to a sales order type#

In the sales order type overview, you have the option to assign a number of dimension settings to a sales order type.

To do this, select [...] - Associated - Sales order type - Dimensions.

Via the menu selection "Dimensions" the functions "Assignment for current dataset" and/or "Assignment for selected datasets" are available for the dimension assignment.

The default dimensions card opens where you can make the assignment using the table below:

Report selection by sales order type#

In addition to the use of order types as a distinguishing criterion and the presetting of dimensions, different printouts can be controlled for each order type. For this purpose, in addition to the selection of the actual document, the sales order type can also be selected in the report selection of sales, in order to then be able to store different reports accordingly, e.g. other order confirmations for spare parts orders.

To do this, first call up the "Report selection - Sales" via the user search.

Via the "Usage" you can first define for which document you want to make your setups.

In addition to selecting the actual document in the rows via the "Report ID" field, you have the option of storing different reports according to the respective sales order type via the "Report selection order types" menu item.

As in the standard report selection, it is also possible to store several reports in a defined sequence in connection with order types.

Incoming orders statistics (AE)#

For medium-sized and larger companies, incoming orders are often an important key figure for managing the company. The order backlog represents the value in the form of orders and unposted invoices minus complaints and unposted credit notes (sales often arise much later).

The incoming order is a key figure on the time line and can change with every change to the documents.

In particular, it is very difficult to retroactively determine the order intake from the posted documents and the remaining open amounts from the unposted documents, or it is no longer possible when changes are made. However, this is crucial for concrete management statements.

The management of incoming orders documents the changes of incoming orders in the following documents of the sales:

• Order
• Complaint
• Invoice (only lines that do not belong to any order)
• Credit notes (only lines that do not belong to any order)

For this purpose, the system forms "incoming order items".

Depending on the setting in the "Accounts Receivable & Sales Setup" in the "Creation Date" field, the order entry item will be created on the order date or on the work date.

In addition, it is possible to define in the setup which date should be used as the basis for changing the order entry. Changes always occur when the job has already been released once and is reopened for processing.

The order entry items are created in orders and complaints when the "Status" field is changed from "Open" to "Released" and from "Released" to "Open" (status change is executed by function in the standard system), as well as when the documents are invoiced and, if necessary, when they are deleted (if document processing is not complete).

In the case of invoices and credit notes, this is only done when the document is posted, unless the lines belong to an order or a complaint.

The following principles apply in orders and complaints:

• The status of the sales header is still open after it has been set up, and the order does not yet have any incoming order items.

• The status of the sales copy is changed to Released:

All sales lines are completely mapped in the incoming order items. The portion of the sales lines that has not yet been billed is mapped in the incoming order items with the conditions and dimensions stored in the sales line. (The portion of the sales lines that has already been billed, if applicable, was mapped with its actual value and dimensions in the incoming order items when the billing was posted.

Incoming order amount of the document = Open amount of the document + Invoiced amount of the document

The sales header status is reset from Released to Open: The incoming order items accurately reflect the billed portion of the sales lines, taking into account its correct breakdown by dimension. The portion of the sales lines that has not yet been billed is negatively reflected in the incoming order items with the conditions and dimensions stored in the sales line, thus balancing the incoming order item of the release.

Incoming order amount of the document = Invoiced amount of the document

Self-learning function Article reference#

In many cases, customers send their orders to the supplier naming their own customer article numbers. These customer article numbers can be used in the order entry in the field "Reference number", provided that they are maintained in the article or customer master under reference numbers. To facilitate the master data maintenance at this point, these reference numbers can be maintained or created in KUMAVISION base (BOOSTER) from the sales line.

For example, if a sales line has the fields * Type = Article * No. = Item number * References. = Customer article number * Unit = item sales unit * Optional variant code

are entered, the system automatically creates a reference entry for this item and this customer.

If there is already a reference entry in the system for this customer and this item number, the user is prompted whether the existing reference entry should be overwritten.

If this message is confirmed with "Yes", the existing reference entry is overwritten. If "No" is selected, the process is aborted.

Sales line DB% and cost price#

Differing from Microsoft Dynamics Business Central™ Standard, the field Cost price (MW) in the sales lines of a sales document is no longer editable by the user. It is filled from the item card or, if inventory data is available, from the inventory data.

The DB% field of the sales line is related to the cost price. It is not calculated in Microsoft Dynamics Business Central™ Standard, but copied from the item card to the sales line. It is not recalculated even if the prices and discounts of a sales line are changed. In KUMAVISION base (BOOSTER), the DB% field is calculated based on the cost price (MW) and sales price and discount of the sales line and therefore corresponds to the correct DB%.

Minimum contribution margin check at row level#

Minimum contribution margins can be stored per article category and article. If the minimum contribution margin is not reached in a sales transaction, the user receives a corresponding warning message. Within this dialog, the user is shown the minimum sales price by means of which the minimum DB (contribution margin) was reached.

Only selected users with special authorization can continue to process the transaction with a minimum DB underrun. For this purpose, "Minimum DB underrun allowed" has been set up in the user authorization. Depending on the user's authorization, a message or error message is displayed if the minimum DB is not reached.

The check for minimum DB is performed according to this hierarchy: * Article * Article category

Establishment#

User setup#

In the user setup, it can be defined per user whether the sales transaction can be processed further if the minimum DB is not reached. Depending on the user's authorization, a message or an error message is displayed if the minimum DB is not reached.

To perform this setup, call up the "User setup" via the user search. Activate the field "Minimum DB underrun allowed" on the respective user setup card on the info tab "KUMAVISION" if the user should be allowed to continue processing in case of an underrun. The user will receive a message in the process in case of a shortfall.

If the switch is disabled, the user will receive an error message and will not be allowed to continue processing.

Care Minimum cover contribution#

To use the minimum contribution margin check at the line level for the sales transaction, either the minimum DB must be maintained on the item card or in the respective item category.

Article card#

To set the minimum contribution margin on the item card, on the "Prices and sales" info tab, in the "Minimum DB%" field, enter the percentage value that should be achieved at least in each sales transaction.

Article category#

The article category can be used for grouping the contribution margin. Each article belonging to the article category will receive the same minimum contribution margin rate. To set the minimum contribution margin for item categories, enter the percentage value that should be achieved at least in each sales transaction in the "Minimum DB%" field of the respective item category.  

Minimum contribution margin check at document level#

Minimum cover contributions can be checked at the document level in addition to the line level check.

When a sales order is released, the system checks whether the entire order falls below a specified minimum contribution margin. Analogous to the check at line level, only selected users can fall below the minimum contribution margin.

For this purpose, "Minimum DB underrun allowed" has been set up in the user setup. The release authorization for document or rows minimum DB underrun cannot be set up separately. The check for minimum DB at document level is performed according to the following hierarchy: * Debtor * Sales order type * Accounts Receivable & Sales Facility

With this hierarchy, the data is checked in the sales document, and the minimum DB is set for the sales document that is found first in this order.

Establishment#

Accounts Receivable & Sales Facility#

The setup of a generally valid minimum contribution margin for sales documents is done in the Accounts Receivable & Sales setup.

To do this, first call this up via the user search. On the info tab "KUMAVISION" in the field "Minimum DB %" you can define the desired minimum contribution margin percentage for the sales documents.

Sales order type#

In the sales order type, the minimum DB % is stored in the field of the same name.

Debtor#

The minimum DB % for sales documents can be stored on the customer in the "Invoicing" info tab.

Process#

If a sales document is entered for a customer and a minimum DB for documents is stored, the user will receive a corresponding warning message if this record is not reached in a sales transaction.

Within this dialog the user is shown the minimum DB that must be reached and which DB the document currently has.

Only selected users with special authorization can continue to process the transaction with a minimum DB underrun. For this purpose, the field "Minimum DB underrun allowed" has been set up in the user setup.

Depending on the user's authorization, a message or an error message is displayed if the minimum DB is not reached.

The check for the minimum DB is triggered by the release of the document. If a document is not released manually, the minimum DB at document level is not checked, e.g. when creating an advance payment invoice without prior release.  

Archive#

In order to track the undercutting of minimum DBs at document level, there is a so-called release archive at the document. To be called up via the Navigate/Releases archive menu ribbon

This makes it possible to track in detail who released an order that fell short of the minimum DB and when.

In addition, this information is also displayed in the Sales Document Information infobox. Here the user also receives information about how high the minimum DB must be and where this specification comes from.

Display of contribution margin information in the info box of the document rows#

Infobox "VK Line Contribution Margin Details#

In the info box "VK line contribution margin details" you can see data about the contribution margin for the respective customer in relation to the corresponding article. The following data can be displayed at row level in the info box: * No. (Item number) * Line amount (MW) * Line amount (MW) without VAT * Cost price (MW) * Cost amount (MW) * Contribution margin (MW) * DB % * Min. DB % * Minimum DB Origin * Shortfall released  

Infobox "Sale voucher information#

In the info box "Sales document information" you can see data on document level concerning the contribution margin for the respective customer in relation to the entire order. The following data can be displayed at document level in the info box: * Pretext * Post text * Sell to Deb. Note * Rech. to Deb. Last VK * Contribution margin * DB % * Minimum DB % * Minimum DB Source * DB undercut. released by

Info box "Sales history for sale to customer".#

In the "Sales history for sales to customer" info box, the customer sales history is displayed with the number of documents that are currently available in the system. The date filter limits the number of vouchers that can be viewed directly by clicking on the respective number.

The date filter is set up via the Accounts Receivable & Sales setup. To do this, first call this up via the user search.

In the "Archiving" info tab, you can specify the desired formula, e.g. -1Y, in the "Sales history date formula" field.

The info box always calculates back from the current date for the duration of the date formula.

If you click on the number of orders in the info box, for example, the customer sales history card will open.

The map is divided into 3 sections:

Filters:
In the filter area, the currently applied filters are set for the data displayed further below. You can change the document selection directly from here and, for example, switch from orders to posted invoices.

Number of vouchers:
Displays the total number of the respective sales documents available in the system.

Debtor Sales History:
In this area, all documents are listed in detail with number and all lines. If you have opened the window from a sales document, you can use the "Copy to document" row function to copy selected rows directly into your current sales document. Alternatively, you can use the "View document" row function to open the documents in Microsoft Dynamics Business Central™.  

Post booking data#

The "Post posting data" function allows you to subsequently correct the posting data in sales orders that have already been delivered but not yet invoiced.

To do this, make your corrections in the corresponding document and execute the "Post entry data" function in the menu ribbon.

When the function is executed, the fields from the open document are transferred to the posted delivery and the associated article, material and value items for all sales order lines that have already been delivered but not yet invoiced.

The following fields are taken into account during the transfer: * Business posting group * VAT business posting group * Product posting group * VAT product posting group * Dimension Set ID * Global dimension code 1 * Global dimension code 2

Print sales documents only for released documents#

When the sales documents are released, the system runs through several checks. Among others, the mandatory field check and the check for pricing. In Microsoft Dynamics Business Central™ Standard it is possible to print open documents as well. In KUMAVISION base (BOOSTER) printing is possible only for released documents. The exception here are the sales quotations and the print preview.

Preparation of offers to contracts#

In order to create offers to prospects, i.e. contacts without an accounts receivable assignment, they can be entered using an accounts receivable template.

Accounts receivable templates are created in the Financial Accounting area.

To create an offer to a prospect, the "Create offer" function is selected in the action area. An offer is drawn with the contact's data and opened directly. At this point, a template can be selected in the "Sales to deb. template code" field. This will be taken over into the offer.

The offer can also be created without creating a customer. In this case, the customer must be created only when converting to an order.

Moreover, offers to contacts can be created and released in KUMAVISION base (BOOSTER) without the need to create a debtor.

Blanket order management#

In the standard Microsoft Dynamics Business Central™, orders can be retrieved directly from a blanket order. This is also possible in partial quantities. However, it is very inconvenient that all blanket order lines are always transferred to the order. If a blanket order now consists of many lines and only two lines have a retrieval quantity <> 0, it is difficult to find these lines in the order between all the lines. Or the user has to delete the unnecessary lines afterwards.

In the standard system, the prices are taken from the blanket order during transfer. However, if the quantity is subsequently changed again in the order, the normal price calculation takes place and the price can change. In practice, however, this is not desired because the price is fixed by the blanket order. See also section "Price origin".

Contrary to the standard, this functionality retrieves only those lines in an order that are marked by the corresponding quantity entry in To Deliver. The sales pricing in the created order is set to blanket order so that no new pricing is carried out if the quantity is changed. When entering an article in a quotation or order, a note is issued if there is already a blanket order for the article and customers.

Assignment of blanket order to sales order#

In order to assign these to the new order after the message in the sales order that blanket order lines exist for the customer, the relevant blanket order no. is entered in the blanket order no. column in the sales line. You will be asked whether the sales price and line discount % should be taken from the blanket order line.

If you confirm with Yes, the corresponding conditions will be transferred. If you confirm with No, the price of this line will be kept as entered in the order.

For better traceability for the user, the quantities that have already been called off to orders are displayed in the blanket order itself. The remaining quantity of the blanket order that can still be released is also displayed in the blanket order. For this purpose, the fields Quantity in order and Remaining quantity less order in blanket order have been created.

This is necessary because the Microsoft Dynamics Business Central™ standard does not set the quantity delivered until the sales delivery of the associated order is posted.

If an attempt is made to retrieve a higher quantity from the blanket order via the order than is available in the remaining quantity less order, a corresponding error message appears:

Framework agreements#

In addition to blanket orders, which are always clearly related to the customer, there are also so-called block orders in KUMAVISION base (BOOSTER).

In contrast to blanket orders, several customers can call off on a common blanket agreement. It should be noted here that the customers are linked to each other via a hierarchy type, and the outline agreement applies to the customer and to customers subordinate to him. The outline agreements are not relevant to requirements, i.e. they are not taken into account in the purchase order or planning worksheets. Only as soon as a call is made on such an outline agreement is the resulting sales order a source of requirements. Stocking in the warehouse must therefore be controlled via the planning parameters or additional sales planning for these articles.  

Establishment#

In order to be able to use the function of the framework agreement, some facilities are necessary. To do this, first call up the Accounts Receivable & Sales setup via the user search.

Number series#

For the framework agreements, it is necessary to store a number series. To do this, enter the number series for the framework agreements in the field of the same name in the "Number series" info tab.

If you have not previously defined a number series for the framework agreements, you can do so via the field - display from complete list, catch up and assign afterwards.

Hierarchy type code#

In the "KUMAVISION" info tab, you have the option to define the hierarchy type code for the outline agreements in the "Outline agreement. Hierarchy type" field.

Create framework agreement#

To create a new framework agreement in the system, first call up the framework agreements via the user search.

You can create a new framework agreement via "New" in the ribbon.

After opening the new framework agreement card, the system will automatically assign a new framework agreement number from the stored number series by clicking in the "Customer no." field. Otherwise, this can be changed manually by the user by an individual identifier.

Now select the desired customer in the "Customer no." field, for which the framework agreement is valid.

If the master agreement applies to several customers, then the master agreement must be issued to the main customer. The associated customers must be linked to the main customer via the hierarchy type. In the fields "Description" and "Description 2" a free text for the internal description of the framework agreement can be entered.

In the fields "Valid from" and "Valid until" the validity period of the agreement is defined.

The lines of the agreement are then entered. If necessary, the framework agreement takes into account listings that are stored at the customer(s).

In the lines, the total quantity per article is stored, which can be retrieved by all customers over the validity period. As an alternative to a defined article, an article price group can also be entered. In orders, the respective exact article is then retrieved from this article price group.

Prices and discounts are specified in the framework agreement lines. These are always net prices, since the function of framework agreements is only required in B2B business. Prices including VAT are only required by default in retail and thus in the end customer business, where, however, framework agreements do not occur.

After completing the entry, the framework agreement can be released via the Release action in the menu ribbon and printed via the Confirm action.

Call off framework agreements#

Outline agreements are called off from an order or quotation.

For this purpose, the article in question is entered in an order or quotation. The user receives a note that a framework agreement exists for this and that this can be called up.

If the framework agreement is entered in the sales document line, the price and discount from the framework agreement are updated in the sales document.

From the outline agreement, it is possible to see in which sales documents quantities are currently called or have already been called. For this purpose, the line function order lines, invoice lines, etc. is called up.

After expiration, a framework agreement can be terminated. It is then deleted from the list of current framework agreements and written to the archive of terminated framework agreements. To do this, call up the End function in the Actions ribbon in the framework agreement.

This process cannot be undone. However, the "Copy framework agreement" function can be used to copy a terminated framework agreement to a new framework agreement. This can be done including header and lines or selectively (analogous to the function Copy document from the sales area).

Commission Management#

Basic#

Commission management is based on the posted sales documents (invoices and credit memos). Only sales that ultimately end in a posted sales document in the document flow are therefore included in commission settlement. (For example, sales that are entered and posted manually as invoices in financial accounting ledgers are not taken into account).

The center of a commission settlement is the standard table Seller / Buyer. It is possible to inherit both a first and a second salesman directly from the accounts receivable, or to adjust these fields before posting in the documents that have not been posted yet.

If only one field is filled with a value, the commission management logic will be executed only for this salesperson. If both sellers are entered, it will be calculated for each. There are no mutual influences of the commission settlements between the two salespersons.

The sales code applies to all lines of a sales document together. It is not repeated in the lines of the unposted document.

In addition, with the help of the various setup options, the commissions can be set as a function of customers, customer groups or even products and product groups as well as responsibility units. Net or gross amounts or contribution margins can be used as the basis for calculation.

Due to these different setup constellations, the commission arrangements can be used flexibly.

Establishment#

Seller#

Each salesperson must be created in the Salesperson/Purchaser table. These salespersons are then assigned in the "Salesperson code" or "Salesperson code 2" fields on the "Commission" info tab when creating an account.

Commission groups#

With the help of commission groups, both customers and products can be grouped and commissioned separately.

This classification into commission groups is inherited in the sales process in the posted documents.

Accounts receivable commission groups#

Codes and corresponding descriptions can be assigned in the Customer Commission Groups table. These codes can then be stored in the customers under the Commission tab.

Product commission groups#

Analogous to the grouping of customers, items can be freely grouped in the Product commission group table. The set up groups can be selected in the item card under the Prices and Sales tab.

A product commission group can be assigned to each G/L account, article, resource, asset and article surcharge (in the field of the respective table) in order to achieve standardization here as well.  

Commission rates#

The commission rates regulate the applicable commissions of the sellers. Here different classifications can be combined with each other. These entries are used to determine the valid applicable commission rates for the posted document lines.

Hierarchy commission rates#

If a posted sales document row is to be commissioned, all valid commission rates for the data of the posted sales document row are determined first. If several commission rates apply to the data of a posted sales document line, the following applies for determining the commission rate to be ultimately applied:
* For all 3 classifications, the following applies independently: A special rule beats a general rule (e.g. an entry for a special customer beats an entry for a special customer commission group. This in turn would have already beaten an entry "All debtors". * If a valid special entry for products exists, it has a higher priority than a special entry for customers. This in turn has a higher priority than a special entry for a seller.

Commission rates in connection with a unit of responsibility behave as follows for corresponding combination hits:

• If no combination of salesperson and unit of responsibility is found in the commission rates, the combination All salesperson/unit of responsibility is used for the calculation.

• If the combination of salesperson and unit of responsibility is maintained in the commission records, the corresponding commission rate of the combination (salesperson / unit of responsibility) is used for the calculation.

• If no unit of responsibility has been defined specifically for the salesperson, the specific (combination salesperson / no unit of responsibility) commission rate will also be used for the calculation.

Creation and analysis#

Commission Book Sheet#

Book commission#

On the basis of the posted document lines, a proposal can be made periodically by means of a book sheet as to which commissions should be paid to which salesperson for which document and in what amount.

Via 'Build commission' in the menu ribbon, the book sheet can first be filled. There are several options for this: * Document date filter * Only consider invoices / credit notes if customer item status: here you can choose between closed or open, open and closed. It is taken into account whether an incoming payment has already been posted or whether the customer item is still open. * Settlement for: both seller code, seller 1 or seller 2

In addition, the booking date and, if necessary, a booking description must be selected. In addition, other filters can be set in relation to the seller, to the header of sales invoices and to the header of sales credits.

The fill run analyzes all posted document lines with a sales code where no commission has been posted so far, and determines the valid commission rate.

With the logic of the commission rates described above, different commission agreements can be agreed at the same time with different levels of detail. As already described above, this has the consequence that due to the flexible system several commission rates may be applicable for one commission case. In the lower part of the book sheet the number of valid commission rates is displayed. These are displayed via the lock-up. Thus, no summation of the found commission rates takes place.

The book sheet rows can be edited manually.

Subsequently, the so-called commission items are formed by posting. In addition, a check mark is placed in the column 'Commission booked salesperson 1' (or salesperson 2) in the posted invoice lines for each salesperson. This prevents a commission from being made twice.  

Cancel commission#

Commission items can be cancelled. To do this, select the corresponding line in the Commission items table and click the 'Cancel items' function in the ribbon. Via a posted Invoice - Related - Invoice - Commission items, these can also be cancelled.

The cancellation causes the deletion of the checkmark 'Commission booked salesman 1' (or salesman 2) in the posted document lines. This allows you to retrieve a commission settlement again at a later time and correct it if necessary.

Commission journal#

The generated commission items can be evaluated in reports. The printed commission reports form the internal company basis for the settlement of the commission to the salesperson (a transfer to payroll or purchasing documents with salesperson as vendor is no longer part of the commission management). For this purpose, the 'Provision' menu offers various reports: * Commission journal * Commission settlement (according to commission groups) * Commission settlement (by voucher).

The commission journal only shows the posted commission items. The commission statements, on the other hand, show the commission per salesperson. The commission statement by commission group also breaks down commission by group. For creation, filters can be made on the items - for example, on the posting date and on the seller.

Alternative lines in offers#

In the offers there is the possibility to mark lines as alternatives. To do this, select in the article line in the column "Alternative = Alternative". Their prices are not included in the total price and can be displayed graphically differently in the printout.

Validity period in the offer#

This functional area extends the standard in that a validity date can be entered in the offers. You can maintain this date manually on the quote card on the "General" info tab in the "Valid until date for quote" field.

Or the validity date is calculated automatically. In order to be able to use this functionality, it is mandatory that an additional validity formula has been stored in the Accounts Receivable & Sales setup in the "Offer validity formula" field on the "General" info tab.

When converting the offer into an order, the user will be notified that the validity has been exceeded by means of the stored validity formula. However, the offer can still be converted into an order.  

Quotation status#

In addition, a status management for quotations has been integrated, so that a quotation status can be assigned to the quotation. When creating and converting an offer into an order, a defined status can be set automatically (e.g. NEW or ORDER). This setup is set under "Offer status".

Delete and archive quotes#

In sales, many quotations are often written, but (unfortunately) not every quotation results in an order. If the offers are not converted to an order, they remain in the system and have to be deleted manually. In order to facilitate this work, a batch processing function has been implemented in KUMAVISION base (BOOSTER), which deletes completed offers.

The call "Delete expired offers" can be found in the offer overview in the menu ribbon under the menu tab "Actions" > "Offer".

Click on the menu item "Delete expired sales offers". A query window opens. Here you can now specify whether the offers that are to be deleted should be automatically archived beforehand. You also have the option of using the filter criteria to narrow down the offers to be deleted.

For example, you could only delete offers whose validity has expired. In addition, it may make sense to filter for a specific seller code. When you confirm the query with "OK", you will be asked again whether you really want to delete the offers.

Confirm this with "Yes".

Zero positions#

Basically, the system prevents unintentional invoicing of orders with an amount of zero in a line.

This can be circumvented by using the zero positions. If an invoice with zero is nevertheless necessary e.g.: for goodwill or warranty, these lines can be declared accordingly in the field "Zero position". The invoice is then possible and instead of the price the option value of the zero position is printed.

Optionally, the amounts present in the line can be kept and a line discount of 100% can be inserted automatically, or the amounts can be set to zero. A corresponding prompt appears to select these options.

Proforma invoice on order#

Especially in the export business it is necessary to provide the forwarder or the customer with a proforma invoice before delivery. For this purpose KUMAVISION base (BOOSTER) offers the possibility to print such an invoice in the order.

Establishment#

Accounts Receivable & Sales Facility#

Since a proforma invoice must normally always have a number printed on it, this is controlled in the Accounts Receivable & Sales setup.

To do this, call up the Accounts Receivable & Sales setup via the user search. Then activate the checkbox "Get invoice no. when printing pro forma invoice" on the info tab.

Report selection sale#

In addition, a report ID must be selected in the Sales report selection for the pro forma invoice.

Printing proforma invoice#

The printing of the proforma invoice from the order is done via the "Actions" > "Booking" > "Proforma invoice" ribbon.

When printing a pro forma invoice from the 'Sales order, the next invoice number to be used is drawn and a "P" is appended. This number is then used up in the number series and can no longer be used for a posted invoice. Otherwise, the proforma invoice is a copy of the order confirmation with the difference that the text modules are printed that would also be printed with an invoice.

Use sales order confirmation Planned delivery date#

This function allows you to control whether the "Planned Goods Issue Date" or the "Planned Delivery Date" should be printed on the order confirmation.

The definition is done globally in the Accounts Receivable & Sales setup via the field "Print Planned Goods Issue Date or Planned Delivery Date" on the info tab "KUMAVISION".

Reference to order doublet#

Similar to the reference to existing quotations and blanket orders, a reference to an order duplicate can also be issued for orders.

Establishment#

Accounts Receivable & Sales Facility#

In order to receive these notes, the setup period order duplicates must be set in the Accounts Receivable & Sales setup. To do this, first call up the Accounts Receivable & Sales setup via the user search. The field "Period of order duplicates" on the info tab "General" defines the period of time in which the system looks back from the work date to see if the same article has already been entered in an order for a customer.

Sales order types#

The message only appears if you are working with sales order types at the same time. For this purpose, the "Note on entered orders" checkbox must be set in the sales order type.

Order duplicate check#

If an order is now entered for a customer with the corresponding order type, the system uses the Created on field on the order line to check whether other order lines exist within the defined period with the same article and the same order type. If this is the case, the system issues a corresponding message.

Create orders for direct delivery / special order from the order#

This service area extends the standard process for direct deliveries and special orders. Contrary to the standard, either orders for direct delivery or special order can be created from an order for selected lines.

Direct delivery#

You can use direct delivery (also called drop shipment) to have ordered goods delivered by your supplier directly to your customer. To create the order for direct delivery from the sales order, proceed as follows.

First, create a new sales order for the desired customer and add the corresponding items to the sales item rows as usual.

Mark the sales item lines as "Direct delivery" by checking the "Direct delivery" box.

Via the ribbon > Action > Schedule > Generate direct delivery you can generate the corresponding purchase order.

The selection of which sales lines are to be transferred is controlled by the "Direct delivery" field, as in the standard system. For this reason, only lines with the Direct delivery indicator are transferred when you call up Direct delivery. The selection window for the vendor opens. It is preset with the default vendor. Confirm with OK to generate the order.  

Special order#

A special order is used as soon as you, for example, order a special production for a customer from your supplier, but this is not to be sent directly from the supplier to the customer after completion, but to you, e.g. to be checked by your quality assurance.

First, create a new sales order for the desired customer and add the corresponding items to the sales item rows as usual.

Mark the sales item lines as "Special order" by checking the "Special order" box.

Via the ribbon > Action > Schedule > Generate special order you can generate the corresponding purchase order.

The selection of which sales lines are to be transferred is controlled by the "Special order" field, as in the standard system. Therefore, when called up under Special order, only lines with the Special order indicator will be taken over.

The selection window for the vendor opens. It is preset with the default vendor. Confirm with OK to generate the order.

Prices#

Price information in the contact management#

Especially in the telephone sales of trading companies, a quick price statement is indispensable. The user can call up the following information directly via the "New customer price information" function:
* Item availability * Pricing of the item for the corresponding customer * Storage of the price or the agreed discount in the master data * Provide price information and save it * Display of existing price information (also already expired)

To call up the price information, open the desired contact card and then execute the function "New customer price information" via the menu ribbon under Link.

The price information card opens.

Fill in the price information card according to your request using the table below:

On the basis of the price and discount data taken or, if necessary, modified, the line amount without VAT is calculated, which serves as a price information for the customer.

The non-editable fields Line Amount (MW) without VAT, Cost Amount (MW), Contribution Margin (MW) and Contribution Margin % show the user the total values for this price request.

The editable fields Remark, Minimum quantity, Start date and End date are used to permanently store the prices or discounts with these details for the customer in the sales prices or discounts.

To save prices, you can use the Save sales price function in the ribbon. If the check mark is set in the field Save information automatically when exiting, the price will be saved automatically.

The line discounts are saved analogously via the Save line discount function.  

Price origin#

In the sales documents, the "Price origin" field is available for information on the price of origin. Depending on the origin, the following information is given in the "Price origin" field:

Analogous to the price origin, the line discount origin field is stored per line. The basic logic and sense of the price origin are applied accordingly to the discount origin.

Saving prices to documents#

Often, due to the high number of potential articles, price maintenance in the retail sector is not carried out in advance, but customer-specifically within an offer. Especially with regard to the tele-sales area, prices are agreed by telephone and stored in the system.

The Save Prices / Discounts section gives the user the possibility to conveniently save the prices individually agreed within an offer or order, so that they are directly available to the article the next time it is used.

To save the individual prices within an offer or order, proceed as follows:

First create an offer / order with the desired article lines. In the columns "Sales price" or "Line discount" the values with the agreed prices/discounts are changed.

Then select the rows for which you want to save the prices / discounts. Using the "Rows" info tab, select the menu item Row - Price / discount calculation - Save price / discount.

The "Save sales price / line discount" mask opens on which you activate the "Save prices" and "Save line discounts" buttons. In addition, further options for saving the prices are available which can be activated/deactivated individually. Then confirm your selection with "OK".

If "Show prices after creation" was activated in the previous mask, the Sales prices mask opens. Here the prices can be checked again and edited if necessary. Otherwise, you will be returned to the sales document.

If "Show line discounts after creation" was activated in the previous screen, the Sales line discounts screen opens. Here the prices can be checked again and edited if necessary. Otherwise, you will be returned to the sales document.  

Sales conditions#

Sales conditions are a new form of price or discount definitions. The Sales Condition application area allows you to flexibly calculate the Sales Price and Line Discount % fields in the sales line using freely definable calculation lines.

You can define the costing lines in a standardized way already in the master data.

Sales conditions allow you to variably calculate a sales price or a line discount % in a sales price or sales line discount, and ultimately a variable price or discount calculation in a sales line.

Sales conditions are first defined as an independent dataset in the sales master data and then assigned to one or more records in the Sales Price or Sales Line Discount tables, depending on whether the sales condition is used to calculate a sales price or a line discount %.

Plant sales conditions#

To create a new sales condition, access the sales condition overview via the application search and click on "New".

A new sales conditions card opens where you can create the desired sales condition using the tables below.

Inforegister General#

Sales condition subform#

The sales condition rows define the calculation steps for calculating a sales price or a sales discount when applying the condition. When defining the sales condition rows, note in particular that the sequence of the subsequent processing of the calculation steps for calculating the sales price or line discount % is determined by the sequence of the rows you have entered in the window.

Example 1:
Sales condition 001
Knife discount -10%Calculation subsequent percentage

Basic condition + 5%Calculation subsequent percentage

Result:
The cost price of the item is valued at 3.040, -€.
10 % of 3.040,00 = 304,00
3.040,00 - 304,00 = 2736,00
5 % of 2736.00 = 136.80
2736.00 + 136.80 = 2,872.80

Example 2:
Sales condition 001 Trade fair discount -10%Calculation net percent Basic condition + 5%Calculation net percent

Result:
The cost price of the item is valued at € 3040.00
10 % of 3.040,00 = 304,00
3040,00 - 304,00 = 2736,00
5 % of 3040.00 = 152.00
2736.00 + 152.00 = 2,888.00

Via the action "Translations" you have the possibility to store a translation for the individual calculation descriptions. This translation will be used instead of the German description when transferring to the documents, provided that a language code is stored in the document. If no translation is available, the German description is always used.

Assignment sales condition in sales price and sales line discount#

The assignment of a sales condition to a record in the "Sales price" or "Sales line discount" table is always done via the "Sales condition no." field. The currency of the condition must match the currency of the "Sales price" or "Sales line discount ".

Records in the "Sales price" table with the "Sales condition no." field filled in always have the value 0 in the Sales price field in the master data, the price is calculated when entering the data in the sales lines. The same applies to the "Sales line discount" table and the line discount % field there.

The calculation of the sales price or the line discount % always takes place at runtime when the respective data record is used in a sales document with its data.

Sales prices or sales line discounts with specified sales conditions#

The sales prices with specified condition number are used like normal sales prices to determine the best price. Whether or not a sales price is taken into account as a valid sales price for pricing in a special sales document is therefore not dependent on the sales condition data. Only the value of the sales price is determined dynamically and the sales price then participates with this determined price in the best price determination.

Function: "Get sales price" in sales document#

The "Get Sales Price" function, available by default in every sales document, lists for the user's selection the records of the Sales Price table applicable to a sales line. The user can select a specific sales price and transfer it to the sales lines, thus manually bypassing the automatic sales price determination when entering the item no. or sales line quantity.

The same applies analogously to the "Get line discount" function (can also be called in the sales document.) The function has been extended in that when a data record from the "Sales price" table with an assigned "Sales condition no." is displayed, the value calculated on the basis of the sales line data using the sales condition lines is now displayed instead of the 0 defined in the master data. This applies to each row of the window that refers to a sales condition.

If a sales price is included in the best price determination, the currency and the unit of the sales line may differ from the currency and the unit of the data record of the Sales Price table. Therefore, the Sales price table has been extended with the information "Currency code (Calculated)", "Unit code Calculated" and "Sales price (Calculated"). The first two fields contain the data of the sales line from which the calculation call has been started. The "Sales price (calculated)" field contains the calculated sales price in the currency and the unit of the sales line, unlike the default "Sales price" field which contains the price in the currency and the unit code of the "Sales price" (master data) record.

By clicking on the Assist button in the Sales condition no. field, you can branch out to a window that shows the application of the sales condition up to the sales price determined in this way and thus makes it comprehensible. The same applies in analogy to the Sales line discount table. Transfer of the sales condition data to the "Sales price/discount calculation line" table. If a sales condition is found during the sales price determination, the data of the sales condition rows are transferred to a sub-table of the sales row ("Sales price/discount calculation row" table). This applies both when using the best price determination by the application and when using the "Get sales price" function by the operator. The same applies here again analogously for the discount determination.

The user can display the records of the "Sales- Price/Discount calculation row" table in a window and also edit them. The parameters can be changed, rows can be deleted and rows can be added.

In addition, if necessary, it is possible to call on a completely empty calculation in the sales line and transfer by function the lines of any condition selected by him.

Editing is always done in a temporary environment, which allows the user to simulate his change and - if he does not like the effect of his change - to discard it completely and restore the previous state before calling the window. By confirming with OK, the changes made are transferred to the sales line, the changes are retained, these can be called up again and edited. The same applies here again for the application of the sales discounts. The sales line contains 2 calculated fields "Sales price calculation available" and "Sales discount calculation available" (both Yes/No). The fields are not initially displayed in the sales line, but can be selected by the user and show the user whether or not there is a respective calculation for the line.

Transfer "Sales price/discount calculation line". when copying, posting, archiving, delivery call-off, etc.#

The data records of the "Sales price/discount calculation line" table are also transferred to the posted documents and archived documents during posting and archiving. These can be displayed read-only from the posted or archived document to the respective line of the document.

Price units#

The price calculation of a document line of the sale from the standard system is based on the formula:

Net amount = quantity * sales price * (100 - discount%) / 100

In practice, other calculation formulas are also encountered. An example of this is the price calculation using price units. Typically, this price calculation is used for goods that have a very low unit price, e.g. screws. When using price units, the price information of the document line must always be interpreted in the unit code of the document line.

Example 1:
The basic unit of the article is Piece, the unit of the document line is also Piece. The price in the document line is given in multiples of 1000 (= price unit). The price entered by the user is to be interpreted as the price for 1000 PIECES.

Example 2:
The basic unit of the article is Piece, the unit of the document line is Package. The unit PAKET is defined in the table of article units for the article, where 1 PAKET = 50 PIECES. The price in the document row is given in multiples of 1000 (=price unit). The price entered by the user is to be interpreted as the price for 1000 PAKET.

In addition, the user can already manage the prices agreed with the customers in the master data by specifying a price unit.

Article price groups#

In view of the fact that in wholesale identical articles are not to be priced individually in both purchasing and sales, but a price is to be stored for an entire group of articles with the same price, the functionality of the article price groups is a time saver and a reduction in the amount of maintenance required for pricing.

An example of an item price group can be colors. A group of colors of the same container always costs the same, no matter if it is red, yellow or green color. Thus, price maintenance in sales can be done via an article price group "color". The prices stored via an article price group are fully integrated into the pricing routine in Microsoft Dynamics Business Central™.

Price agreements for item price groups can be recorded in the same way as item prices, i.e. in particular:

• the sales type can accept all options (All customers / Customer price group / Special customer) even for item price groups,
• Campaign awards are supported,
• Customer hierarchies are supported (see chapter Hierarchies),
• Sales conditions are supported,
• Quantity-based, date-based and currency-based prices are supported,
• unit-dependent prices are also supported, as follows: If a price (defined for an article price group) is to apply to a special article unit, this must be stored in the line. It is up to the user to ensure that this unit is then also defined as an article unit for the articles of this article price group.

To define an article price group, call up the "Article price groups" via the user search.

Via "New" in the ribbon you can define a new item price group using the table below.

Once the article price group has been successfully created, you can use the "Ribbon - Belonging - Article price group - Sales prices" to enter the prices for each customer or customer group of the article price group in the same way as for standard price maintenance.

Graduated prices#

The calculation of the value of the Sales price and Sales line discount % fields of the sales line is based on the price and discount agreements between the customer and the item stored in the master data in the Sales price and Sales line discount tables.

The possibilities of price and discount agreements are very diverse. For example, agreements for all customers, for customer groups or for special customers can be stored on the customer side and agreements for article groups or for special articles can be stored on the article side.

If the user enters an item in a sales line in a sales document for a customer, the application automatically calculates the value of the Sales price and Line discount % fields of the sales line. The calculation is done by comparing the value of the Quantity field of this specific sales line with the minimum quantities stored in the mentioned master data, and thus running a best price determination among all the sales prices or line discounts found.

In principle, the standard system carries out the best price determination described above separately for each sales line of a sales document. In practice, it can happen that the user enters one and the same article several times in one sales document. This may be necessary, for example, if the item is to be delivered on different delivery dates. This industry solution therefore extends the price or discount determination of Microsoft Dynamics Business Central™ in that not only the quantity of the specific sales line that the user is currently entering is used for the price or discount calculation of this line, but the sum of the quantities in all sales lines of the same sales document with the same item number. Price relevant fields for this sales line functionality are:
* Type and no. * Variant code * Unit code and quantity per unit * Alternative with value \<empty> * Allow line discount and allow calculation discount

Only those sales lines that have the same values within these fields will be used for summation via the Quantity field.

As a rule, sales lines with the following values are not included in the totals
* Delivery no. or return no. with value not equal to <empty>.
(i.e. invoice or credit memo lines that have been created by a delivery schedule) * Blank frame order no. with value not equal to .
(i.e. order lines that refer to a blanket order line) * Alternative with value not equal to <empty>

Via the action Update scale prices the scale prices are calculated. The calculation of the scale prices always takes place also with the release of the document.

If the sales price or line discount % is changed manually in a document line, neither the price discount nor the line discount will be recalculated when calculating the scale prices for these lines. Moreover, this line is not included in the total quantity for the calculation of the scale prices and discounts.

This also applies to document lines with a link to a blanket order or blanket agreement, as well as to alternative lines and when invoicing posted deliveries or returns.

If, exceptionally, no distributed scale price determination is to take place in a document, this function can be switched off via the switch Price/discount minimum quantity per line. This can be necessary, for example, if you want to explicitly show the quantity scale prices or discounts to a customer in an offer.

If lines have already been entered in the sales document, the system asks whether this change should be made. Confirm with Yes if you want to switch off scale pricing for the document.

Prices/discounts depending on the type of order#

For different sales situations (e.g. the differentiation of an article sale in the "new customer business" and in the "spare parts business") it is necessary to be able to agree also on different conditions (prices and discounts) for this.

Therefore, in KUMAVISION base (BOOSTER) it is possible to store the sales prices and line discounts depending on the sales order type.

Sales prices The article sales prices can also be stored depending on the respective sales order type. These prices are then taken into account during pricing if the corresponding sales order type is specified (in the sales header).

You can specify the sales order type in the field of the same name in the respective sales price line for the required item.

When a sales order is created with the corresponding sales order type, the corresponding price is determined for the item line.

Sales line discount Analogous to the sales prices, the sales line discounts are maintained. These can now also be stored depending on the sales order type.

Debtors resource prices#

Customer-specific prices can also be stored for resources in KUMAVISION base (BOOSTER). The call of the resource prices is done via the customer or the resource.

Resource prices can be created per customer, per customer price group or for all customers. They apply to specific resources or a resource group and, like item prices, can be given a start and end date.

The logic of best price determination or, depending on the institution, no best price determination also applies to the resources VK prices.

Close prices and discounts#

The correct price and discount determination depends on the use of start and end dates in the corresponding sales price and line discount tables. In KUMAVISION base (BOOSTER), the most recent price always applies as the currently valid price, all other things being equal. Analogously, this is also true for the line discounts.

In principle, it is possible to provide existing price or discount entries automatically with an end date, as soon as an entry with a new start date and the same constellation is made. This makes it easier for users to understand the price or discount found.

To do this, the "Prices and discount" switch on the KUMAVISION info tab must be activated in the Accounts Receivable & Sales setup.

If a new price or a new discount is entered in the corresponding table with a new start date, the system automatically sets the end date to 1 day before the new start date in previous entries that have the same constellation and did not have an end date before.

Best price determination controllable#

In Microsoft Dynamics Business Central™, the so-called best price determination applies. This means that in the customer/article constellation, the system always finds the most favorable price and discount available for the customer that is valid at the time of document entry. A so-called net best price determination is made, i.e. the lowest combination of sales price minus line discount is taken. If necessary, a higher sales price that is eligible for line discount is taken and not a lower sales price that is not eligible for line discount. This also applies to KUMAVISION base (BOOSTER).

However, there are often customers who are excluded from this rule, but receive individual prices slightly higher than the prices generally available in the system.

For this reason KUMAVISION base (BOOSTER) offers the possibility to switch off the best price determination either generally for all customers or customer specific. Switching off the best price determination corresponds to a hierarchical pricing.

Facility general#

In the "Accounts Receivable & Sales Setup" on the "General" info tab, the "Best price determination" field is used to control whether and to what extent best price determination should take place.

The Best price determination field can be assigned the following option values:

Setup controlled best price determination at the debtor#

If the setting "according to customer" is selected in the Accounts Receivable & Sales setup, it must be specifically defined for the respective customer whether the best price determination is to be switched off for this customer.

Activating the "No best price determination" checkbox on the "Invoicing" information tab will always result in the customer-specific price being found for this customer, even if it is higher than the generally valid sales price.

If a new sales document is created for a customer that has the "No best price determination" identifier, the sales document now also (automatically) receives the "No best price determination" indicator in the "Invoice details" info tab.

The (pre-)assignment is done as follows:

In the respective sales document, this default can only be changed by the user if the "Best price determination" field is set to "always" or "according to customer" in the Customers & Sales setup (if set to "never", the field is blocked for entry/change). You can therefore reactivate best price determination in the document if necessary, even if the customer is not normally designated for best price determination.

Pricing behavior#

Several prices can be stored for one article (e.g. for different scale quantities and customers, customer groups, all customers, etc.), all of which are valid in principle.

If best price determination is required, the system automatically finds the most favorable price for the customer for a document line.

Example: The customer orders an item. The system determines the best price for the customer. If no best price determination is desired, the system will not (anymore) find the most favorable price for the customer for a document line, but the most specific customer price.  

Pricing date#

The pricing date in the offer, order and complaint is the order date. For credit notes and invoices, the posting date is the pricing date.

The prices in case of a non-best price determination (hierarchical price determination) are found according to priority.

1. Hierarchy level: The lowest hierarchy level of a customer has priority over the next higher level. This only applies when working with customer hierarchies, e.g. in the context of association structures.
2. Sales type: Campaign, Customer, Customer price group, All customers
3. Sales order type: sales order type filled, no sales order type
4. Type: article, article price group
5. Variant code: Variant code filled, no variant, This only comes into effect when working with variant codes for articles.
6. Unit code: Unit code filled, no unit code
7. Currency code: Currency code filled, no currency code This is only used if the customer works with foreign currencies.
8. Responsibility unit code: Responsibility unit code filled, no responsibility unit code.
9. Minimum quantity
10. Start date: Newest start date, Older, Start date not filled

If a campaign is selected in the sales document, the other active campaigns of the customer are not taken into account in pricing. These campaign prices have priority over all other prices. If no campaign is selected in the document, only the campaigns for the customer/contact of the sales document are taken into account, not for all customers in the hierarchy.

First, pricing takes place at the level of the customer. If the customer belongs to another customer in a hierarchy, this customer is not considered for the time being. If no valid price is found at the customer level, the search continues at the next hierarchy level. If the customer belongs to several customers on the next level, an error message is displayed. The number of hierarchy levels is unlimited. If no valid price is found at the customer level, the search continues at the customer price group level using the same logic.

The following logic applies within a layer:

A price with a variant has a higher priority than a price without a variant, provided that the type of sale and the type are the same.

The same applies to the currency: first the price with currency, then without currency. But this criterion comes after the variant.

After that, the minimum quantity is compared: The higher minimum quantity (within the validity) is taken.

Finally, the start date is checked: A newer price has a higher priority than an older one. Basically, only prices valid on the order date are taken.  

Behavior of the discount determination#

Discount determination with and without best price determination works in the same way as price determination.

Pricing according to hierarchies#

In the best price or best discount determination, entries from customers higher in the hierarchy are also included (see also "Managing hierarchies"). In order to be able to use this functionality, the hierarchy type code to be used in pricing must first be defined in the "General" info tab in the Accounts Receivable & Sales setup.

All customers stored via the defined hierarchy type code are then taken into account accordingly in the price/discount determination. The best price and the best discount in the corresponding combinations (validity, minimum quantity, units, currency, unit of responsibility...) are transferred to the document line. It does not matter in which hierarchy level the price was determined. If necessary, different prices (customer price, customer price group price, etc.) are determined in the different hierarchy levels.

Pricing by unit of responsibility#

This service area extends the two standard modules Sales Prices and Sales Discount by the possibility to define them also per responsibility unit. I.e. both prices and discounts can be different for different units of responsibility. To do this, the desired unit of responsibility must be maintained in the "Unit of responsibility code" field in the corresponding sales price or sales discount line.

UK suggested retail price#

Advanced fields in Advanced Sales Price Proposals#

The function "Extended sales price proposals" include the price fields extended in KUMAVISION base (BOOSTER): * Price unit * Current UK price (price unit) * New UK price (price unit) * Unit of responsibility * Sales order type

The fields are taken into account when calculating the price proposal as well as when saving it in the sales price table.

Sales price proposal based on sales conditions#

When creating the sales price proposal, the new price can be calculated in Microsoft Dynamics Business Central™ based on factors to be entered manually. However, in KUMAVISION base (BOOSTER) there are already sales conditions for the calculation of sales prices, see Sales Conditions. These sales conditions can be used to create the sales price proposal instead of the factor.

Procedure: The "Suggest item price..." function is called up in the Extended Sales Price Suggestion. The option cannot be set for the Suggest item price option. In the options, the calculation base must be set to Sales condition and in the Sales condition code field the desired sales condition is selected, on the basis of which the new prices will be calculated. Only conditions of the type Price condition and without currency code can be selected. Quantity factors are not taken into account. After the action has been performed, the new prices are proposed in the book sheet and can be transferred to the sales price table according to Microsoft Dynamics Business Central™ Standard.

Prices (from version 20.0)#

Function management setup#

The new price management must first be activated in the function administration. To do this, call up the "Function administration" via the user search.

The "Function update: New sales pricing" function must be set to the "All users" value in the "Activated for" column.

Price information in the contact management#

Especially in the telephone sales of trading companies, a quick price statement is indispensable. Users can call up the following information directly via the "New customer price information" function:

• Item availability
• Pricing of the item for the corresponding customer
• Storage of the price or the agreed discount in the master data
• Provide price information and save it
• Display of existing price information (also already expired)

To call up the price information, open the desired contact card and then run via the "Belonging" > "Prices and discounts" ribbon, select the "New price information" function.

The price information card opens. Fill in the price information card according to your request using the table below:

On the basis of the price and discount data taken or, if necessary, modified, the line amount without VAT is calculated, which serves as a price information for the customer.

The non-editable fields Line Amount (MW) without VAT, Cost Amount (MW), Contribution Margin (MW) and Contribution Margin % show users the total values for this price request.

The editable fields Remark, Minimum quantity, Start date and End date are used to permanently store the prices or discounts with these details for the customer in the price list.

To save prices, you can use the "Save sales price" function in the ribbon. If the "Save information automatically when exiting" field is checked, the price will be saved automatically.

The line discounts are saved in the same way using the "Save line discount" function. During the execution of the function, a duplicate check is performed first. If a customer/article/variant combination already exists in the selected price list, users will be informed about it in a separate mask with the possibility to remove these price lines.  

Price origin#

In the sales documents, the "Price origin" field is available for information on the price of origin. Depending on the origin, the following information is given in the "Price origin" field:

Analogous to the price origin, the field "Line discount origin" is stored per line. The basic logic and sense of the price origin are applied accordingly to the discount origin.

Saving prices to documents#

Often, due to the high number of potential articles, price maintenance in the retail sector is not carried out in advance, but customer-specifically within an offer. Especially with regard to the tele-sales area, prices are agreed by telephone and created in the system.

The Save Prices / Discounts section gives users the option of conveniently saving the prices individually agreed within an offer or order, so that these are directly available to the article the next time it is used.

To save the individual prices within an offer or order, proceed as follows:

First create an offer / order with the desired article lines. In the columns "Sales price" or "Line discount" the values with the agreed prices/discounts are changed.

Then select the rows for which the prices / discounts are to be saved. Via the "Rows" info tab, select the "Row" > "Linked information" > "Price / discount calculation" > "Save price / discount" menu item.

The "Save sales price / line discount" mask opens on which you activate the "Save prices" and "Save line discounts" buttons. In addition, there are other options for saving prices that can be activated/deactivated individually.

Meaning of the mask fields for discounts:

Then confirm your selection with "OK".

Sales conditions#

Sales conditions are a new form of price or discount definitions. The Sales Condition application area allows you to flexibly calculate the "Sales price" and "Line discount %" fields in the sales line using freely definable calculation lines.

You can define the costing lines in a standardized way already in the master data.

Sales conditions allow you to variably calculate a sales price or a line discount % in a sales price or sales line discount, and ultimately a variable price or discount calculation in a sales line.

Sales conditions are first defined as an independent dataset in the sales master data and then assigned to one or more records in the price list, depending on whether the sales condition is used to calculate a sales price or a line discount %.

Plant sales conditions#

To create a new sales condition, access the sales condition overview via the application search and click on "New".

A new sales conditions card opens where you can create the desired sales condition using the tables below.

Inforegister General#

Sales condition subform#

The sales condition rows define the calculation steps for calculating a sales price or a sales discount when applying the condition. When defining the sales condition rows, note in particular that the sequence of the subsequent processing of the calculation steps for calculating the sales price or line discount % is determined by the sequence of the rows you have entered in the window.

Example 1:

Sales condition 001Knife discount
-10% Calculation of subsequent percentageBasic condition
+ 5% Calculation of subsequent percentage

Result:

The cost price of the item is calculated as 3.040, -€10
% of 3.040,00 = 304,003040,00
- 304,00 = 2736,005
% of 2736,00 = 136,802736,00
+ 136,80 = 2.872,80

Example 2:

Sales condition 001Knife discount
-10% Calculation net percentageBasic condition
+ 5% Calculation net percentage

Result:

The cost price of the article is calculated as 3040,00 €10
% of 3.040,00 = 304,003040,00
- 304,00 = 2736,00
5% of 3040,00 = 152,002736,00
+ 152,00 = 2.888,00

Via the action "Translations" you have the possibility to store a translation for the individual calculation descriptions. This translation will be used instead of the German description when transferring to the documents, provided that a language code is stored in the document. If no translation is available, the German description will always be used.

Assignment sales condition in sales price and sales line discount#

The assignment of a sales condition is always done via the field "Price condition no." of the respective price list. The currency of the condition must be the same as the currency of the "Sales price" or "Sales line discount".

Price list records with the "Sales condition no." field filled in always have the value 0 in the "Sales price" field in the price lists, the price is calculated when entering it in the sales lines. The same applies to the "Line discount %" field.

The calculation of the sales price or the line discount % always takes place at runtime when the respective data record is used in a sales document with its data.

Sales prices or sales line discounts with specified sales condition#

The sales prices with specified condition number are used like normal sales prices to determine the best price. Whether or not a sales price is included as a valid sales price for pricing in a special sales document is therefore not dependent on the sales condition data. Only the value of the sales price is determined dynamically and the sales price then participates with this determined price in the best price determination.

Function: "Get price" in sales document#

The "Get Sales Price" function, available by default in every sales document, lists the price list records applicable to a sales line for users to select. Users can select a specific sales price and transfer it to the sales rows, thus manually bypassing the automatic sales price determination when entering the item no. or sales row quantity.

The same applies analogously to the "Retrieve line discount" function (also callable in the sales document). The function has been extended to the extent that now when displaying a data record of the price list with assigned "Sales condition no." instead of the 0 defined in the master data, the value calculated on the basis of the data of the sales line using the sales condition lines is displayed. This applies to each row of the window that refers to a sales condition.

If a sales price is included in the best price determination, the currency and the unit of the sales line may differ from the currency and the unit of the data record of the price list. Therefore, the Sales Price table has been extended with the information "Currency code (Calculated)", "Unit code Calculated" and "Sales price (Calculated"). The first two fields contain the data of the sales line from which the calculation call has been started. The "Sales price (calculated)" field contains the calculated sales price in the currency and the unit of the sales line, unlike the default "Sales price" field which contains the price in the currency and the unit code of the "Price list" (master data) record.

By clicking in the Sales condition no. field, you can use the hyperlink to go to a window that shows you the calculation of the sales condition up to the determined sales price. The same applies in analogy to the sales line discounts.

Price unit#

The price calculation of a document line of the sale from the standard system is based on the formula:

Net amount = quantity * sales price * (100 - discount%) / 100

In practice, other calculation formulas are also encountered. One example is the price calculation using price units. Typically, this price calculation is used for goods that have a very low unit price, e.g. screws. When using price units, the price specification of the document line must always be interpreted in the unit code of the document line.

Example 1:

The basic unit of the article is Piece, the unit of the document line is also Piece. The price in the document line is given in a multiple of 1000 (= price unit). The price entered by users is to be interpreted as the price for 1000 PIECES.

Example 2:

The basic unit of the article is Piece, the unit of the document line is Package. The unit PAKET is defined in the table of article units for the article, where 1 PAKET = 50 PIECES. The price in the document row is given in multiples of 1000 (=price unit). The price entered by users is to be interpreted as the price for 1000 PAKET.

In addition, users can already manage the prices agreed with customers in the master data by specifying a price unit.

Article price groups#

In view of the fact that in wholesale identical articles are not to be priced individually in both purchasing and sales, but a price is to be stored for an entire group of articles with the same price, the functionality of the article price groups is a time saver and a reduction in the amount of maintenance required for pricing.

An example of an item price group can be colors. A group of colors of the same container always costs the same, no matter if it is red, yellow or green color. Thus, price maintenance in sales can be done via an article price group "color". The prices stored via an article price group are fully integrated into the pricing routine in Microsoft Dynamics Business Central™.

Price agreements for item price groups can be recorded in the same way as item prices, i.e. in particular:

• the sales type can accept all options (All customers / Customer price group / Special customer) even for item price groups,

• Campaign awards are supported,

• Customer hierarchies are supported (see chapter Hierarchies),

• Sales conditions are supported,

• Quantity-based, date-based and currency-based prices are supported,

• unit-dependent prices are also supported, as follows: If a price (defined for an article price group) is to apply to a special article unit, this must be entered in the line. It is up to the user to ensure that this unit is then also defined as an article unit for the articles of this article price group.

To define an article price group, call up the "Article price groups" via the user search.

Via "New" in the ribbon you can define a new item price group using the table below.

After successfully creating the article price group, you can define the prices via the menu ribbon using the menu item "Prices" > "Sales prices" in the same way as for standard price maintenance.  

Graduated prices#

The calculation of the value of the "Sales price" and "Line discount %" fields of the sales line is based on the price or discount agreements between the customer and the item stored in the price list.

The possibilities of price and discount agreements are very diverse. For example, agreements for all customers, for customer price groups / customer discount groups or for special customers can be stored on the customer side and agreements for article groups or for special articles can be stored on the article side.

If users enter an item in a sales line in a sales document for a customer, the application automatically calculates the value of the "Sales price" and "Line discount %" fields of the sales line. The calculation is performed by comparing the value of the "Quantity" field of this specific sales line with the minimum quantities stored in the aforementioned master data and thus runs through a best price determination among all sales prices or line discounts found.

In principle, the standard system carries out the best price determination described above separately for each sales line of a sales document. In practice, it can happen that users enter one and the same article several times in one sales document. This may be necessary, for example, if the article is to be delivered on different delivery dates. KUMAVISION base (BOOSTER) therefore enhances the price or discount calculation of Microsoft Dynamics Business Central™ in that not only the quantity of the specific sales line that the user is currently entering is used for the price or discount calculation of this line, but the sum of the quantities in all sales lines of the same sales document with the same item number.

Price relevant fields for this functionality of the sales line are:

• Type and no.

• Variant code

• Unit code and quantity per unit

• Alternative with value <empty>

• Allow line discount and allow calculation discount

Only those sales lines that have the same values within these fields will be used to calculate totals via the "Quantity" field.

As a rule, sales lines with the following values are not included in the totals

• Delivery no. or return no. with value not equal to <empty>. (i.e. invoice or credit memo lines created by a delivery schedule).

• Blank frame order no. with value not equal to <blank> (i.e. order lines that refer to a blanket order line)

• Alternative with value not equal to <empty>

Via the action "Update scale prices" the scale prices are calculated. The calculation of the scale prices always takes place also with the release of the document.

If the sales price or line discount % is changed manually in a document line, neither the price discount nor the line discount will be recalculated when calculating the scale prices for these lines. Moreover, this line is not included in the total quantity for the calculation of the scale prices and discounts.

This also applies to document lines with a link to a blanket order or blanket agreement, as well as to alternative lines and when invoicing posted deliveries or returns.

If, exceptionally, no distributed scale price determination is to take place in a document, this function can be switched off via the switch Price/discount minimum quantity per line. This may be necessary, for example, if you want to explicitly show a customer the quantity scale prices or discounts in an offer.

If lines have already been entered in the sales document, the system asks whether this change should be made. Confirm with "Yes" if you want to switch off scale pricing for the document.

Prices/discounts depending on the type of order#

For different sales situations (e.g. the differentiation of an article sale in the "new customer business" and in the "spare parts business") it is necessary to be able to agree also on different conditions (prices and discounts) for this.

Therefore, in KUMAVISION base (BOOSTER) it is possible to store the sales prices and line discounts depending on the sales order type.

These prices are then taken into account during pricing if the corresponding sales order type is specified (in the sales header).

You can specify the sales order type in the field of the same name in the respective sales price line for the required item.

When a sales order is created with the corresponding sales order type, the corresponding price is determined for the item line.

Analogous to the sales prices, the sales line discounts are maintained. These can now also be stored depending on the sales order type.

Debtors resource prices#

Customer specific prices can be stored in KUMAVISION base (BOOSTER) also for resources. The call of the resource prices is done via the customer or the resource.

Resource prices can be created per customer, per customer price group or for all customers. They apply to specific resources or a resource group and, like item prices, can be given a start and end date.

The logic of best price determination or, depending on the institution, no best price determination also applies to the resources VK prices.

Close prices and discounts#

The correct price and discount determination depends on the use of start and end date in the corresponding price lists. In KUMAVISION base (BOOSTER) always the newest price is valid, otherwise the same constellation as the currently valid price. Analogously, this is also the case for line discounts.

In principle, however, it is possible to automatically assign an end date to existing price or discount entries as soon as an entry is made with a new start date and the same constellation. This makes it easier for users to understand the price or discount found.

To do this, the "Close prices and discounts automatically" switch must be activated on the Prices info tab in the Accounts Receivable & Sales setup.

If a new price or a new discount is entered in the corresponding table with a new start date, the system automatically sets the end date in previous entries that have the same constellation and previously had no end date to 1 day before the new start date.

Best price determination controllable#

In Microsoft Dynamics Business Central™, the so-called best price determination applies. This means that in the customer/article constellation, the system always finds the most favorable price and discount available for the customer that is valid at the time of document entry. A so-called net best price determination is made, i.e. the lowest sales price and the best line discount for the customer are used. Prices and discounts are always independent of each other in the price list. Therefore, it may happen that a sales line including line discount is used for best price determination only with the price or the stored line discount with another line (price or discount). This is also valid for KUMAVISION base (BOOSTER).

However, there are often customers who are excluded from this rule, but receive individual prices slightly higher than the prices generally available in the system.

For this reason KUMAVISION base (BOOSTER) offers the possibility to switch off the best price determination either generally for all customers or customer specific. The deactivation of the best price determination corresponds to a hierarchical price determination.

Facility general#

In the "Accounts Receivable & Sales Setup" on the "Prices" info tab, the "Price calculation method" field is used to control whether and to what extent best price determination should take place.

The "Price calculation method" field can be assigned the following option values:

Setup controlled best price determination at the debtor#

Independent of the general definition of best pricing in the Accounts Receivable & Sales setup, a different pricing method can be defined for a specific customer.

You can define this on the respective customer card via the "Price calculation method" field. The options are analogous to those in the Accounts Receivable & Sales setup.

If the "Without best price determination" option is set, it will cause that the customer-specific price will always be found for this customer, even if it is higher than the generally valid sales price.

If a new sales document is created for a customer, the sales document will now also (automatically) receive the valid pricing meta in the "Invoice details" info tab.

The following hierarchy applies to determine the price calculation method:

1. Manual entry in the sales document

2. Debtors card

3. Debtors price group

4. Accounts receivable and sales facility

Pricing behavior#

Several prices can be stored for one article (e.g. for different scale quantities and customers, customer price groups, all customers, etc.), all of which are valid in principle.

If best price determination is required, the system automatically finds the most favorable price for the customer for a document line.

Example: The customer orders an item. The system determines the best price for the customer. If no best price determination is required, the system does not (any longer) find the most favorable price for the customer for a document line, but the most specific customer price.

Pricing date#

The pricing date in the offer, order and complaint is the order date. For credit notes and invoices, the posting date is the pricing date.

The prices in case of a non-best price determination (hierarchical price determination) are found according to priority.

1. Hierarchy level: The lowest hierarchy level of a customer has priority over the next higher level. This only applies when working with customer hierarchies, e.g. in the context of association structures.

2. Sales type: Campaign, Customer, Customer price group, All customers

3. Sales order type: sales order type filled, no sales order type

4. Type: article, article price group

5. Variant code: Variant code filled, no variant, This only comes into effect when working with variant codes for articles.

6. Unit code: Unit code filled, no unit code

7. Currency code: Currency code filled, no currency code This is only used if the customer works with foreign currencies.

8. Responsibility unit code: Responsibility unit code filled, no responsibility unit code.

9. Minimum quantity

10. Start date: Newest start date, Older, Start date not filled

If a campaign is selected in the sales document, the other active campaigns of the customer are not taken into account in pricing. These campaign prices have priority over all other prices. If no campaign is selected in the document, only the campaigns for the customer/contact of the sales document are taken into account, not for all customers in the hierarchy.

First, pricing takes place at the level of the customer. If the customer belongs to another customer in a hierarchy, this customer is not considered for the time being. If no valid price is found at the customer level, the search continues at the next hierarchy level. If the customer belongs to several customers on the next level, an error message is displayed. The number of hierarchy levels is unlimited. If no valid price is found at the customer level, the search continues at the customer price group level using the same logic.

The following logic applies within a layer:

A price with a variant has a higher priority than a price without a variant, provided that the type of sale and the type are the same.

The same applies to the currency: first the price with currency, then without currency. But this criterion comes after the variant.

After that, the minimum quantity is compared: The higher minimum quantity (within the validity) is taken.

Finally, the start date is checked: A newer price has a higher priority than an older one. Basically, only prices valid on the order date are taken.

Behavior of the discount determination#

Discount determination with and without best price determination works in the same way as price determination. Prices and discounts are always independent of each other in the price list. Therefore it can happen that a sales line incl. line discount only with the price or the stored line discount with another line (price or discount) are used for the best price determination.

Pricing according to hierarchy#

In the best price or best discount determination, entries from customers higher in the hierarchy are also included (see also "Managing hierarchies"). In order to use this functionality, the hierarchy type code to be used in pricing must first be defined in the "General" info tab in the Customers & Sales setup.

All customers stored via the defined hierarchy type code are then taken into account accordingly in the price/discount determination. The best price and the best discount in the corresponding combinations (validity, minimum quantity, units, currency, unit of responsibility...) are transferred to the document line. It does not matter in which hierarchy level the price was determined. If necessary, different prices (customer price, customer price group price, etc.) are determined in the different hierarchy levels.

Pricing by unit of responsibility#

This service area extends the sales prices and sales discounts by the possibility to define them also per responsibility unit. I.e. both prices and discounts can be different for different units of responsibility. For this purpose, the desired unit of responsibility must be maintained in the "Unit of responsibility code" field in the corresponding sales price or sales discount line of the price list.

UK suggested retail price#

Extended fields in Extended VK price proposals#

The function "Extended sales price proposals" include the price fields extended in KUMAVISION base (BOOSTER):

• Price unit

• Current UK price (price unit)

• New UK price (price unit)

• Unit of responsibility

• Sales order type The fields are taken into account when calculating the price proposal as well as when saving it in the sales price table.

Sales price proposal based on sales conditions#

When creating the sales price proposal, the new price can be calculated in Microsoft Dynamics Business Central™ based on factors to be entered manually. However, in KUMAVISION base (BOOSTER) there are already the sales conditions for the calculation of sales prices, see Sales Conditions. These sales conditions can be used to create the sales price proposal instead of the factor.

Procedure: The "Suggest item price..." function is called up in the Extended Sales Price Suggestion. For the Suggest sales price option, the option cannot be set up. In the options, the calculation base must be set to Sales condition and in the Sales condition code field, the desired sales condition is selected, on the basis of which the new prices are to be calculated. Only conditions of the type Price condition and without currency code can be selected. Quantity factors are not taken into account. After the action has been performed, the new prices will be proposed in the book sheet and can be transferred to the sales price table according to Microsoft Dynamics Business Central™ Standard.

Document process ID in sales#

In the sales process, it is helpful if related documents can be tracked from the quotation to the complaint with a common ID. For example, when creating a complaint, it should be possible to track the credit note, the return delivery, the purchase complaint and, if necessary, the new resulting order via a common document ID. For this purpose, there is a new field Document Process ID in the sales header and lines in the sales documents.

Establishment#

To use document tracking, a number series must first be created in the Accounts Receivable & Sales setup.

To do this, first call up the Accounts Receivable & Sales setup via the user search. On the Accounts Receivable & Sales setup card in the "Number series" info tab, you now have the option of entering a number series in the "Document process ID" field. You then exit the setup.

Process#

The "Document process ID" field is automatically filled with a sequential number from the number series in the "Start" document in the sales header. The document process ID can be viewed in the document lines in the field of the same name. The document process ID is then transferred to all documents and their lines resulting from the "Start" document.

Example:
A sales quotation is created as a "Start" document. In the document header, a document process ID is automatically assigned to this process. This document process ID is then transferred to the documents resulting from the process. The sales quotation is converted into a sales order. Thus, the sales order would automatically be assigned the document process ID of the original sales quotation as well.

Offer - Order - Archived sales documents - Delivery - Invoice - Sales complaint (only if the lines are created via the "Retrieve document lines to be cancelled" function)

Via the menu item "Line" in the info tab of the same name, the "Navigate Doc.Process.ID" can be called up under the menu item "Linked information". On the Navigate Doc.Process.ID card, all documents for the respective document process ID are displayed. By clicking on the number in the "Number of entries" field, you can display the corresponding document.

Letter Salutation#

In addition to the formal and informal form of address that can be defined for a contact, KUMAVISION base (BOOSTER) provides an additional form of address, the document form of address. It is used in sales documents in the Sales to contact field.

The reason for this is that there are contacts without first names in the system. If such a contact is selected as a contact person for a sales document, only the last name of this person is printed in the document in Microsoft Dynamics Business Central™ Standard.

To avoid this, KUMAVISION base (BOOSTER) enters the result of the document title formula into this field, so that a contact without a first name can be addressed with the appropriate name and title in the document.

Establishment#

The setup of the document salutation should be created for each salutation code. To do this, call up the "Salutations" via the user search.

First select the salutation line for which you want to set up the formula. Then select the "Formulas" menu item via the ribbon.

For each language code, enter a corresponding document reference formula.

Print salesperson in sales documents#

In KUMAVISION base (BOOSTER) there is a possibility to store two salesmen on the customer or in the sales documents. Depending on the use of these two codes in the companies, it is necessary to print one or the other sales code on the printed document to the customer. For example, if the sales representative is entered in sales code 1 to determine commissions and the internal contact person for the customer is in sales code 2, the customer should have the internal contact data displayed in the document.

For this purpose, a selection can be made in the respective documents for the printout of the salesperson in the "Commission" info tab in the "Printout salesperson" field.

Alternatively, a general default setting can also be set in the Accounts Receivable & Sales setup in the info tab "KUMAVISION" via the field "Salesperson proof".

Types of communication according to the 2012 data protection amendment#

On 01.9.2012, a decisive change in the data protection amendment takes effect, which in many cases changes the way customer data is handled.

In particular, it concerns the use of personal data for own business purposes, i.e.: advertising. To this end, far-reaching amendments have been adopted for Section 28 of the BDSG (Federal Data Protection Act).

Ultimately, the processing or use of personal data for advertising purposes will be made more difficult in the future; as of September 1, 2012, use will clearly - and more clearly than before - depend on the consent of the respective person. This becomes problematic because this change does not only affect new data, but also existing data. (Source: GFM News)

Non-personally addressed advertising - e.g., via Postwurf special - is not affected by the tightening of the data protection amendment.

The data protection amendment contains a so-called "opt-in", according to which a customer must expressly consent to the disclosure of data for the purpose of advertising. If this has only been done by telephone, the company must subsequently confirm it in writing. In addition, the customer must be informed in every advertising letter which company stored his or her data for the first time.

The following assessments were made for the implementation of the stricter data protection amendment in the CRM module of:

In principle, personal contacts may now only be used for advertising purposes (i.e., the segmentation of addresses) with the prior consent of the person. This applies in particular to e-mail campaigns. A postal letter is permitted up to the point of objection. Contacts of the type company may always be contacted by any means.

Communication types in contact management#

The contacts are extended in the info tab "Communication" by the communication types letter, e-mail, telephone and fax with the respective characteristic Allowed Yes or No. The default setting is empty, which means undefined. The communication type fields must be filled so that the selection of person addresses can be carried out.

If a change is made in one of the fields between the specifications Allowed Yes or No, an additional table Communication log items documents when and by which user the change was made.

In addition, the user must always enter a comment (e.g. according to telephone from xx.xx.xx) (mandatory entry). This ensures that a change is not made by mistake and that information about the changes can be provided quickly at any time in the event of queries.

The log items can be accessed and viewed directly from the contacts via the "Associated" > "Linked information" > "Communication log items" ribbon.

If a communication type is not explicitly set to Yes or No but remains empty, the system always assumes that this communication type may not be used for the person contact. To initially set the communication type to No for all contacts, the report 5049015 Initialize Comm. Allowance must be run once.

These settings on the contact have no effect on the creation of direct mails via the corresponding mail icon on the contact. Similarly, individual activities can be created for the contact. Only if activities are created via the Log segment function, the check for the permitted communication types is performed.

Segmentation of personal contacts#

When creating segments, a communication type must be selected before adding contacts to the segment.

In this way, the system ensures that only contacts who have agreed to this type of communication are added to this segment. Before logging the segment, the system checks again that the contacts in the segment have still not objected.

To select a communication type, an activity template must be selected in the segment header. It is recommended to select one activity template per communication type. * Fax * E-mail * Letter * Phone

to create.

The Add contacts function checks whether the contacts matching the search criteria are also permitted for the selected communication type. Only contacts that are allowed for this communication type are entered in the segment. A corresponding message confirms that the communication types have been taken into account.

automatic delivery of additional sales lines#

In an order, in addition to the "real" article items (items with stock flow), cost items are often entered, e.g. for freight costs, which are directly related to the article. Also the items of the type "service" are used more and more often.

The basic idea in the procedure is that with the order release these orders do not have to be processed actively in the sales department. I.e. the goods are delivered to the customer via a logistics process (one- or two-stage). In the daily invoicing run (periodic billing), all orders pending invoicing are invoiced.

This would create the problem in Microsoft Dynamics Business Central™ Standard that all items that are not stock items would not be delivered. However, if these items are not delivered, they will also not be invoiced.

A subsequent posting in the sales order could be performed, but this would lead to considerable effort as all invoices would have to be posted manually.

With the functionality enhancement "Automatic delivery of additional sales lines", the scope of functions has been extended so that these items are also invoiced directly when posting the logistics documents.

setup#

kumavision module setup#

In order to be able to use the function of "Automatic delivery of additional sales lines", the switch of the same name must be activated in the "KUMAVISION module setup" first. Otherwise, the function cannot be executed in the system and the corresponding setup will not be visible for users.

automatic delivery of additional sales lines setup#

In the "Automatic delivery of additional sales lines setup", all the

• Items of type=Service
• resources
• G/L accounts

that should be delivered automatically. This table can be seen as a global setup for sales.

procedure#

The facilities from the "Automatic delivery of additional sales lines facility" only apply if logistics documents are used in sales orders. I.e. in case of direct delivery from the order, users must enter the quantities themselves.

In case of mixed documents (lines with logistics and lines without logistics) the logic always takes effect when posting the logistics document. If the lines without logistics are delivered before (from the document), users can also post the lines manually.

Before posting the delivery, the system checks whether the transaction contains a line that is stored in the setup table, e.g. the G/L account for freight costs. If this is the case, the quantity to be delivered is entered automatically. This does not create a separate delivery bill, but is included in the same delivery bill as the goods entry.

Print alternative line totals#

With the switch "Print alternative row totals" in the company data, totals rows in sales quotation documents can be printed separately. If the switch is enabled, one sum line totals all lines of a bundle or subtotal, the second sum is in parentheses and totals all lines that are marked as alternative.

If the switch is deactivated, and rows in a bundle or subtotal are marked as alternatives in sales quotations, no sum of alternatives will be printed in the sales quotation document.

Cancellation of sales deliveries#

If only partial quantities are to be cancelled in a set of sales deliveries, the "Logistics cancellation type" field in the "Accounts receivable and sales setup" must be changed from "Standard" to "Extended cancellation".

A reversal posting can then be made from the "Sales deliveries" field. For this purpose, corresponding cancellation quantities can be entered for each booked delivery line using the "Edit cancellation quantities" function.

After the desired reversal quantities have been entered, the reversal document can be posted via the "Post reversal" function.

!!!note "Note Please note that only unbilled deliveries can be cancelled.