While using this SDK, I found some issues:

1. I used the GuzzleHttp client with the base_uri set to https://api.fattureincloud.it/v1/. Unfortuantely, in your code you preprend the API calls with a slash (e.g. here) making these absolute URLs. What that means is that the /v1 part is stripped from the URL resulting in an invalid call. This may be a different story with another client implementation - which one do you use?
2. How can I update existing entities? The save and delete methods in your code assume that the $client variable is set. However, this is only the case after creating an object via the API. There is no chance to set the client variable, as it is private.

If I find something else, I will update this list. Anyhow, thanks for publishing this SDK :)

Salve, sarebbe interessante e utile avere il campo 'rivalsa' per poter impostare una percentuale di rivalsa inps nei documenti.

From the official documentation: https://api.fattureincloud.it/v1/documentation/dist
Here's the list of what is missing in this library.

Resources

Product

• Product list
• Product new/edit
• Product delete
• Product bulk insert

Document

• Documents Info
• Document email sending

Purchase

• Purchase list
• Purchase new/edit
• Purchase delete

Fee

• Fee list
• Fee new/edit
• Fee delete

Warehouse

• Arrival list
• Arrival detail

Email

• Email archive list

Info

• Misc data

Documentation

• Everything

Tests

• Everything 😄

The phone parser default region is always "IT" as reported in #3 (comment)

Customization should be implemented here (possibly with the help of a static property in the Subject model class?)

/cc @alxy

Can you also add the API interface for Good entities? I was able to create my own API\Good class, but I think it makes sense to have this as well in the package.

The use case is the following: We manage customers and products in our custom CRM, but do the accounting stuff (invoices) directly on the fatture in cloud website.

Document::fromArray which is called after getting a document or creating a new one (returned value is a new objected created from response in order to have all computed values filled from FIC) is already multiplying * 100 all amounts to work with integers. This of course is great when working with amounts, also makes happy Money constructor.

Unfortunately FIC api response sends back floats with a precision of 4 digits. Multiplying by 100 does not give us an integer as expected but leaves us a float. Example we get 32.9644 in the response, we multiply new Money($item['prezzo_netto'] * 100, $this->currency), we have now 3296.44 which is passed to Money constructor.

There a Money\Number object is created in order to check if the amount passed is an integer or not and unfortunately in our case we still have a decimal part:

if (filter_var($amount, FILTER_VALIDATE_INT) === false) {
    $numberFromString = Number::fromString($amount);
    if (!$numberFromString->isInteger()) {
        throw new \InvalidArgumentException('Amount must be an integer(ish) value');
    }

    $amount = $numberFromString->getIntegerPart();
}

This affects only Document so far and a quick fix would be to round down amounts to a precision of 2 digits (keeping PHP_ROUND_HALF_UP mode) before multiplying by 100:

new Money(round($item['prezzo_netto'], 2) * 100, $this->currency)

EDIT:
However this approach would work for most cases (currencies with subunits down to cents) it wouldn't work for other cases like JPY, ISK (just to mention two) without cents or TND which goes down to milim (1/1000).

Knowing that it would be good to get the subunit for a currency in order to know how to round it and how to multiply it to get an integer. Below example:

$eur = new Currency('EUR');
$subUnit = (new ISOCurrencies())->subunitFor($eur);
$amount = new Money(round($item['prezzo_netto'], $subUnit) * (10 ** $subUnit), $this->currency)

This would cover all currencies! @alekitto what do you think?

Cs check should run on every commit/PR.

GitHub actions should be used to run the linter while travis executes the tests.

@alekitto Are you planning to add support for all the other end points of the API? Thinking to products, purchases, mail, info, etc... Maybe you could open some issues where to discuss that and then someone could pick up, I could help with that.

I am afraid that this is another inconsistency in the API, but I just realized the Good class does not contain the giacenza_iniziale attribute, which is documented here.

On the other hand, it does contain another attribute quantita, which I expect is used in the invoice context (which we do not use). Do you see any issue adding the initial stock attribute to the model class?