search

zaneyaung / everest-openerp

Automatically exported from code.google.com/p/everest-openerp
0 stars 0 forks source link

OF - observatii #6

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
La ordinul de fabricatie OF 7230.
Avem comanda pe 1000 de bucati.

Am schimbat cantitatea la 500, am procesat lista de materiale, apoi am 
aproceast ordinul de fabricatie pe 500, dupa care am schimbat din nou OF la 
500. Problema este ca la produse pentru a fi consumate nu ne-a adus cantitatile 
pentru 500 de PF ci pentru 0 PF.

Original issue reported on code.google.com by avram.re...@gmail.com on 5 Apr 2012 at 12:21

Attachments:

GoogleCodeExporter commented 9 years ago 
Nu am facut decat sa apas pe suspendare si apoi pe reluare dupa suspendare. A 
calculat corect.
Nu stiu din ce stare, cand si cum l-ati suspendat de a calculat gresit.

Original comment by DGilce...@gmail.com on 5 Apr 2012 at 12:26

Attachments:

GoogleCodeExporter commented 9 years ago 
Daca te  uiti la screenshotul tau, in comparatie cu al meu, vezi ca in dreapta 
campului Tip productie am pus campul Cnatitate schimbata, care la tine nu este. 
Asta inseamna ca procesul de schimbare s-a petrecut inainte de noile 
functionalitati de la suspendare OF. Te rog sa urmaresti in continuare 
comportamentul suspendarii si sa ne transmiti imediat observatiile.

Original comment by DGilce...@gmail.com on 5 Apr 2012 at 12:36

GoogleCodeExporter commented 9 years ago

Original comment by avram.re...@gmail.com on 9 Apr 2012 at 6:00

GoogleCodeExporter commented 9 years ago 
Si cele cu Piking Exception fac parte din OF nefinalizate.

Original comment by avram.re...@gmail.com on 9 Apr 2012 at 11:52

Attachments:

GoogleCodeExporter commented 9 years ago 
Corect!
Am adaugat si starea picking_exception la nefinalizate. Am pus si un filtru 
special Exception pentru acestea.

Original comment by DGilce...@gmail.com on 9 Apr 2012 at 12:02

GoogleCodeExporter commented 9 years ago 
Avem urmatoarea eroare:
Creem o comanda de vanzare, o confirmam, procesam OF cu cantitatea din OV. 
In ordinul de livrare reperul ramane pe indisponibil. 
Ce trebuie sa faca:
in momentul cand procesam OF peste cantitatea din ordinul de livrare, reperul 
din ordinul de livrare trebuie sa se puna pe disponiblil.

Original comment by avram.re...@gmail.com on 10 Apr 2012 at 12:12

Attachments:

GoogleCodeExporter commented 9 years ago 
Nu este eroare. Este comportament normal.
Disponibilul pe stoc este 100 (campul disponibil este camp function si se 
calculeaza la afisarea formei), dar starea liniei si a pickingului este camp in 
baza de date. Triggerul de verificare disponibil nu este automat. Trebuie sa 
clichezi Check availability.
Am clickkat eu si a devenit disponibil.

Original comment by DGilce...@gmail.com on 10 Apr 2012 at 12:59

Attachments:

GoogleCodeExporter commented 9 years ago 
Da, se pune pe disponibil doar daca apasam Check availability. Dar trebuie sa 
se puna automant pe disponibil daca:
- am produs o cantitate egala sau mai mare decat este in ordinul de livrare
- ordinul de livrare si ordinul de fabricatie este din aceeasi comanda

Pana acum asa lucra programul, chiar dupa migrarea datelor.

Original comment by avram.re...@gmail.com on 11 Apr 2012 at 5:38

GoogleCodeExporter commented 9 years ago 
O sa verificam in sursa, iar daca asa facea, asa va face. Dar m-am uitat in 
sursele de la mrp_production si nu am vazut aceasta functionalitate. Ea trebuie 
sa se regaseasca la finalizarea OFului. Nu exista o legatura directa de tip 
foreign_key intre mrp_production (OF) si linia stock_move din pickingul de tip 
out (livrarea) generat de OV. Nu exista nici legatura directa de tip 
foreign_key intre mrp_production si linia din OV. Exista doar o legatura 
indirecta in sensul ca in campul origin din OF se gaseste referinta OVului, iar 
produsul are acelasi id ca cel din OV.
O asemenea functionalitate trebuie sa se regaseasca in functiile 
action_produce, action_production_end sau test_production_done din mrp.py, 
clasa mrp_production.
Atasez sursele mrp.py si mrp_workflow.xml originale, poate ne identificati 
partea unde era aceasta functionalitate ca sa o portam si in modificarile 
noastre.
Dar oricum aceasta functionalitate se poate adauga. Este insa ceva de lucru 
pentru asta si poate incarca procesul OF, care si asa este destul de incarcat.
Poate e mai bine sa introducem o actiune check_availability multipla, pentru a 
verifica mai multe livrari deodata.

