Odoo API v17

Prijava

Odoo API v17

Verzija teksta: 0.3
Odoo verzija: General
Status: U izradi
Datum: 14.05.2025.
Pisao: Alberto Poljak
Odjel: E-sustavi
Datum zadnje izmjene: 24.11.2025.
Kontrolirao:

Sadržaj:

Česti upiti za "api dokumentaciju" što u biti ne postoji, kako da objasnim RPC? U ovome tekstu ću pokušati objasniti Odoo API, te njegovu generalnu ideju.

1. Uvod

1.1. Zahtjevi za klijenta

Klijent bi trebao definirati njihov workflow s našim timom za treniranje. Znači workflow koji bi koristili kao krajnji user koristeći Odoo preko browsera, te koje dokumente očekuju da mi primimo preko API-a, i generalno kako trebaju biti spremljeni (koja polja itd.).

Sve što se može preko Odoo-a u browseru, može se i preko API-a + dodatno možemo implementirati stvari koje nedostaju.

Primjeri za neke nama potrebne informacije:

koji dokumenti vam trebaju iz API-a (kontakti, računi, nalozi itd.)
da li kad povučemo te dokumente trebamo napraviti nešto naknadno (npr. potvrditi dokument)
da li će povlačenje tih dokumenata biti one-time deal, ili će se povlačiti svakih sat/svaki dan
da li su dokumenti, jednom kad su povučeni, finalni te da li će ih trebati naknadno ažurirati opet sa API-a
da li komunikacije tih dokumenata ikad ide obrnutno tj. iz Odoo-a prema API-u, npr. ako ažurirate dokument u Odoo-u da se to ažurira i na API-u

Za dodatne upite što se tiče samih mogućnosti Odoo-a morate vidjeti sa našim timom za treniranje i prezentiranje Odoo-a.

1.2. XML-RPC

Odoo interno ima API koji ide preko RPC protokola (XML, JSON ili neki treći format, svejedno je).

RPC tj. remote procedure call, vam u biti omogućava identično baratanje internim metodama kao da ih pozivate iz Odoo modula. Znači RPC poziva te interne metode isto kao i Odoo.

U prijevodu, bilo koji interface koji vidite na Odoo web browseru: button, akcija, itd... sve to interno poziva neku metodu. Tu istu metodu možete pozvati preko RPC-a.

Što se tiče formata, možete koristiti standardni XML-RPC ili JSON-RPC, jedina razlika je da payload šaljete ili kao XML, ili kao JSON. U oba slučaja specificirate i zovete X metodu sa Y argumentima.

1.3. Službena dokumentacija

Službena dokumentacija postoji samo za spajanje i generalno baratanje RPC-om https://www.odoo.com/documentation/17.0/developer/reference/external_api.html

Za konkretne primjere ne postoji, razlog zašto ne postoji je jer je nemoguće. Odoo ima mali milijun modula, sa svojih milijun modela, svaki sa svojih milijun metoda, svaka sa svojim argumentima. S tim da custom moduli i dodatna customizacija može dodatno donijeti još više modela i metoda. Da ne spominjemo različite Odoo verzije.

Znači službeni primjeri za nešto konkretno ne postoje, npr. potvrdi ponudu, primi količine u primci, pa kreiraj i potvrdi račun. Za takve stvari treba netko tko barata internim Odoo metodama i njihovim argumentima. Tu onda ulazimo mi, gdje za svaki vaš zahtjev možemo složiti neki workflow. Za većinu stvari će biti dovoljno koristiti postojeće interne metode, te samo znati kako se one zovu i koje argumente primaju. Naravno, ako neka metoda ne postoji ili ne odgovara, mi onda možemo dodati custom metodu, i dodatne argumente.

1.4. Upiti za drugi protokol, npr. REST

Moguće, no nije preporučeno. Razlozi:

1. Nije implementirano u Odoo-u

Mi bi s naše strane trebali donijeti modul za ovo, custom moduli postoje, ali nisu standardni Odoo te nisu nužno stabilni i trebalo bi ih istestirati.

2. Dupliciranje

