Advanced planning API returns date mismatch error when importing

MES DELMIA Apriso MES
, , , , , , , ,
1

We’re getting date mismatch errors when importing forecast data via the advanced-planning API. Our ERP system exports forecast dates in local time (EST), but the API is rejecting them with “Invalid date format” errors. The error message suggests using ISO 8601 format, which we thought we were doing.

Here’s a sample of our payload:


{
  "forecastDate": "2024-12-15T09:00:00-05:00",
  "productId": "PROD-12345",
  "quantity": 1000
}

About 30% of our imports fail with this error, but we can’t identify a pattern. Some dates work fine, others don’t. This is blocking our automated daily forecast imports from the ERP system. Is there a specific timezone format Apriso expects? Do we need to convert everything to UTC before sending?

2

Good point about validation. We’ve been relying on the API to catch errors, but pre-flight validation would be much more efficient. One more question - should we be validating against the Apriso server’s timezone or always use UTC for validation as well?

3

Yes, exactly that format. For DST handling, use a proper datetime library that understands timezone rules - don’t try to calculate offsets manually. In Java, use ZonedDateTime with ZoneId. In Python, use pytz or dateutil. These libraries automatically handle DST transitions. Also, make sure your ERP system is sending consistent timezone metadata with each export so your conversion logic knows which offset to apply.

4

Also worth mentioning - add payload validation before you even call the API. Check that all dates are in the correct format, within reasonable ranges (not in the past for forecasts, not more than 2 years in the future), and that they’re properly converted to UTC. We built a pre-flight validator that catches 95% of date issues before they hit the API, which significantly reduced our error rates and made troubleshooting much easier when real issues occur.

5

Let me provide a complete solution covering all the key aspects of this issue.

1. Timezone Conversion Implementation Your ERP system exports dates in EST/EDT (US Eastern Time), but Apriso’s API requires UTC timestamps. You must convert all timestamps to UTC before sending them to the API. Here’s the correct approach:


// Convert EST/EDT to UTC
LocalDateTime localTime = LocalDateTime.parse("2024-12-15T09:00:00");
ZonedDateTime eastern = localTime.atZone(ZoneId.of("America/New_York"));
ZonedDateTime utc = eastern.withZoneSameInstant(ZoneId.of("UTC"));
String isoFormat = utc.format(DateTimeFormatter.ISO_INSTANT);
// Result: "2024-12-15T14:00:00Z"

This automatically handles DST transitions - the ZoneId “America/New_York” knows when to apply -04:00 (EDT) vs -05:00 (EST) offset. Never calculate offsets manually.

2. ISO 8601 UTC Format Requirements Apriso strictly requires UTC timestamps in this exact format: YYYY-MM-DDTHH:mm:ssZ. The “Z” suffix is mandatory and indicates UTC (Zulu time). Do NOT use offset notation like “+00:00” or “-05:00” even though they’re technically ISO 8601 compliant. The API parser specifically looks for the “Z” suffix.

Key format rules:

  • Always use 24-hour time format
  • Include seconds (even if :00)
  • Use “Z” suffix, not “+00:00”
  • No milliseconds in the timestamp
  • Use hyphen separators in date, colon separators in time

3. Payload Validation Strategy Implement a pre-flight validation layer before calling the API. This catches errors early and provides better diagnostics:

Pseudocode for validation:


// Pseudocode - Forecast data validation:
1. Parse timestamp from ERP export
2. Verify format matches expected pattern (ISO with timezone)
3. Convert to UTC using proper timezone library
4. Validate business rules:
   a. forecastDate must be future date (not in past)
   b. forecastDate must be within planning horizon (next 365 days)
   c. productId must exist in master data
   d. quantity must be positive number
5. Format as ISO 8601 UTC with Z suffix
6. Add to validated payload batch
7. Log any validation failures with specific error details
// See Apriso API Guide Section 7.3 for complete validation rules

Validation should happen in your integration middleware, not in the ERP system and not relying on API error responses.

4. Automated Data Import Pipeline For reliable daily imports, structure your automation like this:

  • Extract Phase: Pull forecast data from ERP with original timestamps and timezone metadata
  • Transform Phase: Convert all timestamps to UTC, validate data quality, filter out invalid records
  • Load Phase: Batch API calls (50-100 forecasts per request), implement retry logic for transient failures
  • Reconciliation Phase: Compare import results with source data, log discrepancies, alert on threshold failures

Implement idempotency by including a unique importBatchId in your payloads so you can safely retry failed imports without creating duplicates.

5. Handling the 30% Failure Rate Your current 30% failure rate is almost certainly due to mixed timezone formats in the ERP export. Some forecasts were created during EST (winter) and others during EDT (summer), resulting in different offset notation. Your integration layer needs to:

  • Parse the timezone offset from each timestamp (don’t assume all are the same)
  • Convert each timestamp individually to UTC using the parsed offset
  • Standardize to “Z” suffix format before API submission
  • Log the original timezone and converted UTC value for troubleshooting

Alternatively, if your ERP can export with timezone identifiers (like “America/New_York” instead of just offsets), use those for more reliable conversion.

6. Additional Recommendations

  • Always validate against UTC, not server local time - Apriso internally stores everything in UTC
  • Set up monitoring alerts when validation failure rate exceeds 5%
  • Implement a dead letter queue for records that fail validation repeatedly
  • Document your timezone conversion logic clearly - this is a common source of bugs during DST transitions
  • Test your import pipeline specifically during DST transition weekends (March and November)

After implementing proper UTC conversion and pre-flight validation, your error rate should drop to near zero. We process 5000+ forecast imports daily using this approach with 99.8% success rate.

6

The API expects UTC timestamps only, without timezone offsets. Your dates with “-05:00” are technically ISO 8601 compliant, but Apriso’s parser is strict about UTC format. Try converting to UTC and using the “Z” suffix instead of offset notation.

7

That makes sense. So instead of “2024-12-15T09:00:00-05:00” I should send “2024-12-15T14:00:00Z”? Will test this approach. Our ERP exports in local time, so we’ll need to add timezone conversion logic to our integration layer. Any recommendations on handling daylight saving time transitions?

8

We had the exact same issue last quarter. The 30% failure rate you’re seeing is probably because your ERP exports contain a mix of timezone formats depending on when the forecast was created. Some might be EST, others EDT if they were created during daylight saving time. You need to normalize everything to UTC before sending to Apriso. We wrote a validation layer that checks and converts all timestamps before API submission.