Demand forecast upload via supply planning API fails due to schema mismatch after recent update to forecast entity

ERP Microsoft Dynamics 365
, , , , , , , ,
1

We’re having issues uploading demand forecasts through the supply planning API after upgrading to 10.0.43. The API returns schema validation errors indicating our payload structure doesn’t match the expected entity format. This started immediately after the upgrade - our integration was working fine in 10.0.41.

Error message:


POST /data/DemandForecastEntity
400 Bad Request: "Property 'ForecastDate' not found"

Our payload includes ForecastDate as it always has. I suspect the recent release updated the forecast entity structure, but I can’t find documentation on what changed. The API payload format that worked for months is now being rejected. Has anyone dealt with forecast entity schema changes in 10.0.43? We need to understand what fields were added, removed, or renamed so we can update our integration.

2

I migrated our forecast integration last week. Besides the field changes mentioned, watch out for the date format validation - it’s stricter now. The entity expects ISO 8601 format with timezone offset, whereas before it accepted various date formats. Also, the batch size limit was reduced from 1000 to 500 records per API call for forecast uploads.

3

Thanks Kevin. I checked the metadata and you’re right - several fields were renamed. Besides ForecastDate to ForecastDateValue, I also see ForecastQty is now ForecastQuantity. Are there any other significant changes I should be aware of? Also, is there backward compatibility or do we need to update all our existing integrations immediately?

4

Make sure you’re also handling the new validation rules for forecast models. In 10.0.43, the API validates that the ForecastModelId exists and is enabled for planning optimization before accepting the payload. Previously, this validation happened during the planning run, not at upload time. If you’re uploading forecasts for models that aren’t configured for planning optimization, you’ll get validation errors now.

5

Here’s a comprehensive solution covering all three focus areas:

Forecast Entity Structure Changes in 10.0.43:

The DemandForecastEntity underwent significant restructuring to support the new planning optimization engine. Here’s the complete field mapping from 10.0.41 to 10.0.43:

Field Renames:

  • ForecastDate → ForecastDateValue
  • ForecastQty → ForecastQuantity
  • ItemNo → ItemNumber
  • SiteId → InventSiteId
  • WarehouseId → InventWarehouseId
  • UnitOfMeasure → UnitSymbol

New Mandatory Fields (were optional or didn’t exist):

  • ForecastModelId (required - must reference active forecast model)
  • AllocationKeyId (required - use “NONE” if not using allocation keys)
  • PlanningOptimizationEnabled (boolean - must be true for new engine)

New Optional Fields:

  • CustomerAccountNumber
  • CustomerGroupId
  • ForecastReductionPrinciple
  • MinimumQuantity

API Payload Schema Update:

Old format (10.0.41):

{
  "ItemNo": "D0001",
  "ForecastDate": "2025-05-15",
  "ForecastQty": 1000,
  "SiteId": "1"
}

New format (10.0.43):

{
  "ItemNumber": "D0001",
  "ForecastDateValue": "2025-05-15T00:00:00Z",
  "ForecastQuantity": 1000,
  "InventSiteId": "1",
  "ForecastModelId": "FORECAST2025",
  "AllocationKeyId": "NONE",
  "PlanningOptimizationEnabled": true,
  "UnitSymbol": "EA"
}

Addressing API Payload Schema Mismatch:

  1. Update your payload builder to use new field names
  2. Add mandatory fields with appropriate defaults
  3. Implement ISO 8601 date formatting with UTC timezone
  4. Reduce batch size from 1000 to 500 records maximum
  5. Add validation for forecast model existence before upload

Recent Release Entity Updates:

The 10.0.43 release notes (often overlooked) document these changes under “Planning Optimization Integration”. Key updates:

  • Entity validation moved from async (during planning run) to sync (at upload time)
  • New composite key structure: ItemNumber + ForecastDateValue + ForecastModelId + InventSiteId
  • Response payload now includes PlanningOptimizationStatus field
  • Error messages are more descriptive but follow different format

Migration Strategy:


// Pseudocode for payload transformation:
1. Load legacy forecast data with old field names
2. Map each field to new schema (see mapping above)
3. Validate ForecastModelId exists in D365 master data
4. Convert dates to ISO 8601 with UTC offset
5. Add mandatory fields: AllocationKeyId="NONE", PlanningOptimizationEnabled=true
6. Batch into groups of 500 records maximum
7. POST to /api/data/v9.2/DemandForecastEntity
8. Parse new response structure for confirmation

Testing Checklist:

  1. Verify metadata retrieval: GET /data/$metadata?$filter=contains(name,‘DemandForecast’)
  2. Test single record upload with all mandatory fields
  3. Validate date format handling (try various timezones)
  4. Test batch upload with 500 records
  5. Verify forecast model validation (try invalid model ID)
  6. Check planning optimization integration in D365 UI

Important Notes:

  • No backward compatibility - you must update immediately
  • Old API endpoint (/data/DemandForecastEntity) still works but expects new schema
  • Consider using /api/data/v9.2/ endpoint for better error handling
  • Monitor the response payload - it now includes optimization metadata that can be useful for troubleshooting

This comprehensive update addresses the entity structure changes, payload schema requirements, and recent release modifications needed for successful forecast uploads in 10.0.43.

6

There’s no backward compatibility for the entity structure changes unfortunately. Beyond the field renames, they also added mandatory fields for the planning optimization integration: AllocationKeyId and ForecastModelId are now required where they were optional before. You’ll also notice that the response structure changed - it now includes planning optimization metadata in the response payload that wasn’t there in 10.0.41.