payroll #52
Comments
|
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 |
|
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? |
|
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? |
|
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. SA va spun cam ce trebuie sa fie intr-un sistem HR serios, la nivelul asta. sper sa va fi dat cateva idei. sunt absolut de acord cu Mihai, nici nu inteleg de ce nu va bazati pe bye, 2015-02-02 19:25 GMT+01:00 Adrian Vasile [email protected]:
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? |
|
Pentru many2one... https://github.com/0k/web_m2o_enhanced poti adapta poate pt 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: daca esti in model si ai employee_id in view 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? Avem:
Trebuie:
|
|
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? 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. |
|
Ori in holidays ori in contract cred că merge. Am renunțat la istoricul salariului per angajat pentru un input. Pentru că:
O întrebare. Să renunţ la dep de public holidays să fac model separat? |
|
Mai in contract daca il folosim si ca act aditional cred ca nu e relevant...il putem pune in employee ca orice faci toate sunt legate de el...un get_baza_cm cu param date_from, date_to...la fel cu get worked days...iar in holiday luam 6 luni inainte de concediu, cu store...in caz ca e concediu medical si are initial,, atunci isi preia calculul din initial... Nu cred ca ar trebui sa renuntam...e la fel si pentru alte lucruri legate de personal care le ai in OCA/hr chiar daca in unported...Cred ca ar trebui sa vedem de acolo ce mai putem folosi si sa facem pr-uri direct in OCA... |
|
Salut...am apucat sa testez un pic, in principiu e ok, mai trebuie reglat numar zile concediu ce e tras in payroll, la tichete masa am facut calcul automat suma in payroll: https://github.com/feketemihai/l10n-romania/tree/payroll Adaugat in view pentru concediile medicale, poate la initial sa mai punem un domeniu ca datele sa fie succesive...altfel nu are rost sa selectezi..pentru ca nu mai e initial... Sper sa mai apuc zilele astea sa mai vad si eu si sa facem o structura de salar... |
|
am lasat tichetele separate de payslip pt ca, la mine de ex, se dau decalate de salar. initialu se calculeaza automat (coming soon). am vazut conditiile pt ca sa fie continuare:
|
|
da...dar tot apar pe stat, nu??? La initial din cate stiu eu puteai avea coduri diferite...deci te poate trece dintr-o incadrare in alta...din ce moment acea boala se agraveaza, mi se pare normal sa ai alt cod si astfel alt concediu medical...din cate stiu eu si am vazut si cazuri era trecut ca si initial cm cu alt cod..doar datele de sfarsit si data inceput sa fie succesive... |
|
Am apucat să mă uit.. La hr_meal_vouchers.py: Nu mai ştiu pe unde am văzut, parcă pe un forum ori saga ori avocat nu ştiu cum. Şi mie mi se părea stupid dar am învătat să nu mă mire. |
|
De altfel,prin certificat de concediu medical în continuare se înţelege orice certificat care prelungeşte un concediu medical anterior neîntrerupt pentru aceeaşi afecţiune,in cf. cu definitia data de Ordinul233/2006. Art.16,al2_1 din Norme60/32/2006reglementeaza acest aspect: |
pareri
https://github.com/yoyo2k/l10n-romania/tree/payroll/l10n_ro_hr_payroll
The text was updated successfully, but these errors were encountered: