SmartConnect sending extra columns in SOAP post to D365 Financials
Paul asked 6 years ago
When trying to import a CashReceiptJournal to Dynamics 365 for Financials (e.g. NAV), I am getting an error that reads, “AccName is readonly!” The odd thing is, I’m not mapping anything to the AccName column. When I inspect the traffic actually being sent over the web services, I can see that SmartConnect is populating the AccName column (and actually some other columns as well, like the Key column and Document_No).To be honest, I’m not even sure how it’s doing that. The AccName does actually appear to be the correct account description, but it’s not issuing a GET before posting the create. I’m not sure if it’s cached somewhere or what.That’s probably irrelevant, though, since the field is read only and doesn’t need to be set. Is there a way to control which fields actually get sent in the SOAP request and limit it to just the ones that I’m actually directly populating?
Hello Paul,
I just tried to enter Cash Receipt Journal into Dynamics 365 for Financials and only specified a batch, document number, amount, account type, and account number. This transaction was imported correctly without an error.
I know Financials has multiple dependencies that cause changes to field requirements based on which fields you map. So it is possible you have an additional field mapped that is causing the web service to attempt to overwrite the account name.
I would recommending simplifying your map as much as possible so that it will import successfully, then slowly add back fields until you find the one that is causing the error.
I’m not sure how to simplify this any more. I’m mapping exactly the same fields that I have working if I just post to the service directly using SOAP. I did look at this in a bit more detail and it is actually sending two requests per document, so that’s got something to do with where the AccName value is coming from.
I don’t think I understand how SmartConnect is trying to handle this type of document because there isn’t a proper child / header relationship like you might expect when integrating to Dynamics GP. The header is really the CurrentJnlBatchName, but batch persists indefinitely in NAV. Every time you post it, it just clears all the child lines.
According to this video (http://www.eonesolutions.com/blog-post/tech-tues-setting-key-fields-and-grouping-inside-of-smartconnect-demo-video/), I should be setting my Key fields to the ones that essentially define the document and then I probably should be marking the same fields as the Group On for the header record. But, SmartConnect is making me use the CashReceiptJournal as though it *is* the header.
In my sample data set, I have 12 total records which make up two documents (documents being defined as sharing the same External Document No, but consisting of multiple CashReceiptJournal lines). If I set my key fields in my source and Group On the local document key, SmartConnect correctly reports that it is sending two documents, but when I inspect the traffic that SmartConnect is actually sending to the web service, it is only sending one line per request. Moreover, it seems that it is sending one request to “create” the batch and then another to update it, which doesn’t make sense to me since the batch already exists and is just being appended to.
Example of request 1 (I have redacted sensitive information and pretty-printed the SOAP body, but made no structural changes):
POST https://{{redacted}}:7047/MS/WS/My%20Company/Page/CashReceiptJournal HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; MS Web Services Client Protocol 4.0.30319.42000)
Content-Type: text/xml; charset=utf-8
SOAPAction: “urn:microsoft-dynamics-schemas/page/cashreceiptjournal:Create”
Authorization: Basic {{redacted}}
Host: {{redacted}}:7047
Content-Length: 398
Expect: 100-continue
Which yields the following response:
HTTP/1.1 200 OK
Content-Length: 1119
Content-Type: text/xml; charset=utf-8
Server: Microsoft-HTTPAPI/2.0
Date: Tue, 18 Jul 2017 19:23:43 GMT
It seems it is then applying the values from the first response when generating the update (to be honest, I’m not really clear on where those values are coming from, but they look a lot like the default values if I just start entering a new line in the app, except that it has an AccName value even though it doesn’t have an AccountNo value).
Example of request 2:
POST https://{{redacted}}:7047/MS/WS/My%20Company/Page/CashReceiptJournal HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; MS Web Services Client Protocol 4.0.30319.42000)
Content-Type: text/xml; charset=utf-8
SOAPAction: “urn:microsoft-dynamics-schemas/page/cashreceiptjournal:Update”
Authorization: Basic {{redacted}}
Host: {{redacted}}:7047
Content-Length: 1409
Expect: 100-continue
Which yields the following response:
HTTP/1.1 500 Internal Server Error
Content-Length: 440
Content-Type: text/xml; charset=utf-8
Server: Microsoft-HTTPAPI/2.0
Date: Tue, 18 Jul 2017 19:23:44 GMT
By contrast, when I generate the SOAP request just using the GeneralJournal_PortClient class generated by adding a service reference in Visual Studio, I generate only one request per line:
POST https://{{redacted}}:7047/MS/WS/My%20Company/Page/CashReceiptJournal HTTP/1.1
Content-Type: text/xml; charset=utf-8
VsDebuggerCausalityData: uIDPo+99Z7YbVylNiN8u/hgJ7yoAAAAA5/MTiiIeGku7Nx/erRZy2xUPnxy4RhpIjk/CRRoEOSsACQAA
SOAPAction: “urn:microsoft-dynamics-schemas/page/cashreceiptjournal:Create”
Accept-Encoding: gzip, deflate
Authorization: Basic {{redacted}}
Host: {{redacted}}:7047
Content-Length: 645
Expect: 100-continue
With response:
HTTP/1.1 200 OK
Content-Length: 1262
Content-Type: text/xml; charset=utf-8
Server: Microsoft-HTTPAPI/2.0
Date: Tue, 18 Jul 2017 20:29:39 GMT
If I set absolutely everything as a key and Group On, it says it sends 12 documents and it does send 12 requests, but they are the same as above, in that half are empty “create” transactions and the other half are “updates” so, in fact, it is only sending 6 transactions. SmartConnect is reporting 4 successes and 8 failures, but only 2 of the 12 requests actually returned an error from NAV. 2 of the errors start with, “Failed to create record with keys… Field AccName is readonly!” while the other 6 start with, “Processing failed for data rows matching…” Looking at the data more, it looks like the lines it isn’t sending are the ones that should be Account_Type = Bank_Account. It’s not giving me much information, though, about what is wrong for those lines. The ones that are actually failing at the server are the Account_Type = G_L_Account lines where the AccName is different than the AccName SmartConnect is sending (apparently, NAV doesn’t care if you send it as long as it matches to what it thinks it should be). I get the same result even if I create a brand new batch. I think it’s probably a bug in NAV that it’s sending an AccName back as part of the initial create request, but then, it also didn’t expect the value to round-trip, so it wouldn’t normally matter.
In summary, I only seem to be able to send G/L Account lines to NAV Cash Receipt Journals using SmartConnect, and then only if the AccountNo matches the default description from the batch. Any thoughts? Try sending two transactions with different G/L accounts and see if you get the same result.
Sigh. This forum didn’t encode the XML tags, so you’re just seeing the values. Here’s a re-post with tags escaped hoping that will render better…
I’m not sure how to simplify this any more. I’m mapping exactly the same fields that I have working if I just post to the service directly using SOAP. I did look at this in a bit more detail and it is actually sending two requests per document, so that’s got something to do with where the AccName value is coming from.
I don’t think I understand how SmartConnect is trying to handle this type of document because there isn’t a proper child / header relationship like you might expect when integrating to Dynamics GP. The header is really the CurrentJnlBatchName, but batch persists indefinitely in NAV. Every time you post it, it just clears all the child lines.
According to this video (http://www.eonesolutions.com/blog-post/tech-tues-setting-key-fields-and-grouping-inside-of-smartconnect-demo-video/), I should be setting my Key fields to the ones that essentially define the document and then I probably should be marking the same fields as the Group On for the header record. But, SmartConnect is making me use the CashReceiptJournal as though it *is* the header.
In my sample data set, I have 12 total records which make up two documents (documents being defined as sharing the same External Document No, but consisting of multiple CashReceiptJournal lines). If I set my key fields in my source and Group On the local document key, SmartConnect correctly reports that it is sending two documents, but when I inspect the traffic that SmartConnect is actually sending to the web service, it is only sending one line per request. Moreover, it seems that it is sending one request to “create” the batch and then another to update it, which doesn’t make sense to me since the batch already exists and is just being appended to.
Example of request 1 (I have redacted sensitive information and pretty-printed the SOAP body, but made no structural changes):
Which yields the following response:
It seems it is then applying the values from the first response when generating the update (to be honest, I’m not really clear on where those values are coming from, but they look a lot like the default values if I just start entering a new line in the app, except that it has an AccName value even though it doesn’t have an AccountNo value).
Example of request 2:
Which yields the following response:
By contrast, when I generate the SOAP request just using the GeneralJournal_PortClient class generated by adding a service reference in Visual Studio, I generate only one request per line:
With response:
If I set absolutely everything as a key and Group On, it says it sends 12 documents and it does send 12 requests, but they are the same as above, in that half are empty “create” transactions and the other half are “updates” so, in fact, it is only sending 6 transactions. SmartConnect is reporting 4 successes and 8 failures, but only 2 of the 12 requests actually returned an error from NAV. 2 of the errors start with, “Failed to create record with keys… Field AccName is readonly!” while the other 6 start with, “Processing failed for data rows matching…” Looking at the data more, it looks like the lines it isn’t sending are the ones that should be Account_Type = Bank_Account. It’s not giving me much information, though, about what is wrong for those lines. The ones that are actually failing at the server are the Account_Type = G_L_Account lines where the AccName is different than the AccName SmartConnect is sending (apparently, NAV doesn’t care if you send it as long as it matches to what it thinks it should be). I get the same result even if I create a brand new batch. I think it’s probably a bug in NAV that it’s sending an AccName back as part of the initial create request, but then, it also didn’t expect the value to round-trip, so it wouldn’t normally matter.
In summary, I only seem to be able to send G/L Account lines to NAV Cash Receipt Journals using SmartConnect, and then only if the AccountNo matches the default description from the batch. Any thoughts? Try sending two transactions with different G/L accounts and see if you get the same result.