Custom modul za REST bi nam dao samo tehničku osnovu da se REST napravi. Mi bi još uvijek morali svaki endpoint postavljati, dokumentirati, testirati, i mijenjati za svaki novi zahtjev. Mislili bi da su REST endponti koliko toliko fiksni jednom kad se naprave, ali ne zaboravite da Odoo može imati 1000 polja u dokumentu, i onda se kasnije sjetite da bi možda to neko dodatno polje bilo dobro koristiti. Vi u payloadu lako ubacite novo polje, dok mi s naše strane moramo mijenjati endpoint i opet testirati.

Najgore je to što bi mi u našem endpointu interno zvali isto kao što bi vi zvali RPC metode, tako da bi nam REST bio samo dodatak na već postojeći RPC, tako samo dupliciramo postojeće za svaku stvar što treba. REST bi nam doslovno bio samo wrapper za RPC.

3. Praksa

Imali smo klijenta koji je, unatoč našoj preporuci, inzistirao na REST-u. To su u početku bile sve neke sitnice, i bilo je održivo, no vrlo brzo su počeli experimentirati te kad su uvidjeli da bi za svaku sitnicu trebalo implementirati REST endpoint (a RPC već postoji) prešli su na XML-RPC.

2. Osnovni tehnički interface

Za konkretan primjer payloada bilo bi dobro biti upoznat sa debug modom, što on predstavlja, te kako ga uključiti. Konkretni primjeri payloada će imati više smisla kad se upoznate s njim i konkretno vidite da browser interface Odoo-a interno koristi iste stvari kao i RPC.

2.1. Uključivanje debug moda

Debug mode vam omogućava da vidite informacije o tehničkim stvarima kao nazive metoda, nazive polja itd. Ti nazivi se onda šalju preko RPC calla.

1. Možete ručno uključiti tako da dodate ?debug=1 u URL:

http://odoo.url/web?debug=1

2. Drugi način je da otvorite postavke, te pri dnu kliknuti da se aktivira debug mode

2.2. Korištenje debug moda

Nakon što je debug mode uključen, kad hoveramo mišem preko nekog polja, dobit ćemo njegove tehničke informacije:

U ovom slučaju, za polje "Customer" na računu, to polje se zove "partner_id", tipa je "many2one", te je na modelu "account.move", tako će se i koristiti u paylodima. Za polja su većinom samo te tri informacije bitne.

Dodatni primjer, je recimo ako hoveramo preko nekog buttona:

U ovom slučaju button za potvrdu računa interno zove metodu "action_post".

2.3. Defaultne vrijednosti kod kreiranja dokumenta

Kod slanja payloada neka polja su obavezna, ali ih se ne mora slati. Ako ih se ne pošalje, Odoo im može dodijeliti neku defaultnu vrijednost. Ako Odoo to ne radi, a ta polja se ne pošalju, onda ćete očekivano dobiti error jer je polje potrebno.

Kako znati koja polja Odoo postavi na defaultnu vrijednost, i na koju vrijednost? Najlakše je kreirati taj dokument preko browsera, u novoj formi, koja još nije spremljena, možemo vidjeti sva polja koja su već automatski postavljena. Primjer kreiranja novog proizvoda:

Vidimo da je brdo polja postavljeno, npr. Product Category (categ_id) je postavljeno na defaultnu "All" vrijednost. Taj "All" je početna kategorija koja se kreira kod instalacije Odoo-a. Naravno ta polja mi možemo specificirati, u ovom primjeru u payloadu možemo poslati specifičan "categ_id", ali ako ne pošaljemo, on će imati kategoriju "All".

3. Slanje payloada

Svi primjeri su pisani u Python-u (pseudokod, razumljiv za bilo koji jezik).

3.1. Autentifikacija

Primjer ima u službenoj dokumentaciji. Ima link iznad.

Konretan primjer:

import xmlrpc.client

url, db = "http://odoo.url", "naziv_baze"
username, password = "admin", "sifra"

models = xmlrpc.client.ServerProxy('{}/xmlrpc/2/object'.format(url))
common = xmlrpc.client.ServerProxy('{}/xmlrpc/2/common'.format(url))
uid = common.authenticate(db, username, password, {})

