SOLVED (YAY!!) REST/XERO I am now officially bald

rocketman

I am now officially bald having torn all my hair out.
Following an excellent post by @Gabitas, I started working on an accounting interface to Xero. succesfully made a call, got my tenant ID to the demo company etc, then thought I'd start small and just GET the account details for the BANK accounts.

So I'm looking in my developer account history and can see I'm making successful calls from AwareIM (returning code 200 OK) and I can see using their API Explorer the results I should be getting back into AwareIM (see below). I have a BO called Accounts, and have all the attributes correctly spelt BUT - I'm not getting anything written back into AIM. Not sure about the UdatedDateUTC field - should that be a timestamp? (it is) I've assumed AIM takes care of that? and I'm not sure about the first bit to the first square bracket, is that ignored or do I need to do something with it.

Any ideas would be much appreciated and if you need more info, just shout out

{EDIT} Such a silly - but time-painful mistake!! It wasn't anything to do with Xero or AIM. I had a stupid VIEW command in my process which was trying to view the wrong BO record and it wasn't resolving to anything in context. Result AIM (correctly) rolled everything back. DOHHHH

{
[b]  "Id": "d160d5bb-3f76-43a9-b153-97931e56c40a",
  "Status": "OK",
  "ProviderName": "API Explorer",
  "DateTimeUTC": "\/Date(1692795459269)\/",
  "Accounts":[/b] [
    {
      "AccountID": "bd9e85e0-0478-433d-ae9f-0b3c4f04bfe4",
      "Code": "090",
      "Name": "Business Bank Account",
      "Status": "ACTIVE",
      "Type": "BANK",
      "TaxType": "NONE",
      "Class": "ASSET",
      "EnablePaymentsToAccount": false,
      "ShowInExpenseClaims": false,
      "BankAccountNumber": "990404987654321",
      "BankAccountType": "BANK",
      "CurrencyCode": "GBP",
      "ReportingCode": "ASS",
      "ReportingCodeName": "Assets",
      "HasAttachments": false,
      "UpdatedDateUTC": "\/Date(1692116322947+0000)\/",
      "AddToWatchlist": false
    },
    {
      "AccountID": "a8d6fb1a-8c5d-4683-90ce-bf9d28fc62ba",
      "Code": "091",
      "Name": "Business Savings Account",
      "Status": "ACTIVE",
      "Type": "BANK",
      "TaxType": "NONE",
      "Class": "ASSET",
      "EnablePaymentsToAccount": false,
      "ShowInExpenseClaims": false,
      "BankAccountNumber": "890303876543210",
      "BankAccountType": "BANK",
      "CurrencyCode": "GBP",
      "ReportingCode": "ASS",
      "ReportingCodeName": "Assets",
      "HasAttachments": false,
      "UpdatedDateUTC": "\/Date(1692116322947+0000)\/",
      "AddToWatchlist": false
    }
  ]
}

Jaymer

you have two BO’s that are being returned here.
The top level response with that 4 fields, and then a child many relation for accounts.
So you need to also remap that ID field as that will conflict with aware’s internal ID field name.

rocketman

Thanks Jaymer - see my edited original post. When I put the top level in, I forgot to change the VIEW target. all good now - even dare I say fantastic (says he with fingers crossed) 2 months to a good integration I reckon.

Just need to work on those DateTimeUTC formats

Jaymer

ahhh
1) yep, those dates looked funky
2) first thing I always do is check the raw data in the DB - cause maybe a missing reference pointer is keep the data from showing up. Then I know if Aware is at least processing something. You'll know data got returned, because you can easily see the "REST service replied" line in the Server Output window. But that doesn't mean it went where you think it should have.

BobK

rocketman wrote
Just need to work on those DateTimeUTC formats

Rocketman, Does that mean you know what to do with those formats and you just need to write the rules?
Or do you need assistance with them?

rocketman

Rocketman, Does that mean you know what to do with those formats and you just need to write the rules?
Or do you need assistance with them?

This is all new to me Bobk - flying by seat of pants. Never seen an output like this before. I was kinda hoping AIM would convert it automatically but no such luck. So next stop is to see if I can put something in the http header to request a different output. If not I've already found out (I think) that those numbers in the brackets are seconds not milliseconds past a linux epoch start date WTF!!!.

Quick google - it seems this (xero) bug has ben around sine 2012, acknowledged but never fixed. The only reply seems to be "switch to XML"

Will try that in the morning but any help appreciated

[edit] boolean values seem to be an issue because AIM wraps true and false with inverted commas which Xero doesn't like, but I can probably work around that

BobK

rocketman wrote
I've already found out (I think) that those numbers in the brackets are seconds not milliseconds past a linux epoch start date WTF!!!.

Yes, the digits are the number of (I believe) milliseconds past an epoch. Also called "Unix Time" or "POSIX Time"
1692795459269 => Wednesday, August 23, 2023 12:57:39.269 PM GMT

If you can not get that data in a different format, see
https://www.epochconverter.com/
for more information. Also, at the bottom of that page is help on how to convert those digits to a human readable format using different programming languages.

rocketman

BobK wrote
rocketman wrote
I've already found out (I think) that those numbers in the brackets are seconds not milliseconds past a linux epoch start date WTF!!!.

Yes, the digits are the number of (I believe) milliseconds past an epoch. Also called "Unix Time" or "POSIX Time"
1692795459269 => Wednesday, August 23, 2023 12:57:39.269 PM GMT

If you can not get that data in a different format, see
https://www.epochconverter.com/
for more information. Also, at the bottom of that page is help on how to convert those digits to a human readable format using different programming languages.

Cheers Bob. I reckon I don't actually need them right now because I can update the "Updated Time" in AIM at the end of the process. But good to know for the future - you never know. 🙂 I squirted my first invoice over from AIM to Xero today. 8-)