Some informations are not customizable

Some infos, like the client, his address, his logo (...), are written directly in the component and can't been updated for another client. We need to make them cutosmizable (updating the model ?)

changed the description

To add some clarification here, what is missing is:

• author logo (here: Happy Dev logo)
• author contact informations (here: Happy Dev, 75 rue du Javelot, contact@happy-dev.fr)
• author company details (here: SIRET and TVA number)

Can we use the Customer table for this? Or should we create another one?

Another option is to configure the component directly with some options when inserted in the page

mentioned in commit bd3ba6f8

mentioned in merge request !23 (merged)

mentioned in commit ea30b8d6

@matthieu @Marjolaine There is also the IBAN number. But Happy Dev Paris doesn't really mind to receive all the money :)

I also would like to make a UP on this one because, we can only deploy it for Paris. So it can't benefit to other clients. And I'm directly interested to extend it to all Happy Dev cells. I'll see about funding with PO.

Related to the model structure, @jbpasquier may know better. Is there a place where all these informations can go? Or should we create a new table?

Can the IBAN go on the config.json file and so get used as an attribute of sib-invoicing? It would make things easier to configure.

Ok for me. So we would be doing the same for these informations?

• author logo (here: Happy Dev logo)
• author contact informations (here: Happy Dev, 75 rue du Javelot, contact@happy-dev.fr)
• author company details (here: SIRET and TVA number)

If you don't want to use ones from the client, yes.

By the way, how do you relate the identity to the invoice? Is it from the instance itself or from something else? Are invoices tied to a community by some manner? If so, you can host those information there and so keep an integrity between all clients.

Otherwise, if someone look at your invoice from another application, they'll not see your information but theirs instead.

Yes right, so I think the informations should be found in a community

yes for me, it makes sense to have all this informations in the community table and join invoices with the communities, no ?

assigned to @plup

@matthieu @jbpasquier @Marjolaine I think those informations require a more detailled ontology.

I my mind logo, address, email, SIRET, VAT number are relative to an organization or let's say a community to match what we alreay have. Whereas IBAN, BIC, overdue fees are relative to financial product.

I'd be happy to help but I don't know how we make changes to the ontology. Also it looks like a long shot where modifications are required on the community's LDP package and component. The client (myself) can't really deploy the component as it is and I'd like to have it quickly.

Would it be acceptable for the time being, to create an unrelated endpoint serving legal terms directly from the invoice endpoint and then passing it to the client config at build time ? I made a MR implementing this !44 (merged) Tell me what you think about it.

I think this is a nice addition to the component!

I made a few comments but it's only minor issues.