Endpoint /xmlrpc/2/common se koristi za dobivanje ID usera, te ujedno i za provjeru autentifikacije.

Endpoint /xmlrpc/2/object se koristi za daljnje RPC pozive i baratanje metodama/modelima.

3.2. Paylod argumenti

Osim autentifikacije, za slanje payloda potrebno je znati ove osnovne informacije:

naziv modela: Model predstavlja Odoo dokument. Npr. u gornjim slikama, kod debuga, imamo dokument za račun, a on je interno u Odoo-u model s nazivom "account.move".
naziv metode: Interna metoda koja se poziva, npr. u gornjim slikama, kod debuga, da bi potvrdili račun moramo pozvati metodu "action_post".
(opcionalno) argumenti za metodu: Ako metoda ima argumente, i njih je potrebno poslati.
Interni database ID Odoo dokumenta: Npr. ako u Odoo imamo 10 računa, i deseti ima interni ID 10, onda možemo poslati ID 10 da bi baratali s tim specifičnim dokumentom. Moguće je poslati i više ID-ova odjednom.

3.3. Tipovi polja

Većina polja su straight-forward i nisu problem kod slanja payloada, npr. integer, float, char itd.

No, potrebno je dodatno objašnjenje za relacijska polja: many2one, one2many i many2many

Ova objašnjenja su tu čisto za bolje razumijevanje, u praksi ćemo mi slati konretne primjere payloada za takve zahtjeve, jer većinom je potrebno interno znanje Odoo-a.

3.3.1. many2one

Ovo polje je obično integer polje, ali predstavlja relaciju na neki drugi dokument. Npr. kod kreiranja kontakta, ako želimo poslati državu tog partnera, moramo poslati "country_id" što je u biti relacija na "res.country" model.

Listu država možemo vidjeti u Kontakti/Konfiguracija/Države

Svaka država je svoj dokument, i ima svoj interni ID npr. Hrvatska ima ID 97.

3.3.2. one2many

Ovaj tip polja i ja Googlam svaki put: https://stackoverflow.com/a/26012940

Često se koristi kod stavaka/liste na samom dokumentu npr. kod računa imamo linije računa, te linije su one2many poveznica na sam račun.

(0, 0, { values }) link to a new record that needs to be created with the given values dictionary

(1, ID, { values }) update the linked record with id = ID (write *values* on it)

(2, ID) remove and delete the linked record with id = ID (calls unlink on ID, that will delete the object completely, and the link to it as well)

Example:

[(0, 0, {'field_name':field_value_record1, ...}), (0, 0, {'field_name':field_value_record2, ...})]

Primjer korištenja kod kreiranja računa i postavljanja njegovih linija računa (invoice_line_ids):

created_move_id = models.execute_kw(db, uid, password, "account.move", "create", [{
    "ref": "12345" ,
    "invoice_date": "2025-01-01",
    "invoice_date_due": "2025-01-01",
    "journal_id": 10,
    "partner_id": 13,
    "currency_id": 2,
    "invoice_line_ids": [
        (0, 0, {"quantity": 1, "price_unit": 9.99, "product_id": 4556}),
        (0, 0, {"quantity": 5, "price_unit": 4.99, "product_id": 4521}),

    ]
}])

3.3.3. many2many

Ovaj tip polja i ja Googlam svaki put: https://stackoverflow.com/a/26012940

Rijetko se koristi, većinom se koristi one2many.

(0, 0, { values }) link to a new record that needs to be created with the given values dictionary

(1, ID, { values }) update the linked record with id = ID (write *values* on it)

(2, ID) remove and delete the linked record with id = ID (calls unlink on ID, that will delete the object completely, and the link to it as well)

(3, ID) cut the link to the linked record with id = ID (delete the relationship between the two objects but does not delete the target object itself)

(4, ID) link to existing record with id = ID (adds a relationship)

(5) unlink all (like using (3,ID) for all linked records)

(6, 0, [IDs]) replace the list of linked IDs (like using (5) then (4,ID) for each ID in the list of IDs)

Example:

[(6, 0, [8, 5, 6, 4])] sets the many2many to ids [8, 5, 6, 4]

