Comptabilité avancée : libellés dans les exports

yves57 · Octobre 24, 2016, 7:00

Bonjour,
[en bref] : dans le fichier d’export, le libellé indique un nom de rubrique du plan comptable inadéquat

[en détaillé]
J’ai inséré dans le plan comptable français de base des entrées personnalisées :
Par exemple
7061 : Prestations à 20%, sous la racine 706
7081 : Refacturation taxes, sous la racine 708
Lors de l’export depuis le journal des ventes (export standard ou CEGID), je retrouve pour les lignes ayant ces codes :
706100 <nom du client> - Facture 16-0093 - Descuentos sobre ventas por pronto pago de productos terminados
708100 <nom du client> - Facture 16-0093 - Sur ventes de produits finis
Je pense que c’est un bogue, à moins que j’aie mal paramétré qqch.
Faut-il que je crée un ticket sur github ?

aspangaro-Easya · Octobre 25, 2016, 5:16

Bonjour,

C’est effectivement un bug, le problème semble corrigé dans la 4.0, a vérifier.

Dans les paramétrages de la compta, il faut mettre le plan comptable espagnol puis aller dans le plan comptable pour supprimer les comptes ayant le même numéro puis ensuite revenir sur le plan comptable Français de base que vous utilisez.

Ne ventilé rien du tout entre temps sinon vous allez vous retrouvez à cheval sur deux plan comptables…

yves57 · Octobre 25, 2016, 7:31

C’est la version 4.0.0 que j’ai.
Faudrait-il la version 4.0.1 ?
J’ai déjà fait une ventilation, sinon, je crois que je n’aurais pas vu le problème. Donc je crains que la suppression des codes ne puisse se faire. Je vais quand même essayer.

yves57 · Octobre 25, 2016, 7:57

Merci pour ces conseils.
J’ai fait la manoeuvre. J’ai pu supprimer les codes litigieux du plan comptable.
Cependant, tous mes codes personnalisés ont disparu de la vue du plan comptable. Cependant, le libellé sur les lignes déjà ventilées est correct.
Faut-il que j’ouvre un ticket sur github ?
A bientôt

DHPM · Janvier 13, 2017, 8:30

Bonjour,
Le problème n’est pas corrigé dans la version 4.0.3
J’ai même désactivé le plan comptable espagnol et le bug est toujours présent.

darkjeff · Janvier 14, 2017, 8:54

Cela veut dire que des ventilations ont été faites avec le mauvais compte comptable (un compte comptable d’un autre plan)

dans le journal de vente le code est le suivant

$sql .= " LEFT JOIN " . MAIN_DB_PREFIX . "accounting_account as aa ON aa.rowid = fd.fk_code_ventilation";

Depuis la page ventilation client, le code prends bien en compte le plan comptable

$sql = "SELECT f.facnumber, f.rowid as facid, f.datef, f.type as ftype,";
$sql .= " l.fk_product, l.description, l.total_ht, l.rowid, l.fk_code_ventilation, l.product_type as type_l, l.tva_tx as tva_tx_line,";
$sql .= " p.rowid as product_id, p.ref as product_ref, p.label as product_label, p.fk_product_type as type, p.accountancy_code_sell as code_sell, p.tva_tx as tva_tx_prod,";
$sql .= " aa.rowid as aarowid";
$sql .= " FROM " . MAIN_DB_PREFIX . "facture as f";
$sql .= " INNER JOIN " . MAIN_DB_PREFIX . "facturedet as l ON f.rowid = l.fk_facture";
$sql .= " LEFT JOIN " . MAIN_DB_PREFIX . "product as p ON p.rowid = l.fk_product";
$sql .= " LEFT JOIN " . MAIN_DB_PREFIX . "accounting_account as aa ON p.accountancy_code_sell = aa.account_number";
$sql .= " LEFT JOIN " . MAIN_DB_PREFIX . "accounting_system as accsys ON accsys.pcg_version = aa.fk_pcg_version";
$sql .= " WHERE f.fk_statut > 0 AND l.fk_code_ventilation <= 0";
$sql .= " AND product_type <= 2";
$sql .= " AND (accsys.rowid='" . $pcgver . "' OR p.accountancy_code_sell IS NULL OR p.accountancy_code_sell ='' OR p.accountancy_code_sell NOT IN
	(SELECT aa.account_number FROM " . MAIN_DB_PREFIX . "accounting_account as aa , " . MAIN_DB_PREFIX . "accounting_system as asy  WHERE fk_pcg_version = asy.pcg_version AND asy.rowid = " . $pcgver . "))";
