Skip to main content

Notifications

Community site session details

Community site session details

Session Id :

Update ItemCoverage using OData – Limitation & Workaround – D365FO

Anitha Eswaran Profile Picture Anitha Eswaran 312

Updating existing data using Odata is not a new ask in any integration. Most of the entities which are exposed in D365FO would not have any issues during update. I`ve posted the CRUD operations for the entities here

Update for entity is not direct and has to be accompanied with the parameters which are defined in ‘Entity Keys’. The columns defined in the entity-key should be specified in the post/patch request.

Although updates for most of the entities works fine, there are few entities that throws error even when the above rules for the update are followed.

One such entity is ItemCoverageSettingsV2.

This entity has 12 columns in the entity key and users will face issues when trying to update the record. We will be in a situation where we will have a doubt if the syntax for the update is right or if there are some mistakes from our side. I had the same situation and after spending an hour, found the issue lies with the entity.

This entity comes with a lot of key fields. And therefore when you try to update it with PATCH request it will fail:

The error was different and having no clue on what the issue was

It is because of the number of characters after DataEntityName should not exceed 260 characters.

In order to handle this , batch comes to rescue.

PATCH /data/$batch

Header details

Content-Type    multipart/mixed;boundary=batch_AAA123

Given below the contents in Body section ( make sure the line spaces are not removed). For the record in my example, warehouse and site were used and other configs were empty. Please fill the other ones according to your record.

--batch_AAA123
Content-Type: multipart/mixed;boundary=changeset_BBB456

--changeset_BBB456
Content-Type: application/http
Content-Transfer-Encoding:binary

PATCH ItemCoverageSettingsV2(dataAreaId='usmf',ItemNumber ='L0006',CoverageWarehouseLocationId='',CoverageItemBatchNumber='',CoverageProductColorId='',CoverageProductSizeId='',CoverageProductStyleId='',CoverageProductVersionId='',CoverageWarehouseId='11',CoverageItemSerialNumber='',CoverageSiteId='1',CoverageInventoryStatusId='',CoverageProductConfigurationId='')?cross-company=true HTTP/1.1
Content-ID: 1
Content-Type: application/json

{
    "IsProcurementLeadTimeOverridden":"Yes",
    "ProcurementLeadTimeDays": 111,   
    "MinimumOnHandInventoryQuantity":10,
    "MaximumOnHandInventoryQuantity":91
}
--changeset_BBB456--
--batch_AAA123--

I first tried a simple GET request in Postman to get the details of Item Coverage for one of the items.

url/data/ItemCoverageSettingsV2?$filter=ItemNumber eq 'L0006'

Now we can make sure if the field names and their values are proper from the above response which can be used in the Patch request.

Any errors would be captured in the response and take actions accordingly.

In my case, when I was trying to update ‘MinimumOnHandInventoryQuantity’ /’MaximimOnHandInventoryQuantity’ , the error was about the warehouse to be available for the record. Warehouse can be updated via another similar request and make sure the value of the warehouse has to be reflected in the body of the next request when actual update of min/max is passed.


This was originally posted here.

Comments

*This post is locked for comments