Re: [tryton-fr] Export FEC
Le 21/09/2018 à 09:50, 'Cédric Krier' via tryton-fr a écrit :
7. Test des dates:
Le fichier n’est pas trié par date de validation.
Le fichier est trié par numéro de postage, ce qui me semble est la
demande au point II.40 dehttp://bofip.impots.gouv.fr/bofip/9028-PGP.html
« Au sein de ce fichier, les écritures doivent être numérotées
chronologiquement de manière croissante, sans rupture ni inversion dans
la séquence. »
Par contre normalement, l'ordre des numéro de postage devrait aussi être
l'ordre de la date de validation puisqu'il y a une séquence unique. Sauf
s'il y a eu manipulation.
J'ai encore pas mal d'erreurs ici...
selon
https://www.impots.gouv.fr/portail/files/media/1_metier/2_professionnel/comptabilite_informatisee_question_reponse.pdf?#page=8=50
réponse Q12:
En application du VII de l’article A. 47 A-1 du LPF et conformément au premier
alinéa du I de
l’article L. 47 A de ce livre, l’ensemble des données comptables et des
écritures retracées
dans tous les journaux comptables au titre d’un exercice est remis dans un
fichier unique,
dénommé fichier des écritures comptables, dans lequel les écritures sont
classées par ordre
chronologique de validation.
j'ai remarqué que le code:
return Line.search(
domain,
order=[
('move.post_number', 'ASC'),
])
ne marche pas correctement au cas de changement de pré/post fixe et/ou la
numérotation
ou bien dans le cas d'importation de la compta depuis un autre système (comme
openerp)
où le post_number peut être par journal...
Ce qui semble mieux fonctionner pour tous ces cas là aussi:
@@ -270,6 +270,7 @@ class AccountFrFEC(Wizard):
return Line.search(
domain,
order=[
+('move.post_date', 'ASC'),
('move.post_number', 'ASC'),
])
cordialement,
--
Richard PALO
--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes
tryton-fr.
Cette discussion peut être lue sur le Web à l'adresse
https://groups.google.com/d/msgid/tryton-fr/2fef955e-0f3c-6cbd-f202-b91b024c5515%40free.fr.
Re: [tryton-fr] Export FEC
Le 03/05/2017 à 11:06, Cédric Krier a écrit : - Au moins un enregistrement dans le FEC ne contient pas de valeur pour le champ PIECEREF => remettre "EcritureNum" lors qu'on a rien à mettre en PieceRef? C'est le cas de toutes les mouvements comptables que je saisis manuellement (opérations diverse, charges saisies sans facture fournisseur, etc.) Je propose de faire comme Odoo et de mettre '-'. Selon expert-fec (lefebvre) d'utiliser le '-' génère un point d'anomalie : Colonne n°9 dénommée "PieceRef" (devant être au format AlphaNumérique et devant toujours être remplie, se reporter aux questions/réponses n°1-18) : détection de 9142 anomalies de format du contenu dont : - 9142 cellules (champs) ne contenant que des espaces ou des caractères spéciaux alors que cette colonne devrait toujours contenir des données (fichier .xls) (fichier .csv) (cette colonne ne peut ni être à blanc ni remplie de caractères ne correspondant pas à des données). Pour information : - Le champ dans le FEC "PieceRef" devrait contenir la référence de la pièce justificative et devrait correspondre soit à une numérotation séquentielle des pièces comptables dans le système, soit à la référence figurant sur les pièces justificatives (se reporter au BOI-CF-IOR-60-40-20 n°180) - Nombre de cellules remplies : 25483 (sur 25483, soit 100%) - Nombre de cellules vides ou sans données : 0 (sur 25483, soit 0%) - Liste des caractères de la colonne n°9 : " &-./0123456789ABCDEFHIJKLMNOPQRSTVW[]adehkortuvx" - Liste des valeurs utilisées dans cette colonne : "-", et cetera... Peut-être un expert-comptable ou commissaire-aux-comptes pourrait nous suggérer une autre valeur... En tout cas, apparemment cette valeur devrait probablement se trouver dans le fichier config, tout comme fec_opening_* cordialement, -- Richard PALO -- Vous recevez ce message, car vous êtes abonné au groupe Google Groupes tryton-fr. Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/tryton-fr/5554c72c-c41f-7e91-edd0-7bd6db072c09%40free.fr.
Re: [tryton-fr] Export FEC
Voici un lien intéressant "Les logiciels de contrôle du FEC": https://www.compta-online.com/les-logiciels-de-controle-du-fec-ao3498 notamment un autre site de contrôle gratuit: Veryfec.com : un logiciel qui complète l'outil de la DGFIP Ce logiciel de contrôle du FEC est proposé par l'association Fidepros, une association d'experts-comptables. S'il n'a pas vocation à remplacer le logiciel de l'administration fiscale, il le complète pour mettre en avant des anomalies ou points d'attention. L'utilisateur envoie son FEC sur le site internet et complète un formulaire pour affiner l'analyse. Seuls les résultats anonymes des contrôles sont conservés. Le FEC ainsi déposé sur le site internet est détruit dès la fin des tests. -- Richard PALO -- Vous recevez ce message, car vous êtes abonné au groupe Google Groupes tryton-fr. Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/tryton-fr/8ff6a1a0-c84a-c6d7-7677-032076fc70df%40free.fr.
Re: [tryton-fr] Export FEC
Le 21/09/2018 à 09:50, 'Cédric Krier' via tryton-fr a écrit : On 2018-09-21 09:05, Richard PALO wrote: Voici un extrait bref et sélectif de quelques anomalies que nous avons rencontré: C'est bien dommage que ce soit bref, ça ne va pas trop aider à faire des corrections. Ce message était principalement pour faire part de l'adresse du site. Nous sommes en train de trier et traiter le détail afin de bien déterminer les anomalies et points d'alertes directement liés à la plateforme à mettre sur bugs.tryton.org. Il n'y a rien qui bloque d'autres utilisateurs à effectuer des essais approfondis aussi... -- Richard PALO -- Vous recevez ce message, car vous êtes abonné au groupe Google Groupes tryton-fr. Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/tryton-fr/95ff636a-8688-4cda-328a-d371d549c940%40free.fr.
Re: [tryton] third-party and self-billing
Le 20/07/2018 à 19:26, Richard PALO a écrit : What I see as really different here, at least in France, is that the invoice sequencing probably should be clearly distinct (http://bofip.impots.gouv.fr/bofip/140-PGP.html paragraph 100) oups... and paragraphs 120-130 -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton/1a579b10-4b7e-6e77-411b-084abfaa3356%40free.fr.
Re: [tryton] third-party and self-billing
Le 20/07/2018 à 18:13, Cédric Krier a écrit : On 2018-07-20 16:48, Richard PALO wrote: I'm curious if somebody has already come up with a third-party and self-billing (autofacturation) module for tryton. This should be relatively trivial, but it would be nice to save some cycles if already done. I'm not sure there is anything to do for self-billing. It is just about creating the supplier invoice yourself. I'm not sure what you mean by third-party. But a sale order can already have 2 different parties. One for the invoice and one for the shipment. But maybe you want to refer to the practice of billing another party than the original one. But I guess it can be managed with a specific invoice address. An example of third-party billing is when a supplier (of goods or services) out-sources their invoicing. I have alluded before to the absence of the third-party in the party model. There may be third parties involved for such as billing, shipping, payments and certainly others. Another example might be where a company (X) is mandated by a consortium (where X may or not be a member) to manage sales and/or purchases ... either all, or on a projet basis. What I see as really different here, at least in France, is that the invoice sequencing probably should be clearly distinct (http://bofip.impots.gouv.fr/bofip/140-PGP.html paragraph 100) As for self-billing, I agree it is relatively simple, but there does need to be the mandatory indication for it... this could be done as a flag on the invoice such that the report can add the necessary text. In France, 'Autofacturation' needs to be clearly indicated (for example, under the invoice number). For both, it is probably more than useful to manage the mandates permitting self- and third-party billing is it is generally a required prerequisite to have a formally signed, written mandate. Especially so if an audit occurs. (BTW: 'shipment' is only pertinent for sales of goods, not really so for services) -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton/c3d30e7b-a0d9-fb2a-302e-216c99b35ed9%40free.fr.
Re: [tryton] sao and comma decimal separator
Le 22/06/2018 à 09:35, Cédric Krier a écrit : On 2018-06-22 08:42, Richard PALO wrote: Le 22/06/2018 à 08:31, Richard PALO a écrit : How to get SAO client data entry to accept numeric keypad decimal as comma which seems to be required for debit/credit entries? I'm using French locale. No problem in standard client. Thought I would double check with chromium and surprisingly there it *is* converted to a ','. So to rephrase the question, how to turn this on with mozilla firefox? You should ask Firefox to support it: https://bugs.tryton.org/msg36685 Well, this may be over simplistic, but noticing this https://stackoverflow.com/questions/24407109/new-webkits-convert-decimal-comma-to-dot-and-vice-versa-in-number-type-inputs and trying https://codepen.io/anon/pen/xDvCB?editors=100 I notice that I can use the keypad decimal just fine in the fox and chromium/vivaldi. I can also use the standard keyboard ',' (or '.' for that matter) Is there perhaps something fudging things up in an intermediate layer? -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton/072fee7d-1bde-7a99-6117-afce601accfd%40free.fr.
Re: [tryton] sao and comma decimal separator
Le 22/06/2018 à 08:31, Richard PALO a écrit : How to get SAO client data entry to accept numeric keypad decimal as comma which seems to be required for debit/credit entries? I'm using French locale. No problem in standard client. Thought I would double check with chromium and surprisingly there it *is* converted to a ','. So to rephrase the question, how to turn this on with mozilla firefox? -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton/fc9a629d-9d3a-1d9b-979f-b424a963dc7c%40free.fr.
[tryton] sao and comma decimal separator
How to get SAO client data entry to accept numeric keypad decimal as comma which seems to be required for debit/credit entries? I'm using French locale. No problem in standard client. -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton/2dbd6fd6-7a28-cb90-3177-6ef08bc4704e%40free.fr.
Re: [tryton] Re: [tryton-fr] Handling of returns/cancelations
Le 08/04/2018 à 09:41, Richard PALO a écrit : For info, https://bugs.tryton.org/issue5180 has been updated with an initial patchset proposal supporting an 'allow_negative_moves' configuration parameter. Perhaps this should be alternately named 'allow red storno moves' as that seems to be a recogniseable term used for this, particularly in eastern europe where it is widely used. try entering 'accounting red storno' in your favourite internet search engine. It seems typically that western accounting packages need to have an option enabled to permit negative moves as I propose above and, if used, the negative moves are even marked up in red, as the name suggests. -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton/1795bd94-2573-a037-a529-058dceaa6918%40free.fr.
Re: [tryton] Using different credit and debit accounts on statement journal
Le 01/06/2018 à 18:39, Richard PALO a écrit : As far as our usage goes (using account_fr), the only journal having differing accounts for debit/credit is the closing journal which is a [special] situation, not a statement, journal. Should probably mention that since the debit/credit accounts are requested in the "Balance non-deferral" assistant, they seem not even required in our closing journal at that. cheers, -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton/7934f330-598d-a268-04e8-548b12c9eb60%40free.fr.
Re: [tryton] Using different credit and debit accounts on statement journal
Le 31/05/2018 à 10:28, Sergi Almacellas Abellana a écrit : Hi All, We are moving the accounts used by statement journal from the accounting journal to the statement journal [1]. This avoids the need to create a different statement journal to use different accounts on the statement. During the review of this change [2] we thought about merging the credit and debit accounts into a single account and use one unique account on bank statement as we nmormally use the same account on both options. Is anybody using different debit and credit accounts to import their statements? Or everybody is using the same account as us? Your feedback will be much appreciated. Thanks in advance. [1] https://bugs.tryton.org/issue7450 [2] https://codereview.tryton.org/50391002/diff/20001/journal.py#newcode48 As far as our usage goes (using account_fr), the only journal having differing accounts for debit/credit is the closing journal which is a [special] situation, not a statement, journal. cheers, -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton/18bf74e3-8cf8-3e1a-854a-4fb127e63671%40free.fr.
Re: [tryton-dev] Move origin issue when in same period
Le 08/05/2018 à 19:56, Cédric Krier a écrit : The origin must be saved before being assigned if you want to store the saved id. I submitted https://bugs.tryton.org/issue7421 to prevent the exception raising. Ok, I'm trying the following, based upon what I see e.g. in modelstorage.py: if move_origin.id is None or move_origin.id < 0: move_origin.save() # work-around for same period origins new_move.origin = move_origin This should keep use of save() down to the handful of cases where id is actually < 0 BTW, why does save(), for example on a move, automatically save() its lines? Is the problem because origin is unidirectional? -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton-dev" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton-dev/0f71a0b0-c227-606b-94c0-5863c58658e8%40netbsd.org.
[tryton-dev] Move origin issue when in same period
I came across a difficulty noticed during FEC generation (French plan) where I get the following exception: ... File "/trytond/modules/account_fr/account.py", line 315, in get_reference return line.move.origin.rec_name AttributeError: 'str' object has no attribute 'rec_name' To briefly explain the issue, it concerns a reversal entry having origin set to the initial entry at the same date (ie:cancel). As these entries are bulk loaded via an openerp2tryton migration script, Move.save() is invoked for all the moves in the period, period by period. What I notice is that the origin saved in the database is "account.move,-272790" so I presume the error is related to the fact that the referenced move is not yet saved when the origin was set, even though when really saved, the origin move will have been saved. Indeed, all the moves where the reversal entry is in a different period have the origin with a non-negative number, with no problem during FEC generation. It concerns only the moves generated in the same period for this scenario. So the question I pose, without resorting to individual saves on the moves which would probably have disastrous timing repercussions on the import (>35K moves), is there perhaps an outside chance that something is forgetting to verify the state (.reload()?) of the origin move prior to saving? Any other suggestion(s)? If needed, I can probably provide a proteus test script demonstrating the problem. -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton-dev" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton-dev/a3bd28c5-d59e-f70b-c959-ae12474e5d40%40netbsd.org.
Re: [tryton-fr] Export FEC
Le 07/05/2017 à 19:19, Richard PALO a écrit :
Le 20/04/2017 à 15:33, Cédric Krier a écrit :
Bonjour,
En corrigeant l'issue6435, j'ai remarqué que l'export FEC n'était pas
tout à fait conforme. Du coup, j'ai créé l'issue6451.
J'en ai profité pour ajouter un scenario de test pour l'export FEC mais
j'aimerais quand même avoir une confirmation sur la validité du format
qu'on génère. Pour cela, je recherche quelqu'un qui a une comptabilité
Française sur Tryton et qui pourrait tester avec les deux patches un
export FEC. Il y a un utilitaire de vérification fournis par la
direction générale des finances publiques qui ne fonctionne que sous
Windows:
http://www.economie.gouv.fr/dgfip/outil-test-des-fichiers-des-ecritures-comptables-fec
https://bugs.tryton.org/issue6435
https://bugs.tryton.org/issue6451
Merci,
Un environnement M$Windoze sous VirtualBOX semble tourner ce programme
convenablement...
Toutefois, je n'arrive toujours pas générer un FEC si l'exercice
n'est pas clos (https://bugs.tryton.org/issue5306)
bien cordialement,
Pour info, il n'est plus vraiment nécessaire d'avoir un poste M$Windoze ni Vbox
installé.
Après `git clone` de https://github.com/DGFiP/Test-Compta-Demat
il n'était pas trop compliqué pour faire tourner nativement sous *nix...
d'abord: assurer que tous les modules perl requis sont bien installés (SQlite,
PDF:{API2,TABLE}, ...)
puis: cd Test-Compta-Demat; chmod +x src/testeur/trt_txt.pl; export
PERL5LIB=$(realpath src/testeur)
finalement: perl src/testeur/init.pl
Cordialement,
--
Richard PALO
--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes
tryton-fr.
Cette discussion peut être lue sur le Web à l'adresse
https://groups.google.com/d/msgid/tryton-fr/fe06ed10-b918-ad33-5dbd-99418e6fbd14%40free.fr.
Re: [tryton-fr] FEC et l'équilibrage des non-reports avant clôture
Le 01/05/2018 à 10:07, Richard PALO a écrit : Je me pose la question sur la validité du FEC généré contenant les écritures d'équilibrage des non-reports avant clôture. Par exemple, j'utilise le journal CLO - Journal des écritures de clôture pour les non-reports, et le journal RAN - Report à nouveau pour les reports. Il n'y a pas de retour du fisc concernant ces écritures? Elles sont plutôt implicites dans les RAN de l'exercice suivant car les comptes de résultat sont toujours reportés à zéro... Cordialement, Pour info, notre expert comptable nous dit pareille. Le FEC envoyé doit être ce qui est représenté par le bilan et le compte de résultat. C'est à dire, inclure l'écriture d'équilibrage des non-reports fait RAZ le compte de résultat, ce qui n'est pas cohérent avec des liasses fiscales déposées. https://bugs.tryton.org/issue7410 -- Richard PALO -- Vous recevez ce message, car vous êtes abonné au groupe Google Groupes tryton-fr. Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/tryton-fr/5c79b1dc-7aa0-ab3c-3126-7db8eaccea1a%40free.fr.
[tryton-fr] FEC et l'équilibrage des non-reports avant clôture
Je me pose la question sur la validité du FEC généré contenant les écritures d'équilibrage des non-reports avant clôture. Par exemple, j'utilise le journal CLO - Journal des écritures de clôture pour les non-reports, et le journal RAN - Report à nouveau pour les reports. Il n'y a pas de retour du fisc concernant ces écritures? Elles sont plutôt implicites dans les RAN de l'exercice suivant car les comptes de résultat sont toujours reportés à zéro... Cordialement, -- Richard PALO -- Vous recevez ce message, car vous êtes abonné au groupe Google Groupes tryton-fr. Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/tryton-fr/9475b6df-80cb-79b2-9b88-7a3fe27bc264%40free.fr.
Re: [tryton-dev] import_data and model account with account_account_type (RESEND)
Le 21/04/2018 à 10:23, Cédric Krier a écrit : On 2018-04-21 09:09, Richard PALO wrote: but get_rec_name() returns the hierarchy of names when there is a parent type, case not treated for but which is *always* the case for account_account_type. Indeed, it will be good to customize the search_rec_name like in party.category. If I set on the header 'type:id', then the lookup seems to expect the identifier of the account_account_type_template and not the instance of it in account_account_type as it invokes ModelData.get_id() much like Sergi mentioned (and must be specified like 'account_fr.provisions_charges' Yes ':id' suffix works only for XML id because they are the only unique ID valid on different databases. The script openerp2tryton is just a starting skeleton and the CSV import is not the most powerful tool. It was used in openerp2tryton for simple case. But it is still more powerful to write proteus script instead. I tried adding the method search_rec_name() on account_account_type but it doesn't seem to get called during import_data(). missing glue? re: ':id', this is fine and preferred. The point is that only the template classes have this (directly getting the dbid), the instantiated classes need to reference that via template=dbid So I'll just update account_account_template instead of account_account and do so prior to creating the chart of accounts.. should have thought of that sooner:-/ WRT proteus script, I guess I don't understand, openerp2tryton seems to me a proteus script as it *is* using proteus... how could it not be? cheers, -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton-dev" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton-dev/9bfd1cb1-5170-c0c5-3ab8-3622500bf459%40netbsd.org.
Re: [tryton-dev] import_data and model account with account_account_type (RESEND)
Le 20/04/2018 à 20:22, Richard PALO a écrit :
Le 20/04/2018 à 20:15, Richard PALO a écrit :
Thanks, I'm finding the correct account.account.type instance now with
the following simplified snippet:
md, = ModelData.find(['fs_id', '=', data[-1]])
at, = AccountType.find(['template', '=', md.db_id])
But import_data() still balks...
Doesn't seem to like either at.id nor str(at.id)
Looked a bit at the code, which suggests that .rec_name should be used,
but that fails as well
data[-1] = at.rec_name
Account.import_data(header, [data], Account._config.context)
The exception message, which is for a type 'provisions_charges',
the first record in my file, gives:
trytond.exceptions.UserError: ('UserError', ("Relation not found: 'Plan de types de
compte (France)PassifProvisionsProvisions >pour charges' in
account.account.type", ''))
The updated 'data' record is as follows:
['158200', 'Provisions pour risques et charges litiges', 'True', '158200',
'other', '158', '', '', 'True', 'Plan de types de compte
(France)\\Passif\\Provisions\\Provisions pour charges']
I'm wondering if it's a quoting problem returned from rec_name?
Any suggestions?
BTW, It's choking in import_data's get_many2one()
Unless I'm missing something, this can not work currently.
The query generated to lookup 'rec_name' uses the simple 'name' :
'SELECT "a"."id" AS "id", "a"."balance_sheet" AS "balance_sheet", "a"."company" AS "company", "a"."create_date" AS "create_date",
"a"."create_uid" AS "create_uid", "a"."display_balance" AS "display_balance", "a"."income_statement" AS "income_statement", "a"."name" AS
"name", "a"."parent" AS "parent", "a"."sequence" AS "sequence", "a"."template" AS "template", "a"."write_date" AS "write_date",
"a"."write_uid" AS "write_uid", CAST(EXTRACT(%s FROM COALESCE("a"."write_date", "a"."create_date")) AS VARCHAR) AS "_timestamp" FROM
"account_account_type" AS "a" WHERE "a"."name" = %s))) AND ((("a"."company" IN (%s) ORDER BY "a"."sequence" ASC NULLS FIRST,
"a"."id" ASC LIMIT 2'
but get_rec_name() returns the hierarchy of names when there is a parent type,
case not treated for but which is *always* the case for account_account_type.
If I set on the header 'type:id', then the lookup seems to expect the
identifier of
the account_account_type_template and not the instance of it in
account_account_type
as it invokes ModelData.get_id() much like Sergi mentioned (and must be
specified
like 'account_fr.provisions_charges'
This seems to imply indirectly what I feared in that the simple name *must* be
unique
else the supporting code must know about treating for hierarchical names
and/or know about treating the instantiated template tables
and/or have a means to stipulate that the db 'id' is supplied for relations
(something like 'type:dbid').
cheers,
--
Richard PALO
--
You received this message because you are subscribed to the Google Groups
"tryton-dev" group.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tryton-dev/d5cfeb94-ff1e-9875-1236-6f9e38d06f01%40netbsd.org.
Re: [tryton-dev] import_data and model account with account_account_type (RESEND)
Le 20/04/2018 à 20:15, Richard PALO a écrit :
Thanks, I'm finding the correct account.account.type instance now with
the following simplified snippet:
md, = ModelData.find(['fs_id', '=', data[-1]])
at, = AccountType.find(['template', '=', md.db_id])
But import_data() still balks...
Doesn't seem to like either at.id nor str(at.id)
Looked a bit at the code, which suggests that .rec_name should be used,
but that fails as well
data[-1] = at.rec_name
Account.import_data(header, [data], Account._config.context)
The exception message, which is for a type 'provisions_charges',
the first record in my file, gives:
trytond.exceptions.UserError: ('UserError', ("Relation not found: 'Plan de types de
compte (France)PassifProvisionsProvisions >pour charges' in
account.account.type", ''))
The updated 'data' record is as follows:
['158200', 'Provisions pour risques et charges litiges', 'True', '158200',
'other', '158', '', '', 'True', 'Plan de types de compte
(France)\\Passif\\Provisions\\Provisions pour charges']
I'm wondering if it's a quoting problem returned from rec_name?
Any suggestions?
BTW, It's choking in import_data's get_many2one()
--
Richard PALO
--
You received this message because you are subscribed to the Google Groups
"tryton-dev" group.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tryton-dev/19d49c68-e468-547f-8acf-1a2540086a5d%40netbsd.org.
Re: [tryton-dev] import_data and model account with account_account_type (RESEND)
Le 20/04/2018 à 11:35, Sergi Almacellas Abellana a écrit :
You can use the following code to get the db ids:
pool = Pool()
ModelData = pool.get('ir.model.data')
db_id = ModelData.get_id('account_fr', 'creances_autres')
And then you can get the type of your company with:
Type = pool.get('account.type')
type, = Type.search([('company', '=', company.id), ('template', '=',
db_id)])
Thanks, I'm finding the correct account.account.type instance now with
the following simplified snippet:
md, = ModelData.find(['fs_id', '=', data[-1]])
at, = AccountType.find(['template', '=', md.db_id])
But import_data() still balks...
Doesn't seem to like either at.id nor str(at.id)
Looked a bit at the code, which suggests that .rec_name should be used,
but that fails as well
data[-1] = at.rec_name
Account.import_data(header, [data], Account._config.context)
The exception message, which is for a type 'provisions_charges',
the first record in my file, gives:
trytond.exceptions.UserError: ('UserError', ("Relation not found: 'Plan de types de compte (France)PassifProvisionsProvisions >pour charges' in account.account.type", ''))
The updated 'data' record is as follows:
['158200', 'Provisions pour risques et charges litiges', 'True', '158200', 'other', '158', '', '', 'True', 'Plan de types de compte
(France)\\Passif\\Provisions\\Provisions pour charges']
I'm wondering if it's a quoting problem returned from rec_name?
Any suggestions?
--
Richard PALO
--
You received this message because you are subscribed to the Google Groups
"tryton-dev" group.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tryton-dev/68a6d8e7-be89-0b41-8de2-959f181cfa85%40netbsd.org.
Re: [tryton-dev] import_data and model account with account_account_type (RESEND)
Le 19/04/2018 à 17:38, Cédric Krier a écrit :
On 2018-04-18 17:40, Richard PALO wrote:
In the French plan, there are unfortunately 7 instances of
account_account_type_template
with the name 'Autres'... but in the xml, there are indeed unique ID's...
Is the mapping of these (xml id => sql id) stored somewhere it can be accessed
to somehow facilitate import?
In "ir.model.data".
Great, for example in my case in hand I find a record with
fs_id = 'creances_autres' having db_id = 196
which is correct for account_account_type_template
Guess I'm not sure what do I need to do to get 'creances_autres' (unique xml id)
to work instead of using the name 'Autres' for the 'type' (last field in
account.csv)
Seems account_account_type_template record id's differ from
account_account_type ids.
Perhaps first updating the 'type' field in each data record using the fs_id
(e.g. 'creances_autres')
to the value found looking up account_account_type having 'template' = the
db_id (196)
followed by the actual import_data?
That is, using the real 'id' instead of 'name' should work, right?
That is, it would be very useful to be able to
use the xml id in import_data as unique label for the sql id.
Better to write a proteus script.
?? I believe migrate.py is a proteus script, no?
I'm in: load_csv(Model.get('account.account'), load['account'])
which invokes Model.import_data...
--
Richard PALO
--
You received this message because you are subscribed to the Google Groups
"tryton-dev" group.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tryton-dev/190da4e6-afab-7482-0fa5-80769f105f8d%40netbsd.org.
[tryton-dev] pg_repack (resend)
I'm curious if anybody has tried and been able to get pg_repack (http://reorg.github.io/pg_repack/) working on a tryton db... cheers -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton-dev" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton-dev/b1278bfb-31b8-714d-19c4-d2a63b93ec92%40netbsd.org.
[tryton-dev] import_data and model account with account_account_type (RESEND)
In the French plan, there are unfortunately 7 instances of account_account_type_template with the name 'Autres'... but in the xml, there are indeed unique ID's... Is the mapping of these (xml id => sql id) stored somewhere it can be accessed to somehow facilitate import? That is, it would be very useful to be able to use the xml id in import_data as unique label for the sql id. Example: id,name,active,code,kind,parent,party_required,reconcile,deferral,type 409600,Fournisseurs - Créances pour emballages et matériel à rendre,True,409600,other,4096,True,True,True,Autres If I try this, the import fails because there are : 7 instances of account types with the name 'Autres'. Currently, I have locally changed line 180 in account_fr.xml from : Autres to Autres créances and updated my csv for import accordingly. Alternately, all the account types names must be made unique (in conformance to the xml id). If this is the only solution, please confirm and I'll file an issue with a suggested patch. BTW, this happens to be an example of manually adding the account padded with zeros to 6 places as I can't seem to get a working trytond-account_code_digits with account_fr on 4.6 (or default). There are other cases as well. -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton-dev" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton-dev/bb88ca9a-ddc0-2da3-9cd2-100a4458cba6%40netbsd.org.
Re: [tryton-fr] openerp2tryton, lettrage et génération d'un FEC
Le 10/04/2018 à 23:00, Richard PALO a écrit : Le 10/04/2018 à 20:03, Cédric Krier a écrit : On 2018-04-10 19:33, Richard PALO wrote: J'ai rencontré une difficulté avec des données migrées depuis openerp notamment dans la génération d'un FEC la 'create_date' de account.move.reconciliation est utilisée pour 'DateLet' mais cette date est par défaut la date de la migration après l'exécution de l'assistant 'account.move.reconcile_lines'. Quelle est la manière 'correcte' de forcer la 'create_date' d'être celle obtenue depuis la base openerp? C'est vrai que depuis https://bugs.tryton.org/issue5270, on pourrait utiliser la date de réconciliation. Malheureusement, selon @240 http://bofip.impots.gouv.fr/bofip/9028-PGP La date de lettrage de l’écriture correspond à la date à laquelle l’opération de lettrage a été validée dans le système comptable. Comptablement, ce n'est pas très logique, la 'date' étant mieux adapté. Mais, apparemment dans les contrôles de la comptabilité c'est la date de la dernière opération de lettrage est surveillée!: http://blog.ig-conseils.com/fec-quelles-donnees-validation-intangible/ J'ai l'impression, pour rester dans une certaine logique des données exploitables, qu'il faudrait ajouter à coté du champs 'date' un champs 'reconcile_date' afin de marquer l'opération (un peu comme 'post_date' dans l'écriture de base). -- Richard PALO -- Vous recevez ce message, car vous êtes abonné au groupe Google Groupes tryton-fr. Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/tryton-fr/e72102e6-1056-06c4-c0af-3f2949f91aa0%40free.fr.
[tryton-fr] openerp2tryton, lettrage et génération d'un FEC
J'ai rencontré une difficulté avec des données migrées depuis openerp notamment dans la génération d'un FEC la 'create_date' de account.move.reconciliation est utilisée pour 'DateLet' mais cette date est par défaut la date de la migration après l'exécution de l'assistant 'account.move.reconcile_lines'. Quelle est la manière 'correcte' de forcer la 'create_date' d'être celle obtenue depuis la base openerp? -- Richard PALO -- Vous recevez ce message, car vous êtes abonné au groupe Google Groupes tryton-fr. Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/tryton-fr/6cff72e8-5e58-0b3b-7a22-2e1f34c7df68%40free.fr.
[tryton] Re: [tryton-fr] Handling of returns/cancelations
Le 26/03/2015 à 16:39, Mathias Behrle a écrit : * Raphael Hertzog: " Re: [tryton-fr] Re: extourne/annulation d'un mouvement" (Wed, 25 Mar 2015 14:37:06 +0100): I am pulling this discussion of the french mailing list to tryton, because I find it interesting enough for the wide public and I would suspect, that at least in Europe we should have some common or at least similar procedures about the handling of credit notes versus cancellation notes. I have put the research together done by the german community at that time (dating back to 2008) and posted it at https://code.google.com/p/tryton/wiki/CreditNotevsCancelation May be we can find together the most common denominator of this business case. Le mardi 24 mars 2015, Richard PALO a écrit : En effet, avec le Nouveau Plan comptable (1999), une obligation de traçabilité des modifications d'écritures comptables impose l'utilisation des contrepassations d'écritures (voir Mémento Comptable 2015 § 332.3 III "Traçabilité". Au delà des règles comptable, la traçabilité est imposée également par l'Administration fiscale qui risquerait de ne pas se satisfaire d'une comptabilité contenant des écritures négatives. Donc, il est impérative d'organiser un aménagement pour tenir une comptabilité légale avec tryton en France. Moi je comprends tout cela bien différemment... « la traçabilité impose l'utilisation des contrepassations d'écritures » ca veut juste dire qu'on ne modifie pas l'écriture d'origine mais qu'on effectue la correction avec une ou plusieurs écritures supplémentaires. Absolutely agreed about tracibility and immutability of posted moves. For german installations we are disabling the button, that allows to change posted moves. Cette question de signe me semble tout à fait anecdotique. L'usage d'un signe négatif pour une contrepassation qui annule totalement la première écriture me semble légitime (pourvu que l'écriture soit documentée comme telle!). As Cédric has pointed out in another mail, the result between annulating a move with negative amounts to the same account (debit/credit) versus positive amounts on the contra account is different. While one will not increase the balance, the other will. Mais je ne suis pas comptable... I am an accountant neither, so happy on further input. For info, https://bugs.tryton.org/issue5180 has been updated with an initial patchset proposal supporting an 'allow_negative_moves' configuration parameter. -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton/bc87b950-223b-23f4-f5f9-31226db0ed75%40free.fr.
Re: [tryton-fr] Re: extourne/annulation d'un mouvement
Le 20/03/2015 à 23:20, Richard PALO a écrit :
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Le 20/03/15 19:20, Richard PALO a écrit :
J'ai remarqué suite au conseil de Cédric d'annuler les mouvements faits
derrière un relevé posté
que cette annulation (ou extourne) se présente dans la forme suivante:
Compte| Débit | Crédit
--+---+---
512 | | 100
604 | 100 |
==+===+==
512 | | -100
604 | -100 |
Nous avions déjà perdu cette bataille avec l'expert comptable (avec Sage et
OpenERP)
les écritures d'annulation et d'extourne doivent obligatoirement être fait
comme suit:
==+===+==
512 | 100 |
604 | | 100
Comment corriger ce traitement d'inversement de signe par
inversement de sorte (Débit ou Crédit)?
Existe t'il un paramètre en particulier à renseigner?
J'ai trouvé ceci dans account/move.py:
373 def cancel(self):
374 'Return a cancel move'
375 pool = Pool()
376 Line = pool.get('account.move.line')
377 TaxLine = pool.get('account.tax.line')
378 default = self._cancel_default()
379 cancel_move, = self.copy([self], default=default)
380 lines = []
381 tax_lines = []
382 for line in cancel_move.lines:
383 line.debit *= -1
384 line.credit *= -1
385 lines.extend(([line], line._save_values))
386 line._values = None
387 for tax_line in line.tax_lines:
388 tax_line.amount *= -1
389 tax_lines.extend(([tax_line], tax_line._save_values))
390 tax_line._values = None
391 if lines:
392 Line.write(*lines)
393 if tax_lines:
394 TaxLine.write(*tax_lines)
395 return cancel_move
Il me semble donc qu'un paramétrage manque dans tryton pour autoriser ou non la
contre passation en écriture négative car ici c'est toujours le cas.
- --
Mise à jour de https://bugs.tryton.org/issue5180
avec la proposition et le projet pour la 1ère phase d'amélioration d'une
annulation
par un paramétrage permettant des lignes négatives ou non dans une écriture
comptable [validée].
--
Richard PALO
--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes
tryton-fr.
Cette discussion peut être lue sur le Web à l'adresse
https://groups.google.com/d/msgid/tryton-fr/c236c304-f5d1-2a70-ad99-6d8a614bfa2f%40free.fr.
Re: [tryton] journal sequences by fiscal year
Le 03/04/2018 à 18:54, Dominique Chabord a écrit : 2018-04-03 18:44 GMT+02:00 Richard PALO <richard.p...@free.fr>: Dans chaque journal, les écritures doivent être identifiées par un numéro séquentiel formant, le cas échéant par période comptable ou par exercice, une série continue. Which quickly translated says that 'In each journal, the entries must be identified by a sequential number forming a continuous series, either by accounting period or by fiscal year.' Personnaly, my translation of "le cas échéant", would be "optionaly" and not "either". Hmm, I guess I simply used 'either' to mean 'where appropriate' or 'if need be':-) -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton/35816377-431a-3556-5f17-66ea41e84905%40free.fr.
Re: [tryton] journal sequences by fiscal year
Le 03/04/2018 à 18:54, Cédric Krier a écrit : On 2018-04-03 18:44, Richard PALO wrote: Interestingly, article III.C.4 Avis CNC 174-1 - Les principes d'une comptabilité régulière found in the site of the Belgian CNC http://www.cnc-cbn.be/files/advice/link/FR_174-01.htm is quite similar to usages in France: Dans chaque journal, les écritures doivent être identifiées par un numéro séquentiel formant, le cas échéant par période comptable ou par exercice, une série continue. Which quickly translated says that 'In each journal, the entries must be identified by a sequential number forming a continuous series, either by accounting period or by fiscal year.' This ensured by the *Post Number* field. Perhaps I missed something, since when is the *post number* journal-specific? Until now I understood it to be cross-journal by fiscal year (as it is configured on the FY). But the point is, at least in France, in mode 'brouillard', the number is consecutive upon initial entry. Post number is consecutive upon validation(posting) which may be somewhat an arbitrary order. -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton/846325f3-5ff0-3194-69a0-b1f6784ce63c%40free.fr.
Re: [tryton] journal sequences by fiscal year
Le 02/04/2018 à 21:58, Cédric Krier a écrit : On 2018-04-02 18:43, Richard PALO wrote: How to set sequences created for general journals to reset every fiscal year? It is not possible. 'not possible' is probably missing the adverb 'currently' It is true that the posted move sequence and invoicing sequences are reset, but any journal that touches the GL should be as well. Why? Well, first off, history shows that many accounting systems permit such, and some even do so automatically. Secondly, it more closely respects the independence of fiscal years where currently internal numbering of journal entries does not. Finally, organisations have their internal procedures for verification/validation. Example: journal 'OD' is a general journal for miscellaneous operations working on finishing up 2017 while 2018 is rolling right along, the mixed numbering and/or holes may make certain actors uneasy (namely the direction, public accountants and auditors). Naturally, an organisation often frowns/balks on limitations migrating to a new system in absence of very good and motivated reasoning. Interestingly, article III.C.4 Avis CNC 174-1 - Les principes d'une comptabilité régulière found in the site of the Belgian CNC http://www.cnc-cbn.be/files/advice/link/FR_174-01.htm is quite similar to usages in France: Dans chaque journal, les écritures doivent être identifiées par un numéro séquentiel formant, le cas échéant par période comptable ou par exercice, une série continue. Which quickly translated says that 'In each journal, the entries must be identified by a sequential number forming a continuous series, either by accounting period or by fiscal year.' -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton/ecce15ed-99ec-2669-2506-2fb239f6f787%40free.fr.
[tryton] journal sequences by fiscal year
How to set sequences created for general journals to reset every fiscal year? It appears even the Default Account Journal sequence is shared... It is true that the posted move sequence and invoicing sequences are reset, but any journal that touches the GL should be as well. -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton/8012d471-93e0-17ba-8184-fa7e6aace6a4%40free.fr.
Re: [tryton-fr] Affichage Grand livre
Le 31/03/2018 à 09:49, Camille a écrit :
Bonjour,
Lorsque j'affiche le grand livre, il me montre tous les comptes, y compris les
comtes désactivés.
Est-il possible de masquer ceux-ci, histoire d'alléger la vue ?
Ajoute un filtre comme: 'Crédit: !0,0 or Débit: !0,0 or "Balance de départ":
!0,0'
Taper une espace (' ') dans la ligne de filtre donnera les noms de champs
disponibles
J'ignore comment faire pour sauter les comptes désactivés mais, en réalité, je
ne suis
jamais arrivé à désactiver un compte mouvementé donc forcément à zéro.
Cordialement,
--
Richard PALO
--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes
tryton-fr.
Cette discussion peut être lue sur le Web à l'adresse
https://groups.google.com/d/msgid/tryton-fr/b661e776-fe58-d2de-92ed-6ef6375c843c%40free.fr.
Re: [tryton-dev] Tax Code Usage
Le 15/03/2018 à 12:48, Cédric Krier a écrit : Hi, I'm working on https://bugs.tryton.org/issue6013 For the migration, I need to define for each tax line if the amount is tax or base. So I write a script that use the existing couple (tax, code) from the tax definition to decide if it is a tax or a base. This works on the assumption that no tax code is used for both. Has anybody an counter example? Thanks, I notice in the French plan, that this seems to be the case. Go to the nested tax code list and note, for example, tax code 0030 is twice (base and tax) "Livraisons d'électricité, de gaz, de chaleur ou de froid imposables en France (base)" "0030""BAOU" "Livraisons d'électricité, de gaz, de chaleur ou de froid imposables en France" "0030""BAOU" -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton-dev" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton-dev/2ed75f08-437a-8635-0520-ac5e5fde2243%40netbsd.org.
[tryton-dev] product_brand?
Out of curiousity, has anybody already an implementation of product_brand working for recent (4.4+) tryton? -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton-dev" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton-dev/94cbfcfb-70c3-2ab4-9fe0-ccae6473287a%40netbsd.org.
Re: [tryton-dev] 80 cols on XML file
Le 20/12/2017 à 16:45, Bernat Brunet a écrit : 2017-12-20 15:55 GMT+01:00 Cédric Krier <cedric.kr...@b2ck.com <mailto:cedric.kr...@b2ck.com>>: Hi, I think we should remove the 80 cols limit on XML file. The rational is that XML file are indented by 4 spaces with at least 2 indentation ( and ) but also XML is quite verbose. So we reach the limit very quickly and so we add line break which makes the XML more difficult to read. Also most of the time 'pyson' attribute already exceed the limit and it can not be break in multiple line. I think we should be more flexible. For example the line with 'model' and 'id' is more readable when not split. But is more readable if each attribute is on his own line. So I think the style should be one line with all attributes or one attribute per line, but not allow mixed. +1 For me will be better if it's one attribute per line. Because sometimes when working with the laptop all in one line wont be good. I'm starting to tend toward what certain software do in terms of leaving that sort of formatting to pretty printers like xml_pp, xmlstarlet or what have you. In general, the output file is most certainly not intended to be interpreted directly by a human without some sort of tool or program (read: filter). In other words, it could simply all go on one line. cheers, -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton-dev" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton-dev/080b7372-020e-6cae-7b27-9c63f98627ca%40netbsd.org.
Re: [tryton] merge invoices
Le 18/12/2017 à 20:11, Cédric Krier a écrit : On 2017-12-18 20:06, Richard PALO wrote: Having a number of suppliers which group multiple deliveries in one invoice, with OpenERP (aka Odoo) we've been using account_invoice_merge extensively. Maybe missing something but haven't seem to have found the equivalent in tryton. Any hints? The module purchase_invoice_line_standalone manages that perfectly. Perhaps I'm still missing something. Now it seems the invoices are no longer created upon reception of the supplier shipment! (though invoice method is still 'Based On Shipment') I notice that I can manually create an invoice and subsequently select what appears to be PO lines (with no shipment nor PO indication)... but that will add enormous amount of time/energy/confusion to current processing. I try to select the shipments to see if there is an action to create an invoice on them to no avail... That would be the easiest (with a comment header introducing each shipment). On a sidenote, from a shipment, there seems to be no indication of the purchase order which should probably be the origin (to give context as to what products are expected)... and I can't seem to find a way to select the product moves from the Shipments Tab of the Purchase Order and create a shipment prefilled either... Once established manually a shipment, it seem impossible to navigate from the supplier shipment to the purchase order, though the inverse is visible on the Shipments Tab. Does it exist documentation to map, for migration purposes, openerp purchase workflows to tryton workflows? This is somewhat the critical path. -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton/ef5bd18c-9bb2-0e6f-ec99-f3c14fa1130f%40free.fr.
[tryton] merge invoices
Having a number of suppliers which group multiple deliveries in one invoice, with OpenERP (aka Odoo) we've been using account_invoice_merge extensively. Maybe missing something but haven't seem to have found the equivalent in tryton. Any hints? cheers, -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton/5bed07e2-e32c-c0cc-28fe-0ef1a8a47a8b%40free.fr.
Re: [tryton-fr] Règlement de facture par un tiers payeur.
Le 24/11/2017 à 11:48, Christophe (.net) a écrit : Bonjour, J'aimerais savoir comment résoudre avec tryton (v4.4). J'ai 2 factures : Client X : 324,00€ TTC Client Y : 432,00€ TTC Le client X règle les 2 factures par virement. Je fais donc la saisie d'un relevé avec une ligne pour le client X de 756,00€ Quand je lance l'assistant de réconciliation il trouve bien la facture du client X, mais comment faire pour lui associer aussi la facture du client Y ? Ou alors je dois passer par une autre procédure, si oui comment faire ? Cordialement selon les infos communiquées dans l'ordre de virement: soit affecter le règlement sur le compte X puis passer une OD afin d'éclater ce montant pour virer le bon montant sur le compte Y puis lettrer les deux comptes soit éclater le montant reçu directement dans le relevé puis sélectionner la facture réglé selon le compte client. cordialement, -- Richard PALO -- Vous recevez ce message, car vous êtes abonné au groupe Google Groupes tryton-fr. Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/tryton-fr/860e5f9a-94d3-e802-5897-3a1dc9d0a8e3%40free.fr.
Re: [tryton] Discount per family and per amount of products in a month
Le 28/10/2017 à 11:27, Cédric Krier a écrit : On 2017-10-28 06:48, Richard PALO wrote: Le 28/10/2017 à 01:12, Cédric Krier a écrit : On 2017-10-27 22:27, Richard PALO wrote: So do not fill it. You do not need to have the supplier price, it is there for information. ?? I thought that stock receptions used the order prices (not the invoiced price) for stock valuation on the stock move. Has this changed, or do I misunderstand the workflow? That is, it is frequent here to have invoices based upon [one or more] deliveries. You should know the price of the product when you validated the quotation and at worst when you receive the goods so you can update the price on the move. Indeed, that is my point. With respect to promotions, sale_promotion is only for sales and not purchases. It seems that it should be neutral, but I imagine you suggest in this case that a purchase_promotion module be devised If you want but I do not think it is a generic feature because as I said most of companies will never encode all the rules of suppliers supposed that they know it. At best they will have a spreadsheet with the price list (and some will be per quantity) which can be uploaded as product supplier price. But the common behaviour is to just adapt the price from the received quotation. This workflow will be improved by the new purchase_request_quotation: https://bugs.tryton.org/issue6175 And even I'm wondering if the unit_price should not be editable on more state than draft and not required before confirmed. It is a good idea to analyse the use cases. I personally believe there are many who value 'verification' and 'update when needing correction' as opposed to manual data entry with greater risks. The latter also greatly complicates control of *unusual* price variations which necessitate rectification by the supplier. Nobody is exempt of errors, but the general rule is to reduce their heads popping up and certainly catch them when they do... not to mention avoiding any increase in the PO => Reception => Invoice entry/validation time. That is, there are companies that may already be on the critical path time-wise to get their monthly VAT reports ready... They don't necessarily have the budget to double their staffing in order to do so. As for quotations, those are prior to selecting the products from a specific supplier for confirmation ... there is no guarantee that a supplier will offer special pricing on all items (which is frequently only on certain non "consumable" articles). (RFQs may [in some cases] be machine generated and comprehensive) RFQ's never send the habitual price with the request to the supplier... it remains extremely useful to have 'a' price present in the draft order preparation to evaluate the price quotation received (sometimes the special price negotiation is just beginning!). cheers, -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton/1a8a2309-5492-05ed-50fa-a13de1b05ad6%40free.fr.
Re: [tryton] Discount per family and per amount of products in a month
Le 28/10/2017 à 01:12, Cédric Krier a écrit : On 2017-10-27 22:27, Richard PALO wrote: So do not fill it. You do not need to have the supplier price, it is there for information. ?? I thought that stock receptions used the order prices (not the invoiced price) for stock valuation on the stock move. Has this changed, or do I misunderstand the workflow? That is, it is frequent here to have invoices based upon [one or more] deliveries. You should know the price of the product when you validated the quotation and at worst when you receive the goods so you can update the price on the move. Indeed, that is my point. With respect to promotions, sale_promotion is only for sales and not purchases. It seems that it should be neutral, but I imagine you suggest in this case that a purchase_promotion module be devised -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton/b9289fd0-0c4d-a2eb-29c7-1324702fbb29%40free.fr.
Re: [tryton] Discount per family and per amount of products in a month
Le 26/10/2017 à 10:09, Cédric Krier a écrit : On 2017-10-26 07:19, Richard PALO wrote: Le 25/10/2017 à 13:57, Cédric Krier a écrit : On 2017-10-25 13:47, Richard PALO wrote: I believe there should be some additional things to consider, typically for suppliers where instead of communicating net prices to their [professional] clients, there are: We don't try to compute instead of the supplier because you do not know how they compute and any way, it is not needed. The current supplier price list per quantity is good enough for approximation. I don't understand what you say here. You can not compute in place of the supplier because you will compute wrong. Also supplier will mostly never tell you what computation they do. Well, I guess we disagree on this point. A 'sale' is an *agreement* on the 'price' of *the* 'article'. Frequently the supplier agreement is based on such a formula as mentioned prior. 1. Fixed reductions : typically by category of product. (e.g. public price - 50%) Supported by sale_promotion This is not the same, promotion is only a punctual reduction, either global or by specific line on the invoice... it is not 'permanent' like the habitual price list conditions are. No sale promotion are not necessary limited in time. The start/end date are optional. What I meant is that a sale 'promotion' is over and above the habitual supplier agreement, and that the existing invoice reduction scheme seems to handle this okay. 2. Compound reductions : e.g. 35% + 15% => (public price * (100%-35%)) * (100%-15%) Supported by price list I see the formula possibility with hard coded coefficients, but I can't seem to get the price list to work at all on suppliers anyway... it simply igores it and uses only the price_unit value on the suppliers form of the product. No price list are not for supplier on purpose. (though I wonder if the patches for issue3797 may cause any problem here?) Already manage: https://codereview.tryton.org/40731002/diff/60001/purchase.py#newcode1139 By the way, I tried the standard approach... Purchase order -> reception -> Invoice and directly with invoice (which loses the supplier specifics from issue3797), but neither seem to understand the supplier price list as configued on the supplier price list as it seems to be only for 'sales' and not 'purchases'. Now if you really want it you can create a custom module purchase_price_list, it will be very easy to implement. Ah, this is indeed the issue I encounter I guess :-( Will need to do this asap! It is primordial to support these on price lists for suppliers as it is unacceptable to force entering line by line standard supplier conditions on articles purchased. There may be hundreds or thousands of lines per month to enter! The forms are already way too verbose for any real-life volume. So do not fill it. You do not need to have the supplier price, it is there for information. ?? I thought that stock receptions used the order prices (not the invoiced price) for stock valuation on the stock move. Has this changed, or do I misunderstand the workflow? That is, it is frequent here to have invoices based upon [one or more] deliveries. -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton/4c7c5faa-f94d-80cd-ff97-dec29f551215%40free.fr.
Re: [tryton] Discount per family and per amount of products in a month
I believe as well that supplier purchase categories could or should probably relate to purchase.product_supplier as opposed to being dumped on product.template cheers -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton/9c2c41a3-3130-f427-9b30-7c07b6e19d0f%40free.fr.
Re: [tryton] Discount per family and per amount of products in a month
Le 25/10/2017 à 13:57, Cédric Krier a écrit : On 2017-10-25 13:47, Richard PALO wrote: I believe there should be some additional things to consider, typically for suppliers where instead of communicating net prices to their [professional] clients, there are: We don't try to compute instead of the supplier because you do not know how they compute and any way, it is not needed. The current supplier price list per quantity is good enough for approximation. I don't understand what you say here. 1. Fixed reductions : typically by category of product. (e.g. public price - 50%) Supported by sale_promotion This is not the same, promotion is only a punctual reduction, either global or by specific line on the invoice... it is not 'permanent' like the habitual price list conditions are. 2. Compound reductions : e.g. 35% + 15% => (public price * (100%-35%)) * (100%-15%) Supported by price list I see the formula possibility with hard coded coefficients, but I can't seem to get the price list to work at all on suppliers anyway... it simply igores it and uses only the price_unit value on the suppliers form of the product. (though I wonder if the patches for issue3797 may cause any problem here?) 3. There may be as well volume discounts (in absence of a different article reference number) Supported by sale_promotion again, not the same as with 1. 4. I understand there may be fixed price reductions too (that is, not a percentage) in the currency used, e.g. 1€ (or 1£ or 1€) or what have you... Also supported by price list and sale_promotion even if it is highly doubtable because of the currency. same as 2. By the way, I tried the standard approach... Purchase order -> reception -> Invoice and directly with invoice (which loses the supplier specifics from issue3797), but neither seem to understand the supplier price list as configued on the supplier price list as it seems to be only for 'sales' and not 'purchases'. It is primordial to support these on price lists for suppliers as it is unacceptable to force entering line by line standard supplier conditions on articles purchased. There may be hundreds or thousands of lines per month to enter! The forms are already way too verbose for any real-life volume. -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton/792dc140-e197-0542-a2c5-8c14c5352a05%40free.fr.
Re: [tryton] Discount per family and per amount of products in a month
Le 25/10/2017 à 10:43, Cédric Krier a écrit : On 2017-10-24 08:29, Gonzalo wrote: The problem is complex, I will try to explain it the best I can. We are trying to use Tryton + GNU Health for a clinic. The clinic has a kind of subscription/insurance where you paid an amount per month and you get an amount of services to use (for example, 3 medical consultation free...). So should be able to know the amount of this products/services uses by a person in the last month, and the price will depend on this. To make things more complicated, the subscription can be per family too, i.e., if your son uses the total of medical consultation that you had free, you will have to pay. I tried to use price_list but I don't understand how it works. Anyway, I think you can’t consider the historic with that. No price list is really not the right solution. I think you should automatically append to the invoices deduction line with negative line for each product that is eligible for the deduction. I believe there should be some additional things to consider, typically for suppliers where instead of communicating net prices to their [professional] clients, there are: 1. Fixed reductions : typically by category of product. (e.g. public price - 50%) 2. Compound reductions : e.g. 35% + 15% => (public price * (100%-35%)) * (100%-15%) 3. There may be as well volume discounts (in absence of a different article reference number) 4. I understand there may be fixed price reductions too (that is, not a percentage) in the currency used, e.g. 1€ (or 1£ or 1€) or what have you... In these cases, the public list price is communicated when updated, as are the reduction coefficients, according to what is negotiated. There is, therefore, an impact on the price list... Naturally a broker may have this on both supplier and client price lists. It seems that currently the pricing and price list schemas don't deal with these common practices. cheers, -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton/635d2cf3-7233-bfcc-9c1e-fc368b1c79c3%40free.fr.
Re: [tryton] Re: openerp2tryton : painfully long in migrate_account_balance
Le 06/10/2017 à 11:32, Albert Cervera i Areny a écrit : 2017-09-20 19:25 GMT+02:00 Richard PALO <richard.p...@free.fr <mailto:richard.p...@free.fr>>: Thought I would mention that I'm seeing roughly a 2,5x speedup using pgbouncer over vanilla postgresql socket connections (via tryton.conf) where pg and proteus are running on the same iron. I'm surprised you're see this speedup using pgbouncer on the same machine. Pgbouncer is just a connection pooler and Tryton already has a connection pooler itself, so it would be great if you could investigate it further. Some things that come to mind: - Tryton is not handling correctly the pool of connections and thus creating a new connection more frequently than it should - You used TCP/IP sockets when you worked with PostgreSQL but use UNIX sockets now that you talk to pgbouncer (so the difference would come from the type of socket, not pgbouncer itself) This is not quite true. Initially I used directly unix sockets: uri = postgresql://tryton@/run/postgresql/ and now as well, but underneath pgbouncer: uri = postgresql://tryton@:6432 pgbouncer.ini uses unix_socket_dir = /run/postgresql - You changed other parameters in Postgres (or Tryton). For example, you should usually change the following default postgresql.conf parameters: - Increase work_mem -> This is the amount of memory to be used per connection so you may put one or two hundred megabytes work_mem = 256MB# min 64kB - Increase shared_buffers -> Depending on database size, but you may want 1GB, for example (if you've got enough memory, of course) shared_buffers = 4GB# min 128kB NB: 32GB main memory on my workstation - Consider using synchronous_commit = off. -> If you use it in production I recommend you try to understand its implications (we use it in our installs) This is indeed interesting, will look into it more deeply. - If you run the migration process on a non-production machine you can use "fsync =off". This can have a huge impact on performance but do NOT use it in production EVER. But I recommend it for development environments if you know that no database you use is critical. It will also have a huge impact when restoring databases. never use these... In any event, once I get all the gritty conversion details completed, I can focus a bit more on runtime tuning. I'm also wondering if psycopg2 use needs to be looked at too. I came across this 'best practice': When should I save and re-use a cursor as opposed to creating a new one as needed? Cursors are lightweight objects and creating lots of them should not pose any kind of problem. But note that cursors used to fetch result sets will cache the data and use memory in proportion to the result set size. Our suggestion is to almost always create a new cursor and dispose old ones as soon as the data is not required anymore (call close() on them.) The only exception are tight loops where one usually use the same cursor for a whole bunch of INSERTs or UPDATEs. So perhaps I'll start there first. Pulling complete moves/lines by period by fiscalyear I'm averaging ~100 seconds per period (roughly 30 minutes per fiscalyear with a rough average of 21-22K lines/year) Don't have numbers to compare, so it's just intuition, but it does not sound specially fast. At this stage, I don't believe these imports are any longer comparable to 'vanilla' openerp2tryton as I'm doing a 'deep' copy now, including journals, periods, reconciliations and all... (in France, my aim is to be able to use exclusively Tryton for previous fiscal year reports, including 'FEC'... I hope to heave OpenERP as far away as possible when fully migrated:P) cheers, -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton/59ea557e-8df3-138e-b347-0ebe71dd4cab%40free.fr.
[tryton-fr] autoliquidation de la TVA dans le bâtiment
Il semblerait que les codes TVA ne tiennent pas compte de l'autoliquidation pour les travaux immobiliers en France. C'est très semblable à ce qui est en place pour la TVA intercommunautaire. pour une description comptable: http://rfcomptable.grouperf.com/article/0423/ms/rfcompms0423_3359679.html Je me demande si quelqu'un n'aurait pas déjà un projet de paramétrage? Il n'y avait pas de projet de revoir les règles de la TVA? cordialement, -- Richard PALO -- Vous recevez ce message, car vous êtes abonné au groupe Google Groupes tryton-fr. Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/tryton-fr/5dbebdf0-fa8a-b009-4813-df51ccf8ee6b%40free.fr.
Re: [tryton] proteus: is it possible to dynamically add/remove simple field to existing model
Le 23/09/2017 à 22:41, Cédric Krier a écrit : No, I'm only answering to the removing a field, adding is possible and the basis of Tryton modularity. OK, noted. Works fine to add/remove programatically a module with the field. No problem then manually dropping the field afterwards with psql. cheers, -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton/cb9858f6-82ff-025c-c7d6-f3db0055369f%40free.fr.
Re: [tryton] proteus: is it possible to dynamically add/remove simple field to existing model
Le 23/09/2017 à 18:43, Cédric Krier a écrit : On 2017-09-23 18:16, Richard PALO wrote: As the title indicates, I'm interested to know if one can add/remove a persistent field (simple, non relational... like an integer) to an existing model with proteus. Tryton enforce data integrity so a client can not modify the data model. Or is the only way by adding a custom module which then can be removed when done. This sounds wrong and I do not even know if it is possible to do it because module has only access to subclasses of the Model. I figured as much for the integrity bit, though I thought the question should be asked to be sure. Unfortunately I don't understand the second response, are you saying that subclassing an existing class and adding a persistent field is not possible? (e.g. an additional integer field on account.move.line) Activate to add, then deactivate to remove... Or am I greatly misunderstanding something here? -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton/3b91f113-c9b9-2b8b-feb4-633aa1f3cf04%40free.fr.
[tryton] proteus: is it possible to dynamically add/remove simple field to existing model
As the title indicates, I'm interested to know if one can add/remove a persistent field (simple, non relational... like an integer) to an existing model with proteus. Or is the only way by adding a custom module which then can be removed when done. Any pointers are welcome. -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton/5843239c-cb18-83aa-b97c-08473e209088%40free.fr.
Re: [tryton] setting sequence.number_next[_internal] via proteus
Le 21/09/2017 à 00:11, Cédric Krier a écrit :
On 2017-09-20 19:26, Richard PALO wrote:
I'm curious how to currectly set the next_number_internal for an ir.sequence,
namely for reconciliations using proteus.
Setting, for example, seq.prefix='A' works just fine but
seq.number_next_internal=10 seems to be a no-op.
Using the tryton client, I can change the sequence manually from the sequences
form, is that the
only way to do it? Hints on doing so?
You should write 'number_next' which is the field show in the UI.
It is because the sequence could be a SQL sequence and so
number_next_internal will not be used.
... >8
Guess I was misled by the what I saw in the module file sequence.py, namely:
# Migration from 2.0 rename number_next into number_next_internal
table.column_rename('number_next', 'number_next_internal')
Seems to work much better! Kudos.
cheers,
--
Richard PALO
--
You received this message because you are subscribed to the Google Groups
"tryton" group.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tryton/5cb0e2f0-8158-abaa-e699-284261c403b6%40free.fr.
[tryton] setting sequence.number_next[_internal] via proteus
I'm curious how to currectly set the next_number_internal for an ir.sequence,
namely for reconciliations using proteus.
Setting, for example, seq.prefix='A' works just fine but
seq.number_next_internal=10 seems to be a no-op.
Using the tryton client, I can change the sequence manually from the sequences
form, is that the
only way to do it? Hints on doing so?
I tried Sequence.write([seq.id], {'number_next_internal': 10,})
but I get:
TypeError: write() missing 1 required positional argument: 'values'
cheers
--
Richard PALO
--
You received this message because you are subscribed to the Google Groups
"tryton" group.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tryton/ae573768-8249-118e-76ac-0c3b4cbb38ad%40free.fr.
[tryton] Re: openerp2tryton : painfully long in migrate_account_balance
Thought I would mention that I'm seeing roughly a 2,5x speedup using pgbouncer over vanilla postgresql socket connections (via tryton.conf) where pg and proteus are running on the same iron. Pulling complete moves/lines by period by fiscalyear I'm averaging ~100 seconds per period (roughly 30 minutes per fiscalyear with a rough average of 21-22K lines/year) cheers, -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton/3bf37461-4aad-346c-ea90-7f334153f13f%40free.fr.
Re: [tryton-fr] Loi de finance 2016 et Logiciels Libres (suite).
Le 10/08/2017 à 17:42, Dominique Chabord a écrit : Le 10 août 2017 à 17:33, Richard PALO <richard.p...@free.fr> a écrit : sinon la comptabilité risque d'être déclarée non-probante. Est ce que tu peux être plus précis sur ce que tu entends par là ? Je pensais que la compta de devait être probante que sur les périodes closes et qu'elle devait simplement correspondre aux pièces comptables archivées. Si j'ai faux, à quoi faut il veiller ? Plutôt sur toutes les écritures validées. http://bofip.impots.gouv.fr/bofip/2899-PGP.html Pas mal d'infos à trouver sur la toile, dont: http://www.lacademie.info/evenements/les_conferences/cahier_n_20_le_controle_fiscal_informatise_comment_s_y_preparer -- Richard PALO -- Vous recevez ce message, car vous êtes abonné au groupe Google Groupes tryton-fr. Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/tryton-fr/3d08d3fe-2911-bf50-52fb-6520ea1a0c4a%40free.fr.
Re: [tryton-fr] Loi de finance 2016 et Logiciels Libres (suite).
Le 10/08/2017 à 16:21, Cédric Krier a écrit : On 2017-08-10 16:05, Cédric Krier wrote: On 2017-08-10 14:47, Richard PALO wrote: Le 10/08/2017 à 10:22, Richard PALO a écrit : un simple horodatage certifié (ISO/IEC 18014-3) ? pour ce cas plutôt simpliste, pourquoi pas servir de `openssl ts`? (avec la possibilité d'une autorité d'horodatage configurée localement) C'est encore mieux évidement si on peut réutiliser un standard (que je ne connaissais pas). En fait, ça ne protège pas contre la suppression des derniers enregistrement signé. Il faut que le serveur de signature vérifie la non-rupture de la chaîne. En effet, j'ai réfléchi à cela. Je me suis dit qu'il existe plusieurs cas de figure dont le cas d'une simple restauration depuis une sauvegarde d'une base après une panne de quelque sorte. Ce sera incompréhensible si votre tiers vous met dans une situation où il serait impossible (ou bien très difficile) de reprendre votre comptabilité. Je pense qu'il existe des possibilités à évaluer comment éviter (ou au moins permettre à détecter) cette sorte de malveillance. Hélas, une fois détecté .. une restauration depuis une sauvegarde encore valable s'impose ainsi que la nécessité de reprendre les écritures perdues... sinon la comptabilité risque d'être déclarée non-probante. cordialement, -- Richard PALO -- Vous recevez ce message, car vous êtes abonné au groupe Google Groupes tryton-fr. Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/tryton-fr/b89f95db-8a63-aeed-eb9a-92eddd1b8118%40free.fr.
Re: [tryton-fr] Loi de finance 2016 et Logiciels Libres (suite).
Le 10/08/2017 à 16:05, Cédric Krier a écrit : On 2017-08-10 14:47, Richard PALO wrote: Le 10/08/2017 à 10:22, Richard PALO a écrit : un simple horodatage certifié (ISO/IEC 18014-3) ? pour ce cas plutôt simpliste, pourquoi pas servir de `openssl ts`? (avec la possibilité d'une autorité d'horodatage configurée localement) C'est encore mieux évidement si on peut réutiliser un standard (que je ne connaissais pas). Les points manquants sont: - openssl ne gère pas l'envoie des requêtes/réponses. Un simple site web avec authentification devrait faire l'affaire. - cryptography n'a pas de binding pour cette interface (https://cryptography.io/en/latest/hazmat/backends/openssl/) Il faudra soit le proposer à cryptography. Par expérience le projet est assez ouvert (j'y ai déjà contribué: https://github.com/pyca/cryptography/commits?author=cedk). Soit il faudra appeler les commandes via subprocess mais ça rendrait le déploiement plus compliqué et moins portable (Windows, MacOSX, etc.). mais le certificat peut être auto-signé: https://superuser.com/questions/738612/openssl-ca-keyusage-extension qui évite, dans ce cas, la nécessité d'envoyer la requête. Sinon, il faut bien envoyer la requete à une autorité d'horodatage (TSA) comme dans cet exemple:> http://unmitigatedrisk.com/?p=395 DuckDuckGo (ou g$ggle): openssl timestamp extendedKeyUsage -- Richard PALO -- Vous recevez ce message, car vous êtes abonné au groupe Google Groupes tryton-fr. Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/tryton-fr/45973487-d9c8-9375-ff56-4cf79772eb00%40free.fr.
Re: [tryton-fr] Loi de finance 2016 et Logiciels Libres (suite).
Le 10/08/2017 à 10:22, Richard PALO a écrit : un simple horodatage certifié (ISO/IEC 18014-3) ? pour ce cas plutôt simpliste, pourquoi pas servir de `openssl ts`? (avec la possibilité d'une autorité d'horodatage configurée localement) -- Richard PALO -- Vous recevez ce message, car vous êtes abonné au groupe Google Groupes tryton-fr. Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/tryton-fr/5697b823-2d77-173d-953f-c646eae68bf6%40free.fr.
Re: [tryton] openerp2tryton : painfully long in migrate_account_balance
Le 21/07/2017 à 15:59, Sergi Almacellas Abellana a écrit : If you are using proteus 4.4, it's already doing one single call to the server using the create and the list of all lines. IIUC, you are creating a move with 15k lines. So I'm wondering if increasing the record cache size [1] to a number higher than 15k for the migration will speedup things a little bit. Of course, this will increase the memory usage, so just take care you don't get out of memory. Hope it helps. [1] http://doc.tryton.org/4.4/trytond/doc/topics/configuration.html?highlight=cache#record This was a nice tip, and it allowed me to get much much further. Thanks. In the end, once I created a tryton move per opererp move, it seemed I could live without modifying the cache and get 5 1/2 years in under a couple of hours (fiscal year by fiscal year). -- Richard PALO "Ne croyez rien, peu importe où vous l'avez lu, ou qui l'a dit, à moins que cela ne s'accorde avec votre raison." -- You received this message because you are subscribed to the Google Groups "tryton" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton/381c0db4-21a7-fc36-76a8-43ce90b6037f%40free.fr.
Re: [tryton] openerp2tryton : painfully long in migrate_account_balance
Le 21/07/2017 à 00:42, Cédric Krier a écrit : On 2017-07-20 14:00, E. Boer wrote: Like Cedric already said, Proteus is not ment to be used for a huge amount of data. You can create a script like explained in the (very) old wiki: http://hg.tryton.org/deprecated/tryton.wiki/file/tip/RemoteCalls.wiki Indeed such call is doable with proteus by using the raw function of the Model like Model.create or Model.write. E.Boer, nice to know you've been able to get such thoughput, which seems much more reasonable. You don't happen to have a version of your script that could work with oerp6.1->tryton4.4? Cedric, since I'm already in proteus, the Model.write() seems quite worthwhile to try out first. Would it be possible to have a very simple example snippet with a move record including a number of move lines such that I can better understand the syntax of what is expected? as to .save(), it appears to seriously suffer, even exponentially, with large numbers of move lines. for info, I placed the move.save() inside the loop to see via the database how things advanced with 15K lines (having already split by fiscal year), and it would do a couple hundred relatively fast, but a thousand was slowing down fast, and many hours later only a total of roughly 2500 move lines were saved so extrapolating 15K is probably close to infinity,timewise. *I presume* multiple moves would help already greatly (but I haven't had a chance yet to try it). cheers -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton/75002dd3-50bf-1045-c4b7-3d10bd5ccbf9%40free.fr.
Re: [tryton] openerp2tryton : painfully long in migrate_account_balance
Le 18/07/2017 à 13:27, Cédric Krier a écrit : On 2017-07-18 13:01, Richard PALO wrote: I'm looking for hints as to how to prod move.save() to complete or at least to give some info as to why it isn't. It appears to be cpu bound (indeed, the openerp base is quite large). move.save is at the end of the following, from line 1065..1070 in migrate_account_balance move.lines.append(new_line) new_line.account = get_account(line.code, code2account) if new_line.account.party_required: new_line.party = code2party[str(line.partner_id)] move.save() How do you know it is the problem? I added print statements to trace ensuring that the 'for line in cur' loop was completed. ... I do not think it could be a problem, I guess it just show you the last query run by the session. yeah, seems probably the case. when I say long, it is already over 5 hours! Yep, proteus is not specially designed for performance. yikes, guess I'll need to try breaking things down a bit differently, that is instead of putting all move lines in a monster 'migration' move. cheers, -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton/e4ac7cf6-ad50-7def-8c43-1f520d28bcb9%40free.fr.
[tryton] openerp2tryton : painfully long in migrate_account_balance
I'm looking for hints as to how to prod move.save()
to complete or at least to give some info as to why it isn't.
It appears to be cpu bound (indeed, the openerp base is quite large).
move.save is at the end of the following, from line 1065..1070 in
migrate_account_balance
move.lines.append(new_line)
new_line.account = get_account(line.code, code2account)
if new_line.account.party_required:
new_line.party = code2party[str(line.partner_id)]
move.save()
phppgadmin seems to believe that the following is cycling:
SELECT "a"."rounding" AS "rounding", "a"."active" AS "active", "a"."code" AS "code", "a"."create_date" AS "create_date", "a"."create_uid" AS "create_uid", "a"."digits" AS "digits", "a"."id" AS "id", "a"."mon_decimal_point" AS "mon_decimal_point", "a"."mon_grouping" AS "mon_grouping", "a"."mon_thousands_sep" AS "mon_thousands_sep", "a"."n_cs_precedes" AS "n_cs_precedes", "a"."n_sep_by_space" AS "n_sep_by_space",
"a"."n_sign_posn" AS "n_sign_posn", "a"."negative_sign" AS "negative_sign", "a"."numeric_code" AS "numeric_code", "a"."p_cs_precedes" AS "p_cs_precedes", "a"."p_sep_by_space" AS "p_sep_by_space", "a"."p_sign_posn" AS "p_sign_posn", "a"."positive_sign" AS "positive_sign", "a"."symbol" AS "symbol", "a"."write_date" AS "write_date", "a"."write_uid" AS "write_uid" FROM "currency_currency" AS "a" WHERE (("a"."id" IN (44)))
when I say long, it is already over 5 hours!
--
Richard PALO
--
You received this message because you are subscribed to the Google Groups
"tryton" group.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tryton/df654e4b-8312-5929-0123-7939fe5cd06f%40free.fr.
[tryton] import_data for accounts
Continuing my adventure with openerp2tryton, I come across a new challenge. Part of the migration includes adapting the default accounting plan with a csv file. PM: I am using account_fr for the French PCG. I use the following header: id,name,active,code,kind,parent,party_required,reconcile,deferral,type everything seems okay until I get to the VAT accounts (4452xx and 44566x, where "Autres" is not a unique name in account.account.type.template (nor in account.account.type) and thus gives an error. There doesn't seem to be any Parent parsing, so prepending a parent (eg 'Créances d'exploitation\Autres') doesn't seem to work nor does replacing the the 'name' with the id directly (tag nor value)... Looking at the code for import_data() in modelstorage.py I thought I'd try using 'type:id' in the header and 'account_fr.creances_autres' in the value but then I get the following: psycopg2.IntegrityError: ERREUR: une instruction insert ou update sur la table « account_account » viole la contrainte de clé étrangère « account_account_type_fkey » DETAIL: La clé (type)=(196) n'est pas présente dans la table « account_account_type ». it appears that import_data uses account.account.type and not account.account.type.template where the db_id retrieved is indeed the id of the type but which appears not to be maintained in account.account.type. Is this a bug in account.account.type structure (that is, losing the valid ids)? Other ideas on how to import these VAT accounts? -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton/2454336e-8553-0a0e-0dda-a1a680e083f5%40free.fr.
Re: [tryton-fr] Compte 517
Le 25/06/2017 à 22:27, Richard PALO a écrit : Le 25/06/2017 à 20:30, Cédric Krier a écrit : Par contre, j'ai crée l'issue si quelqu'un veut l'implémenter: https://bugs.tryton.org/issue6601 Pour mémoire, pour le PCG Français une bonne référence serait toujours Lefebvre Comptable (que j'ai fourni à l'association Tryton) dans l'appendice dédié aux modèles de bilan... Notez là dans le bilan où la racine du compte 4xx ou 5xx est suivi par 'D' ou 'C'. De mémoire c'est similaire (selon leur propre plan comptable) dans beaucoup de pays, notamment aux Pays Bas et en Belgique. bien cordialement, -- Richard PALO -- Vous recevez ce message, car vous êtes abonné au groupe Google Groupes tryton-fr. Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/tryton-fr/1287abba-247d-34a6-7bab-818fa2321c02%40free.fr.
Re: [tryton-fr] Compte 517
Le 25/06/2017 à 20:30, Cédric Krier a écrit : On 2017-06-25 09:51, Camille wrote: Bon, je note De mon côté, pour le livret A, j'ai passé mon 517 en disponibilités, le solde ne pouvant être négatif je ne pense pas prendre grand risque. Mais ta réponse m'interpelle pourtant : Un compte 512 peut bien, lui, avoir un solde négatif et pourtant il est bien calé d'origine en disponibilité. Quelle différence d'approche avec un 517 ? Je ne comprends pas la question. Par contre, j'ai crée l'issue si quelqu'un veut l'implémenter: https://bugs.tryton.org/issue6601 Comment un livret d'entreprise (compte 517) peut il être d'autre chose qu'en disponibilités (ou zéro), en tout cas toujours en 'actif'. Ce serait mieux de créer un compte 517xxx Livret avec le bon 'type' dans ce cas. Mais ce qui est très clair est que lorsque le compte banque (512) est en découvert, c'est devenu un "Emprunt et dettes auprès établissements de crédits" au passif au lieu de "Disponibilités" à l'actif, donc le sens du solde 'débiteur' ou 'créditeur' est bien important. Il parait qu'il y ait aussi un usage de ne pas toujours virer les fournisseurs débiteurs en 401x au 409x (ni les clients créditeurs en 411x au 419x) donc ces comptes tiers pourraient avoir un traitement similaire (mais ici c'est tiers par tiers). C'est l'importance d'une balance auxiliaire pour isoler ces cas, souvent liés aux règlements trop versés (et pourquoi les montants débit et crédit et non seulement le solde de la balance doit se trouver dans les vues du comptes parents). bien cordialement, -- Richard PALO -- Vous recevez ce message, car vous êtes abonné au groupe Google Groupes tryton-fr. Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/tryton-fr/7140d759-e30b-ed64-52fd-0e5106680a6f%40free.fr.
Re: [tryton] updating party_sequence with proteus
Le 20/06/2017 à 17:09, Richard PALO a écrit :
The following code, for example, works as expected if I manually install party
and select
the party sequence with the tryton client.
# Reset the sequence
Sequence = Model.get('ir.sequence')
configuration = Configuration(1)
if not configuration.party_sequence:
configuration.party_sequence = Sequence.find([('code', '=',
'party.party')])
configuration.party_sequence.number_next = max(
list(map(int, iter(code2party.keys() + 1
configuration.party_sequence.save()
I believe I just realised that Sequence.find() is a multivalued function, so
after changing thus:
configuration.party_sequence, = Sequence.find([('code', '=',
'party.party')])
the workaround does seem to be okay in the end.
--
Richard PALO
--
You received this message because you are subscribed to the Google Groups
"tryton" group.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tryton/de68c09c-188e-0f78-e2a0-b3a4a16a8c51%40free.fr.
Re: [tryton] updating party_sequence with proteus
Le 20/06/2017 à 15:19, Cédric Krier a écrit :
On 2017-06-20 15:10, Richard PALO wrote:
Le 20/06/2017 à 14:27, Cédric Krier a écrit :
On 2017-06-20 09:08, Richard PALO wrote:
Not very fluent in proteus nor the recent ir.sequence usage changes, I'm having
difficulty
getting a critical portion of the openerp2tryton to work on 4.4...
In migrate_party, there is the following code around line 254 (nb:this has been
2to3'd):
# Reset the sequence
configuration = Configuration(1)
configuration.party_sequence.number_next = max(
list(map(int, iter(code2party.keys() + 1
configuration.party_sequence.save()
Unfortunately party_sequence is null and I can't seem to determine the
incantation
that will fill it in correctly...
Is it also null when using the client?
Did you do a proper installation?
It appears so. I checked my existing bases, plus a base created under 4.4
Under party->configuration->party configuration the sequence field is blank for
all.
So it seems you have decided to not have automatic code on party.
We could improve the script for this case because obviously it does not
need to be updated.
Hmm, I've haven't [consciously] decided this at all... how would one do this,
and why?
Moreso, has always worked as intended (automatically, that is). I've never
fiddled with
this form prior to you just now asking me to check there in the client.
Therefore I believe at run-time the party.party sequence seems to be
effectively used,
but the script (at least as is) is not able to update the number_next value,
therefore dies
when trying to create the first employee because code '1' is already used (the
company).
That is, I need to explicitly select 'party' to load it.
I do not understand what this means.
Do you mean, you have to fill the code field explicitly when creating a
party?
No. In the party configuration form for the sequence, if I select 'party' then
it seems
selected in a persistent manner.
The problem is that all the modules are typically loaded by the script...
The following code, for example, works as expected if I manually install party
and select
the party sequence with the tryton client.
# Reset the sequence
Sequence = Model.get('ir.sequence')
configuration = Configuration(1)
if not configuration.party_sequence:
configuration.party_sequence = Sequence.find([('code', '=',
'party.party')])
configuration.party_sequence.number_next = max(
list(map(int, iter(code2party.keys() + 1
configuration.party_sequence.save()
But if I don't, the assignment fails after the find as follows:
/opt/trytond/trytond/modules/__init__.py:143: DeprecationWarning: This method
will be removed in future versions. Use 'parser.read_file()' instead.
module_config.readfp(fp)
/opt/trytond/trytond/modules/__init__.py:143: DeprecationWarning: This method
will be removed in future versions. Use 'parser.read_file()' instead.
module_config.readfp(fp)
/opt/trytond/trytond/model/fields/function.py:100: DeprecationWarning:
inspect.getargspec() is deprecated, use inspect.signature() or
inspect.getfullargspec()
if 'names' in inspect.getargspec(method)[0]:
Traceback (most recent call last):
File "migration.py", line 1141, in
'account': args.load_account,
File "migration.py", line 30, in main
migrate_party(installed, cur)
File "migration.py", line 258, in migrate_party
configuration.party_sequence = Sequence.find([('code', '=', 'party.party')])
File
"/usr/lib/python3.6/site-packages/proteus-4.4.1-py3.6.egg/proteus/__init__.py",
line 256, in __set__
AssertionError
cheers,
--
Richard PALO
--
You received this message because you are subscribed to the Google Groups
"tryton" group.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tryton/ee4dd7f5-cf04-6b4e-9612-b35750aac94e%40free.fr.
Re: [tryton] updating party_sequence with proteus
Le 20/06/2017 à 14:27, Cédric Krier a écrit : On 2017-06-20 09:08, Richard PALO wrote: Not very fluent in proteus nor the recent ir.sequence usage changes, I'm having difficulty getting a critical portion of the openerp2tryton to work on 4.4... In migrate_party, there is the following code around line 254 (nb:this has been 2to3'd): # Reset the sequence configuration = Configuration(1) configuration.party_sequence.number_next = max( list(map(int, iter(code2party.keys() + 1 configuration.party_sequence.save() Unfortunately party_sequence is null and I can't seem to determine the incantation that will fill it in correctly... Is it also null when using the client? Did you do a proper installation? It appears so. I checked my existing bases, plus a base created under 4.4 Under party->configuration->party configuration the sequence field is blank for all. That is, I need to explicitly select 'party' to load it. Which would seem to corroborate with what I'm experiencing. I'm current on the 4.4 branch under Python 3.6.1 -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton/83234c80-d04c-080a-93dc-d3e7f058037e%40free.fr.
[tryton] updating party_sequence with proteus
Not very fluent in proteus nor the recent ir.sequence usage changes, I'm having difficulty getting a critical portion of the openerp2tryton to work on 4.4... In migrate_party, there is the following code around line 254 (nb:this has been 2to3'd): # Reset the sequence configuration = Configuration(1) configuration.party_sequence.number_next = max( list(map(int, iter(code2party.keys() + 1 configuration.party_sequence.save() Unfortunately party_sequence is null and I can't seem to determine the incantation that will fill it in correctly... I tried to use get_multivalue() using somewhat as model a snippet from account/party.py but I get the error that get_multivalue() isn't available (where it is in vanilla tryton code). I tried accessing directly 'ir.sequence' for 'party.party' and I can set number_next but cannot 'save()' the record as the method isn't available. Using update_sql_sequence() doesn't seem to work in this context either. So I presume this is probably a false route. Any hints on how to actualise the reference party_sequence under Configuration? Where does ConfigurationSequence play into things, if it does? -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton/4b64077d-b84c-031c-2e8c-04ffcf1641e9%40free.fr.
Re: [tryton-dev] resend:upgrade warnings with recent develop branch
Le 03/05/2017 à 10:12, Cédric Krier a écrit : On 2017-05-01 22:39, Richard PALO wrote: [resend, g$ggle still broke, apparently] full upgrade with recent 'develop' shows the following: 4815 140668832162880 [2017-05-01 16:35:10,058] WARNING trytond.backend.postgresql.table Unable to set column company of table account_fiscalyear_invoice_sequence not null ! Try to re-run: trytond.py --update=module If it doesn't work, update records and execute manually: ALTER TABLE "account_fiscalyear_invoice_sequence" ALTER COLUMN "company" SET NOT NULL Indeed I have 25 records where company is not set here (single company db). Is this a case where I need to manually set the company (id=1), or is it a possible omission in the migration code to check? I'm pretty sure it is because you are migrating between two development versions. We do not support such migration, only between releases. I am pretty sure that this base was always on a released version since creation (03/2015) which I believe was on 3.4. It is only very recently, after 4.2 in waiting for last few bits for 4.4 (which has subsequently been released) that it is on the trunk master. The questions remain, though, as to the rectification needed. -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton-dev" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton-dev/7346ef4e-1c3a-db69-7321-fec84fa0c7cf%40netbsd.org.
[tryton-dev] resend:upgrade warnings with recent develop branch
[resend, g$ggle still broke, apparently] full upgrade with recent 'develop' shows the following: 4815 140668832162880 [2017-05-01 16:35:10,058] WARNING trytond.backend.postgresql.table Unable to set column company of table account_fiscalyear_invoice_sequence not null ! Try to re-run: trytond.py --update=module If it doesn't work, update records and execute manually: ALTER TABLE "account_fiscalyear_invoice_sequence" ALTER COLUMN "company" SET NOT NULL Indeed I have 25 records where company is not set here (single company db). Is this a case where I need to manually set the company (id=1), or is it a possible omission in the migration code to check? I see as well: 4815 140668832162880 [2017-05-01 16:35:29,739] INFO trytond.convert Deleting 58@ir.property from account_payment.property_payment_group_sequence 4815 140668832162880 [2017-05-01 16:35:29,739] WARNING trytond.convert Could not delete id 58 of model ir.property because model no longer exists. 4815 140668832162880 [2017-05-01 16:35:29,760] INFO trytond.convert Deleting 57@ir.property from product.property_cost_price_method 4815 140668832162880 [2017-05-01 16:35:29,761] WARNING trytond.convert Could not delete id 57 of model ir.property because model no longer exists. 4815 140668832162880 [2017-05-01 16:35:29,761] INFO trytond.convert Deleting 1@ir.property from product.property_product_cost_price_method 4815 140668832162880 [2017-05-01 16:35:29,762] WARNING trytond.convert Could not delete id 1 of model ir.property because model no longer exists. 4815 140668832162880 [2017-05-01 16:35:29,773] INFO trytond.convert Deleting 2@ir.property from party.property_party_sequence 4815 140668832162880 [2017-05-01 16:35:29,774] WARNING trytond.convert Could not delete id 2 of model ir.property because model no longer exists. Not clear if these can simply be deleted or not. id | create_uid |create_date | res | value | write_uid | field | write_date | company +++-+---+---+---++- 1 | 0 | 2015-03-22 04:43:04.18063 | | ,fixed| | 732 || 2 | 0 | 2015-03-22 04:44:17.036349 | | ir.sequence,1 | | 909 || 57 | 0 | 2016-05-06 17:12:16.543205 | | ,fixed| | 732 || 58 | 0 | 2016-05-07 03:53:08.345128 | | ir.sequence,4 | | 2404 || (4 lignes) I noticed that there are two other records with a null 'res', namely for the default client and supplier accounts in account.account. I guess I presume they are okay but should there be some value set for 'res'? Something like 'party.party,1' which is the party id of the company? Cheers, -- Richard PALO -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton-dev" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton-dev/3b2c72fe-864f-7dfd-b8fb-365d09a29e1c%40netbsd.org.
[tryton-fr] Re: Montant de base des taxes intracommunautaire
Le 29/03/2017 à 15:31, Cédric Krier a écrit : On 2017-03-29 11:39, Cédric Krier wrote: On 2017-03-29 11:16, Cédric Krier wrote: Bonjour, On m'a fait remarqué que la configuration standard des taxes d'achats intracommunautaire serait incorrecte. Elle met deux fois le montant de base sur les code 44/31 et 207b. Il semblerait qu'il ne faudrait pas mettre le montant de base sur le 207b dans ces cas. J'ai créé: https://bugs.tryton.org/issue6404 Est-ce que ce changement est correcte ? En fait, les codes 207* ont été ajouté par l'issue4570 [1] pour l'auto-déclaration. Donc je pense que la question est plutôt, si c'est normal d'avoir les montants de base et taxe dupliqué dans ces codes ? En fait, c'est normal. L'utilisateur était confus car la totale de la rubrique "Opérations imposables base" ne correspond à rien évidement. Il faudrait peut-être avoir une option pour cacher les sommes qui n'ont pas de signification. Par contre j'ai mis à jour l'issue pour discuter d'une autre anomalie qui est le non-remplissage du code 44. Il y a un commentaire dans le XML mais sans référence. De plus même si ce n'est pas obligatoire, ne serait-ce pas mieux de remplir les cases ? [1] https://bugs.tryton.org/issue4570 Avec PCG France, je tombe sur ce cas avec un achat par amazon venant de DE avec l'écriture suivante générée: Compte Débit Crédit 401138,66 44527,73 44527,73<= ? 44566 7,73 44527,73<= ? 606338,66 Pourquoi ces deux lignes indiquées (ayant la même ligne de taxe)? Comment éviter leur génération? -- Richard PALO -- Vous recevez ce message, car vous êtes abonné au groupe Google Groupes tryton-fr. Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/tryton-fr/dd69d517-18c4-34f8-b756-b42d1afc1496%40free.fr.
Re: [tryton-fr] facture fournisseurs avec reprise matériel
Le 16/04/2017 à 22:50, Cédric Krier a écrit : L'usage est de simplement saisir les lignes de la facture d'achat avec, pour la ligne d'immo dans le compte 2155 (outillage industriel) et au compte de la TVA pour immobilisations (44562) et la reprise du matériel au compte 7752xx (ci supra) TVA 44571x. Je ne vois pas ce qui empêche de le faire. Les deux comptes sont de type expense ou revenue. Et il existe bien des taxes "Achat Immobilisations". Les produits de type actifs ont bien un compte d'actif qui est utilisé quand on les achète et un compte de dépense quand on les vend. Il faut que le produit soit amortissable et qu'un actif soit lié sur la ligne de facture lors de la vente. Dans la version récente, il m'est impossible d'ajouter dans une facture fournisseur un compte dans le 7xxx pour une ligne. Pareille pour un compte 6xxx dans une facture client. J'ai essayé aussi de simplement mettre le montant TTC sur la ligne de reprise de matériel et sélectionner le compte 462xxx (Créances sur cessions d'immobilisations) mais cela n'a pas marché non plus car on ne peut pas sélectionner le compte 462xxx .. (finalement, pour une écriture 'correcte', voir ** ci-dessous). Cette dernière nouvelle me dit qu'il existe aussi le même gendre de problème pour saisir d'autres sortes de factures où, par exemple, une retenue de garantie devrait être appliquée. Car là, on déduit le montant de retenue (souvent 5% TTC) sur le compte 40x7 (fournisseur) ou 41x7 (client) le cas échéant. Bref, je peux vivre facilement sans la possibilité de saisir dans les lignes de factures fournisseurs un compte produit (7xxx) ou dans les factures clients un compte de charges (6xxx) tant que la possibilité existe de saisir outre d'un compte d'immobilisation (2xxx) d'un compte de tiers tel que 4xx7xx pour les RG ou le 46xxx (Débiteurs divers et créditeurs divers). Je peux comprendre que le 'type' de ligne, afin d'éviter la confusion avec un produit proprement dit, devrait être différent pour ces cas, par exemple au lieu de 'ligne', quelque chose comme 'régularisation' ou 'spéciale' pour supporter ces cas de 'retenue de garantie', 'reprise de matériel', voire d'autres comme 'variation de prix', 'compte prorata' et cetera (christophe, tu suis ce fil?;-). Et 'remise commerciale'? ** Un exemple pour une facture fournisseur avec reprise de matériel immobilisé: Compte Tiers Débit Crédit 4011xx 'frn' 807,47 2155xx 668,83 44562x 138,64 462xxx 'frn' 100,00 7752xx 83,33 44571x 16,67 Montant Net à payer exigible: 807,47 - 100,00 = 707,47 (dont le règlement soldera les comptes du tiers 4011xx et 462xxx par compensation.) Pour une retenue de garantie (RG) sur une facture client: Compte TierDébit Crédit 4111xx 'clt' 285,00 704xxx 250,00 4117xx 'clt'15,00 44571x2,50 44571x 47,50 Montant Net à payer exigible: 285€ (les 15€ de RG exigibles qu'au terme de l'échéance définie) Quant aux 'actifs', pour l'instant je n'utilise pas des 'produits' pour les immos, au moins pas encore et surtout pas avant que les difficultés rencontrées avec les 'actifs' et leur amortissements soient adressées.. bien cordialement, -- Richard PALO -- Vous recevez ce message, car vous êtes abonné au groupe Google Groupes tryton-fr. Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/tryton-fr/217060f6-1f0d-70bf-ad1d-f2361c440105%40free.fr.
Re: [tryton-fr] facture fournisseurs avec reprise matériel
Le 16/04/2017 à 19:38, Cédric Krier a écrit : On 2017-04-16 18:46, Richard PALO wrote: Je viens de rencontrer une difficulté dans la saisie d'une facture d'achat avec reprise de matériel immobilisé. Pourrais-tu expliqué ce que c'est ? Pour être simpliste, une facture d'achat avec plusieurs lignes, dont une pour comptabiliser en immobilisations (par exemple: une tronçonneuse) et une ligne de reprise de mon ancien matériel (tronçonneuse, qui est immobilisée). Jusqu'à présent nous avons pu (dans p.e. OpenERP ou Sage) saisir les factures d'achat avec une ligne sur 7752xx (sous-rubrique de produits de cessions d'éléments d'actif ... Immobilisations corporelles) affecté au bon compte de la TVA pour éviter la compensation interdite. Je ne comprends absolument pas cette phrase.> L'usage est de simplement saisir les lignes de la facture d'achat avec, pour la ligne d'immo dans le compte 2155 (outillage industriel) et au compte de la TVA pour immobilisations (44562) et la reprise du matériel au compte 7752xx (ci supra) TVA 44571x. Tryton semble de ne pas permettre ce gendre d'écriture dans les assistants de facturation. C'est quoi "assistants de facturation" ? Je comprends pas ce qui n'est pas permis ? Il faudrait être plus explicite quand on décrit un problème. ? Factures -> Factures fournisseur (ou Factures client le cas échéant) Outre fausser la pièce (facture d'achat) puis saisir une facture de vente fictive, je me demande si quelqu'un a déjà implémenté une bonne solution pour supporter directement cet usage? Mais de quel usage parles-tu ? Voir plus haut. Pour mémoire, j'ai essayé de rajouter les deux lignes (7752xx + TVA) directement dans le mouvement (avant de poster)... c'est possible, mais c'est une opération qui confond bien l'assistant de facture par la suite. Pourrais-tu expliqué quelle est le problème ? Il n'est pas permis dans une facture d'achat de saisir les lignes affectées aux comptes 7xx (PCG France)... Pour une facture d'achat, des lignes affectées au comptes 6xx. De la manière très semblable, nous avons très souvent des factures client exigeant contractuellement la déduction de certains frais qui se résume à une ligne comme de celle-ci dessus mais au compte 60 (typiquement 605xxx pour le compte prorata) affecté au bon compte de la TVA... Je ne vois pas de quelle ligne tu parles ? ? Eh bien, dans la facture, la pièce à *comptabiliser* naturellement. De manière générale, il faudrait être bien plus précis et explicite sans faire de présuppositions quand on pose une question ? Et aussi ne pas considérer que la mailing liste est uniquement centré sur la France, c'est une liste francophone. Effectivement, les usages peuvent varier d'un pays à un autre, même si l'opération serait plus ou moins équivalent. -- Richard PALO -- Vous recevez ce message, car vous êtes abonné au groupe Google Groupes tryton-fr. Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/tryton-fr/e3a8e39b-5cbe-4e35-9e54-2c28c9969958%40free.fr.
[tryton-fr] facture fournisseurs avec reprise matériel
Je viens de rencontrer une difficulté dans la saisie d'une facture d'achat avec reprise de matériel immobilisé. Jusqu'à présent nous avons pu (dans p.e. OpenERP ou Sage) saisir les factures d'achat avec une ligne sur 7752xx (sous-rubrique de produits de cessions d'éléments d'actif ... Immobilisations corporelles) affecté au bon compte de la TVA pour éviter la compensation interdite. Tryton semble de ne pas permettre ce gendre d'écriture dans les assistants de facturation. Outre fausser la pièce (facture d'achat) puis saisir une facture de vente fictive, je me demande si quelqu'un a déjà implémenté une bonne solution pour supporter directement cet usage? Pour mémoire, j'ai essayé de rajouter les deux lignes (7752xx + TVA) directement dans le mouvement (avant de poster)... c'est possible, mais c'est une opération qui confond bien l'assistant de facture par la suite. De la manière très semblable, nous avons très souvent des factures client exigeant contractuellement la déduction de certains frais qui se résume à une ligne comme de celle-ci dessus mais au compte 60 (typiquement 605xxx pour le compte prorata) affecté au bon compte de la TVA... Bien cordialement, -- Richard PALO -- Vous recevez ce message, car vous êtes abonné au groupe Google Groupes tryton-fr. Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/tryton-fr/9d729d5e-acd2-9c8f-7fee-d594b593309f%40free.fr.
[tryton-dev] reconciliation in GeneralLedgerLine
I prototyped adding display of line.reconciliation.name in General Ledger reports iff the reconciliation date is '<=' to the end_date of the end_period (if specified) or of the fiscal year. This seems to work nicely in the generated report, but for 'correctness' I'd like to filter the column already in the GeneralLedgerLine output screen instead. I initially thought to put the fields.Many2One for account.move.reconciliation I added in a fields.Function and provide a 'getter' function get_reconciliation, but then I realised that I probably didn't have the context necessary (namely GeneralLedgerAccountContext) in order to do pick up fiscalyear and end_period. How could this be done? Is there any way to filter columns as opposed to records? cheers, -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton-dev" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton-dev/05d06957-fc0c-3059-68f0-841198ff6a47%40netbsd.org.
[tryton-dev] Re: github not in sync
/stock_package_shipping_ups (4.2.0-6-ge63541a) 104ec3d54ac92d66486861b1fe89a1385901499a trytond/modules/stock_product_location (4.2.0-5-g104ec3d) c44893cb3507e761d9900c34345648a1cd763acc trytond/modules/stock_shipment_measurements (heads/develop) da6936a4fce48c014a495068639cb3fd53c7b397 trytond/modules/stock_split (4.2.0-3-gda6936a) e5d026b620625c36898476184ce9b3327a36616a trytond/modules/stock_supply (4.2.0-12-ge5d026b) b190a6c886b0972d928508181a6c63433e3a0b69 trytond/modules/stock_supply_day (4.2.0-3-gb190a6c) a7d9acf4f42771306cd7a5f1b0f545a4963dad9d trytond/modules/stock_supply_forecast (4.2.0-4-ga7d9acf) 3414044824cbd1813f0e62559a28205efded31c4 trytond/modules/stock_supply_production (4.2.0-12-g3414044) ddd172c59c9a9e09e253b59c91198530cd02a14a trytond/modules/timesheet (4.2.0-4-gddd172c) 9fd54b5ee98170144cdeb68854bd90d56c763ba6 trytond/modules/timesheet_cost (4.2.0-3-g9fd54b5) 63db637ad5a22e5986e5d83bf12d5d23e2e84349 trytond/modules/web_user (4.2.0-3-g63db637) 9e2e7a6a7fa67b559d268db87a586f67a212a23c trytond/modules/webdav (4.2.0-4-g9e2e7a6) cheers -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton-dev" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton-dev/f646a0ef-e155-e841-552c-8244b590d9c3%40netbsd.org.
Re: [tryton-dev] github not in sync
Le 27/03/2017 à 00:39, Cédric Krier a écrit : On 2017-03-26 12:54, Richard PALO wrote: Just finally tried to use the github mirror as I'm much more confortable with git, but there seems to be a number of modules either missing or not up to date.. Could you provide the list? Quickly checking, the following seem to be missing: account_deposit account_payment_sepa_cfonb account_tax_rule_country sale_extra sale_stock_quantity stock_lot_sled for those not up to date, there's at least the following: account_dunning* bank sale_invoice_grouping timesheet_cost Also, for those that are there, any particular reason that they aren't added as submodules located in trytond's trytond/modules (admittedly it's not *that* difficult to add them, but still...) What would it bring? What disadvantage could it add? How will it be possible to have only a subset? How will it work with the mirror script? To start with, 'git clone --recursive' brings all submodules (similar to 'hg nclone', I guess). I'm not sure why you would want only a subset, but if a dev only wants to selectively pick submodules, then he would probably not use recursive on the initial clone, then only init/update the module(s) needed. Don't know much about your script, either, but I would imagine you could add whatever hooks you might need into your master git repository that will ultimately pushed to github (and/or bitbucket and/or elsewhere). Cheers, -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton-dev" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton-dev/a5034ba4-bc1e-6051-da0e-fb7c6488baef%40netbsd.org.
[tryton-dev] github not in sync
Just finally tried to use the github mirror as I'm much more confortable with git, but there seems to be a number of modules either missing or not up to date.. Also, for those that are there, any particular reason that they aren't added as submodules located in trytond's trytond/modules (admittedly it's not *that* difficult to add them, but still...) cheers -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton-dev" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton-dev/5f54057e-7958-8a99-44d6-c8ce027b38c7%40netbsd.org.
[tryton] Re: printing moves and journals
Le 24/03/2017 à 12:23, Cédric Krier a écrit : On 2017-03-22 15:42, Richard PALO wrote: I was just stupefied to notice that there seems to be no default way to print a standard account move nor a period journal report. I guess most of our users embraced the dematerialized movement :-) ja, but I need a file to be able to store and/or forward it (but not necessarily print it >:) Could only find doing a date-to-date general journal report which includes all moves in all journals for the date range selected. Has anybody else that missed this functionality already added something? This may answer: https://bugs.tryton.org/issue3696 Great, thanks... I'll take a look this weekend. Cheers, -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton/192b0056-d75c-1bbe-6605-5ef39e03e672%40free.fr.
Re: [tryton] Re: account_invoice reports
Le 24/03/2017 à 09:10, Cédric Krier a écrit : I see only two possibilities: - the report is cached because you are testing on a posted invoice - the "invoice.origins or invoice.reference" is not false. Maybe a space in the reference field. This was my error, I thought that tryton stored the path and not the bytes of the report when modified in Administration->UI->Actions->Reports->Facture If I update upon every change of the model it seems okay. Sorry for the noise. -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton/09009b3c-e889-edc4-1586-346edaf5ccad%40free.fr.
[tryton] Re: account_invoice reports
Another question I have in this report, is I'm trying to avoid printing the 'Reference:' field if empty (mostly client invoices). So I first tried simply putting around the 'Reference:' clause, but it still printed a blank 'Reference:' field. Tried just "invoice.reference" and some other combinations to no avail. Is there some special magic needed to add a guard here? I doubled checked to see that it wasn't using a cached file, and that Reference was indeed empty, so there seems to be something with the logic. -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton/d62c05ef-9899-fa09-015c-fe7f98325835%40free.fr.
[tryton] printing moves and journals
I was just stupefied to notice that there seems to be no default way to print a standard account move nor a period journal report. Could only find doing a date-to-date general journal report which includes all moves in all journals for the date range selected. Has anybody else that missed this functionality already added something? If so, let's see to get it mainlined as soon as possible! cheers, -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton/b9de8244-d075-c616-1b08-dd0fb79e8e3a%40netbsd.org.
[tryton] Re: account_invoice reports
Le 20/03/2017 à 14:03, Richard PALO a écrit : Le 20/03/2017 à 00:19, Cédric Krier a écrit : On 2017-03-19 18:28, Richard PALO wrote: I have some question concerning account_invoice reports: 1. How do I get rid of the last page, which only has a header/footer? As far as I have seen it is a bug in open/libre—office. Reference please to the LO bugreport? work-around? At least temporarily, it seems I can work-around this by deleting the manual page break after '' perhaps it's possible to put the pagebreak in a conditional if invoice <> None upon successif records. cheers -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton/6b906016-dcdb-afa8-10dd-1816d10b50f7%40netbsd.org.
[tryton] Re: account_invoice reports
Le 20/03/2017 à 00:19, Cédric Krier a écrit : On 2017-03-19 18:28, Richard PALO wrote: I have some question concerning account_invoice reports: 1. How do I get rid of the last page, which only has a header/footer? As far as I have seen it is a bug in open/libre—office. Reference please to the LO bugreport? work-around? 2. What would be the references to translate 'VAT:' to 'TVA:' in locale/fr.po for both the company and the client/supplier? It should be the translation of the option of the Selection field type of PartyIdentifier. But I just saw that we used a function for the selection which makes it not translatable. https://bugs.tryton.org/issue6374 ok, I'll test this. 3. I have a need to kick up price_decimal for calculations, but I don't believe it should be the resulting display precision for unit prices, how can I set this to a different value on the report? You can change the format_number call for unit_price to use the digits you want. I see that https://bugs.tryton.org/issue5386 changed the behaviour. Seems perhaps this should be configurable, perhaps on an invoice type basis... e.g. on printed reports, for our case in hand, we would probably always use the currency rounded default of cents, that is 2 decimal digits. 4. In the file store, final format should probably be pdf, is there a way to get pdf stored, eventually a hybrid pdf? It is the result of the report that is stored. So if the report is configured to have pdf as output, it will be stored as-is. In the current form (that is with extra pages) neither revisable nor pdf is correct [yet}. BTW, in the version of OpenERP we are preparing to deprecate, when an invoice is printed, it is simply added to attachments where it can be managed as any other attachment (including being deleted). This would help not only the migration issues as indicated in the filestore topic just prior, but also in fixing the formatting issues of invoices already posted, or even finally adopting pdf when all is ready. In any event it helps nothing to store documents that need[ed] editing into its final format. cheers, -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton/302d4273-b5bd-265b-45b4-89a0d7792ee8%40netbsd.org.
[tryton] account_invoice reports
I have some question concerning account_invoice reports: 1. How do I get rid of the last page, which only has a header/footer? 2. What would be the references to translate 'VAT:' to 'TVA:' in locale/fr.po for both the company and the client/supplier? 3. I have a need to kick up price_decimal for calculations, but I don't believe it should be the resulting display precision for unit prices, how can I set this to a different value on the report? 4. In the file store, final format should probably be pdf, is there a way to get pdf stored, eventually a hybrid pdf? cheers -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton/5c38591e-7f66-5eab-ffe0-e8d514a994e4%40netbsd.org.
[tryton] some questions about account_invoice / attachments
I have the following questions concerning account_invoice (running on trunk, for now) 1. I'm trying the following in trytond.conf but I can't seem to find my invoices on the filesystem: [database] path = /var/lib/trytond ... [account_invoice] filestore = True naturally the server has been restarted, and the process has rw access to /var/lib/trytond Is there somewhere else things need to be turned on? FWIW: Just to be sure, I tried an attachment, and it creates the file in the filestore just fine. 2. Once new invoices work, how to migrate the in-database cached invoices? 3. I noticed that if I add an attachment, then delete it, the file remains in the filestore. Is this expected behaviour? Is there a mechanism to clean the filestore when all references go to zero? (that is, perhaps via a tryton-admin sort of function, not brute force filesystem deletions) 4. Trying with the [attachment] section, I noticed setting store_prefix is parallel to the default, which is the database name. Is there a mechanism to get the prefix to work as a subdirectory of the database name? cheers, -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton/77b818db-06d9-4334-3e67-5f37af979b79%40netbsd.org.
[tryton-dev] Re: performance of chart of accounts?
Le 24/01/2017 à 11:03, Cédric Krier a écrit : On 2017-01-24 07:52, Richard PALO wrote: Le 23/01/2017 à 21:53, Cédric Krier a écrit : On 2017-01-23 07:16, Richard PALO wrote: Are there any tuning remedies? If not, what would things be like if we were to migrate a company with an average of over 5500 movements per year? Normally it should not depend on the number of moves. For me, the slowness is the number of queries but not the computation of the balance/debit/credit. Those computations should be almost linear (with a very small coefficient). Perhaps this could be split up to run parallel by the top (N) level(s), for example, in French PCG, run parallel queries for each class (1 .. 8) or subclass (1[0-8], 2[0-9] et cetera)... I do not think it will improve. There are very few parts that could be run in parallel like the SQL queries (but only if # accounts > 1000) and the cumulate function (but it should normally iterate only once). Also the machineries to make it parallel will probably cost more then it will benefit, without talking about the complexity it will create. Yeah, I can understand diminishing returns... will just have to avoid using + except at low levels... thanks for the explanations. Also, unfortunately it appears that the 'views' still only update the final balance field and not the debit/credit fields. I thought I already filed an issue including that way back but can't seem to find it. Is it on 'purpose' to exclude displaying the total movements debit/credit as well as, Yes it is on purpose (since 1.0). okay, though this makes it awkward online, will have to deal with this via custom reporting. eventually, the initial balance in the chart of accounts? I guess you are looking for the General Ledger instead of the Chart of Account. (which will load much faster as it is a list) in many respects, especially using filters, GL is indeed somewhat more versatile. Now that I try to compare, is there really any reason not to simply replace chart of accounts by reports->general ledger? No it makes no sense as GL is based on the CoA. CoA? The views would/should probably need to be added back, though, as they seem to be missing in both the display and in the reports. Usually, account without moves are not shown on the GL. View accounts have never any moves. But it could be discussed but probably on tryton@ where accounting guys should be. except I can't seem to post any longer neither directly nor via gmane group interface... As to the threaded performance, I've been meaning to check out using uwsgi, but it's still a bit premature to spend time on that for the moment. As I said, it will not help for this specific issue because it is the client who perform sequential request because of the design of GTK expand all feature and the lazy loading of Tryton. I did mean for other use cases, naturally. cheers -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton-dev" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton-dev/o67p6j%24cp8%241%40blaine.gmane.org.
[tryton-dev] Re: performance of chart of accounts?
Le 23/01/2017 à 21:53, Cédric Krier a écrit :
On 2017-01-23 07:16, Richard PALO wrote:
[2nd resend via gmane... googlegroups seems busted as usual]
Nothing to do with google groups, we configured to not allow anonymous
post, only members can. It is configured on gmane if there was still a
web interface.
I'm not so sure, I have [tried to have, anyway] my two primary email addressses
registered via tryton{,-dev,-fr}+subscr...@googlegroups.com with both confirmed.
typically one works or the other (but not both) and neither seem to work
directly any more for some reason...at least not consistently between the
groups.
This one that finally worked was sent to group:gmane.comp.python.tryton.devel
Previously it seemed to be the opposite, I needed to send directly to
tryton*@googlegroups.com
Perhaps related to previous discussion of GL and perhaps of Issue4028 and co,
I have two bookyears in a db now under tryton 4.2 with PCG French
(neither closed yet) and a total of 103 movements (2/3 from older bookyear)
Opening the chart of accounts for the later year (2016), selecting
the only line 'Plan comptable (French)' and doing a full expand ('+')
takes on the average 4 *minutes* on a quiet system!
Full expand is quiet expensive because of the behavior of GTK.
It triggers an event on each node to open them. The client tries to
optimize as much as possible. We load all sibling children of the first
parent at once to minimize the number of queries. But it is a compromise
between manual expand and automatic expand.
It seems to peg a single core on a 32GB 12*core system (2,3G AMD 6338P)
running PostgreSQL 9.6.1 locally and directly on the socket (not the tcp port).
Usual Python threading model. The embedded server is the default
from Werkzeug which is only threaded. For better performance it is
better to use a pre-forked WSGI server.
But for this case, it will not change anything because each queries are
serialized, they depend on the result of the previous to do the next one
(read children to request the second children level).
Are there any tuning remedies? If not, what would things be like if we
were to migrate a company with an average of over 5500 movements per year?
Normally it should not depend on the number of moves. For me, the
slowness is the number of queries but not the computation of the
balance/debit/credit. Those computations should be almost linear (with a
very small coefficient).
Perhaps this could be split up to run parallel by the top (N) level(s),
for example, in French PCG, run parallel queries for each class (1 .. 8)
or subclass (1[0-8], 2[0-9] et cetera)...
Also, unfortunately it appears that the 'views' still only update the final
balance field and not the debit/credit fields.
I thought I already filed an issue including that way back but can't seem to
find it.
Is it on 'purpose' to exclude displaying the total movements debit/credit as
well as,
Yes it is on purpose (since 1.0).
eventually, the initial balance in the chart of accounts?
I guess you are looking for the General Ledger instead of the Chart of Account.
(which will load much faster as it is a list)
Now that I try to compare, is there really any reason not to simply replace
chart of accounts
by reports->general ledger? The views would/should probably need to be added
back, though, as they seem to be missing in both the display and in the reports.
This is particularly frustrating in the French PCG as the account names are
structured 'in context' (check out classe 2 or 6, for example).
Also, I just noticed too that filters don't seem to do much (on name or code)
in the
'chart of accounts' so 'general ledger' seems to much more flexible here.
As to the threaded performance, I've been meaning to check out using uwsgi, but
it's still a bit premature to spend time on that for the moment.
--
Richard PALO
--
You received this message because you are subscribed to the Google Groups
"tryton-dev" group.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tryton-dev/o66tjl%2453o%241%40blaine.gmane.org.
[tryton-dev] performance of chart of accounts?
[2nd resend via gmane... googlegroups seems busted as usual]
Perhaps related to previous discussion of GL and perhaps of Issue4028 and co,
I have two bookyears in a db now under tryton 4.2 with PCG French
(neither closed yet) and a total of 103 movements (2/3 from older bookyear)
Opening the chart of accounts for the later year (2016), selecting
the only line 'Plan comptable (French)' and doing a full expand ('+')
takes on the average 4 *minutes* on a quiet system!
It seems to peg a single core on a 32GB 12*core system (2,3G AMD 6338P)
running PostgreSQL 9.6.1 locally and directly on the socket (not the tcp port).
Are there any tuning remedies? If not, what would things be like if we
were to migrate a company with an average of over 5500 movements per year?
Also, unfortunately it appears that the 'views' still only update the final
balance field and not the debit/credit fields.
I thought I already filed an issue including that way back but can't seem to
find it.
Is it on 'purpose' to exclude displaying the total movements debit/credit as
well as,
eventually, the initial balance in the chart of accounts?
cheers
--
Richard PALO
--
Richard PALO
--
You received this message because you are subscribed to the Google Groups
"tryton-dev" group.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tryton-dev/o6474i%24mkt%241%40blaine.gmane.org.
Re: [tryton-fr] réouverture année/période encore possible dans 4.2?
Le 07/12/2016 à 06:08, Cédric Krier a écrit : On 2016-12-06 19:58, Richard PALO wrote: J'ai remarqué qu'il est [encore] possible de rouvrir une année fiscale ou bien une période déjà clôturée... mais 'La réouverture d’un exercice clôturé à des fins de modification ou de suppression des écritures comptables est interdite conformément aux articles 420-5 et 420-6 du plan comptable général.' (§140 - http://bofip.impots.gouv.fr/bofip/2899-PGP.html?identifiant=BOI-BIC-DECLA-30-10-20-40-20131213) (http://www.plancomptable.com/titre-IV/titre-IV_chapitre-II.htm) Pour moi, il n'y a pas de contradiction avec le comportement de Tryton. À la clôture, Tryton force à ce que tous les mouvements soient postés et donc ces mouvements ne peuvent plus être modifiés ni supprimés. J'ai également noté la possibilité de rouvrir une période même si la période suivante reste clôturée. Toujours pas de contradiction. Par exemple, j'ai pu rouvrir année 2014 (2015 n'étant pas clôturée) puis rouvrir T2 (2014-04 - 2014-06) sans toucher T3, T4 ou la période d'ajustement pour la clôture, rouvrir le journal d'OD. Avec changeset 1812:67e3aefaf68c Remove journal option for updating posted moves This option is in general bad accounting practice and often forbidden in many countries. issue5825 review32481002 on ne peut, heureusement, plus modifier les écritures validées, mais aucun problème pour en ajouter des nouvelles. Ce n'est pas interdit. Gênant si un FEC a déjà été généré et communiqué au service des impôts des entreprises. C'est de la responsabilité de l'utilisateur de ne pas réouvrir une période si le FEC a déjà été soumis. Je me demande si ce ne serait pas judicieux de faire comme d'autres éditeurs en France et désactiver la possibilité de réouverture de l'année une fois l'exercice clôturé pour account_fr. Période aussi? Quid si on clôture par erreur ou bien trop tôt? ... observations? retour d'expériences avec la tolérance (ou bien de l'intolérance) des contrôleurs fiscaux? Je ne vois pas comment il pourrait avoir connaissance tant que l'on fournit des documents cohérents. Selon 2° Principe d’une procédure de clôture périodique des enregistrements chronologiques §130 http://bofip.impots.gouv.fr/bofip/2899-PGP.html?identifiant=BOI-BIC-DECLA-30-10-20-40-20131213 L’alinéa 3 de l'article L. 123-12 du code de commerce énonce que toute personne physique ou morale ayant la qualité de commerçant « doit établir des comptes annuels à la clôture de l'exercice au vu des enregistrements comptables et de l'inventaire. Ces comptes annuels comprennent le bilan, le compte de résultat et une annexe, qui forment un tout indissociable ». Ainsi donc, au terme d’une période de douze mois, exception faite des situations exceptionnelles telles que le premier exercice social ou la cessation d’activité, par exemple, il doit être obligatoirement procédé à la clôture de l’exercice. L’article 420-6 du plan comptable général énonce de même : « Une procédure de clôture destinée à figer la chronologie et à garantir l'intangibilité des enregistrements est mise en œuvre au plus tard avant l'expiration de la période suivante. La procédure de clôture est appliquée au total des mouvements enregistrés conformément à l'article 420-4. Pour les comptabilités informatisées, lorsque la date de l'opération correspond à une période déjà figée par la clôture, l'opération concernée est enregistrée à la date du premier jour de la période non encore clôturée, avec mention expresse de sa date de survenance. » Notamment la dernière phrase qui semble impliquer l'irrégularité de la réouverture d'une période déjà clôturée (_figée_) pour ajouter une opération au lieu de la rajouter au premier jour de la période non clôturée. Voici pourquoi je m'intéresse aux véritables retours de l'expérience quant à la tolérance du fisc, car la sanction pourrait se révéler sévère. Cordialement, -- Richard PALO -- Vous recevez ce message, car vous êtes abonné au groupe Google Groupes tryton-fr. Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/tryton-fr/69a130e1-d6c4-803c-e195-a0d95165b366%40free.fr.
Re: [tryton] Re: version 4 GL & balance reports
Le 04/12/2016 à 12:30, Cédric Krier a écrit : On 2016-12-04 07:59, Richard PALO wrote: As a side note, seems a bit heavy if tryton needs to read all previous years to get starting balance (I most certinaly hope not). It is not heaving and indeed it is even a speedup. I see, account_account_deferral comes in for caching here. Great. 3. with movements (in the period) This could probably be done by creating a Function field that returns the number of moves. seems there should probably also be an option simply to include or not the 'start balance' as well Do you mean that you want to have a column with debit - credit ? Well, for a balance report, it is useful to have either extra column for initial balance, or both debit and credit, but this is probably a simple matter of report formatting which could be site specific. For me, it is not necessary on trial balance because the goal is to show that the accounts are balanced so if start and and balance sum equals 0 and debit equals credit sum, it is OK. To be clear, what I meant about including or not 'start balance' is for the case where an extract is requested of only the mouvements during the period should show up on 'end balance' In this case, 'start balance' column is not used in computing the 'end balance', and needs not be included, but if displayed, the values should necessarily be '0,00'. with 'start balance' Account | Start Balance | Debit | Credit | Debit - Credit - Start Balance (like now) without Account | 0,00 | Debit | Credit | Debit - Credit or simply (facultive) Account | Debit | Credit | Debit - Credit For GL it is typically an additional line prior to the moves for the period. There is already. yes, indeed... but the request is similar. while suppressing the non-intuitive behaviour currently of 4.x selecting by default only the first account. That's default behaviour to select the first record, I do not think it will change. For a report, this is not intuitive though perhaps a 'selection only' option that limits output to what is selected on the screen could continue to provide current behaviour... It is better to have always the same behaviour in the all application. Any action applies on what is selected. Well, normally, selection is an active process. But when these missing filters are available, they can be saved and this process will be much improved. But have you tried to select only used accounts (say 200-300) out of 1200 in e.g. the French accounting plan? Use the filters. I guess that brings us back to the subject at hand ;-) There seems to miss as well a means to be able to select only non-reconciled entries (relative to the accounting year), which appears to be a crucial need expressed by accountants and legal auditors. I do not understand exactly what you mean. For me, there is no sense to care about non-reconciled per fiscal year. Also I do not see the point to care about them individually, we have the Aged Balance for that. Balance is not interesting for this, although auxiliary balance/GL is also necessary, what is expected is a GL *detailing* only non-reconciled entries, typically for year-end (or periodic situation) closing. What is the point? It is useless in Tryton because non-deferral lines stay. Well, as already mentioned prior (I believe in tryton-fr and in the issue tracker), the accountant and legal auditor ask for it, as well as the decision maker who wants a report of only these 'open' entries, for readability purposes. cordially, -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton/cec71e2f-e789-3f28-14cc-a7a631330b46%40netbsd.org.
[tryton] Re: version 4 GL & balance reports
Le 04/12/2016 à 04:06, Cédric Krier a écrit : On 2016-12-03 13:37, Richard PALO wrote: Anybody get further into prototype mode in order to propose a blueprint supporting, in addition to 'all' as is currently: 1. with 'start balance <> 0' and/or 2. with 'end balance <> 0' and/or I think written is quite complex because it is a SQL SUM but with cumulate of previous fiscal year. So I think probably the easiest will be to write a searcher that will filter the records using python evaluation for each record. This is not very performant but it should be OK as the number of account should not be too large. This is what more or less what I concluded. We have easily 20-30K general ledger entries per year (ignoring analytic) which I consider small to medium for an SME. As a side note, seems a bit heavy if tryton needs to read all previous years to get starting balance (I most certinaly hope not). This is one of the benefits of having an annual opening balance as is traditionnally done (not to mention it expressly provides for independent accounting years, a fundamental principle in accounting). In any event, one must not be myopic as to the number of fiscal years. 3. with movements (in the period) This could probably be done by creating a Function field that returns the number of moves. seems there should probably also be an option simply to include or not the 'start balance' as well Do you mean that you want to have a column with debit - credit ? Well, for a balance report, it is useful to have either extra column for initial balance, or both debit and credit, but this is probably a simple matter of report formatting which could be site specific. For GL it is typically an additional line prior to the moves for the period. while suppressing the non-intuitive behaviour currently of 4.x selecting by default only the first account. That's default behaviour to select the first record, I do not think it will change. For a report, this is not intuitive though perhaps a 'selection only' option that limits output to what is selected on the screen could continue to provide current behaviour... But have you tried to select only used accounts (say 200-300) out of 1200 in e.g. the French accounting plan? There seems to miss as well a means to be able to select only non-reconciled entries (relative to the accounting year), which appears to be a crucial need expressed by accountants and legal auditors. I do not understand exactly what you mean. For me, there is no sense to care about non-reconciled per fiscal year. Also I do not see the point to care about them individually, we have the Aged Balance for that. Balance is not interesting for this, although auxiliary balance/GL is also necessary, what is expected is a GL *detailing* only non-reconciled entries, typically for year-end (or periodic situation) closing. There are many examples such as in SAGE, CEGID, Unit4(if I remember well) -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton/44348d34-6f55-7f8c-528c-d2c14083bd5a%40netbsd.org.
[tryton] Re: version 4 GL & balance reports
Le 27/05/2016 à 09:42, Richard PALO a écrit : As indicated https://bugs.tryton.org/issue5168 I'm trying to see how to approach (as suggested) under 4.0 a function field 'searcher' that operates on 'sum' fields as the patch which worked on 3.8 no longer does. The issue is that since 4.0 the balance and GL reports are huge and, as such, somewhat unuseable as they include *all* accounts, including those with a start balance of 0 *and* no movements (D/C). Under the French plan (PCG), I have for example in a company a balance generating 40 pages of output for only 28 accounts usually printing on two pages. NB: there are over 1200 accounts defined in the French plan The General Ledger prints 948 pages (!) mostly throw away. It should be possible to generate [periodic] balance or GL reports including only the movements in the period (thus without start balance) as well. This, unfortunately, has turned into a blocker to migrate production to 4.0 for the moment. How would a 'searcher' be able to do this in the first place? Is there a good example already implemented in the existing modules to take a look at? To me, it still seems more logical to have a global 'default' option 'with start balance' and only, always, generate accounts with movements. (That is, generating 'all' accounts is perhaps something that could better be done from configure->accounts or perhaps a even a new report under account plan) I'd like to solicit other experiences/observations/suggestions from the community. cheers Given that 4.2+ will be the basis for any future platform certification (in particular for purposes of legal requirements in France), I'd like to renew the call to see if anybody has worked on adding the afore mentioned options to general ledger and balance reports. Having not had more than cursory time myself, perhaps a crowd funding approach is more appropriate. We would certainly participate! Anybody get further into prototype mode in order to propose a blueprint supporting, in addition to 'all' as is currently: 1. with 'start balance <> 0' and/or 2. with 'end balance <> 0' and/or 3. with movements (in the period) seems there should probably also be an option simply to include or not the 'start balance' as well while suppressing the non-intuitive behaviour currently of 4.x selecting by default only the first account. There seems to miss as well a means to be able to select only non-reconciled entries (relative to the accounting year), which appears to be a crucial need expressed by accountants and legal auditors. cheers -- Richard PALO -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton/9ec3822d-efbd-b779-cec6-095d4fdf20a9%40netbsd.org.
Re: [tryton-fr] désactivation de l'option 'update_posted' pour PCG français
Le 12/09/2016 à 21:45, Richard PALO a écrit : Le 24/08/16 17:29, Cédric Krier a écrit : On 2015-12-10 13:42, Cédric Krier wrote: On 2015-12-10 06:59, Richard PALO wrote: Observations? Je pense que la fonctionnalité doit être supprimée de base. Pour info: https://bugs.tryton.org/issue5825 +1 backport pour 3.8? en l'absence de https://bugs.tryton.org/issue5168, nous ne pouvons pas encore considérer 4.0 (pas de temps pour chipoter avec ceci, hélas..) -- Richard PALO -- Vous recevez ce message, car vous êtes abonné au groupe Google Groupes tryton-fr. Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/tryton-fr/9d24c303-47ea-82df-9a0c-4bc23f993c38%40netbsd.org.
Re: [tryton-fr] désactivation de l'option 'update_posted' pour PCG français
Le 24/08/16 17:29, Cédric Krier a écrit : > On 2015-12-10 13:42, Cédric Krier wrote: >> On 2015-12-10 06:59, Richard PALO wrote: >>> Observations? >> >> Je pense que la fonctionnalité doit être supprimée de base. > > Pour info: https://bugs.tryton.org/issue5825 > +1 -- Richard PALO -- Vous recevez ce message, car vous êtes abonné au groupe Google Groupes tryton-fr. Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/tryton-fr/57D705CA.408%40free.fr.
[tryton-fr] Re: Loi de finance 2016 et Logiciels Libres (suite).
Pour infos, voici un document récemment publié: http://bofip.impots.gouv.fr/bofip/10691-PGP.html Sa lecture est vivement recommandée. -- Richard PALO -- Vous recevez ce message, car vous êtes abonné au groupe Google Groupes tryton-fr. Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/tryton-fr/57B7280E.20606%40free.fr.
Re: [tryton] Adding validity dates for product supplier price
Le 22/07/16 07:08, Cédric Krier a écrit : >> That highly depends on the industry. In some of them, suppliers update >> prices yearly and the company want the new prices to take effect on the >> right date. It is also interesting in some cases to know when the new >> prices where given by the supplier and what is the expected "expiry" date >> of the price to know if you need to ask for a new quotation or you can >> count on the price you have to make a sale quotation for example. > > Please can you give me an example of such industry? > One common example is any installation service company (electricity, plumbing, HVAC, etc...) -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton/5791AD52.6080104%40netbsd.org.
[tryton] Re: migration from 3.8 -> 4.0 with webdav
Le 06/05/16 18:55, Cédric Krier a écrit : > First, it is trytond-admin that manages now the upgrade. > And clearly you don't have an up to date calendar module. > I asked here primarily for the migration guide. For instance, I find no mention about 'trytond-admin' in the release announcement nor here (at least not what I can find). grepping the Mercurial repository doc/topics/setup_databases.rst indicates only that a database can be initialised with trytond-admin. Yes, my fault for calendar, omitted to update the package list with the new localisations, so 3.8 re-installed instead of 4.0. Updated now via tryton-admin and am trying to get accustomed to the new interface to GL and balance. cheers -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton/572D72DC.6070409%40netbsd.org.
[tryton] migration from 3.8 -> 4.0 with webdav
Is there a 4.0 migration guide that indicates how deal with webdav? I can only find mention of 3.8. I'm experiencing the following (actually --all -d makes no difference) > richard@omnis:/home/richard/src$ trytond2.7 -c trytond.conf --all -d > Traceback (most recent call last): > File "/opt/local/bin/trytond2.7", line 17, in > from trytond.application import app > File "/opt/local/lib/python2.7/site-packages/trytond/application.py", line > 8, in > Pool.start() > File "/opt/local/lib/python2.7/site-packages/trytond/pool.py", line 97, in > start > register_classes() > File "/opt/local/lib/python2.7/site-packages/trytond/modules/__init__.py", > line 362, in register_classes > mod_file, pathname, description) > File > "/opt/local/lib/python2.7/site-packages/trytond/modules/calendar/__init__.py", > line 5, in > from . import caldav > File > "/opt/local/lib/python2.7/site-packages/trytond/modules/calendar/caldav.py", > line 11, in > from trytond.protocols.webdav import TrytonDAVInterface, CACHE, \ > ImportError: No module named webdav I have built trytond_webdav (4.0.1) and installed it, all the other modules used have been updated to 4.0.0 cheers -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton/572CAF39.6080409%40netbsd.org.
Re: [tryton] asset amortisation and 'yearly' frequency
Le 22/04/16 16:23, Cédric Krier a écrit : > Probably the current design is wrong. It should not be based on monthly > or yearly but instead base on period or fiscal year. But then we can not > create forecast as it is highly improbable that fiscal years and periods > will be create years in advance. At the very least there needs to be some impedence matching provided between month/year and period/fiscal year. There are numerous means and reasons behind the depreciation decided upon in a business. If the mechanisms around generating schedules and managing actual moves are simple but rich enough, the it should be able to cater to most needs. That is, as long as the methods to generate the moves allows for: - initial load of an accounting - for fiscal year end (even if changed) - as well as for interim accounting situations (many company elect or have obligation to prepare one) then KISS should probably apply. If there were a requirements needs analysis done, I would wager that the all that is really needed is the 'true' past, and future simulation. A certified accountant or auditor may potentially invoke more specific details, though. The past (prior to tryton-managed depreciation) should be possible to "fix", perhaps as mentioned earlier by updating the first generated move with the date, value, depreciation, and accumulated depreciation where date is the end_date of the period prior to the first tryton managed one...(which may not be necessarily the first tryton fiscal account year). This would allow folks to migrate to tryton managed assets when it suits them. >>>> To be useful, there might need to be an initial annuity date (in >>>> absence of a fiscal year being defined all the way back to the >>>> activation start_date, that is for amortisations in progress in an >>>> accounting system migration) >>> >>> Indeed existing assets could be a problem. >> >> They are as I still have not found any way to get them dealt with. >> Please advise... The initial balance is typically entered with the >> depreciated amounts taken into consideration... >> >> Perhaps a means to create/edit the 'line's with appropriate >> values and some manner to indicate (or force) that the movement >> for these periods are in the initial balance. > > I guess you can just put as value the value already depreciated at the > start date. > I believe to be generally acceptable, perhaps other data still needs to be taken into consideration.. For example, the degressive method coefficient (in France, at least) depends upon such things as the date of activation and the duration... and the coefficient magnitude has influence naturally upon when the linear optimisation kicks in. I still sort of favour, currently at least, special first 'line' entry (or entries) for 'in progress' depreciations. > >> compute_depreciation does not seem use the typical default. >> It appears to use a mix of 30 days per month but actual days per year. >> (Otherwise the monthly amounts would differ under 'linear') > > Patch is welcome. > Well, I'd like to get 'degressive' polished first, I think linear can be 'fixed' and both methods optimised in a future pass. Walk before run? Teething can be painful:-P Nicolas has a copy of the work in progress. Once I get the GUI part reacting better, to me at least, I'll prepare the issue for comments. cheers, -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton/571A566A.601%40netbsd.org.
