Our world has been thrown into chaos by the COVID-19 pandemic, as lives are being lost, hospitals become overwhelmed and surging demand causes household items like toilet paper and cleaning supplies to sell out.

For businesses which need to maintain operations during this time of crisis, adapting your material planning and supply chain systems to this ever-changing environment is a monumental challenge.

Deep Analysis Leads to Mass Updates

I recall an example from about 10 years ago, when a natural disaster halfway around the world severely impacted a small but critical supplier to the business I was working for at the time. We needed to adjust lead times on specific components, based on information that wasn’t present in our ERP system, because it was only relevant to our supplier’s ability to manufacture them. Nonetheless, we had hundreds of specific items that required close management.

Within Infor M3, there is limited ability to perform mass updates using the CRS800 program, but in situations like these, your supply chain experts are likely to work with spreadsheets in Excel at the item level, and want to adjust planning parameters based on their analysis. Suppliers may advise them that certain categories of goods are still available, while the lead time on others needs to be extended, for example.

Excel + M3 APIs to the Rescue!

That’s where M3 APIs come into play. I’ve written previously about calling M3 APIs from Excel spreadsheets, and that technique of performing mass updates comes in handy during times like these. Using VBA (Visual Basic for Applications), you can create routines that take each line of a spreadsheet and perform an API update in M3 just as if a user was manually keying in the information, respecting all the business logic and security that you have configured.

In this way, you can combine the expertise of your supply chain analysts with the power of M3 to update and communicate your integrated material plan internally and externally. Given the changing nature of this crisis from week to week, those analyses and plans will require multiple major updates along the way.

So take a look at my introduction to calling M3 APIs from within Excel, and if you need assistance with getting started, feel free to ask me for help. These tools can be developed against most functions in M3, but if there isn’t an API available for your specific situation, there are more arcane options available. But we’ll save that for another post…

The post Coronavirus 2020: Managing a Supply Chain Crisis in Infor M3 appeared first on Ready ERP Solutions.

Then, the challenge becomes how to get that data back into M3.

Sure, there is limited ability to perform mass updates in CRS800, but often users come up with a process where they get information out of M3, manipulate it however they like in Excel, and then run into a roadblock trying to get the data back into the system. Nobody wants to manually key in hundreds or even thousands of records, but waiting for IT to develop a robust interface can take months.

In my personal experience, I have tackled this issue at pretty much every ERP installation I’ve worked with. It could be as simple as “we need to change the buyer assigned to this list of suppliers” to “we need to add X weeks to the lead times on parts from Supplier Y for a few months, then change it back later on”.

So what to do?

Excel VBA + Infor M3 API to the rescue

Excel is easily extendable by using VBA (Visual Basic for Applications) code behind the scenes, creating macros that call M3 APIs to get data out of the system or load it back in. One can even perform many common business process tasks by stringing multiple API calls together.

The benefit there is that you are using ERP functions to process your data just as if a user was working within the system, so all of your business logic is still being respected. You aren’t simply slamming records into a database, you are following established procedures, but with the ability to do so in an automated way.

So how to connect Excel to M3? In the past, you would download the M3 API Toolkit from Infor, and install software on each computer which would connect to M3, which was a hassle. Installing .dll files and registering them within Windows could be a real pain if not done correctly. And especially for newer, multi-tenant CloudSuite implementations of M3, the old toolkit really isn’t an option anyway since you’re not able to create socket connections to the M3 server.

Using REST API With Infor M3

Thankfully, we can use REST APIs to make those connections instead. With a REST API call, the communication functions much like your web browser following a link – you sent a string to a server in a URL, and get back information in return.

There is no additional software to install, and when the user makes their first API call they will be prompted to provide a user ID and password, just as if they were logging into M3. For a primer on calling M3 APIs using REST, check out this blog post over at M3 Ideas.

The idea here is that within Excel you will create a URL that is used to make the call to M3. The URL is a web address just like you see at the top of your browser, but it will refer to the M3 environment and API program you are accessing, and include any parameters you need to pass.

For example, if you want to get the item master information for item number ABC123, your URL might look like this:

https://[server]:[port]/m3api-rest/execute/MMS200MI/Get?ITNO=ABC123

