Introduction: In Business Central, we can use Task Scheduler to utilize background processing to ensure that Users do not have to wait for completion of long operations. Task Scheduler provides us an easy to use and monitor way to offload tasks from the main thread. It creates separate sessions for processing and it allows creating multiple sessions which can be used to run tasks in parallel. It also allows us to define the company in which the processing will happening which is useful when we have to perform operations across all available companies, for example initialization of certain fields or creation of certain records on extension installation. Pre-requisites: Business Central OnCloud or OnPremise References: TaskScheduler Data Type – Business Central | Microsoft Docs Task Scheduler – Business Central | Microsoft Docs Configuration: The following procedures are available for the Task Scheduler data type: CanCreateTask() – Checks whether it is possible to create a new task in this session. CreateTask() – Creates a new task with the specified codeunit, we also specify which Codeunit to run if the main codeunit fails, whether the starts of this task would be Ready when it is created, the company this task will be running under and the time after which this task is to be run. TaskExists() – Checks whether the specified Task exists or not. SetTaskReady() – Sets the specified task status to Ready, a Task can only begin processing if it is in Ready state. CancelTask() – Sets the specified Task’s status to Cancel. A Task can only be set to cancel if it is in pending state. A task that is in progress cannot be cancelled. In case the main Codeunit hits an exception then there are two cases: The exception is retriable :- Business Central will re-try the main codeunit a specific number of times with a specific time interval, if it is unable to complete then the task is failed. The exception is not retriable :- The task fails and the session is deleted. Further if there is a failure codeunit defined then Business Central will run the Failure codeunit instead of failing the task and similarly if the Failure Codeunit hits an exception that is it unable to handle then there are same two cases: The exception is retriable :- Business Central will re-try the main codeunit a specific number of times with a specific time interval, if it is unable to complete then the task is failed. The exception is not retriable :- The task fails and the session is deleted. I have created an action which creates a simple task for all the companies available to the User. After that action is called, we can see that there are four separate sessions created with the same codeunit for different companies. The below is the screenshot of the page – Scheduled Tasks Conclusion: Thus we saw how to create and use Scheduled Tasks in Business Central for background processing. Business Central OnPremise requires some configuration before Task Scheduler can be used you can refer to the below link for the same.Microsoft Dynamics 365 Business Central Server Configuration – Business Central | Microsoft Docs

 Scenario: A Business Central User receives a Sales order, the user then created a new customer and linked the new contact to it. The user Created a Sales Order and Posted it. Later found out that the user has created a duplicate customer. The new contact should be linked to Original customer. Steps: How to Merge Duplicate Customer Data. 1. In the Customer list below, the Original Customer no. 5000 has higher balance then the duplicate customer no. C00010 . The correct Contact, Mr Jim Halpert is set for duplicate Customer. 2. Now to Merge the duplicate Customer no. C00010 to Original Customer no. 5000, Open the Original Customer card and click on ‘Actions – Function – Merge with’ 3.The Merge duplicate page will open up, in the Merge with Field, enter the duplicate Customer no. In the fields FastTab, we can override the field value. In this case, check the Override box for contact as it needs to be linked to the original Customer. After updating the fields, now we can hit the Merge button on upper left corner. 4. A message will pop up, warning the user that the merging cannot be undone. The duplicate customer will be deleted permanently and data will be combined with original customer. 5. Now if we go back to Customer List, the duplicate Customer is deleted. The balance of Original customer has Increased. The relevant posted sales shipment and Posted sales Invoices are updated with duplicate customer’s data. 