if (! empty($conf->global->FACTURE_DEPOSITS_ARE_JUST_PAYMENTS)) {
	$sql .= " AND f.type IN (" . Facture::TYPE_STANDARD . "," . Facture::TYPE_REPLACEMENT . "," . Facture::TYPE_CREDIT_NOTE . "," . Facture::TYPE_SITUATION . ")";
} else {
	$sql .= " AND f.type IN (" . Facture::TYPE_STANDARD . "," . Facture::TYPE_STANDARD . "," . Facture::TYPE_CREDIT_NOTE . "," . Facture::TYPE_DEPOSIT . "," . Facture::TYPE_SITUATION . ")";
}

donc le plus simple

faire une sauvegarde de sa base de donnée (toujours faire une sauvegarde avant)
vérifier que dans customer\list.php ligne 181 a 198 le code que j’ai mis au dessus correspond bien (cela permettra de bien ventiler dans le futur)
depuis ventilation client : cliquez sur « effacer les données comptables des lignes qui n’existent pas dans le plan comptable »
re ventiler les lignes

DHPM · Janvier 14, 2017, 9:21

J’ai supprimé les codes compta qui pose problèmes, dans le plan comptable espagnole et belge.
J’ai les bonnes dénomination maintenant.
Je vais essayer ta méthode.

Merci pour ta réponse.

DHPM · Janvier 29, 2017, 3:11

Le problème venait aussi du module d’export vers comptabilité qui ne prend pas les bons codes compta.
Je l’ai désactivé et j’utilise le module natif de dolibarr, export vers EBP… Et tous est rentré dans l’ordre. Ma comptable va être contente…

darkjeff · Janvier 29, 2017, 5:22

ça m’intéresse d’avoir un retour sur l’export EBP

je ne sais si quelqu’un dans le groupe de financement 2017 de la compta utilise l’export ebp
et on fait un point la semaine prochaine sur les exports

pour l’instant ce qui est sur c’est que
standard csv ou cado ok
cegid : ok
coala : ok
quadradus : ok

DHPM · Janvier 29, 2017, 5:40

J’utilisais le module en vente sur Dolistor, mais je l’ai désactivé car les export vers EBP étaient catastrophique… suite à une discution avec un de vos partenaire j’ai donc utilisé l’export natif vers EBP de Dolibarr, cela correspond au parfaitement au standard EBP.

cmaconception · Janvier 29, 2017, 6:17

Bonsoir,
Avez vous des retours pour l’export sous ciel ? Je n’ai pas encore eu le temps de tester ?

darkjeff · Janvier 30, 2017, 8:10

Oups désolé j’ai oublié de répondre

non pas de retour concret sur l’export ciel.

Actuellement je travaille sur une vue personnalisée du grand livre (nouveauté de dolibarr 4 avec le choix des colonnes)
dés que ça fonctionne je vais créer un modèle d’export dit « personnalisé » qui reprendra les colonnes choisis

Et pendant que j’y suis si les personnes qui lisent ce post ont 10 € HT a dépenser (ou plus ^^) on cherche du monde pour le groupe de financement 2017 : http://www.dolibarr.fr/87-actualites/243-lancement-financement-participatif-2017

cmaconception · Février 5, 2017, 10:13

Bonjour,
Je viens de tester l’export sous ciel compta, il m’indique une erreur dans le format de date. Je n’ai pas la possibilité de modifier le format d’import Ciel dans mon logiciel et, lorsque l’on choisi le format d’export ciel sous dolibarr, on ne peut pas accéder non plus aux options de réglages.

Pour info, le fichier en PJ est un fichier que génère ma gestion commerciale Ciel pour l’import sous ciel compta, si cela peut aider

Ma version de Dolibarr : 4.0.3

Merci pour vos suggestions

darkjeff · Février 5, 2017, 10:52

c’est dans le fichier accountancy\class\accountancyexport.class.php

ligne 299 a 330

j’ai deux dates
* date ecriture
* date operation

je peux configurer un format de date special, est ce que vous pouvez me confirmer que c’est bien sous la forme yyyymmdd

Sinon il faut passer en export standard, configurer le modèle de date, puis repasser sur l’export ciel

cmaconception · Février 5, 2017, 12:35

Évidemment, si j’oublie de joindre le fichier, c’est beaucoup moins parlant. Le voici.
Le format de date sur mon fichier est dd/mm/yyy, je n’ai pas accès aux paramétrages de ce format d’import dans mon logiciel.

Pièces jointes :

RImport.txt (12.2 KB)

cmaconception · Février 5, 2017, 1:13

J’ai réussi à modifier le format de date en ajoutant « / » malgré le message mais il ne reconnait pas le code débit/crédit à l’importation.

darkjeff · Février 5, 2017, 1:18

Bon on progresse (je changerai quand même le format de la date)

si je regarde le code, il doit y avoir une colonne « type montant » avec des « D » et des « C »

ciel ne donne pas d’explication pourquoi il voit pas crédit : debit ??

cmaconception · Février 5, 2017, 1:46