The [server]:[port] portion will relate to your individual implementation (each environment will have its own values there), and you can see where the API program (MMS200MI) and transaction (Get) fit into the mix. From there, you append parameters to the end of the URL, such as “&CONO=123” for adding Company Number = 123 as parameter.

Calling REST API from Excel VBA

OK, so we know we have to create a REST API call against M3, but how do we do that from Excel using VBA? First off, you’ll want to make sure you add the Microsoft XML v6.0 library to your VBA references, like so. This gives you the necessary objects, methods and properties to make the REST API call and deal with the XML you will get back from M3:

For an example of how the VBA code looks when making the API call, take a look at the following. At first we set up the objects for the API call (objRequest) and the response we receive back from M3 (xdoc), and then make the call in the line that begins with “.Open”. The variable strURL is a string with the URL defined as we’ve noted above.

Set objRequest = CreateObject("MSXML2.XMLHTTP")
Set xdoc = CreateObject("MSXML2.DOMDocument")
xdoc.async = False
xdoc.validateOnParse = False
blnAsync = True 

With objRequest
     .Open "GET", strURL, blnAsync
     .setRequestHeader "Content-Type", "application/json"
     .setRequestHeader "DateTime", Now
     .setRequestHeader "Cache-control", "no-cache, no-store"
     .setRequestHeader "pragma", "no-cache"
     .setRequestHeader "If-Modified-Since", "Sat, 1 Jan 2000 00:00:00 GMT"
     .Send
     
     While objRequest.readyState <> 4
         DoEvents
     Wend
     xdoc.LoadXML (.ResponseText)
 End With

What you can then work with in Excel VBA is the xdoc object, which contains the XML response from M3.

That’s enough to get you started, I will follow up with more posts covering how to deal with the output received from M3, along with a few tips and tricks I’ve learned along the way while creating these Excel-based tools that interact with M3.

Did you enjoy this post? Go ahead and connect with me on LinkedIn or email me (dirkhoag at gmail), making sure to include a message so I know how you found me! If you could use some assistance with Infor M3 (functional or technical), I am available for remote, part-time consulting. Just send a message for further details!

The post Calling Infor M3 APIs from Excel appeared first on Ready ERP Solutions.

There are some nice blog posts out there which cover the mechanics of creating your own custom lists (such as this one here), but there is an advanced aspect of custom list building which I would like to share with you today.

The basic idea with custom lists is that you start with a particular table (for example, the item master MITMAS) and link out to other Related Tables (such as the item/warehouse record, MITBAL).

Let’s say for the purposes of this discussion that we want to show the on-hand balances available in warehouses AAA, BBB and CCC. We will call this browser ITEM_BAL in CMS010. Normally, that means you would start with MITMAS, and define MITBAL as a related table. So that means you end up a record for each combination of MITMAS and MITBAL, like so:

This is OK, but what if we could have just one line per item, and show the warehouse balances in different columns instead, like the following?

That’s where we get a little bit fancy with our Related Tables.

Linking to the same Related Table multiple times

In order to get things down to one line per item, and a column for each warehouse, what we will do is start with our item master MITMAS, but then we will set up MITBAL as a related table three times, one for each warehouse we want to see.

The key here is that when defining the related tables in CMS011, you designate a different two-character prefix for each time you link into MITBAL, and also specify the unique warehouse which this link will reference. In this case, let’s use AA to link to warehouse AAA, BB to link to BBB, and CC to link to CCC:

Then on panel CMS011/F, where you define how the tables are linked together, you specify “AAA” as the value for MBWHLO, so you are only grabbing records from that warehouse:

And on CMS011/N, I will add the field STQT (on hand approved balance) to our field group. Note that when I add STQT, it shows up as AASTQT thanks to the prefix we designated on the way in. At this point, change the “Overriding name” field to AAA, so the column heading will show “AAA” for these values:

Now, go back and do the same for BBB and CCC. Once complete, if you pull up the related tables for our inquiry (ITEM_BAL), it should look like this:

Since we have our tables and fields all together, let’s create a View to set up our inquiry. Back in CMS010, use Related Options->View on our ITEM_BAL record, and create a new view called TEST:

Now if you go back to CMS010 and do Related Options->Simulate List, you can see our balances for the various warehouses listed side-by-side, as requested:

This is just one example of how to leverage the power of Related Tables to create a more robust view within M3 than one might normally consider possible. Stay tuned for more tips on building custom lists, and other areas of Infor M3.

Note: If you enjoyed this post and could use some help or assistance with Infor M3 (functional or technical), I am available for part-time after hours consulting. Please send a note through my Contact page or connect with me on LinkedIn for further details!

The post Custom Lists in Infor M3: Advanced Tips appeared first on Ready ERP Solutions.

“Thou Shalt Not Run External Reports Against The Production Database” – ReadyERPSolutions.com, Chapter 3 Verse 1

For those of you running M3 on-premise with SQL Server, creating your own mirrored database for reporting purposes is easier than you might think (sorry M3 Cloud users, you’ll have to sit this one out since you don’t get SQL access).

The benefits of setting up a replicated database for reporting purposes are important and straightforward: basically, you avoid the risk of queries slowing down your production database server, which won’t just annoy your users, but could also impact the completion of transactions by the business engine.

I’ve had one client in particular where users gave up on doing anything useful before 10:00 a.m., because overnight reports were still typically running into the morning, slowing down M3 to the point where users couldn’t perform even basic functions.

But let’s get right to the action and show how to set this up…

Setting Up A Mirrored M3 Reporting Database

Note: There’s a document on Infor Xtreme titled “M3 Business Engine and Microsoft SQL Server – Best Practices” which I’d highly recommend reviewing for your combination of M3 and SQL Server version. We worked from the M3 BE 15.1.x/SQL Server 2014 document published in July 2016.

The basic idea here is that we will use SQL Server’s Replication functions to maintain the reporting database. It all starts with a snapshot which is brought over to your reporting server, and after the snapshot is taken transactions are logged and passed over in near real-time (in our experience, almost always less than 5 seconds).

The M3 Production database will be considered a Publisher in SQL Server, while your reporting database is termed a Subscriber. In this example I will create a replica from our TST database to a reporting database called M3TSTRPT.

Step 1: Create the reporting database

This part is real easy – just go into the SQL Server where you want reporting to be performed (NOT YOUR M3 PRODUCTION DATABASE SERVER), and right-click on Databases to create a New Database. Name it however you like (I’m going with M3TSTRPT here) and hit OK.

Next, it is important that you set the collation of the reporting database to the same as it is for M3, i.e. Latin1_General_BIN2 in our case. Immediately after creating your database, go into the Properties for it, and look for collation under the Options section. You want to get this set correctly before we start the replication process.

Step 2: Set up the Publisher

Now we need to designate our M3 database as a Publisher. Log into the SQL Server where your M3 database resides, and expand the Replication section. Right-click on Local Publications in order to create a New Publication. This will launch the New Publication Wizard, so let’s walk through those panels together.

1. First you are asked to designate a Distributor, which can be a server in the middle between the Publisher and Subscriber, which stores and transmits information. In our case, we allowed our M3 database to act as its own Distributor (the default option).
2. Do you want the SQL Server Agent service to start automatically? Yes, yes you do.
3. Next you specify the folder where the snapshot should be placed for the Subscriber to pick up. Since the Subscriber is on another server, this needs to be a network shared folder.
4. Now we select the database which will publish. Typically this will be M3FDBPRD, but since this example uses a TST environment, I am using M3FDBTST.
5. Publication Type: this is a biggie! Here we will select “Transactional Publication”, which operates as described earlier. A snapshot of the database is sent over to start with, and following that, incremental updates are passed along as they occur.
6. Articles: here you can select specific Tables and Views to bring over to your reporting database. I highly recommend you choose your tables based on reporting requirements, rather than just click the checkbox for everything, which could potentially cause performance issues. After all, you don’t need data from the various working tables in M3 such as FCR040. If you don’t get all the tables you need in this step, don’t worry! It is easy to add new ones later on (maybe I’ll cover that process in another article here). For this example I’m just going to bring over the user table CMNUSR.
7. There is a step where you can filter which rows are brought over in the replication process. If, for example, you had multiple companies in M3 and wanted to set up different reporting databases for each one, you could accomplish that by filtering the records you bring across by CONO. Typically, however, you’ll skip this step.
8. Next up, would you like to create a snapshot immediately, or schedule it for a later time? The main reason to schedule it later is if you plan to make changes to the snapshot before flipping the switch for replication (for example, you are waiting to get the final list of Articles you want to import in Step 6).
9. Agent Security: The SQL Server Agent will run all these processes, so you need to provide it with a user ID/password that has appropriate authority. In my example, I use a Windows account that has admin authority to the servers and folders in question, and for the “Connection to Publisher” I choose “Impersonate the process account.”
10. Next, you have a choice as to whether to create the Publication immediately (usually that’s a yes, unless you don’t have your final list of Articles yet), and whether or not to create a script that follows those same steps (in case you plan on doing this a lot, which I doubt).
11. Lastly, give this Publication a name! I’m calling this ReplDemo.

