Open yoyo2k opened 9 years ago
Parerea mea e ca ar trebui sa facem 3 module separate: Unul pentru contracte, unul pentru concedii, si payroll sa depinda de ele...primele 2 contin destul de multe informatii si daca o sa le punem in acelasi modul, o sa iasa un monstru care va fi mai greu de adaptat...
concedii: trebuie adaptata ideea de concediu medical destul de simplu, calculele eu le-as face din reguli singura problema care am gasit-o aici e problema cu alocarea care cred ca e generalizata in odoo 8. contracte: nu prea vad ce s-ar face aici.. da sunt 3-4 tipuri de contracte (cm, drepturi de autor, etc) dar astea se rezolva din reguli si contract_type exista ramane payroll...
Sunt doar 3-4 tipuri de contracte...dar vezi ca in contract se pot modifica multe prin act aditional...si de aceea imi mentin parerea ca sa le facem separat...daca ii schimbi incadrarea, se poate schimba pe langa salar, norma, conditii speciale, cate ore, programul de lucru...cel putin pentru contracte pentru asta as face un modul separat..conceptul de act aditional, contractul sa isi preia daca are acte aditionale ultimele informatii cu privire la modificari, daca nu are sa ia din campurile deja completate in contract.
La concedii, e destul de greu sa socotersti din reguli cand tu nu ai istoricul persoanei, la medicale..acolo trebuie sa ai separat daca a lucrat ultimele 6 luni la alt angajator un model care sa iti permit sa introduci acest lucru...si din reguli e destul de greu sa stai sa socotesti nr zile, cate a lucrat, sarbatori, sa faci media pe zi...
pai poti sa ai n contracte.. def _get_latest_contract... deci nu vad problema, ultimu e baza
la concedii, fix la asta ma gandeam.. model pentru istoric e perfect
Ok...faci functie...dar nu mi se pare ok...ca pentru fiecare act aditional sa faci alt contract cu acelasi numar...aceeasi persoana...
nu e acelasi numar.. e numarul actului aditional.. dai duplicate, schimbi numarul cu numarul actului aditional, si modifici ce e necesar.
Mie mi se pare ca va fi mai greu de revizuit decat a face un one2many catre un nou table de acte aditionale care sa iti permita sa schimbi campurile de mai sus...
Mai mult ca sunt 2 documente diferite care trebuie inregistrate la ITM...
da si nu. in alte module odoo, cum se rezolva cu aditionalele? exista relatia copil-parinte pt contracte? la itm depui tot oricum..
Nu prea ai concept de aditional...daca stai sa te gandesti...dar dupa mine e mai intuitiv sa ai tabel separat...daca faci un sondaj pe cei care lucreaza in hr cred ca toti o sa-ti spuna la fel...vor sa vada exact ce s-a modificat in actul aditional decat sa vada un contract nou si nu mai stii ce s-a modificat...
ok. atunci la contract sa se adauge un parent_id si la print se rezolva.. sau adugam la notes. oricum, pana acum nu s-a lovit nicio tara de problema asta..
au in vedere implementarea unei astfel de relatii in 9?
Nu stiu...ce a fost deocamdata a fost doar Accounting Roadmap care in 9 desi au fost multe spuse si scrise in documentele contabile si rapoarte, nu stiu cat s-a facut pana acuma si cat timp mai au la dispozitie...oricum si in V9 cred ca multe din facilitatile care sunt facute si le facem in continuare toti, trebuie adaptate...chiar daca o sa fie cash accouting, poate evaluari in valuta, rapoarte mai usor de configurat, tot timpul vor implementa lucruri generale (sau specifice tarilor din Vest)..la legislatia noastra oricum trebuie sa adaptam mult...
atunci putem implementa ceva din ce am sugerat mai sus.
Sa vedem ce zic si ceilalti, nu? @dhongu @filsys @mcojocaru @alexteodor @atta-t
Eu-s de principiu kiss. Dacă odoo nu implementează principiul ăsta pt niciun soi de contract şi cred că se poate face şi fără el, atunci să-i dăm drumul aşa.
Asteptăm păreri
Salutare,
Nu am vrut sa ma bag, ca nu am timp sa contribui, si am stat in banca mea. Dar cred ca pot spune ceva aici, am petrecut ceva timp in HR... un act aditional e o modificare adusa unui contract, dar care NU se include in textul contractului, ci sta la dosar separat. Bineinteles ca ar fi mai usor de citit un dosar cu textul adus la zi, dar nu are valoare juridica. sper sa fi fost la subiect. nu m/am uitat la module, dar eu as face AA un tip de contract (gen contract_type) ca sa fie KISS. poate cu un modul pt a genera textul.
SA va spun cam ce trebuie sa fie intr-un sistem HR serios, la nivelul asta. un angajat poate avea unul sau mai multe contracte, depinde cate societati gestioneaza hr. istoricul de contracte si acte aditionale e necesar. ele definesc si modifica conditiile de incadrare. in general, AA este nr x din data de, adus contractului nr y din data de. exista o relatie de parent_id. un contract poate avea o durata, poate fi inlocuit de un nou contract, daca prea multi parametrii principali se schimba. dar in majoritatea cazurilor un aa e suficient. nu si daca se schimba partenerul angajator, de ex daca isi schimba numele. mai sunt poate si alte cazuri, nu imi vin acum.
sper sa va fi dat cateva idei.
sunt absolut de acord cu Mihai, nici nu inteleg de ce nu va bazati pe structurile existente, hr_payroll, contracts, holidays etc. reinventatul rotii costa scump in general. azi sunt 50 de linii, dar cand o sa fie 500 o sa fie mai greu de descalcit, si de adaptat la versiunea urmatoare..
bye, b
2015-02-02 19:25 GMT+01:00 Adrian Vasile notifications@github.com:
Eu-s de principiu kiss. Dacă odoo nu implementează principiul ăsta pt niciun soi de contract şi cred că se poate face şi fără el, atunci să-i dăm drumul aşa.
Asteptăm păreri
— Reply to this email directly or view it on GitHub https://github.com/odoo-romania/l10n-romania/issues/52#issuecomment-72509497 .
Bogdan Stanciu
Multumesc de explicații. Asta explică multe. În odoo, contractele nu reprezintă fiecare act cu cumulul de obligații din contrapartea de pe hârtie ( contract + adiționale ).
Mihai vrea să modificăm, eu nu prea.
Eu as vrea sa le modificam ca sa fie mai evident ce s-a modificat si sa ai un istoric pe fiecare contract...vezi ca in data de s-a modificat orar..sau salar...cu duplicate e greu de urmarit ce campuri se modifica...sa pui in note nu stii niciodata ce il apuca pe cineva si sterge nota...si apoi trebuie sa le iei la rand si sa faci comparatii...
Înteleg ce vrei,dar nu mai bine facem acum asa şi punem refactoring pentru v9?
Ok...hai sa il facem asa acuma...
Întrebare. Cum s-ar putea în qweb să îmi arate doar n opţiuni din m pt un câmp selection?
Nu există o variantă prin modificarea contextului pentru câmpul respectiv? Cum setezi employee_id de ex.
in one2many?
contextul il poti modifica din view...daca ai one2many,m2o: <field name="xx" context="{'employee_id':active_id} daca modelul este hr.employee
daca esti in model si ai employee_id in view <field name="xx" context="{'employee_id':employee_id}
din metode faci context.copy si in new api ii dai with_context(ctx_copy)...
E selection
Zi-mi exact ce vrei sa faci...deci pe baza a unui camp sa sortezi lista din selection?
Din 3 opţiuni vreau să apară 2.
Sincer nu stiu sigur daca merge din fields_view_get, sa iei context si sa filtrezi optiunile in functie de el (cel putin pentru selection)...pt relationate m20, o2m merge...
https://www.odoo.com/forum/help-1/question/domain-in-hardcoded-selection-field-21767
Mai arunca cineva un ochi peste?
Ce fel de indemnizatii? Eu zic ca le putem include in avantaje...un tip in avantaje care e procent sau suma...iar in payrol testam daca e procent inmultim sau adunam. Nu stiu daca am timp in weekend daca nu luni dimineata putem vb si sa stam sa configuram o atructura de salar...
De res.company.payroll nu cred ca ai nevoie...doar un istoric pe salar, minim si mediu...pt taxe putem defini un plan de taxe specifice pt payroll...in account tax...iar in hr_payroll_account poti configura conturi si taxa pe fiecare hr.salary.rule...
Asta era ideea cu avantajele. Întrebarea era unde intră în calcul.
Nu prea are sens testarea dacă e procent decât dacă stii din start cui i se aplică.
Este foarte bine dacă putem seta în account taxes. Trebuie să vedem cum se aplică taxa pe regulă.
În weekend nu prea am timp (copii) iar in timpul săptămânii, dimineata, e la fel. Doar pauze de tigareta şi "telefonul inteligent"
PS: poate putem folosi o combinație între registrul şi analitice pentru generarea d112. Doar o idee.
La contracte alea erau sporuri permanente sau retineri garantii...la calcul ore suplimentare (din hr.attendance)...noapte...weekend adaugam pozitii extra in payroll...plus avantajele, daca bine tin minte...plus din holidays ce concedii a avut si nr zile si suma pe zi luata din holiday...vedem daca nu cand poti...luni mai pe dupa masa...marti...sa vedem ce mai putem adauga...
Mai 112 trebuie sa te bazezi pe multe la generare...de aia am facut initial medical.holidays ca ai nevoie de multe info pentru calcul si declaratii...plus daca e initial sau nu...dar pove pe luni marti...
Apropo de rețineri (de ex popririle). Cred c-ar trebui evidenţiate separat in modulul hr. Trebuie să fie trecute şi într-un analitic separat.
Există reţineri fără executor judecătoresc?
D-asta vreau să las la final declaratiile să vedem ce avem şi de ce mai e nevoie.
Retineri pot fi si de tip garantie....pentru cei ce au gestiune asupra lor: ex. Sef depozit, gestionar, soferi...cu decizie interna se retine garantie, iar la sfarsitul xontractului sau inventare/accidente se pot inchide...astea pot fi fara executor...avantajele pot fi si cu minus...de executor salariul se calculeaza normal...e creditat contul bancar in care se vireaza banii....sau cash retinuti de firma...
Popririle se fac dupa calcul salar...deci trebuie evidentiate manual daca e cash si retinut de firma din net....putem tot asa avea un input.RET care sa il scadem din net in reguli salar...
Eu am luat-o un pic invers...am luat 112 sa vad acolo ce date trebuie ca sa le am pe toate...
Toate reținerile astea (popriri, executor judecătoresc) nu trebuie să apară pe stat separat? Poprirea1, poprirea2, etc.
Altă întrebare. Dacă tot facem localizarea pt românia, de ce nu scriem în română direct?
Normal, dar vreau să văd câte date poate odoo să dea fără customizare în exces. Să avem o amprentă cât mai mică.
Mă gândesc că putem folosi partea de analitic din odoo pt declarații
De obicei analiticele te ajuta in buget...pt 112 odata ce ai statul de plata si concedii medicale, poti din regulile salar sa iei efectiv toate contributiile...si pe companie si pe salariat...
Mă gândeam că putem evita if xx.C1...C14 ca să nu se încarce regulile prea mult
Acolo am facut separat conc medicale pt ca sunt toate info de pe un concediu medical...dar vb pe luni marti cum le mai outem simplifica ce am facut eu...
@fetekemihai poti să mai dai un ochi pe modul ?
A mai rămas calcul bază cm, să dea zilele libere legale şi angajatilor noi şi regulile de salarizare
Crezi ca ar fi mai usor sa facem in holiday functie pt baza concediu...ca e odihna...medical, si tot in holiday sa facem pentru zilele platite de angajator/Caa/acc? Sper sa apuc sa il testez in weekend daca nu luni.
pareri
https://github.com/yoyo2k/l10n-romania/tree/payroll/l10n_ro_hr_payroll