virement instead of check payment.

Using my Dolibarr
1

Hi all
Maybe a bug here
I enter a payment for a supplier using cheque as payment method
when I accept the transaction it is inserted in the table as VIR type.
I have then to manually edit the transaction to change from VIR to CHK.
i dont know if it is a dictionary setup problem but seems to be malfunctioning to me.
Tanks for any help on this
Regards
alejandro

2

Do you have pb with 2.8 ?
Can you reproduce on demo.dolibarr.org ?

3

Dolibarr 2.8 in production install (another dolibarr 2.9 testing purposes)
I can´t reproduce in demo.
I’ll recheck dictionaries setup and repost here if found anything wrong.

4

Additional information on this
When I open “do payment” Virement is the deffault payment method that shows preselected in de dropdown list.
While in the online demo it is not the same, there is no deffault, you have to choose when you do the payment.
but even when I choose checque, is inserted as Virement.

I’ll make a full review of the system and maybe a reinstallation.
regards
alejandro

5

check in your dictionnary that you have a line with status “Always active” and a label “-”.

6

Thanks for helping me…

I do not have such line , and I don’t have a “VIR” paiement type defined in my llx_c_paiement table of database either…

7

Hi!
Thanks Eldy again for your answer, it leaded me to figure out the cause of this issue.
I think I’ve found what’s going on…
Problem is as follows:
We have modified, through the dictionary configuration process, the table of payment methods to suit our needs, laws, and bank reccords… so that payment transactions should have the name and code we need, but this is the confusing thing: Dolibarr is using table position ID “equivalence” to rename transactions.
I think that here there is a missleading concept:
As dolibarr changes languajes it also changes the “libelle”(description) asigned to a code of an ID of table llx-c-paiement.
In my humble opinion: (I should remmark humble because I neither have enough programming knowledge nor English fluent languaje skills to even explain myself better):
If you have something customizable by dictionary setup method, translation should be voided.
If you have an excellent customization method such as dictionary setup variables, browser translation is not needed at all for this values.
further more, if I’ve changed or deleted VIR code, and in fact it doesen’t even exist in my dictionary setup, why dolibarr uses my new coded CHK nº 2 ID to change payment method from CHK code to old nº2 ID and VIR code that, (I repeat) doesn’t even exist in my config.
My concerns now are:
should I revert back everything and use only codes provided by dolibarr, or can I customize my own codes and descriptions as I did…?
I know that maybe this is not a simple problem.
I really need some help on this i can edit the database and revert to factory deffault ID and codes but I thing there is something wrong…

As always: Many Thanks in advance for any help or thought on this
and of course any advice is wellcome.
Regards
Alejandro

8

“I really need some help on this.
I can edit the database and revert to factory deffault payments IDs and codes but I thing there is something wrong…”

I’m still thinking about this, and I dont Know which way is better.

Any help?

9

Dolibarr use the code to find a label
List of predefined codes are

insert into llx_c_paiement (id,code,libelle,type,active) values (0, ‘’, ‘-’, 3,1);
insert into llx_c_paiement (id,code,libelle,type,active) values (1, ‘TIP’, ‘TIP’, 2,1);
insert into llx_c_paiement (id,code,libelle,type,active) values (2, ‘VIR’, ‘Virement’, 2,1);
insert into llx_c_paiement (id,code,libelle,type,active) values (3, ‘PRE’, ‘Prélèvement’, 2,1);
insert into llx_c_paiement (id,code,libelle,type,active) values (4, ‘LIQ’, ‘Espèces’, 2,1);
insert into llx_c_paiement (id,code,libelle,type,active) values (5, ‘VAD’, ‘Paiement en ligne’, 2,0);
insert into llx_c_paiement (id,code,libelle,type,active) values (6, ‘CB’, ‘Carte Bancaire’, 2,1);
insert into llx_c_paiement (id,code,libelle,type,active) values (7, ‘CHQ’, ‘Chèque’, 2,1);
insert into llx_c_paiement (id,code,libelle,type,active) values (8, ‘TRA’, ‘Traite’, 2,0);
insert into llx_c_paiement (id,code,libelle,type,active) values (9, ‘LCR’, ‘LCR’, 2,0);
insert into llx_c_paiement (id,code,libelle,type,active) values (10,‘FAC’, ‘Factor’, 2,0);
insert into llx_c_paiement (id,code,libelle,type,active) values (11,‘PRO’, ‘Proforma’, 2,0);

You can reset the table, however, child tables use the id to link to this table. Link to this table for an invoice payment is field fk_paiement in table llx_paiement_facture.

10

Thanks Eldy…
Finally we found out what is wrong, it’s is in fact a bug!
In “account.class.php” (in adline() function) The value of $oper is hardcoded using a switch : switch ($oper) { case 1: $oper = 'TIP'; break; case 2: $oper = 'VIR'; break; case 3: $oper = 'PRE'; break; case 4: $oper = 'LIQ'; break; case 5: $oper = 'VAD'; break; case 6: $oper = 'CB'; break; case 7: $oper = 'CHQ'; break; }

So the values of llx_c_paiement aren’t being used for llx_bank table
By the way, is there any special reason for referring llx_c_paiement.Code instead of llx_c_paiement.id in llx_bank.fk_type?
I think (my humble opinion) these values should have been taken from there.

Any way now I have a serious problem trying to translate database to meet my own requirements cause of this, I think it could be fixed to avoid this misslinked codes and IDs

Hope this help
Regards
Alejandro

11

Good news. Thanks for report.
It seems that bug has been silently corrected with CVS version.
Translation between id and code is no more hard coded.