Salut.
Expérimentation avec le «code groupe» des fichiers d'importation :
Dans le fichier CSV : deux opérations différentes (deux lignes), deux
dates différentes, même «code groupe».
—> crée deux opérations, à leurs dates respectives, reprenant chacune
les deux opérations; donc deux opérations identiques et erronées.
Proposition:
— Outre la suggestion de ne pas se planter dans les «codes groupes»,
pourrait-on imaginer plutôt que l'usage du «code groupe» ne serve qu'à
rassembler différentes opérations (lignes) qui ont la même date en une
seule opération, et donc que, à partir du moment où deux lignes ont des
dates différentes, QUAND BIEN MÊME ELLES ONT LE MÊME «CODE GROUPE», deux
opérations différentes soient créées.
Ça permettrait de ne pas devoir se soucier du «code groupe» à partir du
moment où les dates sont différentes, hormis, dès lors, quand deux
lignes à la même date doivent être réunies en une opération.
Dans le cas, par exemple, d'opérations d'achat répétitives à des dates
toutes différentes avec de nombreux articles, toute la colonne «CG»
pourrait être remplie de «0» (ou autre code, ou vide) puisque les dates
différencieraient les opérations différentes et que toutes les lignes à
dates identiques – donc appartenant à la même opération dans cet
exemple-ci – seraient automatiquement réunies par le code (identique
pour toutes les lignes, donc celles à date identique également). Si deux
opérations différentes devaient avoir eu lieu le même jour, alors
seulement à cet endroit les «0» du «CG» devraient être remplacés par un
autre code aux lignes correspondant à la seconde opération pour
différencier les deux opérations.
Quels seraient les inconvénients, si d'aucun, d'un tel fonctionnement?
— Si le comportement n'est pas modifié, alors afficher un message
d'erreur quand des lignes ont des dates différentes pour un même «CG»
afin d'éviter l'erreur de «fusion».
Qu'en dites-vous?
y
Dany De Bontridder via noalyss-generale:
Salut,
Le 6/18/21 à 2:26 PM, ydc a écrit :
Salut.
En tentant d'importer avec l'«importation avancée», tout roule excepté
un message d'erreur concernant le journal.
J'ai essayé avec le nom du journal, avec son code interne... «Aucun
journal trouvé [ACHATS]».(...)
Je ne peux pas dire comme ça, tu pourrais aller voir dans IMPOP2 ,
paramétrage pour voir à quel journal correspond ce code ACHATS ?
Aussi, pour un dossier non assujetti, est-il possible de faire une
version simplifiée en laissant les colonnes «code TVA» et «montant HTVA»
(ou celle «montant TTC») vides? Ou doit-on mettre le même montant dans
les deux et un «NOTVA» (selon l'exemple) dans le colonne «code TVA»?
Non tu utilises simplement le code 4 , "aucune tva applicable ", en
interne, on sauve toujours un code TVA "0% non applicable " pour les
dossiers des non-assujettis , donc est d'utiliser ce code. Je ne suis
pas fermé à ce quelqu'un propose un patch pour le cacher dans l'import (
code source est ici https://gitlab.com/noalyss/advancedimport sous
GNU/GPL) ;
Et donc les montants HTVA et TTC sont évidemment identiques, le montant
de la TVA est la simple différence entre ces 2 montants , en faisant
ainsi on évite les problèmes d'arrondi ,
Le code est ici dans la fonction |Impacc_Csv_Sale_Purchase->|record
https://gitlab.com/noalyss/advancedimport/-/blob/master/class/import/impacc2_csv_sale_purchase.class.php
Bon week-end à toi aussi :-)
D.
---
NOALYSS est un Serveur de Comptabilité et de Gestion libre
NOALYSS is an ERP Server opensource focused on accountancy
Gérer votre abonnement https://lists.nongnu.org/mailman/listinfo/noalyss-generale
---
NOALYSS est un Serveur de Comptabilité et de Gestion libre
NOALYSS is an ERP Server opensource focused on accountancy
Gérer votre abonnement https://lists.nongnu.org/mailman/listinfo/noalyss-generale
