Purchasing#

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.

Accounts payable hierarchies are discussed in detail below.

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 vendor, first call up the vendor overview via the user search. Then select the desired vendor and call up the vendor card.

For setting a top-down hierarchy: From the ribbon, select Belonging - Vendor - Hierarchy - Belonging Vendor to access the Hierarchy Relationships card.

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

In the table, enter the vendor number in the "Value" field or select from the list of vendors 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 - Vendor - Hierarchy - Belongs to Vendor to access the Hierarchy Relationships card.

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

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

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

Show hierarchies#

To view the hierarchies of a vendor, first open the desired vendor cards. You can call the hierarchy via the Ribbon - Belonging - Vendor - Hierarchy Usage.

Select the method of use

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

Then click Calculate. The hierarchy will be displayed.

Special notes#

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

Establishment#

In the Accounts Payable & Purchasing setup, a code can be stored on the "General" info tab in the "Code for special notes" field that differentiates "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 only being displayed in the respective area.

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

Representation in processes#

Special notes are displayed in:

• Purchasing Requests,
  
• Orders
  
• Purchase Invoices

The display takes place in the info area of the document header for the special notes of the vendors. The notes are displayed automatically whenever the vendor is selected or when scrolling within the window between the documents.

The notes for articles are displayed in the info area of the document rows. The display occurs automatically for the article used in the rows whenever the article is selected or when scrolling within the rows of the document.  

Purchase order types#

With a large number of open documents, it is very difficult to keep track. Often the documents have different characters such as normal order, rush order, repair order, consignment order as examples of purchase orders. These characters alone can limit the mass of documents already for an overview.

Order types can be assigned dimensions for later analysis, which are inherited by the documents.

Purchase order types facility#

To create the purchase order types, proceed as follows:

Use the user search to enter the term "purchase order types" and select the appropriate link.

The purchase order type overview opens where you can create and define a new purchase order type with the help of the table below via the menu item "New".

Assignment of dimensions to a purchase order type#

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

To do this, select [...] > "Associated" > "Purchase 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 make the assignment using the table below:

Report selection by purchase order type#

In addition to using the purchase order type as a distinguishing criterion and predefining dimensions, different printouts can be controlled for each purchase order type. In addition to the selection of the actual document, the purchase order type can also be selected in the report selection of the purchasing department in order to be able to store different reports accordingly.