CUSTOMER POSTING GROUPS Customer Posting Groups determines the account receivables account.  1. In the search option, enter Customer Posting Groups and then choose related link. 2. In the Code Field, type unique identifier. 3. In the description field, type description of Customer posting group. 4. In each relevant account field, enter the G/L account  that will post the transaction accordingly. Receivable Account: This is a summary account where all the entries from customers will end up in balance sheet. Service Charge Account: This is a fee account where any fee you Charge to the customer when invoicing will end up here. Payment Discount Dr. Account: This account represents cash discounts given to the customers, then the sum representing the difference in original amount and what they’ve actually paid. This will be in debit field. Payment Discount Cr. Account: This account represents cash discounts given to the customers, then the sum representing the difference in original amount and what they’ve actually paid. This will be in credit field. Interest Account: It is an account to which, if you issue reminders or finance charge memos with interest on them, this interest revenue will be posted to this account. Additional Fee Account: This is where the reminder fees and finance charge momos will be posted when they are issued. Add. Fee per line Account: This is where reminder account will be posted if you have a reminder amount on each line of your remainders. Invoice rounding Account: This is where invoice rounding will be posted. Debit Curr. Appln. Rndg. Acc/ Credit Curr. Appln. Rndg. Acc: Both accounts are same except one is Dr and other is Cr. This account is particularly used when you are applying an entry on your customers from different currencies. E.g. Invoice is in USD but payment is in EUROS, in this case rounding difference will be posted to this account. Debit Rounding Account/ Credit Rounding Account: This is same as above mention field except the difference is of same currency and needed a slight adjustment. These accounts will therefore be used to Debit or Credit respectively.  Payment tolerance Debit account/ Payment tolerance Credit account:  These accounts are used to have a payment tolerance towards customers. e.g. If the customers is Invoiced USD 105 but customer pays only USD 100, and you have set a tolerance for 5USD which means the difference will be posted to these two accounts.  Assign Customer Posting Groups to Customers 1. In the search option, enter Customers and then choose related link. 2. Open a Customer Card. 3. Expand Invoicing Tab, in Customer posting group field enter relevant details. VENDOR POSTING GROUPS Vendor Posting Groups determines the account payable account. 1. In the search option, enter Vendor Posting Groups and then choose related link. 2. In the Code Field, type unique identifier. 3. In the description field, type description of Vendor posting group. 4. In each relevant account field, enter the G/L account  that will post the transaction accordingly, Payables Account: This is a summary account where all the transaction from vendors will end up in balance sheet. Service Charge Account: This is a account where you can put any service charge that might come from the vendor. Payment Discount Dr. Account: If you pay your vendor ahead to time and get a cash discount, a debit entry will end up in this account. Payment Discount Cr. Account: This account represents cash discounts given to the customers, then the sum representing the difference in original amount and what they’ve actually paid. This will be in credit field. Invoice Rounding Account: This account is used when an invoice from the vendor has to be rounded. Debit Curr. Appln. Rndg. Acc/ Credit Curr. Appln. Rndg. Acc: This account is used when the different Currencies have to be applied to each other and rounding has to be carried out. Debit Rounding Account/ Credit Rounding Account: This is used when you settle the outstanding amount in same currency but a little rounding off is to be done. Payment tolerance Debit account/ Payment tolerance Credit account: These accounts are used to have a payment tolerance towards vendors. Assign Vendor Posting Groups to Vendors 1. In the search option, enter Vendors and then choose related link. 2. Open a Vendor Card. 3. Expand Invoicing Tab, in Vendor posting group field enter relevant details.

Introduction: Business Central provides us with Web Services which we can use for CRUD operations on specific tables. However it also provides us with different methods of accessing specific records for CRUD operations. Pre-requisites: Business Central On-Premise or OnCloud. References: https://docs.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/properties/devenv-odatakeyfields-property Usage: In Business Central, if we do not specify the ODataKeyFields as a property on the Page that we’ll be using as Web Service, then by default we have to use the Primary Key. However if we specify the “ODataKeyFields” in the page, we can use the field we have specified as the key for pulling the record in Web Services. While there are no limitations on which field can be used as key field, keep in mind that Business Central fetches the first record matching that field. For instance if you use the “Buy-from Vendor No.” as the ODataKeyField, then the Web Service will fetch the first matching record sorted by the Primary Key. Standard Business Central APIs use the “SystemId” field as the ODataKey field. You can also use multiple Keys in ODataKeyFields and use them for fetching records. Conclusion: Thus, we saw how we can use ODataKeyFields property for fetching records and performing CRUD operations. As a side note, you can also use multiple keys in ODataKeyFields.

