Payment terms on contacts not being sent

[alexkb]

Firstly good job on the library it's far superior to the official XeroPHP implementation. Anyway onto the issue:

When adding the payment terms to a contact, this library assumes multiple payment terms with multiple bills (for lack of a better descriptor of supplier bills) are supported and sends the following (same for Sales used for customer invoices):

<Contacts>
  <Contact>
    <ContactNumber>706314</ContactNumber>
    <Name>yet another with terms</Name>
    <PaymentTerms>
      <PaymentTerm>
        <Bills>
          <Bill>
            <Day>7</Day>
            <Type>DAYSAFTERBILLDATE</Type>
          </Bill>
        </Bills>
      </PaymentTerm>
    </PaymentTerms>
  </Contact>
</Contacts>

The Xero API doesn't work this way. The correct way is to send payment terms like this:

<Contacts>
  <Contact>
    <ContactNumber>706314</ContactNumber>
    <Name>yet another with terms</Name>
    <PaymentTerms>
      <Bills>
        <Day>8</Day>
        <Type>DAYSAFTERBILLDATE</Type>
      </Bills>
    </PaymentTerms>
  </Contact>
</Contacts>

Happy to do a pull request to get this fixed if you like, but thought I'd report it first unless I've misunderstood something.

[calcinai]

Ah, I've come across that before. I've got an idea how I can fix that pretty quickly.

[alexkb]

Should just be a case of changing the PaymentTerms in the Contact class to be a property instead of an ArrayObject, and the same for bills/sales inside PaymentTerms class.

[calcinai]

On closer inspection, this is a mess. The generated objects don't really represent the structure as there is a max of one of the singularised objects.

I'm not sure of an elegant way to solve this. If you think about it, it should really be the other way around something like: $contact->setPaymentTerms('Bills', PaymentTerm); but that gets very messy. I think the only real option is dropping the Bill and Sale classes in favour of using just the PaymentTerm class?

Obviously also a bit tricky since this is all generated code, but that's another issue!

[alexkb]

Hey @calcinai thanks again for the reply. For now, we're solving things by inheriting from your Contact and PaymentTerm classes and setting things the way we need them to be. Here's a gist of the code.

May I ask what tool(s) you used to generate the code in this repo? Cheers.

[calcinai]

Have a look in /generator/generate - its a horrible, write-only piece of code...

And I think you're correct to extend it, there is no real way to do it cleanly automatically. I'll migrate to generated base models and make some stubs in 2.0.

[direvus]

Not sure if it is any help, but here is the patch I am running on my local copy of XeroPHP, based on the code gist @alexkb provided (thanks @alexkb !)

https://gist.github.com/direvus/bcffbdd1554413431ae8cf272506e62e

I wonder if it would be practical to have your auto-generation tools do the initial scrape from the Xero docs, and then apply a series of patches to cope with this and other similar issues (like the Tracking Categories).

[rodjsta]

@direvus your patch also worked for me. Is there any reason for this not to be included in the package?