Assuming you told SQL Server to create the Publication immediately in Step 10, you’ll see a pop-up that shows the progress through the various steps of creating the publication and the initial snapshot.

Step 3: Subscribe

Now that we have a Publisher established, we need to tell our reporting database to become a Subscriber. Switch over your SQL Server connection to your reporting database, expand the Replication tab and use a right-click to create a New Subscription.

Once again, you’re led into a Wizard, so here we go:

1. Select the Publisher. From the drop-down list, select “Find a SQL Server Publisher”, which then prompts you to log into your M3 database server and browse for the Publication you just set up.
2. For the Distribution Agent Location, select the bottom option “Run each agent at its Subscriber”. This reduces the workload on your M3 database server, which is the whole point of this exercise, right?
3. Next, select which database will get updated via this Subscription… in this case that’s M3TSTRPT (the one we created in Step One).
4. Next, set the security access for the connections for both the Subscriber and Distributor processes. Much like the earlier bit, I use a Windows account with admin access, and for the Distributor connection I tell it to impersonate the process account.
5. You can schedule how often you want the Subscriber to run. Select “Run continuously” for those near real-time updates from M3.
6. Next, do you want to launch this immediately, or just create a script and run it later?
7. Also, do you want to actually create the Subscriber now, and/or create a script to use later?
8. Click Finish and off you go!

A pop-up will show the progress through the steps of creating the Subscription and starting the Snapshot Agent.

Once this is complete, we have one last change to make. On your reporting server, under Replication/Local Subscriptions, pull up the Properties for your new Subscription. Look for the Snapshot section, which probably reads “Default”. Use the drop-down to change that to Alternate Location, and specify the shared folder in the box immediately below (\\share\folder).

Step 4: Launch the Replication

At this point, if you open up your reporting database you shouldn’t see any File Tables in there yet. So let’s kick off the process!

Go over to your M3 database, browse under Replication/Local Publications, and use a right-click to Reinitialize. That should launch the creation of a new snapshot, and start the replication process running continuously.

Depending on how many tables you are bringing over, and their size, you should begin to see tables populate in your reporting database.

As a quick test I’ll pull up my own user ID record to see how it looks in the reporting database, and then go into M3 and make a change (such as inserting “TEST” at the beginning of my name). Within a few seconds of hitting Enter in M3, I refresh the query on my reporting database and sure enough, the update comes across!

Note: If you don’t see data showing up, check the Job Activity Monitor on both servers to see if the job ran into a problem. Most likely you have an issue with the security access, or perhaps the folder location where the snapshot is being dropped off and picked up.

Next Up: Monitoring Status, Adding Tables, & More

This should be enough to get you started with the process of creating a reporting database in SQL Server for M3. I’ll follow up with more on how we can monitor the status of the replication process, make changes as needed (typically adding more tables), and more.

I highly recommend you try this out first against your test environment to make sure you get all the steps right before implementing against PRD.

Happy Reporting!

Note: If you enjoyed this post and could use some help or assistance with Infor M3 (functional or technical), I am available for part-time after hours consulting. Please send a note through my Contact page or connect with me on LinkedIn for further details!

The post Building a Mirrored Database for M3 Reporting appeared first on Ready ERP Solutions.

