Some issues about fatture-in-cloud-sdk HOT 14 CLOSED

Thanks for opening this issue, this library is still a work in progress and some other bugs may be present.

For those you have listed here:

1. Yes, you’re right. It is probably an error, I’ll fix that asap.
2. The $client property was supposed to be set by a get static method that should fetch the data from the API, but its not yet implemented. Will be done in the next few days.

Please keep us updated if you find some other issues.

from fatture-in-cloud-sdk.

Considering the update/delete API: If I understand your approach correctly, it would always need two calls to update an entity (one to retrieve the data, and one to actually update). I am not sure if I like this approach, because sometimes I really just want to update an entity to keep it in sync with my local client database. Also considering API rate limits, I think there should be at least an option to perform these operations standalone, i.e. only providing the data and the FIC-id.

from fatture-in-cloud-sdk.

1. I was about to open the same issue, I think I can send another pull request tonight about it. The problem is that some calls are using absolutes paths while this is not ok when working than URIs, turns out v1 is stripped out. That should affect only Subject and AbstractList at the moment though.

2. Client is injected into all elements of a list, so you first need to fetch entities filtering maybe passing some parameters and then you can work on single elements of the list updating/deleting them.

from fatture-in-cloud-sdk.

@alxy Yes, you understood well. I used the same approach that I've used in other contexts where API rate limits were not a problem, but I see that in this case could be somewhat limiting.

On the other side, I personally think that updating/deleting a resource without knowing its content or without checking if the update needs to be fired or not is a practice to be discouraged.
A compromise should be making all the $client properties protected: in this way you could safely extend the classes of this library and inject the client via a setter when you want to use it in this way.

from fatture-in-cloud-sdk.

Mh, this really comes down to personal preferences now (and maybe also the application after all).
In my case, I have a local CRM with customers in it, and just wanted to hook into create/update events and sync it with this webservice. There it would be really, really bad, as for each update I would need two calls (I dont need a list of clients there, I just want to update one specific by its ID).

So what I would like is a signature like this:

public function update($id = null, ClientInterface $client = null): self

Both parameters can be null. in this case they are inferred from the current Subject instance.

Maybe there is also a more elegant way of injection the client, as it feels kind of redundant doing it for every call. There are other APIs which save the client in a static variable. I am unsure if this is considered clean code, but the interface to end user looks much cleaner...

from fatture-in-cloud-sdk.

I don't think that injecting a dependency via a static method could ever be considered clean code 😄
But I start thinking that the Subject class is not the right place where to resolve this in a clean way. I'll keep you updated on that in the next few days.

from fatture-in-cloud-sdk.

@alxy You can now use $client->api()->customer()->update() method to update a customer without fetching it first.
Please test it carefully and tell us if it's working correctly and fits your use case.

from fatture-in-cloud-sdk.

Hi @alekitto , I finally found the time to test this out. I used the new API interface for create, update and delete actions: $this->client->api()->customer()->create($customer);

The problem now is, while the request is executed successfully (the customer is created at fatture in cloud), the code throws an exception:
Symfony\Component\Debug\Exception\FatalThrowableError: Undefined property "id" in /home/vagrant/Code/vendor/fazland/fatture-in-cloud-sdk/lib/Model/Subject/Subject.php:163
This is because this line triggers the setter in the Subject model. Maybe it makes sense to make the id property public?

edit/ I just realized the same applies for $client as well.

Another issue: Phone numbers are always expected to be italian. The number may be from an international customer making the number invalid: https://github.com/fazland/fatture-in-cloud-sdk/blob/master/lib/Model/Subject/Subject.php#L152

from fatture-in-cloud-sdk.

IIRC the privateness was set on purpose to limit the visibility of the id and the client properties. I’m going to test (and possibly fix) this in the next days.

For the telephone number question, that “IT” should be only the default region when the number passed is not in an international format. However there’s no way to set a custom default region. I’ll track that down in another issue.

from fatture-in-cloud-sdk.

@alxy the undefined property error should be fixed in ab02ab7.
Can you confirm if it is correctly working?

from fatture-in-cloud-sdk.

I can confirm that this fixes the issue I was experiencing.

Prefixing the phone numbers with the international prefix (e.g. +49) does also solve the issue of wrongly parsed numbers. Thanks!

from fatture-in-cloud-sdk.

Hi, one more request: 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.

from fatture-in-cloud-sdk.

@alxy Can you please open a new issue for adding the Good interface under API?
I'm going to close this issue after that, as the original issue was fixed.

from fatture-in-cloud-sdk.

Sure, sorry for abusing this issue :)

from fatture-in-cloud-sdk.