Je ne connais pas personnellement ni professionnellement cette société, elle est gros contributeur Dolibarr, effectivement sur l’ensemble des présentations des modules il y a la ligne concernant la relève des courriels, il y a également les précisions de support, contrairement à d’autres modules sur le Dolistore au moins il y a un minimum de support, une explication claire sur la procédure pour les contacter etc…
Concernant le module d’import bancaire, en recherchant un peu sur le forum vous auriez vu qu’il y avait un certain nombre de personne déçues par ce module, il y a deux versions sur le Dolistore peut être que la version 2 est mieux, je ne sais pas je n’ai pas eu l’occasion de la tester, sinon il y a sans doute une procédure pour le « remboursement » du module si il ne vous convient pas, à voir avec le Dolistore et/ou directement la société, mais comme il fonctionne avec une banque et pas une autre voir peut être aussi au niveau de la banque qui ne fonctionne pas pour qu’elle fournisse un csv correct.
Société Générale:
DATE1;DATE2,Libellé;debit;credit
Ce sont les CRLF qui perturbent le fichier
pourtant le fichier du CA est bien conforme ,
car un texte entre" est considéré comme du texte, donc les CRLF aussi
Il me semble que dans la configuration du module, vous avez un champs pour permettre de selectionner la liste des champs et ainsi de faire correspondre le format di fichier au element attendu par le module
Bonjour,
le problème n’est pas dand la liste des champs importés ,
mais dans le traitement du fichier CSV du Crédit Agricole
qui inclut des CR(Carrier Return)et LF’(Line Feed) entre des "
ex : « libelléCRLFlibellé CRLF »
normalement, çà devrait être considéré comme du texte.
C’est un bug dans votre import de fichier CSV (de mémoire CA) car comme vous l’avez dis avec un autre import (de mémoire SG) ça fonctionne.
Effectivement sans doute pour certain import il faut les préparer, je pense également au module natif d’import de Dolibarr le problème peut être le même, si l’on ne donner pas un fichier correct effectivement l’application ne peut pas le lire à moins d’avoir une partie conversion intégré, mais dans ce cas là comme le dit ksar il faut effectivement un développement supplémentaire et donc ça a un coût.
Comme déjà dit plus haut, ATM est un très gros contributeur à Dolibarr. Ils jouent le jeu, ont leurs modules disponibles et, in fine, le produit livré est tout en sources. Puisque vous avez été dans l’informatique, vous comprendrez que nous parlons de logiciel libre. Vous contribuez à la vitalité économique de Dolibarr et des sociétés qui œuvrent souvent (voire très souvent) bénévolement dans l’intérêt général.
Concrètement, il me semble que vous avez plusieurs solutions :
- Demandez comme proposé le remboursement ;
- Regardez le code source du module et comprendre pourquoi, dans votre cas, ça ne marche pas. Pour ce faire, activez le module syslog, puis mettez des traces avec dol_syslog() et regardez dans la console de debug de votre navigateur ce qui se passe) ;
- Rémunérer ATM pour faire ce travail à votre place.
Dans les trois cas, votre liberté est respectée. Peut-on en dire autant concernant les éditeurs de logiciels de gestion ‹ privateurs › ?
Si ça ne suffit pas, je vous suggère également de demander aux habitués du forum et qui utilisent ce module un modèle de CSV bien accepté par ce module…
Bonjour,
Dans la définition habituellement admise d’un fichier CSV, les caractères de fin de ligne sont interprétés comme le fin de l’entrée. Les champs sont séparés par de virgules, et la fin de ligne est le début d’un nouvel enregistrement.
Ici, tu nous indiques que le fichier comporte des champs INCLUANT des caractère de fin de lignes. Même si le créateur de ce fichier le fournit comme étant du CSV, ce n’est pas le cas.
Que le module d’ATM ne sache pas le lire ne me surprend pas. Tu lui demandes des choses qui ne font pas partie du périmètre a priori.