Sample SQL from a report I once wrote to help with 1099 processing

One of the more amusing points that comes up when talking about the features of Infor M3 is the number of reports that come with the system and are available “out of the box”.

In my experience of many years and many M3 implementations I can say that very few customers use more than a handful of those “canned” reports, and without exception every M3 customer ends up building their own suite of reports, for both daily operational use and management oversight.

Those basic M3 reports typically go through StreamServe and allow users to either receive a PDF via email or a paper printout, both formats which aren’t easy to work with when analyzing large amounts of data. If you have hundreds or even thousands of records to work with, spreadsheets remain a vital tool in most environments.

Once the decision has been made to create a reporting suite against Infor M3, there are some important considerations to keep in mind, however! Be careful to follow these Commandments and save yourself a lot of heartache…

1. Thou Shalt Not Run External Reports Against The Production Database

This is a big big big big “NO”, and should mark the fundamental technical requirement of your external M3 reporting solution. The M3 Grid manages the interaction between the Business Engine and the database, and if you throw database queries from external report users into the mix, you run the risk of seriously reducing system performance for your users.

NOTE: This recommendation does not apply to reporting options within the M3 solution, such as a well-configured List Panel or the use of Ad Hoc Reports, which are managed by the M3 Grid and cooperate nicely with other processes.

I recall one client who regularly experienced slow system performance each morning, as various Crystal Reports ran to completion while users went for an extra cup of coffee or found other things to do rather than try to work within M3. It was one of those problems that started out as a minor annoyance but became worse over time.

The solution? We used BPW (Business Performance Warehouse) to define a datamart that copied selected tables over from M3 each night, and pointed the reports to run off the datamart instead. There are a number of other options you can use to create a parallel reporting database as well, particularly if you are running on SQL Server.

Not only did this allow users to be productive right from the start each morning in M3, but I imagine they saved a bit of coffee expense, too.

2. Honor Thy Users’ Requests For Spreadsheets

One of the big frustrations many M3 users have is the lack of an easy way to get reports in spreadsheet form from the system. Yes, you can dump the contents of a panel into Excel, and there is a cumbersome process that can turn StreamServe output into a spreadsheet, but these are far from ideal.

The reality is that for many situations, users need to be able to work with hundreds or even thousands of records at a time, and spreadsheets facilitate that kind of analysis far better than a PDF or other reporting format.

A tool like Crystal Reports or Microsoft’s SQL Server Reporting Services (SSRS) provide the flexibility for users to get their information in the format that fits them best, whether a PDF or spreadsheet.

3. Thou Shalt Write Proper SQL For Crystal Reports

One issue for you Crystal Reports users is to make sure that report writers understand the M3 database structure and write SQL statements to retrieve only the appropriate information for a given report, and no more!

If you use Crystal’s Select Wizard to pick which tables you need, and then apply filters to determine which records will show on a report, Crystal Reports will try to load those tables in their entirety and then filter down to show only the required lines. This is tremendously inefficient, both in terms of client performance and the amount of network traffic needed to run a particular report.

For example, if you have a daily Open Orders report for your purchasing department to monitor, using the basic Select Wizard in Crystal will cause entire purchase order tables (as well as any other tables you are linking to) to be brought over to the machine running the report, and then that machine will crank through the data and figure out which PO’s are open and which are not.

Instead, report writers should craft a proper SQL statement that retrieves only the data that is needed. This allows the database server to do the work that database servers are designed to do – grab the specific records and fields you need, and then only transmit that information across your network to the Crystal Reports application, which can then do the work of formatting things nicely and presenting the report.

4. Create SQL Views To Define Common Business Terms

Quite often you may need to develop a set of reports that offer different slices and dices over the same data, such as Open Order reports that may be broken out by product line, vendor, facility, etc. General Ledger data is another area where the same records and fields may need to be presented in a variety of ways.

In those cases, defining a View in your SQL reporting database can provide a shortcut for the development of most of those reports. That view can define standard record selection criteria and the fields needed across a family of reports, and be re-used in multiple queries. This reduces the time spent creating custom queries for each report, and avoids the risk of error when reinventing the wheel with every new report.

5. Custom M3 Reporting Is A Necessary Investment