Non, ça démontre leur volonté d’ouverture
En revanche, j’ai accès au paramétrage des autres format d’import. J’ai alors 2 options : soit j’ai dans mon fichier une colonne Débit et une crédit, soit une colonne montant et une indiquant s’il s’agit de débit ou de crédit, et donc je dois construire une formule pour affecter ce montant en fonction de la valeur de cette seconde colonne.

La première option est plus à ma portée, je viens donc de tenter un export CSV avec séparation des champs par « ; » depuis Dolibarr ce qui semblerai fonctionner mis à part que j’obtiens 2 champs N°de compte.
Pour les comptes de charge, produit, client divers (411000) et fournisseur divers (401000), pas de soucis, seule le premier champs est complété.
En revanche pour les autre comptes de tiers personnalisé, (ex client), le premier champs est complété avec la valeur 411000 et le second avec le bon numéro de compte du client. Idem pour les fournisseurs.
J’ai tenté de modifier dans mon plan comptable en supprimant l’indication de racine de compte mais cela ne change rien.
Du coup, je me retrouve à ne pas pouvoir attribuer le bon numéro de compte à l’import.

cmaconception · Février 9, 2017, 8:16

Bonjour,
J’ai tenté quelques test et vérifications :
Sous Dolibarr, mes fiches clients et fournisseurs sont toute renseignées avec le bon compte comptable. Tous les comptes comptables sont crées dans mon plan comptable.
Lorsque j’enregistre les écritures dans le grand livre, toutes les écritures clients sont mises au 411000 et toutes celles des fournisseurs au 401000 dans la rubrique compte et les numéros de comptes personnalisés sont inscrits dans la colonne tiers.
Dans le journal des ventes et celui des achats, les numéros de comptes indiqués sont les bons.

Quelqu’un aurait-il une piste sur une erreur de paramétrage que j’aurais faite ?

Merci

darkjeff · Février 9, 2017, 8:21

C’est normal

en fonction de l’export choisis il remplacera les 401 / 411 par les comptes tiers

voici une liste des exemples d’exportation (ça tombe bien je l’avais expliqué au groupe de financement 2017 cette semaine ^^)
d’ailleurs on a une correction cette semaine sur l’export cogilog et suivant vos remarques je vais modifier l’export ciel

a) Export Standard (valable pour Cador)

2012016 gérance janvier 2016 (SI1601-0668) 40100000 FGEFFROY 0 1000 ACH
2012016 gérance janvier 2016 (SI1601-0668) 64400000
1000 0 ACH

b) Export Cegid

2012016 ACH 40100000 FGEFFROY C 1000 GEFFROY OLIVIER - gérance janvier 2016 - Tiers gérance janvier 2016 (SI1601-0668)
2012016 ACH 64400000
D 1000 GEFFROY OLIVIER - gérance janvier 2016 - Gerance gérance janvier 2016 (SI1601-0668)

c) Export Sage Coala

02/01/2016 ACH 40100000 1 gérance janvier 2016 (SI1601-0668) 0 1000 E FGEFFROY
02/01/2016 ACH 64400000 1 gérance janvier 2016 (SI1601-0668) 1000 0 E

d) Export Sage Bob 50 (a tester)

1 02/01/2016 F FGEFFROY 0 1000 GEFFROY OLIVIER - gérance janvie…
1 02/01/2016 G 64400000 1000 0 GEFFROY OLIVIER - gérance janvie…

e) Export ciel compta (a tester) format txt

1 ACH06022017020120161 FGEFFROY gérance janvier 2016 (SI1 1000C GEFFROY OLIVIER - gérance janvier O2003
2 ACH06022017020120161 64400000 gérance janvier 2016 (SI1 1000D GEFFROY OLIVIER - gérance janvier O2003

f) Export quadratus format txt

MFGEFFROYAC00006022017 gérance janvier 2016C+000000001000 000000 1 1 EURACH gérance janvier 2016 (SI1601-0661
M64400000AC00006022017 gérance janvier 2016D+000000001000 000000 1 1 EURACH gérance janvier 2016 (SI1601-0661

g) Export EBP

10803 2012016 ACH 40100000 40 GEFFROY OLIVIER - gérance janvier 2016 - 1 1000 C 2012016 EUR
10804 2012016 ACH 64400000 64 GEFFROY OLIVIER - gérance janvier 2016 - 1 1000 D 2012016 EUR

h) Export Cogilog (a tester)

ACH 2012016 1 40100000
GEFFROY OLIVIER - gérance janvier 2016 - Tiers 2012016
1000 gérance janvier 2016 (SI1601-0668) GEFFROY OLIVIER - gérance janvier 2016 - Tiers
ACH 2012016 1 64400000
GEFFROY OLIVIER - gérance janvier 2016 - Gerance 2012016 1000
gérance janvier 2016 (SI1601-0668) GEFFROY OLIVIER - gérance janvier 2016 - Gerance