D365 Business Central, Power Automate

Business Central Batch post and e-mail with Power Automate – no code

Batch posting has been in the product for some time but I am not seeing a clear way, happy to be wrong, on batch post and e-mail. Here are my options (below) as a user conducting the posting. Yes, I have post via the job queue as well but from what I’ve tested this isn’t sending my e-mail for me. Even the print option breeds no results here. Thought it would at least use the “Document Sending Profile” on the customer record.

Even when you use the “Post Batch” you get nothing about e-mailing? 😬 Not forgetting the workflows in BC have no option for “Post & Send” it’s just “Post”. Usually these gaps would need filling with a code modification but not in this blog.

Where there is a will there is a way and my idea here is to use Power Automate to do the heavy lifting. On this occasion I will use a manual trigger but if this was a production ready scenario I would use a scheduled type flow.

The connector for BC in Power Automate is fairly small but I’m sure it will get better over time. There is a slight restriction though as the action of posting and emailing exists but it’s on a singular level like it is in the regular UI. So the first thing I need to do is fire in some data I can use in Power Automate from BC. I will of course need the GUID ID reference to the sales invoice as that’s what the BC Power Automate connector likes. The page that fits the bill here is available as a web service already. I will use the top one in the list 2811. This page is a mixture of open and posted sales invoices so some filtering is needed:

Example of the payload from this page:

Adding a filter to the ODATA query so I only post invoices that are ready to be posted. In the case of this page the “status” values are different to regular BC. In my case I have a choice between draft aka “Open” or open aka “Released”. So I have added ?$filter=status%20eq%20%27Draft%27%20and%20totalAmountIncludingTax%20gt%200 to the end of the web service URL I got from BC. Reason being the feature in the Power Automate BC connector restricts me to draft only and I don’t want to post invoices with a 0 value. Will log something on the Power Automate forum about the connector wanting “Open” invoices rather than “Released”. Backwards logic otherwise, what if I’m using approvals for instance. I think this is possibly wrong so I have posted this to find out more: https://powerusers.microsoft.com/t5/Connecting-To-Data/Is-the-Business-Central-Post-amp-Send-Invoice-action-correct/m-p/637081#M9492

Anyway….

