Skip to Content
  2. Mailing Lists
  3. Contributors

Archives

Contributors

  • Re: suggestion for monitoring error 500
    Hi Dominique

    If you have Odoo running behind NGINX, you can parse the access log file to get some statistics about the timestamps around which this occurs, and on which urls. I have a way of doing that with command line tools such as "awk", "sort" and "uniq" (for hourly statistics), but regular "grep" can also yield you the info.

    Armed with that knowledge you can then check the Odoo log file around those times, sometimes it will also display "Internal error" or even a useful traceback, and you can then use "grep" again to extract relevant patterns over the course of a day or so.

    If not enough information is given, then you could resort to modifying the Odoo source code to add some more exception-catching.

    1 mei 2023 06:57:22 Holger Brunn <notifications@odoo-community.org>:

    > It is a bit of a catchall... Would anybody have any suggestion, to monitor

> such error, and possibly get an email, or a warning as a system

> administrator? Is there a way to catch at odoo level, if there is such

> error and send an email ?

all requests go through
https://github.com/OCA/OCB/blob/16.0/odoo/addons/base/models/ir_http.py#L153
so that seems the best place to catch your exception


-- 
Your partner for the hard Odoo problems
https://hunki-enterprises.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 Tom Blauwendraat - 05:56 - 1 May 2023
  • RE: suggestion for monitoring error 500

    Hi Dominique,

    I normally use the try … except like below:

     


    try:

     

    except Exception as e:

        mail_smtp_server = self.env["ir.mail_server"].sudo().search([], limit=1)

        email_vals = {"state": "outgoing" ,

            "subject": str(self.env.cr.dbname) + " Error in demo 1 controller  " ,

            "body_html": """Error in demo 1 controller  :  """ + str(e.message) + " " + str(e.args) ,

            "auto_delete": True,

            "email_from": mail_smtp_server.smtp_user ,

            "email_to": madeb@regious.co.zw ,

            }

        self.env["mail.mail"].create(email_vals)

     

     

    Regards,

     

    Bill Made

    +263 733 419 060

     

     

     

    From: Dominique k <notifications@odoo-community.org>
    Sent: Monday, May 1, 2023 7:29 AM
    To: Contributors <contributors@odoo-community.org>
    Subject: suggestion for monitoring error 500

     

    Hi,

     

    We have a case where odoo is used as an e-commerce + portal system (with quite a lot of customisation).

    Times to times, the end user (e-commerce customer) will receive an error 500.

     

    It is a bit of a catchall... Would anybody have any suggestion, to monitor such error, and possibly get an email, or a warning as a system administrator? Is there a way to catch at odoo level, if there is such error and send an email ?

    Or could we "monitor" the log file ? <-- any suggestion on possible tool ?

     

    Thanks,

    Dominique

    by Bill Made - 08:51 - 1 May 2023
  • Re: Download Sale Orders from Magento 2.3 to Odoo14
    Francesco,

    Yes, demo is on Enterprise but our connectors of course working on Community Edition. 

    About library to use. Magento has simple rest api. So we investigated available libs. But as result created our own simple one class wrapper. It is very easy. Just we didn’t want to be limited with some library. We faced this with some other libraries for other e-commerce systems because as result we had not only develop our own connector, but also make fixes to library.


    On Sun, 30 Apr 2023 at 19:36, Francesco Ballerini <notifications@odoo-community.org> wrote:


    Romualdo Briosos Jrsab 29 apr, 20:12 (22 ore fa)
    In your situation, I would recommend developing a Python program that can connect to both the Magento API and Odoo API. This would give you greater control over

     

    Oleg Kuryan

    In community you will never find good and well supported connector. This is community, nobody will respond to you for free for bugfixing. You need to fix and contribute yourself. It is very rare case that people will fix your reported bugs. And it is more based on enthusiasm of individual person in case he has free time / desire / good mood :) 
    So yes, in your case it is better to develop your own script that you will understand yourself and will support it yourself 
    I know this 100% as we are developing Connectors to e-commerce systems and we know how much time it takes to support them, constantly develop, fix bugs, respond in reasonable time. 

    Thanks for your feedbacks, it really helps in the decision process! 

    It is very likely that we will proceed this way:

    1) we will make a temporary implementation of the old workflow as I described in the first message for 2 reasons
       - it's more "cluncky" but it's (at least for me) faster to develope and requires less code updates in the future
       - this would also allow us to have a low-level fallback import system, which we can use if "something breaks" after an update 

    2) one day not too far, is very likely that we will implement our own API as you both suggested. About this I'd like to ask if you have specific libraries to recommend, I see there are different libraries and I think this one might be a good point to start https://pypi.org/project/magento/, but I'm not sure about version compatibility. 
    It would be great to know your recommendations about libraries, if you'd like to share any.

    Thanks for the video suggestion Oleg, I have almost finished it, I see the connector Demo is on Odoo Enterprise but VentorTech solutions can also be found for Odoo Community is it correct?

    Thanks,
    Francesco B.


    Privo di virus.www.avast.com

    _______________________________________________
    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, VentorTech OÜ |     Building Personalized Inventory and Product Management Systems

    | ph PL: +48 573 992 456
    | skype: kuryan.oleg
    by "Oleg Kuryan" <oleg@ventor.tech> - 08:16 - 1 May 2023
  • Re: suggestion for monitoring error 500 
    > It is a bit of a catchall... Would anybody have any suggestion, to monitor

> such error, and possibly get an email, or a warning as a system

> administrator? Is there a way to catch at odoo level, if there is such

> error and send an email ?

all requests go through
https://github.com/OCA/OCB/blob/16.0/odoo/addons/base/models/ir_http.py#L153
so that seems the best place to catch your exception


