Archives
Contributors
-
Re: Migration to v14 requirement - readony / invisible
On Sun, Oct 18, 2020 at 4:22 PM Pedro M. Baeza (Tecnativa) <pedro.baeza@tecnativa.com> wrote:so the sentence is correct. It seems the only exception is to get the value from the context (example: `invisible=context.get("key")`).So, are you saying that we can accept dynamic expressions as that one contained in https://github.com/odoo/odoo/blob/d9b794480a5ab7f7d6a1e0d92601eb737175e212/addons/account/views/account_move_views.xml#L413 ?--Alex Comba
Tel (CH): +41 91 210 23 40
by Alex Comba. - 03:35 - 28 May 2021 -
Re: [Compta] Generation des FEC et non assujetti TVA
Hi Mathieu,Alexis De lattre (OCA responsible of l10n_france) worked today on that point (it seems) for v14.Could you review and talk on this PR ? https://github.com/OCA/l10n-france/pull/288kind regards.GRAP - Service informatique (Groupement Régional Alimentaire de Proximité)Site Web | FramaSphere | Facebook
3 Grande rue des Feuillants, 69001 Lyon
Standard : (+33) 09.72.32.33.17Service Informatique : (+33) 09.73.79.64.40Astreinte Informatique : (+33) 06.81.85.61.43Member of the OCA (Odoo Community Association)Le jeu. 27 mai 2021 à 10:26, Mathieu C. <mathieu@matmicro.net> a écrit :Hello,(English below)J'utilise une version Odoo 10, pour une entreprise qui n'est pas assujettie à la TVA, comment générer les Fichiers d'Ecriture Comptable (FEC) ?
Actuellement le systeme oblige à rentrer un numéro de TVA.
Impossible de générer le FEC sans numéro de TVA.
Quelle est la méthode pour y remèdier ?Cordialement
------- (English version)I am using an Odoo 10 version, for a company that is not subject to VAT, how do I generate the Accounting Entry Files (FEC)?
Currently the system requires entering a VAT number.
Cannot generate FEC without VAT number.
What is the method to remedy it?Regards--Mathieu_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Sylvain LE GAL - 11:01 - 28 May 2021 -
Re: [Compta] Generation des FEC et non assujetti TVA
You're right, generating FEC should also work for companies without VAT.I fixed it in this PR on l10n_fr_fec_oca (the OCA "improved" version to generate FEC) for odoo v14.0 :You can backport it to v10, it's very easy.AlexisLe jeu. 27 mai 2021 à 10:26, Mathieu C. <mathieu@matmicro.net> a écrit :Hello,(English below)J'utilise une version Odoo 10, pour une entreprise qui n'est pas assujettie à la TVA, comment générer les Fichiers d'Ecriture Comptable (FEC) ?
Actuellement le systeme oblige à rentrer un numéro de TVA.
Impossible de générer le FEC sans numéro de TVA.
Quelle est la méthode pour y remèdier ?Cordialement
------- (English version)I am using an Odoo 10 version, for a company that is not subject to VAT, how do I generate the Accounting Entry Files (FEC)?
Currently the system requires entering a VAT number.
Cannot generate FEC without VAT number.
What is the method to remedy it?Regards--Mathieu_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Alexis de Lattre - 11:01 - 28 May 2021 -
question about payroll and attendance
Hello, I was wondering if there can be a link between payroll and attendances (hr.attendance) in Odoo ? The payroll module has a link with attendance (work calendar attendences) but not hr.attendences, AFAICT, so it seems weird to not be able to record overtime. But maybe I'm missing something obvious? -- Alexandre Fayolle Senior Software Engineer Tel : +33 4 58 48 20 30 Camptocamp France SAS 18 rue du Lac Saint André 73 370 Le Bourget-du-Lac France http://www.camptocamp.com
by Alexandre Fayolle - 11:06 - 27 May 2021 -
Problem with fiscal year starting on 1 October to 30 September and
Odoo BI Report
Dear community,For the fiscal year that starts from October and ending September. So, on the Odoo BI view, we expect to see that 2021 / Q1 means 1 October to 31 December.I think this is not possible in Odoo, as it only use "Date" to interpret the report, right?To achieve the expected result, I can only think of adding fiscalyear_id, and quarter as computed stored field in every models needed, which is very inefficient.Anyone have better way to achieve this?Many thanks,Kitti U.
by Kitti Upariphutthiphong - 05:01 - 26 May 2021 -
Re: Discover the OCA priorities for 2021 proposed by the board
Ok, I'm agree with you too.Now, I'm understanding that the documentation project take in account many things, besides Functional/Technical docs, like:- Transversal topics ( queue, connector, connector-odoo2odoo ...) depending the Business Objectives and the Technical requirements, so it depends on the specific implementation. So, maybe some sections with recipes for different Business Cases should be appreciate.- Versioning documentation is another gap, for example ReadTheDocs, like many others, manage versioning/branching/languages... and can be integrated with GitHub easily.I appreciate your answers,El lun, 24 may 2021 a las 11:42, Jairo Llopis (<jairo.llopis@tecnativa.com>) escribió:I agree with Tom.Also, having that /docs folder would make migrations even harder. Would make it very hard to find docs of several modules. Would force us to maintain one docs version per module version.El sáb, 22 may 2021 a las 18:42, Tom (<tom@sunflowerweb.nl>) escribió:I am with you except for 1 thing: I think documentation is central and not tied to specific repositories. Because if you want to make a doc about one topic such as "syncing data" it will involve many repositories: queue, connector, connector-odoo2odoo, server-tools, bank-statement, edi....
The e-learning system is good but it is not so strong in wiki-like editing.
The "Migration" docs and "OCA guidelines" have become powerful docs that are much referred to; i think a central place such as that would be better for the docs, and then organized per each topic. Either on Github Wiki or on Github pages.
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--Jairo Llopis_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--
by Juan Del Castillo Gómez - 02:31 - 24 May 2021 -
Re: v14 accounting changes
I'm not actually using v14, but I've play with it a little bit some time ago and there were some things that IMHO where a loss (between v13 and v14).- Now a payment only impacts the outstanding account (cash and bank journals). So, to see the actual balance of those journals
- you must use statements (I like statements but I don't like to be force to use them on all customers and all journals)
- after the v14 release, odoo add a patch that allows you to select the same journal liquidity account as the outstanding account as a way to bypass the outstanding. If you do so:
- The journal dashboard gives wrong data
- you can't use statements for this journal, and if you decide to use them later you are not going to be able to reconcile any previous payment.
- also, the setup to bypass outstanding is not user friendly
- payment + reconcile later vs paying from reconciliation
- In the previous version, if you pay from a bank statement a bill (black line) or if you create the payment and later reconcile it (blue line) the behaviour was the same, one payment. The only difference was the workflow
- on v14, if you create the payment and reconcile later you will have one payment + one statement journal entry. If you pay from the statement you only have one journal entry
- I don't like it because:
- what odoo is doing is not the same regarding the workflow
- If you pay from statements you don't have a payment so you won't see the payment on your payments lists and also you can't send a receipt/payment
- If we make the payment before we have 2 journal entries (the one from the payment plus the one from the statement) for the same operation. In previous version being one journal entry was clearer for me
That's my quick feeback for v14 reconciliationEl vie, 21 de may. de 2021 a la(s) 12:27, Oleg Kuryan (oleg.kuryan@xpansa.com) escribió:I agree with Pedro. I do not see problem statement in an email. Moreover in all above features I see only pluses that finally started to work properly.--On Fri, 21 May 2021 at 17:42, Pedro M. Baeza (Tecnativa) <pedro.baeza@tecnativa.com> wrote:Unless you specify the problems, I don't see such problems in the new "features", except train users on them.If you go to specific things, then the debate can go on. You can do it by topic for not getting a laberintic thread.Regards._______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
///Best Regards,
Oleg Kuryan/// CEO & COO | ventor.tech | Building Personalized Inventory and Product Management System
/// mail : oleg.kuryan@xpansa.com
/// phone : +375293358638
/// skype : kuryan.oleg_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Juan José Scarafía - 12:45 - 23 May 2021 -
Re: Discover the OCA priorities for 2021 proposed by the board
Hi Contributors,
I don't hesitate contribute with my strategical vision and I suggest it:
- Create one /docs folder per repository instead in readme ( and point the readme to docs page )
- One subfolder for technical documentation and another with functional with only the markdown files.
- In /docs folder create a static web page with any generator and render and host it with GitHub pages.
- Create one subdomain per repository pointing to webpage. In this way, making it web page is more searchable and accesible to people.
- To Centralize all the How-To set up the e-learning module at OCA system.
- In the e-learning module you can point content to each subdomain with each web page, in a embeded web page way.
- In this way you can create a course path for functional or technical documentation based on this embeded web pages.
This is my approach, with the e-learning system you can also do gamification, certification and promote the OCA mission.El vie, 19 mar 2021 a las 21:57, Virginie Dewulf (<virginie@coopiteasy.be>) escribió:Hi Tom and other contributors,Thanks a lot for your feedback! This post received a very nice welcome, it's really motivating!I keep note of your ideas about helping functional people get involved and participate to communicate the high value of OCA modules.If you're motivated for the first article (we can decide later on which platform/way of keeping this content) about the import/export module, that could be a first content to directly try and see how to diffuse it!We can keep in touch (outside from this mailing list).To the other contributors: if any other ideas/comments come to your minds, don't hesitate!Have a nice end of week and super cool week-end!Virginie0477/64.17.20-------- Message initial --------De: Tom Blauwendraat <tom@sunflowerweb.nl>Répondre à: Odoo Community Association (OCA) Contributors <contributors@odoo-community.org>À: Contributors <contributors@odoo-community.org>Objet: Re: Discover the OCA priorities for 2021 proposed by the boardDate: Wed, 17 Mar 2021 09:47:32 -0000PS. Instead of blogs, which are perhaps a bit flighty and lose their actuality value over time, it could also be some kind of permanent wiki or github-based website, which is updated and community-reviewed as time goes by, with the latest insights per functional topic and Odoo version.
Anyway, ideas ideas... good luck in the new board for 2021!
Op 3/17/21 om 10:38 AM schreef Tom Blauwendraat:
Hi Virginie
In the post you are mentioning people to react below the blog post, but I can't... so then here:
As a part of communication - maybe a method can be to make a platform that facilitates functional people to write attractive documentation/blogs/howto's about solving Odoo problems with OCA modules. For one, this could supplement the thorough lack of documentation on Odoo CE; but also, if consultants and clients read these blogs with examples and understand better that OCA modules are better than alternatives, because they:
- usually solve problems in the best way, as there is hard-won community consensus on their design
- are designed to interoperate together as a holistic eco-system
- are extendible (even better than most Odoo modules are)
- are quality-controlled
- are OpenUpgradable
- etc.
Then they would understand better why it can be commercially more interesting to choose OCA modules and avoid technical debt, then go for the latest and greatest Odoo version supported by some crude customizations and App Store modules, and become disappointed in Odoo in the long run. And then, they would also become motivated to financially support OCA.
A case in point is for example the import/export modules in the "queue" repository - I'm seeing so many inferior hand-rolled syncing implementations lately, that I'm very motivated to write a furious blog to tell everyone to stop doing that and build on the OCA solution. But now, aside from starting my own blog on the subject, I wouldn't know where to place such an article.
Tom
Op 3/17/21 om 10:12 AM schreef Virginie Dewulf:
Hello contributors,
Here is our latest blog post to present the 2021 OCA priorities proposed by the Board:
Don't hesitate to come back to us/me if you'd like to give your feedback!
Have a nice day,--
Virginie for the Board_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--
by Juan Del Castillo Gómez - 04:41 - 22 May 2021 -
Re: v14 accounting changes
I agree with Pedro. I do not see problem statement in an email. Moreover in all above features I see only pluses that finally started to work properly.--On Fri, 21 May 2021 at 17:42, Pedro M. Baeza (Tecnativa) <pedro.baeza@tecnativa.com> wrote:Unless you specify the problems, I don't see such problems in the new "features", except train users on them.If you go to specific things, then the debate can go on. You can do it by topic for not getting a laberintic thread.Regards.
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
///Best Regards,
Oleg Kuryan/// CEO & COO | ventor.tech | Building Personalized Inventory and Product Management System
/// mail : oleg.kuryan@xpansa.com
/// phone : +375293358638
/// skype : kuryan.oleg
by Oleg Kuryan - 05:25 - 21 May 2021 -
Re: v14 accounting changes
Unless you specify the problems, I don't see such problems in the new "features", except train users on them.If you go to specific things, then the debate can go on. You can do it by topic for not getting a laberintic thread.Regards.
by Pedro M. Baeza - 04:40 - 21 May 2021 -
v14 accounting changes
Hi all,
We started to take a closer look at the v14 accounting.
We are not delighted…to put it mildly.
We were wondering if any of you had something ongoing or planned to address some of the following points that we have encountered so far:
* Major changes in the taxe logic
* Use of a transit account in the bank reconcile process
* Cancel state of accounting entries
* Creation of entries that are then cancelled when a draft invoice is cancelled
On a more general basis, how do you plan to approach the migration to v14 for the accounting part considering the risk?
Looking forward to hear your insights,
Thanks!--
Quentin Lavallee - Chargé de projetsNUMIGI SOLUTIONS INC.(514) 317-7944Longueuil, Québec, Canada
by Quentin Lavallée-Bourdeau - 04:31 - 21 May 2021 -
Re: Migration to Odoo 14: replacing size attribute of Char field
The warning is from Odoo, not from linters, so #noqa is not valid.El vie., 21 may. 2021 14:52, Graeme Gellatly <gdgellatly@gmail.com> escribió:I think if the use case is valid and no convenient good alternative exists then the easiest solution is# noqawith a note.On Sat, May 22, 2021 at 12:16 AM Dominique k <dominique.k@elico-corp.com.sg> wrote:how about api.onchange ?it would work on form modification.--On Fri, 21 May 2021 at 6:57 PM, Simone Rubino <simone.rubino@agilebg.com> wrote:Hi all,I am migrating some modules to version 14 following https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-14.0 but there is:
Remove size=X attribute in Char fields, as it's no longer valid for restricting the size of the strings.
that I don't know how to satisfy.The attribute size=X still works fine in Odoo 14 with also the UI limitation so I believe this comes from https://github.com/odoo/odoo/blob/1c39814bd729cc08882f1545c7d88b0592e63f9a/odoo/fields.py#L1608 but as far I can see, it has always been deprecated (at least from https://github.com/odoo/odoo/commit/524bb0a52027ec81245750bb5f0a9e5320faf922), so is there any reason for this to be explicitly mentioned in Odoo 14 migration?I know I could add an `api.constrains` but this looks to me like overkill since I believe constraints should be used for more complex conditions.Moreover: `api.constrains` does not add any limitation in the UI, so it is not as user-friendly as the attribute size=X that does not allow the user to input more than X characters.I should then add also something in every view showing the Char field (hopefully just an option for the Char widget), but it still seems too much work for such an easy requirement.This said, what is a valid alternative to the size=X attribute?Thanks,Simone Rubino_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
Dominique KON-SUN-TACK [Project Manager]Odoo Gold Partner, best Odoo Partner 2014 for APACMobile: + 65 8502 2399Skype: dominique_elicoWebsite: www.elico-corp.com
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Pedro M. Baeza - 03:00 - 21 May 2021 -
Re: Migration to Odoo 14: replacing size attribute of Char field
I think if the use case is valid and no convenient good alternative exists then the easiest solution is# noqawith a note.On Sat, May 22, 2021 at 12:16 AM Dominique k <dominique.k@elico-corp.com.sg> wrote:how about api.onchange ?it would work on form modification.--On Fri, 21 May 2021 at 6:57 PM, Simone Rubino <simone.rubino@agilebg.com> wrote:Hi all,I am migrating some modules to version 14 following https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-14.0 but there is:Remove size=X attribute in Char fields, as it's no longer valid for restricting the size of the strings.
that I don't know how to satisfy.The attribute size=X still works fine in Odoo 14 with also the UI limitation so I believe this comes from https://github.com/odoo/odoo/blob/1c39814bd729cc08882f1545c7d88b0592e63f9a/odoo/fields.py#L1608 but as far I can see, it has always been deprecated (at least from https://github.com/odoo/odoo/commit/524bb0a52027ec81245750bb5f0a9e5320faf922), so is there any reason for this to be explicitly mentioned in Odoo 14 migration?I know I could add an `api.constrains` but this looks to me like overkill since I believe constraints should be used for more complex conditions.Moreover: `api.constrains` does not add any limitation in the UI, so it is not as user-friendly as the attribute size=X that does not allow the user to input more than X characters.I should then add also something in every view showing the Char field (hopefully just an option for the Char widget), but it still seems too much work for such an easy requirement.This said, what is a valid alternative to the size=X attribute?Thanks,Simone Rubino_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
Dominique KON-SUN-TACK [Project Manager]Odoo Gold Partner, best Odoo Partner 2014 for APACMobile: + 65 8502 2399Skype: dominique_elicoWebsite: www.elico-corp.com_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Graeme Gellatly - 02:51 - 21 May 2021 -
Re: Migration to Odoo 14: replacing size attribute of Char field
how about api.onchange ?it would work on form modification.--On Fri, 21 May 2021 at 6:57 PM, Simone Rubino <simone.rubino@agilebg.com> wrote:Hi all,I am migrating some modules to version 14 following https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-14.0 but there is:Remove size=X attribute in Char fields, as it's no longer valid for restricting the size of the strings.
that I don't know how to satisfy.The attribute size=X still works fine in Odoo 14 with also the UI limitation so I believe this comes from https://github.com/odoo/odoo/blob/1c39814bd729cc08882f1545c7d88b0592e63f9a/odoo/fields.py#L1608 but as far I can see, it has always been deprecated (at least from https://github.com/odoo/odoo/commit/524bb0a52027ec81245750bb5f0a9e5320faf922), so is there any reason for this to be explicitly mentioned in Odoo 14 migration?I know I could add an `api.constrains` but this looks to me like overkill since I believe constraints should be used for more complex conditions.Moreover: `api.constrains` does not add any limitation in the UI, so it is not as user-friendly as the attribute size=X that does not allow the user to input more than X characters.I should then add also something in every view showing the Char field (hopefully just an option for the Char widget), but it still seems too much work for such an easy requirement.This said, what is a valid alternative to the size=X attribute?Thanks,Simone Rubino_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
Dominique KON-SUN-TACK [Project Manager]Odoo Gold Partner, best Odoo Partner 2014 for APACMobile: + 65 8502 2399Skype: dominique_elicoWebsite: www.elico-corp.com
by dominique.k - 02:11 - 21 May 2021 -
Re: Migration to Odoo 14: replacing size attribute of Char field
If I don't remember bad, there's a warning logged saying the size is deprecated, and that's why it's included in the migration guide.I think the alternative is to put it on the view, not on the field.Regards.
by Pedro M. Baeza - 01:01 - 21 May 2021