Introduction: While using Business Central Web Services or APIs, we often use POSTMAN for testing the request and the responses. Today we’ll see how we can automate this testing to a certain extent using the inbuilt features of POSTMAN. We can have testing logic that runs before every request, after every request or logic that tests on particular request. In the below demonstration, we’ll write automated test to check for GET, PUT, POST and DELETE operations for a single record on a custom API. Postman itself provides a bunch of standard procedures or boiler plate code which we can modify as per our requirements. As this uses Javascript we can also use additional JS features here. Pre-requisites: Postman Business Central OnCloud or OnPremise References: Writing tests | Postman Learning Center Announcing Postman for the Web, Now in Open Beta | Postman Blog Configuration: Post Request – So first we are going to be creating a record in the Customer Table with the following fields. One of the common things to be testing with Custom APIs is to verify whether the request is being created successfully (1) and what we are sending and what is being stored in the record are the same(2). As we are using Javascript, the response is stored in the jsonData variable and we can access any of the fields of the response as a property on the jsonData variable.  As the rest of our automated tests are doing to be performed on this same record, we need to store the Identifier for this record inside some variable which exists outside the scope of this request, here we are using a variable with the Collection scope. If you want to use the same variable outside of this collection, you can also define Global variables.  GET Request – In a simple GET request, the only thing we are concerned with here, is whether the request is executed successfully or not. For this we are simply going to be checking the Status Code. PUT Request – In a PUT request, we are going to be modifying the record that we previously created, here I’m going to update the name of the record. A common test-case for PUT requests would be to ensure that (a) the request is completed successfully and (b) what is being sent in the request is what is updated on the record and is available in the response. DELETE Request – In a simple DELETE request, the only thing we are concerned with is whether the requested is executed successfully and here we will be simply checking the Status Code returned. Once all the Automated Tests are written, you can either execute them from the Collection Level or from a folder level. Here we will be executing our tests from the folder level.  We can also define the Run Order for the requests.  Once the Tests have run, we can get a summary of the results as well as detailed version of the results.  Conclusion: Thus we saw how to use Automated Testing in POSTMAN to reduce re-work and increase efficiency while testing. A bonus tip – you can now use POSTMAN Web Version to create requests instead of download the POSTMAN app and the entire blog above was written using the Web App of POSTMAN. Do note that not everything that can be done on the Windows App can be done on the Web App. Happy Coding!

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

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.

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.

Introduction: One of the scenarios where you want the Person A approval request should be approved by Person B and Person B approval request should be approved by Person A. How to achieve this goal: Go to Workflows page I want to create a Purchase Order Approval Workflow from Templates. Go to New-> New Workflow from Template Then select the Purchase Order Approval Workflow from Workflow Templates Click on Add record restriction in the Response field Select the Create approval request option from the Response tab and then set the values Approve Type to be Approver and Approver Limit Type Direct Approver which means whoever is approver the request will go that user only. And then enable the workflow. Then now go to Approval User Setup where we are going to assign which user’s approval request will be sent to which user. Now I will assign my approval request should be sent to the manager and the manager approval request should be sent to me. Now let’s test it  go to Purchase order I am currently in my account and send the approval request from Purchase Order Now my manager will get the request which I have sent. The manager will sign in on his account and then go to the Request to Approve page and approve the request which I have sent. And then once the request is approved by my Manager I will get the status as approved in Purchase order-> Orders-> Approval Let’s try vice versa as well repeat the same steps for the manager as well Now I will be able to see the request from the Manager in the Request to Approve Page Conclusion: Thus we saw how we can set the request approval to be send one on one in Business central Thank you very much for reading my work. Hope you enjoyed the article!

Introduction: While doing some customization testing, which revolved around using different dates, I realized that once the date is switched back to the correct date, I was unable to connect to Business Central. I restarted the server instance, IIS, SQL Server services to no avail. Prerequisite: Business Central On-Premise setup with Web Server and SSL. References: https://serverfault.com/questions/217343/date-header-returned-by-iis7-is-wrong https://support.microsoft.com/en-us/topic/using-net-stop-and-net-start-commands-to-force-iis-services-to-re-read-the-registry-c6fe0d0b-9893-36d0-cc3c-47d03f9ccdde Verification: Logging into Business Central gave no errors, there were no errors in the Event Viewer that explicitly mention that it is a Date related issue. The way I stumbled across it being a date related issue is that in the Response that the Business Central server sent to the Login Request, was carrying the wrong date in it. When I switched the System Date back to the date mentioned in the Response headers, everything seemed to be working again. Solution: This issue is caused because when the system date is changed, the same is changed in IIS but when you change it back IIS does not refresh it and we have to manually reset it. Restarting it does not work, trust me, I tried. One way to do this is to execute the following commands on the Server: net http stop net http start These commands took a lot of time so be sure to have available down time before you run them. The other way, which is much simpler in my opinion, is to simply restart the Server. This stops all the services and restarts them which forces the IIS to reset as well. Conclusion: Thus in this blog, we saw how to resolve the issue of being unable to login after changing Server Date in Business Central. Hope this helps!

