Le Forum des Utilisateurs Sage

[Simba][Simba ODBC Driver][CBase]Domaine de validité du champ incorrect, veuillez vous référer à la documentation.

Pour savoir si mes documents sont verrouillés je dois faire un update sur ceux-ci.
Je fais donc :
update F_Docentete set DO_Ref = 'xxxx' where DO_Piece = 'yyyyy' and DO_Type = 12
le document en question vient d'être créé par la gestion commerciale Sage.
Je comprends bien qu'il y a un problème sur un paramétrage, car cela fonctionnait avant et cela fonctionne sur Bijou, mais :
1) si le pilote ODBC trouve une erreur il pourrait donner un message plus clair.
2) quand la gestion commerciale créé un document, les contraintes définies dans le kit odbc pourraît valablement s'appliquer !
Alors je cherche ....
Ceci n'est pas une demande d'aide, mais plutôt un coup de gueule ...
Par moment cela fait du bien.

J'ai un peu avancé, enfin !
J'ai un problème avec DO_Tarif
Quand la Gestion commerciale créé les bons de commande, DO_Tarif est à 0 (alors que sur Bijou c'est bien à 1).
Malheureusement, s'il y a des lignes dans un doc, le kit Sage ODBC interdit de changer la valeur de DO_Tarif ...
Je ne suis donc pas beaucoup avancé.
Il me reste donc à trouver qu'est-ce que le client a changé sur son fichier pour que Sage me fasse des doc avec DO_Tarif à 0.
Ensuite il me restera à trouver une solution pour les documents déjà créé.
Je persiste, Sage est un peu léger sur son kit ODBC base propriétaire (c'est vrai qu'avec une base SQL, je passerai direct SQL pour contourner leurs erreurs).
edit :
Il s'agit bien sûr de commandes fournisseurs.
Sinon ce serait trop facile, il suffirait avec la gestion commerciale de changer la catégorie tarifaire. Pour un fournisseur ce n'est pas possible et cela n'a pas de sens.
Mais le pilote ODBC insiste et veut une catégorie tarifaire pour une commande d'achat.
Le fournisseur a une catégorie tarifaire à 0
Pourquoi ?
J'avance et je vous tiens informé.

J'avance à petits pas

Pour situer :
La base sur laquelle je suis en train de travailler n'a jamais vu un kit odbc de sa vie, c'est la première fois.
Toutes les données proviennent de la compta et de la gestion commerciale.
Je pars à chaque test de données anciennes "pur Sage" !

J'en suis où :
Le fournisseur est depuis sa création en 2005 avec une catégorie tarifaire à zéro.
Tous ses documents d'achat que j'ai pu trouver dans la base ont un DO_Tarif à 0
Comme le kit ODBC ne peut pas changer DO_Tarif quand il y a des lignes dans un doc !!!!

Je ne peux pas changer le N_CatTarif du fournisseur, car j'ai également le sublime message "Domaine de validité du champ incorrect".
Il doit y avoir autre chose dans ce fournisseur qui pose un soucis, je n'ai pas le courage de m'y attaquer pour le moment.
Si je ne peux pas changer les docs existants, je suis de toute façon sérieusement géné ...

Un petit moment de découragement à passer ...

Je peste quand même que le kit odbc perde son temps à vérifier des données qui sont déjà dans la base et qu'il m'interdit de changer.
Je ne sais si l'auteur n'est pas un peu tordu quand même !!!!

La seule solution que je vois est le passage en version SQL, mais ce n'est quand même pas neutre pour résoudre un bug

salut,
merci pour tes commentaires mais je ne comprends pas tes problèmes.
si tu lies le manuel tu comprendras parfaitement ce que l'obc te permet ou ne te permet pas.
l'obdc n'est que l' reflet du focntionnement de la gestion...ce que tu ne peux pas faire dans la gestion tu as pas bcp de chance de pouvoir le faire via l'odbc....

stephane3381 a écrit:... je ne comprends pas tes problèmes.
si tu lies le manuel tu comprendras parfaitement ce que l'obc te permet ou ne te permet pas.
l'obdc n'est que l' reflet du focntionnement de la gestion...ce que tu ne peux pas faire dans la gestion tu as pas bcp de chance de pouvoir le faire via l'odbc....

C'est pourtant clair, Sage Gestion commerciale a créé un fournisseur ayant une incohérence dans les données.
La Gestion commerciale peut créer des documents avec ce fournisseur sans aucun problème.
Sous ODBC ces documents sont non modifiables car le champ N_CatTarif est mal renseigné (il est à 0 et il devrait être à 1).
Je ne souhaite donc qu'une chose, pouvoir justement faire la même chose que la gestion commerciale qui peut modifier ce document sans problème.
Quand je dis Sage abuse, c'est que le kit odbc nous interdit de modifier l'entête parce qu'une valeur que nous ne changeons pas dans la requète est non valide, et que c'est un champ non modifiable puisqu'il y a des lignes.
Il n'y a donc aucune solution.
Je crois avoir fait le tour, et à part de créer de nouveaux documents qui soient la copie de ces docs, ces documents, créés par Sage ne sont pas modifiable via ODBC, ce qui me pose un problème.

Bonjour,

On pourra peut-être m'affubler de déterreur de topic, mais les faits sont là, et si j'ai subi les mêmes problèmes que Francis 2 ans plus tard, c'est peut-être lié au fait que Sage ligne 100 n'a pas beaucoup évolué... ?

Ma société édite un logiciel de traçabilité qui permet (entre autres) de préparer des commandes et de remonter les informations dans Sage (notamment les lots, numéros de série et un tas d'autres informations plus ou moins utiles selon les cas) et depuis près d'un mois, j'ai un client qui se plaint que certaines commandes ne passent pas dans le statut "à livrer" alors que mon soft indique "[Simba][Simba ODBC Driver][CBase]Domaine de validité du champ incorrect, veuillez vous référer à la documentation." et la requête incriminée est :

Code: Tout sélectionner

UPDATE F_DOCENTETE SET DO_STATUT=2 where DO_PIECE='PL29292' And F_DOCENTETE.DO_TYPE = 2

(On notera la précision du message d'erreur de Sage ligne 100 v14. Que ces messieurs se rassurent la v15 est tout autant laconique).

Après plus de 3h de recherches (éparpillées sur plusieurs jours), je trouve finalement le coupable : le champ DO_EXPEDIT de cette commande est à 0 !!

Loin de moi l'idée de cracher sur Sage ligne 100, qui est pourtant une Gestion commerciale très prisée et d'assez bonne qualité, mais là, je crois qu'il y'a du laisser aller !

1) Un message d'erreur laconique qui n'a pas évolué en plus de 2 ans
2) Une erreur qui surgit même quand vous ne touchez pas à la valeur erronée
3) Une erreur qui est faite par Sage Ligne 100 mais qui vous laisse croire que vous êtes le coupable
4) A aucun moment dans la gestion commerciale on a une alerte expliquant que le mode d'expédition de la commande est mal réglée.

S'il y'a des développeurs du kit ODBC de Sage qui lisent ces lignes, j'espère que vous saurez quoi améliorer dans la prochaine version (si une nouvelle version est prévue).

A bon entendeur !