3.4. Osnovne CRUD metode (akcije) za sve dokumente

Odoo interno ima par "glavnih" metoda: create, write, read, unlink, search.

One su u biti mapiranje standardnih CRUD metoda.

One su na svim modelima, primjeri za korištenje ovih osnovnih metoda su u službenoj Odoo dokumentaciji , koja je navedena iznad.

Konkretan primjer za kreiranje kontakta:

created_id = models.execute_kw(db, uid, password, "res.partner", "create", [{

"name": "Test partner",

"street": "Ulica123",

"zip": "10000",

"city": "Zagreb",

}])

print(created_id)

Rezultat printa ID novog kontakt dokument u Odoo-u.

3.5. Specifične metode (akcije) za dokumente

Ove metode se nalaze u određenim modelima, npr. metoda za potvrđivanje računa "action_post" postoji samo u tom modelu "account.move" koji predstavlja taj račun.

3.5.1. Računi (account.move)

-----> Potvrda računa

models.execute_kw(db, uid, password, "account.move", "action_post", [[10]])

U ovom primjeru bi na modelu "account.move" (koji predstavlja račun) pozvali metodu "action_post" ( koja potvrđuje račun te je identična kao stiskanje buttona Potvrdi preko browsera), na računu koji ima ID 10.

3.5.2. Proizvodi (product.template)

Note: cijeli ovaj section ne uključuju varijante proizvoda, to je specifičan feature Odoo-a koji se može naknadno uključiti, po defaultu nije uključen. One zahtjevaju naprednije primjere i dodatna objašnjenja, ako ih nemate ignorirajte ovaj note, ako imate morate se dodatno konzultirati sa našim tehničkim timom. Imajte na umu da "prelazak" na varijante "kasnije" će zahtjevati dodatni development, tako da to je bitno znati u početku. Konzultirajte se s vašim klijentom i našim timom za treniranje.

-----> Kreiranje proizvoda

Osnovno polje za kreiranje proizvoda je "name", druga polja su isto potrebna, ali ako nisu navedena Odoo im dodijeli neku defaultnu vrijednost (npr. kategoriju itd). Za defaultna polja pogledajte sekciju 2.3.

template_id = models.execute_kw(db, uid, password, "product.template", "create", [{
    "name": "Test proizvod",
}])

print("Kreiran proizvod", template_id)

-----> Mijenjanje prodajne cijene proizoda

Prodajna cijena se koristi kao jedinična cijena tog proizvoda na prodajnom nalogu u Odoo-u.

template_id = 230338
models.execute_kw(db, uid, password, "product.template", "write", [template_id, {
    "list_price": 19.99,
}])

Primjer slika:

Stavljanje tog proizvoda u dokument prodaje on će preuzeti tu cijenu:

-----> Mijenjanje troška proizoda

Trošak proizvoda je malo naprednija cijena. Bilo bi dobro hoverati preko upitnika u debug-u i pročitati opis:

Ovo s vaše tehničke strane bi bilo dobro da se konzultirate s vašim klijentom koji će koristiti Odoo (te po potrebi s našim timom za treniranje), da znate kako će oni uopće tu cijenu koristiti, jer ima više načina. Konretno ima 3 načina, i oni ovise o polju "Metoda troška" u kategoriji proizvoda:

Ako je uobičajena cijena, tj. fixed price, onda je sigurno ovo mijenjati. Ako je metoda neka druga (FIFO, prosječna) onda se obavezno konzultirati s klijentom koji koristi Odoo, i za našim timom za treniranje, da vidite da li uopće smijete mijenjati cijenu i u kojim slučajevima.

Primjer koda:

template_id = 230338
models.execute_kw(db, uid, password, "product.template", "write", [template_id, {
    "standard_price": 9.99,
}])

Primjer slika:

3.5.3. Količine proizvoda

Količine tj. stanja proizvoda koji su skladištivi se u Odoo-u mogu mijenjati na 2 načina:

1) preko inventure

2) preko ulaza/izlaza tj. primke/otpremnice

-----> Dohvaćanje količine proizvoda

Polje za "On hand" količinu je qty_available.

Primjer:

