Bonjour Fred,
La commande est à statut « validé » (ce qui est notre besoin car nous avons un trigger qui crée une commande dans notre logiciel lors de la validation d’une commande).
J’ai tout de même essayé en mettant la commande à l’état brouillon, mais sans succès …
Est ce que vous avez aussi ce blocage en faisant une requete manuelle via l’explorer de l’api rest ?
Bonjour , oui on a ce bug que ce soit en php ou dans l’explorer, comme le montrent les captures du post #98755…(page 5) 
ne cherchez plus, dans la function update de commande.class.php il manque la gestion des extrafields…
// Actions on extra fields
if (empty($conf->global->MAIN_EXTRAFIELDS_DISABLED)) // For avoid conflicts if trigger used
{
$result=$this->insertExtraFields();
if ($result < 0)
{
$error++;
}
}
Bonjour,
Nous recherchons un développeur freelance expert Dolibarr qui peut nous ajouter rapidement cette fonctionnalité qui nous bloque actuellement.
Merci de m’envoyer vos contacts sur cette adresse [email protected].
je vais faire un test d’ici lundi en rajoutant les bouts de code manquant identifier au dessus… je vous tiens au courant
Ok merci d’avance !
en v8 c’est corrigé on trouve bien le code
if (! $error && empty($conf->global->MAIN_EXTRAFIELDS_DISABLED) && is_array($this->array_options) && count($this->array_options)>0)
{
$result=$this->insertExtraFields();
if ($result < 0)
{
$error++;
}
}
fichier commande.class.php, ligne 3070 en V8, un peu plus loin en V7
Bonjour
C’est une très bonne nouvelle. Merci pour votre retour.
Pouvez vous nous préciser où nous pouvons récupérer cette nouvelle version?
Je viens de tester avec la version 8.0. Effectivement les extrafields sont traités mais, gros souci, lors d’un update de commande, la fonction appelée est « insertExtraFields() » qui vide la table et insere les champs postés…! On perd donc tous les champs qui n’ont pas été mis à jour…
vu dans le fichier commonobject.class.php ligne 4926
Je vois qu’il y a pourtant bien une function « updateExtraField() »… N’est-ce pas celle-là qui devrait être appelé lors de l’update d’une commande 
?
Qu’en pensez-vous ?
qu’il faut composer, comme avec le reste de l’API :
- passer toutes les valeurs lors de l’update
- activer si ce n’est déjà fait le module des logs et TOUJOURS REGARDER CE QU’IL SE PASSE EN BASE DE DONNÉES QUAND ON UTILISE L’API REST
- toujours !!! cela vous fera gagner des jours de développement 
Euh… merci pour ces précieux conseils mais j’ai évidemment la bdd ouverte en parallèle et je ne vois pas en quoi ça change le problème …
ça ne change pas le problème, ça permet de tout de suite de le détecter et en général, il est du côté de l’API… pardon… mais il y a beaucoup à faire encore sur cette API…
En effet, il y a beaucoup à faire encore au niveau de l’API mais elle a le mérite d’exister (c’est un travail en cours) 
En parlant de l’API, j’ai mis à jour mon Dolibarr vers la version 8.0 et j’ai vu les nouvelles fonctions liées à Stripe notamment la possibilité de lier un client Stripe à un Tiers Dolibarr. En creusant un peu, j’ai vu que c’était stocké en BDD dans la table llx_societe_account.
Une idée de comment indiquer l’identifiant client Stripe lors de la création/modification d’un tiers en utilisant l’API ?
Pour répondre à tonio79 (message #99430), pour moi, c’est correct.
En effet au sens REST strict, la méthode PUT met à jour une entité de façon complète tandis que la méthode PATCH permet de ne mettre à jour que les champs spécifiés tout en ne touchant pas aux autres champs de l’entité.
Pour répondre à mon précédent message #99729, il semblerait que cela ne soit pas géré pour l’instant.
J’ai vu la Pull Request suivante sur Github https://github.com/Dolibarr/dolibarr/pull/9016/files qui ajoute la gestion des RIB (donc stockés dans la table llx_societe_rib).
Je vais sans doute essayer de m’en inspirer pour ajouter la gestion des Interfaces de paiement dans [code]
htdocs/societe/class/api_thirdparties.class.php[/code
Bonjour,
Je souhaite pouvoir générer des documents via l’API. (En l’occurrence une proposition commerciale, mais ce pourrait être un autre objet).
En suivant la méthode appliquée dans ce post : #85676, je parviens à mes fins. Mais la solution ne me convient pas, car elle impose de modifier le fichier natif api_proposals.class.php.
J’ai donc tenté de faire ce que la doc suggère :
J’ai copié, le fichier /htdocs/modulebuilder/template/class/api_mymodule.class.php comme /htdocs/comm/propal/class/api_mymodule.class.php
Puis y ai inclu ma méthode generatedocument (celle qui fonctionne lorsqu’elle est dans la classe Proposals native). La méthode s’affiche bien dans l’explorer :
GET /mymoduleapi/generatedocument/{id} (si je ne mets pas d’annotation @url)
mais j’ai une erreur 501 API not found (failed to include API file) lorsque j’essaye d’y accéder.
J’ai tenté plusieurs options (changé la méthode, mettre une annotation en entete de classe, sans succès…)
Quelqu’un aurait-il une solution à me proposer ? Une exemple de module custom serait bienvenu…
Merci d’avance…
Bonjour,
L’API permet de générer de façon standard les différents documents (que ça soit des factures ou des propales).
Regardez du côté du endpoint
PUT /documents/builddoc
Pour une propale, vous devez indiquer proposal ou propal pour module_part et le doctemplate par défaut est azur. Pour le original_file, c’est de la forme REF/REF.pdf donc par exemple PR1808-0001/PR1808-0001.pdf
Merci pour la réponse, mais si ce document n’est pas encore créé, comment puis-je faire : je ne peux pas remplir le champ original_file
C’est pour cela que je voulais passer par une action custom.