Introduction: Tags are small pieces of Information that we can display on the POS. This information may be a field from a table or just some text. If we are using a field from some table, it is necessary that, the table can be referenced using only the fields available in the current “POS Transaction” record. There are multiple types of Tags available like: System :- These tags display system information. Transaction :- These Tags display information regarding the current Transaction. Session:- These Tags display information regarding the current Session. References: https://help.lscentral.lsretail.com/Content/LS%20Retail/POS/Data/Tags.htm Prerequisite: Microsoft Dynamics 365 Business Central LS Central Demonstration: In most cases, we are going to use “Transaction” type Tags so let take an example. In this example, we are going to create a Tag which will display the manager of the Store. To create a Tag: Search for POS Tag in BC Create a new POS Tag, by convention the naming is <#TagName> so we are going to follow the same. Since the data we need is from the “Store” table we set the “Store” table’s ID in the “Table No.” field  and as we need the “Manager Name” from the “Store” record, we set the “Field No.” accordingly. In the “POS Trans. Key Field” we specify which field will be used to reference the table mentioned in the “Table No.” field which, in our case, is Store. This list of fields is from the “POS Transaction” table. In the “Expression” we can specify how the data should be presented, %1 is substituted for the data. On the POS, we can use this Tag in the “Description” field of any and all Menu Lines, for example, we can use this as the name of a button, thus the button will change depending on which Store it is being used on.  In this example, I am going to set it on “Manager” button on POS. Right Click on the “Manager” button and click on “Button Properties.“ Click on the three dots and choose the “Tag” that we just created and click on OK. Click on OK again so that the “Button Properties” page closes. The button now shows the “Manager Name” field of the Store, in the expression that we provided. Conclusion: Thus, we saw how to configure and use “Tags” in POS, in LS Central. Thanks for reading!

Introduction: There must be a requirement from client where they want to send different documents using different email accounts.It is possible using Email setup. Steps to achieve the goal: Go to Set up Email  -> Click on Next Business Central gives you an option to choose the account type. I am going to use Microsoft 365 account Give Account name and assign the email address from which you need to send the documents. Don’t turn the default button as it will set this account as default and all documents will be shared from this new account which you added and then click on finish. Go to the email accounts page you will be able to see two accounts one account which will be the default one and another account which I created then go to Email Scenarios Assign the Email scenarios to stated which accounts to be used for sending specific documents. I just want the Sales Invoice to be sent from the new account which I added. Click on Ok. You can assign any scenario you want as well you can remove scenarios Go to Feature management to allow all the users to use this feature And then go to Sales invoice -> click on Print/Send action -> A screen appears with from details and to details and then click on send email. Conclusion: Thus we saw how we can use multiple email accounts to send the specific documents. Thank you very much for reading my work. Hope you enjoyed the article!

Introduction: POS Data Tables are used to display data from any table in POS. The default POS Screen that we see where we enter our items for sale also consists of a Data Table. Data Tables are also used with Lookups, Record Zooms and Data Grids. In this blog, we are going to create our own POS Data Table based on the Customer Table. References: https://help.lscentral.lsretail.com/Content/LS%20Retail/POS/Data/Data%20Tables.htm https://help.lscentral.lsretail.com/Content/Fields/T_99001565_11.htm https://help.lscentral.lsretail.com/Content/Fields/T_99001565_14.htm Pre-requisites: Microsoft Dynamics 365 Business Central LS Central Demonstration: The most important fields in the General Tab are: Field Description Data Table ID Specify a unique ID for this Data Table. Table No Specify the ID of the Table, whose data this Data Table will be showing on POS. Table Columns Specifies the columns that will be visible in the Data Table. Table Rows Specifies how many rows should be visible by default, if there are more you can simply scroll. Key Value Fields Specifies the key fields of the select table. Start Position Defines which record should be selected when this Data Table is opened. Selection Mode This is useful when you are using your Data Table in a lookup, the options available are “MultiSelect“, “SelectOne” or “NoSelect.” Default Search Type Specifies the search type, the options available are: “Any Part“, “Beginning” or “Whole.“ Default Search Command You can specify different searching commands like Filter, Search or Find. Distribution Location Specifies where the POS Data Table should get the data from.Do note that Web Service configuration should be done for this to work and if the record you selected does not exist on your local system, you may get an error. For Data Table Columns: In this tab, we specify the columns we want in our Data Table and the properties of those columns. Field Description Column No. Specifies the order of the Columns Field No. Specifies the Field No. to be used from the Table for the column. Key No. Specify a value in this field if you want to search using this field. Fixed Filter Specify a value in this field for filtering the table. Preferred Width Specify the preferred width of the column. Default Column Setting this value to true, makes the current column be selected by default when opening the data table. Sort Fixed Setting this value to true, disables changing the sort order for that column. Special Field Type  It is used to identify that the current column is a special type of field, there are very limited options on this field and we usually do not need to use them. Read more at Reference #3. Editable Makes the field modifiable when we use Record Zoom Controls. Validate Input Validates the input when we use Record Zoom Controls. Filter Tags Used to set a filter using “POS Tags” on that column. POS Command Code Used to specify a Command which is to be executed when user clicks on this column. A good example of this is the “Quantity” column of main POS Screen which executes the “Change Quantity” command when clicked on it. Conclusion: Thus, we saw how to create our own Data Table and the different properties associated with a Data Table. Thanks for reading!