data = models.execute_kw(db, uid, password, "product.template", "read", [230338], {"fields": ["qty_available"]})

Return:

[{'id': 230338, 'qty_available': 5.0}]

Znači imamo 5 komada tog proizvoda na fizičkoj zalihi.

Note: ovo vrijedi za proizvode koji su skladištvi, u drugim slučajevim je return očekivano uvijek 0 (npr. u slučaju proizvoda tipa usluga).

-----> Mijenjanje količine proizvoda preko inventure

Ovaj način se koristi kada vam treba početno stanje.

Menu preko browsera je Inventory/Operations/Physical inventory

Pošto je ovo one-time deal, preporučeno je ovo napraviti jednostavno preko uvoza XML-a, te onda potvrditi linije ručno preko browsera, nije potrebno komplicirati s API-om.

-----> Mijenjanje količine proizvoda preko ulaza/izlaza

Svi dokumenti (primka, otpremnica, interno itd) idu preko istog dokumenta stock.picking, samo im se polja razlikuju. Note: primjeri za otpremnicu i interni transfer su identični, samo su lokacije i picking type drugačiji. Npr. u slučaju otpremnice lokacije će biti obrnute, te će picking_type_id biti 2 (Delivery Orders).

-----> Primjer za primku

Kreiranje primke:

picking_id = models.execute_kw(db, uid, password, "stock.picking", "create", [{
    "picking_type_id": 1,
    "location_id": 4,
    "location_dest_id": 8,
    "scheduled_date": "2025-06-18",
    "partner_id": 5,
    "move_ids_without_package": [
        (0, 0, {
            "name": "Test1",
            "product_id": 231546,
            "product_uom_qty": 10,
            "picking_type_id": 1,
            "location_id": 4,
            "location_dest_id": 8,
            "date": "2025-06-18",
            "partner_id": 5,
        }),
    (0, 0, {
            "name": "Test2",
            "product_id": 231545,
            "product_uom_qty": 10,
            "picking_type_id": 1,
            "location_id": 4,
            "location_dest_id": 8,
            "date": "2025-06-18",
            "partner_id": 5,
        })
    ],
}])

Objašnjenje polja:

-----> picking_type_id

ID za tip operacije, može se naći u menu Inventory/Configuration/Operation Types

U vašem slučaju vaša defaultna operacija za primke je "Receipts" i ona ima ID 1 (vidljivo u URL-u):

Ostale operacije su (slika ispod): Internal Transfers (ID 5) te Delivery Orders (ID 2)

-----> location_id

Izvorna lokacija. Vidljiva u menu Inventory/Configuration/Locations

Ona ovisi o tipu:

primke: Koristimo lokaciju "Partners/Vendors" koja trenutno ima ID 4

otpremnice: Šaljemo nešto od nas, tako da izvorna lokacija mora biti interna lokacija, u našem slučaju defaultna je WH/Stock (ID 8), slika:

interni transfer: interna lokacija, defaultna isto kao slika iznad, WH/Stock (ID 8)

-----> location_dest_id

lokacija destinacije. Vidljiva u menu Inventory/Configuration/Locations

Ona ovisi o tipu:

primke: zaprimamo sami sebi, tako da destinacija treba biti interna lokacija. U našem slučaju defaultna je WH/Stock (ID 8)

otpremnice: Koristimo lokaciju "Partners/Customers" koja trenutno ima ID 5

interni transfer: interna lokacija, defaultna WH/Stock (ID 8)

3.5.4. Transferi (ulazi/izlazi tj. primke/otpremnice)

-----> Potvrda transfera (primke/otpremnice)

1) Prvo pozovemo metodu za button "Mark as Todo"

models.execute_kw(db, uid, password, "stock.picking", "action_confirm", [[picking_id]])

Ovo prebaci status iz draft u ready, te po potrebi rezervira količinu, ali još uvijek nema nikakvog prijenosa i ne utječe na stvarne količine.

U browser interface-u možemo vizualno vidjeti da li nešto nedostaje (količina linije crvena).

2) Nakon toga pozovemo metodu za button "Validate"

models.execute_kw(db, uid, password, "stock.picking", "button_validate", [[picking_id]])

