Les droits de l'usager Acomba

S’applique àAcombaEntitésCustomerInvoiceCustomerOrderCustomerBidSupplierOrder

Le connecteur ouvre la société comme un usager d'Acomba — celui saisi dans les paramètres de connexion. Il hérite donc exactement de ses droits, module par module : ce que cet usager ne peut pas voir à l'écran, l'API ne le verra pas non plus.

La subtilité, et c'est tout l'objet de cette page : un droit manquant ne produit pas toujours une erreur. Il se manifeste le plus souvent par une extraction qui revient pleine d'enregistrements vides.

Où gérer les droits

1. Ouvrez la société concernée avec l'usager supervisor.
2. Onglet Société, bouton Usager.
3. Choisissez l'usager du connecteur dans la liste.

Ses droits s'affichent alors par onglet — un onglet par module d'Acomba.

Créer un usager, recopier des droits

Cette page traite de quels droits donner pour que l'API fonctionne. Pour la mécanique d'Acomba elle-même — créer un usager, importer les droits d'un autre usager, gérer les mots de passe — référez-vous à la documentation officielle d'Acomba, intégrée à votre logiciel.

Et rappel de la page de configuration : donnez ces droits à un usager dédié au connecteur (AgentExtract par exemple) plutôt qu'au compte d'une personne — voir Connecter et configurer Acomba.

L'onglet Facturation porte quatre entités

C'est le point qui fait perdre le plus de temps. Quatre entités de l'API sont, pour Acomba, des documents de facturation — et dépendent donc toutes du même onglet de droits :

Entité de l'API	Document dans Acomba	Où on le saisit dans Acomba
CustomerInvoice	Facture client	Facturation
CustomerOrder	Commande cliente	Facturation
CustomerBid	Soumission	Facturation
SupplierOrder	Achat	Inventaire > Achats

Un achat est un document de facturation

SupplierOrder se saisit dans Acomba sous Inventaire > Achats — on cherche donc naturellement ses droits du côté de l'inventaire ou des achats. C'est une fausse piste : pour Acomba, un achat est un document de facturation au même titre qu'une facture client. Ses droits sont dans l'onglet Facturation.

Le symptôme : des enregistrements vides, pas une erreur

Sans les droits de l'onglet Facturation, un GET /Entity/SupplierOrder répond HTTP 200, avec le bon nombre d'enregistrements — mais chaque enregistrement est à ses valeurs par défaut :

[
  {
    "NoUniqueSystemeSource": "0",
    "Référence": "",
    "Description": "",
    "DateFacture": "1899-12-30T00:00:00",
    "TotalFacture": 0.0,
    "NbLignes": 0
  }
]

Les trois marqueurs à reconnaître : les identifiants à "0", la date 1899-12-30 (la date zéro d'Acomba) et NbLignes: 0 sur des documents qui ont pourtant des lignes à l'écran.

Pourquoi le nombre est bon mais le contenu est vide : le connecteur parcourt d'abord l'index des documents pour savoir lesquels retourner — cette partie passe, d'où le compte exact. Il lit ensuite chaque document un par un, et c'est cette lecture-là qui est refusée. L'enregistrement reste alors à ses valeurs par défaut et ressort tel quel dans la réponse.

La règle de diagnostic

Des enregistrements vides en série = un problème de droits, pas un problème de données. Une extraction qui ne trouve réellement rien retourne une liste vide ([]), jamais des enregistrements remplis de zéros.

Corriger

1. Dans les droits de l'usager du connecteur, cochez l'onglet Facturation. Le plus simple est de cocher toute la branche, de valider que l'extraction revient remplie, puis de restreindre ensuite si votre politique interne l'exige.
2. Relancez la requête. Les enregistrements doivent maintenant être remplis.
3. Si l'extraction reste vide, redémarrez le service du connecteur : la société est réouverte, cette fois avec les droits à jour. Voir Démarrer, arrêter, mettre à jour l'agent.

Les autres modules

Le principe vaut pour tout Acomba : donnez à l'usager du connecteur les droits de chaque module que l'intégration touche. La lecture seule suffit tant que l'intégration se contente d'extractions (GET) ; il faut des droits de création et de modification dès qu'elle écrit (POST, PUT).

La correspondance exacte entre les autres onglets de droits (Paie, Comptabilité, Inventaire, Clients, Fournisseurs) et les entités de l'API n'est pas encore auditée. En cas de doute, le réflexe le plus rapide reste le même qu'ici : ouvrir Acomba avec l'usager du connecteur et vérifier qu'il voit bien à l'écran les documents que l'API doit extraire.

Voir aussi

• Connecter et configurer Acomba — l'usager, les chemins, le SDK.
• Erreurs Acomba — dont le code #225, Droits d'accès insuffisants, qui remonte quand Acomba refuse explicitement l'opération.