Sales and Marketing#
Create article reference from sales line#
In retail, customers often have their own article numbers. These article numbers can be used in the "Reference number" field during order entry, provided they are maintained in the article or customer master under Reference numbers.
If these article numbers are not yet maintained, this reference number can be entered and permanently created in KUMAVISION trade365 during order entry in the respective line.
In order to use this function, the "Create article references automatically" switch on the "KUMAVISION trade" info tab must be activated in the "Accounts receivable and sales setup".
A sales line is recorded with the following fields:
|Type||No.||Reference number||Unit||Variant code|
|Article||Item number||Customer article number||Article purchasing unit||(can optionally be filled depending on the article as well)|
A reference entry is automatically created for this item and this customer.
If there is already a reference entry in the system for this customer and this article number, it will be displayed as soon as the field with the article number is left.
The list of article references can be accessed and edited via the user search.
Order types and payment terms#
Via order types on the one hand the documents can be distinguished and structured and on the other hand the behavior can be defined.
The order types exist in addition to the standard for service orders for the following documents:
- Order as sales order type
- Purchase order as purchase order type
- Stock transfer as stock transfer order type
- Production order as production order type
Distinguishing characteristics can be, for example, normal order, rush order, consignment order, external production order or also rework order.
Sales order types#
Depending on the order type, a payment term can be assigned that overrides the customer's payment term.
To create a new sales order type, first call it up via the search.
Then the sales order type overview opens, where you can create and define a new order type using the table below via the "New" menu item.
|Code||Unique meaningful abbreviation of the respective sales order type|
|Description||Description of the sales order type|
|Zlg. condition code||Specifies the payment term of the respective order type. This payment term overrides the payment term stored in the customer's master data.
The payment terms can be additionally changed manually in the order. When using the sales order type in the document, the payment term of the order type is entered.
|Minimum DB%||Indication in %. To check for the contribution margin in the processes (VK order).|
|Standard||Default sales order type. This is then automatically preassigned when new sales documents are created.|
|Reference to recorded orders||Note during order entry
If an order with the same combination (order type / customer / article) already exists in the system, a corresponding message appears.
|Standard for Shopify||Orders created via the Shopify interface included in the standard will automatically receive the selected order type.|
|Exclude from periodic billing||If activated, orders with this order type will not be included in the periodic billing.|
Sales order types can be assigned dimensions for later analysis, which are inherited by the documents.
To do this, select in the ribbon > "Associated" > "Sales order type" > "Assignment for current record" and/or "Assignment for selected records" for the dimension assignment.
The default dimensions card opens where you can make the assignment using the table below:
|Dimension code||Specifies the code for the default dimension - a selection from the Dimensions overview table is possible here|
|Dimension value code||Specifies the dimension value code that is proposed as the default dimension - a selection from the Dimension values overview table is possible here|
|Dimension value posting||Specifies how to use default dimensions and their values.
• Code necessary
• Same code
• No code
Report selection by 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 already in the standard report selection, it is also possible to store several reports in a defined sequence in connection with order types. In addition, it is also possible to refine these printouts in relation to a customer. I.e. per customer and order type different documents can be created if necessary.
Automatic display of delivery addresses during order entry#
To minimize data entry errors and streamline the overall sales document entry process, shipping addresses to customers are automatically displayed for selection when a customer is selected in a sales transaction.
After validating the field "Sales to deb. no.", the system checks whether delivery addresses are stored for the respective customer. If this is the case, a list is displayed from which the clerk can select the appropriate delivery address for the transaction. If none of the displayed delivery addresses are to be used, the window can be closed by clicking "Cancel". This will not change the delivery address.
• The selection of the delivery addresses only occurs when the user enters the sales to customer no. in the sales document header - if a document is created via a function from the customer, the selection of delivery addresses does not occur automatically. • If a default delivery address is stored on the debit card in the "Delivery" info tab in the "Delivery to code" field for the customer, the system does not display the delivery address selection during sales document entry, but automatically transfers the address of the default delivery address to the delivery information.
To activate the automatic delivery address display, first call up the Customer & Sales setup via the user search.
The Accounts Receivable & Sales setup opens. Then activate the switch "Display delivery addresses in sales entry" on the info tab "KUMAVISION".
Other fields in delivery addresses#
In order to override various fields in the sales document depending on the delivery address, the following fields have been added to the delivery address card of the customers:
- Seller code
- Seller code 2
- VAT Business posting group
- Business posting group
- VAT No.
- Contact (with lookup to the contacts of the customer)
- Consignment storage location code
- GLN number
If nothing is entered in these fields on the delivery address, the corresponding fields of the customer are used in the sales document. As soon as a value is entered in these fields, this field content will be set in the sales document.
By specifying the VAT. Business Posting Group, VAT ID and Business Posting Group at shipping address level, it is possible to pre-populate the appropriate VAT for deliveries abroad for otherwise domestic customers without having to do this manually on a case-by-case basis in the order. This increases the data quality in order entry. By overriding the seller codes depending on the delivery address, it is easy to implement e.g. commissions by area.
Invoice shipping address#
In practice, it often happens that an order confirmation is to be sent to the customer's main company for approval, but the associated invoice is sent to an address abroad or third party (e.g. billing office).
In KUMAVISION trade365 it is possible to enter several invoice addresses for one customer for sending invoices, similar to the delivery addresses. These invoice addresses can then be used in the sales documents.
To store the invoice addresses with a customer, first call up the desired customer card.
Via the Ribbon > "More options" > "Related" > "Customer" > "Invoice to addresses", you can store several addresses for invoicing, analogous to the delivery addresses. Each billing address is identified by a unique code to be entered for each customer.
When creating the billing address, the complete address is entered including contact person and communication data. All other information regarding delivery, invoice will be taken from the customer's master record when using this billing address.
On the customer card, you can then preassign a default billing address in the "Invoice to Code" field in the "Invoicing" info tab. Invoice to Code" in the "Invoice to Code" field on the "Accounts Receivable" tab. The lookup button displays the entered invoice addresses. If you enter a default invoice address, this will automatically be taken into account in the sales documents.
However, if no standard invoice address has been stored for the respective customer, the user is shown the invoice addresses stored in the customer master for selection during sales document entry. He can then decide per document which is the correct billing address. If the window is closed with "Cancel", the address of the customer master record is transferred to the document.
In order to activate the automatic display of invoice addresses, the checkbox "Display invoice addresses in sales entry" must be activated on the info tab "KUMAVISION" in the Customer & Sales setup.
Separate collective invoice#
Especially with regard to customers that have group structures, many delivery addresses are often used in the form of customer cost centers. In order to be able to split the collective invoice according to delivery addresses in this case, a new field "Separate collective invoice according to" has been included on the "Delivery" info tab in the customer master record.
This field can be used to specify for the corresponding customer that a subdivision of the collective invoice is to be made according to "Sales to deb. no." (e.g. for association invoices) or according to "Delivery to code".
In these cases, the collective invoice run will create a new invoice document for differing records in each case.
If this option field is left <empty>, no separation will be made when creating the collective invoice.
Text modules in delivery addresses#
If you work with delivery-to-addresses in sales, it is necessary to print different information per delivery address in the documents. For this purpose KUMAVISION trade365 offers the possibility to create specific text modules for delivery addresses. The functionality is analogous to the document texts.
The text modules in delivery addresses are called up via the ribbon > "Addresses" > "Text modules" of the respective customer.
Enchancement of the info box in posted and archived sales documents#
Similar to the Infoboxes extension in the open sales documents, the following infoboxes are also available in the posted and archived sales documents:
- Accounts Receivable Sales History - Sales to Deb.
- Sale document information
- Sale document line information
The number of documents displayed in the Customer Sales History - Sales to Customer infobox refers to the documents currently available in the system. Whereas the displayed document text refers to the posted or archived document.
Inventory/acceptance lot size#
In order to control fixed purchase lot sizes in sales, there is a field called "Stock/Purchase Lot Size" on the "Stock" information tab in the article master. If a value is entered here, this article can only be sold in this lot size or a multiple of it. The multiple always applies with reference to the storage location, per storage bin and per batch number.
If the article has variants, deviating stock/receipt lot sizes are maintained at the article variant. If no value is entered in the variant, the stock/receipt lot size from the article card is used.
This fixed inventory lot size applies only to sales lines that refer to storage locations that are not a quarry warehouse.
If an item line in a sales order is entered with a quantity below the stock/acceptance size, the user will receive a corresponding message. The system offers a rounding up of the quantity to the lot size.
The hint message always appears,
- when the "Quantity" field is entered in sales documents (except the blanket order).
- when the "To be delivered" field is entered in a blanket order line.
- when the "Quantity" field is entered in a stock transfer order line.
If the "Quantity" field is entered in the blanket order, the user only receives an info message without any rounding up or down function. This also applies when changing "No.", "Variant code", "Reference no.", "Storage location code" and "Unit code" if the quantity is already filled.
If the stock/receipt lot size is only changed after an order or quotation has already been created, this is checked again when releasing, posting and creating an order from a quotation.
An error message is issued in each case.
If an invoice is created and deliveries are called off there, there is no longer a check for the purchase lot size when the invoice is posted, since this has already been delivered. The same applies to credit notes for complaint lines.
Reservation in connection with replenishment lead times#
If companies work with the "Reserve" function, then reservations can be made, for example, in sales for outstanding orders or also for warehouse stock. If existing stocks are reserved for orders whose goods issue lies far in the future, so that the goods can be procured in this period, an unnecessary amount of stock is built up when reserving, which ties up capital.
Therefore, in KUMAVISION trade365 the possibility of reservation can be limited to the respective replenishment times of the articles.
Today is 01.09.2021. An order is entered with goods issue date 13.09.2021. The article has a replenishment lead time of 10 days, so it can be procured today on goods receipt 10.09.2021. In this case it is unnecessary to reserve the stock.
In order to prevent such reservations the procurement periods must be maintained on the article and the function must be switched on in the Accounts Receivable & Sales setup with the switch "Check replenishment period on reservation" on the info tab "KUMAVISION".
If no procurement time is stored in the article and at the same time the switch is activated in the Accounts Receivable & Sales setup, the article can never be reserved. Unaffected by this setting are also articles that are set to Reserve Always. These are always reserved regardless of the replenishment period.
If the procurement period is exceeded with the goods issue date of the order line, the user receives a corresponding message when reserving.
Time limitation of blanket orders#
In the case of blanket orders, there is not only a quantity limit, but also a time limit to prevent the conditions of the blanket order from continuing to be used after the validity has expired.
For the time limitation of blanket orders, an additional field "Valid until" is inserted in the blanket orders and provided with a function. An error message is issued during manual retrieval.
The field "Blanket order:
valid until" has also been added to the sales lines in order to be able to control the validity of blanket orders at the line level later on, if desired. Currently, the fields are not included in the respective windows and contain the values from the blanket order header.
Blanket order Remaining quantity#
In blanket orders, the remaining quantity to be delivered to the customer is visible. What is not directly visible to the user is the quantity from the blanket order that has already been called off to an order but has not yet been delivered. For this purpose, the blanket order lines have been extended by the fields "Remaining quantity in order" and "Remaining quantity less order.
Sales articles are articles that are being discontinued from the product range. They can either be articles that are no longer reordered by the company or articles that are no longer supplied by the supplier. In order for the sales department in wholesale to be aware of this when entering orders for these articles, there is a sales message through the system with the availability check.
A sales item can be either an item itself or variants of the item.
To mark an article or an article variant as a sale article, first call up the desired article card.
On the "Item" info tab, you can mark the item accordingly by activating the "For sale" button.
Alternatively, you can mark each variant by checking the "For sale" checkbox for the corresponding variant. Article variants can thus be marked individually "For sale".
If an article that has article variants is itself marked as "On sale", this automatically applies to all its variants, regardless of whether they themselves have been marked as "On sale" in the Article variants table.
When entering an item marked for sale in a sales order, the user receives a notice with the availability message that this is just such an item.
Any existing orders for this item will not be displayed for items marked for sale in the availability check. Planned receipt is always set to 0, as it cannot be guaranteed that this order will still be delivered.
If an order exists for this item, it will not be included in the availability message if the delivery date of the order is later than the delivery date of the order.
If the desired delivery date of the order is earlier than the planned goods receipt, an "Earliest availability date" is displayed.
No residues on sale#
There are customers who do not want an order to be re-delivered. Only what can be delivered in one shipment should be delivered from the ordered goods, the rest of the order is reordered by the customer.
For this requirement, KUMAVISION trade365 has the function "No residues in sales".
To set this up, first call up the desired customer who does not want a subsequent delivery.
Then activate the "One-time delivery per order" checkbox on the "Delivery" info tab.
Use in process#
One time delivery per order#
If you then enter a sales order for a customer with the "One-time delivery per order" checkbox enabled, the "One-time delivery per order" field will be transferred from the customer master record to the order. The field is editable in the sales documents. I.e. it is possible to allow one-time exceptions from the default setting of a customer.
If there is subsequently a quantity deviation of the "Quantity" field from the quantity to be delivered / invoiced, the system automatically reduces the quantity when posting and sets the order to completed.
If you work with logistics in goods issue / picking for a one-time delivery, the quantity of the respective item is also reduced in the order by posting the delivery.
The posted delivery of the order contains the field "Order quantity original". Here, the originally ordered order quantity is displayed and recorded, which enables later evaluations of the delivery capability.
Orders with one-time delivery are not automatically deleted when the invoice is posted. To delete these orders, the standard function "Delete completed orders" is used.
The logic for the one-time delivery can not only be set for the complete order as described above, but also per order line differently, if e.g. only for a certain article of the order is not subsequently delivered, but for all other articles of the order is subsequently delivered. To do this, set the "One-time delivery per order" checkbox.
The setting Shipping type:
Complete delivery and additionally One-time delivery = Yes exclude each other. With complete delivery, the system expects that the order quantity is also completely available.
One time delivery for direct delivery#
If an order with one-time delivery and an order via the direct delivery function are linked, the user is informed about the one-time delivery of the order when processing the order.
If the quantity of the order line is changed manually before posting the delivery, nothing changes to the usual procedure of direct delivery. The user is asked whether the order should also be reduced.
However, if the quantity of current delivery of the order line is reduced, the user receives the information that in the related sales order line the field "One-time delivery per order" is set and neither in the order line nor in the order line the quantity is automatically adjusted to the delivered quantity.
This means that the quantities must now be adjusted manually here. This note is only made in the purchase order, not in the goods receipt or in the putaway, since with direct delivery only the purchase order is always worked with.
Detailed prepayment invoices / credits#
The standard "Prepayment" function is used to pre-bill part or 100% of the order value to the customer. The prepayment amount can be calculated as a total amount ("Compress prepayment") or per order item. However, information about the item, unit price and unit is lost, because in the standard the corresponding G/L account of the accounting is printed.
In KUMAVISION trade365 there is therefore the possibility to enrich the prepayment invoices and credit notes with detailed information. For this purpose, the switch "Detailed information for prepayment" has to be set in the Accounts Receivable & Sales setup on the info tab "KUMAVISION". In the sales order, the "Compress prepayment" checkmark must not be set in the Prepayment tab.
Now, when a prepayment invoice is posted to the customer and printed, it contains the same detailed information as a normal sales invoice.
Via consignment warehouse control, users are able to manage an "external warehouse" at a customer location and settle the consumption on the part of the customer.
Since the goods at the customer storage location remain the property of the user until resale to the end customer, the goods must be properly distributed to storage locations within Microsoft Dynamics Business Central™.
Example of application-side flow :
The consignment warehouse is "initially loaded" by transfer order, e.g. from the user's main storage location (MAIN) to the customer's consignment warehouse (KONSI).
The customer consumes / sells these goods. The consumption is reported by the customer to the user. This can be done either by sales reports or new orders.
Within Microsoft Dynamics Business Central™ an order/invoice is now created for the customer with corresponding positions. If the field "Consignment storage location code" is filled in the customer, the consignment warehouse is used as storage location for the sale after user query.
The order lines automatically receive the storage location "consignment storage location code" from the header as the preliminary storage location.
The delivery of the order is posted and invoiced (either by individual or collective invoice). Thus the stock / stock value on the consignment stock is reduced and the consumptions are invoiced to the customers. This process also ensures that items requiring batch or serial numbers are handled properly.
When posting the delivery, a new stock transfer order for the consumed items is automatically created in the background of the application after a user query ("Do you want to replenish the consumed goods at the consignment warehouse?"), so that the stock of the consignment warehouse is replenished without any further manual effort and without explicit logistical interventions (standard logistics expansion stages are used).
To set up a consignment store, first call up the "Storage locations" via the user search.
Via "New" in the menu ribbon you can create a new storage location as usual.
The following fields must be additionally set up for the consignment store on the "General" info tab:
|VK Consignment Camp||Activate the switch to indicate that the storage location is a consignment store.|
|Consi. Apportion. from code||Enter the storage location code in this field from where consignment stocking is to take place. This entry is necessary for the stock transfer.|
In the storage location map, certain storage locations can be marked as sales consignment warehouses (field "Is sales consignment warehouse" = Yes). In addition, a defined storage location can be set up in the "Consi. stock transfer from code" field for stock transfers to it for replenishment. If no "Stock transfer from code" storage location is defined, the stock will be transferred from the customer storage location or the standard storage location.
In order to assign the consignment storage location set up to the desired customer, first call up the customer card.
Then enter the corresponding consignment warehouse on the "Delivery" info tab in the "Consignment storage location code" field. If a storage location is entered here, it is considered the consignment warehouse of the customer. A unique assignment of a consignment storage location to exactly one customer must be maintained.
Alternatively, a consignment location can be assigned to a single delivery address of the customer in the
To do this, call up the "Deliveries to addresses" via the ribbon > Associated > Customer and enter the corresponding consignment warehouse in the "Consignment storage location code" field.
If a consignment storage location was assigned to a delivery address, this has a higher priority than the assignment on the customer.
For a quick overview, it is possible to call up the overview "Articles by storage location" filtered according to the "Consignment storage location" stored in the customer card from the customer card via the menu item "Belonging" > "History" > "Article stock by consignment storage location".
Set up the stock transfer routes accordingly for consignment stocking. To do this, call up the "Stock transfer routes" via the user search. For more information on the stock transfer routes, refer to the Microsoft Dynamics Business Central™ Helpsite (F1).
Stock posting setup#
In addition, the G/L accounts for the consignment warehouse must be entered in the warehouse posting setup. To do this, call up the "Stock posting setup" via the user search. For further information on the warehouse posting setup, please refer to the Microsoft Dynamics Business Central™ Helpsite (F1).
On the respective article card you have the possibility to display articles in consignment storage location via the menu ribbon > "Belonging" > "Availability" > "Article by storage location". As soon as you set the switch, only the storage locations with "Is consignment stock" = Yes will be displayed in the storage location overview.
In addition, you can set up the inventory data as usual.
Consignment processing on the customer side#
When entering a customer in the field "Sales to customer no." in a sales order or a sales invoice, the system checks whether a consignment storage location is assigned to the customer in his customer card. If this is the case, a query is made as to whether a consignment issue is to be processed.
If the user confirms this query with "Yes", the consignment storage location assigned to the customer is entered in the sales order header in the new field "Consignment storage location" and this consignment storage location is entered in all sales order lines of the sales order in the field "Storage location" (issue warehouse).
If the storage location is changed in the Delivery to code field, a query is issued. The storage location in the sales order lines is editable as in the standard, i.e. a storage location different from the consi storage location of the order header can be entered in the respective lines.
There is a corresponding availability check based on the storage location when the items are entered. After posting the delivery (from the sales order or from the goods issue), the system checks whether at least one line to be delivered contains the consignment storage location from the sales order header as a storage location. If this is the case, a query is sent to the user asking whether the consumed goods should be replenished at the consignment warehouse.
If this query is confirmed, a stock transfer order is created for the consignment storage location from the sales order header with the delivered lines of the order as items.
When creating a stock transfer order for consignment storage locations, the system checks that the selected consignment storage location is assigned to only one customer. If this is not the case, the system terminates with an error message.
For this functionality (creating the stock transfer orders) it is necessary to set up the various stock transfer routes, as the transit storage location codes are required for the stock transfer orders.
In the stock transfer order, the following fields are filled according to the sales order:
|Apportion. by code||The consignment storage location is entered in the stock transfer header and stock transfer lines.|
|Quantity||If the "Quantity to be delivered" from the sales order line (i.e. the quantity just delivered by the current delivery) is in the stock transfer lines|
|Apportion. from code||Is determined in the following hierarchy:
The stockkeeping data of the article with the storage location code of the consignment storage location are checked. If the corresponding storage data are found, the "Stock transfer from code" storage location stored there is decisive as the issue storage location.
In the second step, the system checks whether a storage location code is stored in the "Cons. Stock transfer from code", if necessary this is defined as issue storage location.
If necessary, the next step is to check whether a storage location has been assigned to the customer.
If none of the preceding hierarchy levels apply, the standard storage location is defined as the issue warehouse.
If the determination of the storage location in this 4-step hierarchy search did not result in a storage location for the article, no stock transfer line is created for the sales line.
So, if the corresponding stock transfer lines could not be created for all article lines of the delivery, a corresponding message will be issued at the end.
If several stock transfer orders have been created (because different \
In the stock transfer order, the two fields External document number and Your reference can be filled manually. Data contained there will be printed in the logistics documents. This allows detailed information about the customer order on a delivery bill or in the EDI message.
Notes on consignment processing during printing#
If the document lines with the consignment storage location exist in the sales order (storage location of the sales line is the same storage location from the "Consignment storage location" field in the sales header, the warning that at least one document line with the consignment processing relevant storage location exists for the order is issued before the sales order confirmation is called.
The same check is performed with a message also in the goods issue when printing the document, as well as in the document "Posted sales delivery".
In report 208 "Sales delivery bill" a corresponding note has been added to the respective delivery line for consignment.
Archiving reasons sales documents#
Sales documents can be archived for different reasons. The system archiving reasons are automatically written to the archive.
Archiving reasons for offers:
- Offer according to order
Archiving reasons for orders/sales complaints:
Archiving reasons for blanket orders:
Follow-up task for offers#
In standard Microsoft Dynamics Business Central™, when printing a quote, the user is always asked if he wants to create a follow-up task for the quote. Customers who do not work with the task management do not need this query. Therefore, in KUMAVISION trade365 the follow-up task is always disabled when printing a quotation. It can be reactivated by setting up "Enable follow-up task" in the Accounts Receivable & Sales setup.
In standard Microsoft Dynamics Business Central™, customers can be assigned a "Collective Invoice" identifier. With this, collective invoices can be created. However, not in intervals, but always only in manual accrual of posted delivery dates. In companies, however, there are various constellations of how a company can issue its invoices to the customer. Collective invoicing at fixed intervals, collective invoicing for an order with the last delivery for this order, immediate invoicing, etc. In order to take these possible constellations into account, the invoicing can be handled using the "Periodic Invoice" function. This function issues invoices to customers as agreed with the customer.
The periodic billing cannot be used in combination with prepayment invoices. In case of prepayment, the prepayment invoices must still be posted manually.
The setup for periodic billing is mainly done on the customer card. To do this, you first call this up.
The possible setups of periodic billing are explained below:
Collective invoice (period)#
For the collective invoice (period), make the following setup on the desired customer card:
"Invoicing" information register#
|Invoicing type||For the collective invoice (period), the "Invoicing type" field must be set to "Collective invoice (period)".|
|Invoicing rhythm||The "Invoicing rhythm" field must be set to "Periodic" for the collective invoice (period).|
|Invoicing interval code||In the "Invoicing interval code" field, the corresponding interval code is stored. For example 2W|
|Next billing date||The Next billing date field is calculated automatically by the system. When setting up the customer, it must first be set for the first invoice interval.|
"Delivery" information register#
|Collective invoice||The "Collective invoice" switch must be active.|
If the periodic billing document is now created, all posted deliveries of the customer are retrieved in a new sales invoice, which are currently pending for billing. See also Periodic billing process. Depending on the billing date of the periodic billing document and the next billing date on the customer, the delivered items are retrieved into a collective invoice. If the next billing date has not yet been reached, the collective invoice will not be created.
Invoice per order (period)#
The setup is analogous to the setup for collective invoice (period). Only in the field "Invoicing type" the option "Invoice per order (period)" is set. All other settings must be made in the same way.
In the Periodic billing run, all deliveries of an order that lie within the billing period are now combined into one sales invoice. One collective invoice is thus generated per order per billing period.
Invoice per order (last delivery)#
This setting is about invoicing per order, i.e. not combining multiple orders into one invoice. However, the invoice is generated only after the order is completely delivered. If the order still contains an item with remaining quantity, it will not be proposed for billing in the periodic billing.
The required customer is set up as follows:
Invoicing information register#
|Invoicing type||For the invoice per order (last delivery), the "Invoicing type" field must be set to "Invoice per order with last delivery".|
|Invoicing rhythm||The "Invoicing rhythm" field must be set to "Immediately".|
"Delivery" information register#
|Collective invoice||The "Collective invoice" switch must be active.|
Invoice per delivery bill#
The setting Invoice per delivery bill corresponds to the procedure of manual posting Deliver + Invoice. A sales invoice is generated for each delivery posted by the customer.
The following settings are to be set up on the customer:
"Invoicing" information register#
Field Description Invoicing type For the invoice per delivery bill, the "Invoicing type" field must be set to "Invoice per delivery bill". Invoicing rhythm The "Invoicing rhythm" field must be set to "Immediately".
"Delivery" information register#
|Collective invoice||The "Collective invoice" switch must be active.|
Periodic billing process#
To trigger the periodic billing, first call up the "Periodic billing log" via the user search.
To create all invoices for the current day, call up the "Execute periodic billing" menu item from the ribbon.
The execution screen for periodic billing opens where you can set the following filters for executing the billing:
|Posting date||Posting date for the invoices to be posted|
|Replace posting date||Yes replaces the posting date of the created sales invoices with the posting date from the options.|
|Replace document date||Yes replaces the document date of the created sales invoices with the posting date from the options.|
|Calculate invoice discount||Yes calculates the invoice discount for the customer in the generated document.|
|Invoicing date||This date is checked for the collective invoices to be created or invoices per order that are settled periodically. If the billing date from the options is not identical or is greater than the Next billing date on the debit card, no sales invoices will yet be created for the customer in question.|
|Update next invoice date for customer||The next billing date field of the customer card is entered based on the billing interval. This is done regardless of whether invoices are currently being created for a given customer. As soon as it is in the filter of customers to be passed through, its invoicing date will be updated.|
|Post invoice||Yes causes the generated sales invoice to be posted directly.|
|Print booked invoice||Yes causes the posted sales invoice to be printed on the Windows default printer.|
|Delivery date filter||Specifies the period of time to search for posted deliveries in order to create sales invoices.|
Customer tab and Sales order tab:
If filter criteria are entered in these two tabs, they will be taken into account when the "Execute periodic billing" function is run. For example, only orders from a specific customer. Only orders without prepayment, etc.
After you have made your filters, confirm your input with "Ok" to execute the periodic billing.
All invoices that have been created are set in the "Periodic invoice" overview. Green marked rows are posted invoices. Yellow marked lines are set invoices that have not been posted yet. Red marked rows are invoices that could not be posted due to error messages. In this case, the errors must be corrected manually and the invoices must be posted manually.
The posted and unposted documents can be opened from the overview. In addition, the messages due to which a posting could not be made are displayed in the error log.
The error text can also be called up separately in the menu ribbon under [...] - "Actions". In addition, the actions for deleting older entries are also located under this menu item.
In the ribbon under [...] - "Related" the report "Adjust periodic billing settings at customer" can be called.
This allows the Next invoicing date to be overwritten or reset on the customer card. With the type "Fixed date" a new fixed invoicing date, e.g. 01.01.2021, is entered manually. With the type "Date of last invoice" a new next invoicing date is calculated based on the last invoicing date of the customer and his invoicing interval and stored on the customer. In the "Customer" tab, the selection of customers to be processed can be limited.
When periodic billing is run, sales invoices are created, it is not posted directly from the order. The effect of this is that orders that have been fully billed using this function are not automatically deleted on completion. They are only displayed in the overview as fully billed.
To delete these orders from the system, the "Delete completed orders" report must be run at regular intervals.
Dispatch of reminders incl. associated invoices#
For the end customer, it is easier to process reminded invoices if the invoices are sent directly to him together with the reminder. In addition, this eliminates the need for the end customer to request invoice documents that can no longer be found. Therefore, in KUMAVISION trade365, when printing or sending registered reminders by e-mail, the corresponding invoices are printed automatically.
If the reminders for a customer are sent by e-mail document dispatch, the invoices are integrated as PDF documents in the e-mail document. When printing at the printer, please note that the reminder and the attachments are each printed on the printer set up in the printer selection. This leads to the fact that with PDF printing (not with e-mail document sending) the reminder is generated as PDF, but the attachments to it on the standard printer set up at the user.
Long-term supplier declaration#
For deliveries to recipients within the European Union, certificates of the originating status of a good must be issued per long-term supplier's declaration. And this in terms of a preferential arrangement maintained by the European Union. In order to generate a Long Term Supplier Declaration based on the underlying item sales in Microsoft Dynamics Business Central™, a new report Long Term - Supplier Declaration has been developed in KUMAVISION trade365.
For the Lanzeit supplier declaration, some basic setups must first be made, which are explained in more detail below:
Accounts Payable & Purchasing Setup#
Call up the "Accounts Payable & Purchasing Setup" via the user search. On the info tab "KUMAVISION" you have the possibility to enter a text for the printout for the European countries of origin in the field "European country of origin text".
Countries / Regions#
In the countries/regions list, the countries of the European Union are marked. To do this, call up the "Countries / Regions" list via the user search. In the "European Union" field, place a check mark next to the countries that belong to the European Union.
All countries marked here, are supplemented in the report edition with the text for European countries of origin.
Article - Preferential countries assignment#
Since there is no uniform rule for the assignment of articles to the preference rule, the respective preference countries for a particular article must also be stored there. The countries stored on the article are listed in the long-term supplier declaration.
To make this assignment, first call up the desired article card. You can call up the preference country table via the "Belonging" > "Article" > "Preference countries" ribbon. All valid preference countries for this article are entered in the table.
Execution of the report long-term - supplier declaration#
The Long-Term Vendor Declaration report can be accessed from the Accounts Receivable list or from the User Search.
Basically, the report checks items for a given customer in a given period of time and creates a long-term vendor declaration for the items sold to the customer in that period of time.
To run the long-term supplier declaration, access it first. The criteria for executing the report are explained in more detail below:
Here you can select in which language the supplier declaration should be created. You can choose between German or English.
|Debitor no.||Enter here the customer no. for which you want to create the supplier declaration.|
|Contact no.||In this field you can specify a contact person to be printed in the report.|
Register goods delivery date:
In the tab "Goods delivery date" the filter for the posting period of the article items is entered. I.e. all articles from sales article items of this customer in the posting period From to will be listed in the long-term supplier declaration.
Register validity period:
In the Validity period, enter the validity period with Valid from date and To date, which will be printed on the report.
If there are items for which the cumulation indicator must be specified because a component of the item was manufactured in Morocco, for example, even though the item itself has a region of origin within the EU, the indicator must be checked when the report is run.
If you have made all the entries, you can first view the supplier declaration via "Preview" or send it or print it out in advance via "Send to" or "Print".
If you have activated the "Cumulation" check box, the input table for the articles with cumulation notes will appear first. If the checkmark is not set, this table will be skipped.
In the table "Cumulated articles" all articles are entered, for which you have to indicate a cumulation note in the Lanzeitlieferantenerklärung. The selection of the articles is done via the lookup in the field article number. Then the country of origin for the cumulative remark is entered.
If the customer has now purchased the item in question in the selected period, an accumulation note will be entered for this. Marketing
Extension profile questionnaire#
When categorizing contacts, it may not be sufficient to use the fields or profile questionnaire functionalities provided by the Microsoft Dynamics Business Central™ standard.
For example, if the number of possible answers to a question of the profile questionnaire is too large (E.g. year numbers or not only a number of employees range, but the exact number of employees), the usability is no longer given. In KUMAVISION trade365 the profiles of the CRM are extended in such a way that not only an answer can be selected, but also values can be recorded when answering.
In addition, once selected answers can be saved in a history table so that it is always possible to see which answers were given and when. The current value must always be displayed in the profile questionnaire and in the display of answers in the contact's rows.
When setting up the profile questionnaires, two additional columns have now been added. The column "Answer type" defines how the user's input should look like. Until now, only a yes or no answer was possible. Now answers can also be entered as a numerical value (with/without decimal places) and as free text.
The selection option for this is:
- Decimal number
An entry of, for example, "3.5" is not yet meaningful. By means of the "Response unit code" column, the entered number also receives additional significance, e.g. 3.5m³. This unit can be used for preconfiguration. The unit codes set up in the system are available.
The operation of the questionnaire is the same as before. For "Yes/No" answers, the corresponding column can simply be clicked. For free text answers and/or the recording of numbers, the value is entered in the "Answer" column.
If a user places a check mark in the "Selected" column to select this answer, he or she will receive a message that a text or number answer must be entered in this row.
The responses made will then be displayed in the contact management - map in the lines as an overview.
When creating a segment, the values entered in this way can be filtered. The user selects his addresses according to the criterion Profile questionnaire and can specify the desired answer text of a line.
Archiving the answers of a profile questionnaire#
If the information in the profile responses for a contact changes, the user can archive the "old data". The archiving of the answers is done manually. The user opens the desired profile questionnaire. There in the menu ribbon "Belonging" he can call this menu item and archive the answers.
When archiving, the work date is also written.
Changing a once archived answer in the profile questionnaire is only possible if the question for "Multiple answers possible" is activated.
Once archived answers can be viewed again via "View archived answers". The last version is automatically called up. It is possible to access all versions of the answers at any time via the "Version number" field.
Create segments with reference to service information#
The segments in the Marketing section are used to create address lists. In segments contacts can be added and removed. In addition to the standard criteria areas such as Contact, Profile, Value Items, etc., in KUMAVISION trade365 it is also possible to tap information from the Service area to create segments with contacts. This can be used to generate address lists of customers who own service items whose warranty date is about to expire, in order to be able to offer you follow-up contracts. Or alternatively, customers can be targeted based on service contract information.
Create a new segment. Add new contacts. If information from the service item or service contract is to be accessed, the respective switch must be activated in the options of the request page. If segments are created based on contacts, the switch in Consider contacts must be enabled.
For the Consider service items option, only contacts of the Company type are added (Customer contact). The Extend company etc. options work only for the Consider contacts option. For the Consider service contracts option, the contacts that are listed in the Contact no. field in the service contract header are listed. These can be persons or companies.