Original comment by DGilce...@gmail.com on 11 Apr 2012 at 6:25

Attachments:

GoogleCodeExporter commented 9 years ago 
Ai totusi dreptate. In stock_move, in functia action_done, INAINTE de 
finalizarea miscarii care se proceseaza (in cazul nostru intrarea in stoc a 
produsului finit la finalizare OF) se facea FORTARE si finalizare a miscarilor 
care erau destinatie pentru miscare curenta (in cazul nostru livrarea generata 
de OV). Noi am schimbat fortarea si finalizarea cu verificare disponibil, dar 
procesul de verificare a ramas tot INAINTE de finalizarea miscarii curente, asa 
cum a fost prevazut standard. Deci la verificare NU gasea disponibil pentru ca 
nu se finalizase miscarea curenta. Am mutat verificarea disponibilului miscarii 
destinatie DUPA finalizarea miscarii curente si functioneaza.
La urmatoarea repornire de server OpenERP va functiona cum doriti. Cel mai 
probabil maine dimineata.

Original comment by DGilce...@gmail.com on 12 Apr 2012 at 6:43

GoogleCodeExporter commented 9 years ago 
"Poate e mai bine sa introducem o actiune check_availability multipla, pentru a 
verifica mai multe livrari deodata."

- nu este buna deoarece noi avem un produs si in 10 ordine de livrare si 
cantitatea se asociaza la ordinele de livrare haotic.

Cum lucra inainte programul in atasament.

Original comment by avram.re...@gmail.com on 12 Apr 2012 at 11:15

Attachments:

GoogleCodeExporter commented 9 years ago 
Am intese. Nu am vazut comentul 10.

Original comment by avram.re...@gmail.com on 12 Apr 2012 at 11:18

GoogleCodeExporter commented 9 years ago 
Butonul de Terminare imediata puteti sa il puneti undeva mai restrans?

Original comment by avram.re...@gmail.com on 12 Apr 2012 at 11:57

Attachments:

GoogleCodeExporter commented 9 years ago 
Avem comenda pe cantitate 300, producem 350, dar ordinul ramane nefinalizat.
Cand producem o cantitate mai mare decat cea din OV trebuie sa se finalizeze 
automat ordinul de fabricatie. (Nu aparea aceasta eroare la toate OF)

Original comment by avram.re...@gmail.com on 13 Apr 2012 at 7:25

Attachments:

GoogleCodeExporter commented 9 years ago 
Latime buton rezolvata.
Pentru finalizarea productiei cu cantitate mai mica decat cantitatea comndata, 
trebuie sa verificam unde nu iese corect din functia test_production_done.

Original comment by DGilce...@gmail.com on 13 Apr 2012 at 12:24

GoogleCodeExporter commented 9 years ago 
Urmatoarea problema este reprezentata de numarul cantitatii de MP utilizata. 
Acesta nu este rotunjit deloc, si ajung sa am stoc la un produs 0,2. Aveti 
exemplu graitor in primul atasament. Cauza este lista de materiale: din o 
bucata de MP eu produc 3 bucati de produs finit, iar lista de materiale va avea 
cant necesara MP pentru un produs finit 0,334( fiind mai multe zecimale 
rotunjesc la crearea ldm).
Ceea ce doresc este ca numarul de buc de MP necesara sa nu contina zecimale 
deloc. Daca din ldm acest numar este cu zecimale doresc sa fie rotunjit la 
numarul superior.
Pe baza de date 2011 aveam aceasta functionalitate la categoria MP.

Original comment by visean.n...@gmail.com on 19 Apr 2012 at 3:08

Attachments:

GoogleCodeExporter commented 9 years ago 
Probabil in procesul de migrarea a fost schimbata setarea de rotunjire la 
unitatea de masura BUC.
1. Mergeti in Depozit->Configurare->Produs->Unitati de masura->Unitati de masura
2. Deschideti in formular unitatea de masura BUC
3. Setati Rounding Precision = 1,000

Dupa aceasta schimbare, urmatoarele procesari vor fi rotunjite la intreg.

Original comment by DGilce...@gmail.com on 19 Apr 2012 at 3:44

GoogleCodeExporter commented 9 years ago 
Vedeti in atasament unde trebuie sa interveniti.

Original comment by DGilce...@gmail.com on 19 Apr 2012 at 6:03

Attachments:

GoogleCodeExporter commented 9 years ago

Original comment by avram.re...@gmail.com on 20 Apr 2012 at 7:34