GoogleCodeExporter
commented
9 years ago Butonul este practic, dar proceseaza incomplet si incorect. Ceea ce-l face
inutilizabil si periculos. Asta este ce face:
for move in self.browse(cr, uid, ids, context=context): #pentru miscarea din care se declansaza butonul de rebut incearca sa faca inlocuirea
#propune cantitatea de defect egala cu cantitatea din miscare
move_qty = move.product_qty
uos_qty = quantity / move_qty * move.product_uos_qty
#creaza un dictionar cu campuri si valori de inlocuire dar nu corespunde
miscarii stoc sectie
#miscarea din care se declara rebutul este o miscare sectie->productie (din
tabelul produse pentru a fi consumate)
#dar programul face gestiunea sursa (location_id)=gestiunea sursa a miscarii
initiale, adica sectie
#iar gestiunea destinatie (location_dest_id) = gestiunea sursa a miscarii
initiale, adica tot sectie
#deci miscarea de inlocuire va fi una stoc->stoc sau sectie->sectie, pentru
materie prima si stoc->stoc pentru produs finit, ceea ce este gresit.
default_val = {
'product_qty': quantity,
'product_uos_qty': uos_qty,
'state': move.state,
'scrapped' : True,
'location_dest_id': location_id,
'tracking_id': move.tracking_id.id,
'prodlot_id': move.prodlot_id.id,
'date': date or time.strftime('%Y-%m-%d %H:%M:%S'),
'date_expected': date or time.strftime('%Y-%m-%d %H:%M:%S'),
'location_id': location_id or move.location_id.id,
}
#daca gestinea destinatie nu este una interna, face gestiunea sursa = gestiunea
destinatie. Nu e cazul miscarilor noastre
if move.location_id.usage <> 'internal':
default_val.update({'location_id': move.location_dest_id.id})
#creaza miscare de stoc cu valorile setate. Aici este gresit pentru ca recreaza
o miscare stoc->stoc pentru listele de materiale fara gestiune asociata sau
sestie->sectie pentru listele de materiale cu gestiunea sectie asociata (cum
este cazul everest)
new_move = self.copy(cr, uid, move.id, default_val)
Aceasta sursa incearca sa rezolve atat problema mp defecte, cat si a pf rebut.
Daca il pastram in miscarile din Produse pentru a fi consumate din OF, atunci
modificarile sunt substantiale si nu le putem finaliza in 4 ore. In primul rand
trebuie sa facem o modificare in interfete asa fel incat sa apara la consumuri
de mp si sa nu apara la produs finit, dar formularul este pe aceeasi sursa xml
de view. Apoi trebuie sa creeze doua miscari de stoc: una de declarare a mp
defecte in cadrul OFului care se proceseaza si una cuprinsa intr-un picking de
completare (ca sa faca bon) pentru a completa necesarul de mp din sectie. Acest
din urma picking trebuie confirmat si procesat automat. Daca nu poate fi
procesat din lipsa de mp, atunci miscarea initiala din OF la care s-a declarat
mp defecta trebuie pusa pe indisponibil.
Sunt prea multe lucrari de facut si prea riscante ca sa le tratam intr-o
sesiune de modificari OF. De aceea propunerea noastra este sa ascundem butonul
rebut, pentru ca nu functioneaza corect si sa folositi ce am propus sa facem.
Daca in viitor apare o idee mai buna sau o fereastra de timp in care putem sa
implementam o metoda de procesare rebut mai practica, o vom face atunci. Acum
insa este mai greu avand in vedere lucrarile dumneavoastra zilnice, presiunea
asistentei si modificarilor pe care le solicitati zilnic, corectiile in baza de
date care mai sunt de facut. Daca nu acceptati punctul nostru de vedere, atunci
suntem obligati sa va spunem ca folosirea butonului Rebut poate sa genereze
erori in baza de date pe care va trebui sa vi le asumati.Original comment by avram.re...@gmail.com on 5 Apr 2012 at 7:18
Original issue reported on code.google.com by
avram.re...@gmail.comon 5 Apr 2012 at 7:17