Ovo prebaci status iz ready u done, i zapravo utječe na stvarne količine. Transfer je obavljen.

Note: tek u ovom trenutku se "generira" efektivan datum, tj. datum transfera (primke/otpremnice itd). Ako želite nešto zaprimiti u "prošlosti" morate se obratiti našem tehničkom timu.

Note: ova metoda vam može baciti error, ovisno kako vam je workflow postavljen. Npr. ako nema dovoljno količine za transfer (npr. otpremamo 5, a imamo 2). Ovo se može riješiti workflowom da u slučaju nedostatka da se roba automatski replenisha ili narudžbom ili nečim drugim - javite se našem timu za obuku.

3.5.5. Prodaja

-----> Kreiranje ponude

Osnovni poziv za kreiranje dokumenta:

models.execute_kw(db, uid, password, "sale.order", "create", [...polja...])

Primjeri za polja (* znači obavezno i da se mora postaviti):

*partner_id - integer predstavlja ID Odoo kontakta (res.partner).

currency_id - integer predstavlja ID Odoo valute (res.currency). Po defaultu uzima vrijednost zadanu u tvrtki, i većinom je euro.

client_order_ref - string, referenca kupca.

date_order - naivni datetime (UTC-0), datum ponude. Defaultna vrijednost mu je trenutno vrijeme.

fiscal_position_id - integer predstavlja ID Odoo fiskalne pozicije (account.fiscal.position). Ako nije poslano Odoo postavi po svojim pravilima.

partner_shipping_id - integer predstavlja ID Odoo kontakta (res.partner). Slično kao partner_id, samo za adresu dostave. U Odoo su sve adrese u biti kontakti, uključujući adresu dostave. računa itd. Po defaultu uzima adresu dostave koja je postavljena u partner_id, ako taj kontakt nema postavljenu adresu dostave onda bude ista vrijednost kao partner_id.

partner_invoice_id - identično kao partner_shipping_id samo za adresu računa

pricelist_id - integer predstavlja ID Odoo cjenika (product.pricelist). Ako nije poslano Odoo postavi defaultni cjenik.

Stavke ponude se šalju kao lista, svaka stavka ima svoja polja.

order_line - ovo su linije ponude. To je lista za svaku stavku, svaka stavka može imati sljedeća polja:

*auto_product_template_id - integer predstavlja ID Odoo proizvoda (product.???)

product_uom - integer predstavlja ID Odoo jedinice mjere (uom.uom). Ako nije poslano, Odoo automatski povuče postavljenu jedinicu mjere iz proizvoda.

product_uom_qty - float količina proizvoda, u jedinici mjere koja je postavljena za ovu liniju. Preciznost iste ovisi o Odoo sistemskom parametru za preciznost jedinica mjera (po defaultu je 2).

price_unit - float jedinična cijena. Ako nije poslano Odoo uzima defaultu vrijednost iz proizvoda. U valuti koja je postavljena u nalogu. Preciznost iste ovisi o preciznosti valute (po defaultu je uvijek 2).

discount - float popust, od 0-100

tax_id - many2many poveznica na Odoo poreze (account.tax). Ako nije poslano Odoo postavi po svojim pravilima za proizvod/tvrtku/fiskalnu poziciju. Možemo postaviti više poreza odjednom. Ako je ovo poslano, a porezi su prazni, onda na liniji neće biti poreza.

Za primjer payloada ćemo poslati više linija, prva linija je ništa posebno, druga linija je primjer decimala i popusta, treća linija je primjer samo osnovnog polja (ostala Odoo popuni), četvrta je primjer deklariranja specifičnih poreza , u ovom slučaju "PPDV 13% na Predujam" (ID 16) te "13% PDV Dobra" (ID 7).

Primjer payloada:

created_sale_id = models.execute_kw(db, uid, password, "sale.order", "create", [{
    "partner_id": 95297,
    "date_order": "2025-11-24",
    "client_order_ref": "Test API",
    "order_line": [
        (0, 0, {"auto_product_id_by_product_tmpl_id": 233350, "product_uom_qty": 10, "price_unit": 100}),
        (0, 0, {'auto_product_id_by_product_tmpl_id': 227104, "product_uom_qty": 3, "price_unit": 9.87, "discount": 20}),
        (0, 0, {'auto_product_id_by_product_tmpl_id': 226322}),
        (0, 0, {"auto_product_id_by_product_tmpl_id": 226583, "tax_id": [(6, 0, [16, 7])]}),
    ]
}])