To do this, first call up the "Report selection - Purchasing" 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 purchase order type (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 purchase order types (order types).

Assign the purchase order type#

To assign the purchase order type to a purchase order, first create or open a purchase order. Under the "General" info tab, in the "Purchase order type" field, you have the possibility to specify / change the purchase order type.  

Variants#

Variant obligation#

In Microsoft Dynamics Business Central™ Standard, the use of variants is possible. However, the variant is only an additional distinguishing criterion. A check for the mandatory entry of a variant code is not given in the standard.

When using variants for articles, different types are often taken into account (e.g. sizes or color characteristics). In this context, a variant code is mandatory when entering a document line.

Example: To use a work shoe without sizes must be interrupted.

KUMAVISION base (BOOSTER) variant requirement forces the entry of the variant for an item when used in vouchers or book.sheet lines.

Within the article master record it can be defined whether the mandatory specification of a variant code is required for the respective article. For this purpose, the field "Variant obligation" on the info tab "Stock" is used.

The setting of this field refers both to the purchase and to the sale or other entry of the item. The check for a missing variant code is performed when entering the quantity in the respective document or book.sheet.

If an article was marked as requiring a variant and no variant was specified, the system issues a corresponding message.

The entry of a quantity is thus only possible for the line after entering a variant code.

In addition, this mandatory variant check is also performed during the booking process in Sales, Purchasing and from the Book.sheet article.

Variant lock#

In Microsoft Dynamics Business Central™ Standard articles are lockable. This blocking of articles has been extended in KUMAVISION base (BOOSTER) by the distinction "Blocked sales, Blocked purchasing, Blocked production. In addition, it is possible to lock individual variants for a range or completely.

If, for example, the work shoe in a certain size is no longer to be used in sales or purchasing, it is possible to block it for the respective area.

On the article variant card, the following fields are available for the variant lock:

• VK Variant Lock,
  
• EK Variant Lock,
  
• Service variant lock
  
• Production variant lock
  
• Article book sheet variant lock
  
• Stock transfer order variant block
  
• Project Variant Lock
  
• Mounting variant lock

These fields can be used to lock the individual variant for the respective process.

If a locked variant is used within an operation, an error message is issued immediately after the variant code is entered. It is not possible to enter the respective variant.

The blocking indicator check is performed in the following hierarchy:

• the check for the field "Locked" = "no" in the article
  
• the check for the field "Blocked sales" = "no" (or in the purchasing transaction then "Blocked purchasing", production transaction -> "Blocked production", service -> "Blocked service") in the article
  
• the check for the field "Sales variant lock" = "no" (or in the purchasing process then the field "Sales variant lock", Production -> Production variant lock", Service -> Service -variant lock) in the article variant.

Distribute order / planning lines#

The processing of order and planning worksheets is carried out by several people in larger companies. However, the standard system does not offer the possibility to create several purchase order worksheets/planning runs delimited per book.sheet. To meet this requirement, the articles are assigned to MRP controllers. The results of the ordering or planning run are then set (distributed) for each MRP controller in their own worksheet.

Through this distribution function, users are assigned to the articles. After a procurement run, the worksheet lines can then be distributed into their own worksheet names. For this purpose, any number of users can be assigned to each worksheet name and thus groups of users can also be distributed into a worksheet name again.

To assign an article to a user, first call up the desired article card. In the "Planning" info tab, you can make the assignment in the "Assigned user ID" field by selecting the desired user.

In the order worksheet lines, when an item number is created or entered and during the order or planning run, the field is filled using the data from the item card.

The assignment between Assigned User ID and the worksheet names is done in the Worksheet Lines Distribution Filters table, which can be found in the Administration in the Warehouse area. It should be noted that each Assigned User ID may only appear once in the distribution filters.  

Price inquiries with price comparison list#

This service area provides for articles a price comparison list of price requests of quantities, scale quantity, prices and procurement times at different vendors or contacts. The results can be transferred to the vendor/article catalog or the purchase prices.

Price requests are usually created from the purchase order or planning worksheets for a selection of vendors or contacts. Alternatively, the vendors from the vendor/article catalog can be used.

To create a price request from a purchase order or planning worksheet, place a check mark in the "Price request" field in the respective worksheet row.

Via the menu item "Associated" in the menu ribbon, select the "Selection for price requests". The selection options "Assignment for current data record" or "Assignment for selected data records" are available. These can be used to select the desired vendor or contact from which the price inquiry is to be obtained.

A price inquiry can be created via the corresponding function in the menu ribbon. The purchase requests are now generated per vendor no. and contact no. from the selection for price requests.

In the options, you can select whether, in addition to the creditors or contacts listed in the selection for price requests, the creditors from the article/supplier catalog are also used. With a check mark in Print price request, the price requests generated in this way are also printed directly.

The purchasing conditions reported back are entered in the price requests in the system. The results of the price inquiries generated in this way can be displayed under the call "Price comparison list". The call can be called from the order or planning worksheets.

The price comparison chart itself is based on the purchase lines of the Inquiry type, but is sorted by vendor no. and displays other fields.

In addition, the procurement time field is displayed before the Quantity field. At the end there is a calculated field EK price without VAT. (base,MW). This field is calculated from line amount without VAT / quantity per unit. If the currency code is filled still another conversion takes place on client currency.

The following menu items can be called up via the menu ribbon in the price comparison list:

Action - Function:

Related - purchase prices:

Validity period in purchasing requests#

This functional area extends the standard in that a validity date can be entered in the purchasing requests. This date can be maintained on the purchasing request on the "General" info tab in the "Valid until date for offer" field.

If the function "Save price / discount" is called for the rows and the field "Valid until date for offer" is filled in the header of the purchase request, this date is automatically taken over as end date in the function and suggested for saving. If users manually change the date in the window for saving prices and discounts, the manually changed price will be saved.

Order confirmations and reminders#

In order to record order confirmations from suppliers in the system and to dun them if necessary, the functionality of order confirmations has been extended in KUMAVISION base (BOOSTER).

For a purchase order, even with several purchase order lines, it is possible to enter the purchase order confirmations only for selected purchase order lines. Whenever the relevant fields in the purchase line are changed, the corresponding fields in the order confirmation are updated. If the purchase line is deleted, the corresponding order confirmation lines are also deleted.

Establishment#

Accounts Payable & Purchasing Setup#

To make the necessary setups for the purchase order confirmation reminder, first call up the Accounts Payable & Purchasing setup via the user search.

In the "General" info tab, you can specify the reference date of the order confirmation reminder in the "Default order confirmation reminder date field". Date field" you can set the reference date of the order confirmation reminder. You can choose between "Document date" and "Order date". Usually it is set to the document date.

In addition, a number series must be stored in the "Number series" info tab in the "Order confirmation reminder" and "Registered order confirmation reminder" fields.

Order confirmation reminder code#

An order confirmation dunning code is then created and, if necessary, the associated dunning levels. To do this, first call up the "Order confirmation dunning methods" via the user search.

You can set up a new order confirmation reminder code using the "New" menu item.

Furthermore, you should define the required number of dunning levels and their due date. To do this, click on the "Levels" function button in the same ribbon as before and enter your data first.

You can round off the dunning procedure with suitable dunning texts for each stage. To do this, select [...] - Associated - Stages - Pretext / Posttext and formulate your introductory text (pretext) and closing text (posttext) for each dunning stage line by line according to your ideas.

Vendor assignment#

Finally, the order confirmation reminder code must be assigned to each vendor for which an order confirmation reminder is to take place in the "Delivery" info tab.

Report-selection-extended#

In addition, the associated report must be accessed for the reminder. This is set up in the report selection-extended.  

Execute order confirmation reminder#

Create an order confirmation reminder to remind a supplier of your order and ask them to confirm it. To do this, call up the order confirmation reminders via the user search.

A blank order confirmation reminder opens and by pressing the Enter key, the system draws itself a sequential number.

Now select the "Create order confirmation reminders..." item in the ribbon.

The "Create order confirmation reminder" card opens, where you can make further filterings. With the help of the filters you can, for example, limit vendors or articles to be searched. If you leave the filters as default, the system will go through all overdue order confirmations.

The system will automatically create the order confirmation reminder for you with the appropriate reminder lines.

The order confirmation reminder must be registered in the system (necessary for further reminder levels) and to print the corresponding order confirmation reminder. Select the "Register" item in the menu ribbon.

As soon as you have executed the "Register..." function, the corresponding receipt will be printed automatically afterwards on your printer set up as the default printer.

Under "Reg. order confirmation reminders" you can also print your order confirmation reminder. To do this, call up the Reg. order confirmation reminders via the user search and select your generated Reg. order confirmation reminder.

Analogous to the order confirmation reminder, a delivery reminder can be carried out.  

Prices#

Price origin#

In the purchasing 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 is stored per line. The basic logic and sense of the price origin is applied accordingly to the discount origin.

Advanced pricing#

This service area extends the two standard modules "Purchase prices" and "Purchase 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.

In addition, entries from higher-level vendors in the hierarchy are also included in the best price or best discount determination (see also "Managing hierarchies").

To be able to use this functionality, first call up the Accounts Payable & Purchasing setup via the user search. In the "Hierarchy type code pricing" field, enter the hierarchy type code to be used in pricing.

All vendors 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 (vendor price, article price group price, etc.) are determined in the different hierarchy levels.

Purchasing conditions#

Purchase conditions are a new form of discount definitions. The Purchase condition application area allows you to flexibly calculate the line discount % in the purchase line using freely definable calculation lines.

You can define the calculation lines in a standardized way already in the master data. The storage in the master data takes place with the help of so-called "purchase conditions".

Purchase conditions allow you to calculate a variable line discount % and ultimately a variable discount calculation in a purchase line.

Purchasing conditions are first defined as an independent dataset in the purchasing master data and then assigned to one or more records in the Purchasing Line Discount tables.

Attachment purchase conditions#

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

A new purchase condition card opens where you can create the desired purchase condition with the help of the tables below.

Inforegister General#

Inforegister Purchase Condition Subform#

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

Example:
The purchase condition has the following characteristics:

When applying the purchase condition in a purchase line, it has as a basis the item's EK price.

In the first step, a "basic discount" of 5% is calculated and deducted.

In the next step, a "discount for action of 3%" is granted from this result, related here to the EK price of the item.

The purchase condition is now to be used in the purchase discounts of the article in our example. In our example, the article has a purchase price of 26.80 EUR.

The item has the following defined purchase discounts:

The item is now to be purchased in a purchase order on 04/15/2020 from vendor 30000.

The application runs through the standard pricing routine when entering the item. The purchase condition is transferred to the purchase order and calculates the total discount for this line = 8.

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.

Purchase condition in the tables Purchase line discount#

The linking of a purchasing condition to a data record of the "Purchasing line discount" table is always done via the field "Purchasing condition no." The currency of the condition must match the currency of the "Purchasing line discount".

Records in the "Purchase discounts" table with the "Purchase condition no." field filled in always have the value 0 in the "Discount %" field in the master data, the discount is calculated when entering it in the purchase lines.

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

Purchasing line discounts with specified purchasing conditions in best discount determination#

The purchase discounts with specified condition no. are used like normal purchase discounts for the determination of the "best discount". Whether or not a purchase discount is taken into account as a valid purchase discount for pricing in a special purchasing document is therefore not dependent on the purchasing condition data. Only the value of the purchase discount is determined dynamically and the purchase discount then participates with this determined discount rate in the best discount determination.

Transfer of the purchase condition data to the "Purchase discount calculation line" table.#

If a purchase condition is found during the purchase discount calculation, the data of the purchase condition rows are transferred to a sub-table of the purchase row ("Purchase discount calculation row" table).

The user can display the records of the "Purchase- Price/Discount calculation row" table in a window and edit them there if necessary. 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 purchase 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 first 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 purchase line, the changes are retained, these can be called up again and edited.

The purchase line contains 2 calculated fields "Price calculation available" and "Discount calculation available" (both Yes/No). The fields are not initially displayed in the purchase line, but can be selected by the user and show the user whether a respective calculation is available for the line or not.

Transfer of data records of the table "Purchase price/discount calculation line" when copying, posting, archiving, delivery call-off etc.#

The data records of the table "Purchase price/discount calculation line" are transferred to the posted documents and archived documents during posting and archiving.

These can be displayed in read-only from the posted or archived document to the respective line of the document.

The 2 calculated fields "Price calculation available" and "Discount calculation available" can also be displayed in the posted and archived document lines.

During copying and delivery call-off, the data records of the table "Purchase price/discount calculation line" are also copied between the source document and the target document.

This is not the case if the rows are recalculated instead, e.g. when copying a document by selecting "Recalculate rows".

Price units#

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

In practice, other calculation formulas are also encountered.
An example of this is price calculation using price units.

Typical for the task of a price unit is price indication of a multiple of the EK price.

In any case, the price of the document line must 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 50 (=price unit). The price entered by the user should be interpreted as the price for 50 PACKAGES.

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

Basic procedure#

In the purchase lines there are additional fields for entering/managing price units: "Price unit" columns as well as "EK price (price unit) without VAT". Likewise, the fields are in all the corresponding archive tables and in the tables for posted documents. The Item EK Price table also contains the two price unit fields.

Alternatively, price units can be used only in one document or they can be stored in the pricing. When maintaining in the article EK prices, make sure that the purchasing unit must also be maintained accordingly.

Article price group#

Identical items that have not been priced individually can be grouped into item groups based on which prices can be maintained. For example, a group of paperbacks always costs the same, regardless of the title.

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

• Vendor hierarchies are supported
  
• Purchasing conditions are supported
  
• Quantity based, date based, currency based price 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.

The use in the purchasing documents is the same as for item prices. When entering the item no. in the purchase line:

In addition to the prices stored directly for the article, the prices stored behind the article price group are also used.

The best price determination is carried out among all prices found, the prices that come directly from the article and the prices that come indirectly from the article price group have equal rights in the best price determination.

In the info area (purchase order line / purchase invoice line ...) you can branch to the article prices. The prices coming from an article price group are also shown here. The user can also select such a price (corresponds to function Get purchase price).

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 successful creation of the article price group, you can enter the prices via the "Ribbon - Belonging - Article price group - Purchase prices" analog to the standard price maintenance per vendor or vendor group of the article price group.

Graduated prices#

The calculation of the value of the fields Purchase price and Line discount % of the purchase line is based on the price or discount agreements between vendor and item stored in the master data in the tables Purchase price and Purchase line discount.

The possibilities of price and discount agreements are very diverse. For example, agreements for all vendors, for vendor groups or for special vendors can be stored on the vendor 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 purchasing line in a purchasing document for a vendor, the application automatically calculates the value of the purchase price and line discount % fields of the purchasing line. The calculation is done by comparing the value of the Quantity field of this specific purchase line with the minimum quantities stored in the mentioned master data, and thus runs through a best price determination among all the purchase prices or line discounts found.

In principle, the standard system carries out the best price determination described above separately for each purchasing line of a purchasing document. In practice, it can happen that the user enters one and the same article several times in one purchasing 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 purchasing 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 purchasing lines of the same purchasing document with the same item number. Price relevant fields for this functionality of the purchase 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 purchasing lines that have the same values within these fields will be used to calculate totals via the Quantity field.

As a rule, purchasing lines with:

• 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)
• Frame order no. with value not equal to <empty>.
  (i.e. order lines that refer to a blanket purchase 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 purchase 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 frame position as well as to alternative lines and when invoicing posted deliveries or returns.

Saving purchase prices/discounts from documents#

Often, due to the high number of potential articles, price maintenance in the retail sector is not carried out in advance, but supplier-specific within an inquiry/order.

The "Save prices / discounts" section gives the user the option of conveniently saving the prices individually agreed within an inquiry or order, so that they are directly available the next time the items are used.

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

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

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 purchase 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 prices:

Meaning of the mask fields for discounts:

Then confirm your selection with "OK".

Close prices and discounts#

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

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

For this purpose, in the Accounts Payable & Purchasing setup, the "Prices and discounts" switch on the KUMAVISION info tab must be activated.

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.

Prices (From Version 20.0)#

Setup function extension#

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 "Function update: "New sales calculation" must be set to the value "All users" in the column "Activated for".

Price origin#

In the purchasing 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 is stored per line. The basic logic and sense of the price origin is applied accordingly to the discount origin.

Saving purchase prices/discounts from documents#

Often, due to the high number of potential articles, price maintenance in the retail sector is not carried out in advance, but supplier-specific within an inquiry/order.

The "Save prices / discounts" area gives users the option of conveniently saving the prices individually agreed within an inquiry or order, so that these are directly available the next time the articles are used.

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

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

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

The "Save purchase 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 prices:

Meaning of the mask fields for discounts:

Then confirm your selection with "OK".

Purchasing conditions#

Purchase conditions are a new form of discount definitions. The Purchase condition application area allows you to flexibly calculate the line discount % in the purchase line using freely definable calculation lines.

You can define the calculation lines in a standardized way already in the master data. The storage in the master data takes place with the help of so-called "purchase conditions".

Purchase conditions allow you to calculate a variable line discount % and ultimately a variable discount calculation in a purchase line.

Purchasing conditions are first defined as an independent dataset in the purchasing master data and then assigned to one or more records in the Purchasing Line Discount tables.

Attachment purchase conditions#

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

A new purchase condition card opens where you can create the desired purchase condition with the help of the tables below.  

Inforegister General#

Inforegister Purchase Condition Subform#

The purchase condition rows define the calculation steps for calculating a purchase discount when applying the condition. When defining the purchase condition lines, note in particular that the sequence of the subsequent processing of the calculation steps for calculating the line discount % is determined by the sequence of the lines you entered in the window.   |Field |Description| | --- | --- | |Description |Description of the purchase condition line| |Operators |+ adds the entered percentage / currency amount
-subtracts the entered percentage / currency amount| |Value |The value of the percentage or currency amount that will be added or subtracted via the operator is entered here.| |Calculation |Net percentage calculates the percentage
value on the calculation base (purchase price or cost price).

Subsequent percentage calculates
the percentage value on the final value of the previous line in the sales condition.

Currency Amount
adds or subtracts the entered value in the currency amount.|

Example:
The purchase condition has the following characteristics:

When applying the purchase condition in a purchase line, it has as a basis the item's EK price.

In the first step, a "basic discount" of 5% is calculated and deducted.

In the next step, a "discount for action of 3%" is granted from this result, related here to the EK price of the item.

The purchase condition is now to be used in the purchase discounts of the article in our example. In our example, the article has a purchase price of 26.80 EUR.

The item has the following defined purchase discounts:

The item is now to be purchased in a purchase order on 04/15/2020 from vendor 30000.

The application runs through the standard pricing routine when entering the item. The purchase condition is transferred to the purchase order and calculates the total discount for this line = 8.

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 of purchase condition in purchase price and purchase line discount#

The assignment of a purchase condition is always done via the "Price condition" field of the respective price list. The currency of the condition must match the currency of the "Purchase price" or "Purchase line discount".

Price list records with the "Purchase condition no." field filled in always have the value 0 in the "Discount %" field in the master data, the discount is calculated when entering it in the purchase lines.

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

Purchase prices or purchase line discounts with specified purchase condition#

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

Price units#

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

Net amount=quantity∗EK price∗(100-discount%)/100

In practice, other calculation formulas are also encountered. One example is the price calculation using price units.

Typical for the task of a price unit is price indication of a multiple of the EK price.

In any case, the price of the document line must 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 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 50 (=price unit). The price entered by the user should be interpreted as the price for 50 PACKAGES.  

Basic procedure#

In the purchase lines there are additional fields for entering/managing price units: "Price unit" columns as well as "EK price (price unit) without VAT". Likewise, the fields are in all the corresponding archive tables and in the tables for posted documents.

Alternatively, price units can only be used in a document or stored in pricing. When maintaining in the article EK prices, make sure that the purchasing unit must also be maintained accordingly.

E.g. the article is managed in the basic unit piece. The document line is also entered in pieces, but the price calculation of the document line is not based on the piece, but on the weight.

The mapping of such weight-based document pricing is another pricing method and is not mapped in this section.

Receipt printing#

The document printout in all documents is now done using the price unit and the purchase price in the price unit. In addition, the user can already manage the prices agreed with the suppliers in the master data by specifying a price unit.  

Article price group#

Identical items that have not been priced individually can be grouped into item groups based on which prices can be maintained. For example, a group of paperbacks always costs the same, regardless of the title. Price agreements for item price groups can be recorded in the same way as item prices, i.e. in particular:

• Vendor hierarchies are supported
• Purchasing conditions are supported
• Quantity based, date based, currency based price 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.

The usage in the purchasing documents is the same as, for item prices. When entering the item no. in the purchase line:

In addition to the prices stored directly for the article, the prices stored behind the article price group are also used.

The best price determination is carried out among all prices found, the prices that come directly from the article and the prices that come indirectly from the article price group have equal rights in the best price determination.   In the info area (purchase order line / purchase invoice line) you can branch to the article prices. The prices coming from an article price group are also shown here. Users can also select such a price (corresponds to function Get purchase price).

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" > "Purchase prices" analogous to the standard price maintenance.

Graduated prices#

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

The possibilities of price and discount agreements are very diverse. For example, agreements for all vendors, for vendor groups or for special vendors can be stored on the vendor side and agreements for article groups or for special articles can be stored on the article side.   If users enter an item in a purchasing document for a vendor in a purchasing line, the application automatically calculates the value of the fields "Purchase price" and "Line discount %" of the purchasing line. The calculation is performed by comparing the value of the "Quantity" field of this specific purchasing line with the minimum quantities stored in the master data mentioned above, and thus runs through a best price determination among all the purchasing prices or line discounts found.

In principle, the standard system carries out the best price determination described above separately for each purchasing line of a purchasing document. In practice, it can happen that users enter one and the same article several times in one purchasing 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 purchase line that users are currently entering is used for the price or discount calculation of this line, but the sum of the quantities in all purchase lines of the same purchase document with the same item number.

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

• Type and no.
• Variant code
• Unit code and quantity per unit
• Alternative with value >
• Allow line discount and allow calculation discount

Only those purchasing lines that have the same values within these fields will be used to calculate totals via the "Quantity" field.   As a rule, purchasing lines with:

• Delivery no. or return no. with value not equal to (i.e. invoice or credit memo lines created by a delivery schedule).
• Frame order no. with value not equal to (i.e. order lines that refer to a frame order line).
• Alternative with value not equal to

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 purchase price or line discount % is manually changed 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 frame position as well as to alternative lines and when invoicing posted deliveries or returns.

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 the line discounts. In principle, it is possible to automatically assign an end date to existing price or discount entries 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 "Close prices and discounts automatically" checkbox must be activated on the Prices info tab in the Accounts Payable & Purchasing 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.

Pricing by unit of responsibility Extended pricing#

This service area extends the "Purchase prices" and "Purchase 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 purchase price or purchase discount line of the price list.

Best price determination controllable#

In the best price or best discount determination, entries from the hierarchy of higher-level vendors are also included (see also "Management of hierarchies"). To be able to use this functionality, first call up the Accounts Payable & Purchasing setup via the user search. Enter the hierarchy type code to be used in pricing in the "Hierarchy type code pricing" field. All vendors 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 (vendor price, article price group price, etc.) are determined in the different hierarchy levels.

Price calculation when transferring from the order and planning worksheet to the order#

The Microsoft Dynamics Business Central™ standard revalidates the purchase order date when transferring from the purchase order worksheet and planning worksheet to the purchase order. This triggers a new pricing process.

With the switch "Update prices on transfer from purchase order worksheet" in the Accounts Payable & Purchasing setup it can be decided whether a new price calculation should take place on transfer (option: "Standard") or not (option: "No new pricing").

Document process ID Purchasing#

In the purchasing process, it is helpful if related documents can be tracked from the inquiry to the complaint with a common ID. This is particularly useful when documents such as sales complaints are to be linked to purchasing complaints across departments. For this purpose, there is a new field "Document Process ID" in the purchasing header and lines in the purchasing documents.

Establishment#

In order to use document tracking, a number series must first be created in the Accounts Payable & Purchasing setup.

To do this, first call up the Accounts Payable & Purchasing setup via the user search. On the Accounts Payable & Setup card on 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 copied in the purchasing header and to all documents resulting from the "Start" purchasing document and their lines.

Inquiry -> Purchase order -> Archived purchase documents -> Delivery -> Invoice -> Purchase complaint (only if the lines are created using the function Retrieve document lines to be cancelled).

Using a purchase order as an example, the document process ID is created on the purchase order and transferred to the purchase invoice/delivery when they are posted.

Via the menu item "Line" in the info tab of the same name, the "Navigate Doc.Process.ID" can be called up. 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.

In the same way, the general Navigate function can be used to search for all documents that contain a specific document process ID in a line. It is important that the document process ID of the line is decisive for the search.

If a document is copied or if the lines are created with the function Retrieve posted document lines to be cancelled, the document process IDs of the original document are taken over. This means that these lines can then only be retrieved with the original document process ID. If this is not to be the case, the Copy document process ID option must be switched off when creating the corresponding document lines from the Copy document function. When retrieving complaint lines, the original document process ID is always transferred.

Post booking data#

You can use the "Post posting data" function to subsequently correct the posting data in 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 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

Creation of inquiries to contact#

In order to create inquiries to potential suppliers, i.e. contacts without an accounts payable assignment, they can be entered using an accounts payable template.

Vendor templates are created in the Financial Accounting section.

To create an inquiry to potential suppliers, the "Create inquiry" function is selected in the action area. An inquiry is drawn with the contact's data and opened directly. At this point, a template can be selected in the field "Credit template code". This template will be used in the inquiry.

The inquiry can also be created without creating a creditor. In this case, the vendor must be created only when converting to a purchase order.

Moreover, inquiries to contacts can be created and released in KUMAVISION base (BOOSTER) without creating a creditor.

Bonus management#

In the business process, bonus arrangements are often agreed with creditors. These state that if a certain sales volume is achieved at the end of a bonus period, a bonus is paid on the basis of the sales volume.

The bonus settlement rules can vary quite a bit from case to case. For example, the amount of a bonus payment may depend on the achievement of various turnover levels. It may be that the bonus amount is determined by the achieved bonus level, but it may also be that the individual levels must be served in sequence.

The sales of the respective vendor itself or the sales of a group of vendors within a hierarchy can be used for the bonus payment.

The basis of the rebate settlement is the turnover of the creditor according to the creditor items.

The bonus settlement is flexibly designed via a table of bonus groups. A bonus group has different parameters to control the settlement and a sub-table of bonus rates. A bonus group code can be assigned to each vendor.

In addition, a multi-level list of other creditors can be assigned to him, whose turnover is also taken into account for his bonus settlement.

The actual rebate settlement is carried out by means of a report. The user can also call up information on the interim status of the rebate settlement on the accounts payable card.  

Attachment bonus management#

The rebate group regulates two pieces of information. On the one hand, the turnover of which creditor the rebate settlement of a certain creditor is based on and, on the other hand, the staggering of the turnover amount (according to its associated rebate group lines) as well as its application.

To create the bonus group, first call it up via the search. The bonus group overview opens. Click "New" to create a new bonus group using the table below.

Via the menu item "Zugehörog" - "Bonus groups" you now have the possibility to manage the staggering of the bonus amount by calling "Bonus group lines".  

Allocation of rebate management#

To assign the rebate groups, open the Accounts Payable table in the application search.

The creditor overview opens. Call up the desired creditor and assign the corresponding rebate group to him in the "Address and contact" info tab in the "Rebate group code" field.

Calculation of the underlying turnover#

With the help of the service area "Use of hierarchies" any number of hierarchies can be assigned to a vendor. The individual hierarchies are grouped with the help of the Hierarchy type table.

A special hierarchy type can be, for example, "KREDPRO" Vendor commission. In the "Hierarchy relationship" window, a vendor can then be assigned a list of those vendors whose sales - in addition to their own sales - are also to be used as the basis for rebate settlement. The connection of the special hierarchy type to the rebate settlement is now done via in the table Rebate groups in the field Hierarchy type code. The following logic is used:

• If the vendor has been assigned a rebate group (in the field Rebate group code), which has no entry in the field Hierarchy type code, the own turnover at the vendor is the sole basis for the rebate settlement.
• If a bonus group has been assigned to the vendor with an entry in the Hierarchy type code field, the application also takes into account the hierarchy relationships of the vendor (in addition to its own sales) when settling commissions. However, only those hierarchy relationships of the hierarchy type from the bonus group are taken into account.

Bonus settlement#

The settlement of bonuses is done via a report.

To run the rebate settlement, first call up the Vendor Rebate Settlement Report from the search.

In the Vendor Bonus report, you can now run the report by specifying the vendor as well as an appropriate billing period using the filter criteria.

The report determines per vendor the turnover in the accounting period according to the above description. If the turnover was also calculated indirectly via other vendors, the report also provides a list of the concrete composition of the turnover

The report compares this total turnover of the creditor with the amounts of the bonus group line of the respective bonus group. It lists the creditor's bonus payable in detail.  

Print purchasing documents only for released documents#

When the purchasing documents are released, the system runs through a number of 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, but in KUMAVISION base (BOOSTER) printing is only possible for released documents. Exceptions are the purchase request and the print preview.

Extension of blanket purchase order system#

If articles are purchased in larger quantities, a quota is usually agreed with the supplier at a lower price. This can be represented by blanket orders with their own prices.

However, the information in the standard system on the blanket purchase order is very rudimentary for controlling these blanket purchase orders. For example, it is not apparent until a call-off is posted in the blanket purchase order that this call-off exists. Another shortcoming of the standard is that in the purchase order and planning worksheets, blanket purchase orders can neither be displayed nor selected. If the buyer is not attentive or in case of larger item inventories, he orders the item at normal prices and conditions. In addition, the process flow is a call-off from the blanket purchase order with many worksheet lines very tedious and time consuming.

Blanket orders get more information about call-offs through this service area by "Remaining quantity in order". In addition, blanket purchase orders are displayed in purchase order and planning worksheet lines per line and can be assigned manually if the remaining purchase order quantity is sufficient. The vendor data and price conditions are thereby taken over from the blanket purchase order.

Using a convenience function, this assignment can also be made automatically for the selected vendor via the blanket purchase order lines that are still open. The price conditions are also taken over. In addition, a separate purchase order can be generated for each blanket purchase order line.

In the blanket purchase order, the fields "Remaining quantity in purchase order" and "Remaining quantity in purchase order (base)" display the information about existing call-offs.

The Remaining Order Quantity in Purchase Order (Base) field is a FlowField and displays the Remaining Order Quantity (Base) of all purchase order lines associated with this blanket purchase order. The "Remaining Order Quantity in Purchase Order" field is calculated from the Remaining Order Quantity in Purchase Order (Base) field via the "Quantity per Unit" of the blanket purchase order for normal purchase orders.

The purchase order and thus planning worksheet line also contains three additional fields: "Number of blanket purchase order lines", "Blanket purchase order no." and "Blanket purchase order line no.". The first field Number of blanket purchase order lines is a flowfield and shows the number of all blanket purchase order lines where the type, the no. and the storage location code are the same and the remaining order quantity (base) is > 0. The second and third fields allow the user to manually assign to a blanket purchase order or blanket purchase order line by lookup. If selected, the vendor and, if applicable, a vendor item no. and the price conditions (price, discount, price unit, currency) are taken from the blanket purchase order line. If the assignment is removed again, the fields are reset by validating the vendor no. and pricing is carried out again.

During the selection, a check is made whether the remaining order quantity (base) - remaining quantity in order (base) - already assigned proposal line quantity (base) is still sufficient for the quantity (base) of the worksheet line; if necessary, an error message is issued.

Automatic assignment of blanket order#

This variant is a convenience function, it can be started either individually via the menu item "Assign blanket purchase order" or when creating purchase orders via "Execute event message" by the option "Assign blanket purchase order automatically". In the direct menu call there are additionally the options Assign, Reassign and Delete. Reassign is the combination of Assign and Delete.

Via "Assign" the system goes through all filtered worksheet rows with event message=New. If no manual assignment has been made yet, the system searches through all blanket purchase orders for this vendor, article, article variant and storage location with remaining order quantity <> 0. The sort order is document number and document line number. If a blanket purchase order line is found with sufficient open remaining order quantity, it is assigned to the worksheet line. If the quantity of the worksheet line is larger, this part is split off into a new worksheet line. In addition to the frame assignment, the price fields such as purchase price, price unit and discounts are also transferred.

Via Delete the assignment can be removed again. Here, too, the resetting of the pricing is done by validating the vendor.

In the "Execute event message" there is another option "One order per frame". If this is activated, the worksheet lines are additionally sorted according to the blanket purchase order number and blanket purchase order line number. A new purchase order is created for each blanket purchase order or blanket purchase order line.

Manual assignment of blanket order#

If a purchase order is entered manually, the user can also transfer the conditions of the blanket purchase order via the assignment of the blanket purchase order line in the purchase order. To do this, the relevant blanket purchase order number is entered in the "Blanket purchase order no." column in the purchase line. The user receives a prompt asking whether the purchase price and line discount % are to be transferred from the blanket purchase order line.  

Copy article comfort#

The following copy options have been added to the "Copy acticles" function:

If the copy process is executed, the system will also create a production BOM or routing with the "Item No." as the "No." after the item is created, and store it on the item card. In addition, the header information is copied as follows:

Item tracking comfort#

In Microsoft Dynamics Business Central™, an item can be defined as to whether it will be posted with serial or batch number specific tracking. Often, however, this specification for an item changes during its product life cycle. For traceability and repair reasons, however, a change of the article number is undesirable or not possible.

In KUMAVISION base (BOOSTER) a change of the serial no.-specific or batch no.-specific tracking is possible under certain conditions.

When changing the serial no.-specific or batch no.-specific tracking, the following has to be considered:

• If the stock issue method is Selected, the default implementation remains.
• There must be no open items.
• There must not be any article items that have not been completely invoiced.
• The cost price on the item card must be regulated.
• There must be no reservation items for this article with filled serial or batch number.

If these conditions are met, a change can be made. Otherwise, a change is not possible and a corresponding message appears.  

Document attachments for articles#

Plants#

You have the option of storing and monitoring documents such as drawings and certifications for an article.

To do this, first call up the desired article card. Via the "Associated" > "Article" menu tab, you can use the "Attachments" call to save the desired documents to the article with the help of the table below.

The following functions are also available in the Plant Overview ribbon:

Cancellation of purchase deliveries#

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

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

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