An ERP system like Infor M3 doesn’t just serve as the mechanism that enforces your business rules, it also needs to grow and adapt as your business changes. Your reporting requirements will follow that change as well, so prepare yourself by making sure you have the necessary expertise to present whatever information your key business users need.

If you need assistance with reporting against Infor M3, head over to the Contact page and send a note! I can not only help with designing and implementing a custom reporting solution, but can coach up your technical staff so they can handle your reporting needs going forward.

The post The 5 Commandments of M3 Reporting appeared first on Ready ERP Solutions.

This user had produced a sales invoice with three simple lines, but for some reason StreamServe created a page for each line, rather than printing them together like usual.

What could be the cause of that? All I had done was taken the existing form (OIS199PF) that was used by another division, made a few adjustments for the text in the header and footer, and deployed it for the new division.

StreamServe Help Isn’t So Helpful At Times

After digging through the online StreamServe documentation,  I couldn’t come up with any obvious reasons for these mysterious page breaks. I checked topics like mirroring, page sizing, etc., to see if those might be the problem, but no luck.

I had a suspicion that it had to do with a new text box which I placed in the footer of the document, as that was the only new element in this form. But when looking at it in the PageOut tool, it certainly looked like it wasn’t going off the bottom of the page.

So what could it be?

That’s when I remembered that all of the output elements are placed within the document in two manners. First, we look at the PageOut layout and can visually place an element on a document – and that part looked OK.

But in addition, there’s that Process window at the left side of the PageOut program, which determines the logical structure of the output. When I clicked through the various Label elements to see where the various pieces of text showed up in the structure, I found my answer!

The logical structure for an invoice (OIS199PF) is that you have all your header information at the beginning (customer info, etc.) and then there are a couple blocks which can repeat themselves: OIS1990L (the line item information) and OIS199TL (text notes associated with each line).

What I found was that my new text box looked OK in the visual layout, but in terms of the logical structure it had been created within the OIS1990L block. That meant that each time an invoice line was being processed, StreamServe wanted to print that box at the bottom of the page, and thus we ended up with a new page for each line on the invoice.

A simple “cut & paste” from that section of the structure to the main block (see the pic at right, and the red text included) and things worked as expected.

So remember! It’s not just how elements are placed in the visual layout that matters, but where they appear in that Process view can have a huge impact on your StreamServe output. For those of you who don’t work in StreamServe on a regular basis, that is a very easy item to overlook.

Note: If you enjoyed this post and could use some StreamServe help or assistance with Infor M3 (functional or technical), I am available for part-time after hours consulting! Please send a note through my Contact page or connect with me on LinkedIn for further details!

The post StreamServe Help: The Mysterious Multi-Page Invoice appeared first on Ready ERP Solutions.

As if this wasn’t exciting enough (calm down, people!), stick around to the end for a key tip on how to make sure you can process hundreds of orders in a timely fashion, and avoid a common bottleneck that could leave your M3 system choking on large volumes of orders!

Infor M3 Customer Order API Overview

When customer orders are loaded into M3, they begin as “batch” customer orders, which can be seen in OIS275. They don’t actually hit the books as real orders (which impact sales statistics, material plans, etc.) until they go through a confirmation process that validates the data, at which point you will see them in OIS300, the Customer Order Toolbox.

Assuming you already have the data you need (i.e. proper customer numbers, item numbers, and more), there will be three API transactions you will call in sequence:

1. OIS100MI.AddBatchHead
2. OIS100MI.AddBatchLine
3. OIS100MI.Confirm

Whatever program you are using to load your customer orders, first you will set up some looping logic to follow these steps. Let’s say you have a file like the following, with multiple orders, each of which may or may not have multiple lines:

order1     line1
order1     line2
order2     line1
order3     line1
order3     line2

The looping logic you will need to read through this file and load M3 will proceed as follows:

1. Call AddBatchHead each time you encounter a new order number (you will receive back a Temporary Customer Order number)
2. Call AddBatchLine for each line (refer to the Temporary Customer Order number from Step 1 so the line gets added to the correct order)
3. If the next line marks the end of the file or begins a new order, then call Confirm to submit this Temporary Customer Order for validation

