Archives
Contributors
-
Re: By pass security rule on some situation.
I will check it. Thank you for the pointer.On Thu, Apr 29, 2021, 19:07 Holger Brunn <mail@hunki-enterprises.com> wrote:I stand by my claim that allowing to turn off security rules from the client side is a horribly bad idea. If you need this, that means you designed the security rules wrongly, so better go back to the drawing board to write security rules you don't need to bypass. -- 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 Kitti Upariphutthiphong - 07:16 - 1 May 2021 -
Re: 30 Checkout Operations per Minute A job for Odoo or not ?
Hi FrederikA customer requested to support 5k concurrent sale.order (1 or 2 lines of products) in Odoo.The process that we followed were: test, measure, fix, test...The first time that we tested the checkout process supported 15 concurrent virtual users (VUs)The measure said that it had heavy custom functions in the same transaction of checkout but it could be executed in background (cron, queue)and there were slow queries because of indexes issues or too many queries executed because of python codeNote: Be careful with the base_automation if you can migrate them to code it is better.After fix them the next iteration supported 400 VUsSo good but so far from the focus.The next iteration we found that there were methods that could be using LRU-cache (e.g. prices, website that don't change)Now we needed to check where the cache was clearing too frequently and fix it.We implemented CDNe.g. The sentence "/web/image/company.logo" runs 10 queries (prefetching fields, translating fields...) for each user opening the pageAfter using CDN 0 queries are executed.We removed soft process that running with many users it is heavye.g. the random image that odoo assign when you create a res.partnere.g. computed fields moved to cronAfter that we detected concurrent update issuesIt is hell for performance matter.e.g. updating the same record at the same time from many users,e.g. allowing pressing the same button too many timese.g. sequences using no-gap in the main process, and so onAfter finishing all the hints of performance issues in the code and database the next steps were to improve the hardware.Now, It supports 5k concurrent VUs doing checkout process (choose 2 products, type address, payment card info and confirm)So, Odoo will support those users but you will need to test, measure, fix, test...Stress testing tools helps us a lot herepython profilers and query analyzers tooMaybe you are interest to watch our talk in SFO about:El mié, 28 abr 2021 a las 15:35, Frederik Kramer (<frederik.kramer@initos.com>) escribió:Hi Folks, i have a project proposal on my desk that will ultimately end up in approx. 30 checkout transactions per minute. Has anybody got a project with that order volume done with a relatively recent version of Odoo and provide a good reference. Please bear in mind that the project ahead involves a similarly high volume of stock moves. Any suggestion / comment like (but not limited to) Odoo is the wrong technology for that, forget it, because.... over You can do it but, a), b), c) .... to If you really want that beast flying involve us over here because we are among the few ones that already did soemthing similar would be appreciated. From our load intensive projects at initOS i know that 10000 orders a day can be handled but almost 50000 is a different story and thats why i am asking the most experienced resource out there ;-) Thanks in advance for your replay Cheers Frederik -- Dr.-Ing. Frederik Kramer Geschäftsführer initOS GmbH An der Eisenbahn 1 21224 Rosengarten Phone: +49 4105 56156-12 Fax: +49 4105 56156-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: Rosengarten – Klecken Amtsgericht Tostedt, HRB 205226 Steuer-Nr: 15/200/53247 USt-IdNr.: DE815580155_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--Moisés López CalderónMobile: (+521) 477-752-22-30Twitter: @moylop260Twitter: @vauxoo
by Moisés López Calderón - 06:00 - 30 Apr 2021 -
Re: Shipping Costs
to add shipping as cost in accounting, you need to have a vendor bill. a cost must have a contra in the balance sheet (e.g payable or cash)the sales module only look at the revenue side.--On Fri, 30 Apr 2021 at 5:12 PM, Daniel Reis <dreis@opensourceintegrators.com> wrote:This is is concerned with outgoing stock and COGS.
I could be wrong, but I think that landing costs is for incoming stock, and their stock valuation.
Correct?
On 30/04/2021 08:57, Antonio M. Vigliotti (gmail) wrote:
Did you see the landing cost module?
--
Daniel Reis
Managing Director
M: +351 919991307
E: DReis@OpenSourceIntegrators.comAv Doutor Desidério Cambournac 12 • 2710-553 Sintra, Portugal 
_______________________________________________
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 - 03:50 - 30 Apr 2021 -
Re: Shipping Costs
Yes it is correct but I think the concept should be used to evaluate actual value in documents.
We wrote an experimental module that lands costs in every line of document, so any module can use this value per it own purpose.
Give mi some time and i write an pratical example
Antonio M. Vigliotti
Mobile (+39) 342.8740910
Il 30/04/21 11:12, Daniel Reis ha scritto:
This is is concerned with outgoing stock and COGS.
I could be wrong, but I think that landing costs is for incoming stock, and their stock valuation.
Correct?
On 30/04/2021 08:57, Antonio M. Vigliotti (gmail) wrote:
Did you see the landing cost module?
--
Daniel Reis
Managing Director
M: +351 919991307
E: DReis@OpenSourceIntegrators.comAv Doutor Desidério Cambournac 12 • 2710-553 Sintra, Portugal
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Antonio M. Vigliotti - 03:36 - 30 Apr 2021 -
Re: 30 Checkout Operations per Minute A job for Odoo or not ?
Hi Joe, nice one. I'd still probably start with a simple choice and oivot if necessary but that really more an ideological question just like the barbecue analogy. Have a great weekend Frederik Am Freitag, den 30.04.2021, 10:22 +0000 schrieb Joerg Lorenz: > Hi Fred: > > Since the barbecue season is just coming up - or has started with us > - I try to compare with the topics you brought up > > - Some are swearing on a char coal grill - for the taste and heat > - Some are rather more keen on gas grill - simpler handling, quicker > install, little to clean. > - Some are using electric power, very clean, easy, no fossile fuel > > and > > - some have a table grill, totally sufficient for two people, quick > setup, easy to clean > - some use a big grill for friends and family - more stuff in > parallel on the flames > - some have a smoker and really can do big things at once, with > marvellous taste > > At that stage - mouthwatering already - you got choices - which is > great. > > But if your solution is too small, to big - or if you have no fuel or > electricity because you want to grill in the park, you might run out > of luck with your particular choice. > > We did our due diligence mainly on versatility on scalability of > transaction and messaging products, as we want to learn and integrate > just once and use many times. > For us, we rather pick a great "foreign language" product over a poor > one with the same programming language as the ERP for a platform > strategy which is really enterprise ready. > After all, it is an open source solution and we did not have a hard > time yet implementing it about 34 times now. > > And since we own two redundant, highly automated data centers and VM > templates to be turnkey, setup - as always - is a breeze > > The sun is out, have a great barbecue, and some good beer, too. > > Cheers, Joe > Von: "frederik kramer" <frederik.kramer@initos.com> > An: "Odoo Community Association, (OCA) Contributors" < > contributors@odoo-community.org> > Gesendet: Donnerstag, 29. April 2021 14:22:07 > Betreff: Re: 30 Checkout Operations per Minute A job for Odoo or not > ? > > Hi Joe, > > on the first glance that seems to be a reasonable choice. I wonder > why > we were heading for an entire ESB as that comes at quite some cost > and > overhead in maintaince not to say often a undesirable Java stack ;-) > and not ONLy a message broker in the beginning ? > > Did you really need all the environmental functionality and > complexity > of an ESB ? > > Best Frederik > > Am Donnerstag, den 29.04.2021, 12:11 +0000 schrieb Joerg Lorenz: > > > > Hi Fred: > > > > > > > > Thanks for your swift reply. > > > > > > > > On your question: > > > > After making a shootout between various candidates, we ourselves > had > > > > chosen WSO2 (formelry called ESB, now is EI). > > > > Reason is its plugable structure, business critial shape, it stands > > > > up for high volume transaction processing (actually Ebay.com with > one > > > > billion transactions is run on its engine, see > > > > https://wso2.com/about/customers/ebay/ ) and it is open source. > > > > Best, Joe > > > > Von: "frederik kramer" <frederik.kramer@initos.com> > > > > An: "Odoo Community Association, (OCA) Contributors" < > > > > contributors@odoo-community.org> > > > > Gesendet: Donnerstag, 29. April 2021 12:46:51 > > > > Betreff: Re: 30 Checkout Operations per Minute A job for Odoo or > not > > > > ? > > > > > > > > Hi Joe, > > > > > > > > thanks for the valuable feedback. Indeed i wasn't too specific on > the > > > > scenario but its quite unlikely that an order in that business case > > > > is > > > > more than 10 items (standard only 1-2 is guess). However all > > > > considerations with decoupling checkout from logisics and financial > > > > fail in our case (a least without further design changes) because > the > > > > entire physical / financial transaction needs to be accomplished > and > > > > book in less than 10min. But of course a solid message broker > > > > architektur would be something that would be really helpful for the > > > > Odoo ecosystem. Which Message bus do you prefer in your scenarios > and > > > > for what reason, if i may ask > > > > > > > > Best Frederik > > > > > > > > Am Donnerstag, den 29.04.2021, 10:37 +0000 schrieb Joerg Lorenz: > > > > > > > > > > > > > Hi Fred: > > > > > > > > > > > > > > > > > > > > > > > > > > instead of looking into the amount of orders, I would rather look > > > > > > > > > > > > > into the amount of lines per order containing items (excluding > the > > > > > > > > > > > > > one lines that are just informational), first. > > > > > > > > > > > > > This is the key performance measure. > > > > > > > > > > > > > If the order line volume is resonable (1-3 on average on an > online > > > > > > > > > > > > > order), then die 30 to 50 a minute is a hands down job, because, > > > > > > > > > > > > > there is no posting involved, just stock reservation. Question > > > > still > > > > > > > > > > > > > is, what the response time shall be for each order? > > > > > > > > > > > > > > > > > > > > > > > > > > Also a question would be for your scenario, if those really need > to > > > > > > > > > > > > > be put as ORDERs, instead of QUOTEs - which are even simpler to > > > > > > > > > > > > > consume. > > > > > > > > > > > > > > > > > > > > > > > > > > If you like we can talk more on your requirements by phone. > > > > > > > > > > > > > > > > > > > > > > > > > > N.B. > > > > > > > > > > > > > In very high volume sceanrios we did, like with some 20000 orders > a > > > > > > > > > > > > > minute, we usually just consumed, the orders with an message > broker > > > > > > > > > > > > > first, then preprocessed there, confirmed (if no error), queued > and > > > > > > > > > > > > > batched in the the ERP for processing (we did this for DHL for > all > > > > > > > > > > > > > barcode scanners of Deutsche Post service men in Germany, rond > trip > > > > > > > > > > > > > was supposed to be less than 5 seconds to get confirmation to the > > > > > > > > > > > > > barcode scanner). > > > > > > > > > > > > > > > > > > > > > > > > > > Best Joe > > > > > > > > > > > > > > > > > > > > > > > > > > Von: "frederik kramer" <frederik.kramer@initos.com> > > > > > > > > > > > > > An: "Odoo Community Association, (OCA) Contributors" < > > > > > > > > > > > > > contributors@odoo-community.org> > > > > > > > > > > > > > Gesendet: Donnerstag, 29. April 2021 09:52:11 > > > > > > > > > > > > > Betreff: Re: 30 Checkout Operations per Minute A job for Odoo or > > > > not > > > > > > > > > > > > > ? > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Joel, hi Jordi, > > > > > > > > > > > > > > > > > > > > > > > > > > thanks for your valuable answers. For the time being we don't > > > > really > > > > > > > > > > > > > know about the real scenarios as this is a bolt pitch claim of a > VC > > > > > > > > > > > > > driven startup for now. But from the business model it seems > > > > > > > > > > > > > reasonably > > > > > > > > > > > > > realistic for me to ask before claiming something that doesn't > hold > > > > > > > > > > > > > true if it materialized. > > > > > > > > > > > > > > > > > > > > > > > > > > I am pretty sure that - given the business model - there will be > > > > rush > > > > > > > > > > > > > hours. So yes, i could even conceive 50 instead of 30 orders a > > > > > > > > > > > > > minute. > > > > > > > > > > > > > > > > > > > > > > > > > > In similar use cases that you just explained, we have been > applying > > > > > > > > > > > > > both of the strategies you mention > > > > > > > > > > > > > > > > > > > > > > > > > > 1.) Decoupling stock moves > > > > > > > > > > > > > 2.) Batch processing in off-peak times > > > > > > > > > > > > > > > > > > > > > > > > > > In the use case at stake both does not really work as the entire > > > > > > > > > > > > > transaction from Checkout to Delivery (incl. Picking) is supposed > > > > to > > > > > > > > > > > > > take less then 10 min incl. pyhsical transport. > > > > > > > > > > > > > > > > > > > > > > > > > > Nevertheless i think all of that may be doable but, i will > > > > certainly > > > > > > > > > > > > > not claim "without hassle and much invest". > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks for your answers > > > > > > > > > > > > > > > > > > > > > > > > > > Am Donnerstag, den 29.04.2021, 07:32 +0000 schrieb Joël Grand- > > > > > > > > > > > > > Guillaume: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Frederik, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yes this is a big number ! Look, first before anything else, > how > > > > > > > > > > > > > many > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > lines on average for those orders ? According to my XP, this > > > > > > > > > > > > > matters > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > a lot. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Second question is: Are there rushing hours and more calm hours > > > > ? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > In our XP we could not record more than 10 orders per minute. > Was > > > > > > > > > > > > > on > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > V 12 though, so it might have improved a bit by now. In our > case, > > > > > > > > > > > > > we > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > had a rush and calm hour. So the jobs could be recorded during > > > > rush > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > hours and processed during calm ones. It worked well, but that > > > > was > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > for not that many numbers... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > An idea would be to decoule the order confirmation from the > stock > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > move generation and do this in two different times. You could > > > > > > > > > > > > > ensure > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > the reservation using our stock allocation module. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cannot really help much at this stage, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Joël > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Apr 29, 2021 at 1:32 AM Jordi Ballester Alomar < > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > jordi.ballester@forgeflow.com> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > We have a use case with approx 5000/day. I can see how > > > > 50000/day > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > can become a hell. Imagine recomputing a field, or migrating > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > between versions. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > It's a challenge, I give you that. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Apr 28, 2021 at 10:35 PM Frederik Kramer < > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > frederik.kramer@initos.com> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Folks, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > i have a project proposal on my desk that will ultimately > end > > > > > > > > > > > > > up > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > in > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > approx. 30 checkout transactions per minute. Has anybody > got > > > > a > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > project > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > with that order volume done with a relatively recent > version > > > > of > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Odoo > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > and provide a good reference. Please bear in mind that the > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > project > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ahead involves a similarly high volume of stock moves. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Any suggestion / comment like (but not limited to) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Odoo is the wrong technology for that, forget it, > because.... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > over > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > You can do it but, a), b), c) .... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > to > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you really want that beast flying involve us over here > > > > > > > > > > > > > because > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > we > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > are among the few ones that already did soemthing similar > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > would be appreciated. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From our load intensive projects at initOS i know that > 10000 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > orders a > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > day can be handled but almost 50000 is a different story > and > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > thats why > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > i am asking the most experienced resource out there ;-) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks in advance for your replay > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers Frederik > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Dr.-Ing. Frederik Kramer > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Geschäftsführer > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > initOS GmbH > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > An der Eisenbahn 1 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 21224 Rosengarten > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Phone: +49 4105 56156-12 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Fax: +49 4105 56156-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: Rosengarten – Klecken > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Amtsgericht Tostedt, HRB 205226 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Steuer-Nr: 15/200/53247 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > USt-IdNr.: DE815580155 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Mailing-List: > > > > https://odoo-community.org/groups/contributors-15 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Post to: mailto:contributors@odoo-community.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Unsubscribe: https://odoo-community.org/groups?unsubscribe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Jordi Ballester Alomar > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > CEO & Founder | ForgeFlow > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > (+34) 629530707 | jordi.ballester@forgeflow.com | > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://www.forgeflow.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Twitter: https://twitter.com/jordibforgeflow | Linkedin: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://www.linkedin.com/in/jordiballesteralomar > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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 > > > > > > > > > > > > > An der Eisenbahn 1 > > > > > > > > > > > > > 21224 Rosengarten > > > > > > > > > > > > > > > > > > > > > > > > > > Phone: +49 4105 56156-12 > > > > > > > > > > > > > Fax: +49 4105 56156-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: Rosengarten – Klecken > > > > > > > > > > > > > Amtsgericht Tostedt, HRB 205226 > > > > > > > > > > > > > Steuer-Nr: 15/200/53247 > > > > > > > > > > > > > USt-IdNr.: DE815580155 > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > 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 > > > > An der Eisenbahn 1 > > > > 21224 Rosengarten > > > > > > > > Phone: +49 4105 56156-12 > > > > Fax: +49 4105 56156-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: Rosengarten – Klecken > > > > Amtsgericht Tostedt, HRB 205226 > > > > Steuer-Nr: 15/200/53247 > > > > USt-IdNr.: DE815580155 > > > > > > > > _______________________________________________ > > > > 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 > An der Eisenbahn 1 > 21224 Rosengarten > > Phone: +49 4105 56156-12 > Fax: +49 4105 56156-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: Rosengarten – Klecken > Amtsgericht Tostedt, HRB 205226 > Steuer-Nr: 15/200/53247 > USt-IdNr.: DE815580155 > > _______________________________________________ > 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 An der Eisenbahn 1 21224 Rosengarten Phone: +49 4105 56156-12 Fax: +49 4105 56156-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: Rosengarten – Klecken Amtsgericht Tostedt, HRB 205226 Steuer-Nr: 15/200/53247 USt-IdNr.: DE815580155
by Frederik Kramer - 12:51 - 30 Apr 2021 -
Re: 30 Checkout Operations per Minute A job for Odoo or not ?
Hi Fred:
Since the barbecue season is just coming up - or has started with us - I try to compare with the topics you brought up
- Some are swearing on a char coal grill - for the taste and heat
- Some are rather more keen on gas grill - simpler handling, quicker install, little to clean.
- Some are using electric power, very clean, easy, no fossile fuel
and
- some have a table grill, totally sufficient for two people, quick setup, easy to clean
- some use a big grill for friends and family - more stuff in parallel on the flames
- some have a smoker and really can do big things at once, with marvellous taste
At that stage - mouthwatering already - you got choices - which is great.
But if your solution is too small, to big - or if you have no fuel or electricity because you want to grill in the park, you might run out of luck with your particular choice.
We did our due diligence mainly on versatility on scalability of transaction and messaging products, as we want to learn and integrate just once and use many times.
For us, we rather pick a great "foreign language" product over a poor one with the same programming language as the ERP for a platform strategy which is really enterprise ready.
After all, it is an open source solution and we did not have a hard time yet implementing it about 34 times now.
And since we own two redundant, highly automated data centers and VM templates to be turnkey, setup - as always - is a breeze
The sun is out, have a great barbecue, and some good beer, too.
Cheers, JoeVon: "frederik kramer" <frederik.kramer@initos.com>
An: "Odoo Community Association, (OCA) Contributors" <contributors@odoo-community.org>
Gesendet: Donnerstag, 29. April 2021 14:22:07
Betreff: Re: 30 Checkout Operations per Minute A job for Odoo or not ?Hi Joe, on the first glance that seems to be a reasonable choice. I wonder why we were heading for an entire ESB as that comes at quite some cost and overhead in maintaince not to say often a undesirable Java stack ;-) and not ONLy a message broker in the beginning ? Did you really need all the environmental functionality and complexity of an ESB ? Best Frederik Am Donnerstag, den 29.04.2021, 12:11 +0000 schrieb Joerg Lorenz: > Hi Fred: > > Thanks for your swift reply. > > On your question: > After making a shootout between various candidates, we ourselves had > chosen WSO2 (formelry called ESB, now is EI). > Reason is its plugable structure, business critial shape, it stands > up for high volume transaction processing (actually Ebay.com with one > billion transactions is run on its engine, see > https://wso2.com/about/customers/ebay/ ) and it is open source. > Best, Joe > Von: "frederik kramer" <frederik.kramer@initos.com> > An: "Odoo Community Association, (OCA) Contributors" < > contributors@odoo-community.org> > Gesendet: Donnerstag, 29. April 2021 12:46:51 > Betreff: Re: 30 Checkout Operations per Minute A job for Odoo or not > ? > > Hi Joe, > > thanks for the valuable feedback. Indeed i wasn't too specific on the > scenario but its quite unlikely that an order in that business case > is > more than 10 items (standard only 1-2 is guess). However all > considerations with decoupling checkout from logisics and financial > fail in our case (a least without further design changes) because the > entire physical / financial transaction needs to be accomplished and > book in less than 10min. But of course a solid message broker > architektur would be something that would be really helpful for the > Odoo ecosystem. Which Message bus do you prefer in your scenarios and > for what reason, if i may ask > > Best Frederik > > Am Donnerstag, den 29.04.2021, 10:37 +0000 schrieb Joerg Lorenz: > > > > Hi Fred: > > > > > > > > instead of looking into the amount of orders, I would rather look > > > > into the amount of lines per order containing items (excluding the > > > > one lines that are just informational), first. > > > > This is the key performance measure. > > > > If the order line volume is resonable (1-3 on average on an online > > > > order), then die 30 to 50 a minute is a hands down job, because, > > > > there is no posting involved, just stock reservation. Question > still > > > > is, what the response time shall be for each order? > > > > > > > > Also a question would be for your scenario, if those really need to > > > > be put as ORDERs, instead of QUOTEs - which are even simpler to > > > > consume. > > > > > > > > If you like we can talk more on your requirements by phone. > > > > > > > > N.B. > > > > In very high volume sceanrios we did, like with some 20000 orders a > > > > minute, we usually just consumed, the orders with an message broker > > > > first, then preprocessed there, confirmed (if no error), queued and > > > > batched in the the ERP for processing (we did this for DHL for all > > > > barcode scanners of Deutsche Post service men in Germany, rond trip > > > > was supposed to be less than 5 seconds to get confirmation to the > > > > barcode scanner). > > > > > > > > Best Joe > > > > > > > > Von: "frederik kramer" <frederik.kramer@initos.com> > > > > An: "Odoo Community Association, (OCA) Contributors" < > > > > contributors@odoo-community.org> > > > > Gesendet: Donnerstag, 29. April 2021 09:52:11 > > > > Betreff: Re: 30 Checkout Operations per Minute A job for Odoo or > not > > > > ? > > > > > > > > Hi Joel, hi Jordi, > > > > > > > > thanks for your valuable answers. For the time being we don't > really > > > > know about the real scenarios as this is a bolt pitch claim of a VC > > > > driven startup for now. But from the business model it seems > > > > reasonably > > > > realistic for me to ask before claiming something that doesn't hold > > > > true if it materialized. > > > > > > > > I am pretty sure that - given the business model - there will be > rush > > > > hours. So yes, i could even conceive 50 instead of 30 orders a > > > > minute. > > > > > > > > In similar use cases that you just explained, we have been applying > > > > both of the strategies you mention > > > > > > > > 1.) Decoupling stock moves > > > > 2.) Batch processing in off-peak times > > > > > > > > In the use case at stake both does not really work as the entire > > > > transaction from Checkout to Delivery (incl. Picking) is supposed > to > > > > take less then 10 min incl. pyhsical transport. > > > > > > > > Nevertheless i think all of that may be doable but, i will > certainly > > > > not claim "without hassle and much invest". > > > > > > > > Thanks for your answers > > > > > > > > Am Donnerstag, den 29.04.2021, 07:32 +0000 schrieb Joël Grand- > > > > Guillaume: > > > > > > > > > > > > > Hi Frederik, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yes this is a big number ! Look, first before anything else, how > > > > many > > > > > > > > > > > > > lines on average for those orders ? According to my XP, this > > > > matters > > > > > > > > > > > > > a lot. > > > > > > > > > > > > > > > > > > > > > > > > > > Second question is: Are there rushing hours and more calm hours > ? > > > > > > > > > > > > > > > > > > > > > > > > > > In our XP we could not record more than 10 orders per minute. Was > > > > on > > > > > > > > > > > > > V 12 though, so it might have improved a bit by now. In our case, > > > > we > > > > > > > > > > > > > had a rush and calm hour. So the jobs could be recorded during > rush > > > > > > > > > > > > > hours and processed during calm ones. It worked well, but that > was > > > > > > > > > > > > > for not that many numbers... > > > > > > > > > > > > > > > > > > > > > > > > > > An idea would be to decoule the order confirmation from the stock > > > > > > > > > > > > > move generation and do this in two different times. You could > > > > ensure > > > > > > > > > > > > > the reservation using our stock allocation module. > > > > > > > > > > > > > > > > > > > > > > > > > > Cannot really help much at this stage, > > > > > > > > > > > > > > > > > > > > > > > > > > Joël > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Apr 29, 2021 at 1:32 AM Jordi Ballester Alomar < > > > > > > > > > > > > > jordi.ballester@forgeflow.com> wrote: > > > > > > > > > > > > > > We have a use case with approx 5000/day. I can see how > 50000/day > > > > > > > > > > > > > > can become a hell. Imagine recomputing a field, or migrating > > > > > > > > > > > > > > between versions. > > > > > > > > > > > > > > > > > > > > > > > > > > > > It's a challenge, I give you that. > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Apr 28, 2021 at 10:35 PM Frederik Kramer < > > > > > > > > > > > > > > frederik.kramer@initos.com> wrote: > > > > > > > > > > > > > > > Hi Folks, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > i have a project proposal on my desk that will ultimately end > > > > up > > > > > > > > > > > > > > > in > > > > > > > > > > > > > > > approx. 30 checkout transactions per minute. Has anybody got > a > > > > > > > > > > > > > > > project > > > > > > > > > > > > > > > with that order volume done with a relatively recent version > of > > > > > > > > > > > > > > > Odoo > > > > > > > > > > > > > > > and provide a good reference. Please bear in mind that the > > > > > > > > > > > > > > > project > > > > > > > > > > > > > > > ahead involves a similarly high volume of stock moves. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Any suggestion / comment like (but not limited to) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Odoo is the wrong technology for that, forget it, because.... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > over > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > You can do it but, a), b), c) .... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > to > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you really want that beast flying involve us over here > > > > because > > > > > > > > > > > > > > > we > > > > > > > > > > > > > > > are among the few ones that already did soemthing similar > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > would be appreciated. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From our load intensive projects at initOS i know that 10000 > > > > > > > > > > > > > > > orders a > > > > > > > > > > > > > > > day can be handled but almost 50000 is a different story and > > > > > > > > > > > > > > > thats why > > > > > > > > > > > > > > > i am asking the most experienced resource out there ;-) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks in advance for your replay > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers Frederik > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > Dr.-Ing. Frederik Kramer > > > > > > > > > > > > > > > Geschäftsführer > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > initOS GmbH > > > > > > > > > > > > > > > An der Eisenbahn 1 > > > > > > > > > > > > > > > 21224 Rosengarten > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Phone: +49 4105 56156-12 > > > > > > > > > > > > > > > Fax: +49 4105 56156-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: Rosengarten – Klecken > > > > > > > > > > > > > > > Amtsgericht Tostedt, HRB 205226 > > > > > > > > > > > > > > > Steuer-Nr: 15/200/53247 > > > > > > > > > > > > > > > USt-IdNr.: DE815580155 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > > > Mailing-List: > https://odoo-community.org/groups/contributors-15 > > > > > > > > > > > > > > > Post to: mailto:contributors@odoo-community.org > > > > > > > > > > > > > > > Unsubscribe: https://odoo-community.org/groups?unsubscribe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > Jordi Ballester Alomar > > > > > > > > > > > > > > CEO & Founder | ForgeFlow > > > > > > > > > > > > > > (+34) 629530707 | jordi.ballester@forgeflow.com | > > > > > > > > > > > > > > https://www.forgeflow.com > > > > > > > > > > > > > > Twitter: https://twitter.com/jordibforgeflow | Linkedin: > > > > > > > > > > > > > > https://www.linkedin.com/in/jordiballesteralomar > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > > 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 > > > > An der Eisenbahn 1 > > > > 21224 Rosengarten > > > > > > > > Phone: +49 4105 56156-12 > > > > Fax: +49 4105 56156-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: Rosengarten – Klecken > > > > Amtsgericht Tostedt, HRB 205226 > > > > Steuer-Nr: 15/200/53247 > > > > USt-IdNr.: DE815580155 > > > > > > > > _______________________________________________ > > > > 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 > An der Eisenbahn 1 > 21224 Rosengarten > > Phone: +49 4105 56156-12 > Fax: +49 4105 56156-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: Rosengarten – Klecken > Amtsgericht Tostedt, HRB 205226 > Steuer-Nr: 15/200/53247 > USt-IdNr.: DE815580155 > > _______________________________________________ > 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 An der Eisenbahn 1 21224 Rosengarten Phone: +49 4105 56156-12 Fax: +49 4105 56156-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: Rosengarten – Klecken Amtsgericht Tostedt, HRB 205226 Steuer-Nr: 15/200/53247 USt-IdNr.: DE815580155
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Joerg Lorenz. - 12:21 - 30 Apr 2021 -
Re: Shipping Costs
This is is concerned with outgoing stock and COGS.
I could be wrong, but I think that landing costs is for incoming stock, and their stock valuation.
Correct?
On 30/04/2021 08:57, Antonio M. Vigliotti (gmail) wrote:
Did you see the landing cost module?
--
Daniel Reis
Managing Director
M: +351 919991307
E: DReis@OpenSourceIntegrators.comAv Doutor Desidério Cambournac 12 • 2710-553 Sintra, Portugal
by Daniel Reis - 11:11 - 30 Apr 2021 -
Re: Shipping Costs
Did you see the landing cost module?
Antonio M. Vigliotti
Mobile (+39) 342.8740910
Il 29/04/21 17:02, Daniel Reis ha scritto:
Hello,
I found this requirement that I don't see existing features to support it.
Target version is Odoo 14.
A Sales order has a shipping costs line.
There is a shipping price charged to the customer, that is zero in most cases.
And there is an actual cost, that should depend on the delivery method we end up using.
The first gap is that the "Update Shipping Cost" button on the Sales Order updates the *price*, and not the cost.
The second gap is that, if you do set an amount on the SO line cost field, it is not carried over to the invoice.
The account_invoice_margin module solves this, but then, when posting the invoice this cost information is not used for the posting, and is not recorded in the accounting entries.
I'm ready to create a module to support this case, but I'm wondering if I am missing something here.
Am I thinking through this right?
Thanks!
--
Daniel Reis
Managing Director
M: +351 919991307
E: DReis@OpenSourceIntegrators.comAv Doutor Desidério Cambournac 12 • 2710-553 Sintra, Portugal
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Antonio M. Vigliotti - 09:56 - 30 Apr 2021 -
Re: Following the bank statement changes in v14
As this message was blocked during several days, I copied it on this github issue : https://github.com/OCA/bank-payment/issues/740Please refer to the conversion that took place there. The module account_check_deposit has already been updated ; the account_payment_order module will be updated soon.Le mer. 21 avr. 2021 à 21:28, Alexis de Lattre <alexis.delattre@akretion.com> a écrit :Dear OCA friends,Now that most of the key OCA accounting modules are ported to Odoo v14 and that the features that were moved to Odoo Enterprise have been restored in OCA (account_reconciliation_widget in OCA/account-reconcile and account_statement_import in OCA/bank-statement-import), I'm starting to do some real life end-to-end accounting scenarios in Odoo Community v14.The scenario I'm currently testing is the following:- create several vendor bills- add vendor bills to payment order- confirm SEPA payment order- import bank statement with 1 statement line with total amount of paymentIn previous odoo version, if the payment mode was configured with "offsetting_account" = "bank_account", it would generate an account move with the bank account as counterpart account ; and then, in the bank statement reconcile interface, you would match with a proposed blue line and it would not create a new account move but it would update the account move generated by the payment order and link it to the bank statement line.As far as I understand (please correct me if I'm wrong !), this accounting scenario is not possible in Odoo v14. According to my tests on runbot Enterprise, when you are in the bank statement reconcile interface, you can still see blue lines in the proposals, but selecting blue lines will generate a new journal entry, it won't update the journal entry of the payment.In short, the accounting scenario of vendor bill => SEPA payment => bank statement :- with Odoo v9 to v13 with "offsetting_account" = "bank_account" : expense account => supplier account => bank account (total : 3 accounts)- with odoo v14 : expense account => supplier account => Outstanding Payments Account => bank account (total : 4 accounts)So the accounting scenario is similar to what we used to do in v8 with the transfer account (now named "Outstanding Payments Account") before the introduction of the concept of "blue lines" on the bank statement reconcile interface.If this is confirmed, I plan to update the following OCA modules:- account_payment_order from OCA/bank-payment : remove the fields "offsetting_account" and "transfer_account_id" on account.payment.mode. We would keep the field "transfer_journal_id" because you may want to have the journal entry "supplier account => Outstanding Payments Account" in a specific journal that may not be the bank journal.- on account_check_deposit in OCA/account-financial-tools (pending PR https://github.com/OCA/account-financial-tools/pull/1088) : remove the fields "check_deposit_offsetting_account" and "check_deposit_transfer_account_id" on res.company.As these are important changes, I prefer to post this message before modifying the code.And I made a PR to remove the condition payment_id != false on account.move.line in the module account_reconciliation_widget:--Alexis de Lattre
--Alexis de Lattre
Akretion France - 27 rue Henri Rolland - 69100 Villeurbanne - France
Mail : alexis.delattre@akretion.comMobile : +33 6 99 08 92 45
by Alexis de Lattre - 09:20 - 30 Apr 2021 -
Re: New module for data synchronization between Odoo instances
When discussing early options, we were no comfortable with bd-level sync.
I see a lot of potential for intractable Odoo issues.
My personal preference is for something at the ORM level
On 28/04/2021 21:32, Cyril VINH-TUNG wrote:
I would be interested with your work about data sync between instancesWe have a use case here with a pos on a boat without internet access when at sea...We are considering synchro at db level with bucardo...
--
Daniel Reis
Managing Director
M: +351 919991307
E: DReis@OpenSourceIntegrators.comAv Doutor Desidério Cambournac 12 • 2710-553 Sintra, Portugal
by Daniel Reis - 09:56 - 29 Apr 2021 -
Re: Shipping Costs
Cost of 1. Use quantity. Would be my simple workaround.On Fri, 30 Apr 2021, 3:02 am Daniel Reis, <dreis@opensourceintegrators.com> wrote:Hello,
I found this requirement that I don't see existing features to support it.
Target version is Odoo 14.
A Sales order has a shipping costs line.
There is a shipping price charged to the customer, that is zero in most cases.
And there is an actual cost, that should depend on the delivery method we end up using.
The first gap is that the "Update Shipping Cost" button on the Sales Order updates the *price*, and not the cost.
The second gap is that, if you do set an amount on the SO line cost field, it is not carried over to the invoice.
The account_invoice_margin module solves this, but then, when posting the invoice this cost information is not used for the posting, and is not recorded in the accounting entries.
I'm ready to create a module to support this case, but I'm wondering if I am missing something here.
Am I thinking through this right?
Thanks!
--
Daniel Reis
Managing Director
M: +351 919991307
E: DReis@OpenSourceIntegrators.comAv Doutor Desidério Cambournac 12 • 2710-553 Sintra, Portugal
_______________________________________________
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 - 09:06 - 29 Apr 2021 -
Shipping Costs
Hello,
I found this requirement that I don't see existing features to support it.
Target version is Odoo 14.
A Sales order has a shipping costs line.
There is a shipping price charged to the customer, that is zero in most cases.
And there is an actual cost, that should depend on the delivery method we end up using.
The first gap is that the "Update Shipping Cost" button on the Sales Order updates the *price*, and not the cost.
The second gap is that, if you do set an amount on the SO line cost field, it is not carried over to the invoice.
The account_invoice_margin module solves this, but then, when posting the invoice this cost information is not used for the posting, and is not recorded in the accounting entries.
I'm ready to create a module to support this case, but I'm wondering if I am missing something here.
Am I thinking through this right?
Thanks!
--
Daniel Reis
Managing Director
M: +351 919991307
E: DReis@OpenSourceIntegrators.comAv Doutor Desidério Cambournac 12 • 2710-553 Sintra, Portugal
by Daniel Reis - 05:01 - 29 Apr 2021 -
Re: 30 Checkout Operations per Minute A job for Odoo or not ?
Hi Joe, on the first glance that seems to be a reasonable choice. I wonder why we were heading for an entire ESB as that comes at quite some cost and overhead in maintaince not to say often a undesirable Java stack ;-) and not ONLy a message broker in the beginning ? Did you really need all the environmental functionality and complexity of an ESB ? Best Frederik Am Donnerstag, den 29.04.2021, 12:11 +0000 schrieb Joerg Lorenz: > Hi Fred: > > Thanks for your swift reply. > > On your question: > After making a shootout between various candidates, we ourselves had > chosen WSO2 (formelry called ESB, now is EI). > Reason is its plugable structure, business critial shape, it stands > up for high volume transaction processing (actually Ebay.com with one > billion transactions is run on its engine, see > https://wso2.com/about/customers/ebay/ ) and it is open source. > Best, Joe > Von: "frederik kramer" <frederik.kramer@initos.com> > An: "Odoo Community Association, (OCA) Contributors" < > contributors@odoo-community.org> > Gesendet: Donnerstag, 29. April 2021 12:46:51 > Betreff: Re: 30 Checkout Operations per Minute A job for Odoo or not > ? > > Hi Joe, > > thanks for the valuable feedback. Indeed i wasn't too specific on the > scenario but its quite unlikely that an order in that business case > is > more than 10 items (standard only 1-2 is guess). However all > considerations with decoupling checkout from logisics and financial > fail in our case (a least without further design changes) because the > entire physical / financial transaction needs to be accomplished and > book in less than 10min. But of course a solid message broker > architektur would be something that would be really helpful for the > Odoo ecosystem. Which Message bus do you prefer in your scenarios and > for what reason, if i may ask > > Best Frederik > > Am Donnerstag, den 29.04.2021, 10:37 +0000 schrieb Joerg Lorenz: > > > > Hi Fred: > > > > > > > > instead of looking into the amount of orders, I would rather look > > > > into the amount of lines per order containing items (excluding the > > > > one lines that are just informational), first. > > > > This is the key performance measure. > > > > If the order line volume is resonable (1-3 on average on an online > > > > order), then die 30 to 50 a minute is a hands down job, because, > > > > there is no posting involved, just stock reservation. Question > still > > > > is, what the response time shall be for each order? > > > > > > > > Also a question would be for your scenario, if those really need to > > > > be put as ORDERs, instead of QUOTEs - which are even simpler to > > > > consume. > > > > > > > > If you like we can talk more on your requirements by phone. > > > > > > > > N.B. > > > > In very high volume sceanrios we did, like with some 20000 orders a > > > > minute, we usually just consumed, the orders with an message broker > > > > first, then preprocessed there, confirmed (if no error), queued and > > > > batched in the the ERP for processing (we did this for DHL for all > > > > barcode scanners of Deutsche Post service men in Germany, rond trip > > > > was supposed to be less than 5 seconds to get confirmation to the > > > > barcode scanner). > > > > > > > > Best Joe > > > > > > > > Von: "frederik kramer" <frederik.kramer@initos.com> > > > > An: "Odoo Community Association, (OCA) Contributors" < > > > > contributors@odoo-community.org> > > > > Gesendet: Donnerstag, 29. April 2021 09:52:11 > > > > Betreff: Re: 30 Checkout Operations per Minute A job for Odoo or > not > > > > ? > > > > > > > > Hi Joel, hi Jordi, > > > > > > > > thanks for your valuable answers. For the time being we don't > really > > > > know about the real scenarios as this is a bolt pitch claim of a VC > > > > driven startup for now. But from the business model it seems > > > > reasonably > > > > realistic for me to ask before claiming something that doesn't hold > > > > true if it materialized. > > > > > > > > I am pretty sure that - given the business model - there will be > rush > > > > hours. So yes, i could even conceive 50 instead of 30 orders a > > > > minute. > > > > > > > > In similar use cases that you just explained, we have been applying > > > > both of the strategies you mention > > > > > > > > 1.) Decoupling stock moves > > > > 2.) Batch processing in off-peak times > > > > > > > > In the use case at stake both does not really work as the entire > > > > transaction from Checkout to Delivery (incl. Picking) is supposed > to > > > > take less then 10 min incl. pyhsical transport. > > > > > > > > Nevertheless i think all of that may be doable but, i will > certainly > > > > not claim "without hassle and much invest". > > > > > > > > Thanks for your answers > > > > > > > > Am Donnerstag, den 29.04.2021, 07:32 +0000 schrieb Joël Grand- > > > > Guillaume: > > > > > > > > > > > > > Hi Frederik, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yes this is a big number ! Look, first before anything else, how > > > > many > > > > > > > > > > > > > lines on average for those orders ? According to my XP, this > > > > matters > > > > > > > > > > > > > a lot. > > > > > > > > > > > > > > > > > > > > > > > > > > Second question is: Are there rushing hours and more calm hours > ? > > > > > > > > > > > > > > > > > > > > > > > > > > In our XP we could not record more than 10 orders per minute. Was > > > > on > > > > > > > > > > > > > V 12 though, so it might have improved a bit by now. In our case, > > > > we > > > > > > > > > > > > > had a rush and calm hour. So the jobs could be recorded during > rush > > > > > > > > > > > > > hours and processed during calm ones. It worked well, but that > was > > > > > > > > > > > > > for not that many numbers... > > > > > > > > > > > > > > > > > > > > > > > > > > An idea would be to decoule the order confirmation from the stock > > > > > > > > > > > > > move generation and do this in two different times. You could > > > > ensure > > > > > > > > > > > > > the reservation using our stock allocation module. > > > > > > > > > > > > > > > > > > > > > > > > > > Cannot really help much at this stage, > > > > > > > > > > > > > > > > > > > > > > > > > > Joël > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Apr 29, 2021 at 1:32 AM Jordi Ballester Alomar < > > > > > > > > > > > > > jordi.ballester@forgeflow.com> wrote: > > > > > > > > > > > > > > We have a use case with approx 5000/day. I can see how > 50000/day > > > > > > > > > > > > > > can become a hell. Imagine recomputing a field, or migrating > > > > > > > > > > > > > > between versions. > > > > > > > > > > > > > > > > > > > > > > > > > > > > It's a challenge, I give you that. > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Apr 28, 2021 at 10:35 PM Frederik Kramer < > > > > > > > > > > > > > > frederik.kramer@initos.com> wrote: > > > > > > > > > > > > > > > Hi Folks, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > i have a project proposal on my desk that will ultimately end > > > > up > > > > > > > > > > > > > > > in > > > > > > > > > > > > > > > approx. 30 checkout transactions per minute. Has anybody got > a > > > > > > > > > > > > > > > project > > > > > > > > > > > > > > > with that order volume done with a relatively recent version > of > > > > > > > > > > > > > > > Odoo > > > > > > > > > > > > > > > and provide a good reference. Please bear in mind that the > > > > > > > > > > > > > > > project > > > > > > > > > > > > > > > ahead involves a similarly high volume of stock moves. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Any suggestion / comment like (but not limited to) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Odoo is the wrong technology for that, forget it, because.... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > over > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > You can do it but, a), b), c) .... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > to > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you really want that beast flying involve us over here > > > > because > > > > > > > > > > > > > > > we > > > > > > > > > > > > > > > are among the few ones that already did soemthing similar > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > would be appreciated. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From our load intensive projects at initOS i know that 10000 > > > > > > > > > > > > > > > orders a > > > > > > > > > > > > > > > day can be handled but almost 50000 is a different story and > > > > > > > > > > > > > > > thats why > > > > > > > > > > > > > > > i am asking the most experienced resource out there ;-) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks in advance for your replay > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers Frederik > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > Dr.-Ing. Frederik Kramer > > > > > > > > > > > > > > > Geschäftsführer > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > initOS GmbH > > > > > > > > > > > > > > > An der Eisenbahn 1 > > > > > > > > > > > > > > > 21224 Rosengarten > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Phone: +49 4105 56156-12 > > > > > > > > > > > > > > > Fax: +49 4105 56156-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: Rosengarten – Klecken > > > > > > > > > > > > > > > Amtsgericht Tostedt, HRB 205226 > > > > > > > > > > > > > > > Steuer-Nr: 15/200/53247 > > > > > > > > > > > > > > > USt-IdNr.: DE815580155 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > > > Mailing-List: > https://odoo-community.org/groups/contributors-15 > > > > > > > > > > > > > > > Post to: mailto:contributors@odoo-community.org > > > > > > > > > > > > > > > Unsubscribe: https://odoo-community.org/groups?unsubscribe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > Jordi Ballester Alomar > > > > > > > > > > > > > > CEO & Founder | ForgeFlow > > > > > > > > > > > > > > (+34) 629530707 | jordi.ballester@forgeflow.com | > > > > > > > > > > > > > > https://www.forgeflow.com > > > > > > > > > > > > > > Twitter: https://twitter.com/jordibforgeflow | Linkedin: > > > > > > > > > > > > > > https://www.linkedin.com/in/jordiballesteralomar > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > > 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 > > > > An der Eisenbahn 1 > > > > 21224 Rosengarten > > > > > > > > Phone: +49 4105 56156-12 > > > > Fax: +49 4105 56156-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: Rosengarten – Klecken > > > > Amtsgericht Tostedt, HRB 205226 > > > > Steuer-Nr: 15/200/53247 > > > > USt-IdNr.: DE815580155 > > > > > > > > _______________________________________________ > > > > 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 > An der Eisenbahn 1 > 21224 Rosengarten > > Phone: +49 4105 56156-12 > Fax: +49 4105 56156-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: Rosengarten – Klecken > Amtsgericht Tostedt, HRB 205226 > Steuer-Nr: 15/200/53247 > USt-IdNr.: DE815580155 > > _______________________________________________ > 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 An der Eisenbahn 1 21224 Rosengarten Phone: +49 4105 56156-12 Fax: +49 4105 56156-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: Rosengarten – Klecken Amtsgericht Tostedt, HRB 205226 Steuer-Nr: 15/200/53247 USt-IdNr.: DE815580155
by Frederik Kramer - 02:20 - 29 Apr 2021 -
Re: 30 Checkout Operations per Minute A job for Odoo or not ?
Hi Fred:Thanks for your swift reply.On your question:After making a shootout between various candidates, we ourselves had chosen WSO2 (formelry called ESB, now is EI).Reason is its plugable structure, business critial shape, it stands up for high volume transaction processing (actually Ebay.com with one billion transactions is run on its engine, see https://wso2.com/about/customers/ebay/ ) and it is open source.Best, JoeVon: "frederik kramer" <frederik.kramer@initos.com>
An: "Odoo Community Association, (OCA) Contributors" <contributors@odoo-community.org>
Gesendet: Donnerstag, 29. April 2021 12:46:51
Betreff: Re: 30 Checkout Operations per Minute A job for Odoo or not ?Hi Joe, thanks for the valuable feedback. Indeed i wasn't too specific on the scenario but its quite unlikely that an order in that business case is more than 10 items (standard only 1-2 is guess). However all considerations with decoupling checkout from logisics and financial fail in our case (a least without further design changes) because the entire physical / financial transaction needs to be accomplished and book in less than 10min. But of course a solid message broker architektur would be something that would be really helpful for the Odoo ecosystem. Which Message bus do you prefer in your scenarios and for what reason, if i may ask Best Frederik Am Donnerstag, den 29.04.2021, 10:37 +0000 schrieb Joerg Lorenz: > Hi Fred: > > instead of looking into the amount of orders, I would rather look > into the amount of lines per order containing items (excluding the > one lines that are just informational), first. > This is the key performance measure. > If the order line volume is resonable (1-3 on average on an online > order), then die 30 to 50 a minute is a hands down job, because, > there is no posting involved, just stock reservation. Question still > is, what the response time shall be for each order? > > Also a question would be for your scenario, if those really need to > be put as ORDERs, instead of QUOTEs - which are even simpler to > consume. > > If you like we can talk more on your requirements by phone. > > N.B. > In very high volume sceanrios we did, like with some 20000 orders a > minute, we usually just consumed, the orders with an message broker > first, then preprocessed there, confirmed (if no error), queued and > batched in the the ERP for processing (we did this for DHL for all > barcode scanners of Deutsche Post service men in Germany, rond trip > was supposed to be less than 5 seconds to get confirmation to the > barcode scanner). > > Best Joe > > Von: "frederik kramer" <frederik.kramer@initos.com> > An: "Odoo Community Association, (OCA) Contributors" < > contributors@odoo-community.org> > Gesendet: Donnerstag, 29. April 2021 09:52:11 > Betreff: Re: 30 Checkout Operations per Minute A job for Odoo or not > ? > > Hi Joel, hi Jordi, > > thanks for your valuable answers. For the time being we don't really > know about the real scenarios as this is a bolt pitch claim of a VC > driven startup for now. But from the business model it seems > reasonably > realistic for me to ask before claiming something that doesn't hold > true if it materialized. > > I am pretty sure that - given the business model - there will be rush > hours. So yes, i could even conceive 50 instead of 30 orders a > minute. > > In similar use cases that you just explained, we have been applying > both of the strategies you mention > > 1.) Decoupling stock moves > 2.) Batch processing in off-peak times > > In the use case at stake both does not really work as the entire > transaction from Checkout to Delivery (incl. Picking) is supposed to > take less then 10 min incl. pyhsical transport. > > Nevertheless i think all of that may be doable but, i will certainly > not claim "without hassle and much invest". > > Thanks for your answers > > Am Donnerstag, den 29.04.2021, 07:32 +0000 schrieb Joël Grand- > Guillaume: > > > > Hi Frederik, > > > > > > > > > > > > Yes this is a big number ! Look, first before anything else, how > many > > > > lines on average for those orders ? According to my XP, this > matters > > > > a lot. > > > > > > > > Second question is: Are there rushing hours and more calm hours ? > > > > > > > > In our XP we could not record more than 10 orders per minute. Was > on > > > > V 12 though, so it might have improved a bit by now. In our case, > we > > > > had a rush and calm hour. So the jobs could be recorded during rush > > > > hours and processed during calm ones. It worked well, but that was > > > > for not that many numbers... > > > > > > > > An idea would be to decoule the order confirmation from the stock > > > > move generation and do this in two different times. You could > ensure > > > > the reservation using our stock allocation module. > > > > > > > > Cannot really help much at this stage, > > > > > > > > Joël > > > > > > > > > > > > On Thu, Apr 29, 2021 at 1:32 AM Jordi Ballester Alomar < > > > > jordi.ballester@forgeflow.com> wrote: > > > > > We have a use case with approx 5000/day. I can see how 50000/day > > > > > can become a hell. Imagine recomputing a field, or migrating > > > > > between versions. > > > > > > > > > > It's a challenge, I give you that. > > > > > > > > > > On Wed, Apr 28, 2021 at 10:35 PM Frederik Kramer < > > > > > frederik.kramer@initos.com> wrote: > > > > > > Hi Folks, > > > > > > > > > > > > i have a project proposal on my desk that will ultimately end > up > > > > > > in > > > > > > approx. 30 checkout transactions per minute. Has anybody got a > > > > > > project > > > > > > with that order volume done with a relatively recent version of > > > > > > Odoo > > > > > > and provide a good reference. Please bear in mind that the > > > > > > project > > > > > > ahead involves a similarly high volume of stock moves. > > > > > > > > > > > > Any suggestion / comment like (but not limited to) > > > > > > > > > > > > Odoo is the wrong technology for that, forget it, because.... > > > > > > > > > > > > over > > > > > > > > > > > > You can do it but, a), b), c) .... > > > > > > > > > > > > to > > > > > > > > > > > > If you really want that beast flying involve us over here > because > > > > > > we > > > > > > are among the few ones that already did soemthing similar > > > > > > > > > > > > would be appreciated. > > > > > > > > > > > > From our load intensive projects at initOS i know that 10000 > > > > > > orders a > > > > > > day can be handled but almost 50000 is a different story and > > > > > > thats why > > > > > > i am asking the most experienced resource out there ;-) > > > > > > > > > > > > Thanks in advance for your replay > > > > > > > > > > > > Cheers Frederik > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Dr.-Ing. Frederik Kramer > > > > > > Geschäftsführer > > > > > > > > > > > > initOS GmbH > > > > > > An der Eisenbahn 1 > > > > > > 21224 Rosengarten > > > > > > > > > > > > Phone: +49 4105 56156-12 > > > > > > Fax: +49 4105 56156-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: Rosengarten – Klecken > > > > > > Amtsgericht Tostedt, HRB 205226 > > > > > > Steuer-Nr: 15/200/53247 > > > > > > USt-IdNr.: DE815580155 > > > > > > > > > > > > _______________________________________________ > > > > > > Mailing-List: https://odoo-community.org/groups/contributors-15 > > > > > > Post to: mailto:contributors@odoo-community.org > > > > > > Unsubscribe: https://odoo-community.org/groups?unsubscribe > > > > > > > > > > > > > > > -- > > > > > Jordi Ballester Alomar > > > > > CEO & Founder | ForgeFlow > > > > > (+34) 629530707 | jordi.ballester@forgeflow.com | > > > > > https://www.forgeflow.com > > > > > Twitter: https://twitter.com/jordibforgeflow | Linkedin: > > > > > https://www.linkedin.com/in/jordiballesteralomar > > > > > _______________________________________________ > > > > > 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 > An der Eisenbahn 1 > 21224 Rosengarten > > Phone: +49 4105 56156-12 > Fax: +49 4105 56156-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: Rosengarten – Klecken > Amtsgericht Tostedt, HRB 205226 > Steuer-Nr: 15/200/53247 > USt-IdNr.: DE815580155 > > _______________________________________________ > 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 An der Eisenbahn 1 21224 Rosengarten Phone: +49 4105 56156-12 Fax: +49 4105 56156-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: Rosengarten – Klecken Amtsgericht Tostedt, HRB 205226 Steuer-Nr: 15/200/53247 USt-IdNr.: DE815580155
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Joerg Lorenz. - 02:10 - 29 Apr 2021 -
Re: By pass security rule on some situation.
I stand by my claim that allowing to turn off security rules from the client side is a horribly bad idea. If you need this, that means you designed the security rules wrongly, so better go back to the drawing board to write security rules you don't need to bypass. -- Your partner for the hard Odoo problems https://hunki-enterprises.com
by Holger Brunn - 02:06 - 29 Apr 2021 -
Re: By pass security rule on some situation.
On Wed, 28 Apr 2021 at 22:32, Kitti Upariphutthiphong <kittiu@ecosoft.co.th> wrote:Dear community,I want to bypass some field model's security rule. So far, we pass context to tell search/read function to use sudo().But I found this module as the solution we need https://apps.odoo.com/apps/modules/10.0/dynamic_bypass_record_rule/May to double check if community already has something already, else I will ask the author to include it in OCA.Thanks!Kitti U._______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--Lorenzo Battistini
https://github.com/eLBati
by Lorenzo Battistini. - 01:51 - 29 Apr 2021 -
Re: 30 Checkout Operations per Minute A job for Odoo or not ?
Hi Joe, thanks for the valuable feedback. Indeed i wasn't too specific on the scenario but its quite unlikely that an order in that business case is more than 10 items (standard only 1-2 is guess). However all considerations with decoupling checkout from logisics and financial fail in our case (a least without further design changes) because the entire physical / financial transaction needs to be accomplished and book in less than 10min. But of course a solid message broker architektur would be something that would be really helpful for the Odoo ecosystem. Which Message bus do you prefer in your scenarios and for what reason, if i may ask Best Frederik Am Donnerstag, den 29.04.2021, 10:37 +0000 schrieb Joerg Lorenz: > Hi Fred: > > instead of looking into the amount of orders, I would rather look > into the amount of lines per order containing items (excluding the > one lines that are just informational), first. > This is the key performance measure. > If the order line volume is resonable (1-3 on average on an online > order), then die 30 to 50 a minute is a hands down job, because, > there is no posting involved, just stock reservation. Question still > is, what the response time shall be for each order? > > Also a question would be for your scenario, if those really need to > be put as ORDERs, instead of QUOTEs - which are even simpler to > consume. > > If you like we can talk more on your requirements by phone. > > N.B. > In very high volume sceanrios we did, like with some 20000 orders a > minute, we usually just consumed, the orders with an message broker > first, then preprocessed there, confirmed (if no error), queued and > batched in the the ERP for processing (we did this for DHL for all > barcode scanners of Deutsche Post service men in Germany, rond trip > was supposed to be less than 5 seconds to get confirmation to the > barcode scanner). > > Best Joe > > Von: "frederik kramer" <frederik.kramer@initos.com> > An: "Odoo Community Association, (OCA) Contributors" < > contributors@odoo-community.org> > Gesendet: Donnerstag, 29. April 2021 09:52:11 > Betreff: Re: 30 Checkout Operations per Minute A job for Odoo or not > ? > > Hi Joel, hi Jordi, > > thanks for your valuable answers. For the time being we don't really > know about the real scenarios as this is a bolt pitch claim of a VC > driven startup for now. But from the business model it seems > reasonably > realistic for me to ask before claiming something that doesn't hold > true if it materialized. > > I am pretty sure that - given the business model - there will be rush > hours. So yes, i could even conceive 50 instead of 30 orders a > minute. > > In similar use cases that you just explained, we have been applying > both of the strategies you mention > > 1.) Decoupling stock moves > 2.) Batch processing in off-peak times > > In the use case at stake both does not really work as the entire > transaction from Checkout to Delivery (incl. Picking) is supposed to > take less then 10 min incl. pyhsical transport. > > Nevertheless i think all of that may be doable but, i will certainly > not claim "without hassle and much invest". > > Thanks for your answers > > Am Donnerstag, den 29.04.2021, 07:32 +0000 schrieb Joël Grand- > Guillaume: > > > > Hi Frederik, > > > > > > > > > > > > Yes this is a big number ! Look, first before anything else, how > many > > > > lines on average for those orders ? According to my XP, this > matters > > > > a lot. > > > > > > > > Second question is: Are there rushing hours and more calm hours ? > > > > > > > > In our XP we could not record more than 10 orders per minute. Was > on > > > > V 12 though, so it might have improved a bit by now. In our case, > we > > > > had a rush and calm hour. So the jobs could be recorded during rush > > > > hours and processed during calm ones. It worked well, but that was > > > > for not that many numbers... > > > > > > > > An idea would be to decoule the order confirmation from the stock > > > > move generation and do this in two different times. You could > ensure > > > > the reservation using our stock allocation module. > > > > > > > > Cannot really help much at this stage, > > > > > > > > Joël > > > > > > > > > > > > On Thu, Apr 29, 2021 at 1:32 AM Jordi Ballester Alomar < > > > > jordi.ballester@forgeflow.com> wrote: > > > > > We have a use case with approx 5000/day. I can see how 50000/day > > > > > can become a hell. Imagine recomputing a field, or migrating > > > > > between versions. > > > > > > > > > > It's a challenge, I give you that. > > > > > > > > > > On Wed, Apr 28, 2021 at 10:35 PM Frederik Kramer < > > > > > frederik.kramer@initos.com> wrote: > > > > > > Hi Folks, > > > > > > > > > > > > i have a project proposal on my desk that will ultimately end > up > > > > > > in > > > > > > approx. 30 checkout transactions per minute. Has anybody got a > > > > > > project > > > > > > with that order volume done with a relatively recent version of > > > > > > Odoo > > > > > > and provide a good reference. Please bear in mind that the > > > > > > project > > > > > > ahead involves a similarly high volume of stock moves. > > > > > > > > > > > > Any suggestion / comment like (but not limited to) > > > > > > > > > > > > Odoo is the wrong technology for that, forget it, because.... > > > > > > > > > > > > over > > > > > > > > > > > > You can do it but, a), b), c) .... > > > > > > > > > > > > to > > > > > > > > > > > > If you really want that beast flying involve us over here > because > > > > > > we > > > > > > are among the few ones that already did soemthing similar > > > > > > > > > > > > would be appreciated. > > > > > > > > > > > > From our load intensive projects at initOS i know that 10000 > > > > > > orders a > > > > > > day can be handled but almost 50000 is a different story and > > > > > > thats why > > > > > > i am asking the most experienced resource out there ;-) > > > > > > > > > > > > Thanks in advance for your replay > > > > > > > > > > > > Cheers Frederik > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Dr.-Ing. Frederik Kramer > > > > > > Geschäftsführer > > > > > > > > > > > > initOS GmbH > > > > > > An der Eisenbahn 1 > > > > > > 21224 Rosengarten > > > > > > > > > > > > Phone: +49 4105 56156-12 > > > > > > Fax: +49 4105 56156-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: Rosengarten – Klecken > > > > > > Amtsgericht Tostedt, HRB 205226 > > > > > > Steuer-Nr: 15/200/53247 > > > > > > USt-IdNr.: DE815580155 > > > > > > > > > > > > _______________________________________________ > > > > > > Mailing-List: https://odoo-community.org/groups/contributors-15 > > > > > > Post to: mailto:contributors@odoo-community.org > > > > > > Unsubscribe: https://odoo-community.org/groups?unsubscribe > > > > > > > > > > > > > > > -- > > > > > Jordi Ballester Alomar > > > > > CEO & Founder | ForgeFlow > > > > > (+34) 629530707 | jordi.ballester@forgeflow.com | > > > > > https://www.forgeflow.com > > > > > Twitter: https://twitter.com/jordibforgeflow | Linkedin: > > > > > https://www.linkedin.com/in/jordiballesteralomar > > > > > _______________________________________________ > > > > > 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 > An der Eisenbahn 1 > 21224 Rosengarten > > Phone: +49 4105 56156-12 > Fax: +49 4105 56156-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: Rosengarten – Klecken > Amtsgericht Tostedt, HRB 205226 > Steuer-Nr: 15/200/53247 > USt-IdNr.: DE815580155 > > _______________________________________________ > 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 An der Eisenbahn 1 21224 Rosengarten Phone: +49 4105 56156-12 Fax: +49 4105 56156-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: Rosengarten – Klecken Amtsgericht Tostedt, HRB 205226 Steuer-Nr: 15/200/53247 USt-IdNr.: DE815580155
by Frederik Kramer - 12:45 - 29 Apr 2021 -
Re: 30 Checkout Operations per Minute A job for Odoo or not ?
Hi Fred:instead of looking into the amount of orders, I would rather look into the amount of lines per order containing items (excluding the one lines that are just informational), first.This is the key performance measure.If the order line volume is resonable (1-3 on average on an online order), then die 30 to 50 a minute is a hands down job, because, there is no posting involved, just stock reservation. Question still is, what the response time shall be for each order?Also a question would be for your scenario, if those really need to be put as ORDERs, instead of QUOTEs - which are even simpler to consume.If you like we can talk more on your requirements by phone.N.B.In very high volume sceanrios we did, like with some 20000 orders a minute, we usually just consumed, the orders with an message broker first, then preprocessed there, confirmed (if no error), queued and batched in the the ERP for processing (we did this for DHL for all barcode scanners of Deutsche Post service men in Germany, rond trip was supposed to be less than 5 seconds to get confirmation to the barcode scanner).Best JoeVon: "frederik kramer" <frederik.kramer@initos.com>
An: "Odoo Community Association, (OCA) Contributors" <contributors@odoo-community.org>
Gesendet: Donnerstag, 29. April 2021 09:52:11
Betreff: Re: 30 Checkout Operations per Minute A job for Odoo or not ?Hi Joel, hi Jordi, thanks for your valuable answers. For the time being we don't really know about the real scenarios as this is a bolt pitch claim of a VC driven startup for now. But from the business model it seems reasonably realistic for me to ask before claiming something that doesn't hold true if it materialized. I am pretty sure that - given the business model - there will be rush hours. So yes, i could even conceive 50 instead of 30 orders a minute. In similar use cases that you just explained, we have been applying both of the strategies you mention 1.) Decoupling stock moves 2.) Batch processing in off-peak times In the use case at stake both does not really work as the entire transaction from Checkout to Delivery (incl. Picking) is supposed to take less then 10 min incl. pyhsical transport. Nevertheless i think all of that may be doable but, i will certainly not claim "without hassle and much invest". Thanks for your answers Am Donnerstag, den 29.04.2021, 07:32 +0000 schrieb Joël Grand- Guillaume: > Hi Frederik, > > > Yes this is a big number ! Look, first before anything else, how many > lines on average for those orders ? According to my XP, this matters > a lot. > > Second question is: Are there rushing hours and more calm hours ? > > In our XP we could not record more than 10 orders per minute. Was on > V 12 though, so it might have improved a bit by now. In our case, we > had a rush and calm hour. So the jobs could be recorded during rush > hours and processed during calm ones. It worked well, but that was > for not that many numbers... > > An idea would be to decoule the order confirmation from the stock > move generation and do this in two different times. You could ensure > the reservation using our stock allocation module. > > Cannot really help much at this stage, > > Joël > > > On Thu, Apr 29, 2021 at 1:32 AM Jordi Ballester Alomar < > jordi.ballester@forgeflow.com> wrote: > > We have a use case with approx 5000/day. I can see how 50000/day > > can become a hell. Imagine recomputing a field, or migrating > > between versions. > > > > It's a challenge, I give you that. > > > > On Wed, Apr 28, 2021 at 10:35 PM Frederik Kramer < > > frederik.kramer@initos.com> wrote: > > > Hi Folks, > > > > > > i have a project proposal on my desk that will ultimately end up > > > in > > > approx. 30 checkout transactions per minute. Has anybody got a > > > project > > > with that order volume done with a relatively recent version of > > > Odoo > > > and provide a good reference. Please bear in mind that the > > > project > > > ahead involves a similarly high volume of stock moves. > > > > > > Any suggestion / comment like (but not limited to) > > > > > > Odoo is the wrong technology for that, forget it, because.... > > > > > > over > > > > > > You can do it but, a), b), c) .... > > > > > > to > > > > > > If you really want that beast flying involve us over here because > > > we > > > are among the few ones that already did soemthing similar > > > > > > would be appreciated. > > > > > > From our load intensive projects at initOS i know that 10000 > > > orders a > > > day can be handled but almost 50000 is a different story and > > > thats why > > > i am asking the most experienced resource out there ;-) > > > > > > Thanks in advance for your replay > > > > > > Cheers Frederik > > > > > > > > > > > > -- > > > Dr.-Ing. Frederik Kramer > > > Geschäftsführer > > > > > > initOS GmbH > > > An der Eisenbahn 1 > > > 21224 Rosengarten > > > > > > Phone: +49 4105 56156-12 > > > Fax: +49 4105 56156-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: Rosengarten – Klecken > > > Amtsgericht Tostedt, HRB 205226 > > > Steuer-Nr: 15/200/53247 > > > USt-IdNr.: DE815580155 > > > > > > _______________________________________________ > > > Mailing-List: https://odoo-community.org/groups/contributors-15 > > > Post to: mailto:contributors@odoo-community.org > > > Unsubscribe: https://odoo-community.org/groups?unsubscribe > > > > > > -- > > Jordi Ballester Alomar > > CEO & Founder | ForgeFlow > > (+34) 629530707 | jordi.ballester@forgeflow.com | > > https://www.forgeflow.com > > Twitter: https://twitter.com/jordibforgeflow | Linkedin: > > https://www.linkedin.com/in/jordiballesteralomar > > _______________________________________________ > > 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 An der Eisenbahn 1 21224 Rosengarten Phone: +49 4105 56156-12 Fax: +49 4105 56156-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: Rosengarten – Klecken Amtsgericht Tostedt, HRB 205226 Steuer-Nr: 15/200/53247 USt-IdNr.: DE815580155
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Joerg Lorenz. - 12:36 - 29 Apr 2021 -
Re: Special way of searching for products
Hi Radovan,I had a similar problem in my company. I partially solved it by developping some module like https://github.com/grap/grap-odoo-incubator/tree/12.0/multi_search_productBasically, I say to the user to don't enter special char.In your exemple, searching "CD*12345" will return all product containing "CD" and "12345" in any order.Maybe it can help you.Note : the wildcard caracter "*" is a global setting that can be changed.Kind 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. 29 avr. 2021 à 11:32, Graeme Gellatly <gdgellatly@gmail.com> a écrit :Well if you can't use trigram, you need to suffer the performance penalty of using Btree indexes for openended text searches. You could partially mitigate by sanitizing to just lowercase and using a like search rather than ilike but probably only worth it for 25k+ products by the time you massage inputs.But odoo.sh lets you connect via psql, so you can try. pg_trgm is bundled in contrib, same as pg_unaccent so should be there. Just whether you have rights to create extensions.On Thu, Apr 29, 2021 at 9:07 PM Radovan Skolnik <radovan@skolnik.info> wrote:Graeme, thanx for input. This part of your email caught my attention: > Stored computed sanitized code, then sanitize search args on way in. Trigram > index that stored field Stored computed sanitized code - no problem. I can do that and had that in mind. Sanitize search args on way in - you say search for bank accounts shows how to do this? Will check that out. Trigram index that stored field - I am on odoo.sh not sure if that is possible there. However if I am able to sanitize both stored code and input that should generally be enough. I am looking specifcally to work with internal reference (default_code) so no need to handle cases like "Red Cat" or "Cat Red" although it would nice also. Best regards Radovan Skolnik On štvrtok 29. apríla 2021 1:01:59 CEST Graeme Gellatly wrote: > I've done this for years in one way or another. OCA does have trgm module > which allows similarity search but for most use cases I find mostly the > issue is one of order of search terms. Product search is particularly > sucky because it has all sorts of overrides. This is in general my simple > approach. > 1. Install pg_trgm or else you will feel the pain. 2. Override search and > split the name argument into multiple ilikes. In my case I typically split > on spaces, which means users can search "Red Car" or "Car Red" and get same > result. I do it on spaces only. I know you want to avoid but actually for > your use case you are better just copying the way bank accounts are > sanitized and searched. Stored computed sanitized code, then sanitize > search args on way in. Trigram index that stored field On Thu, Apr 29, 2021 > at 9:42 AM Pierre Verkest < pierreverkest84@gmail.com [1] > wrote: Few > ideas based on postgresql: > * not sure if it's possible with SIMILAR TO or ~ operators > * investigate extension * fuzzystrmatch: > https://www.postgresql.org/docs/13/fuzzystrmatch.html [2] * pgtrgm: > https://www.postgresql.org/docs/current/pgtrgm.html#id-1.11.7.40.6 [3] * > create your own unaccent rules: > https://www.postgresql.org/docs/current/unaccent.html [4] regards, > Le mer. 28 avr. 2021 à 22:33, Radovan Skolnik < radovan@skolnik.info [5] > a > écrit : Hello, > I have been asked few times by users if it is possible to search for > products in a way omitting special characters (like dash or space for > exmaple) from product's default_code (or even input string). Let me give an > example: Let's say we have a product with default_code like CD-12345-XYZ In > current situation if user enteres "CD12345" or "CD 12345" nothing is > retrieved. Vice versa, if the default_code is CD12345XYZ and user enters > "CD-12345" or "CD 12345" nothing is retrieved either. So the solution would > be to first remove those special characters from the string being searched > for and then search for default_code transformed with some (SQL?) function. > Is anything like that possible? One idea comes to mind using computed field > where that stripped deault_code would be stored and extending default search > to use this. However that would require stored computed field. Any way to > prevent this? > Thank you. Best regards > Radovan Skolnik > > > _______________________________________________ > Mailing-List: https://odoo-community.org/groups/contributors-15 [6] > Post to: mailto: contributors@odoo-community.org [7] > Unsubscribe: https://odoo-community.org/groups?unsubscribe [8] > > -- > Pierre > > _______________________________________________ > Mailing-List: https://odoo-community.org/groups/contributors-15 [9] > Post to: mailto: contributors@odoo-community.org [10] > Unsubscribe: https://odoo-community.org/groups?unsubscribe [11] > > > _______________________________________________ > Mailing-List: https://odoo-community.org/groups/contributors-15 [12] > Post to: mailto:contributors@odoo-community.org > Unsubscribe: https://odoo-community.org/groups?unsubscribe [13] > > > > [1] mailto:pierreverkest84@gmail.com > [2] https://www.postgresql.org/docs/13/fuzzystrmatch.html > [3] https://www.postgresql.org/docs/current/pgtrgm.html#id-1.11.7.40.6 > [4] https://www.postgresql.org/docs/current/unaccent.html > [5] mailto:radovan@skolnik.info > [6] https://odoo-community.org/groups/contributors-15 > [7] mailto:contributors@odoo-community.org > [8] https://odoo-community.org/groups?unsubscribe > [9] https://odoo-community.org/groups/contributors-15 > [10] mailto:contributors@odoo-community.org > [11] https://odoo-community.org/groups?unsubscribe > [12] https://odoo-community.org/groups/contributors-15 > [13] 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 Sylvain LE GAL - 11:55 - 29 Apr 2021