Our flow starts to take shape like this. Check out my last blog for a more detailed account on the parse JSON part (https://joshanglesea.wordpress.com/2020/07/22/power-automate-purchase-order-alerts-to-vendor/)

Once we add the “id” from the parse JSON step you will get an “Apply to each” wrap around the chosen BC action which is exactly what we want (automatically). Remember our goal Batch post and e-mail invoices – so we better placed than standard.

In my case a small batch of invoices have been handled and emails dished out accordingly. I added an extra step for updating the posting date as well. Just so it takes something useful from the existing “Batch Posting” feature 👍

Power Automate

Business Central Power Automate purchase order alerts to vendor

Recently had a requirement where alerts to a vendor need sending for orders expected in the next two weeks. A reminder is needed as the lead times for the goods are so long.

The goal is therefore, have an email sent to a vendors email address for purchase order lines in the next two weeks from today’s date.

To achieve this Power Automate or Logic Apps are the most appropriate choices. For this blog I have chosen Power Automate.

Given that I will need line data and I want to minimise the need to make multiple HTTP calls so some small DEV BC side will help. I have produced a query object so that I have all the data I require for all the areas I want data from (link to my code is at the end). I’ve chosen header level here for the “Expected Receipt Date” but you could do it for the line level if needed:

Ensure the query is published as a web service and check you have output by using the web link or from an API test tool like Postman:

To get the exact data we want for the scenario some ODATA query logic is needed. Add the following to the end of the web service URL. Replace <Your Date> with the date you want to filter by. The format must be like this: 2020-07-21T00:00:00Z:

?$filter=Expected_Receipt_Date ge (<Your Date>) and Expected_Receipt_Date le (<Your Date>) and Outstanding_Quantity gt 0

The date values will be replaced with calculated fields in the flow which will be a scheduled type flow so that is our starting point along with the ability to create variables for the date/time values which are then used in our ODATA query above:

Use the HTTP connector and call the web service with a GET command and use the current time and future time variables.

The HTTP will produce JSON which we saw earlier, from the web service call, and to use the data from this we need to use the PARSE JSON feature and we’ll be able to then select the content for use in subsequent steps like sending the email. To generate the schema just paste in an example from calling the web service. Works nicely by using an API test tool like Postman as you get it formatted in a nicer structure.

Once the JSON is read by the PARSE JSON step you are able to create a “Apply to each” step which will iterate through each of the received rows of data until it has read them all. Whilst that is happening we can initiate further actions like our email:

Each reference comes from the PARSE JSON and you can use format functions on certain data like I have for the date. The result of this flow is an email much like this one:

Code: https://github.com/JAng13sea/Blogs/tree/master/Purchase_Query

D365 Business Central

Business Central Demand Forecast

Have you ever looked at the demand forecast in D365 BC and thought that is missing features which actually make it usable! I mean look at it…but actually look at it:

Yes I can toggle the matrix view to alter the dates and change to component items instead of sales but if I want to forecast surely I need to do it for items that actually need manufacturing first! After all that is the premise with it. You populate it and then it gets used as part of MRP and MPS. How can we change this situation so the page is actually friendly and a user can apply sensible filters? Initial thoughts would be just personalise it, oh wait you don’t get any fields to choose…

Well the answer lies in the make up of the page object. Which as it turns out is the Item table:

So our goal here is Add sensible fields to the page that can be used for better filtering when devising a demand forecast. This might seem overly simple as an idea but the value comes from the fact the item table, especially for a manufacturer, can become very large indeed. You will have items that get blocked, you will get items that have been replaced by others or are now defective. The list in it’s current state over time will become too difficult to work with.

The method to achieve this goal is simple. Create a page extension to page 9245 and throw in the necessary fields the user is most likely to plan with.

Other fields can be added of course but straight away a user has something way more friendly:

For more information on demand forecasting check this out: https://docs.microsoft.com/en-gb/dynamics365/business-central/production-how-to-create-a-forecast

Code available here: https://github.com/JAng13sea/Blogs/tree/master/Demand%20Forecast

D365 Business Central

Business Central Gen. Jrnl. Imports with Data Exchange Definitions

Have you seen this button on the general journal page and thought that’s useful?

Some of you might not have seen it though as the button only appears if you complete some setup in the General Ledger Setup page:

The above field shows a list of Data Exchange Definitions for the type of “Payroll Import”. So it is fit for purpose but only usable for payroll – and more importantly just one import file structure. For demos I have often mocked up a Data Exchange Definition as a payroll import type and just passed over a CSV file. This falls into my one of many ways a journal can have external data added to it. This is fine for one off demos sessions but how can this idea be taken seriously in a project/production scenario? The answer lies in how is the current “Payroll Import” button working and can we change it for our situation? My end goal here would be to have the user pick from a range of different data exchange definitions which work for different CSV files. In the past customers may of had bespoke import routines passing data through the excel buffer. If they can compromise on having the file converted to CSV this could be a worthwhile solution!

Over in the base app the “Payroll Import” action button looks like this:

So it is only ever looking at that setup page to know which data exchange definition to use. It also has it’s own codeunit to run the process. So the component parts are small and we can adjust them with ease for our end goal.

Very simply a page extension is needed for the general journal and you can go with something like below to add the type of page action we want. In my case I have opted to use the “Generic Import” type on the data exchange definition – which I have set as a global variable on the page.

Codeunit wise I have done a complete copy of the base app and then renamed the function names. Very easy indeed. The process itself works fine so no need to change anything it is more about what you offer the user when they make that button selection.

The end result is a dynamic journal import selection. The user can now maintain and update a data exchange definition or add new one’s as new journal import requirements come along! 👍😁

Don’t know much about data exchange definitions? Check this out: https://docs.microsoft.com/en-gb/dynamics365/business-central/across-how-to-set-up-data-exchange-definitions

Code available here: https://github.com/JAng13sea/DED-Jrnl-Import