D365 F&O - When posting Service Orders, Project Item Journals, Item Transfer Journals, A key with the name 0.00 already exists.

 Recently we ran into an issue when posting Service orders, project item journals, or item transfer journals with multiple lines.  The error we received is:

Check - Journal Journal: 000341 A key with the name 0.00 already exists.

In looking deeper, it seemed that the issue was a violation of the primary key on the InventJournalTrans table that is associated with the voucher.  The actual error is occuring in classes\JournalTransList\selectDB class\method.  Inside that class the 'add' method is called and when calling 'ins' on a RecordInsertList it is failing.

In doing some searching I found a post for AX 2009 here.  This post is nearly 15 years old!  However, my situation is the exact same.  I have an extension of the InventJournalTrans where I added the SMAServiceOrderLineNum field which extends the 'LineNum' EDT.  This was causing the system to think my custom field was part of the index and therefore throwing the error on multiple lines.

Solution:

As mentioned in the link, create your own Real EDT that extends 'LineNum' and use that for your field on the table.

Power Automate Looks like your flow's connection needs to be signed-in again

 Yesterday one of my Power Automate cloud flows started fail with the following message:

Looks like your flow's myemail@mywork.com connection needs to be signed-in again. The most common cause is a changed password or a policy set by your tenant administrator. Connections may also require reauthentication, if multi-factor authentication has been recently enabled for your account.

I didn't have a password change nor did I enable MFA.  It could have been a policy change in our tenant, however, my infrastructure team hasn't been able to confirm.  

I was able to fix the issue by logging into make.powerautomate.com in a Chrome incognito window.  Once I logged in I was showin this:

These are the 3 cloud flows that I have created.  Once I hit 'Reauthenticate' I was then taken to:

I clicked 'Fix connection' on each item and completed a short logon procedure.  This fixed the issue.

This blog post was helpful in understanding what possible causes were and the solution.

Dataverse web api 'Expand'

Today, I was attempting to use the 'Expand' feature in the web api to help me with a lookup field on my custom dataverse table.  No matter what I did, I could get it to work.  It kept telling me that my property 'ver_dataareaid' didn't exist on my table.  It, obviously, did so I knew I was doing something wrong.  When using the 'Expand' you need to use the Schema name of the field:

As you can see, the 'Schema name' can be found under the 'Advanced options' when you 'Edit' the column.  This gave me the actual 'Name' value of the column rather than a guid from the lookup.

Edit Dataverse table record error: It is not possible to change transferred line.

I have a dataverse table that was populated using Dual-Write and a D365 F&O entity.  When attempting to edit a record directly on the dataverse table, I get the following error: 

There was an error in saving this record. Unable to write to Finance and Operations apps due to following error(s): {"Write failed for entity VER_SMAServiceOrderLineEntity with unknown exception - It is not possible to change transferred line.\nvalidateWrite failed on data source 'SMAServiceOrderLine (SMAServiceOrderLine)'"} Please rectify your data and try again. If issue persists after multiple retries, please contact your system administrator.

This error is coming from the 'validateWrite' method on the SMAServiceOrderLine table because the service order is in a 'Posted' status.

 

D365 F&O - DMF Import 'Field 'Service Order' does not allow editing'

 I came across this error while trying to import data into a copied version of the 'SMAServiceOrderHeaderEntity'.  I posted a question about here and was able to find the following solution.

I have a custom Data Entity for the Service Order Table.  My primary key is my ServiceOrderNumber field.

When I import a file with an existing ServiceOrderNumber it updates the record as expected.

However, if I want it to create a new record I can't use the 'Auto Generate' on my primary key as that would break the 'update'.

So, I decided to follow what had been done in the CustCustomerV3Entity.

I set my 'ServiceOrderNumber' 'Allow Edit' field properties on the Entity and Staging table to 'Yes'.

In looking through all the setup and code for the customer entity, this seems to be it.  However, I still get:

Originally, I thought the second error was tied to the first, however, it was not.

In doing more research, I found that the label from this error was this:

 

 

This label is referenced in 4 classes. Only 1 of which would be used by DMF.  

 

That led me to the NumberSequenceTable and the 'numAllowEdit' method.

That method says that unless one of 3 fields is set to 'Yes', the field using the number sequence is NOT editable:

 

 

Once I set 'To a Higher Number' to yes (Seemed like the safest change for my purposes) the '... does not allow editing.' error went away.

The other error remains.  It looks like it isn't generating a new Service Order Number like it should.  Based on the CustCustomerV3Entity, I did the following in the 'initvalue' method of my data entity:

 

 

This is similar to what I see on the CustCustomerV3Entity and other Data Entities that allow Write operations.

I believe this is supposed to tell the field to use the Number Sequence specified in 'SMAParameters'.

However this did not work.  After some trial and error, I found that I had to remove the 'SERVICEORDERNUMBER' column (In my case XML attribute) from my file completely.  It then would successfully import.

This may cause an issue down the line as my import file could come with that field defined for an update or not defined for a new record creation.  We will see how that works out.

D365 F&O - Workspace form pattern error: The browser session was lost due to an error on the server.

This week I was attempting to prototype a workspace in F&O.  After walking through the 'Pattern' I applied to the newly created form, I ran my workspace and ran into this error:

It doing some testing I found that once I got to the 'Form Part' of the 'Tab Page' of the pattern, I had to specify a menu item for the form part. This, basically, shows another form inside your workspace form.  Once I specified that, it worked great.

AX 2012 R2 CU9 (Originally CU6) to D365 F&O Code & Data Upgrade

 Over the past several weeks I have been attempting to upgrade our AX DB into D365 mainly using instructions from here.  

Before doing the steps there, you will need to see if you  have a 'Display' menu item named 'SysCheckList_UpgradeToNextV'.  If you don't have that (Which I did not), then you will need to install KB4048614.  This will give you an upgrade checklist to prep your database and modelstore for the upgrade. (This will require going through the standard software update checklist.)

After going through some failed attempts, I narrowed my focus to 2 main paths:

1. Upgrade my company's custom code / data ONLY.
1. This means removing ALL ISV models. This was ok for us as our ISVs have D365 solutions.
2. Upgrade my company's custom data that fits in vanilla AX. 
1. This means removing ALL custom models.

For BOTH options, you must do a full compile, full CIL, and FULL DB sync along with running the new checklist from above.

For option 1, the best idea is to move ALL your customizations into 1 single model.  For some reason, mine were spread out over 4 different models.  You can keep it in different models, however, I think it makes it more difficult.
After attempting a code and data upgrade for option1, we decided to remove ALL non data related customizations. (Classes, forms, etc.) This would leave us with only our Tables, EDTs, etc. 

However, after looking at the amount of work to upgrade this, we decided to give option 2, from above, a try.

All customizations were removed and we began the 'Data upgrade' using the link above.  Our database is pretty big (Over 300 GB). This upgrade process took over 48 hours.  Aside from time, we only ran into a couple of errors in the 'ExecuteScripts' step.  We had to skip 2 steps. To do that, you can follow instructions here. For some reason there were duplicate records in 4 tables so there were some DB sync failures.  They were easily fixed and we were able to get the full data upgrade completed.