So far, this should all be fairly straightforward, but there is an important design consideration that comes along when we get to that Confirm transaction.

M3 Batch Customer Order Confirmation – Interactive or Batch?

When it comes to confirming the Temporary Customer Order, you have a choice between Interactive or Batch processing.

With Interactive Confirmation, M3 will process your order immediately upon receiving your API call, which means you will likely have to wait several seconds to receive the response message. That return transaction will come back with either “OK” followed by your new Customer Order Number, or “NOK” with a status code that is associated with various issues that come up during validation (error in the header, error in the lines, etc.). If you are calling these APIs from another system where you need that response and are dealing with low transaction volumes this may be the appropriate choice.

In Batch Confirmation, M3 will immediately come back with an “OK” response (assuming you have passed a valid Temporary Customer Order number), and the validation process will take place in a separate batch job within M3. Your API process will not receive back the ultimate Customer Order Number that results from the confirmation, so in this case you will need a separate process to follow up and make sure orders aren’t getting stuck in OIS275 due to validation issues. On the upside, upon receiving back that “OK” you can immediately move on to your next order, so this works better for high-volume situations where you need to load multiple orders in sequence.

How To Speed Up Batch Confirmation For Multiple Orders

During one project we had a requirement to get hundreds of customer orders (with hundreds of lines each) processed all the way through to the point where picking lists being released to the warehouse within a narrow time frame. When we fired up our API process the batch orders were pushed into M3 in a timely fashion, but the confirmation process became the bottleneck.

As we refreshed the view in OIS300 to see how the orders were proceeding through the system, we saw that only 10 orders were being processed at a time (each taking as long as a minute to go through the process of confirmation, allocation, and picking list release). We knew that would never meet the business requirement.

That’s when we took a look at the batch processing setup within M3.

By default, the confirmation jobs will get filed in the QBATCH job queue, with one batch job per Confirm transaction. Typically M3 installations have the QBATCH queue set to allow 10 active jobs at a time, so that is why we saw only 10 orders being validated at once.

In MNS300, however, you can adjust those settings for job queues. We tried bumping it up to 15, and sure enough, overall processing time improved. We then tried 20, and 25, and by that time we were easily beating the business requirement, achieving a 90% reduction in processing time as compared to the client’s existing legacy system!

At another client, I created an Excel-based tool to take data from one system and create Customer Orders in M3, replacing a manual process that had two people keying information all day long into a macro-based function that took one person less than 15 minutes to load, process and confirm the resulting data (which was also much more accurate due to the elimination of manual entry).

This adjustment of the “Max active jobs” setting on the batch job queue allows M3 to create additional separate threads to process these customer orders, which has a tremendous effect on performance when you are working with high-volume situations. Finding the most appropriate number of Max Active Jobs for your implementation could be an exercise in trial & error, like we did in the example above, but you should also consult your system administrator or M3 technical consultant. Obviously if you try to spin up hundreds of threads at once that would present its own complications.

Key Questions To Ask Yourself

If you are planning an Infor M3 customer order API interface, asking yourself these questions can help inform the choices you make in creating your API calls:

• What is the anticipated volume of orders being submitted in a given job? Will this interface process many orders in each blast (batch), or individual orders several times throughout the day (interactive)?
• To what extent can error correction be done by the user or system that is submitting the data? Would providing them with error messages coming back from M3 and allowing them to resubmit be helpful (interactive), or should those be managed on the M3 side (batch)?
• Does your system already have many batch jobs typically running during the day, and would it make sense for a batch load of customer orders to run behind the scenes at a lower priority? If so, consider creating a new job queue and assigning the batch order confirmation job to it in MNS300/MNS310 with its own “Max Active Jobs” setting and priority value, so the orders can load without negatively impacting other users or processes.

Do you have any questions about the Infor M3 customer order API process, or dealing with APIs in general? Feel free to sound off in the comments below.

Note: If you enjoyed this post and could use some assistance with Infor M3 (functional or technical), I am available for part-time after-hours Infor M3 consulting! Please email me (dirkhoag@gmail.com) or contact me on LinkedIn for further details!

The post Infor M3 Customer Order API Processing Tips appeared first on Ready ERP Solutions.