Bonjour à tous,
Je cherche un facture d’acompte via l’api de Dolibarr.
J’utilise avec succès l’api sur des commandes en faisant un GET avec sqlfilters = t.ref=‹ maref › MAIS impossible sur les facture y compris les acomptes, pourquoi ?
L’erreur est la suivante :
« code »: 503,
« message »: « Service Unavailable: Error when retrieve invoice list : Unknown column ‹ t.ref › in ‹ where clause › »
Ce message semble dire que la colonne t.ref n’eixste pas !!?
Une idée ?
Merci beaucoup.
Dolibarr 9.0.1 / ubuntu server 18.04
Je me réponds après un bon moment de recherches diverses :
Il ne faut pas utiliser t.ref dans sqlfilters MAIS t.facnumber !!!
Information trouvée dans la méthode create de la classe Facture. 
Dans Dolibarr V10 c’est t.ref
A purée, c’est vrai ?! 
Pourquoi ce changement ?
Étrange pour la compatibilité ascendante… 
Mais surtout merci pour l’info.
Salut reynald,
historiquement, les tables ont été développées de manière non homogène, dans le sens où un même champs, ayant une même utilisation pouvait s’appeler « t.facnumber » parfois et dans une autre table « t.ref » ou « t.toto »…
depuis quelques versions les dev essaient d’uniformiser tout cela pour rendre le système plus cohérent.
et dans le même temps, ils font le « ménage » dans le code.
D’où ce renommage de certains champs. (ça a déjà été abordé dans plusieurs post, mais je ne sais plus lesquels, fait des recherches sur le forum si tu es curieux 
)
Pour la compatibilité ascendante : pas de problème : le code le prend en compte et chaque mise à jour fait suivre à la fois les modifs de la base et les modifs du code (à un petit raté récent en V9 dans les journaux comptables, mais qui a été corrigé dans la foulée par une version de maintenance)
Ceux qui se font le plus de cheveux blancs avec ça, c’est les développeurs de modules tiers, qui doivent contrôler la version de dolibarr et adapter leur requête en fonction…
Mais bon, c’est un mal pour un bien : la solution tant vers plus d’homogénéité et plus de stabilité ainsi
1 « J'aime »
Bonjour Arre, ou re…
Je comprends, et oui c’est bien que le code soit assaini, mais comme j’ai développer un module de communication avec woocommerce pour mon propre usage, du coup ça m’inquiète un peu.
L’idéale serait que le code de Dolibarr tienne compte de ces nouveaux changements et corrige les requêtes de type cUrl par exemple automatiquement.
Ainsi la bdd aurait le nouveau nom de champ, le code natif utiliserait ce nouveau nom de champ en vérifiant que l’ancien nom ne soit pas utilisé et que la correction soit faite dans ce code natif dans ce dernier cas 
.
