Re: [tryton-dev] Deposit accounts on Spanish Chart
El 12/02/18 a les 10:30, Cédric Krier ha escrit: > On 2018-02-12 10:03, Sergi Almacellas Abellana wrote: >>> If we want to use this feature, yes the fs_values must reflect the sum >>> of what was written by the module. >> I'm not sure if it's worth to implement it. Let me explain: Currently we >> are forced to update a record definition of the same module because the >> new kind is not defined on the same module but on another one. The >> problem is that account_es doest not depend on account_deposit and we >> don't want to add the dependency. Normally this is fixed by adding the >> code on a third module that depends on both modules. > I think there are use cases where it will be useful just like the > "depends" attribute on record because it increases the modularity. > Indeed I think we could extend the "depends" to the "field" tag and have > something like this: > > > other > deposit > > > The parser should use the latest value matching the condition. > Ok I see your point and I agree that this will improve the modularity of the system. JFR, I've created an issue to implement it: https://bugs.tryton.org/issue7127 And also updated the spanish chart of accounts to use it: https://bugs.tryton.org/issue7126 -- Sergi Almacellas Abellana www.koolpi.com Twitter: @pokoli_srk -- 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/68d2761c-9b99-0f78-d65b-2dc493dc86bc%40koolpi.com.
Re: [tryton-dev] Deposit accounts on Spanish Chart
On 2018-02-12 10:03, Sergi Almacellas Abellana wrote: > > If we want to use this feature, yes the fs_values must reflect the sum > > of what was written by the module. > I'm not sure if it's worth to implement it. Let me explain: Currently we > are forced to update a record definition of the same module because the > new kind is not defined on the same module but on another one. The > problem is that account_es doest not depend on account_deposit and we > don't want to add the dependency. Normally this is fixed by adding the > code on a third module that depends on both modules. I think there are use cases where it will be useful just like the "depends" attribute on record because it increases the modularity. Indeed I think we could extend the "depends" to the "field" tag and have something like this: other deposit The parser should use the latest value matching the condition. > I don't think there are so much uses cases for defining the same record > (with different values) on two different modules. Indeed I can not see > any other usage that fixing this issue. No because it is an hack but having values depending on the modules is a use case. > For me it will be simpler to define the deposit kind on the account > module (so CoA modules can define accounts with the deposit kind). I > don't see any drawback of allowing this kind on the account module. I think it is a too simple solution which does not scale. On another point of view, the kind attribute is maybe the problem. A selection field is maybe too limited and we may need a multiselection. But using a Many2Many field will not be good for performance so we may need to find a way to create MultiSelection fields. -- Cédric Krier - B2CK SPRL Email/Jabber: cedric.kr...@b2ck.com Tel: +32 472 54 46 59 Website: http://www.b2ck.com/ -- 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/20180212093016.GN24410%40kei.
[tryton] not callable
I am creating some new calculated fields, running tests along the way
The last one of such fields is giving me troubles
This is the result of running the tests
.F
==
FAIL:
/home/catonano/tributi/build/lib/trytond/modules/tributi/tests/scenario_affissioni.rst
Doctest: scenario_affissioni.rst
--
Traceback (most recent call last):
File "/usr/lib64/python3.6/doctest.py", line 2199, in runTest
raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for scenario_affissioni.rst
File
"/home/catonano/tributi/build/lib/trytond/modules/tributi/tests/scenario_affissioni.rst",
line 0
--
File
"/home/catonano/tributi/build/lib/trytond/modules/tributi/tests/scenario_affissioni.rst",
line 77, in scenario_affissioni.rst
Failed example:
bolletta.lines.append(unaAffissione)
Exception raised:
Traceback (most recent call last):
File "/usr/lib64/python3.6/doctest.py", line 1330, in __run
compileflags, 1), test.globs)
File "", line 1, in
bolletta.lines.append(unaAffissione)
File
"/home/catonano/tributi/env/lib/python3.6/site-packages/proteus/__init__.py",
line 553, in append
self.__check([record])
File
"/home/catonano/tributi/env/lib/python3.6/site-packages/proteus/__init__.py",
line 548, in __check
setattr(record, self.parent_name, self.parent)
File
"/home/catonano/tributi/env/lib/python3.6/site-packages/proteus/__init__.py",
line 260, in __set__
super(Many2OneDescriptor, self).__set__(instance, value)
File
"/home/catonano/tributi/env/lib/python3.6/site-packages/proteus/__init__.py",
line 129, in __set__
instance._on_change([self.name])
File
"/home/catonano/tributi/env/lib/python3.6/site-packages/proteus/__init__.py",
line 1076, in _on_change
context)
File
"/home/catonano/tributi/env/lib/python3.6/site-packages/proteus/config.py",
line 164, in __call__
raise TypeError('%s is not callable' % self._name)
TypeError: on_change_with_risultatoRigo is not callable
--
Ran 14 tests in 16.610s
FAILED (failures=1)
why is it not callable ?
It's no different than many other methods and they are all callable
It' s here
https://gitlab.com/humanitiesNerd/tributi/blob/master/affissione.py#L165
Thanks in advance
--
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/5dc6375b-3ed0-47dc-827e-f1125daaed35%40googlegroups.com.
Re: [tryton] lineas attributes don' t get updated
Il giorno mercoledì 7 febbraio 2018 23:15:07 UTC+1, Cédric Krier ha scritto: > On 2018-02-01 07:47, Cato Nano wrote: > > So, in Proteus I am seeing this sequence of lines > > > > In [52]: bolletta.tipo > > Out[52]: 'sociale' > > > > In [53]: aff.bolletta.tipo <-- aff is a bolletta line > > Out[53]: 'sociale' > > > > In [54]: bolletta.tipo = 'commerciale' > > > > In [55]: bolletta.save() > > > > In [56]: bolletta.tipo > > Out[56]: 'commerciale' > > > > In [57]: aff.bolletta.tipo > > Out[57]: 'sociale' > > > > > > it seems like the line doesn't get updated > > > > Is this expected ? > > If I understand correct, yes it is expected. > When you save a parent record, the existing instance of the children are > not refreshed. You must do it manually by calling .reload or get the new > instance from the parent. > Ok, thanks -- 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/3d1067d1-4604-49b2-bc3f-bb65995e266a%40googlegroups.com.
Re: [tryton] numeric values
Il giorno lunedì 29 gennaio 2018 20:30:20 UTC+1, Cato Nano ha scritto: > Il giorno lunedì 29 gennaio 2018 10:35:08 UTC+1, Cédric Krier ha scritto: > > On 2018-01-28 02:43, Cato Nano wrote: > > > In my numeric calculated fields I should record 4 decimal digits but I > > > should show only 2 decimal digits in my views > > > > > > How can I achieve that ? > > > > You can not display a field with a different value than its value > > otherwise the client will change it and save this new value to the > > server. > > > > Indeed what you want is to show another field which has its value > > derived from the original one. This can be done using a Function field. > > > > interesting. Thanks. I' ll try tomorrow well, it took me a few more days But I followed your suggestion Thanks -- 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/be7818a1-7207-4219-b008-f1ee9f566ba3%40googlegroups.com.
Re: [tryton-dev] Deposit accounts on Spanish Chart
El 08/02/18 a les 20:23, Cédric Krier ha escrit: > On 2018-02-08 16:50, Sergi Almacellas Abellana wrote: >> El 07/02/18 a les 18:22, Cédric Krier ha escrit: >>> On 2018-02-07 18:01, Sergi Almacellas Abellana wrote: El 07/02/18 a les 17:51, Cédric Krier ha escrit: > On 2018-02-07 17:27, Sergi Almacellas Abellana wrote: >> El 07/02/18 a les 16:43, Cédric Krier ha escrit: >>> On 2018-02-07 16:26, Sergi Almacellas Abellana wrote: Hi, The account_deposit module defines a new kind of account (Deposit account) but there is no deposit account on the Spanish CoA. After a little bit of digging i found that the Spanish CoA includes deposit accounts for customers (4380) and suppliers (4070), so this accounts should be marked as deposit. This requires to add the account_deposit as dependency of the account_es module, but not sure if this is the best way as this module also adds new functionaly on party and invoice which is not relevant to people not using the deposit functionaly. >>> You may put those account inside a extra depend module. >> The main issue here is that this account should be included on the >> balance sheet so probably the best is to use the deposit kind when the >> account_deposit module is installed and the other type when not >> installed. > I do not think it is possible to do that. I've achieved it by adding the the following code at the end of the xml definition: >>> update="1"> deposit >>> update="1"> deposit >>> Are you sure that the ir.model.data is correct when the module >>> account_deposit is activated? >> fs_values only contains the values of the last update (kind and >> party_required) but other fields are not computed. Which if i understand >> correctly this is not correct. >> >> Is this something that we should fix? > If we want to use this feature, yes the fs_values must reflect the sum > of what was written by the module. I'm not sure if it's worth to implement it. Let me explain: Currently we are forced to update a record definition of the same module because the new kind is not defined on the same module but on another one. The problem is that account_es doest not depend on account_deposit and we don't want to add the dependency. Normally this is fixed by adding the code on a third module that depends on both modules. I don't think there are so much uses cases for defining the same record (with different values) on two different modules. Indeed I can not see any other usage that fixing this issue. For me it will be simpler to define the deposit kind on the account module (so CoA modules can define accounts with the deposit kind). I don't see any drawback of allowing this kind on the account module. -- Sergi Almacellas Abellana www.koolpi.com Twitter: @pokoli_srk -- 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/46fa92e1-0961-7cfe-3b26-72c89365a961%40koolpi.com.