Introduction: Business Central provides us an easy method of modifying our data from within Excel using Web Services commonly found in the Edit in Excel action. This can be seen in the commonly used List Pages for example Payment Terms. However this functionality can be missing for certain pages or you might want to have additional logic or filtering before executing this. For this I’ll be demonstrating how to add the “Edit in Excel” action in Business Central pages. References: Viewing and Editing in Excel From Business Central – Business Central | Microsoft Docs Using Filter Expressions in OData URIs – Dynamics NAV | Microsoft Docs Configuration: In the above piece of code, I’ve added the “Edit in Excel” action onto the Blanket Sales Order SubForm to allow for easily adding lines using Excel. Firstly, we define the filters that we will be using on the page that we will be passing in the “EditWorksheetInExcel” procedure of the “OdataUtility” codeunit. Note that these filters are defined as Odata expressions as the “Edit in Excel” functionality uses Excel behind the scenes. In the next lines, we see that we pass the Page Caption, the page ID and the filters to be set on the page. Under the hood, the procedure creates a Published Web Service using the provided Page ID and uses that for the data manipulation. We had to prepend the additional “00000” as the procedure has been hardcoded to use “COPYSTR(“00000″ + {PageID}, 5)” meaning it starts reading after the 5th character. Conclusion: Thus we saw how to configure Edit in Excel for pages that do not have built in Excel functionality. Also note that Microsoft is expanding the Excel functionality to List Parts from Business Central v19 Wave 2, you can read more about it here.

Introduction: Business Central provides us with Change Log which helps us in keeping track of the changes made to a particular field in a particular table. References: Auditing changes – Business Central | Microsoft Docs Configuration: Search for Change Log in Business Central.  Select the tables you want to enable the change log for.  You can set the change log for a particular set of fields or for all the fields in the table.Click on the three dots next to the “Some Fields” and select  the fields you want to audit. Set Change Log Activated to true.  Conclusion: Thus we saw how we can configure Change Log for auditing and tracking changes in Business Central.

Introduction: In this blog, we’ll be looking at how to reduce manual work in creating Sales Line in Business Central. For this, we’ll be using the Out of the Box feature of “Recurring Sales Lines” References: Standard Recurring Sales and Purchase Lines – Business Central | Microsoft Docs Configuration: Search for Recurring Sales Lines in Business Central global search and then click on New. Enter a Code for Identification, a short description and the Currency Code, if applicable. In the Lines, enter the Sales Line which are to be re-created. You can also define a Quantity if you want, it can be easily over-written if necessary. Go to the Customer Card for whom the Recurring Sales Line we created is going to be applicable. Then Go to Related > Sales > Recurring Sales Lines. Set the Code of the Recurring Sales Line, we just created and set the Valid From and Valid to Dates. The Insert Rec. Lines have the following options: Manual – System allows you to add the lines as and when required. Using the “Get Recurring Sales Lines” action. Automatic – System adds the recurring lines automatically whenever the Document is created. Always Ask – System shows a notification above which allows you to fetch the Recurring Lines in one click. Conclusion: Thus, we saw how to configure Recurring Sales Lines in Business Central which is a very useful tool in reducing manual work.