Slika generirane ponude:

-----> Kreiranje prodajnog naloga

U Odoo-u, prodajni nalog dolazi od ponude, u trenutku kad se ona potvrdi. To je u biti isti dokument, samo ima drugi status. Prije potvrde ponude ona će imati status "Ponuda" (draft), nakon potvrde imati će status "Prodajni nalog" (sale).

Primjer potvrde ponude:

models.execute_kw(db, uid, password, "sale.order", "action_confirm", [[sale_order_id]])

4. Optimatizacija RPC komunikacije

Skoro pa svaka metoda podržava više recordseta (dokumenata) odjednom. Primjer npr. za slanje 1000 kontakta u jednom pozivu:

models.execute_kw(db, uid, password, "res.partner", "create", [{"name": "Test1"}, {"name": "Test2"}, ..., {"name": "Test1000"}])

Ovo je jedan API call, koji u payloadu ima 1000 dokumentata. Nema overhead-a.

Naravno možete ići i metodom slanja jedan po jedan:

models.execute_kw(db, uid, password, "res.partner", "create", [{"name": "Test1"}])
models.execute_kw(db, uid, password, "res.partner", "create", [{"name": "Test2"}])
...
models.execute_kw(db, uid, password, "res.partner", "create", [{"name": "Test1000"}])

Ovo je 1000 odvojenih API callova, svaki sa svojim malim overhead-om, koji kad se zbroje možda hoće, a možda i neće toliko utjecati na ukupno vrijeme . Ako još dođete na ideju da ovo stavite u thread-ove da vam bude "brže" pa bubnete to sve instanto... to je doslovno mini DDOS, nemojte to raditi (navodim jer se je to dogodilo).

Vi radite metodom koja vam je lakša, oke je slati jedan po jedan poziv, sve dok ste svjesni da postoji opcija da pošaljete to sve odjednom. Obje metode imaju prednosti i nedostatke.

Slanje jednog API poziva sa 1000 dokumenata:

Prednosti:

nema overhead-a, ubrza se proces koliko toliko.

Nedostatci:

veća mogućnost time-outa i hanga sa strane Odoo-a.

Slanje 1000 API poziva (sekvencijalno!) svaki sa 1 dokumentom:

Prednosti:

potecijalno lakše s vaše strane, šaljete ono što trenutno imate, ne morate konstruirati veći payload sa svim dokumentima
manja mogućnost time-outa i hanga sa strane Odoo-a.

Nedostatci:

određeni overhead kod slanja odvojenih poziva

Notes:

time-out: Npr. ako se šalju neki kompleksniji dokumenti, tipa računi, pa Odoo tu svašta nešto interno računa i postavlja, moguće je da će taj jedan call koji kreira X računa odjednom time-outati ili baciti error (hangati). Ovo se dogodi jer Odoo interno ima limit koliko proces može trajati, te koliko može progutati memorije itd. U tom slučaju jednostavno se smanji broj dokumenata u jednom callu. Ovo će biti problem samo za naprednije dokumente, no u praksi nisam imao problema sa slanjem par tisuća dokumenata odjednom, problemi se tek počnu pojavljivati nakon 2k-3k, tako da je za većinu slučajeva oke slati 1000 odjednom.
rollback u slučaju errora: svaki RPC call će u slučaju bilo kakvog erorra biti rollback-an, tj. ništa neće biti commitano, efektivno neće imati nikakav utjecaj na sustav i bazu. Znači svaki RPC call je u svojoj transakciji. Ovo ujedno može biti i prednost i nedostatak.

5. Referenca Odoo dokumenata

U ovom dijelu ću povezati Odoo tehničke nazive dokumenata sa slikama istih u web browseru, tako da znate gdje i kako doći do njih. Ovo služi kao pomoćna referenca za integratora koji čita ove upute.