-- 
Your partner for the hard Odoo problems
https://hunki-enterprises.com
    by Holger Brunn - 07:56 - 1 May 2023

    1 attachments 1 attachments

    signature.asc
  • suggestion for monitoring error 500
    Hi,

    We have a case where odoo is used as an e-commerce + portal system (with quite a lot of customisation).
    Times to times, the end user (e-commerce customer) will receive an error 500.

    It is a bit of a catchall... Would anybody have any suggestion, to monitor such error, and possibly get an email, or a warning as a system administrator? Is there a way to catch at odoo level, if there is such error and send an email ?
    Or could we "monitor" the log file ? <-- any suggestion on possible tool ?

    Thanks,
    Dominique
    by dominique.k - 07:21 - 1 May 2023
  • Re: Download Sale Orders from Magento 2.3 to Odoo14


    Romualdo Briosos Jrsab 29 apr, 20:12 (22 ore fa)
    In your situation, I would recommend developing a Python program that can connect to both the Magento API and Odoo API. This would give you greater control over

     

    Oleg Kuryan

    In community you will never find good and well supported connector. This is community, nobody will respond to you for free for bugfixing. You need to fix and contribute yourself. It is very rare case that people will fix your reported bugs. And it is more based on enthusiasm of individual person in case he has free time / desire / good mood :) 
    So yes, in your case it is better to develop your own script that you will understand yourself and will support it yourself 
    I know this 100% as we are developing Connectors to e-commerce systems and we know how much time it takes to support them, constantly develop, fix bugs, respond in reasonable time. 

    Thanks for your feedbacks, it really helps in the decision process! 

    It is very likely that we will proceed this way:

    1) we will make a temporary implementation of the old workflow as I described in the first message for 2 reasons
       - it's more "cluncky" but it's (at least for me) faster to develope and requires less code updates in the future
       - this would also allow us to have a low-level fallback import system, which we can use if "something breaks" after an update 

    2) one day not too far, is very likely that we will implement our own API as you both suggested. About this I'd like to ask if you have specific libraries to recommend, I see there are different libraries and I think this one might be a good point to start https://pypi.org/project/magento/, but I'm not sure about version compatibility. 
    It would be great to know your recommendations about libraries, if you'd like to share any.

    Thanks for the video suggestion Oleg, I have almost finished it, I see the connector Demo is on Odoo Enterprise but VentorTech solutions can also be found for Odoo Community is it correct?

    Thanks,
    Francesco B.


    Privo di virus.www.avast.com
    by Francesco Ballerini - 07:35 - 30 Apr 2023
  • Re: Download Sale Orders from Magento 2.3 to Odoo14
    Hello Francesco,

    In community you will never find good and well supported connector. This is community, nobody will respond to you for free for bugfixing. You need to fix and contribute yourself. It is very rare case that people will fix your reported bugs. And it is more based on enthusiasm of individual person in case he has free time / desire / good mood :) 

    So yes, in your case it is better to develop your own script that you will understand yourself and will support it yourself 

    I know this 100% as we are developing Connectors to e-commerce systems and we know how much time it takes to support them, constantly develop, fix bugs, respond in reasonable time. 

    On my presentation on last Odoo conference I was comparing connectors to e-commerce. Look at this presentation just for high level overview of connectors in Odoo world (this are first 5 mins or so 

    On Sat, 29 Apr 2023 at 20:12, Romualdo Briosos Jr <notifications@odoo-community.org> wrote:
    In your situation, I would recommend developing a Python program that can connect to both the Magento API and Odoo API. This would give you greater control over the program's behavior and functionality.

    On Sat, Apr 29, 2023 at 9:27 PM Francesco Ballerini <notifications@odoo-community.org> wrote:

    Hello everyone,

     

    we are integrating Odoo14 in our main company business and we need to cover an important need, but we don’t know yet if we should develope our custom solution or use a 3rd party connector.

    It would be really helpful to have your opinion in relation of our needs, if possible, or more simply about Odoo-Magento connectors in general.

     

    We cooperates in dropshipping with a company that use Magento 2.3 (and will possibly switch to Magento 2.4) and we are managing for him the stock and part of delivery workflow.

     

    We don’t need a full syncro, because our ‘dropshipping partner’ only sells product that we already have in stock.

    This means that we only have to sync

     

    • orders
    • possibly new customers, but we don’t manage invoice data so we don’t need much data for the customer sync, just a generic reference

     

    With this premise, we were think that using a connector is not necessary but we would like to have an opinion from experienced people that know Odoo better than us.

     

    The workflow we are using right now with another ERP and we are going to re-create in Odoo is pretty raw, but it works well:

     

    • we receive an XML with orders,
    • we read XML,
    • we create orders in Odoo,
    • we process orders internally,
    • we send, at the end of the day, a csv file with our stock quantity (for all products) back to the ‘dropshipping partner’ so he can update his product availability on Magento website

     

    Also, in Odoo we are going to make some little improvements here and there to make orders easier and fast to manage once they have been processed, so we would need to make a few implementations even if we buy/use a 3rd party module.

     

    From my perspective it’s not worth to get a connector to achieve this specific tasks unless is a very good one, meaning that:

     

    • Well supported by community (if it’s free, but i did not find one) or have very good and responsive assistance service
    • it will work without spending much additional time on it,  expecially because it will probably add hundreds (if not thousands) of code line that we are not fully going to take advantage of,

    so it might just be better to spend time on develope our small but specific solution, if that’s the case

     

    Thanks in advance and regards,

     

    Francesco B.

     

     

     

     

     


    Privo di virus.www.avast.com

    _______________________________________________
    Mailing-List: https://odoo-community.org/groups/contributors-15
    Post to: mailto:contributors@odoo-community.org
    Unsubscribe: https://odoo-community.org/groups?unsubscribe



    --
    Sincerely,

    Romualdo Briosos Jr - Computer Engineer.
    Al Milad - Rocmet Corporation Group

    Corporate Headquarters
    Office Number: +971-4-553-1045
    Address: Unit 1809, Lake Central Fakhruddin Properties, Business Bay, Dubai- U.A.E.

    Warehouse
    Office Number: +971-6-5345587
    Address: Yard No. 14 - Street No. 18 -Industrial Area 11 P.O BOX 21034, Sharjah, UAE

     
      

    DISCLAIMER:

    This email and any files transmitted with it may be confidential and contain privileged or copyright information. If you are not the intended recipient you must not copy, distribute or use this email or the information contained in it for any purpose other than to notify us of the receipt thereof, if you have received this message in error, please notify the sender immediately, and delete this email from your system. Please note that e-mails are susceptible to change, the sender shall not be liable for the improper or incomplete transmission of the information contained in this communication, nor for any delay in its receipt or damage to your system. The sender does not guarantee that this material is free from viruses or any other defects although due care has been taken to minimize the risk.

    _______________________________________________
    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, VentorTech OÜ |     Building Personalized Inventory and Product Management Systems

    | ph PL: +48 573 992 456
    | skype: kuryan.oleg
    by "Oleg Kuryan" <oleg@ventor.tech> - 07:41 - 30 Apr 2023
  • Re: Download Sale Orders from Magento 2.3 to Odoo14
    In your situation, I would recommend developing a Python program that can connect to both the Magento API and Odoo API. This would give you greater control over the program's behavior and functionality.

    On Sat, Apr 29, 2023 at 9:27 PM Francesco Ballerini <notifications@odoo-community.org> wrote:

    Hello everyone,

     

    we are integrating Odoo14 in our main company business and we need to cover an important need, but we don’t know yet if we should develope our custom solution or use a 3rd party connector.

    It would be really helpful to have your opinion in relation of our needs, if possible, or more simply about Odoo-Magento connectors in general.

     

    We cooperates in dropshipping with a company that use Magento 2.3 (and will possibly switch to Magento 2.4) and we are managing for him the stock and part of delivery workflow.

     

    We don’t need a full syncro, because our ‘dropshipping partner’ only sells product that we already have in stock.

    This means that we only have to sync

     

    • orders
    • possibly new customers, but we don’t manage invoice data so we don’t need much data for the customer sync, just a generic reference

     

    With this premise, we were think that using a connector is not necessary but we would like to have an opinion from experienced people that know Odoo better than us.

     

    The workflow we are using right now with another ERP and we are going to re-create in Odoo is pretty raw, but it works well:

     

    • we receive an XML with orders,
    • we read XML,
    • we create orders in Odoo,
    • we process orders internally,
    • we send, at the end of the day, a csv file with our stock quantity (for all products) back to the ‘dropshipping partner’ so he can update his product availability on Magento website

     

    Also, in Odoo we are going to make some little improvements here and there to make orders easier and fast to manage once they have been processed, so we would need to make a few implementations even if we buy/use a 3rd party module.

     

    From my perspective it’s not worth to get a connector to achieve this specific tasks unless is a very good one, meaning that:

     

    • Well supported by community (if it’s free, but i did not find one) or have very good and responsive assistance service
    • it will work without spending much additional time on it,  expecially because it will probably add hundreds (if not thousands) of code line that we are not fully going to take advantage of,

    so it might just be better to spend time on develope our small but specific solution, if that’s the case

     

    Thanks in advance and regards,

     

    Francesco B.

     

     

     

     

     


    Privo di virus.www.avast.com

    _______________________________________________
    Mailing-List: https://odoo-community.org/groups/contributors-15
    Post to: mailto:contributors@odoo-community.org
    Unsubscribe: https://odoo-community.org/groups?unsubscribe



    --
    Sincerely,

    Romualdo Briosos Jr - Computer Engineer.
    Al Milad - Rocmet Corporation Group

    Corporate Headquarters
    Office Number: +971-4-553-1045
    Address: Unit 1809, Lake Central Fakhruddin Properties, Business Bay, Dubai- U.A.E.

    Warehouse
    Office Number: +971-6-5345587
    Address: Yard No. 14 - Street No. 18 -Industrial Area 11 P.O BOX 21034, Sharjah, UAE

     
      

    DISCLAIMER:

    This email and any files transmitted with it may be confidential and contain privileged or copyright information. If you are not the intended recipient you must not copy, distribute or use this email or the information contained in it for any purpose other than to notify us of the receipt thereof, if you have received this message in error, please notify the sender immediately, and delete this email from your system. Please note that e-mails are susceptible to change, the sender shall not be liable for the improper or incomplete transmission of the information contained in this communication, nor for any delay in its receipt or damage to your system. The sender does not guarantee that this material is free from viruses or any other defects although due care has been taken to minimize the risk.

    by romualdo - 08:11 - 29 Apr 2023
  • Download Sale Orders from Magento 2.3 to Odoo14

    Hello everyone,

     

    we are integrating Odoo14 in our main company business and we need to cover an important need, but we don’t know yet if we should develope our custom solution or use a 3rd party connector.

    It would be really helpful to have your opinion in relation of our needs, if possible, or more simply about Odoo-Magento connectors in general.

     

    We cooperates in dropshipping with a company that use Magento 2.3 (and will possibly switch to Magento 2.4) and we are managing for him the stock and part of delivery workflow.

     

    We don’t need a full syncro, because our ‘dropshipping partner’ only sells product that we already have in stock.

    This means that we only have to sync

     

    • orders
    • possibly new customers, but we don’t manage invoice data so we don’t need much data for the customer sync, just a generic reference

     

    With this premise, we were think that using a connector is not necessary but we would like to have an opinion from experienced people that know Odoo better than us.

     

    The workflow we are using right now with another ERP and we are going to re-create in Odoo is pretty raw, but it works well:

     

    • we receive an XML with orders,
    • we read XML,
    • we create orders in Odoo,
    • we process orders internally,
    • we send, at the end of the day, a csv file with our stock quantity (for all products) back to the ‘dropshipping partner’ so he can update his product availability on Magento website

     

    Also, in Odoo we are going to make some little improvements here and there to make orders easier and fast to manage once they have been processed, so we would need to make a few implementations even if we buy/use a 3rd party module.

     

    From my perspective it’s not worth to get a connector to achieve this specific tasks unless is a very good one, meaning that:

     

    • Well supported by community (if it’s free, but i did not find one) or have very good and responsive assistance service
    • it will work without spending much additional time on it,  expecially because it will probably add hundreds (if not thousands) of code line that we are not fully going to take advantage of,

    so it might just be better to spend time on develope our small but specific solution, if that’s the case

     

    Thanks in advance and regards,

     

    Francesco B.

     

     

     

     

     


    Privo di virus.www.avast.com
    by Francesco Ballerini - 07:26 - 29 Apr 2023
  • Re: Proforma invoices in Odoo

    Hello,

    At my employer's, I implemented proforma invoices simply by adding a watermark-like background saying "proforma", covering the whole sheet, if the invoice is still a draft.

    However, other companies may need a more elaborate implementation.

    Regards,

    João Jerónimo


    Às 17:27 de 26/04/2023, Alessandro Uffreduzzi escreveu:

    Hello all,

    long time listener, first time caller. I need to develop a module to handle proforma invoices, as the default Odoo implementation is not at all adequate for the needs of multiple customers. What we need looks more like what Sales Orders have, with the 3 states ("Quotation" => "Quotation Sent" => "Sales Order"), where the proforma invoice corresponds to the "Quotation Sent" state.

    Requirements:

    • Invoices (not SOs) can (optionally) become Proforma Invoices, before being confirmed and posted. It doesn't necessarily have to be a new "state" selection, but it seems to be the most natural fit for it.
    • When an invoice becomes a proforma (which logically implies it's being sent to the customer for confirmation), it should take a sequence number from a different sequence than posted invoices. When the invoice is eventually confirmed and posted, it will then take the usual number.  The number it takes when it becomes a proforma should be saved somewhere.
    • Proforma invoices can go back to draft, be cancelled, or be confirmed and posted.
    • The printed version should clearly state it's a proforma, but it's otherwise the same as a regular invoice.

    I've searched for an OCA module resembling these requirements but couldn't find it. Is there an OCA module for this, or is someone developing it? If not, I will work on it myself and propose it in https://github.com/OCA/account-invoicing/

    Thank you for your time

    Have a good day

    --

    Alessandro Uffreduzzi

    Developer

    alessandro.uffreduzzi@pytech.it

    PyTech Srl

    Sede legale: Via Barozzi 40/8 - 41124 Modena

    Sede operativa: Via P. Giardini 472/L - 41124 Modena

    P.IVA 03988700369

    www.pytech.it

    PyTech Logo

    _______________________________________________
    Mailing-List: https://odoo-community.org/groups/contributors-15
    Post to: mailto:contributors@odoo-community.org
    Unsubscribe: https://odoo-community.org/groups?unsubscribe

    by j_j_b_o_devel - 02:36 - 28 Apr 2023
  • Re: Proforma invoices in Odoo

    Hi Allessandro,

    sorry for not having written earlier. I think the decision that you have taken is the most appropriate one as the standard implementation fullfills the must-have requirement of "proforma invoices" (at least of what i consider must-have).

    It lies in its nature that such an "invoice" isn't a real invoice by fiscal nature (and just like in the case of Odoo is a different object therefore). The only alternative that i would have in mind, was to use the real invoice object (in the Odoo sense) and send them as "proforma" as long as they aren't actually verified. In this case a specific label on the report could mark this. But this wouldn't have any conceivable technical advantages over the standard solution and probably more than one disadvantages besides pure usability, so all in all your choice seems to be pretty sensible.

    Best Frederik


    Am 27.04.23 um 15:56 schrieb Alessandro Uffreduzzi:

    Hello,

    thank you all for your replies. Based on your feedback me and my colleagues insisted with the most pressing customer and we convinced them to use

    1. The native odoo functionality with regards to proforma invoices (i.e. sales orders);
    2. Alternatively, by just changing the title when printing a draft invoice from "draft" to "proforma" (in case they want to send a proforma invoice that's only a part of the original SO)

    therefore avoiding potentially problematic and hard-to-maintain customizations to the flow of invoices themselves.

    Have a great day.

    Alessandro Uffreduzzi

    Developer

    alessandro.uffreduzzi@pytech.it


    On 26/04/2023 8:12 pm, Antonio M. Vigliotti wrote:

    Hi Alessandro,

    I wrote the pro-forma some time ago on Odoo 10.0

    Here you can find source code:

    https://github.com/zeroincombenze/account-invoicing/tree/10.0/account_invoice_line_sequence

    However this code is an improvement of OCA implementation, I think you could find it on account-invoicing repository

    PS As Carlos wrote, pro-forma is somthing closer to a sale order but Italian people will not use sale orderfor thi purpose :-(

    Antonio

    Il 26/04/2023 18:47, Janik von Rotz ha scritto:

    Hi Allessandro

    Can you give us some details on the business case? Is this going more towards downpayments?

    Proforma in Odoo ist just the Sale Order with a different title.

    I assume what you need, is a function to generate an invoice before the quotation is confirmed. Your requirements are more or less what the account module delivers.

    Cheers, Janik

    On 4/26/23 18:27, Alessandro Uffreduzzi wrote:

    Hello all,

    long time listener, first time caller. I need to develop a module to handle proforma invoices, as the default Odoo implementation is not at all adequate for the needs of multiple customers. What we need looks more like what Sales Orders have, with the 3 states ("Quotation" => "Quotation Sent" => "Sales Order"), where the proforma invoice corresponds to the "Quotation Sent" state.

    Requirements:

    • Invoices (not SOs) can (optionally) become Proforma Invoices, before being confirmed and posted. It doesn't necessarily have to be a new "state" selection, but it seems to be the most natural fit for it.
    • When an invoice becomes a proforma (which logically implies it's being sent to the customer for confirmation), it should take a sequence number from a different sequence than posted invoices. When the invoice is eventually confirmed and posted, it will then take the usual number.  The number it takes when it becomes a proforma should be saved somewhere.
    • Proforma invoices can go back to draft, be cancelled, or be confirmed and posted.
    • The printed version should clearly state it's a proforma, but it's otherwise the same as a regular invoice.

    I've searched for an OCA module resembling these requirements but couldn't find it. Is there an OCA module for this, or is someone developing it? If not, I will work on it myself and propose it in https://github.com/OCA/account-invoicing/

    Thank you for your time

    Have a good day

    --

    Alessandro Uffreduzzi

    Developer

    alessandro.uffreduzzi@pytech.it

    PyTech Srl

    Sede legale: Via Barozzi 40/8 - 41124 Modena

    Sede operativa: Via P. Giardini 472/L - 41124 Modena

    P.IVA 03988700369

    www.pytech.it

    PyTech Logo

    _______________________________________________
    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

    --
    Antonio M. Vigliotti

    Mobile (+39) 342.8740910



    _______________________________________________
    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

    -- 
Dr.-Ing. Frederik Kramer
Geschäftsführer

initOS GmbH
Innungsstraße 7
21244 Buchholz i.d.N.

Phone:  +49 4181 13503-12
Fax:    +49 4181 13503-10
Mobil:  +49 179 3901819

Email: frederik.kramer@initos.com
Web:   www.initos.com

Geschäftsführung:
Dr.-Ing. Frederik Kramer & Dipl.-Ing. (FH) Torsten Francke

Sitz der Gesellschaft: Buchholz i.d.N.
Amtsgericht Tostedt, HRB 205226
Steuer-Nr: 15/200/53247
USt-IdNr.: DE815580155
    by Frederik Kramer - 04:11 - 27 Apr 2023
  • Re: Proforma invoices in Odoo
    You have this old module that does exactly what you decided:

    https://github.com/OCA/sale-reporting/tree/10.0/sale_proforma_report

    El jue, 27 abr 2023 a las 15:57, Alessandro Uffreduzzi (<notifications@odoo-community.org>) escribió:

    Hello,

    thank you all for your replies. Based on your feedback me and my colleagues insisted with the most pressing customer and we convinced them to use

    1. The native odoo functionality with regards to proforma invoices (i.e. sales orders);
    2. Alternatively, by just changing the title when printing a draft invoice from "draft" to "proforma" (in case they want to send a proforma invoice that's only a part of the original SO)

    therefore avoiding potentially problematic and hard-to-maintain customizations to the flow of invoices themselves.

    Have a great day.

    Alessandro Uffreduzzi

    Developer

    alessandro.uffreduzzi@pytech.it


    On 26/04/2023 8:12 pm, Antonio M. Vigliotti wrote:

    Hi Alessandro,

    I wrote the pro-forma some time ago on Odoo 10.0

    Here you can find source code:

    https://github.com/zeroincombenze/account-invoicing/tree/10.0/account_invoice_line_sequence

    However this code is an improvement of OCA implementation, I think you could find it on account-invoicing repository

    PS As Carlos wrote, pro-forma is somthing closer to a sale order but Italian people will not use sale orderfor thi purpose :-(

    Antonio

    Il 26/04/2023 18:47, Janik von Rotz ha scritto:

    Hi Allessandro

    Can you give us some details on the business case? Is this going more towards downpayments?

    Proforma in Odoo ist just the Sale Order with a different title.

    I assume what you need, is a function to generate an invoice before the quotation is confirmed. Your requirements are more or less what the account module delivers.

    Cheers, Janik

    On 4/26/23 18:27, Alessandro Uffreduzzi wrote:

    Hello all,

    long time listener, first time caller. I need to develop a module to handle proforma invoices, as the default Odoo implementation is not at all adequate for the needs of multiple customers. What we need looks more like what Sales Orders have, with the 3 states ("Quotation" => "Quotation Sent" => "Sales Order"), where the proforma invoice corresponds to the "Quotation Sent" state.

    Requirements:

    • Invoices (not SOs) can (optionally) become Proforma Invoices, before being confirmed and posted. It doesn't necessarily have to be a new "state" selection, but it seems to be the most natural fit for it.
    • When an invoice becomes a proforma (which logically implies it's being sent to the customer for confirmation), it should take a sequence number from a different sequence than posted invoices. When the invoice is eventually confirmed and posted, it will then take the usual number.  The number it takes when it becomes a proforma should be saved somewhere.
    • Proforma invoices can go back to draft, be cancelled, or be confirmed and posted.
    • The printed version should clearly state it's a proforma, but it's otherwise the same as a regular invoice.

    I've searched for an OCA module resembling these requirements but couldn't find it. Is there an OCA module for this, or is someone developing it? If not, I will work on it myself and propose it in https://github.com/OCA/account-invoicing/

    Thank you for your time

    Have a good day

    --

    Alessandro Uffreduzzi

    Developer

    alessandro.uffreduzzi@pytech.it

    PyTech Srl

    Sede legale: Via Barozzi 40/8 - 41124 Modena

    Sede operativa: Via P. Giardini 472/L - 41124 Modena

    P.IVA 03988700369

    www.pytech.it

    PyTech Logo

    _______________________________________________
    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

    --
    Antonio M. Vigliotti

    Mobile (+39) 342.8740910



    _______________________________________________
    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 Carlos Liébana Anero. - 04:06 - 27 Apr 2023
  • Re: Proforma invoices in Odoo

    Hello,

    thank you all for your replies. Based on your feedback me and my colleagues insisted with the most pressing customer and we convinced them to use

    1. The native odoo functionality with regards to proforma invoices (i.e. sales orders);
    2. Alternatively, by just changing the title when printing a draft invoice from "draft" to "proforma" (in case they want to send a proforma invoice that's only a part of the original SO)

    therefore avoiding potentially problematic and hard-to-maintain customizations to the flow of invoices themselves.

    Have a great day.

    Alessandro Uffreduzzi

    Developer

    alessandro.uffreduzzi@pytech.it


    On 26/04/2023 8:12 pm, Antonio M. Vigliotti wrote:

    Hi Alessandro,

    I wrote the pro-forma some time ago on Odoo 10.0

    Here you can find source code:

    https://github.com/zeroincombenze/account-invoicing/tree/10.0/account_invoice_line_sequence

    However this code is an improvement of OCA implementation, I think you could find it on account-invoicing repository

    PS As Carlos wrote, pro-forma is somthing closer to a sale order but Italian people will not use sale orderfor thi purpose :-(

    Antonio

    Il 26/04/2023 18:47, Janik von Rotz ha scritto:

    Hi Allessandro

    Can you give us some details on the business case? Is this going more towards downpayments?

    Proforma in Odoo ist just the Sale Order with a different title.

    I assume what you need, is a function to generate an invoice before the quotation is confirmed. Your requirements are more or less what the account module delivers.

    Cheers, Janik

    On 4/26/23 18:27, Alessandro Uffreduzzi wrote:

    Hello all,

    long time listener, first time caller. I need to develop a module to handle proforma invoices, as the default Odoo implementation is not at all adequate for the needs of multiple customers. What we need looks more like what Sales Orders have, with the 3 states ("Quotation" => "Quotation Sent" => "Sales Order"), where the proforma invoice corresponds to the "Quotation Sent" state.

    Requirements:

    • Invoices (not SOs) can (optionally) become Proforma Invoices, before being confirmed and posted. It doesn't necessarily have to be a new "state" selection, but it seems to be the most natural fit for it.
    • When an invoice becomes a proforma (which logically implies it's being sent to the customer for confirmation), it should take a sequence number from a different sequence than posted invoices. When the invoice is eventually confirmed and posted, it will then take the usual number.  The number it takes when it becomes a proforma should be saved somewhere.
    • Proforma invoices can go back to draft, be cancelled, or be confirmed and posted.
    • The printed version should clearly state it's a proforma, but it's otherwise the same as a regular invoice.

    I've searched for an OCA module resembling these requirements but couldn't find it. Is there an OCA module for this, or is someone developing it? If not, I will work on it myself and propose it in https://github.com/OCA/account-invoicing/

    Thank you for your time

    Have a good day

    --

    Alessandro Uffreduzzi

    Developer

    alessandro.uffreduzzi@pytech.it

    PyTech Srl

    Sede legale: Via Barozzi 40/8 - 41124 Modena

    Sede operativa: Via P. Giardini 472/L - 41124 Modena

    P.IVA 03988700369

    www.pytech.it

    PyTech Logo

    _______________________________________________
    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

    --
    Antonio M. Vigliotti

    Mobile (+39) 342.8740910



    _______________________________________________
    Mailing-List: https://odoo-community.org/groups/contributors-15
    Post to: mailto:contributors@odoo-community.org
    Unsubscribe: https://odoo-community.org/groups?unsubscribe

    by Alessandro Uffreduzzi - 03:55 - 27 Apr 2023
  • Re: Proforma invoices in Odoo

    Hi Alessandro,

    I wrote the pro-forma some time ago on Odoo 10.0

    Here you can find source code:

    https://github.com/zeroincombenze/account-invoicing/tree/10.0/account_invoice_line_sequence

    However this code is an improvement of OCA implementation, I think you could find it on account-invoicing repository

    PS As Carlos wrote, pro-forma is somthing closer to a sale order but Italian people will not use sale orderfor thi purpose :-(

    Antonio

    Il 26/04/2023 18:47, Janik von Rotz ha scritto:

    Hi Allessandro

    Can you give us some details on the business case? Is this going more towards downpayments?

    Proforma in Odoo ist just the Sale Order with a different title.

    I assume what you need, is a function to generate an invoice before the quotation is confirmed. Your requirements are more or less what the account module delivers.

    Cheers, Janik

    On 4/26/23 18:27, Alessandro Uffreduzzi wrote:

    Hello all,

    long time listener, first time caller. I need to develop a module to handle proforma invoices, as the default Odoo implementation is not at all adequate for the needs of multiple customers. What we need looks more like what Sales Orders have, with the 3 states ("Quotation" => "Quotation Sent" => "Sales Order"), where the proforma invoice corresponds to the "Quotation Sent" state.

    Requirements:

    • Invoices (not SOs) can (optionally) become Proforma Invoices, before being confirmed and posted. It doesn't necessarily have to be a new "state" selection, but it seems to be the most natural fit for it.
    • When an invoice becomes a proforma (which logically implies it's being sent to the customer for confirmation), it should take a sequence number from a different sequence than posted invoices. When the invoice is eventually confirmed and posted, it will then take the usual number.  The number it takes when it becomes a proforma should be saved somewhere.
    • Proforma invoices can go back to draft, be cancelled, or be confirmed and posted.
    • The printed version should clearly state it's a proforma, but it's otherwise the same as a regular invoice.

    I've searched for an OCA module resembling these requirements but couldn't find it. Is there an OCA module for this, or is someone developing it? If not, I will work on it myself and propose it in https://github.com/OCA/account-invoicing/

    Thank you for your time

    Have a good day

    --

    Alessandro Uffreduzzi

    Developer

    alessandro.uffreduzzi@pytech.it

    PyTech Srl

    Sede legale: Via Barozzi 40/8 - 41124 Modena

    Sede operativa: Via P. Giardini 472/L - 41124 Modena

    P.IVA 03988700369

    www.pytech.it

    PyTech Logo

    _______________________________________________
    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

    --
    Antonio M. Vigliotti

    Mobile (+39) 342.8740910



    by Antonio M. Vigliotti - 08:11 - 26 Apr 2023

    3 attachments 3 attachments

    AntonioMariaVigliotti_html_2a3b0efbc5e4661a.png
    AntonioMariaVigliotti_html_51f470c428b0fa9b.png
    AntonioMariaVigliotti_html_60baa43d7331dc71.png
  • Re: Proforma invoices in Odoo

    Hi Allessandro

    Can you give us some details on the business case? Is this going more towards downpayments?

    Proforma in Odoo ist just the Sale Order with a different title.

    I assume what you need, is a function to generate an invoice before the quotation is confirmed. Your requirements are more or less what the account module delivers.

    Cheers, Janik

    On 4/26/23 18:27, Alessandro Uffreduzzi wrote:

    Hello all,

    long time listener, first time caller. I need to develop a module to handle proforma invoices, as the default Odoo implementation is not at all adequate for the needs of multiple customers. What we need looks more like what Sales Orders have, with the 3 states ("Quotation" => "Quotation Sent" => "Sales Order"), where the proforma invoice corresponds to the "Quotation Sent" state.

    Requirements:

    • Invoices (not SOs) can (optionally) become Proforma Invoices, before being confirmed and posted. It doesn't necessarily have to be a new "state" selection, but it seems to be the most natural fit for it.
    • When an invoice becomes a proforma (which logically implies it's being sent to the customer for confirmation), it should take a sequence number from a different sequence than posted invoices. When the invoice is eventually confirmed and posted, it will then take the usual number.  The number it takes when it becomes a proforma should be saved somewhere.
    • Proforma invoices can go back to draft, be cancelled, or be confirmed and posted.
    • The printed version should clearly state it's a proforma, but it's otherwise the same as a regular invoice.

    I've searched for an OCA module resembling these requirements but couldn't find it. Is there an OCA module for this, or is someone developing it? If not, I will work on it myself and propose it in https://github.com/OCA/account-invoicing/

    Thank you for your time

    Have a good day

    --

    Alessandro Uffreduzzi

    Developer

    alessandro.uffreduzzi@pytech.it

    PyTech Srl

    Sede legale: Via Barozzi 40/8 - 41124 Modena

    Sede operativa: Via P. Giardini 472/L - 41124 Modena

    P.IVA 03988700369

    www.pytech.it

    PyTech Logo

    _______________________________________________
    Mailing-List: https://odoo-community.org/groups/contributors-15
    Post to: mailto:contributors@odoo-community.org
    Unsubscribe: https://odoo-community.org/groups?unsubscribe

    by Janik von Rotz - 06:46 - 26 Apr 2023
  • Re: Proforma invoices in Odoo
    I don't know about Italy, but here in Spain a pro-forma invoice is something closer to a sales order than to an invoice. Our approach to your requirement was to copy the default sales order report to another one and replace the string 'sales order' with 'pro-forma'.

    El mié, 26 abr 2023 a las 18:27, Alessandro Uffreduzzi (<notifications@odoo-community.org>) escribió:

    Hello all,

    long time listener, first time caller. I need to develop a module to handle proforma invoices, as the default Odoo implementation is not at all adequate for the needs of multiple customers. What we need looks more like what Sales Orders have, with the 3 states ("Quotation" => "Quotation Sent" => "Sales Order"), where the proforma invoice corresponds to the "Quotation Sent" state.

    Requirements:

    • Invoices (not SOs) can (optionally) become Proforma Invoices, before being confirmed and posted. It doesn't necessarily have to be a new "state" selection, but it seems to be the most natural fit for it.
    • When an invoice becomes a proforma (which logically implies it's being sent to the customer for confirmation), it should take a sequence number from a different sequence than posted invoices. When the invoice is eventually confirmed and posted, it will then take the usual number.  The number it takes when it becomes a proforma should be saved somewhere.
    • Proforma invoices can go back to draft, be cancelled, or be confirmed and posted.
    • The printed version should clearly state it's a proforma, but it's otherwise the same as a regular invoice.

    I've searched for an OCA module resembling these requirements but couldn't find it. Is there an OCA module for this, or is someone developing it? If not, I will work on it myself and propose it in https://github.com/OCA/account-invoicing/

    Thank you for your time

    Have a good day

    --

    Alessandro Uffreduzzi

    Developer

    alessandro.uffreduzzi@pytech.it

    PyTech Srl

    Sede legale: Via Barozzi 40/8 - 41124 Modena

    Sede operativa: Via P. Giardini 472/L - 41124 Modena

    P.IVA 03988700369

    www.pytech.it

    PyTech Logo

    _______________________________________________
    Mailing-List: https://odoo-community.org/groups/contributors-15
    Post to: mailto:contributors@odoo-community.org
    Unsubscribe: https://odoo-community.org/groups?unsubscribe

    by Carlos Liébana Anero. - 06:36 - 26 Apr 2023
  • Proforma invoices in Odoo

    Hello all,

    long time listener, first time caller. I need to develop a module to handle proforma invoices, as the default Odoo implementation is not at all adequate for the needs of multiple customers. What we need looks more like what Sales Orders have, with the 3 states ("Quotation" => "Quotation Sent" => "Sales Order"), where the proforma invoice corresponds to the "Quotation Sent" state.

    Requirements:

    • Invoices (not SOs) can (optionally) become Proforma Invoices, before being confirmed and posted. It doesn't necessarily have to be a new "state" selection, but it seems to be the most natural fit for it.
    • When an invoice becomes a proforma (which logically implies it's being sent to the customer for confirmation), it should take a sequence number from a different sequence than posted invoices. When the invoice is eventually confirmed and posted, it will then take the usual number.  The number it takes when it becomes a proforma should be saved somewhere.
    • Proforma invoices can go back to draft, be cancelled, or be confirmed and posted.
    • The printed version should clearly state it's a proforma, but it's otherwise the same as a regular invoice.

    I've searched for an OCA module resembling these requirements but couldn't find it. Is there an OCA module for this, or is someone developing it? If not, I will work on it myself and propose it in https://github.com/OCA/account-invoicing/

    Thank you for your time

    Have a good day

    --

    Alessandro Uffreduzzi

    Developer

    alessandro.uffreduzzi@pytech.it

    PyTech Srl

    Sede legale: Via Barozzi 40/8 - 41124 Modena

    Sede operativa: Via P. Giardini 472/L - 41124 Modena

    P.IVA 03988700369

    www.pytech.it

    PyTech Logo
    by Alessandro Uffreduzzi - 06:25 - 26 Apr 2023

    1 attachments 1 attachments

    24jeVmJ0Syk0Opsj.png
  • Re: LDAP and MS Azure
    Is that something the Community has considered before and/or are there drawbacks?

    The main issue is knowing what permissions to grant users on the Odoo side.

    There are all sorts of tactics, for example, group memberships at the IDP which are used to drive group memberships in Odoo, etc. but eventually, there is always some exception or special case.

    If you don't grant permissions based on information provided by the IDP then you just create a very restricted user, which needs to be edited anyway, at which point you might as well have not automatically created the user.

    My personal opinion is that it's often wanted, but rarely practical outside of the largest organisations. 

    On Tue, Apr 25, 2023 at 3:27 PM Franklin Smith <notifications@odoo-community.org> wrote:
    Thanks, all. The "auth_saml" OCA module works well. There's a request to have Odoo users created automatically if they don't exist in Odoo once they authenticate with AD. Similar to the LDAP functionatliy. Is that something the Community has considered before and/or are there drawbacks?

    On Sat, Apr 22, 2023, 8:37 AM Graeme Gellatly <notifications@odoo-community.org> wrote:
    I wrote a module for azure ad, but these days you can just backport odoo v16 oauth changes. However in odoonz addons there is a module for v14

    On Sat, 22 Apr 2023, 3:27 pm Dominique k, <notifications@odoo-community.org> wrote:
    There are third party modules that allow to do this
    Dominique 


    On Sat, 22 Apr 2023 at 03:22, Franklin Smith <notifications@odoo-community.org> wrote:
    Hello OCA Contributors. Have a client who is wanting to authenticate Odoo users with Azure Active Directory, and we're running in to some issues.

    Can anyone point me to resources about authenticating Odoo and Azure AD using LDAP? Recent web searches show this is complex and I'm learning Azure AD isn't completely LDAP compliant. Are there any resources or OCA modules related to oauth2 authentication with Azure AD? 

    Thanks much!


    _______________________________________________
    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

    _______________________________________________
    Mailing-List: https://odoo-community.org/groups/contributors-15
    Post to: mailto:contributors@odoo-community.org
    Unsubscribe: https://odoo-community.org/groups?unsubscribe

    by Karl Southern - 04:56 - 25 Apr 2023
  • Re: LDAP and MS Azure
    Thanks, all. The "auth_saml" OCA module works well. There's a request to have Odoo users created automatically if they don't exist in Odoo once they authenticate with AD. Similar to the LDAP functionatliy. Is that something the Community has considered before and/or are there drawbacks?

    On Sat, Apr 22, 2023, 8:37 AM Graeme Gellatly <notifications@odoo-community.org> wrote:
    I wrote a module for azure ad, but these days you can just backport odoo v16 oauth changes. However in odoonz addons there is a module for v14

    On Sat, 22 Apr 2023, 3:27 pm Dominique k, <notifications@odoo-community.org> wrote:
    There are third party modules that allow to do this
    Dominique 


    On Sat, 22 Apr 2023 at 03:22, Franklin Smith <notifications@odoo-community.org> wrote:
    Hello OCA Contributors. Have a client who is wanting to authenticate Odoo users with Azure Active Directory, and we're running in to some issues.

    Can anyone point me to resources about authenticating Odoo and Azure AD using LDAP? Recent web searches show this is complex and I'm learning Azure AD isn't completely LDAP compliant. Are there any resources or OCA modules related to oauth2 authentication with Azure AD? 

    Thanks much!


    _______________________________________________
    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 Arthur Franklin Smith - 04:26 - 25 Apr 2023
  • Re: LDAP and MS Azure
    I wrote a module for azure ad, but these days you can just backport odoo v16 oauth changes. However in odoonz addons there is a module for v14

    On Sat, 22 Apr 2023, 3:27 pm Dominique k, <notifications@odoo-community.org> wrote:
    There are third party modules that allow to do this
    Dominique 


    On Sat, 22 Apr 2023 at 03:22, Franklin Smith <notifications@odoo-community.org> wrote:
    Hello OCA Contributors. Have a client who is wanting to authenticate Odoo users with Azure Active Directory, and we're running in to some issues.

    Can anyone point me to resources about authenticating Odoo and Azure AD using LDAP? Recent web searches show this is complex and I'm learning Azure AD isn't completely LDAP compliant. Are there any resources or OCA modules related to oauth2 authentication with Azure AD? 

    Thanks much!


    _______________________________________________
    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 Graeme Gellatly - 02:36 - 22 Apr 2023