on 06-14-2021 8:59 AM
For a customer I have multiple valid addresses. One of those addresses is flagged as default address with XXDEFAULT. Now I want to change one of the other addresses as default address. From the GUI this is working like a charm. But when I use the API I get the following error message :
The operation I use is a create on the oData V2 model
R11 244 Error_Time Dependency_Addresses XXDEFAULT_ERROR
This is the URL I post :
API_BUSINESS_PARTNER/A_BusinessPartnerAddress(BusinessPartner='1010004614',AddressID='41791')/to_AddressUsage
This is the payload I post :
{
"BusinessPartner":"1010004614",
"AddressUsage":"XXDEFAULT",
"AddressID":"41791"
}
Hi,
I assume that the address usage validity dates are in Epoch format.
take the example of address ID = 34871, Address usage = 0001
"ValidityStartDate": "\/Date(1593993600000+0000)\/" ==> GMT = Monday, July 6, 2020 12:00:00 AM << Time stamp is in miliseconds
"ValidityEndDate": "\/Date(253402300799000+0000)\/", ==> GMT = Wednesday, January 11, 1978 9:31:40.799 PM << Time stamp is in microseconds
Even if I convert the timestamp in miliseconds, still the validity is no correct.
The same holds true for Address ID = 41791 and 41808.
Do you think that's the problem?
Best Regards,
Ankush
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Ankush,
the validity dates for address 41791 are
To change the address usage I do the following post :
"/A_BusinessPartnerAddress(BusinessPartner='1010004614',AddressID='41791')/to_AddressUsage"
with the following payload
{
AddressID: "41791"
AddressUsage: "XXDEFAULT"
BusinessPartner: "1010004614"
ValidityEndDate: "9999-12-31T23:59:59.000Z"
ValidityStartDate: "2021-06-17T00:00:00,000Z"
}
The result from S4 is R11 244 Error_Time Dependency_Addresses XXDEFAULT_ERROR
User | Count |
---|---|
87 | |
10 | |
9 | |
9 | |
9 | |
6 | |
6 | |
5 | |
4 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.