Date Field Changes in the WSDL
In WSDL 68 and earlier, Zuora treats 56 SOAP API date fields as dateTime fields. From WSDL 69 and later, Zuora treats these fields as date fields. These fields are no longer compatible with dateTime values.
This article describes the date field changes and provides guidelines on how check your SOAP API integrations. After checking and updating your integrations, you are ready to download and use WSDL 69 or later.
SOAP API
Before downloading and using WSDL 69, check your SOAP API integration to see if you are passing or receiving any dateTime values to or from date fields.
AQuA API
The date field changes described in this article also apply to AQuA API versions 69 and later. This is because the API version of AQuA is based on the corresponding version of the Zuora WSDL—for example, API version 69 is based on WSDL version 69.
- If you want to use API version 69 or later, check your AQuA integration to ensure that you are not passing in or expecting to receive any dateTime values from date fields.
- If you don't want to use API version 69 or later, ensure that you specify the version you do want to use in the
apiVersion
field of your AQuA queries. Otherwise, AQuA will use the latest version by default, which will result in a different date field format and may cause your existing integration to break.
There is an additional dateTime field issue that was resolved for AQuA in API version 69. See Time Component was Not Present in DateTime Fields in the July 2015 Release Notes for more information.
Zuora for Salesforce
If you use Zuora CPQ, review the affected date fields listed below, and check and update your integration code.
Refer to Zuora Quotes Q2 2015 Release Notes and Zuora 360 Q2 2015 Release Notes for the compatibility between versions of Zuora WSDL and Zuora CPQ packages.
Why Should I Make These Changes?
Future releases of the Zuora WSDL will be based on WSDL 69. After you change your date fields, you will be able to have access to new features in the future using the SOAP API.
What Has Changed in Date Fields?
To use WSDL 69 or later, check your Zuora SOAP API integration for date fields that send or receive dateTime values. The response from a date field will only be a date. The response from a dateTime field will only be a dateTime. If you try to pass a dateTime to a date field when using WSDL 69 or later, you will get an INVALID_VALUE
error message.
To become compliant:
- Remove any time and time zone offset components from values you use with a SOAP API date field.
- Change your Zuora integration to expect that time and time zone offset components are not returned from a date field.
For example:
- 2015-02-28T23:23:23 becomes 2015-02-28
- 2015-02-28T23:23:23-08:00 becomes 2015-02-28
As an example, from WSDL 69 and later, ContractEffectiveDate is a date field and will only accept or return a date value:
In WSDL 68 and earlier, ContractEffectiveDate is a dateTime field and will accept or return a dateTime value:
Which Date Fields Do I Need to Check?
You need to check the following fields in your SOAP API integration:
Object | Field |
---|---|
Account | LastInvoiceDate |
Account | TaxExemptEffectiveDate |
Account | TaxExemptExpirationDate |
AccountingPeriod | EndDate |
AccountingPeriod | StartDate |
Amendment | ContractEffectiveDate |
Amendment | CustomerAcceptanceDate |
Amendment | EffectiveDate |
Amendment | ServiceActivationDate |
Amendment | TermStartDate |
BillRun | InvoiceDate |
BillRun | TargetDate |
BillingPreviewRequest | TargetDate |
BillingPreviewRun | TargetDate |
ChargeMetrics | UpToDate |
CreditBalanceAdjustment | AdjustmentDate |
ExternalPaymentOptions | EffectiveDate |
Invoice | DueDate |
Invoice | InvoiceDate |
Invoice | TargetDate |
Note: This object is deprecated on Production in WSDL version 64.0. | RevRecStartDate |
InvoiceItem | RevRecStartDate |
InvoiceItem | ServiceEndDate |
InvoiceItem | ServiceStartDate |
InvoiceItemAdjustment | AdjustmentDate |
InvoiceItemAdjustment | ServiceEndDate |
InvoiceItemAdjustment | ServiceStartDate |
InvoiceSplitItem | InvoiceDate |
Payment | EffectiveDate |
PaymentMethod | MandateCreationDate |
PaymentMethod | MandateUpdateDate |
PaymentMethodSnapshot | MandateCreationDate |
PaymentMethodSnapshot | MandateUpdateDate |
Product | EffectiveEndDate |
Product | EffectiveStartDate |
ProductRatePlan | EffectiveEndDate |
ProductRatePlan | EffectiveStartDate |
RatePlanCharge | ChargedThroughDate |
RatePlanCharge | EffectiveEndDate |
RatePlanCharge | EffectiveStartDate |
RatePlanCharge | ProcessedThroughDate |
RatePlanCharge | TriggerDate |
Refund | RefundDate |
SubscribeInvoiceProcessingOptions | InvoiceDate |
SubscribeInvoiceProcessingOptions | InvoiceTargetDate |
Subscription | CancelledDate |
Subscription | ContractAcceptanceDate |
Subscription | ContractEffectiveDate |
Subscription | ServiceActivationDate |
Subscription | SubscriptionEndDate |
Subscription | SubscriptionStartDate |
Subscription | TermEndDate |
Subscription | TermStartDate |
TaxationItem | TaxDate |
Related Date Field Changes
Querying SOAP API Objects Using ZOQL
Using WSDL 68 or earlier, you can filter date or dateTime fields with date or dateTime values.
When using WSDL 69 or later, you must use a dateTime value to filter a dateTime field. You can only use a date value to filter a date field.
For example you must use a date value to filter ContractEffectiveDate
:
select AutoRenew from subscription where ContractEffectiveDate = '2015-02-28'
See Zuora Object Query Language for more information.
Data Source Export Actions
In WSDL 68 and earlier, the output format of dates and dateTimes in data source exports depends on how data was entered into Zuora. Integrations that use data source exports in WSDL 68 or earlier may need to accommodate both date and dateTime values for the same field.
From WSDL 69 and later, the output from dateTime fields is a dateTime and the output from date fields is a date. For example:
- A value of
2015-02-13T23:18:00-08:00
will be exported as2015-02-13T23:18:00-08:00
- A value of
2015-02-13
will be exported as2015-02-13
See Data Exports Introduction for more information.