Introduction: Based on certain values dynamically show and hide the fields in the request page of the report. Ideally, we cannot directly use visible property to fields. we can do this by enabling the visibility of fields using groups. Steps to achieve the goal: Create a groups and add the fields which you want to show and hide based on selected data. For example, I have an option filed called Filter By- State, Customer, and Both. If I choose Customer then the Customer field should be visible and if I choose State then the State field should be displayed if I choose both then the Customer and State field should be visible. Create a 2 boolean variable which is of InDataset Create Customer and State field and assign it to groups in report. Then the field value which is been used to show or hide other fields write the below code OnValidate trigger So the above code will do the following if my Filter By field is State then the State field will be visible and if it is Customer then only the Customer field will be visible. If both are selected then both Customer and State fields will be visible. Note: If you want to show or hide the field based on only one value then you don’t need to use the InDataset attribute on the Boolean variable Conclusion: Thus we saw how we can dynamically show and hide the fields based on selected values on the request page in Business Central. Thank you very much for reading my work. Hope you enjoyed the article!

 There are certain scenarios where you have mistakenly applied the payment to the wrong vendor or you need to refund the vendor. There are two methods in order to resolve these issues. Steps to achieve the goal: Method 1: Globally search vendors. Select the vendor in which payment is applied incorrect. Go to Vendor Tab-> Ledger Entries tab. Open the Ledger entries of that vendor and then select the payment which you want to unapply. Go to Process tab and Unapply Entries. A Unapply Vendor Entries page gets open select the payment line and then click on Unapply action and click on OK. Once you click Ok the payment line in vendor ledger entries its remaining amount will not be 0. In order to balance the G/L entries we need to post the refund entry. Go to payment journal-> select the document type Refund Posting date must be same as Payment Posting Date or actual refund date. Assign the Account type as Vendor and assign the Vendor number. Select the Applies to Doc Type as Payment and in Applies to Doc No assign the Payment Document Number. Select the payment method code of return. Select the balance account number appropriately. Post the entry. If you go and check the vendor ledger entries it will be nullified against the refund.                                                                      OR Method 2: Repeat above step number 1,2,3,4,5 and 6 from Method 1 Go to Process tab-> Reverse transaction. Reverse Transaction entries page is open and in which there is action called as Reverse Transaction click on it and entries will be reversed. Conclusion: Thus we saw how we can reverse/unapply the payment mistakenly applied to the wrong vendor in Business Central. Thank you very much for reading my work. Hope you enjoyed the article!

References: Data Access – Business Central | Microsoft Docs Database.SelectLatestVersion Method – Business Central | Microsoft Docs Explanation: Caching is one of the methods which systems use to improve performance and respond to requests rapidly. In a Business Central system, caching is done at two levels: Business Central Server Instance Data Cache SQL Server Data Cache. Whenever a User requests data from Business Central, it firsts check whether The data is available in the Server Instance’s cache, If not, then it checks the SQL Server Data Cache, And if not here then it fetches the data from the database. The Business Central Server Instance’s Cache is accessible to all the Users connected to that Server Instance. There are two types of cache stored here, Global Cache Private Cache Global cache is the one which is accessible to all the Users connected to the SQL Server. Private cache is only accessible over a transaction, for a particular User, for a particular company. This cache is cleared as soon as the transaction is completed. Which cache is to be used for which User depends on whether the Table from which the User is requesting data is locked or not. In case it is locked, Private Cache is queried else Global Cache is queried. The following procedures in Business Central support using Cache: GET GETBYSYSTEMID FIND FINDFIRST FINDLAST FINDSET COUNT ISEMPTY CALCFIELDS Whenever we make a call to the “FIND” functions, 1024 records are cached. The Data Cache size in Business Central can be changed using the “Data Cache Size” setting of the Business Central Server Configuration file. The default value is set to 9 which is equivalent to 500mb. Increasing the value by 1 doubles the cache size. If we want to latest data from the database to be fetched, i.e. if we want to bypass the cache, we can use the “SelectLatestVersion” procedure. The results from Query objects in Business Central are not cached. If there are multiple Server Instances over a single database, Business Central synchronizes the cache every 30 seconds by default. We can change this by using the “CacheSynchronizationPeriod” parameter in the CustomSettings.config file. Conclusion: Thus we saw how to Caching works in Business Central and how we can optimize it usage for maximum performance in Business Central.