On one of my first M3CE projects (and not the only project I’ve encountered this on) I had a customer email me that they couldn’t access M3 within their tenant anymore, they would just get an error and infact, all their users were getting an error when they tried to access M3. They had just done a company copy from their golden configuration company over top of the company that they were testing in.

I logged in to their tenant and was able to access M3.

My user had a different default company in MNS150 to the other users. Examining the users that couldn’t access M3 in MNS151 it became apparent that they didn’t have access to their default company after the company copy.

Correcting this isn’t as simple as adding the accounting entities for the company/divisions in IFS. In order for IFS changes to be replicated, the M3_SecurityUserMaster_Sync_In MEC map must be processed. This MEC map makes a variety of API calls to M3, one of the initial API calls is MNS150MI.GetUserByEUID (this is the IFS GUID of the user). If this API call doesn’t return a M3 user, the MEC map will attempt to add the user rather than update the user.

The key thing here is that for MNS150MI.GetUserByEUID to succeed, the user MUST have access to their default company and division. If they don’t the MEC Map will assume that the user doesn’t exist and call the MNS150MI.Add API and will subsequently fail because the user already exists. The MEC map has the Add API set to exit map on failure, so the MEC map ends before the later loop in the map to add the user to the appropriate companies/divisions (MNS150.AddUsrPerCmpDiv).

Correcting this the first time I struck it was pretty easy. I just added the appropriate MNS151 records to the users for their default company and division and then made a change to each of the users in IFS to push down all the divisions and companies. In this instance I was pretty lucky that I still had access to M3. If I didn’t then I could have leveraged the ION APIs with an account that has the M3BE-SystemAdministrator role and manually call the MNS150.AddUsrPerCmpDiv API to add my company and division to my account to allow me to log in.

I created an example Powershell script that will leverage the ION APIs to change the default company/division of a user or users and add them to MNS151. The Powershell script will need a valid .ionapi file created for a backend service with a valid service account (as noted above, you may need the M3BE-SystemAdministrator role on the account if you have no users with access to M3).

https://github.com/potatoit/m3ChangeDefaultCompanyIONAPI

When doing company copies, there are many things that we need to be conscious of during the project and when we go live. Definitely don’t forget to check the default company and division of users before copying or deleting companies