Pregled korisničkih zahtjeva - Laus CC

Klijent: HP Hrvatska Pošta 

Status: 

Ev. 

broj 

44018 13523 

43921 13501 

Pregled korisničkih zahtjeva 

Datum OD: 01.01.2013 Datum DO: 30.07.2013 

Evidentiran zahtjev, Klijentu poslana ponuda / procjena - čeka se odgovor, Čeka se pojašnjenje 

klijenta, Vraćen na rješavanje, U rješavanju, Riješen, Zatvoren-dupli zahtjev, Zatvoren-neće se 

rješavati, Zatvoren-ponuda bez odgovora, Zatvoren-riješit će se po drugom zahtjevu/zadatku, Isporučen 

-završen, Isporučen - Korisnik potvrdio ispravnost 

43999 13519 Riješen 26.07.2013 APLAC 29.07.2013 26.07.2013 Katja Kraljev 

43986 13518 Riješen 25.07.2013 ABASE 27.07.2013 25.07.2013 Katja Kraljev 

43980 13517 Riješen 25.07.2013 LKROP 27.07.2013 Katja 

43978 13516 

43974 13515 

43920 13496 

43910 13500 

Evidentiran 

zahtjev 

Evidentiran 

zahtjev 

Zatvoren-dupli 

zahtjev 

Isporučenzavršen 

25.07.2013 SYSING 26.07.2013 Ivan 


43926 13502 


Čeka se 

pojašnjenje 

klijenta 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

29.07.2013 LWINFAU 29.07.2013 30.07.2013 29.07.2013 

24.07.2013 APLAC 26.07.2013 Katja Kraljev 

22.07.2013 LWINFAU 22.07.2013 Katja 

22.07.2013 APLAC 19.07.2013 22.07.2013 Katja Kraljev 

19.07.2013 LROBD 19.07.2013 26.07.2013 Katja 

Lista: DetaljZahtjevaZaKlijenta2 29/07/2013 19:00 

Stranica: 1/1080 

Ivan 

Poldrugač 

44009 13522 U rješavanju 29.07.2013 LKEVP 29.07.2013 Glorija 

44006 13521 U rješavanju 29.07.2013 APLAC 29.07.2013 Katja Kraljev 


43966 13513 U rješavanju 24.07.2013 LTRAN 28.07.2013 Katja 

43953 13506 

43949 13505 

43944 

Originalni 

broj 


43963 13511 

43961 13510 

43956 13508 

43943 13504 

Status Datum upisa Područje 


Evidentiran 

zahtjev 

Evidentiran 

zahtjev 

43954 13507 Riješen 23.07.2013 LROBD 25.07.2013 Katja 

Evidentiran 

zahtjev 

Evidentiran 

zahtjev 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Evidentiran 

zahtjev 

Mjesto 

zahtjeva 

Očekivani 

datum 

rješenja 

Procjenjeni 

datum 

rješenja 

Datum 

rješenja 

24.07.2013 LKROP 26.07.2013 25.07.2013 Katja 

24.07.2013 LKEVP 26.07.2013 Katja 


23.07.2013 LWINFAU 01.08.2013 01.08.2013 Ivan 

23.07.2013 LWINFAU 24.07.2013 Ivan 

23.07.2013 LWINFAU 31.07.2013 Ivan 

23.07.2013 LFINK bilanca 19.07.2013 23.07.2013 23.07.2013 dugan 

23.07.2013 LWINFAU 01.08.2013 Ivan 

43941 13503 U rješavanju 23.07.2013 LNABD 25.07.2013 Katja 

Kontak 

osoba 

22.07.2013 EPNAB 24.07.2013 23.07.2013 Katja


Status: 

Ev. 

broj 

43889 13499 

43888 13474 

43761 13480 






43886 13495 U rješavanju 17.07.2013 AFINK 19.07.2013 Katja Kraljev 

43885 13497 U rješavanju 17.07.2013 LFINK 19.07.2013 Ivan 

43877 13494 


43788 13483 Riješen 10.07.2013 LCSBI 20.07.2013 19.07.2013 Višnja 

43765 13481 Riješen 09.07.2013 WINTRAN 11.07.2013 Katja 

43764 13482 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

09.07.2013 EOBRRAC 11.07.2013 10.07.2013 Katja 

09.07.2013 EPNAB 10.07.2013 10.07.2013 Višnja 

43757 13479 U rješavanju 09.07.2013 LTRAN 12.07.2013 10.07.2013 Katja 


43741 13477 Riješen 09.07.2013 LWINFAU 12.07.2013 10.07.2013 Katja 

43738 13476 Riješen 09.07.2013 LNABD 11.07.2013 Katja 

43729 13475 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Vraćen na 

rješavanje 


Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Evidentiran 

zahtjev 

18.07.2013 LROBD klase,artikli 18.07.2013 18.07.2013 25.07.2013 katja 

18.07.2013 LTRAN 08.07.2013 Ivan 

43887 13498 Riješen 17.07.2013 SYSING 18.07.2013 18.07.2013 

17.07.2013 EPNAB 18.07.2013 23.07.2013 Katja 


43867 13492 

43859 13491 

43833 13489 


Originalni 

Mjesto 


broj 


Vraćen na 

rješavanje 

Čeka se 

pojašnjenje 

klijenta 

Evidentiran 

zahtjev 

Očekivani 

datum 

rješenja 

Procjenjeni 

datum 

rješenja 

Datum 

rješenja 

43830 13488 Riješen 12.07.2013 WINTRAN 16.07.2013 Katja 


08.07.2013 LKEVP 15.07.2013 Višnja 




Ivan 

Poldrugač 

16.07.2013 LROBD 19.07.2013 Katja 

16.07.2013 EPNAB 17.07.2013 Višnja 


12.07.2013 LWINFAU 16.07.2013 Katja 



Kontak 

osoba


Status: 

Ev. 

broj 

43536 13450 






43705 13472 U rješavanju 05.07.2013 LFINK PDV 2013-07 10.07.2013 Glorija 

43688 13469 U rješavanju 04.07.2013 LWINFAU PDV 2013-07 06.07.2013 Glorija 


43682 13470 


43673 13468 

43664 13467 

43653 13466 

43577 13454 Riješen 27.06.2013 LROBD 10.07.2013 Glorija 

43576 13453 

43567 13452 

Evidentiran 

zahtjev 

Evidentiran 

zahtjev 

Čeka se 

pojašnjenje 

klijenta 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Evidentiran 

zahtjev 

Evidentiran 

zahtjev 

43556 13451 Riješen 26.06.2013 LWINFAU 20.07.2013 Glorija 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

04.07.2013 LWINFAU PDV 2013-07 06.07.2013 Glorija 

03.07.2013 LWINFAU 10.07.2013 Glorija 

03.07.2013 EPNAB 04.07.2013 Višnja 

02.07.2013 LROBD 05.07.2013 08.07.2013 Katja 


43650 13464 

43643 13463 Riješen 02.07.2013 LKROP 31.07.2013 26.07.2013 Višnja 

43641 13462 

43640 13461 

43635 13460 


43624 13457 


Originalni 

Mjesto 


broj 


Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Čeka se 

pojašnjenje 

klijenta 


zahtjev 

Čeka se 

pojašnjenje 

klijenta 

Očekivani 

datum 

rješenja 

Procjenjeni 

datum 

rješenja 

Datum 

rješenja 

02.07.2013 LROBD 05.07.2013 10.07.2013 Katja 

02.07.2013 LTRAN 05.07.2013 11.07.2013 Katja 

02.07.2013 EPNAB 04.07.2013 Višnja 

02.07.2013 LCSBI 02.07.2013 02.07.2013 Glorija 

01.07.2013 EPNAB 03.07.2013 Višnja 



43598 13455 Riješen 28.06.2013 LWINFAU PDV 2013-07 01.07.2013 Glorija 



21.06.2013 EOBRRAC 21.06.2013 26.06.2013 Glorija 

Markovac 

43502 13449 U rješavanju 20.06.2013 LROBD 26.06.2013 Glorija 



Kontak 

osoba


Status: 

Ev. 

broj 

43501 13448 

43496 13446 







43467 13444 

43466 13443 

43388 13436 

43385 13435 Riješen 12.06.2013 LWINFAU 30.06.2013 25.06.2013 Glorija 

43376 13434 Riješen 12.06.2013 LWINFAU 07.06.2013 13.06.2013 

43374 13433 

43365 13432 

43348 13431 U rješavanju 11.06.2013 EHPUR 18.06.2013 Katja 

43347 13430 U rješavanju 11.06.2013 EHPUR 18.06.2013 Katja 

43337 13429 

Evidentiran 

zahtjev 


Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 


Vraćen na 

rješavanje 


Isporučen - 

Korisnik 

potvrdio 

ispravnost 

20.06.2013 LSLOD 26.06.2013 Glorija 


19.06.2013 LFINK 26.06.2013 

19.06.2013 EHPUR 21.06.2013 03.07.2013 Katja 

18.06.2013 LROBD 18.06.2013 19.06.2013 Glorija 

Markovac 

43465 13442 U rješavanju 18.06.2013 WINTRAN 25.06.2013 

43462 13441 Riješen 18.06.2013 LROBD 

43435 13438 Riješen 17.06.2013 LFINK 17.06.2013 17.06.2013 Ivan 

43415 13437 

43408 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

14.06.2013 LFINK 14.06.2013 14.06.2013 Ivan 

11.06.2013 LWINFAU faktN_fas 13.06.2013 ivan 




Glorija 

Markovac 

Glorija 

Markovac 

13.06.2013 LROBD 18.06.2013 19.06.2013 Katja 

43399 13415 Riješen 13.06.2013 LWINFAU 15.06.2013 13.06.2013 Ivan 

Glorija 

Markovac 

43461 13440 Riješen 18.06.2013 LROBD 22.06.2013 Katja Kraljev 

43451 13439 


Originalni 

Mjesto 


broj 


Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Očekivani 

datum 

rješenja 

Procjenjeni 

datum 

rješenja 

Datum 

rješenja 

Kontak 

osoba 

17.06.2013 LWINFAU 17.06.2013 18.06.2013 02.07.2013 Glorija 

Markovac 

12.06.2013 EHPUR 13.06.2013 Katja 

Ivan 

Poldrugač 

12.06.2013 LROBD 17.06.2013 Katja Kraljev


Status: 

Ev. 

broj 

43334 13428 

43323 13427 

43165 13414 







43280 13424 

43278 13425 

43262 13423 

43253 13385 

43252 13385 

43228 13420 

43211 13419 

43204 13418 

43189 13416 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 


43160 13413 Riješen 29.05.2013 LFINK 05.06.2013 Ivan 

43159 13412 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 


Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Zatvoren-neće 

se rješavati 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 


10.06.2013 EOBRRAC 10.06.2013 12.06.2013 Višnja 

10.06.2013 LROBD 13.06.2013 26.07.2013 Katja 

06.06.2013 LKEVP 10.06.2013 14.06.2013 Višnja 

06.06.2013 LKEVP 15.06.2013 01.07.2013 Višnja 

06.06.2013 LTRAN 07.06.2013 06.06.2013 13.06.2013 Katja 

05.06.2013 LSLOD 31.05.2013 06.06.2013 Glorija 

05.06.2013 LROBD 31.05.2013 17.06.2013 Glorija 

43248 13422 Riješen 05.06.2013 LWINFAU 10.06.2013 20.06.2013 Glorija 

43239 13421 


Originalni 

Mjesto 


broj 


Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Očekivani 

datum 

rješenja 

Procjenjeni 

datum 

rješenja 

Datum 

rješenja 

05.06.2013 LWINFAU 07.06.2013 05.06.2013 13.06.2013 Ivan 

04.06.2013 EHPUR upisnik - test 07.06.2013 19.06.2013 Katja 

04.06.2013 LWINFAU 06.06.2013 06.06.2013 13.06.2013 Katja 

04.06.2013 LROBD 06.06.2013 13.06.2013 Katja 

43197 13417 Riješen 03.06.2013 LSTAN protstn.stn 10.06.2013 30.06.2013 Glorija 

03.06.2013 LFINK 03.06.2013 12.06.2013 Glorija 

29.05.2013 EHPUR 31.05.2013 Katja 



Kontak 

osoba


Status: 

Ev. 

broj 

43158 13411 

43157 13410 

43151 13409 

43145 13408 

43126 13407 

43122 13406 

43098 13405 

43074 13404 

43067 13403 

43063 13402 

43062 13401 

43055 13399 






43049 13398 Riješen 22.05.2013 LCSBI 23.05.2013 03.06.2013 Glorija 

43048 13397 


43041 13395 

43036 13394 


Originalni 

Mjesto 


broj 




Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 


Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 


se rješavati 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Očekivani 

datum 

rješenja 

Procjenjeni 

datum 

rješenja 

29.05.2013 EHPUR 31.05.2013 Katja 

29.05.2013 EHPUR 31.05.2013 04.07.2013 Katja 

29.05.2013 EPNAB 29.05.2013 01.07.2013 Višnja 

29.05.2013 EPNAB 31.05.2013 01.07.2013 Višnja 

28.05.2013 LROBD 05.06.2013 13.06.2013 Glorija 

28.05.2013 LROBD 29.05.2013 31.05.2013 Katja 

27.05.2013 LBASE 28.05.2013 28.05.2013 Katja 

24.05.2013 LWINFAU 23.05.2013 03.06.2013 Ivan 

23.05.2013 EPNAB 27.05.2013 24.05.2013 Višnja 

23.05.2013 LWINFAU 23.05.2013 24.05.2013 Ivan 

23.05.2013 EHPUR 24.05.2013 27.05.2013 Višnja 

43058 13400 Riješen 23.05.2013 LWINFAU 23.05.2013 25.06.2013 

Datum 

rješenja 

22.05.2013 EPNAB 24.05.2013 24.05.2013 Višnja 

22.05.2013 EHPUR 22.05.2013 27.05.2013 Višnja 

22.05.2013 LFINK 24.05.2013 04.06.2013 Glorija 

21.05.2013 LFINK 21.05.2013 14.06.2013 Ivan 



Kontak 

osoba 

Ivan 

Poldrugač


Status: 

Ev. 

broj 

43033 13393 

43027 13392 

43026 13391 

43020 13390 






42965 13380 Riješen 16.05.2013 LFINK 17.05.2013 17.05.2013 

42964 13379 

42962 13378 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 



20.05.2013 LFINK 21.05.2013 13.06.2013 Ivan 

43019 Riješen 20.05.2013 SYSING 21.05.2013 04.06.2013 Višnja 

43017 13389 

43012 13388 

42997 13387 

42996 13386 

42995 13385 

42992 13383 

42988 13384 


Originalni 

Mjesto 


broj 


Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

42970 13381 U rješavanju 17.05.2013 LWINFAU 

Očekivani 

datum 

rješenja 

21.05.2013 EPNAB 24.05.2013 27.05.2013 Višnja 

21.05.2013 LFINK 22.05.2013 12.06.2013 Glorija 

21.05.2013 EHPUR 22.05.2013 27.05.2013 Katja 

20.05.2013 LFINK 20.05.2013 03.06.2013 Glorija 

20.05.2013 LROBD 25.05.2013 13.06.2013 Glorija 

17.05.2013 LFINK 31.05.2013 12.06.2013 Glorija 

Markovac 

17.05.2013 LFINK 31.05.2013 13.06.2013 Glorija 

Markovac 

17.05.2013 EHPUR 20.05.2013 27.05.2013 Katja Kraljev 

17.05.2013 LROBD 20.05.2013 04.06.2013 Katja Kraljev 

42978 13382 U rješavanju 17.05.2013 LFINK 25.05.2013 

Procjenjeni 

datum 

rješenja 


Markovac 



Ivan 

Poldrugač 


16.05.2013 LWINFAU 16.05.2013 17.05.2013 

Datum 

rješenja 

Kontak 

osoba 

Glorija 

Markovac 

Glorija 

Markovac 

Ivan 

Poldrugač


Status: 

Ev. 

broj 

42960 13377 

42959 13376 

42947 13375 

42936 13374 

42888 13365 

42887 13364 

42877 13361 

42874 13363 






Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Čeka se 

pojašnjenje 

klijenta 


Isporučen - 

Korisnik 

potvrdio 

ispravnost 

16.05.2013 SYSING 16.05.2013 13.06.2013 

13.05.2013 EPNAB 13.05.2013 15.05.2013 Glorija 

Markovac 

13.05.2013 LWINFAU 13.05.2013 

13.05.2013 LFINK 13.05.2013 12.06.2013 



Ivan 

Poldrugač 


42932 13373 U rješavanju 15.05.2013 LFINK 20.05.2013 

42928 13372 

42922 13371 

42916 13370 

42903 13369 

42902 13368 

42898 13367 

42891 13366 


Originalni 

Mjesto 


broj 


Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Evidentiran 

zahtjev 

Čeka se 

pojašnjenje 

klijenta 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Očekivani 

datum 

rješenja 



14.05.2013 EPNAB 20.05.2013 

Procjenjeni 

datum 

rješenja 

14.05.2013 EPNAB 20.05.2013 15.05.2013 

13.05.2013 LWINFAU 20.05.2013 27.06.2013 

Glorija 

Markovac 

15.05.2013 EHPUR 27.05.2013 Katja Kraljev 

14.05.2013 EOBRRAC 14.05.2013 15.05.2013 

14.05.2013 LBASE 27.05.2013 30.06.2013 

Datum 

rješenja 

Kontak 

osoba 

Ivan 

Poldrugač 

Glorija 

Markovac 

Višnja Abija- 

Ivček 


Ivček 



Ivček 

Glorija 

Markovac 

13.05.2013 LROBD 20.05.2013 28.05.2013 Glorija 

Markovac 

Ivan 

Poldrugač


Status: 

Ev. 

broj 

42871 13362 

42839 13359 

42838 13358 

42823 13357 

42819 13356 

42740 13347 

42721 13346 






Isporučen - 

Korisnik 

potvrdio 

ispravnost 

42868 U rješavanju 10.05.2013 LCSBI sql serveri 

42867 13360 

42744 


Isporučen - 

Korisnik 

potvrdio 

ispravnost 



Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Čeka se 

pojašnjenje 

klijenta 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

10.05.2013 LFINK 10.05.2013 26.06.2013 


09.05.2013 LROBD 12.05.2013 09.05.2013 Glorija 

Markovac 

08.05.2013 LKEVP prepod_jke 15.05.2013 15.05.2013 15.05.2013 visnja 

08.05.2013 EPNAB 

42815 13355 Riješen 08.05.2013 LCSBI 

42814 13354 

42801 13353 

42793 13352 

42784 13351 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

otvaranje 


08.05.2013 28.05.2013 visnja 

02.05.2013 LFINK 02.05.2013 03.05.2013 Glorija 

30.04.2013 LTRAN 30.04.2013 13.06.2013 Ivan 



Ivan 

Poldrugač 

Marin 

Junušić 


06.05.2013 LTRAN prihp_jtr 06.05.2013 07.05.2013 visnja 

42783 13350 Riješen 06.05.2013 LKROP oobu_fk 31.05.2013 30.06.2013 09.07.2013 visnja 

42771 13349 

42767 13348 


Originalni 

Mjesto 


broj 


Evidentiran 

zahtjev 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

08.05.2013 LWINFAU fiskalni broj 15.05.2013 glorija 

07.05.2013 LWINFAU 

06.05.2013 LWINFAU knjkat.jas 07.05.2013 07.05.2013 13.06.2013 glorija 

03.05.2013 EHPUR 

bilanca PS 

2012 

ruckat.jas 

DTV 

Promjena 

naziva spisa 

Očekivani 

datum 

rješenja 

Procjenjeni 

datum 

rješenja 

Datum 

rješenja 

20.05.2013 05.06.2013 glorija 

07.05.2013 28.05.2013 ivan 

06.05.2013 LKROP dis_ban_fk 20.05.2013 20.05.2013 visnja 

06.05.2013 06.05.2013 06.05.2013 

Kontak 

osoba 

višnja abija 

ivček 

02.05.2013 LCSBI 06.05.2013 Glorija


Status: 

Ev. 

broj 

42719 13345 

42606 13332 

42572 13325 






42704 Riješen 29.04.2013 APLAC BO 29.04.2013 29.04.2013 29.04.2013 Goga 

42690 13343 

42629 13334 

42551 13330 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 


Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

29.04.2013 LFINK 30.04.2013 12.06.2013 Ivan 


42631 13335 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

30.04.2013 EHPUR 07.05.2013 28.05.2013 Katja 

42716 13344 U rješavanju 30.04.2013 LFINK 15.05.2013 Glorija 

42658 13341 

42654 13340 

42652 13339 

42639 13338 

42634 13337 

42632 13336 


Originalni 

Mjesto 


broj 


Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Očekivani 

datum 

rješenja 

Procjenjeni 

datum 

rješenja 

Datum 

rješenja 

25.04.2013 LFINK 30.06.2013 29.04.2013 Glorija 

25.04.2013 LFINK 07.05.2013 26.04.2013 Glorija 

25.04.2013 LWINFAU 26.04.2013 13.06.2013 Ivan 

24.04.2013 LROBD 26.04.2013 14.06.2013 Katja 

24.04.2013 WINTRAN 26.04.2013 04.06.2013 Katja 

24.04.2013 LFINK 06.05.2013 03.05.2013 12.06.2013 Glorija 


23.04.2013 LKROP 24.04.2013 23.04.2013 Višnja 

42628 13333 U rješavanju 23.04.2013 LROBD 26.04.2013 Ivan 

22.04.2013 EHPUR 26.04.2013 28.05.2013 Katja 

19.04.2013 LFINK 18.04.2013 12.06.2013 Glorija 

18.04.2013 LWINFAU 24.04.2013 30.04.2013 Glorija 

42541 13329 Riješen 18.04.2013 LWINFAU 30.04.2013 Ivan 



Kontak 

osoba


Status: 

Ev. 

broj 

42463 13311 

42442 13310 







42536 13327 

42533 13326 

42522 13324 

42520 13319 

42514 13323 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 


zahtjev 


se rješavati 


Evidentiran 

zahtjev 

16.04.2013 LROBD 19.04.2013 04.06.2013 Katja 

16.04.2013 LKROP 16.05.2013 17.04.2013 Višnja 

16.04.2013 LROBD 19.04.2013 15.05.2013 Katja 


42506 13321 

42504 13320 

42474 13312 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

17.04.2013 EHPUR 19.04.2013 30.04.2013 Katja 

17.04.2013 EHPUR 18.04.2013 18.04.2013 Katja 

16.04.2013 LFINK 17.04.2013 02.05.2013 26.06.2013 Ivan 


42497 13319 

42493 13318 

42480 13316 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

15.04.2013 LFINK 25.04.2013 26.04.2013 17.05.2013 Glorija 


42478 13314 U rješavanju 15.04.2013 LROBD 19.04.2013 Katja 

42475 13313 


Originalni 

Mjesto 


broj 


Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Očekivani 

datum 

rješenja 

Procjenjeni 

datum 

rješenja 

Datum 

rješenja 


16.04.2013 LKROP dis_ban_fk 03.05.2013 07.05.2013 13.06.2013 višnja 

16.04.2013 LFINK 30.06.2013 17.05.2013 Glorija 

12.04.2013 LFINK bss ubrzanje 15.04.2013 22.04.2013 28.05.2013 ivan 

12.04.2013 LFINK bss 15.04.2013 16.04.2013 26.06.2013 ivan 

12.04.2013 LKROP 30.04.2013 19.04.2013 17.04.2013 Glorija 

11.04.2013 LKROP 30.04.2013 31.08.2013 Višnja 



Kontak 

osoba


Status: 

Ev. 

broj 

42440 13309 

42435 13308 

42394 13307 

42386 13306 

42374 13305 

42373 13304 

42364 13303 

42363 13302 

42349 13299 

42343 13298 

42331 13297 

42325 13296 






Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

08.04.2013 LFINK 09.04.2013 Glorija 

Markovac 

05.04.2013 LWINFAU 

fiskalizacija 

platni 

08.04.2013 08.04.2013 13.06.2013 glorija 

05.04.2013 LCSBI pri_ftr 18.04.2013 

42324 13295 Riješen 05.04.2013 LKEVP ERV 07.04.2013 

42314 13294 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 


Isporučen - 

Korisnik 

potvrdio 

ispravnost 

11.04.2013 LWINFAU 14.04.2013 13.06.2013 Ivan 

11.04.2013 LFINK 12.04.2013 31.05.2013 Glorija 

09.04.2013 EPNAB 15.04.2013 23.04.2013 Višnja 

09.04.2013 LROBD 10.04.2013 04.06.2013 Katja 


42356 13301 Riješen 08.04.2013 LKEVP 08.04.2013 08.04.2013 

42351 13300 


Originalni 

Mjesto 


broj 


Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 


Očekivani 

datum 

rješenja 

Procjenjeni 

datum 

rješenja 

Datum 

rješenja 


08.04.2013 LFINK 20.04.2013 12.06.2013 Glorija 

Markovac 

08.04.2013 LFINK 10.04.2013 12.06.2013 

08.04.2013 LNABD 15.04.2013 08.04.2013 

08.04.2013 LKROP 30.04.2013 30.04.2013 19.04.2013 



Kontak 

osoba 

Ivan 

Poldrugač 


Ivček 


Ivček 


Ivček 

Ivan 

Poldrugač 


Ivček 

05.04.2013 LFINK 12.06.2013 Glorija 

Markovac


Status: 

Ev. 

broj 

42305 13293 

42303 13292 

42287 12603 

42277 13291 

42276 13290 

42270 13289 

42259 13288 

42250 13287 

42235 13286 

42226 13285 

42216 13284 

42210 13283 

42207 13282 

42206 13281 

42205 13280 

42204 13279 







Originalni 

Mjesto 


broj 


Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 


Isporučen - 

Korisnik 

potvrdio 

ispravnost 


Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 


Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 


04.04.2013 EHPUR 08.04.2013 19.04.2013 Katja 

04.04.2013 LTRAN 08.04.2013 13.06.2013 Katja 

03.04.2013 EPNAB 

toška 8 OS 

adaptivno 

Očekivani 

datum 

rješenja 

Procjenjeni 

datum 

rješenja 

Datum 

rješenja 

08.04.2013 visnja 

03.04.2013 LTRAN 05.04.2013 14.06.2013 Ivan 

03.04.2013 LSLOD 10.04.2013 19.04.2013 08.04.2013 Glorija 

03.04.2013 LBASE 03.04.2013 18.04.2013 Glorija 

03.04.2013 LFINK 04.04.2013 04.04.2013 Glorija 


02.04.2013 WINTRAN 05.04.2013 04.06.2013 Katja 

02.04.2013 EPNAB 04.04.2013 11.04.2013 Višnja 

02.04.2013 EHPUR 05.04.2013 25.04.2013 Katja 








Kontak 

osoba


Status: 

Ev. 

broj 

42203 13278 

42199 13277 

42198 13276 

42197 13275 

42193 13274 

42190 13273 

42167 13272 

42164 13271 

42163 13270 

42146 13269 

42142 13238 

42139 13268 

42134 13267 

42128 13266 

42124 13265 






Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 


Isporučen - 

Korisnik 

potvrdio 

ispravnost 

26.03.2013 EHPUR 02.04.2013 10.06.2013 Katja 

26.03.2013 LROBD 28.03.2013 04.06.2013 Katja 

26.03.2013 LKEVP 27.03.2013 27.03.2013 Višnja 

26.03.2013 LWINFAU 27.03.2013 13.06.2013 Ivan 

42119 13264 Riješen 26.03.2013 LBASE 15.04.2013 15.06.2013 Višnja 

42118 13263 


Originalni 

Mjesto 


broj 


Isporučen - 

Korisnik 

potvrdio 

ispravnost 


Isporučen - 

Korisnik 

potvrdio 

ispravnost 


se rješavati 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 


Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 


Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Očekivani 

datum 

rješenja 

Procjenjeni 

datum 

rješenja 

Datum 

rješenja 





28.03.2013 LTRAN 03.04.2013 13.06.2013 Katja 

28.03.2013 LTRAN 02.04.2013 29.03.2013 29.03.2013 Katja 

27.03.2013 LWINFAU 28.03.2013 14.06.2013 Ivan 

27.03.2013 EPNAB 29.03.2013 16.04.2013 Višnja 

27.03.2013 EHPUR 02.04.2013 25.04.2013 Katja 

27.03.2013 EOBRRAC 02.04.2013 12.06.2013 Ivan 

26.03.2013 LKROP 15.04.2013 Višnja 

25.03.2013 WINTRAN 28.03.2013 04.06.2013 Katja 



Kontak 

osoba


Status: 

Ev. 

broj 

42113 13262 

42087 13261 

42083 13260 

42082 13258 

42081 13259 

42080 13257 

42076 13256 

42074 13255 

42018 13248 

42012 12600 






Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Čeka se 

pojašnjenje 

klijenta 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

25.03.2013 WINTRAN 28.03.2013 08.04.2013 Katja 

22.03.2013 LROBD 

42073 13249 Riješen 22.03.2013 LCSBI 

42063 13254 

42056 13252 

42049 13251 


Originalni 

Mjesto 


broj 


Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 


se rješavati 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

42022 13249 Riješen 20.03.2013 LCSBI 

RO2ul_jd 

RO2ulO_jd 

28.03.2013 13.06.2013 glorija 


22.03.2013 LTRAN 26.03.2013 27.03.2013 Katja 

22.03.2013 LFINK 28.03.2013 26.04.2013 12.06.2013 Glorija 

22.03.2013 LTRAN 26.03.2013 27.03.2013 Katja 

22.03.2013 EHPUR 26.03.2013 28.05.2013 Katja 


DDRDG 

upute za 

2013. 

22.03.2013 LFINK 27.03.2013 09.05.2013 Glorija 

21.03.2013 LROBD 28.04.2013 13.06.2013 Glorija 

42035 13250 Riješen 20.03.2013 LFINK 20.03.2013 02.04.2013 Glorija 

nova 

hijerarhija 

Očekivani 

datum 

rješenja 

Procjenjeni 

datum 

rješenja 

Datum 

rješenja 

25.03.2013 22.03.2013 02.04.2013 Nada 

Martinović 



22.04.2013 26.03.2013 05.04.2013 glorija 

20.03.2013 LSLOD 30.04.2013 13.06.2013 Glorija 

19.03.2013 EPNAB 31.10.2012 14.05.2013 višnja 



Kontak 

osoba


Status: 

Ev. 

broj 

41951 13231 

41950 13230 






42007 13247 Riješen 19.03.2013 LWINFAU 26.06.2013 


41993 13245 

41992 13244 

41991 13243 

41983 13242 

41982 13241 

41981 13240 

41978 13238 

41977 13237 

41976 13236 

41971 13235 

41961 13233 Riješen 15.03.2013 LKROP 20.03.2013 15.04.2013 

41960 13232 

41949 13229 


Originalni 

Mjesto 


broj 


Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Evidentiran 

zahtjev 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 


Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 


Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 


se rješavati 

Čeka se 

pojašnjenje 

klijenta 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Očekivani 

datum 

rješenja 

19.03.2013 LWINFAU 31.03.2013 13.06.2013 Ivan 

19.03.2013 LWINFAU 31.03.2013 Ivan 

19.03.2013 LNABD 22.03.2013 04.06.2013 Katja 

18.03.2013 LROBD 21.03.2013 04.06.2013 Katja 

15.03.2013 EPNAB 18.03.2013 16.04.2013 


Markovac 

15.03.2013 LWINFAU 18.03.2013 

Procjenjeni 

datum 

rješenja 

Datum 

rješenja 



Ivan 

Poldrugač 

18.03.2013 LNABD 22.03.2013 08.04.2013 Katja 

18.03.2013 LOSSA 18.03.2013 14.06.2013 Glorija 

18.03.2013 LWINFAU 20.03.2013 28.05.2013 Ivan 

41980 13239 Riješen 18.03.2013 LROBD 20.03.2013 Ivan 

Kontak 

osoba 

18.03.2013 LKROP 30.03.2013 19.04.2013 18.04.2013 Višnja 

18.03.2013 LROBD 22.03.2013 04.06.2013 Katja 

18.03.2013 LROBD 22.03.2013 04.06.2013 Katja 


Ivček 


Ivček 

Ivan 

Poldrugač 


Markovac


Status: 

Ev. 

broj 

41938 13228 

41937 13227 

41936 13226 

41931 13226 

41930 13225 

41924 13224 

41868 13215 






Isporučen - 

Korisnik 

potvrdio 

ispravnost 


zahtjev 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

14.03.2013 WINTRAN asorl.trn 18.03.2013 03.06.2013 katja 

14.03.2013 LWINFAU 14.03.2013 14.03.2013 14.03.2013 Ivan 

14.03.2013 LBASE 20.03.2013 04.06.2013 Glorija 


41922 13223 U rješavanju 14.03.2013 LKROP 31.07.2013 Višnja 

41869 13217 


Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

14.03.2013 LROBD hp_Pknj_jd 20.03.2013 20.03.2013 15.03.2013 glorija 

14.03.2013 LWINFAU 

odobrenja na 

rucfak i fakis 

15.03.2013 15.03.2013 03.06.2013 ivan 

41919 13222 U rješavanju 14.03.2013 LKROP 31.03.2013 21.06.2013 Višnja 

41913 13221 

41900 13219 

41899 13220 

41888 13218 

41873 13216 

41870 13213 


Originalni 

Mjesto 


broj 


Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Čeka se 

pojašnjenje 

klijenta 

Očekivani 

datum 

rješenja 

Procjenjeni 

datum 

rješenja 

Datum 

rješenja 

14.03.2013 LROBD 14.03.2013 04.06.2013 Katja 


13.03.2013 LFINK 17.03.2013 04.06.2013 Glorija 

12.03.2013 LFINK 13.03.2013 03.06.2013 Ivan 

12.03.2013 LROBD 13.03.2013 04.06.2013 Katja 


12.03.2013 LWINFAU 15.03.2013 Ivan 

12.03.2013 LROBD 12.03.2013 12.03.2013 Katja 

12.03.2013 EHPUR 13.03.2013 02.04.2013 Katja 

41859 13212 Riješen 11.03.2013 AFINK 13.03.2013 12.03.2013 Glorija 



Kontak 

osoba


Status: 

Ev. 

broj 

41858 13211 

41855 13210 

41852 13209 

41851 13208 

41850 13207 

41807 13200 

41789 13198 

41787 13197 

41775 






41802 Riješen 07.03.2013 LROBD 15.03.2013 18.03.2013 Katja 

41799 13199 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Zatvoren-riješit 

će se po 

drugom 

zahtjevu/zadatk 

u 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

11.03.2013 LWINFAU 12.03.2013 13.03.2013 03.06.2013 Ivan 

11.03.2013 EHPUR 13.03.2013 02.04.2013 Katja 

11.03.2013 EHPUR 13.03.2013 15.03.2013 Katja 


11.03.2013 LFINK 12.03.2013 27.03.2013 21.03.2013 Ivan 


41841 13205 

41837 13204 


Originalni 

Mjesto 


broj 


Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Očekivani 

datum 

rješenja 

Procjenjeni 

datum 

rješenja 

Datum 

rješenja 

11.03.2013 LFINK 12.03.2013 26.06.2013 Ivan 

11.03.2013 LWINFAU 12.03.2013 13.03.2013 03.06.2013 Ivan 

41836 13203 Riješen 11.03.2013 LKEVP BO 30.03.2013 26.04.2013 16.04.2013 Višnja 


41808 13201 U rješavanju 08.03.2013 LSLOD 15.03.2013 Glorija 

08.03.2013 LWSLOD 15.03.2013 03.05.2013 26.06.2013 Glorija 



07.03.2013 EHPUR 08.03.2013 18.03.2013 02.04.2013 Katja 

07.03.2013 LROBD 08.03.2013 11.03.2013 Renata 

Basrek 



Kontak 

osoba


Status: 

Ev. 

broj 

41766 13196 

41756 13195 

41753 13194 

41750 13186 

41747 13193 

41746 13192 

41744 13191 

41743 13185 

41742 13190 

41708 13182 

41694 13179 

41690 13181 






Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 


Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 


06.03.2013 EHPUR 11.03.2013 25.04.2013 Katja 

06.03.2013 LFINK 08.03.2013 12.03.2013 Katja 

06.03.2013 LROBD 08.03.2013 06.03.2013 Katja 

06.03.2013 EHPUR 08.03.2013 11.03.2013 Katja 

06.03.2013 EOBRRAC 06.03.2013 12.06.2013 Ivan 

06.03.2013 LROBD 08.03.2013 04.06.2013 Katja 

06.03.2013 EHPUR 08.03.2013 08.03.2013 Katja 


41721 13184 

41719 13183 


Originalni 

Mjesto 


broj 


Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

41736 13188 U rješavanju 05.03.2013 LWINFAU 20.03.2013 Glorija 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Očekivani 

datum 

rješenja 

Procjenjeni 

datum 

rješenja 

Datum 

rješenja 

06.03.2013 EHPUR 08.03.2013 25.03.2013 Katja 

06.03.2013 LWINFAU 06.03.2013 Ivan 


05.03.2013 EHPUR 08.03.2013 28.05.2013 Katja 

05.03.2013 EHPUR 08.03.2013 22.05.2013 Katja 

04.03.2013 LTRAN 04.03.2013 04.06.2013 Katja 

04.03.2013 LFINK 05.03.2013 20.03.2013 Ivan 

04.03.2013 LROBD 06.03.2013 06.03.2013 Katja 



Kontak 

osoba


Status: 

Ev. 

broj 

41689 13180 

41670 

41656 13171 

41632 13178 

41627 13177 

41626 13176 

41561 13167 

41556 13166 

41541 13165 

41535 13163 

41534 13162 







će se po 

drugom 


u 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 






41538 13164 U rješavanju 25.02.2013 LSTAN 15.03.2013 10.07.2013 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

04.03.2013 EHPUR 15.03.2013 02.04.2013 Katja 

01.03.2013 LROBD RM1--> RM2 01.03.2013 01.03.2013 04.06.2013 kučuk 

01.03.2013 EPNAB 28.02.2013 13.03.2013 


Markovac 

28.02.2013 LKEVP ERV 15.03.2013 01.06.2013 17.05.2013 

28.02.2013 LKROP 06.03.2013 08.03.2013 

41616 13175 Riješen 28.02.2013 LKEVP BO 06.03.2013 19.04.2013 22.04.2013 

41594 13174 

41593 13173 

41592 13172 

41589 13170 

41582 13169 


Originalni 

Mjesto 


broj 



se rješavati 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 


se rješavati 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 


27.02.2013 LFINK 

kamob_ff, 

kamsve_ff 

Očekivani 

datum 

rješenja 

Procjenjeni 

datum 

rješenja 

Datum 

rješenja 

26.02.2013 LROBD SI u upotrebi 15.03.2013 28.02.2013 Glorija 

markovac 



25.02.2013 LFINK 28.02.2013 12.06.2013 Glorija 

Markovac 




Ivček 


Ivček 


Ivček 

15.03.2013 19.03.2013 Glorija 

Markovac 


Markovac 

27.02.2013 LROBD 27.02.2013 Katja Kraljev 

41573 13168 Riješen 26.02.2013 LKROP 06.03.2013 14.03.2013 15.04.2013 

Kontak 

osoba 


Ivček 

27.02.2013 LWINFAU ruckat.jas 04.03.2013 19.03.2013 Glorija 

Markovac 

27.02.2013 LBASE 04.03.2013 12.06.2013 Glorija 

Markovac 


Ivček 

26.02.2013 LROBD prd_ul_jd 28.02.2013 27.02.2013 Katja Kraljev 

Glorija 

Markovac


Status: 

Ev. 

broj 

41533 

41448 13149 

41447 13148 






12640dopuna 

41529 13161 

41528 13160 

41524 13159 Riješen 25.02.2013 LCSBI 

41523 13147 

41497 13158 

41496 13157 

41495 13156 

41493 13155 

41492 13154 

41485 13153 

41481 13152 

41479 13151 

41460 13150 

41446 13146 


Originalni 

Mjesto 


broj 



Čeka se 

pojašnjenje 

klijenta 


će se po 

drugom 


u 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 


Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 



Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 


25.02.2013 LTRAN 08.03.2013 08.03.2013 Glorija 

Markovac 

25.02.2013 LKEVP 15.03.2013 01.07.2013 

25.02.2013 LWINFAU 25.02.2013 09.04.2013 

Fluktuacija i 

NTI 

Očekivani 

datum 

rješenja 

Procjenjeni 

datum 

rješenja 

Datum 

rješenja 

27.02.2013 25.02.2013 Glorija 

Markovac 

25.02.2013 LROBD 25.02.2013 Glorija 

Markovac 

22.02.2013 LFINK 14.05.2013 Glorija 

Markovac 

21.02.2013 LROBD 25.02.2013 04.06.2013 Katja 

21.02.2013 EHPUR 25.02.2013 04.03.2013 Katja 

21.02.2013 LBASE 22.02.2013 30.06.2013 Glorija 



Ivan 

Poldrugač 

21.02.2013 EHPUR 25.02.2013 25.02.2013 Katja 


Ivček 

22.02.2013 EHPUR 11.03.2013 Katja Kraljev 

22.02.2013 LROBD 22.02.2013 22.02.2013 22.02.2013 Katja Kraljev 

22.02.2013 LFINK 28.02.2013 04.03.2013 15.03.2013 

Kontak 

osoba 


Ivček 

22.02.2013 LROBD 22.02.2013 22.02.2013 25.02.2013 Katja Kraljev 

22.02.2013 LROBD 22.02.2013 Glorija 

Markovac 

22.02.2013 LROBD 22.02.2013 Katja Kraljev 

22.02.2013 EHPUR 25.02.2013 Katja Kraljev


Status: 

Ev. 

broj 

41428 13145 

41416 13143 

41414 13048 

41412 13142 

41356 13095 

41339 13053 






Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

15.02.2013 LFINK bss_ugovor 20.02.2013 12.06.2013 ivan 

41354 13113 Riješen 15.02.2013 LKEVP 16.02.2013 15.02.2013 Višnja 

41342 13053 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 


se rješavati 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

20.02.2013 EPNAB 25.02.2013 05.06.2013 Višnja 

41425 13144 U rješavanju 20.02.2013 LKROP 28.02.2013 Višnja 

41410 13141 

41409 13139 

41407 13141 

41398 13138 

41397 13137 


zahtjev 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

19.02.2013 LFINK 28.02.2013 17.05.2013 Glorija 

19.02.2013 LBASE 25.01.2013 25.04.2013 Glorija 

19.02.2013 WINTRAN 20.02.2013 20.02.2013 Glorija 

19.02.2013 LWINFAU 25.02.2013 19.02.2013 Ivan 

19.02.2013 LFINK 28.02.2013 12.06.2013 Glorija 


41393 13135 


Originalni 

Mjesto 


broj 


Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Očekivani 

datum 

rješenja 

Procjenjeni 

datum 

rješenja 

Datum 

rješenja 

19.02.2013 LROBD 22.02.2013 04.06.2013 Katja 

19.02.2013 LWINFAU fak* Zone 25.02.2013 13.06.2013 

19.02.2013 LFINK 19.02.2013 19.03.2013 Ivan 

18.02.2013 LBASE 18.02.2013 23.04.2013 Glorija 


15.02.2013 LROBD 18.02.2013 22.02.2013 Katja 

14.02.2013 LROBD 18.02.2013 22.02.2013 Katja 



Kontak 

osoba 

ivan 66 26 

313


Status: 

Ev. 

broj 

41338 13053 

41337 13053 

41336 13132 

41335 13131 

41325 13130 

41316 13129 

41315 13128 

41298 13127 

41296 13126 

41294 13125 

41292 13080 

41291 13124 

41277 13123 

41274 13122 

41263 13121 







Originalni 

Mjesto 


broj 


Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Čeka se 

pojašnjenje 

klijenta 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 


Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Očekivani 

datum 

rješenja 

Procjenjeni 

datum 

rješenja 

Datum 

rješenja 

14.02.2013 LROBD 15.02.2013 22.02.2013 Katja 

14.02.2013 LROBD 19.02.2013 22.02.2013 Katja 

14.02.2013 EPNAB 15.02.2013 Višnja 

14.02.2013 EHPUR 18.02.2013 11.03.2013 Katja 

14.02.2013 EOBRRAC 14.02.2013 24.06.2013 Ivan 

14.02.2013 LWINFAU 15.02.2013 01.03.2013 13.06.2013 Ivan 

14.02.2013 LWINFAU 15.02.2013 13.06.2013 Ivan 

13.02.2013 LROBD 15.02.2013 04.06.2013 Katja 

13.02.2013 EOBRRAC 15.02.2013 28.05.2013 Ivan 

13.02.2013 LROBD 15.02.2013 04.06.2013 Katja 

13.02.2013 LWINFAU ruckat, vr4 15.02.2013 05.06.2013 

13.02.2013 LWINFAU 13.02.2013 13.06.2013 Ivan 

12.02.2013 LWINFAU 13.02.2013 12.02.2013 13.06.2013 Višnja 

12.02.2013 LKROP 13.02.2013 12.02.2013 Višnja 

12.02.2013 LROBD 15.02.2013 04.06.2013 Katja 



Kontak 

osoba 

visnja, 

glorija


Status: 

Ev. 

broj 

41252 13120 

41251 

41242 13119 

41240 

41233 13118 

41230 13117 

41229 13115 

41200 13114 

41183 13106 







41187 13108 

41185 13107 



zahtjev 


07.02.2013 WINTRAN 11.02.2013 11.02.2013 Katja 

07.02.2013 LFINK 15.02.2013 28.02.2013 Višnja 

07.02.2013 LKEVP 15.02.2013 01.06.2013 21.05.2013 Višnja 

41181 13105 Riješen 07.02.2013 LFINK 08.02.2013 11.02.2013 Katja 

41166 13103 Riješen 06.02.2013 LFINK pna_kot_jf 07.02.2013 11.02.2013 višnja 

41150 13102 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Evidentiran 

zahtjev 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

11.02.2013 LTRAN 14.02.2013 07.05.2013 Katja 

11.02.2013 LROBD 11.02.2013 04.06.2013 Katja 

11.02.2013 LFINK 11.02.2013 12.06.2013 Ivan 

11.02.2013 LROBD 11.02.2013 13.06.2013 Renata 

11.02.2013 WINTRAN 13.02.2013 02.04.2013 Katja 

11.02.2013 LFINK 11.02.2013 19.03.2013 Ivan 

07.02.2013 LWINFAU 15.02.2013 Ivan 


41194 13110 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 


08.02.2013 LFINK 

07.02.2013 LKEVP 15.02.2013 25.02.2013 Višnja 

41193 13111 Riješen 07.02.2013 LKEVP ERV 15.02.2013 30.04.2013 03.05.2013 Višnja 

05.02.2013 LWINFAU 

prijenos 

računa iz BSS 

fakis.jas nova 

lista 

11.02.2013 01.03.2013 ivan 

41221 13116 Riješen 08.02.2013 LKEVP Prijenos ERV 08.02.2013 22.02.2013 višnja 

41203 13114 


Originalni 

Mjesto 


broj 



će se po 

drugom 


u 

Očekivani 

datum 

rješenja 

Procjenjeni 

datum 

rješenja 

Datum 

rješenja 

07.02.2013 LWINFAU 15.02.2013 19.02.2013 Ivan 

07.02.2013 13.02.2013 13.06.2013 ivan 



Kontak 

osoba


Status: 

Ev. 

broj 

41149 13104 

41135 13101 

41116 13100 

40988 13086 

40987 13085 







41110 13098 Riješen 04.02.2013 LKROP 07.02.2013 25.02.2013 15.04.2013 Višnja 


41072 13096 

41071 13095 

41006 13088 


Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 



05.02.2013 LWINFAU ruckat 06.02.2013 06.02.2013 11.02.2013 ivan 

04.02.2013 WINTRAN 11.02.2013 04.06.2013 Katja 

01.02.2013 LTRAN 

41067 13094 Riješen 01.02.2013 LCSBI 

41064 13093 

41060 13092 

41049 13091 

41015 13089 


05.02.2013 LWINFAU 11.02.2013 13.06.2013 Višnja 

hp_lm_jtr 

PRIJENOS 

ŠIFARNIKA U 

MIPS 

05.02.2013 11.02.2013 katja 

01.02.2013 LWINFAU bss, DTV 01.02.2013 15.05.2013 ivan 


Markovac 

41014 13087 

41013 13070 


Originalni 

Mjesto 


broj 


Isporučen - 

Korisnik 

potvrdio 

ispravnost 


će se po 

drugom 


u 


Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

učitavanje 

podataka 

02.02.2013 05.02.2013 07.03.2013 glorija 

01.02.2013 LWINFAU ispis računa 01.02.2013 04.02.2013 28.02.2013 glorija 

01.02.2013 AFINK 

upute za 

konta u 

uputama za 

generiranje 

konsolidiranih 

izvještaja 

Očekivani 

datum 

rješenja 

Procjenjeni 

datum 

rješenja 

Datum 

rješenja 

02.02.2013 07.03.2013 glorija 

01.02.2013 LSTAN 11.02.2013 Glorija 

Markovac 

30.01.2013 LROBD RUDul_jd 04.02.2013 11.02.2013 katja 

30.01.2013 LROBD asortiman 30.01.2013 01.02.2013 katja 

30.01.2013 LFINK pna_kot_jf 30.01.2013 30.01.2013 04.02.2013 Višnja 

30.01.2013 EPNAB ugovori 30.01.2013 30.01.2013 07.02.2013 višnja 

29.01.2013 LROBD RIMul_jd 29.01.2013 29.01.2013 11.02.2013 katja 




Kontak 

osoba


Status: 

Ev. 

broj 

40986 13084 

40975 13083 

40967 13081 

40966 13082 

40945 13080 

40942 13079 

40937 13078 

40913 13077 

40910 13075 

40893 13073 

40888 13072 

40887 13071 

40886 13070 

40885 13069 

40884 13068 

40881 12603 







Originalni 

Mjesto 


broj 



Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 


će se po 

drugom 


u 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 


Isporučen - 

Korisnik 

potvrdio 

ispravnost 




Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Čeka se 

pojašnjenje 

klijenta 

29.01.2013 LROBD 29.01.2013 11.02.2013 Ivan 

29.01.2013 EOBRRAC 29.01.2013 19.02.2013 Ivan 

29.01.2013 LBASE 02.02.2013 28.02.2013 Glorija 

29.01.2013 LTRAN 29.01.2013 05.02.2013 Katja 


25.01.2013 LFINK 

PDV obrasci 

2013 

Očekivani 

datum 

rješenja 

Procjenjeni 

datum 

rješenja 

Datum 

rješenja 



40927 13076 Riješen 28.01.2013 WINTRAN 29.01.2013 11.02.2013 Glorija 

05.02.2013 01.03.2013 ivan, kramer 

25.01.2013 LWINFAU 25.01.2013 26.01.2013 11.02.2013


Status: 

Ev. 

broj 

40873 13067 

40854 13066 

40853 13065 

40841 13064 

40832 13063 

40829 13062 

40822 13061 

40821 13060 

40819 13057 

40818 13058 

40814 13059 

40793 13056 

40785 13055 

40778 13054 

40769 12714 

40768 12714 

40767 12714 

40766 12714 

40765 12714 







Originalni 

Mjesto 


broj 


Isporučen - 

Korisnik 

potvrdio 

ispravnost 


se rješavati 



Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 



Isporučen - 

Korisnik 

potvrdio 

ispravnost 


Isporučen - 

Korisnik 

potvrdio 

ispravnost 



Isporučen - 

Korisnik 

potvrdio 

ispravnost 


Čeka se 

pojašnjenje 

klijenta 


Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 


23.01.2013 LROBD 29.01.2013 05.02.2013 Katja 

23.01.2013 LROBD 23.01.2013 23.01.2013 23.01.2013 Katja 

22.01.2013 LWINFAU 

22.01.2013 LWINFAU 

knjdig.jas i 

knjstb.jas 

fakture 

tiptar=8 

Očekivani 

datum 

rješenja 

Procjenjeni 

datum 

rješenja 

Datum 

rješenja 

24.01.2013 ivan 

23.01.2013 13.06.2013 ivan 

22.01.2013 LFINK eo_vrac 22.01.2013 07.02.2013 ivan 

22.01.2013 LFINK iz_bss_ff 22.01.2013 11.02.2013 ivan 

22.01.2013 LNABD ispisi NARul 31.01.2013 11.02.2013 glorija 

22.01.2013 WINTRAN udr_trn 22.01.2013 22.01.2013 04.02.2013 katja 

22.01.2013 LSLOD rekg_ji 22.01.2013 22.01.2013 08.04.2013 glorija 

22.01.2013 LWINFAU rucfil.jas 22.01.2013 22.01.2013 katja 



21.01.2013 LBASE 21.01.2013 23.01.2013 Glorija 

18.01.2013 EHPUR ZAHTJEV 19 01.01.2013 katja 



18.01.2013 EHPUR ZAHTJEV 16 01.01.2013 28.05.2013 katja 




Kontak 

osoba


Status: 

Ev. 

broj 

40764 12714 

40763 12714 

40762 12714 

40761 12714 

40760 12714 

40759 12714 

40758 12714 

40757 12714 

40756 12714 

40755 12714 

40752 12714 

40751 12714 

40749 12714 







Originalni 

Mjesto 


broj 


Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Čeka se 

pojašnjenje 

klijenta 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

40753 Riješen 18.01.2013 LCSBI bexweb 21.01.2013 Nada 

Martinović 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Očekivani 

datum 

rješenja 

Procjenjeni 

datum 

rješenja 

Datum 

rješenja 











40754 laus 40603 Riješen 18.01.2013 AFINK kontni plan 18.01.2013 Nada 

Martinović 






Kontak 

osoba


Status: 

Ev. 

broj 

40745 13053 

40725 13050 

40711 13049 

40689 13044 

40688 13047 

40652 13036 

40645 13035 






Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 


Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 


Isporučen - 

Korisnik 

potvrdio 

ispravnost 

18.01.2013 LROBD 18.01.2013 04.06.2013 Katja 


40727 13051 

40686 13046 

40666 13040 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

18.01.2013 WINTRAN 22.01.2013 22.01.2013 Katja 

18.01.2013 LBASE 20.01.2013 12.06.2013 Glorija 

17.01.2013 LWINFAU 18.01.2013 18.01.2013 Ivan 

17.01.2013 LWINFAU 16.01.2013 18.01.2013 Katja 

17.01.2013 LWINFAU 20.01.2013 13.06.2013 Ivan 


40681 13045 

40672 13041 

40665 13037 

40663 13039 


Originalni 

Mjesto 


broj 


Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 


Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Očekivani 

datum 

rješenja 

Procjenjeni 

datum 

rješenja 

Datum 

rješenja 

16.01.2013 LROBD 16.01.2013 16.01.2013 Glorija 



16.01.2013 LROBD 16.01.2013 18.01.2013 Glorija 

15.01.2013 LFINK 15.01.2013 18.02.2013 Glorija 


15.01.2013 EPNAB 16.01.2013 18.01.2013 Višnja 

40662 13038 Riješen 15.01.2013 EPNAB 22.01.2013 11.02.2013 Višnja 

15.01.2013 LZETT 16.01.2013 17.01.2013 Višnja 

15.01.2013 LTRAN 16.01.2013 31.01.2013 Višnja 



Kontak 

osoba


Status: 

Ev. 

broj 

40641 13034 

40629 13033 

40622 13032 

40621 13031 

40480 13020 

40476 13019 

40475 13018 

40469 13017 

40466 13016 







Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 




će se po 

drugom 


u 

14.01.2013 WINTRAN 16.01.2013 24.01.2013 Katja 


40603 

40594 13029 

40589 13028 

40582 13027 

40528 13026 

40522 13025 

40499 13022 


Originalni 

Mjesto 


broj 


Isporučen - 

Korisnik 

potvrdio 

ispravnost 



Čeka se 

pojašnjenje 

klijenta 






Isporučen - 

Korisnik 

potvrdio 

ispravnost 

14.01.2013 LWINFAU 

14.01.2013 WINTRAN 16.01.2013 15.01.2013 Katja 

11.01.2013 AFINK 

ruckat.jas- 

statusi 

kontrolni 

pregled 

financijskih 

izvještaja: 

konta i upute 

za generiranj 

Očekivani 

datum 

rješenja 

15.01.2013 15.01.2013 28.02.2013 glorija 

14.01.2013 LROBD 16.01.2013 16.01.2013 Katja 

14.01.2013 

Procjenjeni 

datum 

rješenja 

40496 13021 Riješen 08.01.2013 LZETT 15.01.2013 08.01.2013 

07.01.2013 LWINFAU 09.01.2013 08.01.2013 Katja 

07.01.2013 LWINFAU 07.01.2013 09.01.2013 Ivan 

07.01.2013 LROBD 07.01.2013 07.01.2013 Katja 

07.01.2013 LROBD 07.01.2013 07.01.2013 Katja 

07.01.2013 LROBD 07.01.2013 07.01.2013 Katja 

40458 13016 U rješavanju 04.01.2013 LKROP 15.01.2013 31.07.2013 

Datum 

rješenja 



Nada 

Martinović 

11.01.2013 LROBD 14.01.2013 14.01.2013 Katja 

11.01.2013 LWINFAU 14.01.2013 11.01.2013 11.02.2013 Katja 

10.01.2013 LWINFAU 11.01.2013 11.02.2013 Katja 

08.01.2013 LFINK 15.01.2013 11.02.2013 Višnja 

08.01.2013 LWINFAU 08.01.2013 11.02.2013 Ivan 

08.01.2013 LWINFAU 10.01.2013 09.01.2013 08.01.2013 Katja 


40497 13024 Riješen 08.01.2013 LKEVP prepod_jke 09.01.2013 12.03.2013 Višnja 

Kontak 

osoba 


Ivček 


Ivček


Status: 

Ev. 

broj 

40451 13015 

40448 13014 

40418 13008 

40414 13007 

40413 13006 

40411 13005 

40399 13004 

40395 13003 

40383 13002 

40375 13001 








će se po 

drugom 


u 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 


Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

Isporučen - 

Korisnik 

potvrdio 

ispravnost 

04.01.2013 WINTRAN 07.01.2013 04.01.2013 Katja Kraljev 

40446 13013 Riješen 04.01.2013 LTRAN 05.01.2013 04.01.2013 

40444 13012 

40431 13004 


40436 13010 Riješen 03.01.2013 EPNAB 

40435 13009 


Originalni 

Mjesto 


broj 





će se po 

drugom 


u 

04.01.2013 LKROP 07.01.2013 14.01.2013 

04.01.2013 LBASE 

03.01.2013 LBASE 

prot_fm stopa 

5 pdv 

ugovori 

bagatelna JN 

prot_fm - 

stopa 5 

Očekivani 

datum 

rješenja 

Procjenjeni 

datum 

rješenja 

Datum 

rješenja 


03.01.2013 EOBRRAC 03.01.2013 08.01.2013 Ivan 

03.01.2013 LBASE 08.01.2013 11.02.2013 Glorija 

03.01.2013 EHPUR 07.01.2013 11.01.2013 Katja 

02.01.2013 EOBRRAC 02.01.2013 04.01.2013 Ivan 

02.01.2013 EPNAB 07.01.2013 08.05.2013 Višnja 

02.01.2013 LKROP 07.01.2013 15.01.2013 Višnja 

02.01.2013 EHPUR 02.01.2013 11.01.2013 Višnja 

40371 12795 Riješen 02.01.2013 LFINK 31.01.2013 11.02.2013 Glorija 



Kontak 

osoba 


Ivček 

Ivan 

Poldrugač 

04.01.2013 07.01.2013 08.01.2013 glorija 

40443 13011 Riješen 04.01.2013 LROBD 04.01.2013 Katja Kraljev 

04.01.2013 04.01.2013 11.02.2013 višnja 


07.01.2013 07.01.2013 04.01.2013 kramer


Status: 







Korisnički zahtjev broj: 44018 

Originalni broj: 

Status zahtjeva: 

Klijent: 

HP Hrvatska Pošta 

Tip zahtjeva: 

Bug / Nepravilan rad 

Mjesto zahtjeva: 

Hitnost: 

Vrlo hitno 

Kontakt osoba: 

Ivan Poldrugač 

Opis zahtjeva: 

13523 

Isporučen-završen 

Datum i vrijeme upisa: 

29.07.2013 15:53 

Upisao: 

Boško Tokić 

Područje: 

LWINFAU 

Očekivani datum rješenja (klijent): 

29.07.2013 

Procijenjeni datum rješenja (LAUS CC): 

30.07.2013 

Kod ispisa fakture na produkciji (1100401317676) preko objekta Rucfak.jas, fakis.jas javlja se greška sa 

slike. 

( prilog ) 

Obrada korisničkog zahtjeva: 44018/1 Datum: 29.07.2013 

Ispravljena je greška koja se javljala kod ispisa fakture. 

Preuzmite novi WIN FAUS lib koji će biti dostupan u utorak 30/07/2013. 


Stranica: 32/1080




Status: Evidentiran zahtjev, Klijentu poslana ponuda / procjena - čeka se odgovor, Čeka se pojašnjenje 







Klijent: 



Izrada novog segmenta 


Hitnost: 

Vrlo hitno 


Glorija 


13522 

U rješavanju 


29.07.2013 09:29 

Upisao: 

Božo Mišeta 

Područje: 

LKEVP 


29.07.2013 


Molimo da žurno izvršite ispravak po našem zahtjevu od kako bi podaci za obračun plaće za radnika 18856 

za 07-2013 bili ispravni. 

Lp 

Na objektu erv_dol_jke Unos erv-a po vremenu dolaska i odlaska molimo da za radnika 18856 Kljančar 

Miljenko izvršite unos rada na dan 23.06.2013 (nedjelja) rad od 16:00 do 24:00 – po vrsti rada 1-RR 6 sati i 

3-RR 2 sata. 


Stranica: 33/1080











Klijent: 



Pitanje 


Hitnost: 

Vrlo hitno 


Katja Kraljev 


AFINK / APLAC 

13521 

U rješavanju 


29.07.2013 08:46 

Upisao: 

Boško Tokić 

Područje: 

APLAC 


29.07.2013 


napravljena je plaća za HPA za 07.2013. U zbrojnom nalogu (datoteka) u dijelu koji se odnosi na Poziv na 

broj odobrenja nema unešenih modela. Modeli su unešeni samo za doprinose, porez i prirez. Za obustave i 

plaću nisu te stoga zbrojni nalog neće biti ispravan. Molim uputu gdje i na koji način upisati te modele da se 

ubuduće ispravno pokazuju na zbrojnom nalogu. 

Zbrojni nalog (ispis na A4) greške su kako slijedi: 

a)kod poreza i prireza te obustava nema naziva i središte primatelja 

b)kod neto isplate nema središte primatelja 

c) kod svih naloga nema modela u pozivu na broj odobrenja 

d)Piše da je datum predaje na FINU 25.07.2013. iako je datum predaje stavljen 01.08.2013. 

U prilogu šaljem zbrojni nalog koji se učitava te ispis zbrojnog naloga. 


Stranica: 34/1080









Poštovani, 

podaci model i poziv na broj za isplatu plaće unose se za svaku pojedinu banku i način isplate (T,K,V) na 

objektu: 

Plaće-Osnovni šifarnici-Evidencija računa za isplatu, 

dok se za obustave ti podaci unose na objektu: 

Plaće-Obustave-Evidencija partnera po obustavama. 

Međutim ukoliko je u evidenciji obustava po djelatniku navedeno da se treba formirati pojedinačan a ne skupni 

virman onda se pozv na broj odobrenja uzima iz te evidencije po djelatniku. 

Što se tiče datuma vezanih uz zbrojni nalog prilikom njegaova kreiranja (ekran koji se dobije tipkom Obradi 

virmane na pregledu pripremljenih virmana) inicijalno se nudi današnji datum ali se svi datumi mogu prekucati na 

ekranu (datum plaćanja,kreiranja,predaje). 

Pozdrav 


Stranica: 35/1080











Klijent: 



Objašnjenja/podrška 


Hitnost: 

Vrlo hitno 


Katja Kraljev 


13520 

Riješen 


26.07.2013 10:55 

Upisao: 

Boško Tokić 

Područje: 

APLAC 


29.07.2013 


U Lausu 6 za HP Arhiv moram obračunati neke zaostake koji se odnose na period od 13.03.2013.- 

30.06.2013. godine. 

Te zaostatke bi htjela obračunati u jednom obračunu za koji sam stavila period obračuna 01.07.2013.- 

31.07.2013..Međutim, imam 2 radnice koje danas više nisu u radnom odnosu u HP Arhivu (jedna ima 

raskid u 6. mjesecu, a druga u 4. mjesecu) a imaju pravo na te zaostatke. 

Kada sam ih htjela unijeti u obračun program je javio da u navedenom periodu radnice nemaju aktivna 

rješenja i nije mi dao upis. 

Kada sam u otvaranju obračuna htjela promijeniti razdoblje na 13.06.-30.06.2013. program je rekao da je 

datumski period pogrešan. 

Dakle, u periodu može biti samo 1 mjesec. 

Molim uputu kako napraviti ovaj obračun. 

Napomena, obračun je otvoren na testnoj bazi. 


Poštovani, 

LAUS6 ima sustav kontrola vezanih za unos primanja i obračun tako da radnik mora imati aktivno rješenje za 

period obračuna.Stoga za isplatu zaostataka otvorite obračun za neki mjesec u kojemu svi ti radnici imaju 

aktivno rješenje, ili napravite više obračuna. 

Pozdrav 


Stranica: 36/1080











Klijent: 



Pitanje 


Hitnost: 

Vrlo hitno 


Katja Kraljev 


13519 

Riješen 


26.07.2013 10:49 

Upisao: 

Boško Tokić 

Područje: 

APLAC 


29.07.2013 


Na kojem ekranu se u Lausu 6 mogu isprintati potpisne liste? Iste su potrebne zbog toga što imamo 

zakonsku obvezu imati papir na kojem se osoba potpisala da je dobila isplatnu listu od plaće i ostalih 

primanja. 


Poštovani, 

na objektu Obračun dohotka je potrebno označiti obračun pa na Ostalim poslovima izabrati Pregled obračuna. 

Na izabranom pregledu imate tipku Ispis na kojoj se nalaze ispisi vrećica i potpisne liste. Imate dva načina 

listanja potipisnih lista: 

- Lista radnika za obračun (za sve radnike) 

- Lista radnika za obračun (osobe bez e-maila) - svi radnici kojima se vrećice ne šalju putem e-maila nego se 

dostavljaju isprintane platne vrećice. 

Srdačan pozdrav. 


Stranica: 37/1080











Klijent: 





Hitnost: 

Vrlo hitno 


Katja Kraljev 


13518 

Riješen 


25.07.2013 11:49 

Upisao: 

Boško Tokić 

Područje: 

ABASE 


27.07.2013 


Na testnoj bazi je ažurirano polje naziv za firmu “HPPROD” u HP PRodukcija d.o.o., međutim na IRA se u 

podnožju ispisuje HP Produkcija d.o.o.. ( sa dvije točke). Molim ispravak. 

( prilog ) 


Poštovani, 

Ispravljen je prikaz podataka za firmu na izlaznoj fakturi. 

Biti će vam dostupno sa novom verzijom. 

Lijepi pozdrav 


Stranica: 38/1080











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13517 

Riješen 


25.07.2013 09:16 

Upisao: 

Božo Mišeta 

Područje: 

LKROP 


27.07.2013 


Dobili smo slijedeće upozorenje od banke PBZ d.d., a odnosi se na novi format datoteke koji se šalje u 

banke. 

Molim da ga ispravite u skladu s pravilima novog formata. 

“Greška je u slogu tipa 301, red.br.6 S301IZNNALUK (ukupan iznos naloga), format je 20 numeričkih 

znakova. 

Neispravno (org.datoteka) imala je 19 numeričkih znakova : 

0000000000000053289 

Ispravno (potrebno dodat jednu nulu da bi bilo 20 znakova) 

00000000000000053289 

Isto primjeniti i na drugu datoteku.” 


Stranica: 39/1080









Poštovani 

ne možemo simulirati navedenu grešku.Naime polje za ukupan iznos naloga je dugo 20 znakova sa vodećim 

nulama.U slučaju da nije tako sve banke bi dale isto upozorenje jer se ista datoteka koristi za sve banke.Možete 

li nam dostaviti primjer neispravne datoteke.Ukoliko je nemate, dostavite nam novu datoteku na provjeru prije 

idućeg slanja na PBZ banku. 



Dodatno pitanje 

PBZ banka Vam je napisala: 

Greška je u slogu tipa 301, red.br.6 S301IZNNALUK (ukupan iznos naloga) 

Slog tipa 301 je drugi redak u datoteci.Nije nam jasno što im znači red. br. 6 

Pozdrav 


Ispravljen je podatak ukupan iznos na nalozima za isplatu plaće u retku 301 u datoteci za banke u novom 

formatu.Greška se pojavila samo u slučajevima kada je ukupna isplata na pojedinu banku za sve radnike u 

datoteci manja od 1000 kn kao što je u slučaju datoteke iz priloga. 

Potrebno za instalaciju i testiranje: 

krop lib od 29.07.2013 


Stranica: 40/1080











Klijent: 



Intervencija na podacima/bazi 


Hitnost: 

Vrlo hitno 


Ivan 


13516 

Evidentiran zahtjev 


25.07.2013 07:18 

Upisao: 

Božo Mišeta 

Područje: 

SYSING 


26.07.2013 


Potrebno je napraviti migraciju Laus v6 aplikacije Argosy za HP produkciju i HP arhivu na novi server 

definiran od strane HP sistemske podrške. 


Stranica: 41/1080











Klijent: 





Hitnost: 

Vrlo hitno 


Katja Kraljev 


13515 

Subject: Laus 6 - Neispravan format RSm datoteke 

From: Katja Kraljev 

Čeka se pojašnjenje klijenta 


24.07.2013 14:51 

Upisao: 

Boško Tokić 

Područje: 

APLAC 


26.07.2013 

Srdačan pozdrav, Katja Kraljev, Odjel za implementaciju ERP rješenja 



Stranica: 42/1080









Poštovani, 

datoteku koja nastaje u Argosy sustavu REGOS.txt ne učitavate u e-Regos već ju je potrebno snimiti na 

računalo i obraditi putem Regos aplikacije koja mora biti instalirana na vašem računalu.Obradom nastaje 

datoteka REGOS.RM0 koja se onda učitava u e-Regos aplikaciju. 

Pozdrav 


Poštovani, 

u prilogu su upute za obradu datoteke REGOS.txt kroz REGOS aplikaciju prije učitavanja u e- 

Regos.Napominjemo da je LAUS support u tijeku obuke i testiranja upozorio korisnike Argosy sustava da je 

datoteku dobivenu u Argosy sustavu potrebno obraditi prije učitavanja u e-Regos te da je pri tome naglašenja 

potreba testiranja i ponuđena obuka i pomoć kod navedenog postupka. 



Kako je navedeno u našim uputama u aplikacijske parametre dodajete 4 poslodavca - obveznika jer imate dvije 

firme a posebno se upisuje poslodavac za isplatu plaće a posebno za isplatu drugog dohotka.Obzirom da se na 

ekranu odabire vrsta obveznika pravna osoba ili isplatitelj drugog dohotka tj. firma identifikacijski broj obveznika 

je OIB firme kao i adresa i ostali podaci u zaglavlju ekrana. 

Greške koje javlja aplikacija najćešće su uzrokovane neispravno popunjenim podacima. 

Naime iz slike ne znamo da li ste odabrali dobrog obveznika tj. odabrali ste poslodavca sa rednim brojem 2 a da 

li je to HP ARHIV sa vrstom obveznika 01 za isplatu plaće a ne drugog dohotka sa vrstom obveznika 03 pa 

provjerite prvo to. 

Zatim napisali ste mjesec isplate 08 a datum slanja je 25/07/2013.Obzirom da se RSM obrazac ne predaje 

unaprijed pa shodno tome upisani podaci nisu ispravni.Nadam se da je to uzrok greške te da će nakon ispravka 

podataka proći učitavanje. 

Pozdrav 


Poštovani, 

molimo Vas informaciju da li ste nakon reinstalacije Regos aplikacije uspjeli dobiti REGOS.RM0 datoteku kako bi 

mogli zaključiti zahtjev. 



Stranica: 43/1080











Klijent: 





Hitnost: 

Vrlo hitno 


Katja Kraljev 


13514 

Riješen 


24.07.2013 13:29 

Upisao: 

Boško Tokić 

Područje: 

APLAC 


25.07.2013 

Poštovani! Molim Vas da nam što prije odgovorite na upit iz priloga. 



HP Arhiv nam je dostavio odluku o uvećanju osnovne plaće za minuli rad te isplate prehrane. Obzirom da je 

po odluci prehrana definirana u bruto iznosu i isplaćuje se samo za dane nazočnosti na radu koju formulu 

trebamo unijeti kod definiranja šifre? 

( prilog ) 


Stranica: 44/1080









Poštovani, 

da bi se osnovna plaća uvećala za minuli rad potrebno je na uputama svih primanja koja se obračunavaju kao 

redovan rad (RR00, PD00, GO00, DP00) označiti indikator Obračun minulog rada. 

Što se tiče Prehrane potrebno je definirati novo primanje s formulom 39 a u polje Iznos evidentirati mjesečni 

bruto iznos za isplatu. 

Novo primanje je potrebno vezati na radne odnose (objekt Veza vrsta primanja - Radni odnos). 

Na uputama za prijenos Vrsta rada u šifre Primanja je potrebno primanje RR00 vezati i na novo primanje za 

Prehranu. Tako će se u obračun prebaciti samo sati prisutnosti a prema formuli 39 obračunati samo bruto prema 

tim satima. 



Poštovani, 

šaljemo Vam detaljniju uputu za točku 3. 

Pod Osnovnim šifarnicima segmenta Evidencija radnog vremena, kroz objekt Veza Vrste rada s Vrstom 

Primanja potrebno je upisati još jednu uputu za prijenos podataka: 

vrsta rada R, vrsta primanja - novu koju ste definirali, indikator sati F, indikator dana R. 



Stranica: 45/1080











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13513 

U rješavanju 


24.07.2013 11:39 

Upisao: 

Božo Mišeta 

Područje: 

LTRAN 


28.07.2013 


Na objektu pmac_jtr kod prijenosa stanja depoa na dan omogućiti zadavanje perioda koji će se prenositi, 

jer sada moramo prenositi dan po dan, a promjene dolaze za datume koji su mlađi od trenutnog datuma i 

po mjesec i pol. 


Poštovani, 

navedeni zahtjev smatramo adaptivnim, jer se traži proširenje funkcionalnosti (do sada dan po dan, a traži se za 

period) 

S štovanjem 


Stranica: 46/1080











Klijent: 



Izmjena u postojećem programu 


Hitnost: 

Vrlo hitno 


Katja Kraljev 


13512 

Riješen 


24.07.2013 11:31 

Upisao: 

Boško Tokić 

Područje: 

ABASE 


26.07.2013 


Kako nam se, u podnožju dokumenta IRA, uz poslovnu banku: Hrvatska poštanska banka d.d. Zagreb , 

sjedište poslovne banke ne ispisuje (Zagreb), molim da se taj podatak 'čita' iz polja 'Grad'. 

Privremeno smo u nazivu posl.partnera 613853 Hrvatska poštanska banka d.d. dodali Zagreb kako bi se u 

podnožju dokumenta, uz naziv poslovne banke, ispisivalo i sjedište. 

( prilog ) 


Poštovani, 

Na ispisu izlaznog računa postavljeno je da se grad banke čita iz stalne adrese partnera (banke). 

Novu verziju ćete dobiti u toku dana. 



Stranica: 47/1080











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13511 



24.07.2013 10:22 

Upisao: 

Božo Mišeta 

Područje: 

LKROP 


26.07.2013 


Podaci na OSB LISTA IZ ARHIVA (aosb_fk) su u potpunosti neispravni. Na kraju liste je podatak o broju 

radnika/sati 304.787. 

Molim što hitnije ispravite navedenu listu sa ispravnim podacima. 


Poštovani, 

možete li nam poslati primjer liste za isti obračun sa ispravnim podacima formiranu iz obračuna prije 

arhiviranja ,vjerovatno je imate izlistanu. 

Pozdrav 


Poštovani! 

Na žalost, nemamo tu zadnju listu izlistanu prije arhiviranja. Šaljemo vam primjere OSB listi (ispravnu i 

neispravnu) od prethodnog mjeseca, ako će vam to pomoći. 

Lp, 

Katja 


Preuzmite krop lib koji je već na internetu. 

Ispravljena je OSB lista iz arhiva na način da kao i ona iz obračuna uključuje organizacije grupe koje počinju sa 

PL.Do sad nije imala taj uvjet pa su se podaci multiplicirali jer su uključivali sve org. grupe. 


Stranica: 48/1080











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13510 



24.07.2013 09:26 

Upisao: 

Božo Mišeta 

Područje: 

LKEVP 


26.07.2013 


Kontrolom podataka u programu ERV-a uočeno je da pojedini radnici na objektu erv_dol_jke imaju ispravno 

iskazane sate DONO na početku mjeseca 07-2013, no na kontrolnoj listi objekt prsdo_jke POPIS 

ODRAĐENO RAZLIČITO OD MJESEČNOG FONDA SATI – ispis na F4 DONO ti radnici nisu prikazani. 

Radi se o kontroli donosa u 07/2013. 

Napominjem: kontrolirala sam prethodni mjesec 06-2013 i ti isti radnici su imali također sate DONO koji su 

dobro iskazani na oba objekta. 

Molimo obrazloženje zašto se dolje navedeni radnici ne prikazuju na objektu prsdo_jke za 07-2013. 


Stranica: 49/1080











Klijent: 





Hitnost: 

Vrlo hitno 


Katja Kraljev 


13509 

Riješen 


24.07.2013 08:27 

Upisao: 

Boško Tokić 

Područje: 

ABASE 


26.07.2013 

Ne može se unijeti IBAN za poslovnog partnera. Molimo da to ispravite. ... 

( prilog ) 



Poštovani, 

Dozvoljen je unos IBAN-a za poslovnog partnera. 



Stranica: 50/1080











Klijent: 





Hitnost: 

Vrlo hitno 


Ivan 

13508 



23.07.2013 14:56 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


01.08.2013 


01.08.2013 


Stranica: 51/1080









Unificirati izgled računa za sve fakture za poslovne korisnike sukladno primjeru u privitku preko objekata 

fakis.jas, rucfak.jas. 

Pojašnjenja: 

1) Datum isporuke 

Umjesto dosadašnje labele 'Obračunsko razdoblje' potrebno je upisati labelu 'Datum isporuke' 

2) Jedinična neto cijena se treba iskazati kao ukupan iznos bez PDV-a/količina analogno izračunu koji se 

sada primjenjuje kod izračuna bruto jedinične cijene. 

3) napomene o osnovi za oslobađanje od poreza treba primijeniti prema slijedećoj tablici: 

Tarifna grupaPripadajući tekstUsluga 

3Oslobođeno poreza temeljem čl.39, st.1, t. a) Zakona o PDV-uobuhvaća sve univerzalne poštanske 

usluge, odnosno stavke cjenika koje sada imaju tarifnu grupu 3, a šifra usluge im počinje brojem 2 - 35 

4Oslobođeno poreza temeljem čl. 33, st. 3 Zakona o PDV-uostaje isto 

5Oslobođeno poreza temeljem čl. 45, st.1, t.1 Zakona o PDV-u (isporuke izvan EU), odnosno čl. 41, st. 1, t. 

a) Zakona o PDV-u (isporuke unutar EU) ostaje isto 

6Oslobođeno poreza temeljem čl. 41, st.7 Pravilnika o PDV-u ostaje isto 

7Oslobođeno poreza temeljem čl. 25 Pravilnika o PDV-u ostaje isto 

8Ne obračunava se PDV temeljem čl. 135. Zakona o PDV-u ostaje isto 

9Oslobođeno poreza temeljem čl.40, st.1, t. a) Zakona o PDV-uusluge koje sada imaju tarifnu grupu 3, a 

šifra usluge im počinje s 445 

10Oslobođeno poreza temeljem čl. 40, st.1, t. d) Zakona o PDV-uusluge koje sada imaju tarifnu grupu 3, a 


11Oslobođeno poreza temeljem čl. 40, st. 1, t. e) Zakona o PDV-uusluge koje sada imaju tarifnu grupu 3, a 


12Oslobođeno poreza temeljem čl. 40, st. 1, t. h) Zakona o PDV-uusluge koje sada imaju tarifnu grupu 3, a 

šifra usluge im počinje s 36 i 441 i usluga 9181 

13Oslobođeno poreza temeljem čl. 40, st. 1, t. l) Zakona o PDV-uusluga 9100 

4) Podaci o temeljnom kapitalu i sl. se trebaju ispisivati na svakoj stranici. 


Stranica: 52/1080









Poštovani, 

1) Unificirati izgled računa za sve fakture za poslovne korisnike sukladno primjeru u privitku preko objekata 

fakis.jas, rucfak.jas. 

- zahtjev se odnosi se na masovne i ručne fakture koje nisu u valuti tj. nije filatelija niti računi u valuti po 

zahtjevu HP13505 ? 

- ugovor NE MORA biti N-neto princip a cijan na ispisu MORA biti neto cijena : 

za princip obračuna B-bruto i N-neto se ispisuje neto cijena . Za princip obračuna B-bruto neto JC se računa 

prema poslanom pod 2) ? 

Jedinična neto cijena se treba iskazati kao ukupan iznos bez PDV-a/količina analogno izračunu koji se sada 

primjenjuje kod izračuna bruto jedinične cijene. 

2) vrij_neto/kolusl= jedcijn ? 

3) napomene o osnovi za oslobađanje od poreza treba primijeniti prema tablici koju ste poslali . 

Predlažemo širenje tablice lm_usl_dod poljem za unos napomene koja se odnosi na Oslobođenje : za svaku 

uslugu njena napomena za oslobođenje jer se unutar iste tarifne grupe različit osnov 

Onda se kod ispisa ispisuju sve distinct napomne vezane za usluge iz računa . 

Druga opcija je hardcode jer lm_pdv nije pogodna za ovo . 

Ptanje : za napomenu kod tarifna grupa 5 : 

Oslobođeno poreza temeljem čl. 45, st.1, t.1 Zakona o PDV-u (isporuke izvan EU), odnosno čl. 41, st. 1, t. a) 

Zakona o PDV-u (isporuke unutar EU) 

Treba li ili ne ispisivati napomenu samo ovu ako je isporuka izvan RH (ino kupac) ? 

ili je dovoljno ispisati samo jednu od : 

Oslobođeno poreza temeljem čl. 45, st.1, t.1 Zakona o PDV-u (isporuke izvan EU) 

čl. 41, st. 1, t. a) Zakona o PDV-u (isporuke unutar EU) 

Pitanje :Ako je ino kupac unutar eu bez vat broj i part_pdv=D ispisuju se napomene kao da je u RH ? 

4) Podaci o temeljnom kapitalu i sl. se trebaju ispisivati na svakoj stranici. 

--- memorandum je bi prije samo na zadnjoj a sad na svakoj stranici ? 

-- Mislimo da to nije potrebno trošenje papira a zauzima i dosta mjesta. 

Stavke se ispisuju u 2 reda pa više od 5 stavki nestane . 

Predlažemo : na prvu stranicu fakture ispisati zaglavlje kao i dosad, sumarne iznose , mjesta potpisa i podatke s 

memoranduma . 

na sve ostale stranice ispisivati stavke 

Napomena: lm_fak_stav tablica , kao i lm_kat_stav te lm_fil stav zbog zahtjevane forma ispisa bit će proširene 

potrebnim neto* poljima 


Stranica: 53/1080











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13507 

Riješen 


23.07.2013 14:01 

Upisao: 

Božo Mišeta 

Područje: 

LROBD 


25.07.2013 


Kod automatskog knjiženja dokumenata iz poštanskog ureda u nalogu 136P0199 pojavljuje se razlika na 

dokumentu RC8 Promjena cijena za PU, u iznosu od 4.920,00 kuna. 

Molimo za provjeru i rješenje nastale razlike. 


Razlika na nalogu 136P0199 od 4920,00 kuna nastaje zbog dokumenta RC8 NIVELACIJA CIJENA NA PU 

35075-X13-00139 datuma dokumenta 02/07/2013 na artiklima 322977 kojem je iz mips-a pridružen cjenik 

1300378 koji ne važi na 02/027/2013 nego je trebao biti pridružen 1300401. 

Potrebno je ispraviti iznose u gore navedenom nalogu ili da se ažurira aktivni cjenik u gore navedenom 

dokumentu te ponovno pusti priprema za knjiženje te proknjiži u glavnu knjigu (prethodno potrebno izbrisati iz 

glavne knjige dokument i nalog iz pripreme). 


Stranica: 54/1080











Klijent: 





Hitnost: 

Vrlo hitno 


Ivan 


13506 



23.07.2013 13:33 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


24.07.2013 

Na odobrenjima ODO 24085-013-05810 i ODO 24085-013-05811 

je neispravno iskazan iznos porezne osnovice i poreza : 



Stranica: 55/1080











Klijent: 





Hitnost: 

Vrlo hitno 


Ivan 

13505 



23.07.2013 12:42 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


31.07.2013 



Stranica: 56/1080









Molim da nam dostavite rok za zahtjev iz priloga. 

Lp, 

1. 

Unos ugovora o poslovnoj suradnji s kupcem u EU – transakcije unutar EU – izrada fakture 

I 

Na objektu ugovor1_fas Unos ugovora s kupcem: 

1. Dodati novo polje s indikatorom „DRŽAVA“ s nazivom države npr. HRVATSKA, SLOVENIJA, 

MAĐARSKA… koje postoji u bazi partnera. Polje treba biti obavezno za unos i imati funkciju pregleda 

ugovora s drugim državama. 

2. Dodati novo polje za unos VAT no. (PDV broj domicilne države) ispod polja KUPAC 

- 20 slovnih mjesta 

- nije obavezan unos (neki kupci imaju VAT no.,a neki nemaju) 

3. Ako kupac nije porezni obveznik u sustavu PDV-a u drugoj državi, nema važeći VAT no. , oznaka za 

obračun PDV-a je kao i za unutarnji promet „D-plaća PDV“ (polje „PDV“) i računa se kao za unutarnji 

promet – za usluge s PDV-om 

-za univerzalne poštanske usluge (bez PDV-a) PDV se ne obračunava ?????? tretman kao za unutrašnji 

promet ???? 

4. Ako je kupac porezni obveznik u sustavu PDV-a u drugoj državi, ima važeći VAT no. : 

- u polju „PDV“ otvoriti novu oznaku „P - prijenos porezne obveze“ 

- za usluge s PDV-om u važećem Cjeniku - ne iskazuje se obračun PDV-a na računu 

- za univerzalne poštanske usluge (bez PDV-a) u važećem Cjeniku – ne iskazuje se obračun PDV-a na 

računu 

- uz oznaku „P-prijenos porezne obveze“ na izlaznim računima treba se automatski ispisivati nova 

napomena „Prijenos porezne obveze (reverse charge) temeljem čl. 17. St. 1 Zakona o PDV-u.“ 

5. U polju „VALUTA“ upisivati će se oznaka valute koja treba imati funkciju preračunavanja kunskih iznosa 

u zadanu valutu (primjeri računa u privitku) 

Npr. ako upišemo „978“ EURO na fakturi će uz kunske iznose biti preračunati iznosi u EUR-ima. 

Preračunavanje iznosa u drugu valutu, po srednjem tečaju HNB-a NA DAN IZRADE fakture (jer ne 

možemo znati tečaj unaprijed). 

II 

Izrada fakture za EU 

1. Primjeri računa s preračunatim iznosima u drugu valutu prema uvjetima upisanim u ugovoru, nalaze se u 

privitku: 

a) račun s PDV-om 


Stranica: 57/1080







b) račun -završen, bez iskazanog Isporučen PDV-a - Korisnik potvrdio ispravnost 

2) polje/indikator „VALUTA“ treba značiti ispis računa u ranije zadanoj valuti upisanoj u ugovoru te je 

potrebno dodati na: 

- faktN.jas - Fakturiranje poštanskih usluga (uz polje „način plaćanja“ ) 

- fakhp.jas – Fakturiranje hpeksres usluga (uz polje „način plaćanja“ ) 

- fakpl.jas – Fakturiranje platnog prometa (uz polje „način plaćanja“ ) 

- spmt.jas – Rekapitulacija po mjestima troška 

- rekr.fas - Rekapitulacija izdanih računa kupcima 

- rucfak.jas – Pregled i ručni unos faktura (kod uvjeta pregleda i kod unosa ili izmjene) 

Račun i rekapitulacija po mjestima troška,s kunskim i preračunatim iznosima, treba se ispisivati na 

računima na rucfak.jas, fakis.jas i spmt.jas. 

Ispis rekapitulacija je potrebno prilagoditi na pisač i u excel-u: 

-Ispis na pisač - iza stupca „Ukupno“ dodati stupac „Ukupno ***“ (*** znači slovnu oznaku valute npr. EUR) 

-Ispis u excel-u – Ispis specifikacije u excel-u – dodati stupac „Ukupno***“ (s slovnom oznakom valute 

zadane u ugovoru ili po kojoj je preračunata faktura ) uz ukupno u kunama. 

KoličinaRabatNeto iznosUkupnoUkupno 

EUR 

330,00198,00 kn247,50 kn 

210,00126,00 kn157,50 kn 

3) Otvoriti će se nove vrste dokumenata/faktura: 

FPM- faktura za poštanske usluge - međunarodna 

FHM-faktura za hpekspres usluge – međunarodna 

Vezani dokumenti za izradu faktura su radni nalozi RNP-FPM i RNH-FHM. 

Vrste usluga ostaju kao i do sada POS-za poštanske usluge (RNP-FPM) i HPX-za hpekspres usluge (RNH 

-FHM). 

Napraviti će se veze za knjiženje. 

Fakture će se automatski knjižiti po modelu kunskih izlaznih faktura na Konta 7***-prihod, 2400-porez, a 

potraživanja na konto 121100 – Potraživanja od inozemnih kupaca te se knjiži I iznos u kunama I u valuti. 

Uplate će se moći knjižiti automatski uz uvjet ispravno upisanog poziva na broj. 

Računi izdani kupcima unutar EU evidentirati će se u protokolu 2 – devizni izlazni računi. Time je 

omogućena evidencija iznosa u stranoj valuti (koja trenutno nije moguća u protokolu =). 

Prilog: ispis_faktura 


Stranica: 58/1080









Poštovani, 

Radi procjene molimo odgovor na pitanja : 

1. Otkud se uzimaju neto cijene tj. cijene bez PDV-a u kunama obzirom da ih je obvezno iskazati na računu 

( ugovor treba biti po N-neto principu) 

a) upisat će ih u s ugovor : a1) lm_rab_ug ili a2) lm_ugv_stav 

b) bit će cijene u prometu (lm_nalog) 

c) bit će cijene u cjeniku (lm_usluga_cij) 

d) program ih terba izračunati iz prometa po formuli koju će dostaviti HP 

Potrebno definirati za svaki slučaj fakturiranja : 

- faktN.jas - Fakturiranje poštanskih usluga : 

- fakhp.jas -- Fakturiranje hpeksres usluga : 

- fakpl.jas -- Fakturiranje platnog prometa : 

- rucfak.jas -- Pregled i ručni unos faktura (kod uvjeta pregleda i kod unosa ili izmjene) 

2. Po kojem redosljedu se gledaju cijene kod automatskog fakturiranja (neto) 

1. lm_rab_ug 

2. lm_ugv_stav 

3. lm_usluga_cij 

4. lm_nalog 

Sada program automatskog fakturiranja poštanskih usluga prvo gleda lm_rab_ug pa lm_ugv_stav. Ako nema u 

te dvije tablice tada taj nalog niti ne ulazi u fakturu. 

3. Ovisi li redoslijed traženja cijene o tome po kojem principu se radi račun (B-bruto ili N-neto ? 

4. Prema zahtjevu vezanom za unificirani izgled računa tj.ispis ( HP 13508) neovisno o principu obračuna 

Bruto/Neto ispisana faktura na sebi treba imati iskazanu neto cijenu ? 

Drugim riječima , i za princip obračuna B-bruto i N-neto na ispisu se prikazuje neto cijena . 

-- Za princip obračuna B-bruto neto JC se računa prema : 

Jedinična neto cijena se treba iskazati kao ukupan iznos bez PDV-a/količina analogno izračunu koji se sada 

primjenjuje kod izračuna bruto jedinične cijene. 

U prilogu su i komentari (crveno) na pojedine točke zahtjeva vezano za ugovore . 

Molim stav vezano za navedeno u prilogu . 


Stranica: 59/1080











Klijent: 



Izmjena na podacima/bazi - uslijed 

greške u aplikaciji 


bilanca 

Hitnost: 

Vrlo hitno 


dugan 


-- bez službenog HP broja zahtjeva 

-------- Original Message -------- 

Subject: bilanca se ne zatvara 

Date: Fri, 19 Jul 2013 12:06:16 +0000 

From: Martina Dugan 

To: Dajana Lekic 

Isporučen - Korisnik potvrdio ispravnost 


23.07.2013 09:52 

Upisao: 

Dajana Lekić 

Područje: 

LFINK 

Poštovana možete me nazvati (hitno) – 6/2013 se ne zatvara 


19.07.2013 


23.07.2013 


Stranica: 60/1080











Klijent: 





Hitnost: 

Vrlo hitno 


Ivan 


13504 



23.07.2013 10:50 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


01.08.2013 


Potrebne izmjene na org.jedinici 46307-GRUPA POSLOVA FAKTURIRANJA u svrhu prilagodbe izgleda 

računa temeljem novog Pravilnika o PDV-u od 01.07.2013: 

-aplikativne promjene primijeniti kod dokumenata sa oznakom vrste:RUF i ODO 

-aplikativne promjene provesti na objektima: ugovor.jas/rucfak.jas/rucfakd.jas/ 

fakot.jas/faksto.jas 

Kod ručnog unosa faktura skinuti kontrolu za fakture koje se izrađuju iz ugovora koji imaju INDIKATOR 

OBRAČUNA postavljen na 'N' i omogućiti izradu faktura bez obzira što u stavkama tih ugovora cijena nije 

iskazana u točno određenom iznosu već ima samo oznaku TIP CIJENE-N. 


Stranica: 61/1080











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13503 

U rješavanju 


23.07.2013 09:52 

Upisao: 

Božo Mišeta 

Područje: 

LNABD 


25.07.2013 


Na objektu NRDul_jd NARUDŽBA DOBAVLJAČU omogućiti uvid u stanje zaliha naručene robe na način da 

se kolona Nab.vrij. zamjenjuje kolonom: Stanje u depou – uzima količinu robe koja je na stanju u depou koji 

naručuje robu (šifra depoa koji naručuje robu-primjer: Stanje u 35358) i kolona Vrijednost zamjenjuje 

kolonom: Stanje robe u ostalim depoima (zbraja količinu robe u svim depoima na nivou HP-a osim količinu 

robe u depou koji naručuje robu). 

Navedena stanja vidljiva su samo na ekranu, a kod ispisa u excel (document za dobavljača) navedena 

stanja nisu vidljiva. 


Stranica: 62/1080











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13502 



22.07.2013 10:24 

Upisao: 

Božo Mišeta 

Područje: 

EPNAB 


24.07.2013 


Potrebno je spis HP-10/2/1-007680/13 „otključati“, tj. vratiti u status Nabava u tijeku jer je referent zaboravio 

neke stvari upisati… 


Poštovani, molimo pristup na produkciju za Tvrtka Matoševića. 

Pozdrav 


Poštovani, 

Spis u postupku nabave HP-10/2/1-007680/13 je vraćen u status Nabava u tijeku. Molim potvrdu zatvaranja 

zahtjeva. 

Lp, 


Stranica: 63/1080











Klijent: 



Pitanje 


Hitnost: 

Vrlo hitno 


Katja 


13501 



22.07.2013 09:36 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


22.07.2013 


Molim vas da nam javite da li dokumenti RP3 (primka od dobavljača) i RD3 (povrat dobavljaču) ulaze u 

obračun komisijske robe? 


Stranica: 64/1080











Klijent: 





Hitnost: 

Vrlo hitno 


Katja Kraljev 


13496 

Zatvoren-dupli zahtjev 


22.07.2013 09:29 

Upisao: 

Boško Tokić 

Područje: 

APLAC 


19.07.2013 


Poštovani, Molim hitno rješavanje zahtjeva. 

S poštovanjem, Renata Basrek, Voditelj odjela za implementaciju ERP rješenja, Služba za razvoj i 

implementaciju IT rješenja 

Obavještavam Vas da je kod obračuna dara u naravi (HPPRODUKCIJA) obračunat i doprinos za 

zdravstvenu zaštitu u inozemstvu iako nije bila unesena ta šifra primanja (nema je ni na popisu primanja u 

obračunu). 

Dakle, sustav je to unio automatski. Obzirom da je to pogrešno molim da se navedeno što hitnije ispravi. 


Stranica: 65/1080











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13500 



19.07.2013 11:40 

Upisao: 

Božo Mišeta 

Područje: 

LROBD 


19.07.2013 


Aortiman 000079 je dezaktiviran (u status je 3). U njemu su ostala 6 artikla (322270, 320698, 322272, 

321742, 320973, 322269) koja su u status 2 (aktivna su). 

U aplikaciji ne postoji mogućnost dezaktiviranja artikala (koji su u status 2), već samo brisanje ??? 

Kad korisnik pobriše stavke asortimana (nikad se ne dezaktiviraju) I ta akcija se onda ne prenese u 

mips_laus bazu pa imamo situaciju da u mips_laus bazi bude aktivan jedan artikl u dva asortimana što ne 

može biti. 

Molim Vas da se hitno ugradi kontrola da se ne može deaktivirati asortiman a da stavke ostanu aktivne!!! 


Stranica: 66/1080









Poštovana, 

Aortiman 000079 je dezaktiviran (u status je 3). U njemu su ostala 6 artikla (322270, 320698, 322272, 321742, 

320973, 322269) koja su u status 2 (aktivna su). 

Odgovor: Točno, postoje stavke koje su u statusu 2. U toku je analiza, javit ćemo kad ustanovimo razlog i 

napraviti izmjenu u programu ako je to razlog. 

Zbog hitnosti možete li kroz bazu postojeće stavke prebaciti iz statusa 2 u 3 ili da to mi napravimo. 

U aplikaciji ne postoji mogućnost dezaktiviranja artikala (koji su u status 2), već samo brisanje ??? 

Odgovor: u aplikaciji nije moguće niti brisanje, niti izmjena stavaka koje su u asortimanima koji su u statusu 

različitom od 1!!!! 

Kad korisnik pobriše stavke asortimana (nikad se ne dezaktiviraju) I ta akcija se onda ne prenese u mips_laus 

bazu pa imamo situaciju da u mips_laus bazi bude aktivan jedan artikl u dva asortimana što ne može biti. 

Odgovor: Korisnik nemože obrisati stavke, i nastavak ove tvrdnje je netočan (ili je tvrdnja vjerojatno neprecizna) 

Molim Vas da se hitno ugradi kontrola da se ne može deaktivirati asortiman a da stavke ostanu aktivne!!! 

Odgovor: U radu 


Asortiman 000079 je dezaktiviran (u status je 3). U njemu su ostala 6 artikla (322270, 320698, 322272, 321742, 

320973, 322269) koja su u status 2 (aktivna su) te su dezaktivirana kroz produkcijsku bazu odnsono prebačena 

u status 3 i prijenosom iz laus ->mips će biti ažurirano u mips bazi. 

Basd lib sa procedurom koja izbjegava ponavljanje ove greške isporučen je na tesnu bazu. 


Asortiman 000096 je dezaktiviran sa svojim stavkama. 

Nije potrebno preuzimati libove. 


Asortiman 000096 je dezaktiviran sa svojim stavkama. 


Stranica: 67/1080











Klijent: 





klase,artikli 

Hitnost: 

Vrlo hitno 


katja 


13499 



18.07.2013 08:30 

Upisao: 

Dajana Lekić 

Područje: 

LROBD 


18.07.2013 


18.07.2013 

Potrebno je jednokratno napraviti update kroz bazu (upisati slog sa akcija=I izmjena gdje je bilo zadnji sa I 

ili U, odnosno sa akcija=D ,gdje je bilo D, na tablicama 

artikli, 

klasa, 

kako bi se prenijeli artikli sa klasom prije 22.4.2013.g. 

-- veza zahtjev : 

HP 13234 .MIPS baza : prijenos artikala proširen sa klasa : artikli.klasa je popunjena istim podatkom kao i 

u LAUS baza art.klasa 

prenosi se i šifarnik klasa (klasa like 6 - roba 

Nedostaju klase na artiklima prenesenim prije ovih izmjena te ranije unesene klase u šifarniku klasa prije 

postavljanja trigera (inicijalno punjenje ) 


Stranica: 68/1080









Poštovani, 

vezano za : 

Potrebno je u tablicu klase u MIPS bazi insertirati kroz bazu za svaku klasu koja ne postoji u njoj sa akcija=U a 

postoji u šifarniku klasa u LAUS bazi i počinje sa 6 upisati slog sa akcija=U-upis te ubaciti slog rednog broja 

prijenosa u tablicu ac_prijenos 

napravljena je provjra i priprema sql-ova za inicijalni laod klasa . 

Nije trebalo ništa ubacivati u mips_laus@mips_laus:klase jer nije postojala aktivna klasa 6% u laus:klasa a da 

nije u ovoj mips:klase sa akcija=U 

Detalji u prilogu 

Trenutno se radi da pridruživanju klasa artiklima koji su preneseni ranije bez klase 


Poštovani, 

vezano za 

pridruživanje klasa artiklima koji su preneseni ranije bez klase 

Napravljeni sql-ovi, kontrole i ubacivanje slogova ( PRODUKCIJA) : 

u tablicu artikli u MIPS bazi za svaki artikal upisan slog sa akcija=I (izmjena gdje je bilo zadnji sa I ili U ) 

odnosno sa akcija=D (gdje je bilo D) 

u kojema je klasa iz LAUS:art trenutna . 

Artikli koji sad nemaju klasu 6 nisu ovim obuhvaćeni iako su nekad preneseni u MIPS:artikli : 

artikal klasa datum uradio 

301727 42001 08/02/2011 SVEBPINJ 

305269 42001 11/01/2011 SVEKUCUK 

-- ubačen slog u tablicu rednog broja prijenosa 5445 , slog=l_art, datum,vrijeme sistemski , korisnik=MASTER 

detalji u prilogu 

Molimo povratne informacije/suglasnost za zatvaranje zahtjeva - Riješen 

Napomena : ukoliko isto trebamo odraditi na TEST molimo javite . 


Stranica: 69/1080









Poštovani, 

---Ponovljen je inicijalni load klasa : 

Prethodno su bile poslane samo klase koje su na artiklima . 

Sad su poslane klase : 

-- sve klase (aktivne i neaktivne) koje počinju sa 6 uključivo i one koje nisu na artiklima ( jer su nadređene, jer su 

neaktivne,..) 

--Ponovljeno slanje klase uz artikal za sve artikle koji su ikad poslani u mila bazu. 

Prethodno su bili poslane klase uz artikle koji dotad nisu bili poslani s klasom . 

Sad su poslane klase uz artikle : 

--sve artikle (aktivne sa akcija=U, neaktivne sa akcija=D) skupa s klasom ako im je klasa 6 

Akcija je I-izmjena jer su artikli ranije poslani u mila bazu sa akcija=U 

kako bi imali sve klase 6* i sve veze artikal-klasa za sve artikle ikad poslane . 

Molimo povratne informacije /suglasnost za zatvaranje zahtjeva - riješen 

---------------------------- 

Napomena : 

kontrolom utvrđene nepravilnosti vezano za artikle 

19950 ima artikala - u mila bazu tablica artikli . rb prijenosa = 5461. 

samo 2 nemaju klasu 6 - provjerite ih !! : 

matsta matnaz klasif klasa akcija 

305269 ZBIRNI POćTANSKI KOVŹEŚI(ŹETVm 60404 I 

301727 SIEMENS EUROSET 832 60406 I 

ostali su nak lasi 6 : 

klasa akcija akk akt_kl (count(*)) 

6 D U D 5370 artikal je neaktivan a klasa aktivna - normalno stanje 

6 D D N 2018 i artikal i klasa imaju akcija=D (neaktivni su) - normalno stanje 

6 I U D 12423 artikal ima akcija=I-izmjena (već je poslan u mips) a klasa U-upis - aktivan 

artikal i klasa - normalno stanje 

6 I D N 137 aktivni artikal je na neaktivnoj klasi ( provjerite ih !!! - klasa6na.txt u home 

direktoriju admlaus-a ) 

svih 19950 ikad poslanih u mila.artikli su ubačeni 

Oni koji nisu nikad poslani a na klasi su 6* ne bi tebali postojati ali postoje : 

a bb 

N 2894 - neaktivni artikli 

D 159 -- aktivni artikli na aktivnoj klasi koji nisu u mila bazi.artikli 

artnisu.txt artikli kojih nema u mila bazi - provjerite ih !! 

SQL-ovi :artikli_kl1 ,2,3 i 4 


Poštoani, 

Molim povratne informacije/suglasnost za zatvaranje zahtjeva - Riješen . 

Nakon zadnjeg inicijalnog load-a klasa i pridriuživanja klasa artiklima nismo dobili primjedbe 

- zasad sve u redu (Blaženka Periša) 


Stranica: 70/1080









Po vašem nalogu zatvaramo zahtjev. 

S štovanjem 

Poštovani! 

Možete zatvoriti ovaj zahtjev. 

Lp, 


Stranica: 71/1080











Klijent: 





Hitnost: 

Vrlo hitno 


Ivan 


13474 

Vraćen na rješavanje 


18.07.2013 07:15 

Upisao: 

Božo Mišeta 

Područje: 

LTRAN 


08.07.2013 


OBRATITI POZORNOST, U OBRADAMA SU BAR DVA DODATNA ZAHTJEVA UZ OVAJ OSNOVNI! 

Postupiti prema zapisniku iz priloga. 

Nadopuna zahtjeva 13474: 

Potrebno je proširiti slijedeća polja u LAUS i MILA bazi: 

LAUS: tablica lm_usluga_cij: 

· cijena DECIMAL(16,4), 

· cijena_bez_pdv DECIMAL(16,4), 

MILA: tablica cjeusl: 

· cijena DECIMAL(16,4), 

· cijena_bez_pdv DECIMAL(16,4) 

lp, 

Ivan 


Stranica: 72/1080









Poštovani, 

Molimo : 

-- pošaljite/proslijedite nam sql-ove za proširenje tablica u MIPS bazi kako bi ih izveli na našoj mila test bazi 

tj.provjerili jesmo li dobro odradili proširenje . 

-- Nemamo informacije kad izmjene prijenosa zbog proširenja prometnih tablica treba isporučit - dostavite nam 

termin isporuke jer smo prijenos već prilagodili ali nismo isporučili nego je kod nas u razvoju. Napomena : prije 

isporuke treba odradit : 

-- proširenje tablica u mips bazi 

-- proširenje tablica u LAUS bazi koje ćemo mi poslat s isporukom nove verzije TRAN-a. 

-- punjenje novih polja sa vrijednošću 0 u novim poljima (neto cijena i neto promet) za sve slogove koji su već u 

tablici . 

Vezano za Zapisnik sa sastanka 04.07.2013. pod : 

----3.Fakturiranje: ----------- 

Novi način fakturiranja i ispisa faktura bit će parametriziran od strane Lausa i to posebno za svaki poslani zahtjev 

(vrstu dokumenta, objekt,….). Pojašnjenje: Kako ne možemo odrediti točan datum u kojem će se zahtjevane 

promjene primijeniti u pojedinim aplikacijama, a i rješavanje novog načina fakturiranja i ispisa po pojedinim 

zahtjevima neće se primijeniti u istom trenutku, potrebno je navedenim upravljati preko parametara (npr. fakture 

za kontroling rade se ručno i ne ovise o promjeni u prometu, te će se možda moći primijeniti ranije nego fakture 

za poštanske usluge). 

------Riješit ćemo na način -:--------------- 

--- parametar kojim se upravlja načinom fakturiranja jest Indikator obračuna B-bruto / N-neto koji se unosi u 

zaglavlju ugovora 

--- Kad ugovri i promet budu spremni za rad po neto principu program će kod fakturiranja uzimati neto cijenu po 

prioritetu : 

1. posebno ugovoreni rabati/cijene ( lm_rab_ug ) 

2. ugovorna cijena ( cijena u stavkama ugovora lm_ugv_stav ) 

3. cijena iz prometa ( cijena u nalozima iz kojih se fakturira) 

Ako je u sva 3 slučaja cijena = 0 ------> fakturiranje se neće odraditi tj. neće nastati faktura . 

Ako je Indikator obračuna zaglavlju ugovora postavljen na : 

B-bruto onda se ugovrene cijene tumače kao bruto cijene ,a gleda se bruto cijena (jedcij) iz prometa 

(lm_nalog) 

N- neto onda se ugovrne cijene tumače koa neto cijene, a gleda se neto cijena (jedcijn) iz prometa (lm_nalog) 

--- 4.Zaključak ------------- 

1.Dogovorene su izmjene u prijenosu podataka, ali se podaci neće moći puniti dok se aplikacije ne prilagode 

novim uvjetima a za to biznis i/ili računovodstvo treba točno definirati način izračuna i preračuna koji se sada 

bazira u potpunosti na cijenama s pdvom 

--- Molimo povratne informacije 

2.Izmjene na prometnim tablicama koje su dogovorene bit će provedene nakon dostavljene suglasnosti svih 

strana 

--- Molimo povratne informacije 

3.Izmjene u web brzojavnom nisu potrebne jer se kod knjiženja gotovine za sada ništa ne mijenja – ako se ukaže 

potreba definirat će se naknadno 

-- Molimo potvrdu da monex također ne treba mijenjati jer se više ne koristi 

--- U gotovinskom prometu nema promjena . Prometne tablice iz MIPS i HPX zajedno dostavljaju u istim 

tablicama i gotovinski promet i kreditirani, ubuduće proširen novim poljima . Smatramo da , osim lm_naolog 

(kreditirani promet) , treba proširiti i lm_usl_stav ( gotovinski promet) novim poljima i preuzimati dostavljeni 

sadržaj ali , zasad, bez utjecaja na evidencije i knjiženja . Budući se radi o 2 nova polja u ,inače, velikoj tablici i 

po broju polja i po broju slogova, molimo vaš stav u vezi proširenja lm_usl_stav poljima jedcijn i posprzn 


Stranica: 73/1080









Proširena su polja cijena i cijena_bez_pdv u tablici lm_usluga_cij. 

Izmjene su napravljene i na programu ručnog unosa cijenika za usluge izvan mips-a. 

Sutra 25/07/2013 bit će dostupan novi WIN FAUS lib. 

Odraditi sql: 

alter table lm_usluga_cij MODIFY ( 

cijena DECIMAL(16,4), 

cijena_bez_pdv DECIMAL(16,4) ); 


Prijenos HPX-a iz MIPS-a je proširen sa poljima cijenan i posprzn. 

Potrebno za instalaciju i testiranje:Instalacija: novi LAUS/TRAN lib je već na internetu. 


Tim poljima proširene su i LAUS tablice lm_nalog i lm_usl_stav. Tablisa lm_bes je proširena poljima jedcij, 

jedcijn, posprz i posprzn. 


Instalacija: Novi LAUS/TRAN lib je već na internetu. 

Odraditi sql-ove: 

alter table lm_nalog ADD ( 

jedcijn decimal(12,2) before jedcij, 

posprzn decimal(14,2) before posprz); 

alter table lm_usl_stav ADD ( 

jedcijn decimal(12,2) before jedcij, 

posprzn decimal(14,2) before posprz); 

alter table lm_bes ADD ( 

jedcij decimal(12,2) before uradio, 

jedcijn decimal(12,2) before uradio, 

posprz decimal(14,2) before uradio, 

posprzn decimal(14,2) before uradio); 


Stranica: 74/1080











Klijent: 



Ostalo 


Hitnost: 

Vrlo hitno 




13498 

Riješen 


17.07.2013 16:01 

Upisao: 

Boško Tokić 

Područje: 

SYSING 


18.07.2013 


18.07.2013 

Prema tel. dogovoru sa D.Pavlović: 

Napravili smo export LAUS6 produkcijske baze te je backup prebačen na argtest server - Putanja: 

F:\Argosy4HP20130717.bak. 

Potrebno je provjeriti verzije LAU6 na produkciji i na testu kako bi mogli učitati backup na testnu LAUS6 

bazu. 


Stranica: 75/1080











Klijent: 



Pitanje 


Hitnost: 

Vrlo hitno 


Katja Kraljev 


Po uzoru na objekte u Laus3 

- rdgHP_ff RDG ZA HP 

- billHP_ff BILANCA ZA HP 

13495 

U rješavanju 


17.07.2013 15:14 

Upisao: 

Boško Tokić 

Područje: 

AFINK 


19.07.2013 


Molimo uputu kako postaviti službene obrasce Bilance i RDGa u aplikaciji Laus6. 


Stranica: 76/1080











Klijent: 





Hitnost: 

Vrlo hitno 


Ivan 


13497 

U rješavanju 


17.07.2013 15:08 

Upisao: 

Božo Mišeta 

Područje: 

LFINK 


19.07.2013 


Molim analizu podataka koji su završili u greškama kod pripreme kartice kupca(bss_kart_jf) prema 

slijedećim uvjetima: 

select s.bss_greska,g.naziv,p.* from bss_priprema p,bss_status s ,bss_greska g 

where date(p.datum_pripreme)='16.07.2013' 

and p.slog_id=s.slog_id 

and g.bss_greska=s.bss_greska and g.bss_greska='042' 

and p.opis_knjizenja like '1______'; 

Ja sam primjetio da se uglavnom radi o poslovnim partnerima koji na 6-ci imaju nadređenog (nositelja SK). 

Jedan primjer: 

Partner na 6 ima nadređenog koji je nositelj SK. Ovdje mi je čudno jer je jedna uplata prošla a 4 nisu. 

select * from part where part='500116'; 

select * from arhivk where analitika='621874' and konto='120710'; 

select s.bss_greska,g.naziv,p.* from bss_priprema p,bss_status s ,bss_greska g 

where p.analitika='621874' and date(p.datum_pripreme)='16.07.2013' 


and g.bss_greska=s.bss_greska; 


Stranica: 77/1080









Poštovani, 

u prilogu su detalji analize rađene jučer 

Molimo povratne informacije/suglanost za zatvaranje zahtjeva - Riješen . 

Ako želite izmjene tj. riješiti slučaj : knjiži se na NSC a u BSS šalje partner sa šifrom 5* koja je u veznoj tablici 

kupaca 

pošaljite novi zahtjev sa opisom izmjena . 


Stranica: 78/1080











Klijent: 





Hitnost: 

Vrlo hitno 


Katja Kraljev 


Laus 6 - HPPROD 

13496 

Riješen 


17.07.2013 13:42 

Upisao: 

Boško Tokić 

Područje: 

APLAC 


19.07.2013 


Obavještavam Vas da je kod obračuna dara u naravi (HPPRODUKCIJA) obračunat i doprinos za 

zdravstvenu zaštitu u inozemstvu iako nije bila unesena ta šifra primanja (nema je ni na popisu primanja u 

obračunu). 

Dakle, sustav je to unio automatski. Obzirom da je to pogrešno molim da se navedeno što hitnije ispravi. 


Obračun doprinosa za inozemstvo D007 obračunao se zato jer je upravo povezan na radni odnos C u evidenciji 

stopa doprinosa. 

On u toj evidenciji treba biti povezan samo sa radnim odnosom I - inozemstvo a ne sa i sa ostalim radnim 

odnosima, jer će se onda obračunavati uvijek za sve navedene radne odnose i za sva primanja. 

Kako smo naveli u obradi zahtjeva 43850 originalni broj 13331 na radne odnose C i D se povezuje primanje INO 

kako bi se moglo upisati radniku u obračunu.Zatim treba ažurirati parametre: 

RadniOdnosSluzbeniPutInozem u kojemu treba biti vrijednost -> I 

VrstaPrimanjaSluzbeniPutInozem u kojemu treba biti vrijednost -> INO. 

Temeljem tih evidencija obračun doprinosa za inozemstvo dogoditi će se i obračunati radnicima koji imaju u 

obračunu upisano primanje iz parametra VrstaPrimanjaSluzbeniPutInozem tj. INO, ali po stopi koja je 

evidentirana na radnom odnosu iz parametra RadniOdnosSluzbeniPutInozem tj. I. 



Stranica: 79/1080











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13494 



17.07.2013 09:18 

Upisao: 

Božo Mišeta 

Područje: 

EPNAB 


18.07.2013 


Potrebno je spis HP-10/2/1-010283/13 „otključati“, tj. vratiti u status Nabava u tijeku jer je referent zaboravio 

neke stvari upisati. 


Stranica: 80/1080









Poštovani, na testnom ePlanuNabave su dvije narudžbenice po okvirnom sporazumu poslane u LAUS, no iste 

nisu dobile LAUS broj. 

Molimo vas da provjerite da li radi servis na testnom ePlanuNabave. 

Brojevi narudžbenica: 

HP-10/2-021959/12-1 

HP-10/1-005410/13-2 

Pozdrav 


Poštovani, 

Spis u postupku nabave HP-10/2/1-010283/13 je vraćen u status Nabava u tijeku. Molim potvrdu zatvaranja 


Lp, 


Stranica: 81/1080











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13493 

Riješen 


17.07.2013 07:24 

Upisao: 

Božo Mišeta 

Područje: 

LROBD 


17.07.2013 


Imamo situaciju da smo asortiman 000074 deaktivirali (stavili u status 3) I dio artikala (cca 25) je ostalo 

aktivno (u status 2) I sada imamo problem da je jedno te isti artikal aktivan u dva asortimana (u jednom – 

koji je deaktiviran 000074 I drugom –koji je aktivan 000095). 

Dakle, aplikacije ne smije dozvoliti deaktivaciju samo dijela artikala, već svih artikala ako deaktiviramo 

asortiman. Tu se dogodilo da se za deaktivirane artikle gledao datum do – koji je upisan 16.07., a za ostale, 

kod kojih je ostao 31.12.2013 , su ostali aktivni. 


Artikli uasortimanu 000074 su deaktivirani. 


Nije potrebno preuzimati libove 


Stranica: 82/1080











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13492 



16.07.2013 13:01 

Upisao: 

Božo Mišeta 

Područje: 

LROBD 


19.07.2013 


Za potrebe redovnog rada omogućiti na ME1225 modul ZAHpd_pr_fd PREGLED DOKUMENATA tipkom 

F2-URADIO pregled datuma i vremena kada je narudžba napravljena. Podatak o navedenom prijenosu 

omogućiti iz aplikacije „MIPS“. 


Za vrstu dokumenta ZAH Zahtjevnica na pregledu ipsravljena je funkcijska tipka F2(URADIO9. 

Potrebno je preuzeti base lib koji će biti na internetu 18.7.2013. 


Stranica: 83/1080











Klijent: 





Hitnost: 

Vrlo hitno 


Višnja 


Poštovani, 

Na testnom ePlanu javlja se greška: 

13491 



16.07.2013 10:11 

Upisao: 

Božo Mišeta 

Područje: 

EPNAB 


17.07.2013 



Stranica: 84/1080









Poštovani, smatramo da ovaj zahtjev nije korektivno nego adaptivno održavanje. Dokument IT je na testnu 

okolinu isporučio navedene zahtjeve, a odluka HP-a je bila da se napravi restore s produkcijske na testnu 

okolinu. Navedeni utrošak vremena posljedica je provjere ispravnosti rada aplikacije na testnoj okolini nakon 

ažuriranja na stanje prije restorea. 

Riješen je problem koji se pojavljivao kod prijave na testni ePlanNabave. Ponovno su na testni ePlanNabave 

spuštene dorade na test po zahtjevima: 

13457 

13369 

13461 

13132.1 

13132.9 

13132.11 

13132.13 

Molimo potvrdu promjene vrste održavanja u adaptivno i potvrdu zatvaranja zahtjeva. 

Lp, 


Stranica: 85/1080











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13490 

Riješen 


16.07.2013 07:15 

Upisao: 

Božo Mišeta 

Područje: 

LROBD 


19.07.2013 


Dostavljamo ispis dokumenta koji je knjižen – RP3 31657-X13-00399 (originalni MIPS broj: 281). 

Razlika je na ispisu (MDOKzg_rd) i knjiženju u vrijednosti marže, nabavne vrijednosti i PDV-a. 

Analizom utvrđeno da je ukupna vrijednost PDV-a, za artikle 322889 i 322988, pogrešno izračunata. 


Ispravljeno je čitanje kalkulativnih elemenata iz cjenika odnosno kalkulacije na listi MDOkzg_rd za dokumente iz 

PU-a. 

Potrebno je preuzeti laus libove rob0,rob1,rob2,rob3 irob4 koji će biti na internetu 17.07.2013. 


Stranica: 86/1080











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


Poštovani! 

13489 


Tekst iz memoranduma, ćemo mi u HP-u dodavati. 

TEKST S MEMORANDUMA 


12.07.2013 14:47 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


16.07.2013 


1.Vrsta dokumenta za račune za katalošku i digitalnu prodaju je: DIG (digitalna televizija za račune 31005 i 

35358); GR1 (za račune 31005 i 35358) i VR1 (za račune 35358), a vrsta dokumneta za obračun kom. robe 

je OKR. 

2.Modul u kojem se računi digitalne i kataloške prodaje izrađuju je ruckat.jas – računi bez ugovora, a za 

Obračun komisione robe je ME5692. 

3.Tekst općih podataka: prenijeti sa memoranduma. 

4.Na obračun komisione robe koji se dostavlja komitentu dodati klauzulu „samoizdavanje računa“ (čl. 79. st. 

6. Zakona o PDV-u) 

Priloženi su računi za katalošku i digitalnu prodaju i obračun kom. robe. 


Stranica: 87/1080











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13488 

Riješen 


12.07.2013 13:56 

Upisao: 

Božo Mišeta 

Područje: 

WINTRAN 


16.07.2013 


Molimo da na ispis mipsdok (Ispis kalkulacije – primka) dodate dva polja: “JEDINIČNU NABAVNU CIJENU” 

I “MALOPRODAJNU CIJENU”. 


Na ispisu mipsdok (Ispis kalkulacije – primka) dodana su dva polja: NC cijena i MPC cijena . 

Potrebno je preuzeti win tran lib koji će biti na internetu 16.07.2013. 


Stranica: 88/1080











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13487 

Riješen 


12.07.2013 13:35 

Upisao: 

Božo Mišeta 

Područje: 

LROBD 


17.07.2013 


Potrebno omogućiti na objektu RKPzg_fd POVRAT ROBE OD KUPCA – KATALOŠKA PRODAJA knjiženje 

sa trenutnim datumom, obzirom da u praksi postoji mogućnost povrata od kupca sa odmakom od mjesec 

dana. Trenutno aplikacijia “preslikava” datum iz otpremnice. 


Na objektu RKPzg_fd POVRAT ROBE OD KUPCA – KATALOŠKA PRODAJA omogučen je unos datuma 

dokumenta odnosno ne mora biti jednak datumu vezanom dokumentu RNK- Otpremnica kupcu kataloške 

prodaje. 

Potrebno je preuezti laus libove rob0,rob1,rob2,rob3 i rob4 koji će biti na internetu 16.07.2013. 


Stranica: 89/1080











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13486 

Riješen 

Trenutno stanje artikla 310918 iznosi 90 kom. 


12.07.2013 08:22 

Upisao: 

Božo Mišeta 

Područje: 

LROBD 


12.07.2013 


Sa dokumentom RM1 istu tu količinu želim prebaciti na skladište 35365 ali javlja da količina na stanje ne 

može biti manja od 0. 


Ažurirano je skladišno stanje artikla 310918 na skladištu 35350 te je u dokumentu RM1 35358-R13-09384 

moguće prebaciti 50 kom na skladište 35365. 



Stranica: 90/1080











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13485 

Riješen 


12.07.2013 08:20 

Upisao: 

Božo Mišeta 

Područje: 

LROBD 


12.07.2013 


Prilikom knjiženja dokumenta Zahtjevnice i generiranja dokumenta RIM Izdatnica u maloprodaju te 

pokušaja statusiranja dokumenta u status 7 – Robno proknjižen (slika 1) javlja nam se poruka kao na 

ekranu. Konkretan artikl je po modulu robs2_fd PREGLED STANJA ARTIKALA ZA SKLADIŠTE (slika 2) na 

nuli, a na modulu sks2_fd 1 SKLADIŠNO STANJE ARTIKALA ZA SKLADIŠTE (slika 3) je stanje 8 

komada. Kako je u izdatnici navedena količina spornog artikla aplikacija ne dozvoljava knjiženje u status 7, 

ali ne dozvoljava ni dokument stornirati (slika 4). Molim Vas za pomoć prilikom rješavanja navedenog 

problema. 


Izdatnica u maloprodaju RIM 35358-U13-31503 je storinrana odnosno prebačena u status 9 . 

Potrebno je preuzeti laus libove rob0,rob1,rob2,rob3 i rob4 koji će biti na internetu 13.07.213. 


Stranica: 91/1080











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13484 

Riješen 


12.07.2013 06:37 

Upisao: 

Božo Mišeta 

Područje: 

LROBD 


12.07.2013 


Međuskladišnica-izlaz RM1 35348-R13-05346 je stornirana ali nije nastao vezni dokuement. 

kao što je to npr. slučaj kod dokumenta 35348-R13-05345 

U depou Zagreb je nastao RM2 35358-R13-9160, roba nije vraćena na stanje depoa Split te je nije 

moguće proslijediti u depo Zg. 


Dokument RM1 35348-R13-05346 je prebačen u status 9 sa svojim parnjakom te je RM2 35358-R13-09160 je 

izbrisan jer se nalazi u statusu 1 te je ažurirano skladišno stanje na skladištu 35348. 



Stranica: 92/1080











Klijent: 





Hitnost: 

Vrlo hitno 


Višnja 


13483 

Riješen 


10.07.2013 14:50 

Upisao: 

Božo Mišeta 

Područje: 

LCSBI 


20.07.2013 


U prilogu zahtjeva dostavljen je dokument (Bilanca.xlsx) na kojem je usporedba iznosa bilančne pozicije 

Trgovačka roba iz liste Bilance na 31.05.2013. u Crystalu s bilancom na isti dan u Argosy međubazi. 

Potrebno je utvrditi zašto se podatak u MIS-u ne slaže s podatkom u Argosyiu. 


Poštovani, 

molimo Vas, možete li provjeriti da razlika koja se pojavljuje je usljed naknadnog knjiženja ili izmjene knjiženja u 

1. mjesecu ove godine? 

Hvala 


Poštovani, 

ustavnovljavamo da sada po pitanju bilance od početka godine do 6. mjeseca uključno nema razlika. 

Pretpostavljamo da je moguće da je crystal report bilance pozvan 4.7. u trenutku kada se nove upute od 4.7. još 

nisu bile učitale do kraja. 


Stranica: 93/1080











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13481 

Riješen 


09.07.2013 15:12 

Upisao: 

Božo Mišeta 

Područje: 

WINTRAN 


11.07.2013 


Nisu usklađene nabavne cijene za više artikala( prvi artikl (318218) ima dobro pridruženu nabavnu cijene ,a 

svi ostali imaju istu kao ovaj prvi- prilog ispis primke-kalkulacije.PDF, čak je i redni broj svugdje 1). Molim 

da to ispravite. 


Usklađena su cijene artikala na listi mipsdok i u cjeniku artikala na datum dokumenta. 

Potrebno je preuzeti win tran lib kiji će biti na internetu 12.07.2013. 


Ispravljeni je redni broj stavaka na listi mipsdok . 

Potrebno je preuzet laus win tran lib koji će biti na internetu 13.07.2013. 


Stranica: 94/1080











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13482 



09.07.2013 15:01 

Upisao: 

Božo Mišeta 

Područje: 

EOBRRAC 


11.07.2013 


Budući da ambulantnu dostavu robe od 01.07.2013. zadužuju poštanski uredi putem MIPS-a, dolazi do 

problema kod e obrade računa kod kojeg se treba pridružiti primka iz Lausa. U e obradi računa ne vidi se 

primka iz WINLAUSA, u privitku su račun, primka iz MIPS-a i primka iz WINLAUSA, napominjem da je 

plaćanje računa 12.07.2013. Potrebno ispitati o čemu se radi i molim info o istom. 


Stranica: 95/1080









Poštovani, 

Katja poslala : 

Od jučer e obrada povlači primke, nije bitno da li je malo ili veliko slovo x kod pretrage ispred godine u broju 

primke . 

Za sada je sve ok, ako neće povlačiti ponovo primke javim se. 



Poštovani, 

Zahtjev zatvaramo uz vašu suglasnost - Riješen 



Poštovani! 

Ovaj zahtjev možete zatvoriti. Riješen. 

Lp, 

From: Katja Kraljev 


Stranica: 96/1080











Klijent: 





Hitnost: 

Vrlo hitno 


Višnja 


13480 



09.07.2013 13:22 

Upisao: 

Božo Mišeta 

Područje: 

EPNAB 


10.07.2013 


Ugovor o bagatelnoj nabavi broj HP-10/2/1-013006/13 je 8.7.2013 poslan u LAUS. Još uvijek kroz 

ePlanNabave nema LAUS broja: 


Stranica: 97/1080









Poštovani, 

Navedenom ugovoru smo ručno dodijelili LAUS broj. U logu se vidi da je podatak o Laus broju ugovora uspješno 

prenijet, dok u samoj bazi ePlanaNabave tog podatka nema. 

Je li HP ovaj tjedan radio restore baze podataka za ePlanNabave ili neki drugi zahvat nad tom bazom? 

Molimo potvrdu zatvaranja zahtjeva, 

Lp, 



S štovanjem 

Poštovani, 

Potvrđujemo zatvaranje zahtjeva. 

Lijep pozdrav, 

----------------------------------------------------- 

Višnja Abija-Ivček 


Stranica: 98/1080











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13479 

U rješavanju 


09.07.2013 13:05 

Upisao: 

Božo Mišeta 

Područje: 

LTRAN 


12.07.2013 


10.07.2013 

Korisnica andelka.bakota (SVEBAKOT) ne može odraditi prijenos računa jer joj se javlja slijedeća greška: 


Stranica: 99/1080











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13478 

Riješen 


09.07.2013 09:30 

Upisao: 

Božo Mišeta 

Područje: 

LROBD 


10.07.2013 


Na dokumentu RIM vise nije moguće unositi kategoriju O-ostalo jer ste umjesto nje dodali kategoriju Mmarke, 

ali naš zahtjev za promjenom kategorije O u M se odnosio samo I isključivo na dokument 

ZAHJTEVNICA SKLADIŠTU koja dolazi iz PU I u njoj se nalazi kategorija (R, I, M – koju koristi poštanski 

ured). 

Kategorija u dokumenti RIM se koristi u depou. 

Molim da što hitnije ispravite kategoriju M na dokumentu RIM. 


Na dokumentiu RIM omogučen je unos kategoprije O-Ostalo. 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13477 

Riješen 


09.07.2013 08:59 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


12.07.2013 


10.07.2013 

Onemogućiti više storniranja za isti račun – ne smije se dozvoliti storniranje računa u statusu 9. Primjer: za 

račun 4630001359043 napravljeno je 13 storno računa (podaci iz veza_ds): 


Onemogućeno je više puta storniranja za isti račun. 

Novi WIN FAUS lib će biti dostupan sutr ujutro (10/07/2013). 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13476 

Riješen 


09.07.2013 07:21 

Upisao: 

Božo Mišeta 

Područje: 

LNABD 


11.07.2013 


Pokušajem izrade narudžbe na ME1206 modulu zahg fg GENERIRANJE NARUDŽBI IZ ZAHTJEVNICA 

prema dobavljačima na ekranu pojavljuje nam se poruka kao na slici dolje ( slika 1.) Molim Vas za 

provjeru. 


Potrebno provjeriti odosno definirati sljedeće na uzoru prema testnoj bazi sljedeće objekte : 

vodk_fm - vrstu dokumenta NRD (panther) 

protup_ff - upute za difiniranje dokumenta (panther) 

vdr_p_jd UVJETI ZA ROBNE DOKUMENTE (jam) 

vzs_ul_ja DEFINIRANJE VEZA IZMEŃU DOKUMENATA (jam) 

ISPul_jm PRIDRU¦IVANJE ISPISA DOKUMENTIMA (jam) 

stu_ja UPUTE ZA PRELAZAK STATUSA (jam) 




0











Klijent: 





Hitnost: 

Umjereno hitno 


Višnja 


13475 



08.07.2013 12:13 

Upisao: 

Božo Mišeta 

Područje: 

LKEVP 


15.07.2013 


Prijenosom ERV-a u obračun plaće za 06-2013 radniku 20247 Bobek Vesna preneseno je 7 sati više od 

fonda (160). 

Pogrešno je izvršen prijenos ERVa za navedenog radnika sa 7 sati više od fonda. 

Molimo ispravak. 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13473 

Riješen 


05.07.2013 09:36 

Upisao: 

Božo Mišeta 

Područje: 

LROBD 


10.07.2013 


Na pregledu dokumenta “Zahtjevnica” potrebno je omogućiti filtiranje zahtjevnica i po kategoriji : ‘M’ – 

marke. 

Zahtjevnice iz aplikacije Mips dolaze sa oznakama: M- marke, R-redovna, I-izvanredna i sa tim oznakama 

se vide u Lausu na pregledu zahtjevnica, ali se trenutno ne mogu filtrirati po kategoriji M. 



0









Poštovani, 

dokumenti koji dolaze iz MIPS-a imaju oznaku kategorije O-ostalo, R-redovno i I-izvanredno. Te se može dobiti 

pregled po tom filteru. 

Ostalo, redovno i izvanredno su oznake brzine ili načina ili prioriteta po kojem se riješava zahtjevnica. M - marke 

je vrsta robe i to nije kategorija. 

Ako je nekakva izmjena napravljena mi nismo obavješteni o istoj. 

Radi preciznosti, da li vaš zahtjev glasi, da se izbaci indikator O - ostalo iz ponude kategorija i zamjeni 

indikatorom M - marke ili 

da ostanu sva tri indikatora i da se doda četvrti M - marke, te na taj način i omoguči filtriranje. 

S štovanjem 


Sad je zadatak jasan, hvala. 

S obzirom na definiciju zahtjeva, mislim da treba promjeniti vrstu održavanja iz perfektnog (ovo nema veze s 

zakonskim izmjenama) u adaptivno. 

Molim potvrdu. 

S štovanjem 


Na zaglavlju dokumenta ZAH Zahtjevnica i samom pregeldu istih zahtjevnica omogučena je pretraga po 

kategoriji M- Marke. 




0











Klijent: 





PDV 2013-07 

Hitnost: 

Vrlo hitno 


Glorija 


13472 

U rješavanju 


05.07.2013 07:15 

Upisao: 

Božo Mišeta 

Područje: 

LFINK 


10.07.2013 


U NN 79/2013. objavljen je Pravilnik o porezu na dodanu vrijednost sastavni dio kojeg su i novi pdv 

obrasci. Molim da se sukladno navedenom u Laus-u pod 

ME236 PDV¬ - Porez na dodanu vrijednost doda novi ME2366 POREZ NA DOD.VRIJE. (OD 01.07.2013. 

-) sa pripadajućim NOVIM obrascima 

-KNJIGA IZLAZNIH RAČUNA 

-KNJIGA ULAZNIH RAČUNA 

-PDV OBRAZAC 

-PDV –K OBRAZAC 

-PDV-S OBRAZAC 

-OBRAZAC ZP 



0









Poštovani, 

Molimo proslijedite na relevantne adrese unutar HP vezano za pojašnjenja koja tražimo 

Narodne novine 79/2013 od 27.6.2013 objavile su Pravilnik o porezu na dodanu vrijednost po kojem je 

propisan sadržaj knjige U-RA i I-RA te ostalih obrazaca vezano za PDV od 2013-07. 

porezna uprava objavila je izgled svih obrazaca za PDV na : 

http://www.porezna-uprava.hr/HR_obrasci/Stranice/default.aspx 

pod :POREZ NA DODANU VRIJEDNOST 

Standardno radimo kao i dosad : 

I-RA (ima dosta promjena) 

U-RA (nema promjena) 

PDV (ima dosta promjena) 

PDV-K (ima dosta promjena ) 

Po zahtjevu traženi su još obrasci : 

PDV-S Prijava za stjecanje dobara i primljene usluge iz drugih država članica Europske unije 

ZP Zbirna prijava za isporuke dobara i usluga u druge države članice EU 

Molimo pojašnjenje vezano za PDV-S i ZS obrazac : 

a) međunarodne poštanske uputnice : ulaze ili ne u PDV-S i ZP obrazac ili ne . 

b) kombinacije vrsta protokola i vrsta dokumenta koje ulaze u PDV-S te ZP . 

Ako ulaze sve vrste dokumenta evidentirane u nekoj vrsti protokola dovoljno je navesti samo vrstu protokola. 

c) za slučaj : isporučena su dobra ( napr filatelija) u zemlju čalnicu EU ali kupac nema VAT number (porezni broj) 

Ulazi li račun za ovaj slučaj u ZP obrazac ? 

d) stečena su dobra ili usluge iz zemlje čalnice EU ali dobavljač nema VAT number (porezni broj) 

Ulazi li račun za ovaj slučaj u PDV-S obrazac ? 

NAPOMENA :Ostale obrasce ne radimo : 

P-PDV Zahtjev za registriranje za potrebe poreza na dodanu vrijednost 

Isporuka NPS Prijava za isporuke novog prijevoznog sredstva iz RH u rugu državu članicu 

Stjecanje NPS Prijava za stjecanje novog prijevoznog sredstva iz druge sržave članice EU 

PDV-P Zahtjev za povrat poreza na dodanu vrijednost 

PDV-F Evidencija računa o prodanim dobrima radi povrata poreza na dodanu vrijednost u okviru 

putničkog prometa 

PDV-H Zahtjev za povrat poreza ovlaštenim tijelima za izvezena dobra 

PDV-MI Evidencija o prodanim dobrima na koje se primjenjuje poseban postupak oporezivanja marže 

ZP-PDV Zahtjev za povrat (tax refund form) 

PDV-MU Evidencija o nabavljenim dobrima u posebnom postupku oporezivanja marže 

Izvješće PDV Izvješće o ostvarenim oslobođenjima od plaćanja PDV-a 



0









Poštovani, 

Molimo te proslijedite u računovodstvo : 

Kombinacije vrste protokola i vdok te država koji se u njima nalaze u računima kupaca i dobavljača izvan RH iz 

2013 su u prilogu . 

Također, u prilogu sadašnji način listanja knjiga U-RA i I-RA te PDV obrasca - vdok nebitan. 

Napomena : 

Potrebno je ažurirati šifarnik država podatkom članica EU D/N 

Planiramo širiti razradu neoporezivog zbog uvođenja novih stupaca u knjigu I-RA pod neoporezivo, a vezano za 

isporuke u člance/nečlanice EU 

Smatramo da , osim oznake članstva u EU ulogu kod svrstavanja u pojedine stupce knjige I-RA za neke 

slučajeve protokol nije dostatan jer se u istom protokolu nalaze izlazni računi za članice i nečalnice EU . 

Rješenje bi moglo biti ili nova vrsta dokumenta ili nova vrsta protokola ukoliko se želi izbjeći hard code. 

Podsjećamo da još čekamo odgovre na pitanja : 

Molimo pojašnjenje vezano za međunarodne poštanske uputnice : ulaze ili ne u PDV-S i ZP obrazac ili ne . 

Molimo, navedite kombinacije vrsta protokola i vrsta dokumenta koje ulaze u PDV-S te ZP . 

Ako ulaze sve vrste dokumenta evidentirane u nekoj vrsti protokola dovoljno je navesti samo vrstu protokola 

Također, molimo pojašnjenje za slučaj : 

a) isporučena su dobra ( napr filatelija) u zemlju čalnicu EU ali kupac nema VAT number. 

Ulazi li račun za ovaj slučaj u ZP obrazac ? 

b) stečena su dobra ili usluge iz zemlje čalnice EU ali dobavljač nema VAT number (porezni broj) 

Ulazi li račun za ovaj slučaj u PDV-S obrazac ? 


Poštovani, 

Pitali ste : 

Da li je moguće postaviti veze u prijavi PDV tako da neki protokol i vrsta dokumenata ne ulaze u knjigu ulazni ni 

u knjigu izlaznih faktura 

a ulaze u prijavu PDV-a. 

Odgovaramo : 

Za knjige U-RA i I-RA zadaju se vrste protokola za koje se želi listati /kontrolirati (F2 Ukupno) 

Za prijavu tj.obrazac PDV i PDV-K također se zadaju vrste protokola koje ulaze u prijavu , neovisno o zadanom 

za knjige U-RA i I-RA 

Preduvjet : zadati se mogu samo vrste protokola koje u šifarniku imaju upisano da ulaze u PDV i da su ulazni tj. 

izlazni protokoli 

Ne može se izvršiti zadavanje po kriteriju vrsta dokumenta a nakon sastanka jučer smatramo i nepotrebnim. 



0









Poštovani, 

Predlažemo POREZ NA DOD.VRIJE. (OD 01.07.2013.-) sa svim pripadajućim obrascima navedenim u zahtjevu 

napraviti pod WinPanther. 

Molimo vaš stav u vezi s predloženim . 

Pojašnjenje prijedloga : 

CharPanter : 

Veliki broj stupaca , dugački nazivi onemogućavaju prikaz na svrsishodan način, gubi se smisao i namjena 

kontrolnih pregleda jer postaju nepregledni 

( više Alt ekrana ) posebice kod Knjiga I-RA :a) F5 pregled i b) F2 Ukupno 

WinPanther 

svi ispisi bili bi u formi excel : nema ograničenja broja stupaca ni kod ispisa niti kod pregleda . 

Kontrolni pregledi/liste za nove obrasce - HP treba poslati zahtjev : 

-- PDV-S : novi obrazac : potreban kontrolni pregled po razini dokumenata koji u njega ulaze (sastanak 

9.7.2013.) 

-- ZP : novi obrazac : potreban kontrolni pregled po razini dokumenta koji u njega ulaze (sastanak 9.7.2013. ) 

U zahtjevu specificirati uvjete, stupce, redoslijed, sume . Posebno navesti trebaju li ,osim dokumenta koji ulaze u 

obrasce , u kontrolnim pregledima/listama biti prikazani i vezni dokumenti . NApr, za PDV-S kontrolni 

pregled/listu osim dokumenta koji ulaze u obrazac treba biti prikazan i račun dobavljaća iz EU koji se evidentira u 

protokolu 6 (ne ulazi u PDV obrasce) 



0









Poštovani, 

Napravljen je novi objekt pdv_up_jm UPUTE ZA REVERSE CHARGE. 

Ovdje upisane aktivne upute koriste se kod popune novog PDV , PDV-K te PDV-S obrasca. 

Na novom objektu postoje tri funkcijske tipke: 

F1 Unos - unos uputa 

F2 Aktivacija/Deaktivacija - aktivacija i dezaktivacija postojeće upute 

F5 Pregled - pregled uputa 

Izmjena i brisanje nisu dozvoljeni kroz aplikaciju .Upute se upisuju u novu tablicu pdv_up. 

Prijavljen je u objekte i na meni ME236 PDV - POREZ NA DODANU VRIJEDNOST, izbor 8 

u prilogu radna popuna uputa za obračune poreza i pretporeza po reverse charge (prijenos porezne obveze) - 

primjer popune . 


1. preuzeti novi LAUS BASE liba u petak 19.7.2013. 

2. preuzeti nove objekte i menije s interneta 19.7.2013 

3. izvesti dolje navedeni sql za kreiranje nove tablice pdv_up 

4. proslijediti u računovodstvo kako bi odredili osobu koja će ažurirati upute 

CREATE TABLE "l1base".pdv_up 

( 

vprotokol char(1) NOT NULL, 

vdok char(3) NOT NULL, 

uliz char(1) NOT NULL, 

ino char(1) NOT NULL, 

pdv_s char(1) NOT NULL, 

vrsta char(1) NOT NULL, 

aktivnost char(1) NOT NULL, 

uradio char(8) NOT NULL, 

datum date NOT NULL, 

vrijeme char(5) NOT NULL, 

terminal varchar(30,8) NOT NULL, 

primary key (vprotokol,vdok) 

); 

grant all on pdv_up to public AS l1base; 



0









Poštovani, 

Na koji će meni zakačiti novi podmeni za pdv od 01.07.2013. pod WinPanther ? 

Sve procedure i ekrni su rađeni u WIN FAUS libu. 

Na taj novi podmeni bit će prijavljeni objekti kao u prilogu . 

Trenutno stanje pojedine liste/obrasca također je u prilogu . 

Dovršava se ekran evidencije izlaznih računa koji ulaze u PDV - isporuka ovaj tjedan 

Napomena : 

za postojeće izlazne račune sa datum pdv-a manji od zadanog u parametru novom IRAEU otvarat će se 

postojeći ekran . 

Za nove račune koji se tek unose ili postojeće kojima je datum pdv-a veći ili jednak od zadanog u IRAEU 

paramtetru otvarat će se novi ekran sa novim stupcima razrade neoporezivog. 

Detaljno ćemo poslati kad bude u isporuci . promjene su bile nužene iako nisu naznačene jer je nova knjiga IRA 

drugačija od one prije 01.07.2013. 



0











Klijent: 





PDV 2013-07 

Hitnost: 

Vrlo hitno 


Glorija 

13469 

U rješavanju 


04.07.2013 12:19 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


06.07.2013 




0









Sukladno Izmjenama zakona o PDV-u od 01.07.2013. treba napraviti izmjene u LAUS-u na izlaznim 

računima s jediničnim neto cijenama koji su baza za dolje navedene izmjene. 

Za Vdok – FAP, FAH, FAO, FAS, ODO, OBN, DON, RAV, PIK : 

1. u zaglavlju desno iznad adrese dodati logo Hrvatske pošte kao u memorandumu (ili na računu za 

katalošku prodaju) 

2. u zaglavlju desno u adresi HP-a, izmijeniti ulicu i poštanski broj i naziv u „JURIŠIĆEVA 13, 10000 

ZAGREB“ 

3. u podnožju faktura dodati tekst kao u Memorandumu 

- u mailu nalazi se tekst koji treba biti ispisivan 

4. oznaku R-1 na računima – brisati 

5. desno od adrese – mijenjati naziv „Broj računa“ u „Evidencijski laus broj“ 

6. na Vdok – FAP, FAO, FAS, ODO, OBN –izmijeniti napomenu „Oslobođeno plaćanja PDV-a temeljem 

članka 11 i 11.a Zakona o PDV-u“ u novu napomenu „Oslobođeno plaćanja PDV-a temeljem čl.39. i čl.40. 

Zakona o PDV-u.“ 

Ta napomena mora vrijediti za fakture za datum pdv-a od 01.07.2013. 

7. na fakturi mijenjati naziv „POREZ“ u skraćenicu „PDV“ (u stupcu koji iskazuje PDV). U zbrojnom iznosu 

fakture riječ „POREZ“ treba mijenjati u naziv „PDV 25%“. 

Ukoliko se na istoj fakturi pojavljuju usluge po drugim stopama PDV-a trebaju biti iskazane kao: 

PDV 0% 

PDV 10% 

PDV 25% itd. Ako nema usluga po drugim stopama, na fakturi se iskazuje samo ona koja je obračunata u 

uslugama. 

8. Jedinične cijene na fakturi trebaju biti izražene u neto iznosima (cijene bez PDV-a) 

9. Ako su u ugovorima upisane neto jedinične cijene usluga – LAUS treba čitati cijene iz ugovora. 

Ako u ugovoru nisu upisane neto jedinične cijene usluga, cijene se čitaju iz prenesenih podataka iz drugih 

aplikacija. 

10. Iz MIPS-a, umjesto bruto cijena iz Cjenika u prijenosu trebaju dolaziti neto jedinične cijene 

11. Složene cijene –iz MIPS-a će biti prenesene cijene u neto iznosima, na fakturama će se iste 

obračunavati prema ukupnoj neto vrijednosti podijeljenoj s količinom usluge kako bi se dobila „prosječna 

jedinična cijena“ 

12. U stupcu „Porezna osnovica“ mijenjati naziv u „Osnovica“ 

13. u stupcu „Vrijednost u kn“ mijenjati naziv u „Vrijednost u kn bez PDV-a“ 

14. u stupcu „RABAT“ mijenjati naziv u „POPUST“ 

15. u zbrojnom iznosu računa mijenjati: 

- „UKUPNO“ u „Ukupno bez PDV-a“ 

- „RABAT“ u „“Popust“ 

- „POREZNA OSNOVICA“ u „Osnovica za 25% PDV-a“ (ako ima drugih stopa nizati jednu ispod druge po 

rastućem broju stope) 

- „POREZ“ u „PDV 25%“ 

- Ako ima više stopa PDV-a dodati „Ukupno PDV“ 



0







- „Neoporezivo“ -završen, ostaje Isporučen kao do - sada Korisnik potvrdio ispravnost 

- „UKUPNO ZA PLATITI (KN)“ mijenjati u „Ukupno kn“ 

16. Na računima s iskazom Rekapitulacije količina i rabata po zonama (na zadnjoj strani računa lijevo od 

zbrojnog iznosa) „Iznos rabata“ iskazuje se NETO iznos rabata 

17. Navedene promjene je potrebno napraviti na objektima na kojima se izrađuju izlazne fakture : 

- rucfak.jas Pregled i ručni unos faktura (za račune, predračune, odobrenja, račune za primljeni predujam) 

- rucpred.jas Predračuni bez ugovora 

- fakt.jas Fakturiranje poštanskih usluga 

- fakhp.jas Fakturiranje hpekspres usluga 

- fakot.jas Unos odobrenja 

- fakis.jas Ispis računa 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13471 

U rješavanju 


04.07.2013 10:53 

Upisao: 

Božo Mišeta 

Područje: 

LTRAN 


08.07.2013 


Trenutno se u mips_laus tablici stanje_depo ne pune polja korisnik_dos I dat_vri_dos. Molim da to 

ispravite. 



0











Klijent: 





PDV 2013-07 

Hitnost: 

Vrlo hitno 


Glorija 

13470 



04.07.2013 10:30 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


06.07.2013 




0









rucfak_fas - pregled i ručni unos računa 

fakplN_fas – fakturiranjae platnog prometa 

Za vrstu dokumenata FAF potrebno je izvršiti slijedeće izmjene: 

- u polju OIB ukloniti slovne oznake HR 

- ukloniti oznaku R1 

2. Omogućiti izradu faktura s neto jediničnim cijenama, na dva načina; ako je cijena unijeta u ugovor pri 

izradi fakture sustav povlači cijenu, a ako cijena nije unijeta u ugovor onda se ručno unosi u stavke fakture. 

3.U naziv kolone na fakturi Jedinična cijena u kn dodati tekst „bez PDV-a“ 

4. U napomeni izmijeniti članak vezan uz oslobođenje plaćanja, ispravna napomena glasi: Oslobođeno 

plaćanja PDV-a temeljem članka 40. Zakona o PDV-u. Navedeni članak treba vrijediti za fakture gdje je 

datum pdv-a od 01.07.2013. 

5. U razradi Ukupno za platiti iznos PDV-a razvrstati po stopi PDV odnosno pokraj riječi porez dodati i stopu 

6. Na dnu fakture treba navesti opće podatke o izdavatelju računa, sukladno čl. 21 Zakona o trgovačkim 

društvima: 

HP - Hrvatska pošta d.d., Jurišićeva 13, HR - 10000 Zagreb 

Kontakti: telefon: 0800 303 304, telefaks: (01) 6626 889 , internet: www.posta.hr 

MB: 1414895; OIB: 87311810356; 

NADZORNI ODBOR: Martina Jus - predsjednica; UPRAVA: Alen Premužak - predsjednik, Ivica Kranjčić, 

Ranko Marinović, Željko Žarko - članovi 

POSLOVNA BANKA: Hrvatska poštanska banka d.d., Jurišićeva 4, HR-10000 Zagreb, 2390001- 

1100018674; IBAN: HR16 2390 0011 1000 1867 4; BIC/SWIFT: HPB ZHR2X; 

REGISTAR: Trgovački sud u Zagrebu; MBS: 080266264 

TEMELJNI KAPITAL: 952.636.100.00 kuna, u cijelosti uplaćen, podijelijen na 9.526.361 dionicu u 

nominalnom iznosu od 100.00 kuna 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13458 

U rješavanju 

OVO JE ZAHTJEV 43625 KOJI JE GREŠKOM OBRISAN!!!!! 


04.07.2013 08:11 

Upisao: 

Božo Mišeta 

Područje: 

LTRAN 


04.07.2013 


PU 47106 KARLOVAC 6 napravio je narudžbu u aplikaciji „MIPS“, ali je mi u aplikaciji „LAUS“ na ekranu 

ME1225, modul ZAHpd_pr_fd ne vidimo. 

Zahtjevnica, koja je poslana iz PU, nije vidljiva u aplikaciji Laus 

U mips_laus tablici : zahtjev_prijenos je vidljiva – u statusu je 1 (šifra_pu: 31303, mips_dokument=1, 

artikl=307099) 


Poštovani, 

Za zahtjevnicu je ponovljen prijenos, nastao je dokument 35358-Q13-09351. 

Ispravljeni servis prenosa stavljen na tesnu bazu HP-a. 

Nakon testiranja molim nalog da se prebaci i na produkciju. 

S štovanjem 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Glorija 


13468 



03.07.2013 13:42 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


10.07.2013 


Sukladno promjenama koje se obavljaju za omogućavanje pristupa poštanskoj mreži, potrebno je prilagoditi 

ispis fakture na način da bude prepoznatljivo gdje su fakturirane pošiljke otpremljene (unutarnji ili 

međunarodni promet) te po kojoj osnovi su dodijeljeni popusti (stupanj razrađenosti pošiljaka te Pristup I ili 

II). Kratice koje će se primjenjivati uz nazive pošiljaka koje se predaju kroz pristup: 

-„I R“ – Pristup I, razrađene pošiljke, unutarnji promet 

-„I NR“ – Pristup I, nerazrađene pošiljke, unutarnji promet 

-„II R“ – Pristup II, razrađene pošiljke, unutarnji promet 

--„I RM“ - Pristup I, razrađene pošiljke, međunarodni promet 

Primjer ispisa svih mogućih naziva za pismo do 50 g: 

UNUTARNJI POŠTANSKI PROMET 

I R Pismo do 50 g 

I NR Pismo do 50 g 

II R Pismo do 50 g 

MEĐUNARODNI POŠTANSKI PROMET 

I RM Pismo do 50 g 

U privitku zahtjeva nalazi se primjer fakture za Unikom, čije zaglavlje odgovara i primjeni za pristup 

poštanskoj mreži. 

Na objektu rucnalN.fas Pregled i ručni unos naloga promijeniti nazive: 

-Točka pristupa u „Pristup“ 

-Razrađeno u „Razvrstano“ 

-Nerazrađeno u „Nerazvrstano“ 

2. Proširiti indikatore „Razvrstano“ za Pristup za pristup mreži za pošiljke u međunarodnom prometu – novi 

naziv „međunarodne pošiljke“ (iste su po Pristupu 1) 

3. Na objektu rekbrouN-fas Rekapitulacija ob.usluga kred.korisnicima na dan, u uvjetima pregleda, dodati 

indikatore za točke pristupa i razrađenosti po modelu objekta rucnalN.fas (iz točke 1 ovog zahtjeva) 



0


Status: 








Stranica: 

120/108 

0











Klijent: 





Hitnost: 

Vrlo hitno 


Višnja 


13467 



03.07.2013 10:04 

Upisao: 

Božo Mišeta 

Područje: 

EPNAB 


04.07.2013 

Narudžbenice po okvirnom sporazumu ne rade kako je dogovoreno. 


Prilikom dodavanja nove, otvori se uredan prozor gdje je Broj narudžbenice jednak broju Okvirnog 

sporazuma: 

vidi prilog 



0









Poštovani, 

Ovaj zahtjev je prebačen na test. Riješen je problem koji se pojavljivao kod narudžbenice po okvirnom 

sporazumu, gdje je nakon spremanja podataka program izmijenio broj narudžbenice. 

Lp, 


Nastavno na problematiku u zahtjevu 13467 potrebno je u HP odlučiti sljedeće, a vezano je uz narudžbenice po 

okvirnom sporazumu: 

1. Kod prijenosa narudžbenica iz ePlanNabave u Laus dokumentu je potrebno dodijeliti tip vrste 

postupka. Predlažemo da to bude tip 24 za narudžbenice. 

2. Kod dodjele rednog broja narudžbenice potrebno je definirati jednistveni parametar preko kojeg će 

se povratna informacija o Laus broju dokumenta pohranjivati u ePlanNabave. 

a. Prva i kvalitetnija opcija je da se onemogući ručna dodjela broja narudžbenice i da se redni broj generira 

od strane sustava. U tom slučaju će sve narudžbenice imati osiguranu jedinstvenu oznaku. 

U ovom slučaju potrebna je dorada na strani ePlanNabave. Ova opcija je korektivno održavanje. 

b. Druga opcija je da se iz Lausa kao povratna informaciuja šalje ID dokumenta iz ePlanNabave kako bi se 

dokument mogao ispravno pohraniti. Razlog je taj što rućna dodjela broja narudžbenice znači mogućnost 

ponavljanja broja narudžbenice. 

U ovom slučaju potrebna je dorada na strani ePlanNabave i Laus. Ova opcija je adaptivno održavanje, a 

procjena može biti definirana nakon potvrde HP da žele ovu opciju. 

Potrebni su nam odgovori na obje točke kako bismo mogli poduzeti daljnje korake po pitanju zahtjeva 13647. 

S poštovanjem, 


Poštovana, 

Zahtjevi 13461 i 13467 se ne mogu riješiti do kraja dok ne dobijemo odgovor na pitanje po zahtjevu 13467. 


Lea Gagulić 



0









Riješen je problem koji se pojavljivao kod slanja narudžbenice u LAUS. Narudžbenice po okvirnom sporazumu 

su TIP=24. Broj narudžbenice po okvirnom sporazumu kao o broj ugovora po okvirnom sporazumu se povlači 

kao i do sada s odabranog okvirnog sporazuma, korisnik ga može mijenjati s time da je ugrađena provjera da li 

već postoji broj narudžbenice ili ugovora. Ukoliko postoji, dobije se upozorenje da broj već postoji. Također su 

napravljene i dorade na servisu. Ovaj zahtjev je prebačen na test. 

Lp, 


Ovaj zahtjev je prebačen na produkciju. Molimo potvrdu zatvaranja zahtjeva. 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13466 



02.07.2013 14:43 

Upisao: 

Božo Mišeta 

Područje: 

LROBD 


05.07.2013 


Na ME1234, objektu mid_jd MASOVAN ISPIS DOKUMENATA (HP) omogućiti ispis kao i na objektu 

RIMzg_fd Iispis IZD. U MALOPRODAJU PO KLASAMA (RIMzgaKHP_rd.txt). 


Izmjenjeno je kod masovnog ispisa dokumenta mid_jd za vrstu dokumenta RIM da se ipsiuje ispis IZDATNICA 

U MALOPRODAJU PO KLASAMA RIMzgaKHP_rd. 

Potrebno je preuzeti laus libove rob0,rob1,rob2,rob3 i rob4 koji će bit na internetu 5.7.2013. 


Nije potrebno dodavati nove ispise već postojeći ispis za vrstu dokumenta RIM ispisuje ispis RIMzgaKHP_rd 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13465 

Riješen 


02.07.2013 14:35 

Upisao: 

Božo Mišeta 

Područje: 

LROBD 


05.07.2013 


Na ME1225 na modulu ZAHpd_pr_fd omogućiti filtriranje zahtjevnica po kategoriji: „R“ – redovna i „I“ - 

izvanredna. Mogućnost izbora kategorije „M“ je u funkciji. 


Poštovani, 

ovaj zahtjev smatramo adaptivnim, jer se traži izrada nove funkcionalnosti. 

Molimo potvrdu. 

S štovanjem 


Na pregledu zahtjevnica odnosno dokumenta vrste ZAH skinut je filter pretrage po vrstama robe, a uveden filer 

Kategorija - O-Ostalo , R-Redovna i I-Izvanredno . 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13464 



02.07.2013 14:09 

Upisao: 

Božo Mišeta 

Područje: 

LROBD 


05.07.2013 


Kod unosa artikla (ekran artd_fa) na polju „ekran“ ograniči unos na samo 26 znaka. 


Na objektu za unos artikala artd_ja omogučen je unos za naziv artikla ekranski na 26 znakova. 


Molimo potvrdu o ispravnosti riješenja zadatka. 



0











Klijent: 





Hitnost: 



Višnja 


13463 

Riješen 


02.07.2013 11:57 

Upisao: 

Božo Mišeta 

Područje: 

LKROP 


31.07.2013 


Potrebno je kroz obu_pz_fk OBUSTAVE PO ZAJMODAVCIMA napraviti izmjenu na način da se prema 

izboru omogući pregled/ispis po aktivnim/neaktivnim radnicima, odnosno da se ulaskom na ekran 

obu_pz_fk Pregled Obustava Po Zajmodavcima izborom da/ne odabere prikaz aktivnih/neaktivnih radnika 

sa obustavama po izabranom zajmodavcu kao kroz objekt obu_ps_fk PREGLED PO VRSTI OBUSTAVE: 


Kod odabira objekta obu_pz_fk OBUSTAVE PO ZAJMODAVCIMA ugrađeno je i programski podržano pitanje 

kao što postoji kod objekta obu_ps_fk PREGLED PO VRSTI 

OBUSTAVE. 

Preuzeti novi krop lib od 08.07.2013 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13462 



02.07.2013 11:00 

Upisao: 

Božo Mišeta 

Područje: 

LTRAN 


05.07.2013 

Kod prijenosa klasa (tipka F1) javlja se greška 201. Molim da je ispravite. 




0









Napravljena je izmjena kod prijenosa klasa (tipka F1). 

Potrebno je provjeriti dali se opet javlja greška 201. 

Sutra ujutro (10/07/2013) bit će dostupan novi LAUS TRAN lib. 


Po vašem nalogu zatvaramo ovaj zahtjev. 

Poštovani! 


Lp, 


Poštovani, 

Zahtjev zatvaramo uz vašu suglasnost - Riješen . 

Utvrđeno je da se greška -201 (Syntax error) javljala zbog 2-stukih navodnika u nazivima klasa : 

qklasa qnaziv 

6030501 KUTIJE TIPIZIRANE ZA PAKETE "BELIćE" 

6030502 KUTIJE TIPIZIRANE ZA PAKETE "LOVINŹI" 

6030503 KUTIJE TIPIZIRANE ZA PAKETE "NARODNE NOVINE" 

605542 ULAZNICE - "LUDBREćKO SUNCE" 

Predložili smo načine rješavanja : 

a) ukloniti navodnike iz naziva klasa 

b) na bazi laus izvesti :update ac_klasa set prebacen='X' where prebacen='N' and naziv like '%"' 

pa onda pustiti prijenos klasa . 

Odrađena je opcija b) i pušten prijenos. Uredno prošao. (Katja) 

Napomena : gore naveden klase nisu prenešene u AC jer u prijenos ulaze samo oni slogovi iz ac_klasa sa 

prebacen=N. 

Nakon sređivanja naziva potrebno je za njih postaviti prebacen X--->N i pustiti prijenos da se i one prenesu . 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Višnja 


13461 



02.07.2013 10:44 

Upisao: 

Božo Mišeta 

Područje: 

EPNAB 


04.07.2013 


Dva ugovora po okvirnom sporazumu: 

Broj ugovoraLaus brojDatum sklapanja ugovoraNaziv ugovoraNaziv ponuditeljaUgovorena cijena bez PDV 

Ugovor vrijedi odUgovor vrijedi doStatus 

HP-10/1-005410/1303269-R13-0000617.6.2013.Usluge deratizacije i dezinsekcijeADRIA GRUPA D.O.O. 

193.357,8614.6.2013.14.6.2014.POSLAN_U_LAUS 

HP-10/1-005690/1303269-R13-0000527.5.2013.Nabava rezervnih dijelova iza održavanje pokretnih traka 

za transport vreća i paketa - Ugovor #1STI.M D.O.O.399.821,5027.5.2013.27.5.2014.POSLAN_U_LAUS 

nisu dobili ispravan LAUS broj. 

Jedan ugovor je od Ureda za korporativnu sigurnost, a drugi je od Sektora sortiranja…predbroj LAUS broja 

koji oni imaju (03269) se odnosi na Ured za javnu nabavu. 

Dosad su svi ugovori imali predbroj Tehničkog nositelja kojemu pripadaju, a tako bi trebali i ugovori po 

okvirnom sporazumu. 

Molimo žurno rješavanje. 



0









Poštovani, 

Do potrebe za zahtjevom 13461 došlo je posljedično na temelju HP zahtjeva 12603.8. Tamo je na zahtjev HP-a 

dogovoreno da će se podatak o tehničkom nositelju ukloniti s forme dokumenta. Podatak o tehničkom nositelju 

temelj za određivanje oznake koja će biti dodijeljena dokumentima u Laus sustavu. 

Na temelju navedenog stav Dokument IT-ja je da je riječ o adaptivnom zahtjevu s procjenom od 4 radna sata. 


Poštovani, 

Nismo dobili potvrdu da je HP prihvatio ovo kao adaptivno održavanje. 

Danas su na sastanku potvrđeno je 4h adaptivnog održavanja. Ukoliko takva obavijest postoji potrebno je 

proslijediti je u Dokument IT. 



Poštovani, 

Ovaj zahtjev je riješen i prebačen na test. Na ekran ugovora po okvirnom sporazumu i narudžbenice po 

okvirnom sporazumu dodano je polje Tehnički nositelj. Prilikom dodavanja ugovora ili narudžbenice, u polju 

Tehnički nositelj se prikazuje podatak iz polja Naziv podnositelja Zahtjeva – Tehničkog nositelja s odabranog 

okvirnog sporazuma, ali je ostavljena mogućnost editiranja tj. da se odabere neki drugi tehnički nositelj. To je i 

bio razlog da su LAUS brojevi dobivali predbroj Ureda za javnu nabavu (jer je ona i sačinjavala taj ugovor). 

PITANJE: Da li ćemo na produkciji za ova dva postojeća ugovora po okvirnom sporazuma iz zahtjeva (HP-10/1- 

005410/13 i HP-10/1-005690/13) mijenjati LAUS broj i ako da u koji. 

Lp, 


Poštovani, 

Kako bismo riješili navedenu problematiku s prijenosom podataka o narudžbenicama po OS potreban nam je 

odgovor na pitanja po zahtjevu 13467 koja smo vam poslali 8. srpnja. 






0











Klijent: 





Hitnost: 

Vrlo hitno 


Glorija 


13460 



02.07.2013 10:09 

Upisao: 

Božo Mišeta 

Područje: 

LCSBI 


02.07.2013 


Ne može se u excelu otvoriti izvještaj eksportiran iz BexWeb-a. Sustav ne prepoznaje korisnika, tj. ne 

prihvaća korisničko ime i lozinku. 


Poštovani, 

ovo je ponovljeni zahtjev od 10.7.2012. godine (laus broj 37242 sada smo mu dodali i Vaš broj 13460). 

"Učitavanje exporta iz bexWeba u obliku „excela“ u Excel – neupotrebljivo je. Traži login i password za svaku 

sliku koja postoji u tom de facto html fileu. Budući da ih ima na desetke, onda traži desetke puta login i pwd. 

Provjereno problme je upravo u tome.". 

Na žalost nismo u mogućnosti ponuditi izravno rješenje. samo zaobilazno: otvaranje datoteke u text editioru i 

uklanjanje linkova na sliku koja stvara problem (it podrška to treba učiniti). 

prema zadnjim informacijama kao jedno od rješenja instaliran je BexAnalyzer za Excel, a početkom ove godine 

neslužbena informacija je da nije prikladan za neke potrebe analize. Možete li možda opisati u kojim slučajevima 

nije prikladan pa da to možda bude put ka rješavanju ovog problema... 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13459 

U rješavanju 


02.07.2013 07:09 

Upisao: 

Božo Mišeta 

Područje: 

LTRAN 


03.07.2013 


Kod izračuna kalkulacije za npr. artikal 311957, zbog zaokruživanja (na dvije decimale) dolazi do razlike u 

MPC bez PDV-a. 

Kada se NC zbroji sa provizijom, dolazi do razlike u MPC bez PDV-a za jednu lipu i takva cijena se prenosi 

u mips_laus bazu što nije dobro (64.58 + 59.14=123.72, provizija treba biti 59.13 a MPC bez PDV 123.71) 

Potrebno je da zboj NC i provizije odgovara MPC bez PDV-a 


Poštovani, 

navedeni tip kalkulacije prilikom zaokruživanja na dvije decimale, ponekad iskazuje razliku kad se zbrajaju 

zaokružene vrijednosti. 

Razlog tome je matematička pravilnost. Kako nebi dolazilo do odstupanja, potrebno je da nam odredite na koju 

vrijednost u kalkulaciji treba razlike zbog zaokruživanja dodati ili oduzeti (MPC bez PDV-a, PDV, MPC s PDVom, 

provizija, NC, PDV na NC, Fakturna cijena). 

Uobičajeno je da se razlika stavlja na proviziju (umanjuje ili povečava provizija) - konzultirati knjigovodstvo 

S štovanjem 


Kod kalkulacije tipa HP2 razlika zaokruživanja zbroj nabavne i provizije sa maloprodajene dolazi kod 

prikazivanja same cijene na 2 decimale dok prava cijena koja se nalazi u kalkulacije upisana je sa 4 decimale 

polje iznos u tablici kalka za pojedini kalkulativni element. Uz tu cijenu sa 4 decimale postoji i cijena na 6 

decimala polje iznos_d . 

Prema tome dali je potrebno uopće raditi izmjenu i kako na samoj kalkulaciji ili samo prilikom prijenosa hp_lm_jtr 

PRIJENOS ŠIFARNIKA U MIPS odnosno cjenika/cijena te tamo razliku staviti na proviziju. 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Višnja 


13457 



01.07.2013 13:29 

Upisao: 

Božo Mišeta 

Područje: 

EPNAB 


03.07.2013 


Pojavila su se 2 buga koja onemogućavaju normalno funkcioniranje aplikacije. 

Kroz: Bagatelna nabava, Postupci nabave, Nabava po grupama … 

a.Ako se nalazimo u gridu Uređivanje spisa po gore navedenim tabovima – Tražilica ne radi, odabirom bilo 

kojeg kriterija u pregledu su uvijek svi spisi 

b.Rebalans – Uređivanje predmeta nabave – Nabava po grupama…prilikom označavanja grupe za 

uređivanje pojavljuje se „znak“ Učitavam koji neprestano traje tj. nikada ne dohvati tu grupu. 

Taj problem se pojavljuje kod sva 3 browsera. 

Molimo hitno rješavanje tog problema. 



0









Poštovani, 

Dio po b. iz ovaj zahtjev je prebačen na test. Otklonjen je problem pojavljivanja poruke „Učitavam“ koji se javljala 

prilikom označavanja grupe u rebalansu plana nabave u uređivanju predmeta nabave po grupama. Ukoliko se 

nekom korisniku i dalje pojavljuje ovaj problem, potrebno je očistiti cache memoriju. 

Lp 


Poštovani, 

Dio po a. iz ovog zahtjeva je prebačen na test. Sada radi tražilica u Uređivanju spisa u tabu Spisi i Arhivirani 

spisi u bagatelnoj nabavi, postupku nabave i nabavi po grupama. 

Lp 


Poštovani, 

vezano za : zahtjev izmjenu pod a.) danas staviti na produkciju.Na testu radi. 

Molimo uvažite pojašnjenje koje slijedi . 

Kada se prebacuje testna verzija ona ide 100% takva kakva je na produkciju. Da bi u budućnosti uklonili 

nesporazume i probleme koji se javljaju nakon prebacivanja, ne smijemo dopustiti da se na produkciju prebaci 

verzija a na testnoj još uvijek traje testiranje nekih drugih zahtjeva. 

Događa se da se na test isporuči verzija, u međuvremenu dođu novi zahtjevi koji se odrade i prebace na test, a 

prvo testiranje nije završeno. U tom slučaju nije moguće prebaciti na produkciju samo zahtjeve iz prve faze 

testiranja. 

Zato ne može danas ići na produkciju izmjena pod a) 

Dizat ćemo na produkciju kada se potvrdi da se mogu prebaciti svi zahtjevi koji su još na testu : 

13132.1 

13132.11 

13132.13 

13457 dio pod b) 


Ovaj zahtjev (obje točke zahtjeva) je prebačen na produkciju. Molimo potvrdu zatvaranja zahtjeva. 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Glorija 


12317 

Riješen 


01.07.2013 07:21 

Upisao: 

Božo Mišeta 

Područje: 

LROBD 


01.07.2013 


Potrebno grešku hitno otkloniti jer 01.07.2013 počimlje listanje dokumenata ambulatne dostave. 

vidi prilog - greška -284 


Isparavljeno je filter polje analitika na pregledu mips dokumenta mipsprdok_trn. 

Potrebn oje preuzeti win tran lib koji je već na internetu. 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Glorija 


13456 

Riješen 


28.06.2013 14:40 

Upisao: 

Božo Mišeta 

Područje: 

LROBD 


05.07.2013 


U izvještaj sidok_rd.txt ubačen je stupac procijenjene vrijednost. Trebalo bi i u excel-dat za SIM/SIV ubaciti 

stupac procijenjena vrijednost. 


Na obejktu sidok_jd PREGLED SI PO DOKUMENTIMA odnosno excel ispis sidok_xls_rd za vrstu dokumenta 

SIM/SIV dodan je stupac procijenjena vrijednost. 

Potrebno je preuzeti lasu libove rob0,rob1,rob2,rob3 i rob4 koji će biti na internetu 2.7.2013. 



0











Klijent: 





PDV 2013-07 

Hitnost: 

Vrlo hitno 


Glorija 

13455 

Riješen 


28.06.2013 14:37 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


01.07.2013 




0









Zbog izmjene Zakona o PDV-u potrebno je napraviti sljedeće izmjene u aplikaciji vezane za izdavanje 

računa u valuti (izvoz): 

•U šifarniku država potrebno dodati indikator da li država pripada EU ili ne (može se realizirati kroz isti 

šifarnik ili nova vezna tablica za zemlje EU). Po defoultu staviti taj indikator na N, a mi ćemo provesti 

izmjene na D. 

Kod izrade računa i predračuna razlikovati ćemo 4 slučaja kupca i preme tome kreirati račune i predračune. 

A) Slučaj TREĆE ZEMLJE (ne-EU) – POREZNI OBVEZNIK - oslobođeno PDV-a kao izvozna isporuka 

B) Slučaj TREĆE ZEMLJE (ne-EU) – FIZIČKA OSOBA - oslobođeno PDV-a kao izvozna isporuka 

C) Slučaj EU – POREZNI OBVEZNIK - oslobođeno PDV-a kao isporuka dobara unutar EU 

D) Slučaj EU – FIZIČKA OSOBA - oporezivo hrvatskim PDV-om sve dok se ne prijeđe prag isporuke u 

pojedinoj zemlji EU 

•Da li poslovni partner porezni obveznik ili fizička osoba razlikovati će se preko dodatnog podatka za 

partnera VAT (porezni broj). Ukoliko ima upisan smatra se poreznim obveznikom i ne zaračunava mu se 

porez unutar HR, te se na računu kao i do sada ispisuje njegov porezni broj (VAT number). 

PREDRAČUN (PID) 

Kod slučajeva A, B i C ostaviti dosadašnji način izrade i ispisa predračuna tj. kupcima se ne zaračunava 

PDV i nigdje se ne iskazuje. U slučaju D potrebno je računati porez na svakoj stavci robe 25% (ne usluge). 

Sam izgled predračuna se ne mijenja osim u donjoj rekapitulaciji dodaje je sumarni porez, koji naravno 

povećava i ukupni iznos predračuna za platiti. Znači valuta u prikazu je samo euro, izgled donjeg dijela 

predračuna 

RAČUN (IRI) 

SUB TOTAL 728,00 

VAT (25% ) 182,00 

POSTAGE DUES 7,00 

TOTAL 207,00 

Kod slučajeva A, B, C račun će ostati kao a dosada tj. nema iskaza PDV-a, ali će se na računu morati 

prikazivati iznosi i u kunama. Preračun u kune će se raditi po srednjem tečaju HNB-a na datum izrade 

računa (Document date). Znači postojeći račun potrebno preurediti za ove slučajeve. 

Izgled stavke računa 

Ordinal number Title Service code Quantity Price (misli se na eur ili dolar) pa staviti kraticu i valute Price 

HRK (može i PRICE gore) DISCOUNT - ovo gornji red a dolje % , amount EUR , amount HRK , AMOUTN 

– gornji red a dolje Amount EUR Amount HRK 

Izgled rekapitulacije 

SUB TOTAL 6,12 0,82 

POSTAGE DUES 29,84 4,00 

TOTAL 35,96 4,82 

Na dnu računa ispod Napomena (jedan red prazno) potrebno je u slučajevima A i B ispisivati sljedeće: VAT 

exempt pursuant to Article 45 of the Value Added Tax Act. Kod slučaja C ispisivati: VAT exempt pursuant to 

Article 41, paragraph 1, item a) of the Value Added Tax Act, a ispod toga “reverse charge”. 

U slučaju računa D potrebno je računati na stavci PDV za robu. Napraviti drugi oblik računa i kod njega 

izbaciti na ispisu DISCOUNT. 



0







Izgled stavke -završen, računa Isporučen - Korisnik potvrdio ispravnost 

Ordinal number Title Service code Quantity Price (misli se na eur ili dolar) pa staviti kraticu i valute Price 

HRK Amount HRK Amount EUR 

Izgled rekapitulacije 

Neriješeno pitanja: 

SUB TOTAL 6,12 0,82 

VAT (25%) 1,57 0,26 

POSTAGE DUES 29,84 4,00 

TOTAL 37,53 5,03 

1)Usluga poštarine ili žigosanja u sustavu su oporezive tj. u kalkulaciji imaju pridruženo 25%. Da li i na njih 

u slučaju 4 treba računati pdv ili ne kao i do sada? 



0









Šifarnik država je proširen s podatkom dali je država članica EU. 

Već je na internetu novi LAUS/TRAN i WIN/BASE lib. 

Odraditi sql: 

alter table drzava add ( 

eu char(1) ) ; 

update drzava set eu = 'N'; 


Poštovani, 

Pitanja vezano za slučaj pod D) i to vezano za obračun poreza : 

a) računati porez na svakoj stavci robe 25% bez obzira po kojoj stopi je roba oporeziva u RH ? 

b) Usluga poštarine ili žigosanja u sustavu su oporezive tj. u kalkulaciji imaju pridruženo 25%. pa treba računati 

pdv po stopi 25 kao i za POSTAGE DUES oporezivo po 25% . 

Na sve usluge računati porez 25% čak iako su neoporezive ili imaju drugu stopu različitu od 25 ? 

ili treba : 

računati porez po istom principu kao da je isporuka unutar RH (krajnji kupac) tj. primjeniti važeći porezni 

tretman/stopu za robu/uslugu ? 



0









Poštovani, 

Molimo pošaljite primjere ispisa računa za filateliju ( stvke, zbrojevi, napomene - kompletne račune) kako 

trebaju izgledati obzirom na 3 različita porezna tretmana takvih računa . Iz poslanog u zahtjevu te naknadnih 

pojašnjenja ne može se zaključiti kako treba izgledati račun u cjelosti, posebno stavke za porezni tretman 3 . 

Status : čekamo primjere računa i potvrdu navedenog dolje 

--Pitali smo : 5.7.2013 

Pitanja vezano za slučaj pod D) i to vezano za obračun poreza : 

a) računati porez na svakoj stavci robe 25% bez obzira po kojoj stopi je roba oporeziva u RH ? 

b) Usluga poštarine ili žigosanja u sustavu su oporezive tj. u kalkulaciji imaju pridruženo 25%. pa treba računati 

pdv po stopi 25 kao i za POSTAGE DUES oporezivo po 25% . 

Na sve usluge računati porez 25% čak iako su neoporezive ili imaju drugu stopu različitu od 25 ? 

ili treba : 

računati porez po istom principu kao da je isporuka unutar RH (krajnji kupac) tj. primjeniti važeći porezni 

tretman/stopu za robu/uslugu ? 

--HP Odgovor na neriješeno pitanja: 8.7.2013. 

Usluga poštarine ili žigosanja u sustavu su oporezive tj. u kalkulaciji imaju pridruženo 25%. Da li i na njih u 

slučaju 4 treba računati pdv ili ne kao i do sada? U slučaju fizičke osobe u EU PDV se obračunava i na 

poštarinu. 

--8.7.2013. (sastanak Horvatova) te 9.7.2013 ( sastanak Jurišićeva) HP stav : 

U slučaju fizičke osobe u EU PDV se obračunava na sve usluge i robe po stopi 25% . 

Fizička osoba u EU je svaki kupac koji nema VAT number (porezni broj) . 

Dakle, postoje 3 porezna tretmana vezano za kupce filatelije izvan RH : 

1. Kupac izvan RH i izvan EU - nema poreza (izvoz kao i dosad ). 

Nije stupac 8 knjige I-RA (kao dosad) nego stupac 15 nove knjige I-RA od 01.07.2013. 

2. Kupac izvan RH unutar EU i IMA VAT number (porezni broj) - nema poreza (nije izvoz kao dosad nego 

isporuka roba unutar EU s reverse charge) . 

Nije stupac 8 knjige I-RA (kao dosad) nego stupac 9 nove knjige I-RA od 01.07.2013.. Napomena : reverse 

charge 

3. Kupac izvan RH unutar EU i NEMA VAT number (porezni broj) - ima porez na sve 25 % tj. tretira se kao 

fizička osoba (nije izvoz kao dosad nego 

isporuka roba unutar EU bez reverse charge tj. RH obračunava hrvatski PDV i za iznos PDV-a uvećava 

iznos računa ) 

Nije stupac 8 knjige I-RA (kao dosad) nego stupci 21 i 22 ( osnovica i PDV za stopu 25) nove knjige I-RA od 

01.07.2013. 

Za porezni tretman pod 3. obevzno se iskazuju stavke i ukupni iznosi u kunama , na kraju računa zbirni iznosi 

osnovice i poreza te ukupno i u stranoj valuti Poželjno u napomeni naznačiti tečaj po kojem je preračun ( devize- 

->kune ) izvršen . 


Napravljene su sve izmjene na objektu za devizne račune. Ispis je napravljen prema zadnjoj dostavljenoj verziji. 

Instalacija: novi WIN FAUS lib je već na internetu 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Glorija 


13454 

Riješen 


27.06.2013 13:20 

Upisao: 

Božo Mišeta 

Područje: 

LROBD 


10.07.2013 


Za upisano skladište potrebno je dati pregled artikala i ispis koji imaju definiranu minimalnu količinu, a 

stanje na skladištu im je manje od te minimalne količine. 


Na objektu MIN, MAX, OPT Količine Artikala Na Skladištu artmm_ul_ja dodana je funkcijska tipka F7((PR-MIN) 

gdje se za određeno skladište ispiše se na pregledu i ispisu artikli kojima je stanje na skladištu manje od 

minimalne količine. 

Lib je već preuzela HP (zakašnjela obrada zahtjeva) 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Glorija 


13453 



27.06.2013 13:13 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


10.07.2013 


Kada se radi unos računa sa otpremnice u kojoj je analitika generička šifra potrebno je prenijeti polja naziv, 

adresa, država, grad sa narudžbenice s time da polje VAT nije obavezno i kao takvo unijeti na račun. Do 

naružbenice se dolazi preko otpremnice. 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Glorija 


13452 



27.06.2013 10:57 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


10.07.2013 


Potrebno dostaviti rok isporuke za zahtjev PO SVIM TOČKAMA tj. molimo da isporuka bude kompletna i 

cjelovita. 

1.Popraviti filtriranje na objektu „webgrupa_fas“ 

2.Ne osvježava formu „veza artikl – Internet trgovina“. Kod unosa novog podatka stoji stari podatak i to 

zbunjuje u radu, ne čisti nazive kada se izbriše neki podatak za pretraživanje 

3.Postavit default za djelatnike filatelije „domaće i strano“ znači omogućiti vezivanje korisnika sa dodatnim 

podatkom npr. TRZ Tržište i ovisno o prijavljenom korisniku stavljati defoult 

4.Kod pretrage po grupama velika slova su po „defaultu“ 

5.Na formi za vezu artikla i Internet trgovine ne prenose se podatci u“ gridu s podacima“ koji imaju 

parametar „upisani / neupisani“. Povratom s atributa mora biti upisan filter 

6.Treba ubaciti pretraživanje artikla prema komercijalnom nazivu za filateliju – dodatni podatak HRV za 

artikal 

7.Kod podataka za artikal dolje staviti i šifru i naziv dobavljača za taj artikal 

8.Maknuti stanje na ostalim skladištima (najveća 3) već staviti da se vidi stanje po svim depoima (gdje 

količina nije 0) i PU (količina != 0) 

STANJE 

DEPO --- otvori se ekran sa stanjem u svim depoima != 0 

PU --- otvori se ekran sa stanjem u svim PU != 0 

9.Potrebno na posebnu tipku Kontrola MIN dati prikaz svih artikala koji su upisani na WEB-u aktivni, a 

stanje na web skladištu je ispod definirane minimalna količine za web skladište 



0











Klijent: 





Hitnost: 



Glorija 


13451 

Riješen 


26.06.2013 09:45 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


20.07.2013 


Na objektu rekuslN.jas REKAPITULACIJA PO USLUGAMA omogućiti pregled 

za zadani poštanski ured, za sve usluge na pregledu. 

Sada se na rekapitulaciji dobiju sumarni podaci za zadano razdoblje za sve poštanske urede. Za potrebe 

kontrole knjiženja prometa pojedinih poštanskih ureda potrebno je omogućiti pregled podataka za 

pojedinačni poštanski ured. 


Na objektu rekuslN.jas REKAPITULACIJA PO USLUGAMA na pregledu po artiklima omogućen je pregled za 

zadani poštanski ured, za sve usluge na pregledu. 

Novi WIN FAUS lib je na internetu. 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Glorija Markovac 


(prilog) 

13450 



21.06.2013 14:49 

Upisao: 

Boško Tokić 

Područje: 

EOBRRAC 


21.06.2013 


Primka je I eObradu 14.06.2013 otišla sa akcijom D i aktivnost stavljena na N I više ne može prijeći u mila 

bazu. Potrebno je primku probaciti u eObradu. 



0









Poštovani, 

Za spornu primku u primka_eolog u MIPS bazi zadnji zapis je da je neaktivna (ne postoji) : 

id protokol dobavljac akc datum_preuzimanja s akt 

126194 46283-P13-01010 642808 I 2013-06-14 12:24:03 1 D bilo ranije 

126225 46283-P13-01010 642808 D 2013-06-14 12:24:09 1 N bilo ranije 

Prijenos zapisa iz laus baze u MIPS bazu ne može se postići upis sloga u MIPS bazu kojim bi se ova primka 

aktivirala (postoji) : 

--jer je već jednom upisana . 

-- jer nije dozvoljena /moguća izmjena primke koja je neaktivna 

Radi gore navedenog i traženog da se zahtjev riješi hitno kroz MIPS bazu smo upisali za ovu primku 2 nova 

zapisa 

(akcija I-insert i U-update) sa aktivnost=D : 

127098 46283-P13-01010 642808 I 2013-06-21 15:52:31 1 D ubacila u bazu sa akcija=I ,aktivnost=D 

127099 46283-P13-01010 642808 U 2013-06-21 15:52:31 1 D ubacila u bazu sa akcija=U ,aktivnost=D 

Molimo provjerite vidi li se sad primka u eObradaRačuna 

Molimo povratne informacije/ suglasnost za zatvaranje zahtjeva riješen 


Poštovani, 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Glorija 


13449 

U rješavanju 


20.06.2013 07:30 

Upisao: 

Božo Mišeta 

Područje: 

LROBD 


26.06.2013 


Ponovno aktivirati analitiku L za potrebe inventure, podatak koji bi pobliže opisivao analitiku R,O i S. 

Za lokacije ureda kao i analitiku S trebalo bi iskoristiti podatke iz baze OSA,dok za diviziju podrške i urede 

uprave treba vidjeti da li možemo što automatizirati ili ručno unijeti 

Kod ispisa inventurnih listi omogućiti ispis po: 1. Lokacija 2.Org.jed. 3. Analitika R i S 

Ukoliko zahtjev prelazi 40 sati potrebna procjena i opis promjena unutar aplikacije koje bi s provodile. 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Glorija 


13448 



20.06.2013 07:27 

Upisao: 

Božo Mišeta 

Područje: 

LSLOD 


26.06.2013 


Na objektu invs_fi inventarna lista za si kod djelatnika omogućiti ispis redom po MT sve tri diviziie ,kao kod 

sitnog inventara 

Na objektu invs_fi objekti invs_ri Inventarna lista za si i invsr_ri Inventarna lista za si bez stanja redoslijed 

ispisa po mjestu troška,a unutar njega po divizionom ustroju npr. 51260 PU CRIKVENICA ispis po 

11932,21103,31843,nakon toga slijedeće MT….. 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Glorija 


13447 

Riješen 


20.06.2013 07:24 

Upisao: 

Božo Mišeta 

Područje: 

LROBD 


26.06.2013 


Na objektu sidok_jd dodati stupac procijenjena vrijednost 

Razlog - kod nastanka viškova i manjkova na inventuri nemamo nigdje zbirni izvještaj o tome. S obzirom da 

postoji mogućnost osim nabavne vrijednosti unijeti i procijenjenu vrijednost/na prijedlog tehničkih nositelja/ 

potrebno je i imati i takav izvještaj. 



Na objekt sidok_jd PREGLED SI PO DOKUMENTIMA odnosno sidok_rd dodan je stupac procjenjena vrijednost 

za dokumente SIM/SIV (zapisnik višak/manjak po inventuri SII u upotrebi). 



0











Klijent: 





Hitnost: 

Vrlo hitno 




13446 



19.06.2013 15:24 

Upisao: 

Božo Mišeta 

Područje: 

LFINK 


26.06.2013 


Molim da se postavi automatska uputa za knjiženje uplate po žiro računu HR1623900011100018674 

Uplate s oznakom poziva na broj: 01 – oznaka poštanskog ureda – DDMMGGGG-647266 knjižiti na konto 

259905, potražno, na P 647265, nivo 00000, u opis poziv na broj odobrenja. 


Poštovani, 

Program za automatsko knjiženje je prilagođen za knjiženje prema formatu poziva na broj odobrenja 01 – 

oznaka poštanskog ureda – DDMMGGGG-647266 prema traženim uputama. 

U uputama za automatsko knjiženje izvoda potrebno je upisati novu uputu točno prema uzoru na već upisanu 

uputu za poziv na broj odobrenja 01-618754 sa pozivom na broj odobrenja 01-647266. 


Obavijestiti korisnika o pruzimanju novog LAUS FINK liba koji je već na internetu 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13445 

Riješen 


19.06.2013 09:58 

Upisao: 

Božo Mišeta 

Područje: 

LROBD 


21.06.2013 


Ograničenja u aktivaciji asortimana 

a. Prilikom izrade asortimana, a prije statusiranja i stavljanja u aktivni status provjeravati vrijeme 

statusiranja. U slučajevima kada je pokušaj statusiranja u vremenu prije 13 h, aktivaciju asortimana provesti 

po modelu „datum statusiranja + 1“, no ukoliko je pokušaj statusiranja nakon 13 h aktivaciju asortimana 

onemogućiti, zatražiti promjenu datuma početka važenja. U drugo opisanoj situaciji postaviti model „datum 

statusiranja +2“. 


Prilikom aktiviranja asortimana na objektu asort_ja odnsono njegovog prebacivanja u status 2 uvedena je 

kontrola da datum od mora biti barem jedan dan mlađi od trenutnog odnosno dva dana ako radi aktivacija 

asortimana nakona 13:00 sati. 

BASD lib je prenesen na TESNU bazu HP-a. Obavezno nakon testiranja uputiti zahtjev i naložiti spuštanje na 

produkciju. 


Bae prebačen u produkciju prema zahtjevu. 

Molimo potvrdu radi zatvaranja zahtjeva. 

S štovanjem 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13444 



19.06.2013 07:42 

Upisao: 

Božo Mišeta 

Područje: 

EHPUR 


21.06.2013 


U aplikaciji eHPUR nije evidentiran urudžbeni broj DPO-05/2-012342/13 koji je otvoren 23.5.2013. godine, 

odnosno isti je aplikacija promijenila u DPO-05-011924/13 , tako da sada postoje dva ista broja 011924/13. 

Potrebno je urudžbeni broj DPO-05/2-011924/13 promijeniti u DPO-05/2-012342/13, a u „Dnevniku rada“ i 

u „Surješeni spisi“ spisa koji su surješavani spajanjem spisa: DPO-5/2-022984/12; DPO-5/2-018670/12; 

DPO-5/2-00977/12 i spisa koji je surješen ponovnom evidencijom DPO-05/2-008025/12 također treba 

promijeniti ur. broj DP0-05/2-11924/13 u urudž. broj DPO-05/2-012342/13. 



0









Poštovani, 

Molimo Vas 02.07.2013. pristup produkciji kako bismo izvršili korekcije, a vezano za zahtjev 13444. 

Pristupati će Tvrtko Matošević. 


Imamo li pristup? 

Branka Gorup Ladović 


Poštovani, 

Izvršene su korekcije na spisima sukladno Vašim zahtjevima. 

Lp, 


Poštovani, 

po vašem nalogu zatvaramo zahtjev. 

Poštovani, 

Možete zatvoriti zahtjev. 

Lp, 



0











Klijent: 



Pitanje 


Hitnost: 

Vrlo hitno 




13443 



18.06.2013 15:45 

Upisao: 

Boško Tokić 

Područje: 

LROBD 


18.06.2013 

Kada se dokument prebacuje u status 7 (iz 1) javi se nevedena poruka: 

Vrsta analitike ne odgovara definiranoj u uputstvu P i onda (prilog) 




0









Poštovani, 

usporedbom produkcijske i tesne baze (na kojoj se ne javlja navedena greška) pronašli smo samo razliku 

u uputama (panther) za dokumenat RZP na objektu protup_ff Upute za evidentiranje objekata. U polju analitika 

treba stajati oznaka ? - sve analitike. 

Pojašnjenje: dokumenat RZP zapisnik o razlikama nastaje sa različitih robnih dokumenata. Npr. sa RPP primke 

gdje je analitika P - poslovni partner, sa RPM povrat iz PU gdje je analitika O - organizacijska jedinica.Kako je 

riječ o različitim analitikama obavezno treba staviti indikator ? - sve analitike. 

Drugo pitanje je da li je potrebno aktivirati proceduru generiranja dokumenta RZP na primci, povratu, 

međuskladišnici, itd.... 

Traženi dokumenat RZP napravljen je još prošle godine, a njegovo stavljanje u upotrebu vezano je sa zahtjevom 

da se identičan dokumenat napravi i u PU (Mips), radi jednoobraznog tretiranja problema razlika pri isporuci. 

Neznam u kojoj fazi je izrada istog dokumenta u PU, ali na obuci od 18/06 

dobio sam uvjeravanje od kordinatora skladišta da to mora biti gotovo i u upotrebi prije inventura (po meni 

prekasno). Jer izradom fiktivnih dokumenata radi ispravljanja grešaka pri neisporuci ugrožava se točnost 

inventure, knjigovodstvenih izvještaja, kao i točnost napravljenih komercijalnih lista i izvještaja. 

Molim vas za potvrdu stavljanja ovog zshtjeva u status riješen. 

S štovanjem 


Po vašem nalogu zatvaram zahtjev. 

S štovanjem 

Poštovani! 

Možete zatvoriti ovaj zahtjev. Vrsta održavanja: bug /nepravilan rad - korektivno. 

Lp, 



0











Klijent: 





Hitnost: 

Vrlo hitno 




13442 

U rješavanju 


18.06.2013 14:20 

Upisao: 

Boško Tokić 

Područje: 

WINTRAN 


25.06.2013 


Ako je u polju Naručitelj generička šifra (definirana parametrom POSPA) onda OIB nije potrebno tražiti – 

maknuti poruku. Naziv objekta izmijeniti u NARUDŽBENICA, jer se ne odnosi samo na katalošku. 

(prilog) 



0











Klijent: 





Hitnost: Očekivani datum rješenja (klijent): 

Vrlo hitno 




GREŠKA: Loše polje ili argument, ... 

(prilog) 

13441 

Riješen 


18.06.2013 13:24 

Upisao: 

Boško Tokić 

Područje: 

LROBD 



Ispravljen je pregled min i max količina artikala. 

Nije potrebno preuzimati lib-ove! 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja Kraljev 


13440 

Riješen 


18.06.2013 13:19 

Upisao: 

Boško Tokić 

Područje: 

LROBD 


22.06.2013 


Uvođenjem pozicije BAR-KODA molim da se na dokumentima RIM i RPM prema pretpostavljenom unosu 

omogući pozicioniranje kursora na polje ŠIFRE ARTIKLA, a unos po barkodu da se omogući proizvoljno 

odnosno po potrebi. Pozicija za upis barkoda neka ostane iznad šifre artikla. 



Na dokumentima RIm Izdatnica u maloprodaju i RPM Povrat robe iz maloprodaje pri otvaranju ekranu stavke 

RIMst_fd,RPMst_fd kursor je poziciniran u polje artikal te je omogučen bez upisa šifre artikla pozicioniirat se na 

polje Bar-kod . 



0











Klijent: 





Hitnost: 

Vrlo hitno 




13439 



17.06.2013 15:36 

Upisao: 

Boško Tokić 

Područje: 

LWINFAU 


17.06.2013 


18.06.2013 

Na objektu razduženje za prodanu komisionu robu i marke, u automatsko knjiženje osim vrste dokument 

FAP I ODO, dodati i vrstu dokumenta FAS. 


Poštovani, 

Na objektu razduženje za prodanu komisionu robu i marke, u automatsko knjiženje nadodana je i vrsta 

dokumenta FAS. 


U srijedu 19.06.2013 bit će dostupan novi WIN FAUS lib. 



Po vašem nalogu, zatvaramo zahtjev. 

Zahtjev možete zatvoriti. 

Lp 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Ivan 


13438 

Riješen 


17.06.2013 09:20 

Upisao: 

Božo Mišeta 

Područje: 

LFINK 


17.06.2013 


Molim analizu i ispravak podataka koji su završili u greškama kod pripreme kartice kupca(bss_kart_jf). To je 

većina podataka iz naloga koji je LAUS punio kroz bazu. 

Podaci koji su u greškama: 

select * from bss_priprema where date(datum_pripreme)='15.06.2013' and status='G' and 

nalogk='13E50090'; 



0









Poštovani, 

Molimo suglasnost za zatvaranje zahtjeva - Riješen 

kao i za promjenu vrste održavanja korektivno ---> perfektivno. 

Analizom je utvrđeno da se ne radi o programskoj greški nego postupanju sa stavkama naloga 13E50090 . 

Utvrđeno da je nalog 13E50013 obrisan nakon što su stavke poslane. u bss. 

Potom je ponovo puštena priprema u koju su ušle novknjižene stavke. Većina je završila u greškama : različit 

opis, iznos analitika,..u odnosu na već poslano za nalogk i red 

Potrebno uskalditi stavke naloga 13E50090 u arhivk i bss_poslano tj. bss_priprema . 

Prijedlog : 

a)Obrisati iz bss_poslano te iz bss_priprema sve što se odnosi na nalogk 13E50090 pa pustiti pripremu 

ponovno 

– ovo treba dogovriti sa BSS da i oni učine isto 

b)Rekonstruirati nalog 13E50090 iz bss_priprema tako da se u njega stave stavke koje su u bss_priprema sa 

status=D i datum perfektivno 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Ivan 


13437 



14.06.2013 10:58 

Upisao: 

Božo Mišeta 

Područje: 

LFINK 


14.06.2013 

Stavke sa uslugom 9203 završile su u greškama na donjim računima. 

Bss_laus produkcijska baza 

select * from bss_zaglavlje where brdok in ( 

'100029920130501', 

'100004720130501' , 

'100025520130501' ); 

select * from bss_stavke where brdok in ( 

'100029920130501', 

'100004720130501' , 

'100025520130501' ); 

LAUS produkcijska baza 

Razlika je između donjih usluga u SS parametru. 

select * from lm_usluga where usluga in ('9203','9907'); 

select * from lm_usl_dod where usluga in ('9203','9907'); 

select * from lm_usluga_cij where usluga in ('9203','9907'); 




0









Poštovani, 

Zahtjev zatavramo uz vašu suglasnost ( Ivan) - Riješen . 

Računi sa slugom 9203 završili su greškama ( 024 Nepostojeĺa lm_veza za uslugu) jer u lm_veza usluge 

vrste DIG trebaju biti sa tip_slog=E a ne K 

Potrebno je 

a) upisati u lm_veza ovu uslugu sa tip_slog=E , 

b) postaviti račune (zaglavlje i stavke) ponovo za prijenos 

indikator_laus = '' 

and (korisnik_obr = '' 

and dat_vri_obr = '' 

c) pustiti prijenos ponovno 

Vrsta održavanja promijenjena KOR-->PER -nije greška u programu 



0











Klijent: 



Pitanje 


Hitnost: 



Katja 




13.06.2013 13:45 

Upisao: 

Božo Mišeta 

Područje: 

LROBD 


18.06.2013 


Obuka 18/06.2013 od 12 do 16h. Dokumenti zahtjevnica, izdatnica, zapisnik o neisporukama, generiranje 

narudžbe dobavljaču, narudžba dobavljaču. Veza ugovor po projektu E-zahtjevnica 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Ivan 


13415 

Riješen 


13.06.2013 10:46 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


15.06.2013 


13.06.2013 

U ugovor na temelju kojeg se izrađuje skupna faktura (Zagrebačka banka) nije moguće dodavati nove 

usluge. Ono što je nama vidljivo u polju po stavkama potrebno je dodati oznaku S ( poštanske usluge i 

usluge hpx), a možda treba izvršiti i neke izmjene u programu. 


U polju po stavkama nadodana je oznaka S. 

novi WIN FAUS lib je već na internetu. 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13436 



12.06.2013 15:23 

Upisao: 

Božo Mišeta 

Područje: 

EHPUR 


13.06.2013 


U aplikaciji eHPUR nakon što smo podesili margine za ispis na naljepnice više nam ne ispisuje dobro na 

obrazac omot spisa. 

Molimo da se podesi ispis na obrazac spisa. 

U prilogu dostavljamo primjer trenutnog ispisa. 



0









Poštovani, 

Prebačene su dorade po ovom zahtjevu na test. 

Molimo provjerite ispis omota spisa te ukoliko smatrate da je isti potrebno dodatno korigirati, kontaktirajte 

direktno kolegu Branimira Marjanovića na broj 091 2325 815 kako bismo skratili postupak i rješili što prije zahtjev 

na obostrano zadovoljstvo. 



Poštovani, 


Molimo provjerite ispis omota spisa te ukoliko smatrate da je isti potrebno dodatno korigirati, kontaktirajte 

direktno kolegu Branimira Marjanovića na broj 091 2325 815 kako bismo skratili postupak i rješili što prije zahtjev 

na obostrano zadovoljstvo. 

Poslano datum i vrijeme: 17.6.2013 7:26:49 

helpdesktmp@laus.hr 

support@laus.cc 

odjel.imp_ERP_rjesenja@posta.hr 

Molimo suglasnost za prebacivanje na produkciju 


Molim Vas informaciju o statusima slijedećih zahtjeva: 

* 13410 

* 13411 

* 13412 

* 13436 

* 12714, zahtjev 9 

* 12714, zahtjev 18 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Glorija 


13435 

Riješen 

rekart .jas REKAPITULACIJA PO ARTIKLIMA 


12.06.2013 14:40 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


30.06.2013 


25.06.2013 

Potrebno po uzoru na tipku Ispis napraviti takav ispis i u excelu. 


Poštovani, 

Na objektu rekart .jas REKAPITULACIJA PO ARTIKLIMA nadodana je nova tipka Ispis Excel. 

Tipka je napravljena po uzoru na ekranski ispis osim što se e excel ispisu sumarno prikazuje iznos PDV-a. 


Instalacija: Novi WIN FAUS lib će biti dostupan u srijedu 26.06.2013. 



Nije bio prebačen novi lib WIN FAUS. 

Novi WIN FAUS lib je već na internetu 



0











Klijent: 





Hitnost: 

Vrlo hitno 




13434 

Riješen 


12.06.2013 11:01 

Upisao: 

Boško Tokić 

Područje: 

LWINFAU 


07.06.2013 


13.06.2013 

Kod unosa stavaka ta ručne fakture (rucfak.jas) javlja se poruka sa slike(za navedenu uslugu i ugovor nije 

definirana neto cijena): 

(prilog) 

Ugovor ima indikator obračuna 'B' 

Ugovor: 11005 R10 00872 

Faktura: 11005 113 00096 


Ispravljena je greška koja se javljala kod unosa stavaka (bruto) za ručne fakture (rucfak.jas) 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja Kraljev 


13433 



12.06.2013 09:23 

Upisao: 

Boško Tokić 

Područje: 

LROBD 


17.06.2013 


1.Na ekranu katpu_fa omogućiti unos indikatora (aktivan ili neaktivan) za svaku kategoriju PU. 

Na ekranu pregleda kategorija prikazivati samo aktivne kategorije, ali omogućiti da se vide sve ili samo 

neaktivne. 

2. Onemogućiti povezivanje kategorija i asortimana na ekranu katpu_a_fa kada je kategorija PU „N“, a 

asortiman u statusu 0 i 3. 



0









Nakon spuštanja liba i odrađenih sql-ova, obavjestiti me kako bi se odradio basd.lib. 

Prema telefonskom dogovoru, najbolje bi bilo da se to odradi sutra. 

Najnovije upute šaljem direktnim mail-om na odjel informatike HP-a. 

1)Na šifarniku za unos kategorije PU dodano je polje aktivnost D/N. 

Onemogućeno je povezivanje kategorija i asortimana na ekranu katpu_a_fa kada je kategorija PU „N“, a 

asortiman u statusu 0 i 3. 

alter table kategorija_pu add aktivnost char(1) before uradio ; 

update table kategorija_pu set aktivnost='D' ; 

alter table kategorija_pu modify aktivnost char(1) not null ; 

2) Omogućen je prijenos podatka o aktivnosti u MIPS. 

Akcije koje su moguće prilikom prijenosa kategorija poštanskih ureda u MIPS su: 

U - unos, I-izmjena, A-aktivacija, D-dezaktivacija. 


Instalacija: prebaciti novi laus/tran lib sa datumom 18/07/2013 

Izvesti sql-ove: 

SQL koji se izvode na MIPS bazi: 

ALTER TABLE kategorija_pu 

ADD aktivnost char(1) before uradio ; 

UPDATE kategorija_pu SET aktivnost='D' ; 

ALTER TABLE kategorija_pu MODIFY aktivnost char(1) NOT NULl; 

SQL koji se izvodi na LAUS bazi: 

CREATE PROCEDURE "l1basd".azur_katpu( 

pre_kategorija_pu CHAR(6),post_kategorija_pu char(6), 

pre_akt char(1) ,post_akt char(1), 

pre_naziv nchar(70), post_naziv nchar(70)) 

IF post_naziv!=pre_naziv 

THEN 

insert into "l1tran".zah_kategorija_pu (kategorija_pu,akcija,datum) 

values (post_kategorija_pu,'I',CURRENT ); 

END IF 

IF pre_akt=='N' AND post_akt =='D' 

THEN 


values (post_kategorija_pu,'A',CURRENT ); 

END IF 

IF pre_akt=='D' AND post_akt =='N' 

THEN 


values (post_kategorija_pu,'D',CURRENT ); 

END IF 

END PROCEDURE; 



0







DROP trigger -završen, "l1basd".kategorija_pu_upd; 


create trigger "l1basd".kategorija_pu_upd update on "l1basd".kategorija_pu 

referencing old as pre new as post 

for each row 

( 

execute procedure "l1basd".azur_katpu (pre.kategorija_pu, 

post.kategorija_pu ,pre.aktivnost, post.aktivnost, 

pre.naziv, post.naziv) 

); 


Poštovana, 

na zadnjem sastanku - prezentaciji, krajnji korisnik se nije mogao složiti pa su ponuđena tri statusa: 

Statusi 1 Nastala narudžba (mogu se raditi izmjene) 

Statusi 2 Narudžbu je verificirala (odobrila skladišna služba) 

Status 3 Narudžba je verificirana od komercijale (znači poslana je dobavljaču) 

Dakle riječ je o procesu obrade dokumenta ( kolanju dokumenta) kroz različite službe. Nisam siguran da će to 

tako i ostati, ali za sada je tako. 

Na moju korisničku uputu TREBA DODATI KRAJNJI KORISNIK NJIHOVU UPUTU ZA RAD, koja ne postoji jer 

nitko nije bio siguran kako će to izgledati. 

Status 9, je standardni staus kod svih dokumenata - storno dokumenta, koji je morao biti skinut, mislim prije 4-5 

mjeseci jer dok ne postoji točno definiran prethodni dio procesa (statusi) onda neznamo što procedura 

prebacivanja u status 9 (storniranje) treba odraditi. 

Kako dokumenat narudžba dobavljaču ne mijenja nikakvo stanje skladišta, nije knjigovodstveni dokumenat, već 

je isklučivo vezan uz komercijalu, možemo se nadati da će u budučnosti netko iz te službe definirati i napraviti ili 

tehnologiju rada, ili kolanja dokumenta, ili uputu za rad ili definirati što taj status (9) treba raditi (koje procedure 

treba podržati). 

S štovanjem 


Poštovani, 

Prebačeni su novonapravljene procedure u modula BASD u HP na testnu instalaciju. 

S štovanjem 



0











Klijent: 





faktN_fas 

Hitnost: 

Vrlo hitno 


ivan 


13432 



11.06.2013 16:36 

Upisao: 

Dajana Lekić 

Područje: 

LWINFAU 


13.06.2013 

Ne mogu fakturirati HEP, ugovor sa neto cijenama, javlja grešku. 

Greška prilikom čitanja na cijena_lm_rab_ug broj -284 



Poštovani , 

Greška poslana u zahtjevu je ispravljena .: 

cijena usluge se nije čitala po zoni (lm_rab_ug) pa bi u slučaju više cijena za 1 uslugu ( po 1 cijena za svaku 

zonu) dolazilo do greške . 

Potrebno za instalaciju i testiranje : 

Preuzeti novi WinFaus lib sutra ujutro 12.06.2013 sa interneta 

Molimo povratne informacije / suglasnost za zatvaranje zahtjeva - Riješen 



0











Klijent: 



Izrada dokumentacije 


Hitnost: 

Vrlo hitno 


Katja 


13431 

U rješavanju 


11.06.2013 10:57 

Upisao: 

Božo Mišeta 

Područje: 

EHPUR 


18.06.2013 


Kako bi u HP- u mogli prebacivati nove verzije aplikacije na produkcijski server, molim da nam pošaljete 

postupak instalacije aplikacije 


Poštovani, 

Molim Vas pristup danas 18.07.2013. za kolegu Matoševića, a vezano za izradu zahtjeva 13431. 

Zahvaljujem. 

Lp, 


Poštovani, 

U tijeku je izrada korisničkih uputa za prebacivanje verzija aplikacija na produkciju. S obzirom na osjetljivost 

procesa prebacivanja novih verzija aplikacija na produkcijsku okolinu potrebno je održati edukaciju osoba koje će 

to ubuduće raditi za HP. Potrebni su i kontakt podaci navedenih osoba kako bi se dogovorio točan termin 

edukacije. Pretpostavljeni termin je u kolovozu. 


Lea Gagulić 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13430 

U rješavanju 


11.06.2013 10:53 

Upisao: 

Božo Mišeta 

Područje: 

EHPUR 


18.06.2013 


Potrebno je napraviti integraciju aplikacije eHPUR sa autorizacijom preko domene. 


Poštovani, 

Ovaj zahtjev mijenjamo u adaptivno održavanje. Procjena utroška vremena je 20 sati. 

Molimo suglasnost na gore navedeno. 

Lp, 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Glorija 


Zahtjev potrebno hitno riješiti. 

Lp 


13429 



10.06.2013 12:56 

Upisao: 

Božo Mišeta 

Područje: 

EOBRRAC 


10.06.2013 




0









Poštovani, 

Da li ste koristili korekciju PDV-a u razradi? Korekcija PDV-a je uvedena upravo zbog takvih odstupanja. 


Poštovani, 


Analiziran i slučaj iz ovog zahtjeva te još detaljnije objašnjano zašto se ne može riješiti automatski niti ako se 

koriste 3 umjesto 2 decimale za izračun neto troška ( u prilogu excel ) . 

Slučaj je riješavan prema zahtjevu 11528 (sličnan slučaj kao u ovom zahtjevu ) 

Ukoliko želite mijenjati opisane načine izračuna , molimo pošaljite novi zahtjev (adaptivno) sa točnom 

specifikacijom izračuna pojedinih vrijednosti . 

Po zahtevu 11528 Dogodilo se ovo : 

Na računu redni broj 012729-11 iskazana je razlika od 0.01 kn zato što neto trošak nije dobro izračunat. 

Ostali iznosi su točni i odgovaraju iznosima na računu tako da ne treba raditi korekciju ni ukupnog iznosa niti pdv 

-a. 

Neto trošak treba računati po formuli : osnovica + pdv- odbiti što u konkretnom slučaju iznosi : 

175.00 + 40.25 – 2.42 = 212.83 A ne 212.84 kako je prikazano na ekranu 

Odgovor/pojašnjenje : DIT 15.09.2011 : 

Prema formuli "PDV x prorata/100" 

iznos za odbiti je 2.415, što se u aplikaciji zaokruži na 2.42 

Kada računamo neto trošak prema formuli 

"iznos+PDV-odbiti" 

dobijemo iznos 212,835 (175,00+40,25-2,415) što se zaokružuje na 212,84. 

Upravo zbog zaokruživanja decimala dogovoreno je da se u Laus mogu slati računi čija je razlika do 0,03. 

Račun 012729/11 se može poslati u Laus jer je razlika 0,01 (unutar dopuštene vrijednosti). 

Rješeno : 16.9.2013 : 

U aplikaciji kod razrade PDV-a omogućili smo korekciju neto troška. 


Poštovani, 


Kako se ovo ne može riješiti "automatski" onda je ok mogućnost korekcije neto troška. Zahtjev se može zatvoriti. 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Višnja 


13428 



10.06.2013 11:54 

Upisao: 

Božo Mišeta 

Područje: 

EOBRRAC 


10.06.2013 


Kod slanja računa u Laus računa javlja se navedena poruka. Potrebno hitno otkloniti. 



0









Poštovani , 

Molimo omogućiti pristup na produkciju eObradaRAcuna . 

Spajat će se kolega Tvrtko Matošević. 


Programer se ne može spojiti na produkciju budući da su dva korisnika HP spojena na server. Molim da se jedan 

odlogira. 


Pitanje za HP: 

Da li ste uspjeli koji račun poslat danas u Laus? Da li se greška javlja kod svih računa ili samo kod ovog kojeg 

ste prijavili? 


Potreban nam je backup baze sa produkcije (eObraduRačuna) vezano za rješavanje zahtjeva 13428. 


Poštovani, 

na mips_laus test i produkcijskoj bazi potrebno je izvesti SQL za proširenje polja prorata : 

alter table eo_razrada modify prorata char(8) not null ; 

Razlog : promjena naziva prorate (primjer '70p' -> '70p (20)'). 

Prošireno je već na eObradaRačuna strani na test i produkcijskoj bazi . 

Kad se proširi u Lausu pokušajte izvršiti akciju Pošalji u Laus na likvidiranim računima. 

Molimo povratne informacije/ suglasnost za zatvaranje zahtjeva riješen 


Poštovani, 

Molimo da se korisnik mdimitrov odjavi potpuno iz aplikacije eObradaRačuna pa ponovo prijavi 

Ukoliko to ne riješi problem pa se opet javi greška : 

Korisnik mdimitrov ne može koristiti model oporezivanja p(25) – javlja se poruka „Ne postoji takva vrijednost 

comboboxa“. 

Ostali korisnici mogu normalno raditi s proratom 25. Možete li vidjeti u čemu je korisniku problem. 

svakako javite tako da možemo tražiti pristup na produkciju radi rješavanja . 

Ako je sve u redu nakon molimo suglasnost za zatvaranje zahtjeva - Riješen 


Poštovani, 



Lp 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


Veza – zahtjev br. 13053 

13427 



10.06.2013 09:24 

Upisao: 

Božo Mišeta 

Područje: 

LROBD 


13.06.2013 


Po projektu “eNarudžbenica (eZahtjevnica)” nije riješena točka 13. prepiske koju šaljem u prilogu. 



0









Poštovani, 

po ovom zahtjevu potrebno je organizirati sastanak HP _Laus _ MIPS. 

S štovanjem 


Poštovani, 

odgovara nam termin sastanka, molimo za potvrdu termina i broj sobe u kojoj će se održati sastanak. 

Molim obavezno pozvati predstavnika MIPS-a. 

S štovanjem 


Poštovani, 

molim vas da točku četiri ovog zahtjeva, izdvojite u poseban zahtjev (koji je prioritetan) i spada u adaptivno 

održavanje. 

S štovanjem 

4. Ograničenja u aktivaciji asortimana 

a. Prilikom izrade asortimana, a prije statusiranja i stavljanja u aktivni status provjeravati vrijeme statusiranja. 

U slučajevima kada je pokušaj statusiranja u vremenu prije 13 h, aktivaciju asortimana provesti po modelu 

„datum statusiranja + 1“, no ukoliko je pokušaj statusiranja nakon 13 h aktivaciju asortimana onemogućiti, 

zatražiti promjenu datuma početka važenja. U drugo opisanoj situaciji postaviti model „datum statusiranja +2“. 



0









Sutra u toku dana isporuka i najnovije korisničke verzije uputa. 

Preporučujem sve izvesti na tesnoj bazi i čekati eventualne izmjene MIPS-a. 

1)SQL za proširenje MIPS zahtjev_prijenos tablice 

alter table zahtjev_prijenos add kolicina_min int; 

Nakon što se izvede SQL slijedi isporuka integracijskog servisa na bazu na kojoj je odrađen SQL. 

Javiti nakon izvođenja da nastavimo sa isporukom nove verzije integracijskog servisa na testnom serveru. (isto 

kao i BASD po prethodno obrađenom zahtjevu) 

2)Proširen je prijenos podataka o asortimanima sa poljem minkol. 

Sutra preuzeti novi LAUS/TRAN lib i izvesti sql-ove: 

Sql koji se treba izvesti na MIPS bazi: 

ALTER TABLE asortiman_art 

ADD minkol char(3) BEFORE pre_asortiman; 

SQL koji se treba izvesti na LAUS bazi: 

alter table asortiman_art 

add minkol char(3) before pre_asortiman 

3)Na ekranu asortimana omogučeno polje min.količina - 2 numerik znaka, 

Tablicu asortiman_art proširiteno sa poljem minko. 

Na dokumentu zahtjevnica dodano je i polje min. količina 2 znaka. 



Poštovana, pretpostavljam da se vaš upit odnosi na produkcijsku bazu. 

Sve pobrojene libove možete spustiti na produkciju (dati nalog Laus-u da kompletira BASD procedute) 

nemojte odraditi SQL za proširenje MIPS zahtjev_prijenos tablice 

alter table zahtjev_prijenos add kolicina_min int; niti tražiti da se spusti servis od strane Laus-a, 

i ako bog da sve bi trebalo raditi! 

Navedeni sql i najnoviju verziju servisa za preuzimanje dokumenata odraditi kad MIPS završi svoj dio posla! 

S štovanjem 



0









MOLIM HITNU POTVRDU NIŽE NAVEDENOG PRIJEDLOGA!! 

Kod prijenosa veza asortiman artikal došlo je do greške jer nije proširena tablica asortiman_art sa poljem minkol. 

Prijedlog: 

Proširiti LAUS tablicu asortiman_art, a prijenos veza asoriman - artikal u MIPS napraviti da ne prenosi podatak 

minkol. 

Na taj način bi se omogućila u LAUS-u evidencija podatka, ali se taj podatak nebi prenosio u MIPS nego tek 

kada MIPS proširi svoju tablicu. 

Mi bi u toku dana isporučili TRAN lib koji ne prenosi polje minkol u MIPS! 

Molim hitnu potvrdu! 


Odradili smo telefonom, ali evo i napismeno! 

Izmjenjen je prijenos veza artikal - asortimanna način da se više ne prenosi podatak minkol. 

Instalacija: novi LAUS TRAN lib je već na internetu. 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13426 

Riješen 


07.06.2013 09:06 

Upisao: 

Božo Mišeta 

Područje: 

LROBD 


10.06.2013 


Na ekranu deaktiviranja i storniranja asortimana (asortd_fa) omogućiti da aplikacija nudi datum koji je za 

jedan dan mlađi od trenutnog datuma. Takođe se mora treba omogućiti i proizvoljan unos datuma koji ne 

smije biti stariji od sutrašnjeg datuma (primjer: asortiman koji deaktiviram danas treba nuditi datum 

deaktivacije od sutra, a može prihvatiti proizvoljan unos datuma većeg od sutra, ali ne manjeg). 


Kod dezaktiviranja asortimana odnosno prebacivanja u status 3 na ekranu asortd_fa datum dezaktiviranja tj. 

Datum do asortimana mora biti malđi barem jedan dan od trenutnog. 

Kad se asortiman stornira odnosno prebaci u status 0 Datum do asortimana se ažurira trenutni datum uvećan 

za 1 datum. 

BASD lib je prenesen na TESNU bazu HP-a. Obavezno nakon testiranja uputiti zahtjev o spuštanju na 

produkciju. 

S štovanjem 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Višnja 


13424 



06.06.2013 13:05 

Upisao: 

Božo Mišeta 

Područje: 

LKEVP 


10.06.2013 


Na Odluci o rasporedu i trajanju godišnjeg odmora (odl40p_rke) potrebno je izmjeniti tekst: 

Na temelju članka 64. Zakona o radu (NN 149/09, 61/11 i 82/12), a sukladno članku 27. Kolektivnog 

ugovora za radnike 

HP - Hrvatske pošte d.d. (HP Glasnik 10/11 i 17/11),te punomoći broj HP-1/1-5/12 od 22.5.2012. godine 

donosim 

sa tekstom: 

Na temelju članka 64. Zakona o radu (NN 149/09, 61/11 i 82/12), a sukladno članku 27. Kolektivnog 

ugovora za radnike 

HP - Hrvatske pošte d.d. (HP Glasnik 10/11, 17/11, 4/13, 10/13 i 12/13), te punomoći broj HP-07/2- 

10852/13 od 08.05.2013. godine donosim 



0









Poštovani, 

izmijenjen je tekst na navedenoj odluci. 

kevp će biti dostupan od 07/06/2013. 


Novi kevp lib je na internetu! 

S štovanjem 


Poštovani, 

Zahtjev nije na popisu neriješenih zahtjeva koji je poslan kao prilog zapisniku sa sastanka IT-LAUS 

10.06.2013.g. 

Nismo sigurni da HP potvrđuje zatvaranje - Riješen jer je : 

isporuka 7.6.2013. petak 

zapisnik 10.6.2013 ponedjeljak 

Molimo povratne informacije/ suglasnost za zatvaranje zahtjeva - Riješen 


Poštovani, 


S štovanjem 

Poštovani, 

Suglasni smo sa statusom da je zahtjev riješen. 


----------------------------------------------------- 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Višnja 


13425 



06.06.2013 13:02 

Upisao: 

Božo Mišeta 

Područje: 

LKEVP 


15.06.2013 


Prijenosom ERV-a u obračun plaće za 05-2013 radniku 37602 je iskazano 6 sati više od fonda. 

Radnik 37602 je radio na dan 01.04.2013. RAD NA PRAZNIK 12 SATI. Na isti dan ima DONO iz 03-2013 - 

10 sati i sa istim danom ( 01.04.2013) promijenjeno mu je rješenje: 


Poštovani, 

radnik 37602 je imao na dan blagdana 30/05/2013 rad s dnevnicom i rad bez dnevnice, zbog noćnog rada 

prethodnog dana. 

Rijetka kombinacija. 

Ispravljen je program za oduzimanje sati rada na blagdan na primanjima redovnog rada A00 i A001. 

Preuzmite lib: kevp (verziju možete preuzeti 01/07/2013.). 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13423 



06.06.2013 07:25 

Upisao: 

Božo Mišeta 

Područje: 

LTRAN 


07.06.2013 


06.06.2013 

Kod prijenosa klasa (F1) javlja se greška 201. Molim da ju otklonite. 


Greška se dogodila zbog toga što se u testnoj bazi u tablici klasa nisu ispravno napunili nazivi klasa (hrvatski 

slova ščćđž se nisu ispravno napunila). 

Podaci nisu upisani ktoz LAUS aplikaciju nego su se upisivali kroz bazu pa je zbo toga došlo do greške. 

Potrebno je ispravno napuniti tablicu klasa pa će i prijenos klasa biti dobar. 


poštovani, 

Zahtjev zatvaramo - rješen 

- nije na popisu neriješenih zahtjeva koji je poslan kao prilog zapisniku sa sastanka IT-LAUS 10.06.2013.g. 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Glorija 


13385 

Zatvoren-neće se rješavati 


05.06.2013 11:21 

Upisao: 

Božo Mišeta 

Područje: 

LSLOD 


31.05.2013 


NAPOMENA ZAHTJEV OTVOREN 3X POD ORIG. BROJEM 13385! ISPORUČITI SLOD, ROBD I FINK 

KAD SU SVA TRI ZAHTJEVA RIJEŠENA! 

1.NA EKRANU EVIDENTIRANJE DOKUMENTA prot1_fm (KOLONA ZA ODBITI – F12 STOPE 

PRETPOREZA ZA ODBITI) 

-BRISATI 17, 70+17, 30+17, 30, 70 

-OSTAVITI 100, 0, 20, 70+20, 30+20 

-DODATI 25 (NOVA STOPA PRORATE) 

2. U robno materijalnom na objektu kalka_HP3 izmijeniti stopu prorate na 25%. 

3. U aplikaciji službene odjeće izmijeniti stopu prorate na 25%. 



0









Poštovani, 

Kroz ovaj KZ rješava se točka: 


Molimo budite određeniji jer nismo uspleli pronaći dio koda u kojem se koristi prorata za cijene ili dokumente 

vezano za službenu odjeću 

Status : Čekamo odgovor HP-a 


Poštovani, 

po vašem nalogu zahtjev zatvoren! 

S štovanjem 

U aplikaciji službene odjeće nema mogućnost unosa prorate tj. u aplikaciji nema kalkulacije za primku, pa se 

izračun već provede kroz cijenu i vrijednost, pa nemate nikakve izmjene po ovom dijelu. 

Lp 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Glorija 


13385 



05.06.2013 11:15 

Upisao: 

Božo Mišeta 

Područje: 

LROBD 


31.05.2013 


1. 

NA EKRANU EVIDENTIRANJE DOKUMENTA prot1_fm (KOLONA ZA ODBITI – F12 STOPE 


-BRISATI 17, 70+17, 30+17, 30, 70 

-OSTAVITI 100, 0, 20, 70+20, 30+20 






0









Poštovani, 

Kroz ovaj zahtjev rješava se točka 2. zahtjeva : 


sad se na kalka_HP3 vide ove mogućnosti odabira prorate (prora_id) : 

PRORATA 

100 

70 

30 

0 

17 

Pitanje : Dovoljno je i jedino potrebno stopu 17 zamijeniti sa novom stopom prorate 25 ? 

Status : Čekamo odgovr HP-a 


Promjena prorate na kalkulaciji tipa HP3 sa 17 na 25 potrebno je izmjenti prametar sustava PRORA odnosno 

izmjeniti podatak. 


Izmijenjen je program za čitanje prorate. Čita se PRORA parametar po ključu godina . 

Godina je određena iz datuma kalkulacije . 

Napr , 

na kalka_ul_jd KALKULACIJA za zadani Datum 13/06/2013, godina=2013 u datumu kalkulacije 

pa se čita PRORA za ključ=13. 

Iz parametra PRORA pročitan je podatak 25 za ključ=13 što je stopa prorate za godinu 2013 . 

Ta pročitana stopa se onda prikaže na help ekranu (prora1_id) u polju PRORATA za klakulaciju HP3 

(kalka_HP3_fd) 

Ukoliko za godinu inje zadana pro rata, javit će se poruka: Morate unjeti PRORATU ZA GODINU ... 


Preuzeti robd* libove koji su već na internetu 

Ažurirati parametar PRORA po ključu godina 

sifra kljuc podatak 

PRORA 10 17 

PRORA 11 20 

PRORA 12 20 

PRORA 13 25 

Unosi se u PRORA parametar 

ključ od 2 znaka za godinu, 

podatak stopa prorate za godinu u ključu 

Molimo potvrdu učinjenog, radi zatvaranja zahtjeva! 

S štovanjem 



0









Poštovani, 


S štovanjem 


Lp 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Glorija 


13422 

Riješen 


05.06.2013 10:28 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


10.06.2013 


20.06.2013 

Na objektu Dodavanje usluga u ugovore kod upisa šifre partnera pojavljuje se poruka „partner nije nositelj 

salda konta“. 

Isto se svojevremeno pojavljivalo kod Pregleda ugovora pa smo tražili da se poruka makne. Molim da se 

isto primjeni i na objektu Dodavanje usluga. 


Na objektu Dodavanje usluga u ugovore kod upisa šifre partnera više se ne pojavljuje poruka „partner nije 

nositelj salda konta“. 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Ivan 


13421 



05.06.2013 07:12 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


07.06.2013 


05.06.2013 

Kod unosa fakture preko ruckat.jas za uvjete sa slike (2-Digitalna TV) nakon potvrde unosa javi se poruka 

da li se žele evidentirati podaci o kupcu i nakon što se odabere 'DA' otvara se prozor za unos podataka. 

Nakon unosa podataka javlja se poruka da je unos fakture uspješan ali nigdje nisu evidentirani podaci o 

kupcima(lm_usl_r1). Traba omogućiti spremanje tih podataka te njihov ispis kod generiranja fakture na 

mjestu gdje sada piše analitika iz protokola. 



0









Poštovani, 

Ovaj zahtjev spada u adaptivno održavanje jer se radi o proširenju podrške za druge vrste računa. Detaljno 

objašnjenje, u nastavku. 

Srdačan pozdrav 

Ljubo NIkolić 

Po zahtjevu HP 13219 : 

Računi Vrste 4 ( korekcije MIPS tračuna) 

Molim da se na objektu Ručni unos računa: 

1. za partnera P619801 omogući Unos podataka za R1 -poslovnog partnera (znači GR1 i VR1) 

omogućen je 18.3.2013 . na način : 

Omogućen je unos podataka za R1 - poslovnog partnera (GR1 i VR1) za partnera 619810. 

Da bi se upisali R1 podaci potrebno je partnera 619801 upisati u parametra sustava po šifrom POSPA. 

Parametar: 

Sifra = POSPA, 

kljuc = '2', 

podatak = 619801 

------------------------------- 

Za ostale vrste računa nije traženo ništa pa nije niti omogućeno. 

Parametar POSPA ima 'rezervirane' podatke za ključeve 1,2,3 a niti jedan nije vezan za generičku šifru 

partnera za EVO TV : 

-- 632531 EVO TV-PRODAJA 

--lect sifra,kljuc,podatak from laus@laustest:parametar where sifra='POSPA' 

--fra kljuc podatak 

--SPA 1 626551 

--SPA 2 619801 

--SPA 3 645904 

--lect part,naziv from laus@laustest:part where part in 

--'626551','619801','645904') 

--rt 626551 naziv KATALOćKA PRODAJA 

--rt 619801 naziv ćIFRA PARTNERA ZA RAŹUNE R1 

--rt 645904 naziv INTERNET TRGOVINA-INOZEMNI KUPCI 

Postoje li još neke generičke šifre partnera ? 

Za svaku od njih treba postojati zahtjev kao što su napisani iz navedene 3 što treba koji program s njima raditi . 

Napomena : 

moglo bi biti problema sa generičkom šifrom za EVO TV ako se ona koristi za račune bilo koje vrste osim 2 

( prodaja STB uređaja ) 

tj. za račune koji se knjiže na 120710 mora biti poznat i kupac i ugovor i preuzet iz BSS-a . 



0









Na objektu za ručni unos računa (ruckat.jas) sada se i kod unosa računa za 2-Digitalna TV upisuju dodatni 

podaci o partneru. 

Novi WIN FAUS lib je već na internetu. 



0











Klijent: 





upisnik - test 

Hitnost: 

Vrlo hitno 


Katja 


13420 



04.06.2013 15:17 

Upisao: 

Božo Mišeta 

Područje: 

EHPUR 


07.06.2013 


Kod transakcije T21 - Unos ponude/Nabave u tijeku, odabirom predmeta nabave u prozoru „Nabava“ te 

zaključavanjem iste omogućena je izmjena „Roka za dostavu ponuda“ i „Vrijeme za dostavu ponuda“. 

Potrebno je onemogućiti (zasiviti) izmjenu polja „Rok za dostavu ponuda“ i polja „Vrijeme za dostavu 

ponuda“. 



0









Poštovani, 

Ekran koji Vi prikazujete je prije samog zaključavanja i na njemu su dozvoljene izmjene u poljima koja ste 

označili (vidimo da postoji na ekranu gumb ˝Ručno zaključavanje roka za dostavu ponuda˝ koji se ne prikazuje 

nakon akcije zaključavanja). 

Nakon što zaključate nabavu, podaci u označenim poljima se prikazuju i dalje crnom bojom, ali nije moguće 

izvršiti korekciju nad njima jer nemate gumb koji promjene sprema već samo gumb Odustani˝ (privitak). 

Predlažemo zatvaranje zahtjeva. 

Lp, 


Poštovani, 

Omogućena Vam je izmjena navedenih polja u tom koraku jer ste prilikom potvrđivanja ispravnosti izvorne 

projektne dokumentacije potvrdili da se u uređivanju nabave (T20) ista polja mogu izmijeniti pa smo pretpostavili 

da tako želite i u T21 jer se radi o ekranu nabave i istim poljima. 

Ukoliko želite onemogućiti izmjenu polja i u T20 molimo potvrdu te predlažemo promjenu u perfektivno 

održavanje. 

Status : čekamo pojašnjenje/odgovor HP 


Poštovani, 




Poštovani, 

Potvrdili ste ispravnost rada nakon dorada po ovom zahtjevu na test okruženju. 

Prema dogovoru, Upisnik do daljnjeg ne ide na produkciju . 

zahtjev 13420 se odnosi na Upisnik te ga smatramo riješenom . 



Poštovani! 

po vašem nalogu zatvaramo ovaj zahtjev. 

S štovanjem 

Poštovani! 

Možete zatvoriti ovaj zahtjev - 13420. 

Lp, 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13419 



04.06.2013 09:33 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


06.06.2013 


06.06.2013 

Na ispisu predračuna ispod žiro računa, potrebno dodati IBAN Hrvatske pošte. 


Na ispisu predračuna ispod žiro računa,nadodan je prikaz IBAN Hrvatske pošte. 



Poštovani, 





0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13418 



04.06.2013 07:24 

Upisao: 

Božo Mišeta 

Područje: 

LROBD 


06.06.2013 


Na pregledu asortimana postavite status 2 kao defaultni status, da možemo kod pregleda odmah vidjeti 

aktivne asortimane. 


Na pregledu asortimana po deafaltu je postavljen status 2 - Aktivan asortiman. 

Nije potrehbno preuzimati libove. 


Poštovani, 





0











Klijent: 





protstn.stn 

Hitnost: 



Glorija 


13417 

Riješen 


03.06.2013 13:21 

Upisao: 

Božo Mišeta 

Područje: 

LSTAN 


10.06.2013 


30.06.2013 

Na navedenom objektu potrebno je maknuti kontrolu za tablicu vdokkon tj. da postoji upustvo za knjiženje. 

Potrebno je da samo postoji upustvo za evidenciju dokumenta. Knjiženje će ići na nivo 00000. 


Na objektu protstn.stn maknuta je kontrola na uputstva za knjiženje (vdokkon). 

Preuzeti novi WIN STAN liba u pondejeljak 17.6.2013. 

Molimo potvrdu o zatvaranju zahtjeva. 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Glorija 


13416 



03.06.2013 11:02 

Upisao: 

Božo Mišeta 

Područje: 

LFINK 


03.06.2013 


Zahtjevom 25.1. traženo je sljedeće i isporučeno. 

U ispisu opomena opo_hp podatak IBAN je dodan u liniji ispod broja žiro računa te se čita iz tipa dodatnog 

podatka IBN za korisnika. 

U petak su puštene opomene I na ispisu izlazi IBAN od HPB-a, bez obzira što je korisniku ITKALCEC 

pridružen dodatni podatak IBN ispravan IBAN od HP-a. Potreban hitan ispravak. 


Poštovani, 

Ispravljeno je čitanje IBANa iz dodatnog podataka IBN korisnika koji lista opomena na objektu opo_hp_ff. 

Pruzimite novi LAUS FINK liba. Novi lib se već nalazi na internetu. 

S štovanjem 


Poštovani, 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Glorija 


13414 

Nedostaju zadnja tri znaka u prenosi iBAN-a (vidi prilog) 



29.05.2013 15:11 

Upisao: 

Božo Mišeta 

Područje: 

EOBRRAC 


05.06.2013 




0









Napravljene su izmjene na objektu eo_pren_jf Prijenos računa iz eObrade u Laus ako se u polju ziroracun nalazi 

IBAN onda se u prefiks modela puni HR inače je prazno. 

Potrebno je izvesti SQL za proširenje tablice eo_zag na mips_laus bazi: 

alter table eo_zag modify ziroracun char(21); 

Preuzeti novi LAUS FINK liba koji je na internetu. 


Integracijski servis uredno prenosi podatke između baza. Ovo je slog iz eObradeRacunaLaus baze i ti podaci su 

se uredno prenjeli u mips bazu. U toj bazi pišu žiro računi bez zadnje 3 znamenke pa su se takvi i prenjeli dalje. 

140571DM-3-00614/13-03721028364-131912-501-16908302013-05-17 00:00:00.000HR752360000110169303 

13501019122-100106962013-05-21 00:00:00.0002013-06-01 00:00:00.0002013-17.13100540143ZBJITRGOV. 

ROBAR120000-R09-002632013-05-28 12:00:35.2570 

140827DP-3-000385/13-00200029026-138480-H002-536223012013-05-21 00:00:00.000HR1424020061100015 

0327-00848082013-05-27 00:00:00.0002013-06-05 00:00:00.0002013-4.3.11102538433ZDBITEH.PREG.R1 

10015-R12-013812013-05-29 14:45:17.0770 


Molimo pristup na produkciju za Tvrtka Matoševića radi rješavanja zahtjeva 13414. 


Poštovani, 

Zahtjev13414 i 12625 prebačeni su na test . 

Molimo povratne informacije / omogućite spjanja na produkciju eObradaRačuna . 

Spajat će se kolega Tvrtko Matošević 

Zbog hitnosti zahtjeva 13414 i 12625 na produkciju će se zajedno s njima prebaciti slijedeći zahtjevi: 

12625, 12658, 13130, 13269 i 13386, osim 12268. 


Izmjene su prebačene na produkciju. Predlažem zatvaranje zahtjeva. 


Poštovani, 

Zahtjev zatvaramo uz vašu suglasnost - Riješeno 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Ivan 


13413 

Riješen 


29.05.2013 11:20 

Upisao: 

Božo Mišeta 

Područje: 

LFINK 


05.06.2013 

Potrebno je rješiti rasknjižavanje uplata po dospijeću prema zapisniku iz priloga. 

Prilog: zapisnik sa sastanka od 28.05.2013. 

Naknadno će biti poslane tablice sa primjerima rasknjižavanja 




0









Na kraju pripreme punjenja nezatvorenih uplata dodano je brisanje onih čije saldo manji ili jednak 0. 

Na objektu bss_knj_jf izmjenjeno je da u proces rasknjižavanja ulaze samo uplate i računi koji imaju saldo i 

odnose se na isti ugovor. 

Omogućeno je knjiženje preostalog dijela uplate na stavku bez protokola sa opisom u kojem se nalazi broj 

ugovora. 

LAUS FINK lib je već na internetu. 


Na objektu bss_knj_jf kod pregleda stavki za rasknjižavanje postavljen je prikaz svih stavki bez obzira da li je 

nalog otvoren ili zatvoren. 

Zato kod knjiženja je postavljena kontrola da li je nalog uplata otoren ili zatvoren. Pa ako nije dobije se 

upozorenje "Nalog uplata X nije zatvoren . Potvrdite knjiženje podataka (d/n) ?". 

Pruzeti novi LAUS FINK liba u utorak 11.6.2013. 


Poštovani, 

Napravljene su potrebne izmjene na programu za rasknjižavanje bss_knj_jf radi ispravljanja greške kod 

računanja salda po računu 

a zbog čekga se uplata nije pravilno rasknjižavala na preostali saldo jer je isti bi multipliciran x puta 


Obavijestiti korisnika o preuzimanju novog LAUS FINK liba. Novi lib se već nalazi na internetu. 

Molimo povratne informacije/suglasnost za zatvranje zahtjeva - Riješen . 

Napomena : prije ponovnog testa obrišite : 

nalog red 

13E50114286 

13E50114285 

13E50114287 


Poštovani, 

Napravljene su dorade na progamu za rasknjižavanje bss_knj_jf. 


Obavijestiti korisnika o preuzimanju novog LAUS FINK liba. Novi lib se već nalazi na internetu, 




0









Poštovani , 

Analiziran je slučaj nezatvaranja stavki : 

nalogk red idin dp opis datumdok 

13E50115 1 -80.00 P 1001411 15/06/2013 * 

13E50115 3 50.02 P 1001411 15/06/2013 ** 

13E50116 1 -50.02 P 1001411 15/06/2013 ** 

13E50116 3 30.03 P 1001411 15/06/2013 saldo po opisu nije 0 nego 30.03 pa se ne 

zatvara jer nije 'zrelo' za zatvaranje 

13Z50142 1 80.00 P 1001411 15/06/2013 * 

Da je pušteno zatvaranje stavaka prije knjiženja naloga 13E50116 opet se ne bi zatvorilo jer bi onda saldo bio 

50.02 za opis=1001411 . 

Program 'kontrolira' ovakvu situaciju jer u svako slijedeće rasknjižavanje ulazi sa saldom po opisu tako da ne 

uzima uplate nerasknjižene pojedinačno za datumdok (datum uplate) nego saldo nerasknjiženih uplata za 

datumdok . 

Kad sve po jednoj uplati u Z5 bude rasknjiženo na račune zatvorit će se i ove stavke. 

NApr, u ovom slučaju kad bi bio račun x na 30.03 zatvoren saldom uplata 30.03 nastale bi stavke : 

-30.03 P strono nerasknjižene uplate (nema protokol tj LB) 

30.03 P rasknjižena uplata na račun x (ima prookol tj. LB) 

Tada bi se gornjem skupu stavaka bez LB pridružila i stavka od -30.03 P sa opisom 1001411 pa bi ukupni 

saldo za opis=1001411 bio 0 

što je nužno za zatvaranje 

U svakom trenutku , može se napraviti ručno zatvaranje preko rucnoz_jf ZATVARANJE STAVKI tako da se 

zatvore * i ** stavke a ostane otvorena stavka na 30.03 ali to u ovom slučaju ne utječe na ishod slijedećeg 

rasknjižavanja jer će opet saldo biti 30.03 


Napravljene su dorade za ubrzanjem knjiženja na objektu bss_knj_jf. 

Preuzeti LAUS FINK liba. Novi lib je već na internetu. 



0









Poštovani, 

Molimo povratne informacije / suglasnost za zatvaranje zahtjeva 

Ukoliko želite izmjene na zatiz_jf ZATVARANJE STAVKI PO IZNOSU pošaljite novi zahtjev . 

Pitali ste : 

Na zatiz_jf ZATVARANJE STAVKI PO IZNOSU 

za uvjete : 

Konto 120710 KONTO ZA DIGITALNU TELEVIZIJU 

Nivo knjişenja 46300_ SEKTOR NEPREHRANE 

Analitika A T010091 TEST BSS 

Kontrola na opis D (D/N) 

Opis smije biti prazan N (D/N) 

Ne napravi zatvaranje stavaka : 

duguje= potražuje= 84.19 tj. saldo =0 za opis = 101047420130501 

Odgovor : 

Program oduvijek radi na način : 

Traži se 1 uplata (jedna stavka) koja ima isti opis i iznos kao račun a ne više njih . 

U ovom slučaju 2 uplate imaju isti opis i sumarni iznos kao račun tj. nijedna od njih nema iznos kao račun . 

Naknadno dodana i opcija zatvaranja stavaka čiji je saldo na istoj strani knjiženja jednak 0 (stavka iz Z5 i njen 

storno u E5) . 

NAPOMENA: u konkretnom slučaju stavke će se automatski zatvoriti zatvaranjem naloga jer su i račun i obje 

uplate knjižene na isti LB čiji saldo je 0 . 


Napravljene su dorade na ubrzanju rasknjižavanja na objektu bss_knj_jf. 

Preuzeti novi LAUS FINK liba. Novi lib se već nalazi na internetu. 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13412 



29.05.2013 10:40 

Upisao: 

Božo Mišeta 

Područje: 

EHPUR 


31.05.2013 


Vezano uz pretraživanje orgj (orgj. oznaka prije 01.09.2009.) 

U slici 3 i 4 je vidljivo kada pretražujemo po nadležnosti da ne povlači stare orgj (oznake koje su prethodile 

1.9.2009). Oznake tipa D-P/1, D4/1 itd. 

Potrebno je dodati nadležnosti koje su prethodile 1.9.2009. da bi se mogle uređivati u polju "Poveži 

neaktivne organizacijske jedinice na postojeću aktivnu" 



0









Poštovani, 

Podaci prije 2009. , a vezano za org. jedinice nisu ni importirani u aplikaciju jer za time nije ni bilo potrebe 

odnosno nisu se importirale neaktivne orgj. 

Ukoliko želite, u aplikaciji Vam je omogućen unos neaktivnih org. jedinica i povezivanje istih na aktivne. 

Ovaj zahtjev mijenjamo u adaptivno. 

Predlažemo zatvaranje zahtjeva - Riješen 



* 13410 

* 13411 

* 13412 

* 13436 

* 12714, zahtjev 9 

* 12714, zahtjev 18 


Sati po ovom zahtjevu u 6/2013 su stornirani jer je promijenjena vrst azahtjeva u adaptivno održavanje. 

Sati su evidentrani u 7. mejsecu. Objašnjenje korisniku je poslano 11.6.2013 (u nastavku obrade) 

Poštovani, 

Podaci prije 2009. , a vezano za org. jedinice nisu ni importirani u aplikaciju jer za time nije ni bilo potrebe 

odnosno nisu se importirale neaktivne orgj. 

Ukoliko želite, u aplikaciji Vam je omogućen unos neaktivnih org. jedinica i povezivanje istih na aktivne. 





0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13411 



29.05.2013 10:36 

Upisao: 

Božo Mišeta 

Područje: 

EHPUR 


31.05.2013 


Kada pretražujemo po nadležnosti HP-07 rješavatelju Milan Radosavljević dobijemo kao rezultat 881 

podataka (slika 1), A kada pretražujemo samo po rješavatelju Milan Radosavljević dobijemo 2933 podataka 

(slika 2). 



0









Poštovani, 

razlog različitih podataka je što većina podataka/spisa koji se odnose na rješavatelja M. Radosavljević nema 

nadležnost i radi se spisima iz 2004 godine. 

Kako biste dobili točan prikaz, možete sve spise prosljediti (T65) na traženu nadležnost kako je i dogovoreno pri 

samom importu za takve spise. 


Predlažemo zatvaranje zahtjeva. - Riješen 



* 13410 

* 13411 

* 13412 

* 13436 

* 12714, zahtjev 9 

* 12714, zahtjev 18 



0









Analizom podataka na korsičkoj instalaciji utvrđen je razlog različitog prikaza. Odgovor poslan korisniku 

10.6.2013 

Sati nisu bili evidentorani, a kako se radi o adaptivnom državanju, iskazani su u 7/2013, temeljem ove obrade. 


Subject: HP: 13411 

Date: Mon, 10 Jun 2013 14:02:09 +0000 

From: Branka Gorup Ladović 

To: support@laus.cc 

CC: Dajana Lekic (dajana.lekic@laus.cc) , Lea Gagulic 

Poštovani, 

razlog različitih podataka je što većina podataka/spisa koji se odnose na rješavatelja M. Radosavljević nema 

nadležnost i radi se spisima iz 2004 godine. 

Kako biste dobili točan prikaz, možete sve spise prosljediti (T65) na traženu nadležnost kako je i dogovoreno pri 

samom importu za takve spise. 




Utrošeno sati 

4h 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13410 



29.05.2013 10:33 

Upisao: 

Božo Mišeta 

Područje: 

EHPUR 


31.05.2013 


Rješavatelj Milan Radosavljević je pripadao nadležnostima HP-7, HP-07 i HP-07/1. 

U zbirnom pretraživanju smo naišli na dva neispravna spisa: 

DP-3/2-004982/10 - gdje je nadležnost DP-3/2, a trebala bi trenutno biti HP-07/1. 

DP-3/2-002880/10 - gdje je nadležnost DPO-2 te u dnevniku rada nikada nije bio zadužen na 

Radosavljevića. Ispravno DPO-2 te ispraviti rješavatelja Jasminka Frank. 

Prilog - 4. Sve Radosavljevic Excel Nadleznost.png 



0









Poštovani, 

Na spisu DP-3/2-002880/10 su izvršene korekcije sukladno Vašem zahtjevu. 

Vezano uz spis DP-3/2-004982/10 prilikom dearhiviranja spisa niste odabrali novu nadležnost HP-07/1 te je spis 

ostao na prethodnoj nadležnosti. 

Izmjenu možete izvršiti u transakciji T65. 

Ovaj zahtjev mijenjamo u perfektivno i predlažemo zatvaranje istog. - Riješen 



* 13410 

* 13411 

* 13412 

* 13436 

* 12714, zahtjev 9 

* 12714, zahtjev 18 


Poštovani, 

Ne znam da li se dobro razumijemo. 

Naime, iz privitka koji ste nam dostavili (spis 4982-10) vidljivo je da se nadležnost na spisu promijenila u HP-07/1 

(privitak nadležnost) što je bio Vaš zahtjev. 

Lp, 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Višnja 


13409 



29.05.2013 09:08 

Upisao: 

Božo Mišeta 

Područje: 

EPNAB 


29.05.2013 


Molim žurno rješenje za slijedeći slučaj: 

28.05.2013. negdje oko 10 sati je Ugovor po Okvirnom sporazumu HP-10/1-005690/13 (datum ugovora 

27.05.2013) kroz ePN poslan u Laus i u ePN je zabilježen status 'poslan u LAUS'. 

Međutim uvidom u Laus konstatirano je da navedenog ugovora nema u Lausu, niti dan kasnije - slijedećeg 

jutra. 

Molimo za rješavanje tog problema. 



0









Poštovani, 

ugovor je stigao u MBAZA ( na produkciji je to mips_laus@mips_laus ) u tablicu epn_ugovor . 

NIje se dalje prenijeo u laus jer je tip=36 za ovaj ugovor a u prijenos ulaze ugovori koji zadovoljavaju uvjete : 

where ( status='' or status is null ) 

and tip in ('2','20','21','24') 

Također , tip=36 nije vezan niti za vrstu postupka JN (tablica vr_postupka) : 

vr_postupka naziv tip 

UOS UGOVOR PO OKVIRNOM SPORAZUMU 2 

UJN UGOVOR O JAVNOJ NABAVI 20 

UBN UGOVOR O BAGATELNOJ NABAVI 21 

NAR NARUDŚBENICA 24 

OST OSTALO 00 

Predlažemo koristiti tip=2 koji je već povezan sa UOS UGOVOR PO OKVIRNOM SPORAZUMU 

tj. izmijeniti za ovaj ugovor tip 36--->2 kroz bazu . 

Za ubuduće , potreban je stav HP: 

tip 2 i tip 36 trebaju se razlikovati te je potrebno u prijenos uključiti i tip 36 te isti povezati u vr_postupka tablici 

ili 

tip 2 i tip 36 ne trebaju se razlikovati tj. radi se o istom tipu i treba sve dolaziti kao tip=2 te prijenos nije potrebno 

mijenjati nego kod slanja u LAUS ePN treba tip 36 i tip 2 svesti na tip=2 

Status : čeka se stav HP 


Poštovani, 

Ovaj zahtjev je riješen i prebačen na test. Ugovori koji su uneseni kroz Registar okvirnih sporazuma sada su tip 

2 (prije 36) tj. Ugovori po okvirnom sporazumu i Ugovori po okvirnom sporazumu uneseni kroz Registar okvirnih 

sporazuma su svedeni na Tip 2. 

Lp, 


Poštovani, 

Ovaj zahtjev je riješen i prebačen na test. Ugovori koji su uneseni kroz Registar okvirnih sporazuma sada su tip 

2 (prije 36) tj. Ugovori po okvirnom sporazumu i Ugovori po okvirnom sporazumu uneseni kroz Registar okvirnih 

sporazuma su svedeni na Tip 2. 








0









Poštovani, 

Danas 27.6.2013. iza 16 sati molimo omogućite spajanje na produkciju ePN . 


Veza zahtjev: 13408 i 13409 


Poštovani, 


Lp, 


Poštovana, 

Možete li potvrditi zatvaranje sljedećih HP zahtjeva: 

§ 12603.9 

§ 13408 

§ 13409 

Sva tri navedena zahtjeva su riješena i prebačena na produkciju, ali nemamo službenu potvrdu o zatvaranju. 


Poštovani, 

ekran koji ste poslali je okvirni sporazum a ne ugovor po okvirnom sporazumu. 

Ugovor po ovom okvirnom sporazumu je dobio LAUS broj. 

Ekran ugovora po okvirnom sporazumu s produkcije u prilogu. 



Potvrđeno je od strane korisnika da je sada u redu, pa možete zatvoriti zahtjev. 


----------------------------------------------------- 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Višnja 


13408 



29.05.2013 07:29 

Upisao: 

Božo Mišeta 

Područje: 

EPNAB 


31.05.2013 

Kroz ePN osoba koja doda Ugovor po OS ne vidi taj ugovor kasnije. 

Korisnik Stjepan Marić vidi odmah ugovor po OS 




0









Poštovani, 

Ovaj zahtjev je prebačen na test. Sada korisnik koji je izradio Ugovor po Okvirnom sporazumu kasnije vidi taj 

ugovor. 

Lp, 


Poštovani, 

Ovaj zahtjev je prebačen na test. Sada korisnik koji je izradio Ugovor po Okvirnom sporazumu kasnije vidi taj 

ugovor. 







Poštovani, 

Danas 27.6.2013. iza 16 sati molimo omogućite spajanje na produkciju ePN . 


Veza zahtjev: 13408 i 13409 


Poštovani, 


Lp, 



0









Poštovana, 


§ 12603.9 

§ 13408 

§ 13409 




Potvrđeno je od strane korisnika da je sada u redu, pa možete zatvoriti zahtjev. 


----------------------------------------------------- 




0











Klijent: 





Hitnost: 



Glorija 


13407 



28.05.2013 11:44 

Upisao: 

Božo Mišeta 

Područje: 

LROBD 


05.06.2013 


Potrebno omogućiti unos vrste analitike A – ostala analitika. Ako se upiše 

Otpremnica da se povlači analitika sa otpremnice ako je i vrste A. Prilagoditi i ostale tipke ako je potrebno. 


Na dokumentu RPK Povrat robe od kupca omogučen je unos vrste analitike A - ostala analitika te sukladno sa 

oppremnicom kupcu ROk dodan je indikator digitalne tv (DTV d/n) . 



Poštovani, 





0











Klijent: 



Unapređenje programa 


Hitnost: 

Vrlo hitno 


Katja 


13406 



28.05.2013 11:10 

Upisao: 

Božo Mišeta 

Područje: 

LROBD 


29.05.2013 


Kada napravimo npr. primku od dobavljača i uđemo u stavke dokumenta, ne možemo se pozicionirati u 

polje barkod već samo u artikl. Molim da nam omogućite pozicioniranje u polje bar-kod. 


Na stavci dokumenta RPP Primka od dobavljača omogučen je unos Bar-koda . 

Potrebno je preuzeti laus liboe rob0,rob1,rob2,rob3 i rob4 koji će btii internetu 29.05.2013 


Prilikom očitanja barkoda odnosno ispisa artikla barkod ostaje ispisan tj. ne briše se . 

Kod ulasaka na ekran za unos stavaka dokumenta RPP Primka od dobavljača kursor se pozicionira na polje 

barkod. 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13405 



27.05.2013 13:07 

Upisao: 

Božo Mišeta 

Područje: 

LBASE 


28.05.2013 


Molim dodavanje objekta RIN9 u tablicu nobjekt, jer ga trenutno nije moguće dodijeliti korisniku. 


Poštovani, 

Evidentiran je novi objekt: 

RIN9 Storniran dokument (G, l1robd, JAM5). 

Sutra preuzeti nove menu-e i objekte, te nakon toga moguće je dodavati korisnicima dozvole na taj objekt. 

S štovanjem 



0











Klijent: 



Pitanje 


Hitnost: 

Vrlo hitno 


Ivan 

13404 



24.05.2013 07:16 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


23.05.2013 




0









Molim za provjeru izvještaja za marketing koji su kreirani preko objekta: izm.jas. 

Iz izvještaja za 11-2011 dobije se (na produkciji) 

select sum(kolicina),sum(prihod) from markk_rdg where godina='2011' and mjesec='12' and pozicija_rdg= 'I 

1.1.1.1.' and oib='HR69326397242'; 

kolicina 1.377.724prihod929.182,35 

Kada sam pustio ovaj SQL: 

select * from arhivk where datumk>='01.12.2011' and datumk









Poštovani, 

U lm_market_gr za pozicija_rdg= 'I 1.1.1.1.' postoje 3 sloga : 

za sve konto 750000 , grupa različita PISMO,TISAK i '' 

Potrebno je obrisati suvišne 2 veze 

Analizom nije utvrđen uzrok tj. greška u programu ( u prilogu) 

Zaključak : 

Potrebno pustiti u HP na produkcijskoj bazi pripremu kako je navedeno u prilogu i poslati povratne informacije 

kako bismo ubrzali rješavanje zahtjeva . 

Napomena : U ovom izvještaju rezultat ovisi o upisanom podatku OIB za prtnera . Ako je on mijenjan , izvještaj 

može biti bitno drugačiji . 


Poštovani, 

Potrebno je upisati SSx veze ili SPM vezu za orgj koje imaju promet u 2011-12 a nemaju veze na orrgj ( x= 

1,2,3,4 ili D ) -. Upišite im neku od veza - sumnjamo da je to uzrok upisa sloga gpp=ZG na iznos koji pravi 

razliku 

Radi se o prometu na : 

protokol konto orgj prihod 

1100301103308 750000 11044 74520.90 

1100301103308 750000 11039 344.10 

1100301103308 750000 11051 859410.50 

Molimo pustite najprije pripremu bez upisa veza , pa onda sa upisom za slučaj pod a),b),... 

Ukoliko trebate pomoć kod puštanja pripreme , javite se 

Status : čekamo povratne informacije 



0









Poštovani, 

Zanemarite prethodne obrade - ne treba testirati po poslanim uvjetima. Ne treba upisivati dodatne podatke na 

orgj : ako nema idu na gpp=DI 

Uzrok prikaza podataka na gpp=ZG za slučaj u zahtjevu jesu korektivna knjiženja u mjesecu različitom od 

mjeseca prometa : 

vuku količine u izvještaj a odnose se na fakture koje su izvorno ušlje u neki period prije. 

Za ovaj slučaj , prihod je knjižen prije pa djelimično storniran u 2011-12 : 

protokol nalogk datumk (sum) 

1100301101005 11I20075 31/05/2011 908700.24 

1100301101005 11TZ1151 31/12/2011 -1980.08 ** 

1100301101097 11I20078 31/05/2011 908700.24 

1100301101097 11TZ1151 31/12/2011 -1980.08 ** 

1100301101250 11I20088 30/06/2011 908700.24 

1100301101250 11TZ1151 31/12/2011 -1968.43 ** 

1100301102237 11I20118 30/09/2011 937428.70 

1100301102237 11TZ1151 31/12/2011 -3340.26 ** 

Predlažemo: 

staviti uvjet kod traženja količina da je količina=0 ako je faktura knjižena sa minus iznosom u mjesec x a 

prometno (lm_fak_stav.datpro) je u mjesecu y 

detalji u prilogu . 

Status : Čekamo stav HP vezano za slučaj/prijedlog 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Višnja 


13403 



23.05.2013 13:34 

Upisao: 

Božo Mišeta 

Područje: 

EPNAB 


27.05.2013 


Kroz Registar ugovora u ePlanNabave potrebno je ispraviti broj ugovora: 

Za spis HP-10/2/1-009178/13 

je unesen Broj ugovora „HP-/2/1-009178/13“, a treba biti „HP-10/2/1-009178/13“ 


Poštovani, 

Ovaj zahtjev je riješen na produkciji. Na spisu HP-10/2/1-009178/13, na ugovoru broj HP-/2/1-009178/13 je 

izmijenjen broj ugovora u HP-10/2/1-009178/13. U Registru ugovora, broj ugovora HP-/2/1-009178/13 je 

izmijenjen u HP-10/2/1-009178/13. Molimo potvrdu zatvaranja zahtjeva. 

Lp, 



0











Klijent: 



Pitanje 


Hitnost: 

Vrlo hitno 


Ivan 


13402 



23.05.2013 11:53 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


23.05.2013 


Molim za provjeru automatskog knjiženja gotovine. 

U knjiženju u razdoblju od 01.-10.05.2013. u nalozima 135K0122-135K0130 pojavljuje se konto 120300,a 

konto je neaktivan. 

Primjetili smo da je jedna od razlika na ovoj orgj. i to u iznosu od 12kn – što točno odgovara ovom slogu (na 

produkciji); 

select * from lm_usl_stav where orgj='31012' and datpro='05.05.2013' and matsta='312380'; 


Poštovani, 

zahtjev zatvaramo uz vašu suglasnost - Riješen. 

HP potvrdila na sastanku 27.5.2013 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Višnja 


13401 



23.05.2013 11:26 

Upisao: 

Božo Mišeta 

Područje: 

EHPUR 


24.05.2013 


U aplikaciji eHPUR je primijećen još jedan veliki propust. 

Naime novootvoreni spis broj 12355/13 je naknadno obilježen kao poslovna tajna kada se spis obradio 

akcijom poslovna tajna promijenio mu se urudžbeni broj u 11933/13. 

Sada postoje dva dupla broja 11933/13, a broj 12355/13 više ne postoji. Ponovno navodim da se ovakva 

greška ne smije događati. Ovo dovodi u pitanje vjerodostojnost rada aplikacije i točnosti podataka. 

Molimo da se što hitnije riješi ovaj problem odnosno ustanovi razlog ovim greškama. 



0









Poštovani, 

Molim sutra 24.05.2013. od 09.00 sati pristup za kolegu Matoševića. 

Zahvaljujem. 

Lp, 


Poštovani, 

Imamo li pristup? 

Lp, 


Poštovani, 

Izvršene su izmjene na produkciji. 

Molimo provjeru istih. 



Poštovani, 

Da, riješen je. 

Prilikom dorada na zahtjevu 13345 dio koda se ˝refelktirao˝ i na transakcije koje ste naveli. 

Tijekom otklanjanja grešaka izvršena je provjera nad ostalim spisima i ne bi trebalo biti više problema sa 

urudžbenim brojevima. 




0











Klijent: 





Hitnost: 

Vrlo hitno 




13400 

Riješen 


23.05.2013 10:16 

Upisao: 

Boško Tokić 

Područje: 

LWINFAU 


23.05.2013 


25.06.2013 

Na objektu rucj.jas potrebno je omogućiti unos cijene i cijene bez PDV na 3 decimale. Također treba 

proširiti polja u lm_usluga_cij da rade na 3 decimale (cijena_bez_pdv,cijena). 


Poštovani, 

Na objektu rucj.jasomogućen je unos cijene i cijene bez PDV na 3 decimale. 

Ta polja su proširena i u tablici u lm_usluga_cij. 


1. Instalacija: Novi WIN FAUS lib će biti dostupan u srijedu 26.06.2013. 

2. Potrebno je izvesti i sql za proširenje cjenika usluga (cijene na 3 decimale ) : 

ALTER TABLE lm_usluga_cij MODIFY ( 

cijena decimal(16,3), 

cijena_bez_pdv decimal(16,3) ); 



Omogučen unos cijena na tri decimale. 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Višnja 


13399 



22.05.2013 14:35 

Upisao: 

Božo Mišeta 

Područje: 

EPNAB 


24.05.2013 


Kroz ePlanNabave potrebno je ispraviti broj ugovora: 

- u ePN za Spis HP-10/2-005702/13 je unesen Broj ugovora „HP-10/2-005702/13“, a treba biti „HP-10/2- 

005702-1/13“ 

- u ePN u Registru ugovora broj ugovora „HP-10/2-005702/13“ izmjeniti u „HP-10/2-005702-1/13“ 


Poštovani, 

Ovaj zahtjev je riješen na produkciji. Na spisu HP-10/2-005702/13, na ugovoru broj HP-10/2-005702/13 je 

izmijenjen broj ugovora u HP-10/2-005702-1/13. U Registru ugovora, broj ugovora HP-10/2-005702/13 je 

izmijenjen u HP-10/2-005702-1/13. Molimo potvrdu zatvaranja zahtjeva. 

Lp, 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Glorija 


13398 

Riješen 


22.05.2013 11:20 

Upisao: 

Božo Mišeta 

Područje: 

LCSBI 


23.05.2013 


Prema izvještaju o statusu podataka, noćas nije izvršeno učitavanje podataka u LCS BI sustavu. Slika u 

nastavku je nakon refresh-a. 


Poštovani, 

greška je uočena jutros u procesu učitavanja podataka iz LAUS-a u međubazu i ispravljena. Budući podaci u 

međubazi nisu bili osvježeni, nije se nastavilo učitavanje u HP MIS. Noćašnjim učitavanjem svježi podaci će se 

normalno učitati u HP MIS. 


Poštovani, 

process chain noćnog loada u LCS BI iz međubaze je bio prekinut i to je uzrok prekida loada po ovom 

ponovljenom zahtjevu. load nekoliko dana sada radi uredno. 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Višnja 


13397 



22.05.2013 10:59 

Upisao: 

Božo Mišeta 

Područje: 

EHPUR 


22.05.2013 


U aplikaciji eHPUR je primijećen još jedan veliki propust. 

Spis broj DP-06-010471/13 je nestao iz aplikacije. Po spisu je jučer 21.05.2013 bila zadnja obrada, 

proslijeđen je u transakciji T65, nadležnosti HP-07, rješavatelju Lidiji Karlović. 

Ne možemo ga pronaći u zbirnom niti ostalim transakcija. 

Ne znam što se to događa s aplikacijom, ali pitanje je koliko još nedostaje spisa koji su nestali ili poprimili 

krivi broj. To se ne smije događati. 

Molim da se ovaj problem hitno riješi jer na temelju ispravnosti urudžbenih brojeva se veže cijela aplikacija. 



0









Poštovani, 

Molim Vas pristup za kolegu Matoševića danas poslije 16.00 sati. 

Zahvaljujem. 

Lp, 


Poštovani, 

Molimo pristup na produkciju za kolegu Livaića (više zahtjeva)? 

Lp, 


Poštovani, 

Molim Vas informacije o spisu DP-06-010471/13 : 

· Naziv spisa 

· Pisarnica koja je radila po navedenom spisu 

· Datumu kada je spis bio kreiran (ako ne znate točan datum, bar otprilike period navedite) 

Zahvaljujem. 

Lp, 


Poštovani, 

Izvršene su izmjene na produkciju. 

Molimo provjeru istih. 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Ivan 


13396 

Riješen 


22.05.2013 10:40 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


23.05.2013 


22.05.2013 

Na objektu rucfak.jas ne može se promijeniti podatak 'Plaćeno' za dokument (vprotokol='H',vdok='RAV') u 

statusu 2. Kod upisa novog datuma u Plaćeno i pritiska tipke 'Izmjena' javlja se poruka 'Izmjena uspješna' 

ali se taj podatak ne promijeni (lm_usl_fak.datum_pla). 


Na objektu rucfak.jas omogućena je izmjena podatka 'Plaćeno' za dokument (vprotokol='H',vdok='RAV') u 

statusu 2. 

Novi WIN FAUS lib će biti dostupan sutra u četvrtak 23/05/2013 ujutro. 


Poštovani, 


Nismo dobili primjedbe nakon isporuke rješenja : 

Na objektu rucfak.jas omogućena je izmjena podatka 'Plaćeno' za dokument (vprotokol='H',vdok='RAV') u 

statusu 2. 

Novi WIN FAUS lib će biti dostupan sutra u četvrtak 23/05/2013 ujutro. 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Glorija 


13395 



22.05.2013 06:59 

Upisao: 

Božo Mišeta 

Područje: 

LFINK 


24.05.2013 


Potreebno navedeni zahtjev realizirati do kraja tjedna, jer od 01.06. moramo slati uplatnice na HUB3 

obrascu, treba nam još nešto vremena za podešavanje printera i slično. 

Napraviti ispis i na HUB3 obrascu. Sve ostaje isto kao na postojećem osim što se dodaje IBAN 

HR2423900011400003640 

LFINK--> LBASE - perfektivno zakonska promjena : mijenja se sadržaj obrasca i raspored 



0









Na objektu vir7stn_jm STANOVI - ISPIS UPLATNICA omogućen je ispis uplatnica na HUB3 virmanu. 

Dosadašnji prikaz žiro računa zamjenjen je sa IBAN-om HR2423900011400003640, 

Budući polje opis plaćanja koje se formira prilikom generiranja uplatnica pod WIN STAN aplikacijom i nalazi se u 

formatu: ŠIFRA KUPCA, ORIGINALNI BROJ, REDNI BROJ RATE, DATUM DOSIJEĆA predugačak da stane u 

jedan redak opisa plaćanja na novom HUB3 virmanu, ono je razbijeno u četiri retka koliko ih ima predviđenih na 

novom HUB3 virmanu za polje opis plaćanja gdje svaki redak sadrži jedan od gore navedenih podataka od kojih 

se sastoji opis plaćanja. 

Ako ispis ne bude odgovoaro molimo da pošaljete primjer ispisa na novom HUB3 virmanu radi daljne koriekcije. 

Preuzeti LAUS BASE liba. Novi lib se već nalazi na internetu. 


Napravljene su tražene izmjene radi prilagodbe ispisa uplatnica za stanova na novi HUB3 virman. 

Preuzeti novi LAUS BASE liba. Novi lib je već na internetu. 


Poštovani, 

Napravljene su tražene izmjene na ispisu uplatnica stanova na novi HUB3 virman sa objekta vir7stn_jm. 

Prezeti novi LAUS BASE liba. Novi lib je već na internetu. 

S štovanjem 


Napravljena je nova izmjena na ispisu uplatnica stanova za novi HUB3 virman. 



HUB3 savršen . Zahtjev možete zatvoriti. 

Lp 


Poštovani, 

Zahtjev zatvoren 

S štovanjem 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Ivan 


13394 



21.05.2013 14:52 

Upisao: 

Božo Mišeta 

Područje: 

LFINK 


21.05.2013 

Kod rasknjižavanja uplata preko bss_knj_jf potrebno je maknuti kontrolu/poruku 

'Stavka je već knjižena želite li ju ponovno proknjižiti'. 


Potrebno je već odmah unutar rasknjižavanja omogućiti zatvaranje stavaka ako postoje za to uvjeti 

(konto,analitika,opis,iznos) kako bi se izbjegle greške kada postoje 2 ili više uplata kod rasknjižavanja sa 

različitim datumima koje tada više puta zatvaraju istu fakturu. 

Potrebno je na istom ekranu dodati uvjet na datum dospijeća kao na obavezno polje. Program treba 

rasknjižavati uplate samo na fakture koje imaju datum dospijeća manji ili jednak datumu dospijeća koji se 

unese na ekranu. Ostaktak koji ostaje nakon rasknjižavanja ostaviti kao otvorenu uplatu. 



0









Na ekranu bss_knj_ff nadodan je uvijet na datum dospijeća kao na obavezno polje. Program sada rasknjižava 

uplate samo na fakture koje imaju datum dospijeća manji ili jednak datumu dospijeća koji se unese na ekranu. 

Sutra prebaciti novi LAUS FINK lib. 


Kod rasknjižavanja uplata preko bss_knj_jf maknuta je kontrolu/poruka: 




Fink lib je na internetu, možete ga preuzeti odmah! 

Poz 



0









Poštovani, 

Status zahtjeva je : čekaju se pojašnjenja od korisnika . 

Slučaj 1) 

Pustio sam rasknjižavanje u E5 nalog i zadao uvjet da je datum dospijeća do 20.05.2013. 

Program je javio da je stavka već proknjižena i pitao me da li ju želim ponovno proknjižiti. 

Nakon potvrde 'DA' program je stvorio minus uplatu i plus uplatu sa opisom protokola. Ovo je sve ispravno osim 

što se javila poruka. 

POJAŠNJENJE : 

obrada 2: 22.5.2013. 

Kod rasknjižavanja uplata preko bss_knj_jf maknuta je kontrolu/poruka: 



Dakle, promjena je vidljiva tek u lib-u od 23.5.2013. a testiranje rađeno 22.5.2013. ( 22 May 2013 15:15 ) 

Molimo provjeru javlja li se poruka nakon preuzimanja fink lib-a od 23.5.2013. nadalje 

Slučaj 2) 

Pustio sam rasknjižavanje u E5 nalog i zadao uvjet da je datum dospijeća do 20.02.2013. 

Program je rasknjižio i javio poruku 'uspješno proknjižena 1 stavka' 

Kada sam pogledao karticu vidio sam da je program rasknjižio u E5 nalog uplatu samo sa minus predznakom. 

Znači u ovom slučaju imamo dvije uplate na kartici sa istim iznosom a sa različitim predznakom što nije ispravno 

jer to daje na kartici kupca krivi podatak , tj. kao da kupac uopće nije ništa platio. 

Program je trebao prvu uplatu ostaviti otvorenu . Kao što sam i naveo u zahtjevu!!! 

Neznam da li je to najnoviji fink ali ako nije trebate voditi računa da se to ne događa u programu koji ćete 

dostaviti sutra!!! 


Nakon što je traženo napravljen je uvjet na datum dospjeća. 

NIje specificirano što sa uplatama koje su stigle a nema otvorenih računa kojima je dospjeće manje ili jednako 

zadanom datumu 

tako da program nije mijenjan nego radi kako je dosadašnjim zahtjevaima određeno : 

proknjiži minus stavku naloga Z5 pa rasknjižavaj ju po računima . 

Kako nema računa , ostala je 'visiti' minusna stavka koja stavlja nalog u neravnotežu jer nema svoj + par 

a još gore je to što na kartici kupca izgleda kao storno uplate tj. kao da kupac nije ništa platio. 

Na sutrašnjem sastanku nadam se da ćemo se dogovoriti oko svega . 

Kod automatskih knjiženja jedino normalno stanje i regularna situacija je ona koja daje : saldo naloga = 0 

NAPOMENA: 

Nisje napravljeno : unutar rasknjižavanja omogućiti zatvaranje stavaka ako postoje za to uvjeti 

(konto,analitika,opis,iznos) 

Razlog : potrebno sutra na sastanku odrediti što napraviti sa djelimičnom uplatom te slučaj kad postoji 

odobrenje 



0









Poštovani, 

Predlažemo zatvaranje ovog zahtjeva 13394 - Riješen. 

Razlog : danas smo zaprimili novi zahtjev 13413 kroz kojeg će se rješavati dalje rasknjižavanje po dospjeću, a 

prema zapisniku sa satanka održanog jučer 28.5.2013 

---------nakon 

analize i realizirani kroz ovaj zahtjev i isporučeno : 

Kod rasknjižavanja uplata preko bss_knj_jf potrebno je maknuti kontrolu/poruku 'Stavka je već knjižena želite li 

ju ponovno proknjižiti'. 

-- Riješeno ( 22. i 27.5.2013 jer 2 procedure kontroliraju je li već knjižena ista stavka ) 

Potrebno je na istom ekranu dodati uvjet na datum dospijeća kao na obavezno polje. 

Program treba rasknjižavati uplate samo na fakture koje imaju datum dospijeća manji ili jednak datumu dospijeća 

koji se unese na ekranu. 

Ostaktak koji ostaje nakon rasknjižavanja ostaviti kao otvorenu uplatu. 

--- Program sada rasknjižava uplate samo na fakture koje imaju datum dospijeća manji ili jednak datumu 

dospijeća koji se unese na ekranu. 22.5.2013. 

Nije rješavano - ne treba : 

Potrebno je već odmah unutar rasknjižavanja omogućiti zatvaranje stavaka ako postoje za to uvjeti 

(konto,analitika,opis,iznos) kako bi se izbjegle greške kada postoje 2 ili više uplata kod rasknjižavanja sa 

različitim datumima koje tada više puta zatvaraju istu fakturu. 

-- Zatvaranje po iznosu se provodi nakon rasknjižavanja E5 preko zatiz_jf tj. neće se raditi zatvaranje unutar 

bss_knj_jf nego ostaje kao dosad. Zaključak sa sastanka 28.5.2013. 

Problem koji se rješava dalje u 13413 : 

Nakon što je traženo napravljen je uvjet na datum dospjeća. 

NIje specificirano što sa uplatama koje su stigle a nema otvorenih računa kojima je dospjeće manje ili jednako 

zadanom datumu 

tako da program nije mijenjan nego radi kako je dosadašnjim zahtjevaima određeno : 

proknjiži minus stavku naloga Z5 pa rasknjižavaj ju po računima . 

Kako nema računa , ostala je 'visiti' minusna stavka koja stavlja nalog u neravnotežu jer nema svoj + par 

a još gore je to što na kartici kupca izgleda kao storno uplate tj. kao da kupac nije ništa platio. 

Princip kod zahvata računa i uplata za rasknjižavanje : 

· Ako postoji saldo po uplati za ugovor x a ne postoji nijedan račun za taj ugovor sa saldom uplata se ne 

rasknjižava . 

Dakle, u proces rasknjižavanja ulaze samo uplate i računi koji imaju saldo i odnose se na isti ugovor . 



0









Poštovani, 

Molimo suglasnost za zatvaranje ovog zahtjeva 

Razlog : sve ovdje navedene točke su riješene i isporučene ili se od nij odustalo ( zatvaranje odmah kod 

rasknjižavanja ) 

Trenutni status : 77- isporučeno -testiramo kod korisnika 

-- danas smo greškom poslali : 



Rješava se dalje kroz 13413 . 

Do zabune je došlo jer ovaj zahtjev vodimo pod FINK područjem a ne winFaus 

Ispričavamo se zbog greške/ zatvaranja . 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Višnja 


13393 


Kroz ePlanNabave potrebno je ispraviti broj ugovora: 

„HP-10-2/2-009066/13“, a treba biti „HP-10/2/2-009066/13“ 


21.05.2013 11:48 

Upisao: 

Božo Mišeta 

Područje: 

EPNAB 


24.05.2013 



Poštovani, 

Ovaj zahtjev je riješen na produkciji. Broj ugovora HP-10-2/2-009066/13 je ispravljen u HP-10/2/2-009066/13. 

Molim potvrdu zatvaranja zahtjeva. 

Lp, 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Glorija 


13392 



21.05.2013 09:59 

Upisao: 

Božo Mišeta 

Područje: 

LFINK 


22.05.2013 


Na objektima nkuun_jf, nkuin_jf, nkmun_jf, nkmin_jf, nkrun_jf i nkrin_jf, prilikom odabira izvoznog zaključka 

npr. 152 javlja se greška prikazana na ekranu u nastavku. 

Molim da se greška što hitnije ispravi kako bi se mogao nesmetano nastaviti rad po nadzornim knjigama. 


Ispravljena je greška koja se javljala na objektima nkuun_jf, nkuin_jf, nkmun_jf, nkmin_jf, nkrun_jf i nkrin_jf, 

Novi LAUS FINK lib je već na internetu 


Poštovani, 





0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13391 



21.05.2013 09:51 

Upisao: 

Božo Mišeta 

Područje: 

EHPUR 


22.05.2013 


U aplikaciji eHPUR prilikom pokušaja zbirnog prosljeđivanja/vraćanja u rad ustanovili smo da ista akcija ne 

radi. 

U transakcijama T65, T10 i T24 prilikom obrade akcija „Proslijedi“, „Proslijedi na potpis zbirno“ i „Vrati u rad 

zbirno“ ne nudi niti jednog rješavatelja tj baza rješavatelja je prazna za sve organizacijske jedinice. 

Iste akcije su jučer 20.5.2013 oko 16:00 sati radile. Provjereno sa korisničkim ulazom ereich i zbanic 

( uloga:”Pisarnica”) 

Molimo rješavanje navedenog problema. 


Poštovani, 

Dorade po ovom zahtjevu su izvršene i vidljive na produkciji. 

Molimo provjeru. 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Ivan 


13390 



20.05.2013 16:20 

Upisao: 

Božo Mišeta 

Područje: 

LFINK 


21.05.2013 


Kod rasknjižavanja uplata preko bss_knj_jf za cijelo konto 120710 program neispravno formira datumdok 

(uplata iz 25.04.2013 dobila je datumdok 17.05.2013 što je bio datum rasknjižavnja), 

select * from arhivk where konto='120710' and analitika='T009537' and (jail='' or jail is null) and vdok='UPL'; 

datumknalogkredvdokdatumdokdatumdosopisprotokolidin 

25.04.2013.13E50068 704UPL25.04.2013.(null)1009953 99 

17.05.2013.13Z50114 31UPL17.05.2013.(null)1009953 1 

17.05.2013.13E50090 63UPL17.05.2013.(null)1009953 -99 

17.05.2013.13E50090 64UPL17.05.2013.(null)1009953201304014630001332211 1 

17.05.2013.13E50090 65UPL17.05.2013.(null)1009953 -1 

17.05.2013.13E50090 66UPL17.05.2013.(null)1009953201304014630001332211 1 

17.05.2013.13E50090 793UPL17.05.2013.(null)1009953 98 



0









Kod rasknjižavanja u naloga uplata postavljeno je da se podatci datum dokumenta i datum dospijeća povlače iz 

originalnog naloga izvoda. 

Poredak dohvata podataka postavljen je po datumu uplate tako da starija uplata zatvara starije dospjeće. 

Preuzeti novi LAUS FINK liba u utorak 21.5.2013 


Poštovani, 

Kroz zadnju obradu 21.5.2013 poslano je : 

Kod rasknjižavanja u naloga uplata postavljeno je da se podatci datum dokumenta i datum dospijeća povlače iz 

originalnog naloga izvoda. 

Poredak dohvata podataka postavljen je po datumu uplate tako da starija uplata zatvara starije dospjeće. 

Nakon toga nismo dobili primjedbe na rad programa a isto je provjereno i utvrđen ispravan rad pri testiranju po 

zahtjevu HP 13413 na vašoj test bazi 



Poštovani, 




0











Klijent: 



Pitanje 


Hitnost: 

Vrlo hitno 


Višnja 


Poštovani, 

Riješen 


20.05.2013 16:02 

Upisao: 

Božo Mišeta 

Područje: 

SYSING 


21.05.2013 


Primjećeno je da je izvršena promijena korisnika ‘MASTER’ po nazivu, a nama nije poslana obavijest po 

kojem zahtjevu je to traženo. 

Molim da nas obavijestite o takvoj izvršenoj promijeni naših korisnika. 


----------------------------------------------------- 




0









Za korisnika MASTER sam ja, Dajana Lekić, izmijenila naziv jer je isti bio i u test i u produkcijskoj bazi što je 

nezgodno nekad kad trebamo testirati na test bazi i sa sigurnošću znati u kojoj bazi radimo kroz aplikaciju . 

Tako sam stavila u naziv TEST i PRODUKCIJA jer se naziv korisnika vidi na svim ekranima, a naziv baze ne vidi 

tj. ne vidi u cijelosti pa kako i test i produkcijska baza imaju isti početni dio naziva laus ne može se po tom znati o 

kojoj se bazi radi . 

Drugih razloga za promjenu naziva nema. 

Ispričavam se zbog učinjenog jer za to nismo dobili zahtjev a niti odobrenje od vas jer sam izmjenu smatrala 

korisnom svima te da ne smeta nikome. 

Naravno da sam trebala tražiti u svakom slučaju jer ste vi isključivi vlasnik svih podataka u svim vašim bazama. 

Još jednom se ispričavam na nepoštivanju procedure- neće se ponoviti . 

P.S. : Ukoliko nazive treba vratiti na staro - vratit ću . Zahtjev ne treba : dovoljan je remail . 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Glorija 


13389 



20.05.2013 13:40 

Upisao: 

Božo Mišeta 

Područje: 

LFINK 


20.05.2013 


Protokol E se krivo formira u obrascu PDV – OBRAZAC. Potrebna provjera i za PDV - K OBRAZAC. Znači 

povlači se cijeli iznos poreza, a trebao bi samo onaj za odbiti. 

Zahtjev potrebno hitno riješiti, jer sutra prijava pdv-a za 4/2013. treba biti gotova 

U pdv obrazac za 4/2013. Na stavci III.7. prikazuje se ukupan pretporez iz evidentiranih dokumenata u 

protokol E (usluge inozemnih poduzetnika) a treba samo onaj „može se odbiti“ kao i kod svih drugih 

„ulaznih“ protokola.(sve u privitku) 

Lp 




0









Poštovani, 

Za protokol E se u obrascu PDV – OBRAZAC. povlači se iznos poreza za odbiti a ne cijeli iznos poreza kao što 

je bio slučaj prije. 

U pdv obrazac za 4/2013. Na stavci III.7. prikazuje se pretporez za odbiti iz evidentiranih dokumenata u 

protokol E 

(usluge inozemnih poduzetnika) kao i kod svih drugih „ulaznih“ protokola a ne cijeli pretporez kao što je bio 

slučaj prije . 


Preuzeti FINK.libu od 21.5.2013 koji je već na internetu od jutros 

Molimo povratne informacije kako bismo isto izmijenili i na PDV-K obrascu . 


Poštovani, 

Ispravljen je prikaz ukupnog pretporez iz evidentiranih dokumenata u protokol E za PDV-K OBRAZAC. 

promjene već preuzete sa verzijom FINK liba od 28.5.2013 nadalje 



Poštovani, 

Zahtjev zatvaramo uz vašu suglanost - Riješen 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Glorija 


13388 



20.05.2013 11:38 

Upisao: 

Božo Mišeta 

Područje: 

LROBD 


25.05.2013 


Na objektu omogućiti tipke Unos, Izmjena i Briši. Kod dokumenta za sada omogućiti prikaz tih količina na 

RM1 i RM2. Provjeriti mogućnost za ostale dokumente. Ne ulaziti u prevelike zahvate za sada. 


Potrebno je koristiti objekt artmm_ul_jd MIN, MAX, OPT Količine Artikala Na Skladištu koji se nalazi na ME 1203 

OSTALI PODACI gdje je omgučena unos ,brisanje i izmjena. 


Poštovani, 





0











Klijent: 





Hitnost: 





13387 



17.05.2013 15:56 

Upisao: 

Boško Tokić 

Područje: 

LFINK 


31.05.2013 



1.Uplate s oznakom poziva na broj: 01 – oznaka poštanskog ureda – DDMMGGGG-621545 knjižiti na 

konto 259905, potražno, na P 636994, nivo 00000, u opis poziv na broj odobrenja 





0









Poštovani, 

Program za automatsko knjiženje izvoda ( iz_knj_jf ) je prilagođen za knjiženje po formatu poziva na broj 

odobrenja : 

01 – oznaka poštanskog ureda – DDMMGGGG-621545 i 

01 – oznaka poštanskog ureda – DDMMGGGG-617663 


Obavijestiti korisnika o preuzimanju novog LAUS FINK liba u utorak 21.5.2013. 

U uputama za automatsko knjiženje izvoda potrebno je upisati dvije nove upute točno prema uzoru na već 

upisanu uputu za poziv na broj odobrenja 01-618754. U prvu uputu upisuje se poziv na broj odobrenja 01- 

621545 , a drugu 01-617663 . 

Molimo povratne informacije/suglasnost za zatvaranje zahtjeva - riješen 


Poštovani, 

zahtjev je riješen i isporučen u 21.5.2013 o čemu smo poslali obavjest : 

poslano datum i vrijeme: 20.5.2013 13:56:14 





Napomena : nema ga u popisu neriješenih zahtjeva uz zapisnik sa sastanka održanog jučer 10.6.2013. 


Poštovani, 




0











Klijent: 





Hitnost: 





13386 



17.05.2013 15:51 

Upisao: 

Boško Tokić 

Područje: 

EOBRRAC 


31.05.2013 


Na ekranu Razrada PDV-a u izborniku pod Model oporezivanja treba dodati p-25 (nova stopa prorate); uz 

postojeći p dodati 20 (p-20) kako bi se razlikovale stara i nova prorata (kombinacije 30p i 70p sa novom 

proratom 25% nisu potrebne) 

Model oporezivanja: 

(prilog) 


Poštovani, 

Izvršene su izmjene u nazivu prorata i dodana je nova - p (25). 

Napomena: Prije testiranja molimo da očistite cache/browsing history/povijest. 





Poštovani, 




0











Klijent: 





Hitnost: 





LAUS 

13385 



17.05.2013 15:45 

Upisao: 

Boško Tokić 

Područje: 

LFINK 


31.05.2013 


NA EKRANU EVIDENTIRANJE DOKUMENTA prot1_fm (KOLONA ZA ODBITI – F12 STOPE 


-BRISATI 17, 70+17, 30+17, 30, 70 

-OSTAVITI 100, 0, 20, 70+20, 30+20 


(prilog) 





0









Napravljene su tražene izmjene na ekranu za izbor prorate pdvura_im. 



Poštovani , 

Pitali ste : 

Zahtjev je stavljen u status riješeno, ali da li su prilagodbe za proratu napravljene i u materijalnom dijelu te u 

dijelu službene odjeće. 

Odgovor : 

Zahtjev ovaj je riješen i isporučen . Status : 

Interni : 77 Isporučen- testiramo kod klijenta 

Za klijenta: 90 Isporučen- završen 

Nakon što potvrdite ispravnost (ako ne bude primjedbi ) zahtjev se zatvra i imat će konačni status : 

interni : 80 Riješen 

za klijenta : 100 Isporučen - Korisnik potvrdio ispravnost 

Molimo povratne informacije/ suglasnost za zatvaranje ovog zahtjeva - Riješen 

Prilagodbe za NOVU proratu i ukidanje straih prorata nisu rađene u materijalnom dijelu (ROBD) niti u dijelu 

službene odjeće (SLOD) 

Razlog : u zahtjevu nije traženo. 

Molimo pošaljite posebne zahtjeve vezano za novu proratu 25 i ukidanje straih prorata (ako treba) : 

1. za doradu u SLOD 

2. za doradu u ROBD/MATE 

Napomena : vezano za OSSA i prijenos računa iz eObradaRačuna - Prilagodbe za NOVU proratu i ukidanje 

straih prorata nisu rađene 

Razlog : dorade nisu potrebne . 

vos_p_jo VEZA DOKUMENATA I OSNOVNIH SREDSTAVA 

dorade nisu potrebne kod upisa nove veze jer se prorata zadaje u iznosu 

pogon_fo POGONSKA KARTICA OSNOVNOG SREDSTVA 

dorade nisu potrebne jer se radi o pregledu/ čitanju podataka vezanih za : 

--- dokumente u kartica_r kojima je status='7' i vdok in ('ROM','RO2','RSI','RSP') te vanalitika='S' (osnovno 

sredstvo) 

-- veze ossa i dokumenata (vossadok) koje se upišu preko vos_p_jo ili prijenosom eObrada-->LAUS za ovjeru 

po inv.broju 

eo_pren_jf PRIJENOS RAčUNA IZ E-OBRADE U LAUS 

dorade nisu potrebne jer se prenosi što stigne iz eObradaRačuna 



0









Poštovani , 

Zahtjev ovaj KZ 42995 u kojem se vode prilagodbe za nOVU proratu kod evidencije dokumenta (prot1_fm) je 

riješen i isporučen . 

Molimo suglasnost za zatvaranje zahtjeva - Riješen . 

NAPOMENA : 

Prilagodbe za NOVU proratu : 

u materijalnom dijelu (ROBD) vode se pod posebnim KZ broj 43252, HP 13385 - status : u rješavanju 

u dijelu službene odjeće (SLOD) vode se pod posebnim KZ broj 43253, HP 13385 - satatus : neće se rješavati 

(nije potrebno) 

vezano za OSSA i prijenos računa iz eObradaRačuna - Prilagodbe za NOVU proratu i ukidanje straih prorata 

nisu rađene 

Razlog : dorade nisu potrebne . 

vos_p_jo VEZA DOKUMENATA I OSNOVNIH SREDSTAVA 

dorade nisu potrebne kod upisa nove veze jer se prorata zadaje u iznosu 

pogon_fo POGONSKA KARTICA OSNOVNOG SREDSTVA 

dorade nisu potrebne jer se radi o pregledu/ čitanju podataka vezanih za : 

--- dokumente u kartica_r kojima je status='7' i vdok in ('ROM','RO2','RSI','RSP') te vanalitika='S' (osnovno 

sredstvo) 

-- veze ossa i dokumenata (vossadok) koje se upišu preko vos_p_jo ili prijenosom eObrada-->LAUS za ovjeru 

po inv.broju 

eo_pren_jf PRIJENOS RAčUNA IZ E-OBRADE U LAUS 

dorade nisu potrebne jer se prenosi što stigne iz eObradaRačuna 


Po vašem nalogu zatvaramo zahtjev iz područja FINK. 

Za evidenciju dokumenata da, za robno materijalno ne 

Lp 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja Kraljev 


13383 



17.05.2013 15:19 

Upisao: 

Boško Tokić 

Područje: 

EHPUR 


20.05.2013 


Tajnica Ivana Habuš (ihabus) ne vidi surješeni spis iz 2013. g. na produkcijskoj bazi 10973/13 

(prilog) 


Poštovani, 

Izvršena je korekcija, molimo istu provjerite na produkciji. 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja Kraljev 


13384 



17.05.2013 14:52 

Upisao: 

Boško Tokić 

Područje: 

LROBD 


20.05.2013 


Zapisnik o višku po inventuri RZV 35348-R13-03386 je u status 7, ukupan iznos mu je 0,00 iako ima 

stavke sa vrijednostima >0. 


Ispravljena je ukupna vrijednost dokumenta 35348-R13-03386 . 



Poštovani, 




0











Klijent: 





Hitnost: 

Vrlo hitno 




13382 

U rješavanju 


17.05.2013 11:57 

Upisao: 

Boško Tokić 

Područje: 

LFINK 


25.05.2013 


U prilogu prijedlog izrade liste potraživanja za evotv (konto 120710). Navedeno potrebno realizirati kroz 

novi objekt. 



0









Poštovani, 

Kako bismo završili liste tražene ovim zahtjevom molimo odgovore na opitanja : 

1. Starosna strukturu potraživanja za evo TV . 

Vdok : Ako se zada BSS onda prikazuje samo podatke za račune vrste BSS . Strana potražna (uplate) nema 

ograničenja na vdok . Točno? 

Redoslijed : vanalitika,analitika ili naziv ili bss broj ugovora ili neki drugačiji ili je nebitan ? 

2. Naplata - u prilogu primjer s prikazom neraspoređene uplate i % naplate sumarnim sa i bez prikaza te uplate 

Za ovaj način izlistanja odobrenja bi trebala imati datum dospijeća. Ako nemaju datumdos=datumdok ? 

Order : datum dospijeća za račune pa na kraju neraspoređene uplate ? 

Neraspoređene (nepovezane) uplate staviti u poseban red pod naplaćeno dugovanje, ostali iznosi 0 bez datuma 

dospjeća i postotka naplate ? 

% naplate za svaki redak u listi izračunavati ovako : naplaćeno*100/dospjelo ? 

NA kraju liste sumirati sve stupce s iznosima osim % naplate jer se on računa za svaki redak ? 


Poštovani, 

Molimo odgovr na pitanje : 

Želite li liste u excel formatu i obični ispis ? 

Također, nismo dobili odgovor na pitanja polsana ranije . 

Trenutno se radi lista ppod 1. pa molimo pošaljite barem odgovre na pitanja vezano za nju . 





Kako bismo završili liste tražene ovim zahtjevom molimo odgovore na opitanja : 

1. Starosna strukturu potraživanja za evo TV . 

Vdok : Ako se zada BSS onda prikazuje samo podatke za račune vrste BSS . Strana potražna (uplate) nema 

ograničenja na vdok . Točno? 

Redoslijed : vanalitika,analitika ili naziv ili bss broj ugovora ili neki drugačiji ili je nebitan ? 

2. Naplata - u prilogu primjer s prikazom neraspoređene uplate i % naplate sumarnim sa i bez prikaza te uplate 

Za ovaj način izlistanja odobrenja bi trebala imati datum dospijeća. Ako nemaju datumdos=datumdok ? 

Order : datum dospijeća za račune pa na kraju neraspoređene uplate ? 

Neraspoređene (nepovezane) uplate staviti u poseban red pod naplaćeno dugovanje, ostali iznosi 0 bez datuma 

dospjeća i postotka naplate ? 

% naplate za svaki redak u listi izračunavati ovako : naplaćeno*100/dospjelo ? 

NA kraju liste sumirati sve stupce s iznosima osim % naplate jer se on računa za svaki redak ? 



0











Klijent: 






Vrlo hitno 




13381 

U rješavanju 


17.05.2013 09:09 

Upisao: 

Boško Tokić 

Područje: 

LWINFAU 


Sve prihode kod automatskog knjiženja knjiži na nivo MREŽE (neki prihodi trebaju ići na nivo hpx ili pošte). 

Potrebno knjižiti na nivo definiran uslugom, kao promet što dolazi iz Mipsa. 

Kod ručnog knjiženja pokaže se broj dokumenta (npr: 31012-513-22566) dok kod automatskog ne pokaže 

broj što je jako bitno kod kontrole (Pregled stavki po broju dokumenta). Potrebno knjižiti laus broj 

dokumenta kod konta prihoda i konta PDV-a. 



0









Poštovani, 

Analiziran je zahtjev i doneseni zaključci/prijedlozi riješenja . 

Molimo povratne informacije potrebne za rješavanje zahtjeva 

Status : Čekamo vaš stav - Usaglašavanje 

1. Sve prihode kod automatskog knjiženja knjiži na nivo MREŽE (neki prihodi trebaju ići na nivo hpx ili pošte). 

Potrebno knjižiti na nivo definiran uslugom, 

kao promet što dolazi iz Mipsa. 

Zaključak : knjmips.jas KNJIŽENJE RUČNIH GOTOVINSKIH RAČUNA se odnosi na račune unešene preko 

ruckat (vrsta 4) . 

Kod evidencije zaglavlja i stavki računa unosi se laus šifra orgj . I u zaglavlju i ustavkama postoji ograničenje da 

je orgj iz mreže ( SS2 veza) 

sql select naziv xxnorgj from orgj where orgj = "30085" and orgj in (select orgj from orgjdod where tipp ='SS2'); 

Knjiži se na nivoe koji su uneseni u račun : 

Nivo knjižanja za konto PDV-a (24*) te konto kupca (12*) jest orgj iz zaglavlja tj. nivo mreže - ok 

Nivo knjiženja za konto prihoda (75*) uzima se iz stavke tj. nivo mreže - nije ok 

Dakle, Izvor problema nalazi se u evidenciji stavaka a ne knjiženju . 

Prijedlog : 

a) u stavke se unosi mips šifra PU a program prema toj šifri i usluzi odrađuje orgj (nivo) : 

napr. za uslugu x lm_usl_dod.pripadnost= SS1 pa se po tome za mips_pu šifru PU 10000 određuje orgj (ide 

se u orgjdod where tipp=SS1 and tekst=10000 i dobije orgj ) 

b) u stavke se i dalje unosi laus šifra orgj ali ne mora biti iz mreše (SS2) nego : bilo koja ili samo koja ima SS* 

vezu ? 

Molimo pošaljite vaš stav u vezi s prijedlozima 

2. Kod ručnog knjiženja pokaže se broj dokumenta (npr: 31012-513-22566) dok kod automatskog ne pokaže broj 

što je jako bitno kod kontrole (Pregled stavki po broju dokumenta). 

Potrebno knjižiti laus broj dokumenta kod konta prihoda i konta PDV-a. 

ZAKLJUČAK :Knjiži se po istom principu kao i gotovinski promet iz MIPS-a preuzet ( knjts5 za VR1 i knjts7 za 

GOT i GR1) : 

GOT gotovinski zbirni računi knjiže se zbirno bez laus broja 

GR1 pojedinačni gotovinski R1 računi knjiže se pojedinačno sa laus brojem 

VR1 pojedinačni R1 računi plaćeni virmanom knjiže se pojedinačno sa laus brojem 

Račun koji ste naveli je vrste GOT tj. knjiži se bez laus broja. 

Molimo potvrdite da se na knjmips.jas KNJIŽENJE RUČNIH GOTOVINSKIH RAČUNA i za vdok=GOT knjiži 

pojedinačno s laus brojem računa na svim kontima : ukupno 12*, pdv 24* i prihod 7* 



0











Klijent: 





Hitnost: 

Vrlo hitno 




13380 

Riješen 


16.05.2013 15:57 

Upisao: 

Boško Tokić 

Područje: 

LFINK 


17.05.2013 


Molim za provjeru, zašto ne knjiži automatski stavke žiro računa u prilogu. Imamo cca. 1000 neproknjiženih 

stavaka. 

Prolazi automatsko za prva tri partnera, a zadnja dva ne prolaze. 

održavanje KOR--> PER ( odobrila HP) 



0









Poštovani, 

Budući je traženo , napravili smo za prva 3 partnera : 

HP 13143 : posebno knjiženje za 618754 

HP 13316 : posebno knjiženje za 685748 i 649919 

Zahtjev za posebno knjiženje analitika koje navodite nismo dobili . 

Nijedan od partnera : 621545 , 617663 nije nositelj salda-konta (isaco = N ) 

part nadpart naziv aktivnost nsc 

621545 636994 OBRT ZA TRGOVINU GORAN D N 

617663 635951 24SATA D.O.O. ODJEL MARKETINGA D N 

Prije upućivanja zahtjeva za posebno knjiženje za njih postavite ih da su nositelji salda/konta ili napište neke 

druge partnere koji su NSC. 

Oprečno je tražiti izričito knjiženje na neku određenu analitiku a da ta analitika nije NSC jer se kosi sa općim 

principom kojeg smo ugradili u knjiženje : 

knjiži se isključivo na NSC (HP zahtjevi broj : 12789, 12793,...) 

Molimo povratne informacije : Čekamo stav HP 



0









Poštovani , 

Molimo suglasnost za zatvaranje ovog zahtjeva 13380 kao i zahtjeva 13143 te 13316 - Riješeno 

Molimo suglasnost za promjenu vrste održavanja KOREKTIVNO u PERFEKTIVNO za ovaj zahtjev 13380 

Status : Čekamo povratne informacije 

Pojašnjenje : 

Došlo je do nesporazuma vezano za knjiženja izvoda po uputama koje sadrže u pozivu na broj šifru partnera . 

Budući je traženo , napravili smo za prva 3 partnera : 

HP 13143 : posebno knjiženje za 618754 

HP 13316 : posebno knjiženje za 685748 i 649919 

Ako želite knjižiti po istom principu i na neke druge partnere , za svakog je potrebno isprogramirati tu 

mogućnost . 

Ove dvije upute koje ne prolaze otvorili ste po uzoru ne prethodne tri što je u redu : moraju postojati i upute . 

Međutim, automatsko knjiženje nije prošlo jer ne postoji isprogramirana ta mogućnost da se po specifičnom 

pozivu na broj knjiži na točno određenog partnera tj. NSC za njega . Ne smeta ako partner iz upute nije NSC 

samo što se onda knjiži na partnera koji je NSC za njega . 

Dakle, potrebno je poslati novi zahtjev za ova 2 slučaja : 

part naziv 

621545 OBRT ZA TRGOVINU GORAN 

617663 24SATA D.O.O. ODJEL MARKETINGA 

Za zadnji zahtjev 13316 poslan je odgovor koji se odnosio na upute : samo treba dodati novu uputu sa novim 

partnerom po uzoru na prethodne stavke. 

Međutim, treba i svaki pojedini slučaj isprogramirati 

----------------13316 --Poslano datum i vrijeme: 25.4.2013 16:10:22 

Poštovani 

Program za automatsko knjiženje izvoda ZR je prilagođen za knjiženje prema formatu poziva na broj odobrenja 




upisanu 

uputu za poziv na broj odobrenja 01-618754. 

U 1. novu uputu ide poziv na broj odobrenja 01-685748 , 

U 2. novu uputu ide poziv na broj odobrenja 01-649919 . 

Ostalo u pojedinoj kako ste napisali u zahtjevu . 


Obavijestiti korisnika o preuzimanju novog LAUS FINK liba u petak 26.4.2013. 

Molimo povratne informacije/ suglasnost za zatvranje zahtjeva - Riješen 


Poštovani , 

Uz vašu suglasnost : 

zahtjev zatvaramo - Riješeno 

mijenjamo vrstu održavanja KOREKTIVNO u PERFEKTIVNO 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja Kraljev 


13379 



16.05.2013 15:53 

Upisao: 

Boško Tokić 

Područje: 

LROBD 


17.05.2013 


Na objektu REVul_jd IZDATNICA NA REVERS kod pokušaja ispisa dokumenta (F6- Ispis) , dokument se 

ne može ispisati jer se niti ne pojavljuje ‘okaćeni’ ispis 

koji smo definirali za objekt REVul_jd. 


Kroz objekt PRIDRUŽIVANJE ISPISA DOKUMENTIMA ISPul_jm potrebno je pridružiti za objket REVzg_fd 

naziv ispisa IZDATNICA NA REVERS PO KLASAMA sa procedurom REVzg_isp_jd HPK . 

Nije potrebno preuzimati lib-ove. 



0











Klijent: 





Hitnost: 

Vrlo hitno 




Rucfak.jas 

13378 



16.05.2013 15:48 

Upisao: 

Boško Tokić 

Područje: 

LWINFAU 


16.05.2013 


17.05.2013 

Na prvom prikazanom ekranu vidi se broj Naruđbenice koji se dobije iz Ugovora no na ispisanom Računu 

nalazi se neki drugi neispravan broj. 

Molim što hitniju provjeru nastale situacije radi pravovremenog slanja Računa korisniku. 



0









Poštovani, 

Kod ispisa fakture (za fakture poštanskih usluga) se za partnera ispisiva broj iz dodatnog podatka SUG. 

Kod fakture iz zahtjeva je polje narudžbenica prazno. Tako i treba biti jer nije evidentirana narudžbenica za 

fakturu (na ekranu iz priloga se prikazuje narudžbenica iz ugovora). 


Instalacija: ne treba ništa. 

Molimo povratne informacije / suglasnost za zatvaranje zahtjeva - Riješen. 

Molimo suglasnost za promjenu vrste održavanja KOREKTIVNO u PERFEKTIVNO 


Poštovani, 


Nismo dobili primjedbe nakon zadnje obrade 17.5.2013 : 

Kod ispisa fakture (za fakture poštanskih usluga) se za partnera ispisiva broj iz dodatnog podatka SUG. 

Kod fakture iz zahtjeva je polje narudžbenica prazno. Tako i treba biti jer nije evidentirana narudžbenica za 

fakturu (na ekranu iz priloga se prikazuje narudžbenica iz ugovora). 


Instalacija: ne treba ništa. 

Molimo povratne informacije / suglasnost za zatvaranje zahtjeva - Riješen. 

Molimo suglasnost za promjenu vrste održavanja KOREKTIVNO u PERFEKTIVNO 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja Kraljev 


13377 

Poštovani! 

Molim Vas hitno rješavanje zahtjeva iz priloga! 



16.05.2013 14:44 

Upisao: 

Boško Tokić 

Područje: 

LROBD 


17.05.2013 



Na ekranu artdd_fa, program ne dozvoljava dezaktivaciju dobavljača. Dakle, na polju Aktivnost kada 

pritisnemo tipku F2- izmjena, javlja se poruka “Morate unijeti krovnog dobavljača….”. 

Molim Vas da to ispravite. 

(prilog) 


Na ekranu artdd_fa omogučeno je dezaktivarnje dobavljača bez obzira na nadređenost. 



Poštovani, 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja Kraljev 


13376 



16.05.2013 14:38 

Upisao: 

Boško Tokić 

Područje: 

LROBD 


17.05.2013 


Na objektu artd_ja uvesti kontrolu kod upisa dobavljača za artikal da se, kod prvog unosa artikla i 

dobavljača, može unijeti samo krovna (nadređena) šifra dobavljača. 


Na objektu artd_ja uvedena je kontrolu kod upisa dobavljača za artikal da se kod prvog unosa artikla i 

dobavljača, može unijeti samo krovna (nadređena) šifra dobavljača. 



Poštovani, 




0











Klijent: 





Hitnost: 

Vrlo hitno 




13375 



16.05.2013 08:45 

Upisao: 

Boško Tokić 

Područje: 

SYSING 


16.05.2013 


Jučer nam je ponestalo memorije na LAUS produkcijskoj bazi te su kolege iz sistemske podrške morale 

nasilno restartat bazu, također javile se se i neke greške: 

(prilog) 



0









Poštovani, 

Transakcija j kod godišnjeg zatvaranja (zksg_jf) e postavljena na godišnjoj razini jedne kombinacije 

(konta,orgj,vrste analitke i analitike) koja se zatvara. 


Obavijestiti korisnika o preuzimanju novog LAUS FINK liba koji se već nalazi na internetu. 

Molimo pustite zatvaranje za 1 konto , ako je sve u redu onda za klasu . 

Molimo povrtane informacije 

----------------------------------- 

Anlizom utvrđeno : 

arhivk na locklevel=row . 

program troši previše memorije jer je transakcija (begin i commit) na početku i na kraju cijele obrade 

a slogova u obradi za godina =2012 i konto 750 previše : 4 054 298 

Potrebno preprogramirati tako da begin i commit budu na početku i na kraju logične cjeline u obradi : 

zatvaranje jedne kombinacije konto,orgj,vanalitika,analitika jednim brojem zatvaranja 


Poštovani, 

Nakon što je zahtjev riješen nismo dobili primjedbe . 


Zadnja obrada (poslano datum i vrijeme: 17.5.2013 9:47:35 ) 

Transakcija j kod godišnjeg zatvaranja (zksg_jf) e postavljena na godišnjoj razini jedne kombinacije 

(konta,orgj,vrste analitke i analitike) koja se zatvara. 



Molimo pustite zatvaranje za 1 konto , ako je sve u redu onda za klasu . 

Molimo povrtane informacije 

----------------------------------- 

Anlizom utvrđeno : 

arhivk na locklevel=row . 

program troši previše memorije jer je transakcija (begin i commit) na početku i na kraju cijele obrade 

a slogova u obradi za godina =2012 i konto 750 previše : 4 054 298 

Potrebno preprogramirati tako da begin i commit budu na početku i na kraju logične cjeline u obradi : 

zatvaranje jedne kombinacije konto,orgj,vanalitika,analitika jednim brojem zatvaranja 


Poštovani Ivane, 


S štovanjem 

Možete zatvoriti 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja Kraljev 


13374 



15.05.2013 13:04 

Upisao: 

Boško Tokić 

Područje: 

EHPUR 


16.05.2013 


Djelatnicu Sandru Uroić je potrebno prebaciti sa odgj DM/K u DM-02/2, međutim, kod pokušaja 

dezaktiviranja korisnika ili dodavanja nove organizacijske oznake, javlja se poruka:”već postoji djelatnik pod 

istom laus šifrom”. Molimo da to ispravite. 



0









Poštovani, 

Zahtjev je riješen i prebačen na testni server. 



Poštovani, 

Molimo Vas pristup na produkciju za kolegu Vjerana Livaića danas, 20.05.2013. od 16.00 sati. 

Prebacivali bi se slijedeći zahtjevi: 

· 13183 

· 13184 

· 13256 

· 13332 

· 13372 

· 13374 

Molimo povratnu informaciju. 

Lp, 


Poštovani, 

Zahtjev je prebačen na produkciju. 

Molimo suglasnost za zatvaranje zahtjeva. 




0











Klijent: 





Hitnost: 

Vrlo hitno 




13373 

U rješavanju 


15.05.2013 10:44 

Upisao: 

Boško Tokić 

Područje: 

LFINK 


20.05.2013 


Omogućiti na navedenom objektu kamob_ff da se preskoči nivo knjiženja, tj. da u obračun uđu svi nivoi 

knjiženja i umetnuti stavku Hijerahija gdje će se moći odabrati D-pregled za izabranog partnera i O-pregled 

za izabranog partnera i partnere sa istim OIB-om. Tipke za daljnji rad i obradu na ekranu (F1, F2 i F5) 

prilagoditi novom načinu pretraživanja. 



0









Poštovani, 

Molimo potvrdu prijedloga rješenja za navedeno pod a), b) ,c) te pod e) slučaj s1 i s3 

Molimo odgovore na pitanja vezano za navedeno pod d) te pod e) slučaj s2 i s4 ( Hijerarhija=O) 

Status : Usaglašavanje voditelj-klijent / Čekamo pojašnjenje od HP 

Omogućiti na navedenom objektu kamob_ff 

a) da se preskoči nivo knjiženja, tj. da u obračun uđu svi nivoi knjiženja i 

b) umetnuti stavku Hijerahija gdje će se moći odabrati D-pregled za izabranog partnera i O-pregled za izabranog 

partnera i partnere sa istim OIB-om. 

c) Tipkeu F1 prilagoditi novom načinu pretraživanja. 

d) Tipku F2 prilagoditi novom načinu 

e) Tipku F5 prilagoditi novom načinu 

planiramo realizirati na način : 

a) da se preskoči nivo knjiženja, tj. da u obračun uđu svi nivoi knjiženja : 

---mijenja se validacija koja sad traži obavezno zadavanje orgj : Morate unijeti podatak (bilo potrebno kad je 

svako Sp radilo za sebe) 

b) umetnuti stavku Hijerahija gdje će se moći odabrati D-pregled za izabranog partnera i O-pregled za izabranog 

partnera i partnere sa istim OIB-om. 

-- ubacuje se novo polje Hijerarhija pored polja Godina ** 

-- Novo polje dugo je 1 znak, (default=D ) 

-- navezano na hijerarhija_if ali se može zadati samo opcija : 

D ( samo zadani partner) ili 

O ( svi partneri sa OIB kao što ga ima zadani partner ) 

-- validacija u slučaju da partner nema OIB javlja poruku parner nema OIB i postavlja Hijerarhija=D 

Razlog : pregled sa opcijom Hijerarhija=O u tom slučaju nema smisla kao ni obračun kamata za sve partnere 

koji nemaju OIB a zadan je neki konkretni partner 

c) Tipkeu F1 prilagoditi novom načinu pretraživanja. 

Na tipkama nema dorada : 

Detalj F1 - nema dorada 

Natrag F7 - nema dorada 

Naprijed F8 - nema dorada 

d) Tipku F2 prilagoditi novom načinu 

---- analizirat će se nakon što se usaglasimo oko načina rješavanja za izmjena za F5 pregled . 

dilema : Što napraviti u slučaju da je neki broj zatvaranja na stavkama partnera koji nemaju isti OIB tj. dio 

prometa je na oib_x a dio na oib_y : 

-- onemogućiti obračun kamata i javiti poruku : Sve stavke nisu na praterima sa istim OIB-om - kamate se ne 

mogu obračunati 

ili 

-- ne treba ništa javljati niti braniti nego napraviti obračun pa kako bude pa ako se kupac žali onda poslati LAUSu 

kao grešku u programu da ispravi ili knjigovodstvu da preknjiži ? 

NAPOMENA : KLJUČNI princip : stavke zatvorene jednim brojem zatvaranje su u jednom obračunu kamata !!! 

Ako ovakve problematične stavke trebaju ulaziti u obračun kamata , molimo navedite : u obračunu su za 

partnera na kojem je račun ili na kojem je uplata ? 

e) Tipku F5 prilagoditi novom načinu 

---Dorade na Stavke F5 vezano uz moguće zadane uvjete za Orgj i Hijerarhija : 

orgj Hijerarhija Oznakla sličaja 

zadana D s1 

zadana O s2 

nije zadana D s3 

nije zadana O s4 

slučaj s1 : Orgj zadana , Hijerarhija =D 

--- dorada nema jer je zahvat podataka kao što sad radi : 



0







-- prikupljaju -završen, se jail-ovi Isporučen (brojevi - Korisnik zatvaranja potvrdio za obračun ispravnost ) na način da se gledaju zatvorene uplate na zadanom 

partneru i orgj 

--- uzimaju se onda sve zatvorene uplate i računi zatvoreni prikupljenim jail-ovima 

--- sve skupa ulazi u obračun kamata 

slučaj s3 : Orgj nije zadana , Hijerarhija=D 

-- dorade su jednostavne : svugdje se ukida uvjet na arhivk.orgj=zadani . 

-- ostalo bez promjene . 

slučajeve s2 i s4 tj. Hijerarhija = O ne možemo riješiti bez jasnih odgovora na pitanja : 

1. Koje stavke na strani računa (za konto 120000 dugpot=D) ulaze u pregled i obračun kamata ? 

2. Koje stavke na strani uplata ( za konto 120000 dugpot=P) ulaze u pregled i obračun kamata ? 

3. Što napraviti u slučaju da je neki broj zatvaranja na stavkama partnera koji nemaju isti OIB tj. dio prometa je 

na oib_x a dio na oib_y : 

--- takve jail-ove tj stavke sa tim jail-ovima uopće ne treba prikazati na pregledu : ni one koje imaju ni one koje 

nemaju OIB kao zadani partner 

ili 

-- takve stavke na pregledu posebno prikazati/označiti 

ili 

-- ne treba ništa posebno raditi u ovom slučaju nego samo prikazati stavke koje imaju jednak OIB kao i zadani 

partner 



0











Klijent: 






Vrlo hitno 


Katja Kraljev 


13372 

Subject: Tajnica - ne vidi spise iz 2011. i 2012. 



15.05.2013 09:20 

Upisao: 

Boško Tokić 

Područje: 

EHPUR 




Poštovani, 

Zahtjev je riješen i prebačen na testni server. 

Molimo povratne informacije /suglasnost za prebacivanje na produkciju 


Poštovani, 






0











Klijent: 





Hitnost: 

Vrlo hitno 




13371 



14.05.2013 14:52 

Upisao: 

Boško Tokić 

Područje: 

EOBRRAC 


14.05.2013 


Ne vidi se podgrupa troška 2013-5.6.3 u Eobradi kod P1-T2(Urudžbiranje računa u novi predmet). 

Napravljen je prijenos prema MILA bazi 

(prilog) 


Poštovani, 

Podgrupa 2013-5.6.3. vidljiva je u P1-T2 ( u prilogu) 



Poštovani, 




0











Klijent: 





Hitnost: 





13370 



14.05.2013 13:42 

Upisao: 

Boško Tokić 

Područje: 

LBASE 


27.05.2013 


30.06.2013 

Otvoriti novi meni KREDITNA KATEGORIJA KUPACA unutar koje će se unositi 

- matični podaci o partneru 

- zaključak o kreditnoj kategoriji kupca 

- blokada 

-pregledi i liste 

Vjerojatno će se nakon nekog vremena ukazati potreba za proširivanjem i otvaranjem novih objekata, za 

sada bi unosili matične podatke prema zahtjevu dalje. 

(prilog) 



0











Klijent: 





Hitnost: 

Vrlo hitno 




Poštovani... 

13369 



14.05.2013 10:41 

Upisao: 

Boško Tokić 

Područje: 

EPNAB 


20.05.2013 


Stupanjem na snagu novog Zakona o javnoj nabavi propisano je i donošenje odgovarajućih uredbi. Jedna 

od tih uredbi je i „Uredba o dokumentaciji za nadmetanje i ponudama“. U članku 5. se spominje način 

funkcioniranja Okvirnih sporazuma koji nije u skladu s funkcioniranjem aplikacije. 

Naime, moguće je odrediti okvirne količine kod Okvirnih sporazuma i te količine mogu biti do iznosa 

procijenjene vrijednosti. Dakle, unatoč što smo mi dobili cijenu npr. 700.000 kn na procijenjenu od 

1.000.000 kuna, možemo sklapati ugovore do iznosa od 1.000.000 kuna. Trenutno je moguće izdavanje 

ugovora/narudžbenica do iznosa ponude, a ne procijenjene vrijednosti. 

Stoga predlažemo, rješavanje tog problema kako je na skici OS-a: 

(prilog) 



0









Poštovani, 

Rok za prebacivanje izmjena po zahtjevu 13369 je 18.7.2013. 



Poštovani, 

Ovaj zahtjev je prebačen na test. Na ekran okvirnog sporazuma dodana je kvačica Okvirne količine i polje 

Dopuštena cijena bez PDV. Odabirom kvačice Okvirne količine otvara se polje za unos Dopuštene cijene bez 

PDV (koja ne može biti veća od procijenjene vrijednosti predmeta nabave). U Registar OS-a dodana je nova 

kolona Dopuštena cijena bez PDV. Ukoliko postoji iznos u koloni Dopuštena cijena bez PDV, tada je to 

relevantna vrijednost za sklapanje ugovora i izdavanje narudžbenica po OS-u. Ukoliko na okvirnom sporazumu 

nije određena Dopuštena cijena bez PDV ,tada u registru OS nema iznosa u koloni Dopuštena cijena bez PDV i 

kao relevantna vrijednost za sklapanje ugovora i izdavanje narudžbenica po OS-u je iznos iz kolone Ukupna 

vrijednost. 

Lp 



0









Poštovani, 

Nastavno na današnji sastanak održan u prostorima HP u Hrovatovoj, na testnom HP serveru nalaze se sljedeći 

zahtjevi: 

§ 13132.1 – zahtjev djelomično riješen 

§ 13132.9 – potvrđeno za prebacivanje na produkciju 



§ 13369 – potvrđeno za prebacivanje na produkciju 

§ 13457 – točka a potvrđena za prebacivanje na produkciju, za točku b još uvijek čekamo potvrdu 

§ 13461 – potvrđena ispravnost po ovom zahtjevu, ali se čekalo rješavanje zahtjeva 13467 

§ 13467 – potvrđeno za prebacivanje na produkciju 

S obzirom da se radi o ukupno 8 zahtjeva, među kojima zahtjev 13369 ima najveći prioritet (izmjene vezane uz 

okvirne količine na okvirnim sporazumima), nismo u mogućnosti prebaciti samo dio izmjena na produkcijsku 

okolinu. Stoga predlažemo da se na produkcijsku okolinu prebace svi gore navedeni zahtjevi. Preduvjet za isto je 

potvrda od strane HP da se isto može napraviti. 

Zahtjev 13132.1 djelomično je riješen i smatramo da prebacivanje istog na produkcijsku okolinu neće stvoriti 

probleme u radu. Navedeni zahtjev bit će riješen ovaj tjedan. 

Zahtjev 13491 odnosi se na rušenje aplikacije nakon što ste na testni server kopirali produkcijsku bazu. 

Navedeni zahtjev je riješen i još zuvijek čekamo potvrdu o zatvaranju istog. 

Potrebna nam je potvrda gore navedenih točaka kao temelj za daljnje aktivnosti. 



Poštovani, 




0











Klijent: 





Hitnost: 

Vrlo hitno 




13368 



14.05.2013 10:36 

Upisao: 

Boško Tokić 

Područje: 

EPNAB 


20.05.2013 


Kroz ePlanNabave potrebno je ispraviti podatak 'Ugovor vrijedi do' za ugovor HP-10/2/1-008072/13 i 

staviti 13.06.2013 (sada nema datuma): (prilog) 


Poštovani, 

Ispravljen je na produkciji podatak 'Ugovor vrijedi do' za ugovor HP-10/2/1-008072/13. Stavljen je datum 

13.06.2013. 

Molim potvrdu zatvaranja zahtjeva. 


Poštovani, 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja Kraljev 


13367 



14.05.2013 07:33 

Upisao: 

Boško Tokić 

Područje: 

EHPUR 


16.05.2013 

Poštovani! Molim Vas da se ovaj zahtjev riješi tijekom sutrašnjeg dana. 



Od ureda za pravne poslove zaprimio sam zahtjev za promjenom naziva predmeta i rješavatelja budući je 

došlo do omaške pri otvaranju dolje navedenih predmeta. 

Sukladno traženju Ureda za pravne poslove molim Vas da se u spisu broj: 010762/13, naziv predmeta: 

Zahtjev za zaštitu prava - Vusilović Nenad, promjeni u naziv predmeta: Milan Kraguljac – upozorenje, te da 

se promjeni rješavatelj u: Lidija Karlović. 

Također je u spisu broj: 010763/13, naziv predmeta: Zahtjev za zaštitu prava - Jakupović Nataša, promjeni 

u naziv predmeta: Prijedlog Pravilnika o mirenju, te da se promjeni rješavatelj u: Ivan Antić. 


Poštovani, 

na produkciji su izvršene korekcije na spisima sukladno Vašim zahtjevima. 



Poštovani! 




0











Klijent: 





Hitnost: 

Vrlo hitno 




13366 

Dorade vezane za WEB shop: (prilog) 



13.05.2013 14:07 

Upisao: 

Boško Tokić 

Područje: 

LWINFAU 


20.05.2013 

U dijelu Veze Grupe Internet trgovine-Artikl potrebno je izvršiti dorade: 


1. Polje “Tržište”umjesto “Strano” trebalo bi biti “Domaće i strano” 

2. U srednjem dijelu ekrana pregleda gdje se dobiju polja kao rezultat pretraživanja uvesti i polje 

“Stanje” koje bi davalo stanje po tim artiklima na skladištima definiranim parametrom za internet trgovinu, 

ali i druga skladišta, u prilogu grafički prijedlog rješenja ili kod prikaza stanja u donjem ekranu za upisani 

artikl staviti mogućnost da se dobije stanje tog artikla po drugim skladištima ( ne samo web), 

te stanje tog artikla ako postoji u PU 

3. U pregledu kod 'Veza Grupe Internet trgovine-Artikal' uvesti polje za preživanje (,=), pa polje za unos 

broja tako da bi se mogli dobiti npr. artikli koji imaju stanje na skladištima za web < 10 kom 

4. Postaviti alarm (upozorenje) za minimalnu zalihu kao i u Laus modulu za e-bonove 

5. Ne pročita se nadređena grupa nakon što se upiše grupa 

6. Uključiti nadređenu grupu u pretraživaču 

7. excel treba biti sa svim atributima artikla označenog za internet prodaju 

8. Postaviti mogućnost sortiranja artikala po abecednom redu u srednjem prozoru 



0









Poštovani, 

Procjena za rješavanje ovog zahtjeva je 16 sati . 

Dio zahtjeva će se isporučiti sutra (srijeda 15.05.2013). Ostatak do petka 17.05.2013. 


Poštovani, 

U polje Tržište omogućeno je da umjesto Strano bude Domaće i strano. 

Kao filter polje nadodana je nadređena grupa. 

Kod ispisa u excel sada se prikazuju i podatci o atributima. 


Instalacija: novi WIN FAUS lib je već na internetu. 


update web_grupa_art 

set trziste = '1' 

where trziste = 'D'; 

update web_grupa_art 

set trziste = '2' 

where trziste = 'S'; 

Molimo povratne informacije 


Poštovani, 

Kod pregleda na ekranu 'Veza Grupe Internet trgovine-Artikal' nadodano je filter polje za pretraživanje po stanju 

na web skladištima (,=). 

Na istom ekranu je nadodan i prikaz stanja na skladištu koja nisu WEB. Kako nema puno slobodnog mjesta na 

ekranu, stavljeno je da se prikazuje stanje sa 3 skladišta sa najvećim količinama. 


Instalacija: sutra u četvrtak 16.05.2013. bit će dostupan novi WIN FAUS lib. 



Poštovani, 

Iz ovog zahtjeva ostaje još neriješeno : 

-- sortiranje 

Prijedlog : Za sortiranje podataka možemo napravit novo polje gdje bi se odabralo po čemu se žele sortirati 

podaci u pregledu. 

Pitanje : Osim po abecednom redu artikala, po čemu biste joše željeli imati mogućnost sortiranja? 

Stataus : Čeka se odgovor HP 

--- alarm : 

Postaviti alarm (upozorenje) za minimalnu zalihu kao i u Laus modulu za e-bonove. 

Pitanje : Gdje bi se to upozorenje prikazivalo? Kolika je minimalna zaliha? 

Status : Čeka se odgovr od HP 

Molimo pošaljite odgovore/ pojašnjenja kako bismo mogli zahtjev riješiti do kraja 



0









Poštovani, 

Na ekranu je omogućeno sortiranje podataka po šifri artikla i po nazivu artikla. 

Ako artikal na WEB skladištima ima manju količinu od minimalno definirane količine tada se crvenom bojom 

prikaže poruka upozorenja (iza teksta Stanje na WEB skladištu). 

Da bi se poruka o upozorenju pravilno prikazivala potrebno je za WEB artikle definirati minimalne količine. 


Instalacija: Novi WIN FAUS lib je već na internetu. 



Poštovani , 

Vezano za maksimalnu, minimalnu i optimalnu količinu artikla na skladištu u robnom dijelu postoji mogućnost : 

-- pregleda i ispisa na :artmz_ul_ja ARTIKLI SA MIN.MAKS.OPTIM.KOLIĽINOM 

-- ažuriranja na : artmm_ul_ja PRIDRUŞIVANJE ARTIKLU MIN.MAKS.OPTIM.KOLIĽINA 

Podaci se smještaju u tablicu artmm . 

Ukoliko je ovo dostatan odgovor na upit kojeg ste poslali : 

U kojem dijelu robnog i materijalnog poslovanja se može unijeti količina po artiklu na skladištu? 

molimo suglasnost za zatvaranje zahtjeva - Riješen 


Filter Stanje WEB se dosad primjenivao samo na upisane artikle. Sada se taj filter primjenjuje i na neupisane 

artikle. 

Kod pregleda neupisanih artikala sada se prikazuju samo artikli tipa R (roba). 



Na ekranu pregleda artikala u pregledu je nadodano polje Stanje WEB gdje se za artikal prikaziva ukupna 

količina sa svih WEB skladišta. 

U četvrtak 06.06.2013 ujutro bit će dostupan novi WIN FAUS lib. 


Poštovani, 

Prema našoj evidenciji sve po zahtjevu je isporučeno , uključivo i dorade tražene 22.5.2013 (zadnje) 

Molimo povratne informacije /suglasnost za zatvaranje zahtjeva - Riješen 

Slijedi popis isporuka po zahtjevu : 

15.5.2013. 

1. Riješeno : U polje Tržište omogućeno je da umjesto Strano bude Domaće i strano. 

6. Riješeno : Kao filter polje nadodana je nadređena grupa. 

7. Riješeno : Kod ispisa u excel sada se prikazuju i podatci o atributima. 

3. Kod pregleda na ekranu 'Veza Grupe Internet trgovine-Artikal' nadodano je filter polje za pretraživanje po 

stanju na web skladištima (,=). 

2. Na istom ekranu je nadodan i prikaz stanja na skladištu koja nisu WEB. Kako nema puno slobodnog mjesta 

na ekranu, stavljeno je da se prikazuje stanje sa 3 skladišta sa najvećim količinama. 



0








PITANJA : 

8. Za sortiranje podataka možemo napravit novo polje gdje bi se odabralo po čemu se žele sortirati podaci u 

pregledu. 

Osim po abecednom redu artikala, po čemu biste joše željeli imati mogućnost sortiranja? 

# HP: Još po šifri artikla 

4. Postaviti alarm (upozorenje) za minimalnu zalihu kao i u Laus modulu za e-bonove. 

Gdje bi se to upozorenje prikazivalo? Kolika je minimalna zaliha? 

# HP : U kojem dijelu skladišnog poslovanja se unosi količina po artiklu? 

Iz tog dijela neka se u novom podatku ‘Minimalna količina’ (prilog) prikazuje minimalna količina i prikazuje 

poruka upozorenja. 

17.5.2013. 

8. Riješeno :Na ekranu je omogućeno sortiranje podataka po šifri artikla i po nazivu artikla. 

4. Riješeno : Ako artikal na WEB skladištima ima manju količinu od minimalno definirane količine tada se 

crvenom bojom prikaže poruka upozorenja (iza teksta Stanje na WEB skladištu).Da bi se poruka o upozorenju 

pravilno prikazivala potrebno je za WEB artikle definirati minimalne količine. 

4. # HP PITANJE: 

Potrebno je poslati odgovor na upit: :U kojem dijelu robnog i materijalnog poslovanja se može unijeti količina po 

artiklu na skladištu? 

LAUS odgovor : 

Vezano za maksimalnu, minimalnu i optimalnu količinu artikla na skladištu u robnom dijelu postoji mogućnost : 

-- pregleda i ispisa na :artmz_ul_ja ARTIKLI SA MIN.MAKS.OPTIM.KOLIĽINOM 

-- ažuriranja na : artmm_ul_ja PRIDRUŞIVANJE ARTIKLU MIN.MAKS.OPTIM.KOLIĽINA 

Podaci se smještaju u tablicu artmm . 

Ukoliko je ovo dostatan odgovor na upit kojeg ste poslali : 

U kojem dijelu robnog i materijalnog poslovanja se može unijeti količina po artiklu na skladištu? 

molimo suglasnost za zatvaranje zahtjeva - Riješen 

22.5.2013. 

#HP : Objekt webart.jas VEZA GRUPA - ARTIKL 

Na srednjem ekranu pregleda nedostaje polje Stanje (količina na skladištima definiranim parametrom) iza Naziva 

artikla – može se naziv kratiti ili šifra Artikla , tefilter Stanje WEB ne radi ispravno.U pregledu (Upisani ili 

Neupisani) trebali bi se pojavljivati samo artikli tipa R (roba). 

05.06. 2013. 

Filter Stanje WEB se dosad primjenivao samo na upisane artikle. Sada se taj filter primjenjuje i na neupisane 

artikle. 

Kod pregleda neupisanih artikala sada se prikazuju samo artikli tipa R (roba). 

Na ekranu pregleda artikala u pregledu je nadodano polje Stanje WEB gdje se za artikal prikaziva ukupna 

količina sa svih WEB skladišta. 



0









Poštovani, 

U obradi 9 ovog KZ dana 17.5.2013. vezanog za točku 4. stoji : 

# HP PITANJE: U kojem dijelu robnog i materijalnog poslovanja se može unijeti količina po artiklu na 

skladištu? 

LAUS odgovor :Vezano za maksimalnu, minimalnu i optimalnu količinu artikla na skladištu u robnom dijelu 

postoji mogućnost ažuriranja na : 

artmm_ul_ja PRIDRUŽIVANJE ARTIKLU MIN.MAKS.OPTIM.KOLIČINA 

Naknadno smo utvrdili da kod vas na meniju taj objekt ne postoji ( veza zahtjev HP broj 13388) . 

Potrebno je koristiti objekt artmm_ul_jd MIN, MAX, OPT Količine Artikala Na Skladištu 

koji se nalazi na ME 1203 OSTALI PODACI gdje je omgučena unos ,brisanje i izmjena. 


NAPOMENA : sve točke zahtjeva su riješene i isporučene ( zadnja isporuka 5.6.2013) 


Ispravljena je kontrola da se ne treba upisivati naziv na engleskom za domaće tržište. 

Nadređena opća grupa se uvijek prikazuje kada se upiše neki artikal. 

Količina za rtikle se gleda iz tablice stanje_skl. 

Na test serveru je definirana količina na web skladištima samo za artikle: 

artikal kolicina 

320800 4.000 

317046 28.000 

322544 990.000 

300047 120.000 

312322 10.000 

320803 30.000 

315376 10.000 

320801 250.000 

300004 50.000 

320798 1000.000 

322545 1000.000 




S štovanjem 

Poštovani, 

Zahtjev 13366 možete zatvoriti. 


----------------------------------------------------- 




0











Klijent: 





Hitnost: 

Vrlo hitno 




13365 



13.05.2013 13:25 

Upisao: 

Boško Tokić 

Područje: 

EPNAB 


13.05.2013 

Kroz ePlanNabave danas 13.5.2013 pet ugovora su poslano u LAUS: 

Originalni broj ugovora LAUS broj Dobavljač 

NARUDžBENICA 02/2013 01400R1300069 601584 2013.05.13 

HP-10/1-007787/13 10015R1300041 641485 2013.05.13 

HP-10/2-005232/13 40015R1300041 649525 2013.05.13 

HP-10/2/1-007647/13 40015R1300042 630740 2013.05.13 

HP-10/2/1-007645/13 41039R1300200 640517 2013.05.13 

U ePlanuNabave ni jedan ugovor nije dobio LAUS broj. 


Napominjem da je ArgosyIntegracijski servis bio ugašen, pa je ponovo startan oko danas oko 11:00, ali 

LAUS brojeva u ePN nema. 

Zašto je integracijski servis bio ugašen? Zar ne postoji automatika startanja servisa nakon njegovog 

gašenja? 


Poštovani, 

Provjerom na produkciji u aplikaciji ePlanNabave, navedeni ugovori i narudžbenica su dobili LAUS broj. Molimo 

potvrdu zatvaranja zahtjeva. 


Poštovani, 




0











Klijent: 





Hitnost: 

Vrlo hitno 




13364 



13.05.2013 13:19 

Upisao: 

Boško Tokić 

Područje: 

LWINFAU 


13.05.2013 

Potrebno napraviti hitnu procjenu na temelju dostavljenog zahtjeva. (prilog) 

Lp, Glorija Markovac 




0









Analiza zahtjeva korisnika. Priprema pitanja na temelju izvornog oblika zahtjeva, kako bi se došlo do što točnije 

prve procjene. 


Poštovani, 

u prilogu su komentari /pitanja na koje HP treba dati svoj stav kako bi procjenili potrebni angažman i rokove 

isporuke 

Status : Čeka se pojšnjenje klijenta 

Napomena : u prilogu različitim bojama označeno : 

crveno :: prijenosi koji nisu u zahtjevu navedeni ali se podrazumijevaju 

plavo : prijenosi koji su navedeni u zahtjevu 

siva podloga : pitanja za koja molimo odgovore/pojašnjenja 

žuta podloga : krovne šifre partnera u prijenosu,ugovorima i računima 


Poštovanje, 

U privitku je okvirna procjena angažmana po pojedinim segmentima za realizacije integracije LAUS i eBox 

sustava. Procjena je temeljena na dosad dostupnim informacijama i određenim ogradama navedenim u privitku. 

Prije odobrenja realizacije, potrebno je napraviti detaljnu snimku procesa i analizirati sve zahtijevane 

funkcionalnosti, te ponoviti procjenu za aktivnosti od dokumentiranja do isporuke. 

LP 

Ljubo Nikolić 


Poštovani, 

Zahtjev je na popisu neriješenih zahtjeva koji je poslan kao prilog zapisniku sa sastanka IT-LAUS 10.06.2013.g. 

Mismo zahtjev zatvorili nakon što smo poslali procjenu kao što ste tražili . 

U međuvremenu nismo dobili potvrdu procjene 

Za realizaciju zahtjeva očekujemo da ćete uputiti novi zahtjev uz napomenu - veza zahtjev 13364 


Trenutni status : Čeka se stav HP 

zadnja obrada 21.5.2013 : 

U privitku je okvirna procjena angažmana po pojedinim segmentima za realizacije integracije LAUS i eBox 

sustava. Procjena je temeljena na dosad dostupnim informacijama i određenim ogradama navedenim u privitku. 

Prije odobrenja realizacije, potrebno je napraviti detaljnu snimku procesa i analizirati sve zahtijevane 

funkcionalnosti, te ponoviti procjenu za aktivnosti od dokumentiranja do isporuke. 



0











Klijent: 





Hitnost: 

Vrlo hitno 




13361 



13.05.2013 10:23 

Upisao: 

Boško Tokić 

Područje: 

LROBD 


20.05.2013 


Kod ispisa MDOKzga_rd (koristi se kod svih ispisa dokumenata sa PU – protokol X) potrebno je napraviti 

sljedeće promjene. Smanjiti polje Naziv, Cijena staviti MPC, a staviti PDV, Marža i Nabavna (sve prikazati 

kao vrijednosti). Znači imamo Artikl šifra pa Artikl naziv pa JMJ pa količina pa MPC (jedinična), pa onda 

vrijednosti (MPC, PDV, Marža i Nabavna). Polja Red i V izbaciti. Na dnu liste polja Vrijednosti dati sumarno. 

Po istom principu preurediti listu XXXzgaHP_rd, ostaju polja Artikal Naziv pa JMJ pa Količina pa MPC 

jedinična – polje MPC bez PDV-a izbaciti, a polja PVV, Marža i NC prikazati kao vrijednosti i na dnu staviti 

sumu tih vrijednosti. 


Na ispisima XXXzgaHP_rd i MDOKzg_rd dodane su vrijednosti po kalkulativnim elemntima MPC1,POR,MPM i 

NC kao zbroj tih vrijednosti. 

Preuzmite laus libove rob0,rob1,rob2,rob3 i rob4 koji će bit na internetu 15.05.2013. 


Lista XXXzgaHP_rd je za dokumente u statusu većem od 1 uzimala vrijednosti iz obračuna (tablica hp_svrij) , a 

pošto 41043 nje robno skladište nego materijalno tada vrijednosti osim nabavne su jednake nuli odnosno nema 

ih tj. sada lista i za dokumente u statusu većem od 1 uzima vrijednosti ,cijene iz cjenika koje su aktivne na datum 

dokumenta. 

Potrebno je preuzeti laus rob0,rob1,rob2,rob3 i rob4 koji su na internetu 29.05.2013. 



0











Klijent: 





Hitnost: 

Vrlo hitno 




13363 



13.05.2013 08:46 

Upisao: 

Boško Tokić 

Područje: 

LFINK 


13.05.2013 


Napravljen je prijenos IBANa za jednog partnera prema eObradi. 

Napravljen je prijenos IBANa prema MILA bazi te su isti prenijeti od strane integracijskog servisa ali se ne 

vide u eObradi: 

select * from partzir_eolog where ziror like 'HR%' and part='613157'; 

select * from mips_laus@mips_laus:partzir_eolog where ziror like 'HR%' and part='613157'; 

Zašto ? 

--- ranije poslan u eObrada i nije na partneru 613157 : 

slog_id part akt akc datum upisa datum preuzimanja status 

274460 625062 D I 2013-02-08 14:53:55 2013-02-08 22:31:19 1 

274459 638105 D I 2013-02-08 14:53:55 2013-02-08 22:20:19 1 

-- sad upisani kroz bazu laus u part_eolog preneseni u mips_laus bazu i staggeing bazu na eObrada strani 

41 slog sa obilježjem : 

part akt akc datum upisa datum preuzimanja status 

613157 D I 2013-05-12 00:00:00 2013-05-12 23:02:07 1 



0









Poštovani, 

Da li se ne prenošenje IBAN-a odnosi na testno okruženje ili na produkciji? 


Poštovani, 

Provjerili smo : 

IBAN su vidljivi u eObradiRačuna na produkciji. 




IBAN su vidljivi u eObradiRačuna na produkciji. 





Poštovani, po vašem nalogu zatvaramo zahtjev. 

S štovanjem 





0











Klijent: 





Hitnost: 

Vrlo hitno 




13362 



10.05.2013 15:43 

Upisao: 

Boško Tokić 

Područje: 

LFINK 

eo_mila_jf PRIJENOS PODATAKA IZ LAUS-A U E-OBRADU 


10.05.2013 

Potrebno je poslati sve primke iz LAUSa u eObradu koje nisu prenijete. 

Uvjet je da te primke nisu u tablici primka_eolog 

select * from protokol where vdok in ('RP3','RPP','TPR') 

and datumdok >='01.04.2013'; 




0









Poštovani , 

Prema zadanim kriterijima u zahtjevu te uvjetu da status nije 9 (12 primki) i da dobavljač nije izvan Hrvatske ( 1 

primka P 688660) 

-- u laus bazi je upisana 3851 primka u tablicu primka_eolog : 

RPP nema ih u rad_protokol jer je trigger bio neaktivan ( 140 primki) 

RP3 su u rad_protokolu ali se nisu prebacile jer su nastale prije nego je trigger proširen sa RP3 

-- programom eo_mila_ff prenesene u mila bazu. Prijenos F1 

[Prijenos podataka (primke,ugovori,partneri) iz Lausa u eObradu (preko Mile) 

Dan, datum i vrijeme prijenosa Pet 10/05/2013 16:36 


NAPOMENA: 

u laus bazi je akcija U za primke koje dolaze prijenosom (RP3) ili ako triger ne radi tj. nije registrirano za vrijeme 

upisa primke kao nova (akcija=I) . 

Akcija U preslika se u akcija= I u mila bazi ako se utvrdi da u mila bazi nema takve primke . 

Ubačene primke su u datoteci /home/admlaus/ primka.txt 


Poštovani , 

Prijenos primki LAUS-->eObrada funkcionira na sljedeći način: 

1. tipkom se primke za prijenos prenose iz laus tablice primka_eolog u mip tablicu primka_eolog (eo_mila_jf) 

2. integracijski servis preuzima podatke iz mips primka_eolog i šalje ih u međubazu eObradaRacuna - 

provjereno 

3. DokIT dalje preuzima te podatke i puni ih u produkcijsku bazu 

Problem predstavljaju točke 1 i 3, a integracijski servis uredno prenosi sve što dođe do mips primka_eolog 

tablice. 

1. Utvrđeno i ispravlja se prijenos eo_mila_jf zašto se primke ne prenose, a uredno su označene da su 

prebačene u mila bazu. 

3. DokIT provjerava sa njihove starne zašto se NE preuzimaju primke iz eObradaRacuna međubaze. 


Zasad ništa . 

NAPOMENA : istražujemo koje sve primke se nalaze u primka_eolog u laus bazi a nema ih u mips_laus bazi (1) 

te ćemo poslati popis . 



0









Poštovani, 

Omogućen je prijenos između tablica primka_eolog LAUS->MILA na objektu eo_mila_pup za slogove sa akcijom 

I koje se u LAUS pune triggerom u tablici primka_eolog. 


Obavijestiti korisinka o preuzimanju novog LAUS FINK liba koji se već nalazi na internetu. 

Status: molimo suglasnost za predloženo 

------------------------------- 

Primke koje se iz laus baze nisu prenijele u mila bazu nemaju popunjeno aktivnost. - rješavamo 

-------------------------------- 

Utvrdili smo : 

Postoji 12 282 zapisa koji se odnose na primke koje imaju aktivnost null ili '' u laus bazi , različitih 6653 . 

Njih 168 preuzeto je prije sa akcija=I , aktivnost=D . Preostalih 6485 različitih kombinacija 

protokol,dobavljac,akcija nema u mips_laus bazi 

PRIJEDLOG poslati ove neprenesene primke ponovo u eObrada . Potrebno je : 

a) generirati 6485 različitih zapisa u primka_eolog sa popunjenom aktivnost D ili N ovisno o akciji - baza laus 

b) pustiti prijenos eo_mila_jf 

c) provjeriti jesu li primke došle u mila bazu 

Molimo pošaljite suglasnost za formiranje zapisa u bazi navedenih pod a) kako bi se primke prenijele u 

eObrada 

NAPOMENA: 

u mips_laus bazu primke se prenose sa akcija=I-insert ako dosad nisu prenesene odnosno akcija =U-update ako 

su ranije prenesene a promijenio se dobavljač u odnosu na ranije poslano . Očekivat je da u laus bazi ima više 

slogova u primka_eolog nego u istoimenoj tablici u mips_laus bazi 

jer se od napr 10 izmjena (status='', akcija=U-update, aktivnost=D ) prenese samo zadnja važeća i to pod 

uvjetom da je različita od već poslanog) 



0









Poštovani, 

Upisano je 6577 slogova u primka_eolog u laus bazi sa datum_upisa= '2013-05-14 15:00:00' 

akcija='I' ; 5710 

akcija='U' ;861 

akcija='D' ; 6 

U mips bazi 170 već preuzetih sa aktivnost null 

Postojali su nepreneseni slogovi sa aktivnost null . 

akcija (count(*)) 

I 182 

U 1271 

primke_danas.txt 1453 row(s) unloaded. - kao primka_eolog ima stupce ,delimiter pipe 

Izvela sam ** : 

update primka_eolog set aktivnost='D' where 

aktivnost is null and akcija!='D' and 

( status='' or status is null) ; 

update primka_eolog set aktivnost='N' where 

aktivnost is null and akcija ='D' and 

( status='' or status is null) ; 

tako da i oni ulaze u prijenos. ( neki se preklapaju sa napunjenima ali ne utječe na prijenos) 

Sve dok se ne isporuči ispravak vezan za slučaj aktivnost null , prije puštanja prijenosa eo_mila_jf potrebno je : 

a) izvesti ** 

b) pustiti prijenos eo_mila_jf 

c) provjeriti jesu li primke došle u mila bazu 



Poštovani, 

Ispravljen je slučaj : u laus bazi primka_eolog se puni triggerima na protokol tablicu tako da je aktivnost null 

nakon zadnje izmjene istih 

Potrebno za instalaciju/testiranje : 

Izvedite na laus bazi upite u prilogu 


Poštovani, 

Primka 35358-P13-02686 je vidljiva u eObradiRačuna. (u prilogu) 

Nema neprenesenih primki (međubaza-baza na eObrada strani) 




0









Poštovani, 

Servis je stao te se zbog toga neki podaci nisu prikazivali u eObradi. 



Poštovani , 

Za rješavanje slučaja : 

Ne puni se aktivnost na primki kod akcije U- update . Procedure koje su poslane u OKZ 7 mijenjane su samo 

kod unosa i brisanja a nisu kod izmjene. 

potrebno je izvesti sql-ove za drop i create procedure protokol_dokit_upd za popunu polja aktivnost u tablici 

primka_eolog za akcija=U-update 

( u prilogu ) 

Molimo povratne informacije /suglanost za zatvaranje zahtjeva - Riješen 


Poštovani, 

Uprethodnoj obradi poslan prilog i odgovor . 

Molimo povratne informacije /suglanost za zatvaranje zahtjeva - Riješen 

Za rješavanje slučaja : 

Ne puni se aktivnost na primki kod akcije U- update . Procedure koje su poslane u OKZ 7 mijenjane su samo 

kod unosa i brisanja a nisu kod izmjene. 

potrebno je izvesti sql-ove za drop i create procedure protokol_dokit_upd za popunu polja aktivnost u tablici 

primka_eolog za akcija=U-update 

( u prilogu ) 






Poštovani, 




0











Klijent: 





sql serveri 


Nije hitno 


Marin Junušić 


Poštovanje! 

U rješavanju 


10.05.2013 14:16 

Upisao: 

Damir Konjevod 

Područje: 

LCSBI 


Može li se u sklopu MIS aplikacije konsolidirati MS SQL baze u smislu da imamo samo jednu instancu na 

jednom serveru (eventualno na klasteru)? 

Podsjećam kakva je trenutna situacija: 

SV-1OT-LAUSMIS.posta.int Microsoft SQL Server 2005 9.4.5000.00 SP4 Standard 

Edition 

sv-1ot-lausm1.posta.int Microsoft SQL Server 2008 R2 10.51.2500.0 SP1 Enterprise 

Edition (64-bit) 

sv-1ot-lausmis2.posta.int Microsoft SQL Server 2008 R2 10.51.2500.0 SP1 Enterprise 

Edition (64-bit) 

Još jedna napomena: Mi smo davno na lausm1 i lausmis2 instalirali SQL Server 2008 Standard Edition, a u 

procesu implementacije SAP servisa 

netko je reinstalirao SQL Server i stavio Enterprise Edition. Na početku ovog projekta ste nam rekli da je 

Standard edicija dovoljno dobra za ove servise. 

Da li onda ta nova instanca koju bi eventualno digli može biti Standard Edition? 

Pozdrav! 



0









Poštovani, 

Dražen Pavlović će kontaktirati tehniku CubeServa i poslati odgovor za svoj dio pitanja pa kad sve sastavimo 

Vam odgovorimo. 


Poštovani, 

odgovor što se tiče LAUS CC dijela je sljedeći (čekamo još odgovor tehničke službe od CubeServa za njihov dio) 

Sama baza na SV-1OT-LAUSMIS.posta.int može se konsolidirati. 

Server SV-1OT-LAUSMIS.posta.int mora nastaviti postojati jer se na njemu nalazi SQL Server Integration 

Services koji rade prepumpavanje LAUS baze u međubazu. Program koji radi prepumpavanje ovisan je o verziji 

Integration services, pa se stoga ne može jednostavno prebaciti na novu verziju. 


Poštovani, 

još uvijek čekamo odgovor od CubeServ-a za njihov dio. 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja Kraljev 


13360 



10.05.2013 14:08 

Upisao: 

Boško Tokić 

Područje: 

LROBD 


16.05.2013 


Preko objekta artdd_ja je moguće artiklu pridružiti podređenu šifru partnera, što nije u redu. 

Potrebno je i na ovom objektu staviti kontrolu da se artiklu može pridružiti samo krovna (nadređena) šifra 

partnera. 


Prilikom pridruživanja partnera artiklima artdd_ja omogučen je unos samo krovne šifre partnera. 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja Kraljev 


13359 



09.05.2013 11:08 

Upisao: 

Boško Tokić 

Područje: 

LROBD 


13.05.2013 


Kako bi u robno-materijalnom dijelu Laus aplikacije htjeli učitavati artikle preko barkod čitača na jedan od 

slijedeća dva načina: 

1.uđemo u robni dokument, učitamo artikal preko barkod čitača, unesemo količinu, spremimo uneseno i 

ponovim postupak za svaku slijedeću stavku dokumenta 

ili 

2.uđemo u robni dokument, učitamo artikal preko bar kod čitača, unesemo količinu, ponovimo postupak za 

svaku slijedeću stavku i na kraju spremimo unsene stavke. 

molim vas da nam pošaljete procjenu broja sati za izradu zahtjeva (za točku 1 i 2.) 

Barkod čitač koji bi koristili u depoima (Zagreb, Rijeka, Split, Osijek) – 

model Datalogic Gryphon GD4430KIT 



0









Poštovani, 

Točka 1. 

Za realizaciju podrške za rad u skladištu korištenjem bar kod čitača, na način da korisnik koristi bar kod čitač za 

očitanje šifre artikla i za to koristi postojeće LAUS ekrane, LAUS ne treba nikakve prilagodbe, pa nema ni našeg 

angažmana za implementaciju takvog rješenja. 

Točka 2. 

Izrada dokumentacije 12h 

- Dorade u programskom rješenju 120 h 

- Korisnička dokumentacija 20h 

- Instalaciju na test okruženje, test 10h 

- Edukaciju korisnika u trajanju od 2 dana 10h 

Ukupno 172h. 

S štovanjem 


Poštovani, 

Na dokumentima RPP-RPD,RIM-RPM,REV-REP i RM1 omogučeno čitanje artikla sa barkod čitačem. 

Potrebno je preuzeti laus liobove rob0,rob1,rob2,rob3 i rob4 koji će biti na internetu 6.6.2013. 

Molimo da provjerite opravdanost i potvrdite zahtjev da se tražena izmjena primjeni na dokumente RZU, RZI, i 

RZA - ovi dokumenti služe za knjigovodstvene ispravke i ne vidimo koristi od primjene bar cod čitača na njima. 

Također ne vidimo koristi za primjenu bar cod čitača na dokumentu RI1-inventura, jer u tom dokumentu stavke 

se automatski generiraju na osnovu skladišnog stanja. Također ne vidimo uporabnu vrijednost za dokumente 

RZP, RZV i RZZ jer oni automatski nastaju u statusu 7 i krajnji korisnik nema mogučnost pristupa stavkama! 

Molim potvrdu zahtjeva i za ovih 7 pobrojanih dokumenata. 

S štovanjem 


Na stavkama dokumenta RDP,RDU,RUD,RUP,ROK,RPK i RDD dodano je polje Bar-kod t omogučen je upis 

barkoda.Za dokumente kataloške prodaje nije potrebno jer nastaju iz narudžbenice kataloške prodaje NAR. 

Napravljen ispravak na dokumentu RPD. 

Potrebno je preuzeti laus libove rob0,rob1,rob2,rob3 i rob4 koji će biti na interentu 07.06.2013. 


Poštovani, 





0











Klijent: 





Hitnost: 

Vrlo hitno 




13358 



09.05.2013 10:49 

Upisao: 

Boško Tokić 

Područje: 

LROBD 


12.05.2013 


Kod punjenja tablice hp1_god_mj za 2013-03 rbr=1 dogodilo se da je 218779 slogova ušlo sa praznim 

brojem cjenika i kalkulacijom. Kada smo izbrisali i ponovili punjenje dogodilo se isto. Čudno je što je za iste 

artikle u jednom slučaju to napunjeno, a u drugom prazno. Tada na rekapitulacijama podaci budu bez 

kalkulativnih elemenata. U mailu primjeri. 

Prilozi: 

1. Zahtjev i 

2. Tabele 


Ispravljeno generiranje odnsono ažuriranje tablice hp1_god_mj sa cjenikom iz tablice hp0. 

Preuzmite laus libove rob0,rob1,rob2,rob3 irob4 koji će biti na internetu 10.05.2013. 



0











Klijent: 





prepod_jke 

Hitnost: 



visnja 


13357 



08.05.2013 12:56 

Upisao: 

Dajana Lekić 

Područje: 

LKEVP 


15.05.2013 


15.05.2013 

Pogrešan prijenos ERV-a za radnika – plaća 04/2013: 2013-04 br.obračuna 12 ( prepod_jke PRIJENOS 

PODATAKA IZ ERV U OBRAČUN) 

Prijenosom ERV-a u obračun plaće za 04/2013 radnik 39759 ima iskazano 10 sati više u fondu. Prijenos u 

ERV-u je dobro odrađen i radnik stvarno nema višak sati zaključno sa 30.04.2013. 

Ovaj radnik radio je na dan 01.04.2013. RAD NA PRAZNIK 12 SATI. Na isti dan ima DONO iz 03-2013 -10 

sati i sa istim danom ( 01.04.2013) promijenjeno mu je rješenje. Očito kod ovakve kombinacije program ne 

kompenzira dobro sate DONO sa satima rada na blagdan. 

Potrebno je izvršiti ispravak 


Poštovani, 

riješena je navedena kombinacija sati: 

- na dan blagdana i negativnim satima Donosa za rješenje koje je vrijedilo samo na taj datum prebacit će se 

točan fond sati. 

Prijenos možete provjeriti na Kontrolnom pregledu prijenosa za navedenu orgj 15229. 

Preuzmite kevp lib koji je dostupan od 15/05/2013. 



0











Klijent: 





otvaranje zahtjeva 

Hitnost: 

Vrlo hitno 


visnja 


13356 

Nemoguće otvaranje zahtjeva kroz ePN . Zašto ? 



08.05.2013 10:29 

Upisao: 

Dajana Lekić 

Područje: 

EPNAB 


08.05.2013 



Poštovani, 

Molim Vas, da li se to da ne može otvoriti zahtjev događa samo korisniku Stjepanu Mariću ili i ostalim korisnicima 

te u kome browseru se to događa. 


Poštovani, 

Navedeni zahtjev je u rješavanju. 

Dok se ne riješi, možete ručno razvući ekran zahtjeva klikom na rub i povlačenjem miša. Time omogućujete 

prikaz prozora na ekranu. 


Poštovani, 

Ovaj zahtjev je riješen na produkciji. Zahtjevi za nabavu (ekrani) koja se nisu mogli otvoriti, mogu se otvarati u 

sva tri browsera (IE, Firefox i Chrome). Molimo potvrdu zatvaranja zahtjeva. 

Lp, 



0











Klijent: 





bilanca PS 2012 

Hitnost: 



glorija 


13355 

Riješen 


08.05.2013 09:06 

Upisao: 

Dajana Lekić 

Područje: 

LCSBI 


20.05.2013 


Stanje u bilanci na 31.12.2012. u MIS-u ne odgovara podacima iz Lausa. Nakon izvršene provjere pojedinih 

pozicija, rekla bih a nisu učitana početna stanja za 2012. Prethodna godina (2011.) je u redu. Podaci za 

usporedbu nalaze se u privitku. 

Prilozi: Laus lista Bilanca 2012. 



0









Poštovani 

problem je otklonjen. Kod prebacivanja 11. mjeseca iz tekućeg perioda u arhivske podatke u agregacijskoj kocki 

je došlo do zastoja agregacije. Riješeno sinoć. 


Poštovani, 

Zahtjev je Riješen 9.5., pa 16.5. 

Od 16.5.2013 u statusu vraćen na rješavanje jer se radi o ponovljenom problemu ili neriješenom problemu : 

puca učitavanje 

Zadnja korespondencija s kojom raspolažemo je da je učitavanje s kojim je Dražen htio provjeriti situaciju puklo 

s razlogom . 

( Ivan Poldrugač 16.5.2013 ) : 

„Procedura je pukla zbog toga što smo morali produkcijsku bazu nasilno restartati zbog opterećenja na njoj. 

Molim te da mi pošalješ status migracije. 


Poštovani, 

ustanovljeno je da je došlo do izmjena u knjiženjima u 11/2012 koji je izvan dnevnog loada u LCS BI te je zbog 

toga došlo do neravnoteže bilance. Preporučamo odobravanje ponovnog inicijalnog loada 11/2012 u LCSBI. 


Poštovani, 

sinoć je odrađeno učitavanje 11/2012. U prilogu su balance za 11 mjesec i za cijelu 2012. U ravnoteži su. 



0











Klijent: 





fiskalni broj 

Hitnost: 



glorija 


13354 



08.05.2013 09:03 

Upisao: 

Dajana Lekić 

Područje: 

LWINFAU 


15.05.2013 


Molimo da se objektima fakot_fas, spamt_fas omogući uvjet pregleda, uz postojeći Laus broj računa, 

pregled po fiskalnom broju računa. 



0











Klijent: 





ruckat.jas DTV 

Hitnost: 



ivan 


13353 



07.05.2013 09:57 

Upisao: 

Dajana Lekić 

Područje: 

LWINFAU 


07.05.2013 


Kod unosa stavke preko objekta ruckat.jas za račune za digitalnu TV potrebno je osim postotka rabata 

omogućiti i ručni unos iznosa rabata 

(u tom slučaju postotak se izračuna). 


Poštovani, 

Kod unosa stavke preko objekta ruckat.jas omogućen je i ručni unos iznosa rabata (postotak se izračuna). 


Instalacija: U četvrtak ujutro 09.05.2013 bit će dostupan novi WIN FAUS lib 



Poštovani, 





0











Klijent: 



Zakonska promjena 


dis_ban_fk 

Hitnost: 

Vrlo hitno 


visnja 


13352 

Diskete za banke - novi format sloga (KROP)-HITNO! 



06.05.2013 17:00 

Upisao: 

Dajana Lekić 

Područje: 

LKROP 


20.05.2013 


Potrebno je kroz dis_ban_fk DISKETE ZA BANKE napraviti novi format sloga za HPB d.d. za isplatu 

neto plaća i ostalih primanja prema uputama u prilogu. 

Kako HPB u obavijesti navodi da je ovo jedinstveni format koji će vrijediti za sve banke molimo da se 

parametarski omogući primjena novog formata kako bi mogli na produkciji novi format mogli primijeniti 

samo za HPB, a ostale banke ćemo uključivati po odobrenju. 



0









Na izborniku IZVJEŠĆA NAKON OBRAČUNA PLAĆE napravljen je novi objekt dat_ban_fk DATOTEKA ZA 

BANKE na kojemu je moguće napraviti 

datoteku za banku u novom jedinstvenom formatu koji će se od 01.06.2013 koristiti za sve banke na kojima 

radnici imaju račune za isplatu plaće.Ukoliko banke ne zahtjevaju novi format datoteke 

i dalje se mogu koristi datoteke sa objekta dis_ban_fk DISKETE ZA BANKE. 

Kod formiranja datoteke koristi se IBAN račun radnika ukoliko je upisan, a do 01.06.2014 moguće je i dalje 

koristiti format tekućeg računa radnika (7 vodećih znakova iz računa banke + 10 znakova broja štednje radnika). 

Na ekranu je potrebno zadati šifru banke i račun firme sa kojeg je obavljena uplata plaće na banku.Inicijalno 

polje računa je popunjeno sa osnovnim računom firme a neki drugi se može odabrati 

tipkom Traži.Osim toga potrebno je zadati šifru vrste primanja koja se isplaćuje radnicima,a obzirom da se 

uglavnom radi o plaći polje je inicijalno popunjeno sa podatkom 100 koji označava isplatu plaće u cijelosti.Ostale 

vrijednosti mogu se odabrati tipkom Pomoć sa tog polja. 

Obzirom da datoteka odnosno zbrojni nalog za platni promet već ima preporučeni naziv UNggggmmdd.txt ova 

datoteka za isplatu plaća će imati naziv UNXXXXXXXX.txt gdje X-evi predstavljaju matični broj firme u duljini od 

8 znakova. 

NAPOMENA: 

prije formiranja datoteka u novom formatu potrebno je: 

- otvoriti novi tip dodatnog podatka INT - INTERNA ŠIFRA FIRME U BANCI 

- za svaku banku saznati njezinu internu šifru Vas kao poslodavca koji isplaćuje plaću i upisati je u dodatne 

podatke tog partnera - banke kao tip dodatnog podatka INT 

- ukoliko firma ima organizacijske grupe koje rade zasebne datoteke za banke, na matični broj firme nadodati će 

se oznaka upisana u dodatnom podatku REG za organizacijsku jedinicu koja predstavlja organizacijsku grupu. 

Ako je moguće testiranje nove datoteke u HP banci molimo Vas da napravite ovu datoteku za plaću 2013/04 i 

kontaktirate HP banku kako bi testirali datoteku. 

Preuzmite krop i base libove (dostupno od 13.05.2013.) te objekt/meni-e. 



0











Klijent: 





prihp_jtr 

Hitnost: 

Vrlo hitno 


visnja 


HITNO RIJEŠITI 

13351 



06.05.2013 11:18 

Upisao: 

Dajana Lekić 

Područje: 

LTRAN 


06.05.2013 

Kroz prihp_jtr PRIJENOS PROMETA - HPX / LAUS javlja se greška: 

Greška prilikom izvršavanja na greska_insert_protokol broj -674 isam(0). 



Poštovani, 

Nakon jučerašnjeg pojašnjenja (Mirko- Višnja telefonski ) : 

iz naziva trigger-a i procedura izbaciti ownera - informix sam to riješi/postavi kako treba . 

molimo povratne informacije / suglasnost za zatvaranje zahtjeva - Riješen 


Poštovani, 




0











Klijent: 





oobu_fk 

Hitnost: 



visnja 

13350 

Riješen 


06.05.2013 11:12 

Upisao: 

Dajana Lekić 

Područje: 

LKROP 


31.05.2013 


30.06.2013 



0









Poštovani, 

Za poslani zahtjev molim procijenu i rok isporuke. 

Datoteke obustava za HSP sindikat 

1. Potrebno je kroz oobu_fk PREGLED OBUSTAVA IZ OBRAČUNA preko F3 Szajm 

izborom zajmodavca 06 - HSP-HRVATSKI SINDIKAT POŠTE na ekranu Pregled Djelatnika po 

Zajmodavcu - iz Obračuna (oobupd_fk): 

1.Preko F2 datoteku u 'txt' formatu sa delimiterom '|' sa slijedećih podacima o svim obustavama 

zajmodavca '06' osim obustave O216-članarina: 

-JMBG radnika 

-Šifru obustave 

-Ukupni iznos obustave 

-Rata 

-Saldo 

-Ukupan broj rata za otplatu (podatak '0' u slučaju da se ne može prikazati) 

-Broj tekuće rate (podatak '0' u slučaju da se ne može prikazati) 

-Datum uplate (jednak datumu isplate obračuna plaće) 

-Datum od kada vrijedi obustava 

Primjer sloga: 

0101952391551|O274|6312.00|526.00|4208.00|0|0|15/04/2013|01/12/2012| 

2.Preko F3 datoteku u 'txt' formatu sa delimiterom '|' sa podacima o članarinama zajmodavca 06 po 

obustavi O216-članarina 

-JMBG radnika 

-Šifru obustave O216 

-Ukupni iznos članarine 

-Datum uplate (jednak datumu isplate obračuna plaće) 

-Godinu i mjesec obračuna plaće (pr. 2013-03 ako je plaća za 03.mjesec 2013) 

-Broj obračuna plaće (12) 

Primjer sloga: 

2211963391003|O216|81.01|15/04/2013|2013-03|12| 



0









Zahtjev se procjenjuje na 8 h .Što se tiče roka isporuke prioritet imaju zakonske izmjene a i ostali Vaši zahtjevi 

koji su u rješavnju ili na čekanju tako da se ovaj zahtjev neće rješavati tokom ovog mjeseca.Ukoliko želite 

redefinirati prioritete zahtjeva molimo da nas obavijestite. 



Na objektu oobu_fk PREGLED OBUSTAVA IZ OBRAČUNA -> Szajm F3 -> Izbor F1 na dobivenom ekranu 

oobupd_fk su dodane dvije tipke 

koje omogućuju ispis traženih podataka o obračunatim obustavama za izabranog zajmodavca u obliku 

tekstualne datoteke: 

1. F2 Obus-rata - za obustave u rati (podaci ukupan broj rata za otplatu i broj tekuće rate se pune nulama) 

2. F3 Obust-post - za obustave u postotku . 

Preuzeti krop lib od 05.06.2013 


U datoteci za obustave u postotku dodan je delimiter između obračuna i broja obračuna.Delimiter možete sami 

mijenjati jer se prikazuje onaj koji je zabilježen u parametru EXDEL. 

Što se tiče ukupnog duga u datoteci sa obustavama u rati iznosi su 0 jer nije upisan podatak ukupni dug u 

evidenciji obustava pa tako ni u obračunskim podacima. 

Pozdrav 



0











Klijent: 





knjkat.jas 

Hitnost: 

Vrlo hitno 


glorija 


13349 



06.05.2013 08:28 

Upisao: 

Dajana Lekić 

Područje: 

LWINFAU 


07.05.2013 


07.05.2013 

knjkat.jas KNJIŽENJE PROMETA KATALOŠKE PRODAJE 

Potrebno da se automatski knjiže i dokumenti u statusu 9, a ne samo status 3. 


Poštovani, 

Na objektu knjkat.jas KNJIŽENJE PROMETA KATALOŠKE PRODAJE sada se automatski knjiže i dokumenti u 

statusu 9. 


Instalacija: U srijedu 08.05.2013 bit će dostupan novi WIN FAUS lib. 



Poštovani, 





0











Klijent: 





Promjena naziva spisa 

Hitnost: 

Vrlo hitno 


višnja abija ivček 


13348 



03.05.2013 17:44 

Upisao: 


Područje: 

EHPUR 


06.05.2013 


06.05.2013 

Molim vas da zbog potrebe posla žurno u aplikaciji eHPUR urudžbenom broju DPO-06/3-008316/13 

promijenite naziv spisa u „PRAVILNIK O OBAVLJANJU POSLOVA ČIŠĆENJA POSLOVNIH PROSTORA“ 

te ulaznom podnesku DPO-06/3-008316/13-000001 promjenite opis podneska u „PRAVILNIK O 

OBAVLJANJU POSLOVA ČIŠĆENJA POSLOVNIH PROSTORA“. 


Poštovani, 

Molimo pristup na produkciju za programera Vjerana Livaića za rješavanje zahtjeva 13348-42767. 

Status : čekamo 


Poštovani, 

Spis je korigiran. 

Molimo suglasnost za zatvaranje zahtjeva - riješen 


Poštovani, 




0











Klijent: 



Pitanje 


Hitnost: 

Vrlo hitno 


Glorija 


Poštovani, 



02.05.2013 11:36 

Upisao: 

Božo Mišeta 

Područje: 

LCSBI 


06.05.2013 


Kod prijave na MIS ispos foldera Hrvatska pošta sada se nalaze samo NTI i Flukatacija, dok su prije kod 

prijave po defoltu bili svi izvještaji, bilanca, rdg, top n kupaca … da li su nam svi izvještaji dostupni za 

testiranje? Kada se povuče izvještaj bilanca koja stoji kod dokumenata da je bio izvođen javlja se navedena 

greška. Kada ćemo moći provesti testiranje svih raspoloživih izvještaja? 


Poštovani, 

molim Vas provjerite da li Vam se sada prikaz foldera dobro prikazuje. Trebalo bi biti ispravno. Molimo javite je li 

imate još kakvih problema u vezi toga te pošaljite i screenshote ako postoje... 

Hvala 



0











Klijent: 



Pitanje 


Hitnost: 

Vrlo hitno 


Glorija 


13347 



02.05.2013 11:08 

Upisao: 

Božo Mišeta 

Područje: 

LFINK 


02.05.2013 


Nakon automatskog knjiženja žiro-računa ostao je veći broj neproknjižen stavaka od Ministarstva 

pravosuđa. Potrebna provjeru neknjiženih stavaka. 



0









Poštovani, 

Postoje 533 uplate koje zadovoljavaju uvjete : 

dat_izv='30/04/2013' 

br_izv='108' 

oznakat='20' 

zirod ='HR1410010051563200575' 

--------------------------- 

ZAKLJUČAK : 

Z1. Preuzmite verziju fink lib od 1.5.2013. nadalje ( sad je na produkciji 17187382 Apr 29 16:01 laus-fink.lib ) 

Z2. Upišite na partnere iz ovih računa iban kao izvod_ziro.zirod ='HR1410010051563200575' 

Z3. Pošaljite kao dopunu zahtjeva HP 13259 : za slučaj pod a) omogućiti automatsko knjiženje uplate za bilo 

koji model a ne samo 00 ako je u pozbo fiskalni broj računa (završava sa -1) 

Z4. Sredite šifre koje imaju ovaj iban jer je čudno da seu neke od njih neaktivne a nositelji su salda konta. 

Z5. Ako budete sređivanje radili intervencijom kroz bazu , obavezno pustite formiranje ustroja za partnere . 

Z6. Pustite automatsko knjiženje izvoda broj 108 datum 30.4.2013. 

Status : čekamo povratne informacije/ upute za postupanje /zahtjeve od HP 

NAPOMENA : 

Nakon izvršenja gore navedenog proknjižit se trebaju većina uplata za račune koji su navedni pod c)jer postoji i 

grana automatskog knjiženja za 'krnje' laus brojeve u pozbo(nedostaje kontrolni broj za model 05 ili nedostaje 

vrsta protokola ispred godine -13-,..) 

Ukoliko želite da se omogući automatsko knjiženje i za slučaj da analitika/partner u računu nema pridružen i 

aktivan ZR/IBAN kao što je u izvodu zirod , pošaljite novi zahtjev u okviru adaptivnog održavanja . Specificirajte 

koje kontrole koje u tom slučaju treba provesti kako se ne bi događala pogrešna knjiženje uplata ( ZR/IBAN 

jednak zirod mora biti upisan na NSC za partnera u računu ili na njegovu 'krovnu' šifru ili neki drugi kriterij ) 

To se izbjegava postojećim uvjetom zirod je upisan na partnera iz računa koji se plaća. Ne preporučujemo 

ukidanje ovog uvjeta bez dodavanja nekog dovoljno pouzdanog novog uvjeta . 

Detalji analize u prilogu . 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Ivan 


13346 



30.04.2013 11:10 

Upisao: 

Božo Mišeta 

Područje: 

LTRAN 


30.04.2013 


Kod prijenos prometa preko objekta 'pri_ftr PRIJENOS PROMETA - MIPS / LAUS' potrebno je dodati 

naziv za grešku tipa 99. 

Također potrebno je omogućiti da se promet evidentira samo na aktivnu organizacijsku jedinicu. 


Napravljena je izmjena kod prijenos prometa preko objekta pri_ftr PRIJENOS PROMETA - MIPS / LAUS. 

Sada se promet evidentira samo na aktivnu organizacijsku jedinicu. 

Slog koji se treba upisati u tablicu lm_greska 

lm_greska 99 

naziv Za ured definirano viçe organizacijskih jedinica 

opis prijenos MIPS-LAUS 

pom1 

pom2 

aktivnost D 

Novi laus/tran lib je već na internetu. 


Poštovani, 





0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13345 



30.04.2013 10:54 

Upisao: 

Božo Mišeta 

Područje: 

EHPUR 


07.05.2013 


Uočili smo grešku kod izvršavanja transakcije T63 Surješavanje ponovnom evidencijom. 

Naime nakon obrade spisa u transakciji T24 Vraćanje spisa u rad, spis vraćamo u rad rješavatelju koji se 

nalazi u novoj oznaci organizacijske jedinice, 

Ali bez obzira što je u transakciji T24 izabrana nova oznaka organizacijske jedinice, obradom spisa u 

transakciji T63 spis ne povlači novo izabranu oznaku organizacijske jedinice. 

Molimo rješavanje navedene greške. 

Greška na produkciji: 

-Spis DPO -5/1-009556/12 surješen na -10144/13. Vraćen je u rad na organizacijsku jedinicu DPO-06/2. 

Ispravno urudžbeni broj DPO-06/2-10144/13. 

Na testu smo provjerili te se također događa ista pogreška. 

Primjer na testu: 

-Spis HP-2/3-026496/11 surješen na -005637/13. Vraćen je u rad na organizacijsku jedinicu HP-02/3. 

Ispravno urudžbeni broj HP-02/3-005637/13. 

-Spis HP-7/2-024871/12 surješen na HP-7/2-005638/13. Vraćen je u rad na organizacijsku jedinicu HP- 

07/2. Ispravno urudžbeni broj HP-07/2-005638/13. 



0









Poštovani, 

Zahtjev je prebačen na testni server. 

Molimo povratne informacije/ suglasnost za prebacivanje na produkciju 


Poštovani, 

Spis HP-2/3-004218/13 niste mogli naći i surješiti ponovnom evidencijom jer se radi o spisu u tekućoj godini i on 

se ne nudi na tražilici u T63 jer je takav uvjet odnosno surješavati se mogu samo spisi iz prethodnih godina. 

Maloprije smo na testu probali vratiti u rad 2 spisa (odabrali smo u jednom slučaju HP-02/2, a u drugom HP-02/3 

te se prilikom izvršavanja akcije u T63 spisima promjenio ur. broj u HP-02/2-005644/13 i HP-02/3-005645/13: 

· na spisu tako 

· na omotu spisa 

· u dnevniku rada 

Molimo Vas probajte ponovno. 



Poštovani, 





0











Klijent: 





Hitnost: 



Glorija 


13344 

U rješavanju 


30.04.2013 10:42 

Upisao: 

Božo Mišeta 

Područje: 

LFINK 


15.05.2013 


fak1_jf STANJE OBVEZA I POTRAŽIVANJA - BILANCA 

„REKAPITULACIJA PO PARTNERIMA I KONTIMA“ 

kod ispisa u excel dodati kolone 

-redni broj u izvještaju bilanci (kontni plan) na koji je konto povezan 

-naziv konta 

-ukupni saldo dugovno minus potražno – može i kod kupaca i dobavljača isto ili još bolje d-p kod kupaca, pd 

kod dobavljača 


Na objektima: 

bilancHP_ff BILANCA (USTROJ) 

arhpk_m_jf KNJIGOVODSTVENA KARTICA 

na polju Konto isključenja postavljeno je slovo N po defaultu. 

Preuzeti novi LAUS FINK liba u utorak 11.6.2013. 



0











Klijent: 





BO 

Hitnost: 

Vrlo hitno 


Goga 


Riješen 

Kod unosa rješenje bolovanja u HPu javla mi grešku: 

Samo napomena unjela sam osobu. 

Exception: Morate popuniti polje Osoba. 


29.04.2013 16:46 

Upisao: 

Mirela Šilje 

Područje: 

APLAC 


29.04.2013 


29.04.2013 

at Plac.BOBolovanjeRjesenje.DalBOBolovanjeRjesenje.set_BOBolovanjeRjesenjeOsoba(String value) 

at Plac.BOBolovanjeRjesenje.set_Radnik(Radnik value) 

at WinPlac.WinBOBolovanjeRjesenjeUnos.Spremi() 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Ivan 


13343 



29.04.2013 12:32 

Upisao: 

Božo Mišeta 

Područje: 

LFINK 


30.04.2013 


Pdv i pdv-k obrasci elektronski se šalju putem aplikacije ePorezna u poreznu upravu, sa pdv obrascima sve 

je ok, ali pdv-k obrazac koji sutra treba predati u poreznu ne mogu si poslati na mail javlja grešku (na mail 

pošalje bez podataka). 

Molim hitno omogućiti slanje ispravnog obrasca pdv-k na mail. 

Objekt je na ME2364 PDV-POREZ NA DOD.VRIJ. (01.03.-31.12.2012.) - ob_pdk25_jf 

PDV-K OBRAZAC. 


Ispravljena je greška kod generiranja XML datoteke PDV-K obrazca. 

Preuzeti LAUS FINK lib. Novi lib se već nalazi na internetu. 


Poštovani, 





0











Klijent: 





Hitnost: 

Vrlo hitno 


Ivan 


13342 

Riješen 


29.04.2013 10:04 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


30.04.2013 


29.04.2013 

Na objektu rucnal.jas potrebno je na pregledu proširiti polje usluga na 13 znakova, te također kod unosa 

naloga potrebno je omogućiti unos/izmjenu i brisanje stavaka čija usluga ima više od 10 znakova. Trenutno 

se može unositi usluga preko 10 znakova ali kad odabira radnog naloga se pregleda režu se znamenke. 


Na objektu rucnal.jas polje usluga je prošireno da se može upisati 13 znakova. 

U utorak 20.04.2013 bit će dostupan novi WIN FAUS lib. 


Poštovani, 

Molimo suglasnost za zatvaranje zahtjeva - Riješen. 

Nakon zadnje obrade nismo dobili primjedbe .: 

Na objektu rucnal.jas polje usluga je prošireno da se može upisati 13 znakova. 




0











Klijent: 





Hitnost: 

Nije hitno 


Glorija 


13341 



25.04.2013 11:38 

Upisao: 

Božo Mišeta 

Područje: 

LFINK 


30.06.2013 


Kod ispisa listi u financijskom dijelu Lausa kod opcije Excel-mail liste se u većini slučajeva formiraju na 

način da je kod numeričkih polja ponašanje kao u excelu (zarez je razdjelnik decimalnih mjesta, a točka je 

razdjelnik tisućica). Na primjeru ove liste je slučaj obratan tj. jednako je kao u Lausu. Potrebno je sve liste 

svesti na isti format (excel). 



0









Poštovani, 

Na meniju ME213 LISTE KNJIGOVODSTVENIH KARTICA 

samo se liste sa kartica_ff LISTA KOMPLETNE KARTICE 

mogu dobiti opcijom Excel-mail kod ispisa . 

Status : u rješavanju tj. ispravlčja se decimalni znak u stupcu za iznos 

Obzirom na veliki broj zahtjeva koje još treba riješiti , u dogledno vrijeme ne možemo ispitivati koje sve od 

velikog broja listi u LFINK treba korigirati na isti način . Smatramo neracionalnim trošenjem vremena iako je 

zahtjev potpuno opravdan . 

Predlažemo radi racionalnijeg trošenja vremena i bržeg rješavanja : 

Uputite korisnicima ovih listi iz LFINK aple da kad primjete da lista koju su ispisivali opcijom ispisa Excel-mail 

ima decimalni znak točku a ne zarez istu proslijede na rješavanje . 


Poštovani, 

Na excel listi sa objekta kartica_ff postavljen je format iznosa sa decimalnim zarezom. 

Prije ispravka , foramt iznosa je bio sa decimalnom točkom - nije excel format za iznos 



Molimo povratne informacije/ suglasnost za zatvaranje zahtjev a- Riješen . 

Molimo pošaljite novi zahtjev ako se treba ista korekcija napraviti na nekoj drugoj listi 



0











Klijent: 





Hitnost: 



Glorija 


13340 



25.04.2013 10:02 

Upisao: 

Božo Mišeta 

Područje: 

LFINK 


07.05.2013 


Na objektu aknj_ul_jf AUTOMATSKO KNJIŽENJE PDV-A omogućiti automatsko knjiženje za : 

1. Protokol B, vrsta dokumenta IRV 

2.Protokol E , vrsta dokumenta UPI 



0









Poštovani, 

Na objektu aknj_ul_jf AUTOMATSKO KNJIŽENJE PDV-A automatsko knjiženje bez programskih izmjena je 

moguće za oba navedena slučaja . 

Potrebno je zadati/izmjeniti veze konto-dokument (upute za knjiženje) za vdok PDV kako je dolje navedeno . 

Molimo povratne informacije/ suglasnost za zatvaranje zahtjeva - riješen 

1. Protokol B, vrsta dokumenta IRV : 

a) u veza konto-dokument promijeniti uputu tako da protokol bude * a ne samo 0 za : 

240200 PDV ***** 0 - - D - - 

240201 PDV ***** 0 N - D - - 

b) Kod automatskog knjiženja PDV-a zadati : 

Vrsta protokola B 

Vrsta dokumenta IRV 

Knjižiti na: 

Konto1 240000 

Stopa1 PDV-a 25.00 

Vrsta dokumenta PDV PRIJAVA PDV-A 

Duguje/Potrazuje D 

2. Protokol E , vrsta dokumenta UPI : 

a) zadati uputu za vdok PDV po uzoru na vezu za konto 140000 i vdok PDV za sva potrebna konta 140* . 

b) Kod automatskog knjiženja PDV-a zadati : 

Vrsta protokola E 

Vrsta dokumenta UPI 

Knjižiti na: 

Konto1 140200 

Stopa1 PDV-a 25.00 

Vrsta dokumenta PDV PRIJAVA PDV-A 

Duguje/Potrazuje P 


Poštovani, 

zahtjev zatvaramo uz vašu suglasnost - Riješen 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Ivan 


13339 



25.04.2013 09:58 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


26.04.2013 


Potreno je kod knjiženja sa objekta knjdig.jas omogućiti i knjiženja odobrenja za račune (vdok='ODO') 

digitalne televizije. Stavke odobranja nalaze se u tablici 'lm_kat_stav' . 

Takođe potrebno je ugraditi kontrolu da se sa tog objekta mogu knjižiti samo dokumenti čiji se broj 

protokola nalazi u tablici bss_vezar.protokol (samo računi i odobrenja koji su stigli u prijenosu iz BSSa). 


Napravljene su izmjene na objektu knjiženja knjdig.jas. 

Omogućeno je knjiženje odobrenja za račune (vdok='ODO') digitalne televizije. 

Od sada se sa ovog objekta knjiže samo dokumenti čiji se broj protokola nalazi u tablici bss_vezar.protokol 

(samo računi i odobrenja koji su stigli u prijenosu iz BSSa). 



Poštovani, 





0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


Poštovani! 

13338 



24.04.2013 10:24 

Upisao: 

Božo Mišeta 

Područje: 

LROBD 


26.04.2013 


Molim da nam pošaljete procjenu broja sati za izradu traženih aplikacijskih dorada i rok kada bi se mogao 

realizirati zahtjev kojeg šaljem u prilogu. 



0









U prilogu šaljemo procijenu sati za odradu zahtjeva 13338! 

S štovanjem 


Poštovani, 

Tražena procjena za rješavanje zahtjeva 'Otuđenja u PU' . 

Procjena je poslana 24.4.2013. 

Zahtjev smo zatvorirli istog dana - Riješen te molimo da učinite isto. 

Trenutni status : Čeka se stav HP-a 

Molimo potvrdite procjenu i realizaciju zahtjeva ili pošaljite suglasnost za zatvaranje zahtjeva - Riješen 

NAPOMENA : 

Zahtjev je naveden na popisu neriješenih zahtjeva koji je poslan kao prilog zapisniku sa sastanka IT-LAUS 

10.06.2013.g. te zato šaljemo ovu obradu . 

Nismo dobili suglasnost za procjenu niti za početak realizacije zahtjeva . 

Molimo pošaljite novi zahtjev ukoliko se odlučite za realizaciju uz napomenu :veza zahtjev 13338 


Poštovani, 


S štovanjem 


Katja 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13337 



24.04.2013 09:36 

Upisao: 

Božo Mišeta 

Područje: 

WINTRAN 


26.04.2013 


Primijetili smo da nam podaci iz usporedne liste za dva razdoblja nisu točni. 

U privitku se nalaze (po sheetovima) podaci iz: 

•Winlausa hp3 liste = šifra artikla 322082 = 820 komada prodano 

•Winlausa usporedna lista = šifra artikla 322082 = 919 komada prodano 

Stvarna prodaja 820 kom. 

Razdoblje: 01.03.-31.03.2013 

Molim Vas da provjerite zašto se razlikuju podaci o prodaji za isto razdoblje koji se nalaze u lausovim 

listama (hp3 i usporedna lista), 



0









Poštovani, 

Razlika je očekivana ako se artikal prodaje i na depou a ne samo u PU . 

Objašnjenje : 

upd lista uključuje i depo-e (SDL podatak) ) a hp3 lista ne. 

Na depou 35365 je prodano 99 komada artikla 322082 u periodu 2013-03 . 

Zbrojeno sa 820 prodanih u PU-ima dobije se 919 koliko je i prikazano na listi upd 

Prodano za artikal i period (hp1d.datum) za depo-e se dobije iz hp1d kao suma : 

koli_rok+koli_rnk-koli_rkp-koli_rpk (ROK, RNK otpremnice kupcu ,RKP,RPK - povrati od kupca ) 



Ne treba ništa 


Poštovani, 




0











Klijent: 





Hitnost: 



Glorija 


13336 



24.04.2013 07:28 

Upisao: 

Božo Mišeta 

Područje: 

LFINK 


06.05.2013 


03.05.2013 

Za potrebe Internet trgovine je otvorena generička šifra Internet trgovina-ino kupci 645904 (kao što je 

otvorene šifra za katalošku prodaju 626551). Kako će s epomoću te šifre izrađivati računi vezani za prodaju 

robe na stranim tržištima putem Internet trgovina potrebno je istu prilagoditi nadzornoj knjizi prometa robaizvoz 

(u svrhu dobivanja izvoznog zaključka). 

U nadzornim knjigama moraju biti ispisani sljedeći podaci o partneru za svaku narudžbu: 

•Broj računa – automatski se preslika U NK po izradi računa u Laus-u 

•Vrsta dokumenta 

•Originalni broj računa 

•Datum računa 

•Tvrta – naziv kupca 

-adresa kupca (ulica,grad, država) 

•Ugovorena vrijednost posla (iznos fakture) 

Potrebno je kod nadzorne u prikazu i ispisu ako se radi o generiračkoj šifri partnera da se onda padaci 

čitaju iz dodatne tablice o partneru (lm_fil_part). 

Podaci se trebaju i dalje automatski preslikavati u NK sa svim potrebnim podacima, jer bez izvoznog 

zaključka se roba ne može poslati kupcu. 



0











0







Poštovani, 


svi podaci koji moraju biti ispisani u NK se uredno bez dorada ispisuju i u slučaju da je u računu analitika neka 

od generičkih šifri u POSPA 

osim naziv i sjedište kupca jer se za sve slučajeve isto čita iz šifarnika partnera . 

Za sredit naziv i sjedište kupca u nadzornim knjigama za račune internet prodaje za ino-kupce treba : 

--- upisati u parametar POSPA : kljuc =3, podatak=645904 

--doraditi NK izvoza roba (vnk=Z) : validacije i ispis u dijelu čitanja naziv i sjedište partnera 

Ako je analitika upisana u POSPA za ključ 3 onda ne treba čitati generalije kupca iz part tablice nego iz 

lm_fil_part 

( računi internet trgovine za ino-kupce ) naziv ,adresa,drzava za protokol (račun) 

a) Potrebne dorade na nkrin_jf NADZORNA KNJIGA PROMETA ROBA - IZVOZ (nkrn_ff) 

polje Tvrtka validacija : 

b) tipka F8 Detalj otvara nkudr_ff . Potrebne dorade kod čitanja : 

Naziv tvrtke 

Sjedište tvrtke 

-- tablica je part ili lm_fil_part : 

c) tipka F6 ispis otvara nki_ff. Potrebne dorade kod čitanja : 

naziva za Poslovni partner 

-- tablica je part ili lm_fil_part : 

d) tipka F6 otvara nki_ff pa onda F6 Ispis . Potrebne dorade liste nkudr_rf kod čitanja : 

Naziv tvrtke nerezidenta s kojim je posao sklopljen 

Zemlja sjedišta nerezidenta s kojim je posao sklopljen 

-- tablica r je part ili lm_fil_part 

Status: u rješavanju 

----------------------------------------------------------------------------------- 

Kroz ovaj zahtjev ne radi se ništa na rucfil vezano za račune internet trgovine za ino-kupce 

Razlog : uopće nije definirano na koji način će se raditi računi internet trgovine za ino kupce, nego je samo 

rečeno da će se raditi na rucfil.jas. 

Potrebno je poslati zahtjev ( WinFaus područje ) u kojem treba specificirati : 

Omogućiti na rucfil.jas izradu računa za ino-kupce internet trgovine . 

Potrebno je omogućiti upis podataka o kupcu u lm_fil_part tablicu ako je upisana analitika P 645904 kao što je 

to omogućeno na ruckat.jas za vrstu računa 1 i analitiku P 626551 . 

Račune je potrebno upisivati u nadzornu knjigu prometa robaizvoz (vnk=Z) 

Naznačiti treba li ili ne za ove račune raditi POST DUE i Weight klauzule kao što treba za račune filatelije . 

Naznačiti koje usluge/artikle treba omogućiti /zabraniti u računima za ino-kupce kataloške (artikli tipa U usluge ili 

neke druge usluge ako uopće ima usluga) 

Naznačiti koje cijene/cjenik koristi internet trgovina tj. jesu li one proizvoljne ili se čitaju cijene iz kalkulacije za 

artikal i valutu u kojoj se izadaje račun . 

Napomena : 

ako će se računi za ino-kupce internet trgovine izrađivati u protokolu Px sa vrstom dokumenta Vx za koje ne 

postoji upisana uputa u 

nku_up_jf UPUTE ZA NADZORNE KNJIGE istu je potrebno upisati . 

Sa zadanom uputom upis je moguć na prot_fm EVIDENTIRANJE DOKUMENATA 

Takvi računi ne mogu automatski biti upisani u NK niti nakon upisa upute jer nije podržano na rucfil.jas, osim 

ako se rade u protokolu i sa vdok kao filatelija 

Nema upisa u NK ako nije određeno ( poslali ste Z) i podržano programom u koju vrstu NK se račun upisuje : 

UVOZ : U=Usluga, R=Roba, M=MeĐ.pošt.up 

IZVOZ : I=Usluga, Z=Roba, P=MeĐ.pošt.up 



0









Poštovani, 

Na objektu : nkrin_jf NADZORNA KNJIGA PROMETA ROBA - IZVOZ ( vnk= Z) 

Dodano je čitanje generlija partnera ( naziv, sjedište) iz tablice lm_fil_part za šifru partnera (645904) koja je 

upisana u parametar POSPA za kljuc 3 

za konkretan broj računa . 

Uzeto je u obzir napravljeno po KZ 42631, Originalni broj zahtjeva: HP 13335 :Omogućen je i upis grada za 

partnera. 

Polje grad nije obvezno za unos. Upisani grad će se prikazivati i na ispisu (za slučaj kada za partnera nije 

definirana pošta). 

NAPOMENA : 

tipka F6 ispis otvara nki_ff. Kod čitanja naziva za slučaj da je kao uvjet zadan Poslovni partner= 645904 naziv 

se čita iz tablice part jer nije poznato na koji konkretan račun se naziv partnera odnosi. U ispisu / listi nkudr_rf 

kod čitanja : 

Naziv tvrtke nerezidenta s kojim je posao sklopljen 

Zemlja sjedišta nerezidenta s kojim je posao sklopljen 

za svaki račun kojem je analitika P 645904 pročitaju se podaci lm_fil_part upisani upravo za taj račun. 



Upisati u parametar POSPA :klju=3 , podatak=645904 

Molimo povratne informacije/ suglasnost za zatvaranje zahtjeva- riješen 


Poštovani, 

Na ekranu nkrn_ff prilikom čitanja grada i države tvrtke za partnera koji se nalazi u parametru POSPA sa ključem 

3 postavljeno je sljedeće: 

- čita se šifra pošte i drzava iz lm_fli_part za upisani broj dokumenta. 

- ako je šifra pošta upisana onda se ispisuje naziv pošte i naziv države odvojene zarezom. 

- ako šifra pošte nije upisana onda se ispisuje podatak iz polja grad i naziv države odvojeni zarezom 

- ako ni podatak grad nije upisan onda će se ispisati podatak adresa i naziv države odvojeni zarezom 

Na tipku F8 Detalj otvara se ekran nkudr_ff koji je prošien sa još jednim retkom tako da se u polju Sjedište tvrtke 

u prvom retku ispisuje adresa i naziv pošte ( ili grada ako pošta nije upisana) te u drugom retku naziv države. 


Obavijestiti korisnika o preuzimanju novog LAUS FINK liba u srijedu 15.5.2013. 



Poštovani, 





0











Klijent: 





Hitnost: 



Glorija 


13335 



24.04.2013 07:23 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


06.05.2013 


30.04.2013 

Kod pregleda prikazuju se samo podaci koji imaju upisanu poštu. Potrebno prikazivati sve (posta sa outer). 

Dodati polje Grad na unosu i pregledu (nije obavezan podatak) i onda ga ispisivati na ispisu ako je upisan 

(kod slučaja generičke šifre partnera). 


Kod evidentiranja dodatnih podataka za partnere kod pregleda se sada prikazuju i partneri koji nemaju 

evidentiranu poštu. 

Omogućen je i upis grada za partnera. Polje grad nije obvezno za unos. Upisani grad će se prikazivati i na ispisu 

(za slučaj kada za partnera nije definirana pošta). 


Izvesti sql: 

ALTER TABLE lm_fil_part ADD ( 

grad nchar(40) BEFORE uradio); 


Poštovani, 





0











Klijent: 





Hitnost: 

Vrlo hitno 


Višnja 


13334 



23.04.2013 13:51 

Upisao: 

Božo Mišeta 

Područje: 

LKROP 


24.04.2013 


Kroz virzap_jk PRIPREMA VIRMANA ZA PLATNI PROMET javlja se greška -217 


Ispravljen je program formiranja virmana na objektu virzap_jk koji je javljao grešku 217. 

Preuzmite: krop lib (već je na internetu). 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Ivan 


13333 

U rješavanju 


23.04.2013 13:15 

Upisao: 

Božo Mišeta 

Područje: 

LROBD 


26.04.2013 


Potrebno je u LAUS bazi definirati tablicu sa opisom grešaka koje nastaju kod prijenosa podataka preko 

objekta 'amb_jd PRIJENOS PODATAKA IZ MIPS-A'. 

Šifra greške se zapisuju u tablicu hp1_greska sa brojem sloga iz prijenosa te šifrom greška ali nemamo 

nigdje poveznicu koje su to greške već samo njihove šifre. 


U tablici hp1_greska odnosno koja se ažurira prilikom prijenosa podataka /dokumenta iz mipsa u laus amb_jd 

se mogu ispisati sljedeće greške odnosno njihova značenja : 

0 - Krivi dokument 

1 - nije zadana pošta 

2 - nije zadan artikal 

3 - nisu ispravne oznake ulaza/izlaza 

4 - neispravne vrste analitike 

5 - neispravne orgj 

6 - neispravni part 

7 - neispravna oanal 

8 - neispravan radnik 

9 - neispravno bez analitike 

10 - neispravni tarifni brojevi 

11 - nema zadani vdok 

12 - popust nije upisan 

13 - nije zadan cjenik 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13332 



22.04.2013 14:22 

Upisao: 

Božo Mišeta 

Područje: 

EHPUR 


26.04.2013 


Po dogovoru sa sastanka održanog 16.04.2013 u Jurišićevoj 13, u prilogu vam dostavljam tablicu 

Posebnog popisa arhivskog i registraturnog gradiva HP-a. 

Kako ste nam odgovorili da nije moguće kroz aplikaciju unijeti dostavljene podatke, molim Vas da ih vi 

unesete kroz bazu. 

Tražili ste i odgovor na slijedeći upit: 

„Molimo Vas informaciju jeste li dosadašnje spise povezivali sa starim/trenutnim podacima iz ovog polja? 

Naime, ako jeste, potrebno je onda pronaći sve te spise i ˝namapirati˝ na nove podatke koje ste dostavili. 

Ako je tako, onda nam treba poveznica sa starih na nove ili eventualno označiti stare zapise kao neaktivne. 

– veza zahtjev br. Obrada korisnickog zahtjeva-41719/6-Originalni broj: [13183], Sent: Friday, April 19, 

2013 12:59 PM)“ 

HP odgovor: Dosadašnje spise nismo povezali sa trenutnim podacima tako da ne treba poveznica. Ako 

postoje nekakvi podaci to je bilo radi testiranja tako da se mogu pregaziti sa novim popisom ili izbrisati. To 

polje će se početi koristiti donošenjem novog pravilnika tj. reorganizacijom kod arhiviranja. 

Molim Vas procjenu za izradu ovog zahtjeva. 



0









Poštovani, 

Procjena za ovaj zahtjev je 3,5 sati (u ovu procjenu uračunato je i do sada potrošeno vrijeme na korespodenciju 

odnosno analizu). 

Lp, 


Poštovani, 

Vaš zahtjev je riješen i prebačen na testni server. 

Molimo povratne informacije/suglasnost za prebacivanje na produkciju 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Glorija 


13325 



19.04.2013 09:58 

Upisao: 

Božo Mišeta 

Područje: 

LFINK 


18.04.2013 


Potrebno napraviti prilagodbu na objektu da se umjesto Pozicije u ispisu doda Datum knjiženja. Kao filter 

potrebno dodati Datum dospijeća, te Datum knjiženja do (opcionalno). Zahtjev prioritet 1. uz onaj 13308. 

Polje Opis nije u ispravnom formatu (excel-mail). 



0









Poštovani, 

Status : Čekamo stav HP u vezi predloženog. 

Vezano za : 

Kao filter potrebno dodati Datum knjiženja do (opcionalno). 

Predlažemo : 

Ukinuti uvjete : 

Godina i Mjesec od i do (sve troje se obavezno zadaje sad) 

Omogućiti zadavanje : 

Datum knjiženja od i do ( mora se barem jedan zadati) 

Ponaša se kao što ste opisali za datum dospijeća : 

1) od 01.01.2012 do 01.05.2013 zadaju se oba datuma, lista samo stavke koje imaju datum dospijeća u 

intervalu zadanom 

2) od______do_______ dospijeće ostavlja se prazno, lista se kartica kao prije dok nije bilo datuma dospijeća, 

3) od_______do 01.03.2013. listaju se sve stavke koje imaju dospijeće do 01.03.2013 

4) od 01/01/2013 do______ listaju se sve stavke koje imaju dospijeće od 01.01.2013 do dalje 

osim što nema opcije pod 2) kako bi se izbjeglo nesvjesno listanje svih stavaka 


Na objektu kartica_ff dodana su filter polja za Datum dospijeća od od. Na ispisu umjesto stupaca pozicija dodano 

je polje Datum knjiženja. 

Preuzeti novi LAUS FINK liba u četvrtak 25.4.2013. 


Poštovani, 





0











Klijent: 





Hitnost: 

Vrlo hitno 


Glorija 


13330 



18.04.2013 10:22 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


24.04.2013 


Potrebno je izmijeniti nivo knjiženja kod PDV-a, da knjiži na nivo 00000 kao i ostalu gotovinu. 

Knjkat.jas KNJIŽENJE PROMETA KATALOŠKE PRODAJE 


Na objektu knjkat.jas KNJIŽENJE PROMETA KATALOŠKE PRODAJE kod knjiženja gotovine, izmijenjen je nivo 

knjiženja PDV-a na nivo 00000. 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Ivan 


13329 

Riješen 


18.04.2013 08:23 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


30.04.2013 

Na objektu ugrab_fas Stavke ugovora sa posebno ug.cijenama i rabatima 

dodati u poljima Uvjeta pregleda: 

-Upis laus broja ugovora sa i bez crtica između orgj, godine i broja 

-Dodati polje Kupac te omogućiti pretraživanje po šifri kupca 

-Uz laus broj ugovora ispisati šifru i naziv kupca na kojem je evidentiran ugovor 

-Uz upisanu šifru usluge napisati naziv 



Na objektu ugrab_fas Stavke ugovora sa posebno ug.cijenama i rabatima napravljene su tražene izmjene. 

U poljima Uvjeta pregleda omogućen je upis broja ugovora sa crticama i nadodano je polje Kupac. 

Na pregledu je nadodan prikaz šifre i naziva kupca te naziva usluge. 

U petak 03.05.2013 bit će dostupan novi WIN FAUS lib. 


Poštovani, 


Nismo dobili primjedbe nakon zadnje obrade : 

Na objektu ugrab_fas Stavke ugovora sa posebno ug.cijenama i rabatima napravljene su tražene izmjene. 

U poljima Uvjeta pregleda omogućen je upis broja ugovora sa crticama i nadodano je polje Kupac. 

Na pregledu je nadodan prikaz šifre i naziva kupca te naziva usluge. 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Ivan 


13328 

Riješen 


18.04.2013 08:20 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


30.04.2013 


20.06.2013 

Na objektima: 

rucfak.jas - Pregled i ručni unos faktura 

fakis.jas - Ispis računa 

Laus Broj računa i fisklani broj računa R1 treba ispisati podebljano, na zaslonu, ispis na pisaču. 

Laus Broj računa nalazi se lijevo od adrese, ispod datuma DVO-a. 

Podebljani ispis broja računa treba primijeniti za vrste faktura FAP, FAH, FAO, FAS, FAB, ODO, RAV, 

OBN. 


Na svim ispisima fakrura se sada prikazuje podebljano LAUS broj računa i fiskalni broj računa. 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13327 



17.04.2013 14:47 

Upisao: 

Božo Mišeta 

Područje: 

EHPUR 


19.04.2013 


Kod zbirnog pretraživanja spisa, za zadani tip zapisa:”Spis” , ne možemo dobiti ispis u excel format . Javlja 

nam se poruka u prilogu: “Server error- request timed out”. 

Molimo da nam omogućite ispis liste po zadanom uvjetu ili da nam pošaljete 

popis neriješenih spisa razvrstanih po rješavateljima. 

Pošto nismo u mogućnosti sami izvesti excel tablicu u aplikaciji eHPUR zbog previše podataka (okvirno 

130.000),molimo vas da nam dostavite popis neriješenih spisa. (može i u excel tablici) 

Pod neriješene spise pripadaju svi spisi koji nisu arhivirani tj. svi spisi u statusu: 

-Signiran 

-Proslijeđen na potpis 

-Stavljen u rok 

-Zaduzen 

-Zadužen (Surješen) 

-Zadužen(proslijeđen) 

-Zahtjev za arhiviranjem spisa 

-Zahtjev za prosljeđivanje spisa 

-Zahtjev za prosljeđivanje spisa na potpis 

-Zahtjev za stavljanje spisa u rok 

-Zahtjev za vraćanje spisa u rad 



0









Poštovani, 

Molim Vas pristup za kolegu Vjerana Livaića, a vezano za zahtjev 13327. 

Zahvaljujem. 


Poštovani, 

U privitku Vam dostavljamo tablicu u xls. formatu prema Vašem zahtjevu. 

Tablica sadrži podatke o nerješenim spisima zaključno s datumom 18.04.2013. i sastoji se od 2 radna lista, prvi 

sortira spise po abecednom redu ur. brojeva, a drugi po abecednom redu rješevatelja. 



Poštovani, 

problem s eksportom je tehničke prirode jer .xls format podržava maksimalno 65536 zapisa (redaka) u jednom 

radnom listu. 

Predlažemo da kriterij pretrage prilagodite tako da rezultat bude oko 60000 zapisa i kao takve ih eksportirate u 

više etapa. 

Predlažemo zatvaranje ovog zahtjeva. 

Lp, 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13326 



17.04.2013 14:12 

Upisao: 

Božo Mišeta 

Područje: 

EHPUR 


18.04.2013 


Uočen je sigurnosni propust u aplikaciji eHPUR. 

Naime, moguće se prijaviti sa korisničkim ulazom „1“ lozinka „1“ koordinator aplikacije identično kao 

koordinator na testnoj verziji aplikacije. 

Molimo da se, kod preuzimanja podataka, sa testne na produkcijsku bazu ne preuzimaju i korisnički ulazi 

sa testne baze. 


Poštovani, 

Navedenu primjedbu uvažit ćemo kod slijedećeg preuzimanja podataka sa testne na produkcijsku bazu . 

Molimo deaktivirajte nepotrebne ulaze . 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13324 



16.04.2013 15:25 

Upisao: 

Božo Mišeta 

Područje: 

LROBD 


19.04.2013 


Na ME1234, objektu PREGLED SVIH DOKUMENATA (prd_ul_jd) dodati filter polje “URADIO” i omogućiti 

unos korisničke šifre koja je vezana uz dokumente korisnika, kao i Broj dok. OD _____ DO _____. 


Na pregledu dokumenata prd_ul_jd Pregled dokumenata dodana su filter polja Uradio i Broj dokumenta OD i 

DO. 



Poštovani, 




0











Klijent: 





Hitnost: 



Višnja 


13319 



16.04.2013 15:21 

Upisao: 

Božo Mišeta 

Područje: 

LKROP 


16.05.2013 


Potrebno je kroz dis_ban_fk DISKETE ZA BANKE na ekranu dis_ban_fk dodati novi meni ISTARSKA 

KREDITNA BANKA D.D. i omogućiti izradu datoteke za plaću za: 

4063 ISTARSKA KREDITNA BANKA D.D. 

prema uputama u prilogu. 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13323 



16.04.2013 14:39 

Upisao: 

Božo Mišeta 

Područje: 

LROBD 


19.04.2013 


Prilikom knjiženja generiranog dokumenta iz PU na ME1225 - RPM ul_jd POVRATNICA IZ 

MALOPRODAJE potrebno je da prilikom knjiženja na skladišne i knjigovodstvene kartice aplikacija knjiži 

sa trenutnim datumom odnosno datumom kada su artikli zaprimljeni u Depou. 



0









Poštovani, 

na dokumentu postoji datum dokumenta, koji pokazuje kada je taj dokumenat nastao. 

To je ujedno i datum koji se prikazuje na skladišnoj kartici. 

Na robnoj kartici osim tog datuma prikazuje se i datum knjiženja (to je datum kada je dokumenat prebačen u 

status 7 ili 9) 

Molimo vas da nam specificirate što treba napraviti, jer iz zahtjeva koji ste dostavili to nemožemo zaključiti. 

S štovanjem 


Poštovani, 

"Npr. PU knjiži dokument na datum 05.XX, depo preuzima i knjiži na 12.XX, i taj 12.XX je potrebno da se knjiži 

na knjigovodstvenu karticu." 

Pa sada to upravo tako i radi. Na knjigovodstvenoj kartici je zabilježen i datum dokumenta i datum knjiženja. 

To i jest nejasno, što zapravo korisnik hoće? 

S štovanjem 


Poštovani, 

Zahtjev zatvaramo uz vašu suglasnost - Neće se rješavati 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Glorija 


13322 

Riješen 


16.04.2013 13:55 

Upisao: 

Božo Mišeta 

Područje: 

LCSBI 


25.04.2013 


Molim da se u MIS-u ispravi greška u RDGu na aop poziciji 125: 5. Ostali troškovi. Potrebno je ispraviti 

upute kao u Argosyiu. 

Podaci za 2012. godinu u Argosyiu odgovaraju onima iz Laus aplikacije (ispravni su), WebI i Cryistal ne 

štimaju za iznos naznačen na dokumentu u privitku. 



0









Poštovani, 

molimo Vas možete li poslati iz 2012. godine razbijeno po mjesecima stavku ili stavke konta koje se razlikuju na 

toj poziciji kako bi mogli ustanoviti gdje je pogreška? 


Poštovani, 

ovim putem Vas obavještavamo da smo ustanovili da na bazi hp4lcs (poznata kao "međubaza" za HP MIS) je 

uklonjen triger na tablici [tFinkIzvjestajMatricaUputa], te također da su izbrisani SVI audit podaci za izmjene na 

uputama za konsolidirane izvještaje u tablici [tFinkIzvjestajMatricaUputaAudit] tako da je trenutno zadnji zapis od 

4. mjeseca prošle godine. Obzirom da smo ove godine bili koristili ovu audit tablicu u rješavanju nekih zahtjeva, 

znamo da je triger radio i podaci da su bili zapisivani cca barem do kraja prošle godine. 

Obavještavamo Vas da ćemo ponovo postaviti taj trigger. 

Ukoliko Vam je poznato da je uklanjan odnosno razlog zašto ga je netko uklonio, molimo Vas javite nam kako bi 

mogli uskladiti potrebe. 


Poštovani, 

ponovnim učitavanjem podataka za arhivske mjesece rujan i listopad 2012 usklađeni su podaci produkcijskog 

sustava i HP MIS-a. 


Poštovani, 

Zahtjev je riješen - obrada o rješenju poslana 22.4.2013 u 9:20 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Ivan 


13321 



16.04.2013 13:47 

Upisao: 

Božo Mišeta 

Područje: 

LFINK 


17.04.2013 


02.05.2013 

U prilogu šaljem primjer grešaka kod automatskog zatvaranja uplata po dospijeću. 



0









Poštovani, 

Prema dogovru i zapisniku sa sastanka 16.4.2013. : 

LAUS tokom 17.4.2013. na produkciji u tablicu bss_priprema treba spremiti storno i nove stavke za korisnike 

čija je kartica krivo poslana u BSS. 

napravljeno je : 

-- stornirano 147 pogrešnih stavaka (bss_priprema.status=X) 

-- veza slog_id stornirani i slog_id njegovog storna u /home/admlaus/bss_st.txt - 147 

Stupci : slog_old,slog_new,nalogk,red, brugo,idpart,iznpot,storno 

-- upisan ispravak za 139 storniranih (bss_priprema.status=Y) : brugo=opis(1,7) će se sad dobro uparivati 

-- veza slog_id stornirani i slog_id njegovog ispravka u /home/admlaus/bss_opis.txt - 139 

select slog_old,slog_new,nalogk,jed,brugo,jdpart,iznpot, novi_brugo 

-- Ne može se ni po čemu odrediti koji je brugo jer LB='', opis != brugo, a kupac ima 2 ugovora - ovo će sad biti 

nova greška 

-- sporni u /home/admlaus/bss_ne.txt - 16 redova za svaki po 2 - 8 

Molimo dostavite točan brugo za svaki tj. pobrišite red koji nije dobar pa vratite da se i zanjih upiše ispravak : 

slog_id nalogk red idpart kanalitika bss_ugo 

210762 13E50038 1626 1004270 T007494 1008189 

210762 13E50038 1626 1004270 T007494 1008317 

225888 13R50013 1 1007713 T001971 1002318 

225888 13R50013 1 1007713 T001971 1002328 

225889 13R50013 2 1007713 T001971 1002318 

225889 13R50013 2 1007713 T001971 1002328 

225890 13R50013 3 1007713 T001971 1002318 

225890 13R50013 3 1007713 T001971 1002328 

225901 13R50015 2 1007129 T001971 1002318 

225901 13R50015 2 1007129 T001971 1002328 

225902 13R50015 3 1007129 T001971 1002318 

225902 13R50015 3 1007129 T001971 1002328 

225903 13R50015 4 1007129 T001971 1002318 

225903 13R50015 4 1007129 T001971 1002328 

225921 13R50019 1 1004501 T001971 1002318 

225921 13R50019 1 1004501 T001971 1002328 



0









Poštovani, 

Upisano je 8 slogova ispravka za stavke za koje ste poslali točan brugo . 

bss_priprema.status : D-kako je ranije poslano, X-storno poslanog, Z-ispravak . 

( /home/admlaus/z13321_ivan*.sql ) te Veza slog_id starih , storna i ispravka u bss_ivan.txt ) 

Napomena : u arhiv (knjiženje) ništa ne treba raditi, mijenjati , doknjižavati 

slog_id nalogk red brugo idpart iznpot s 

210762 13E50038 1626 1004270 67716 99.00 D 

285668 13E50038 1626 1004270 67716 -99.00 X 

285911 13E50038 1626 1008189 67716 99.00 Z 

225888 13R50013 1 1007713 52014 -19.00 D 

285708 13R50013 1 1007713 52014 19.00 X 

285912 13R50013 1 1002318 52014 -19.00 Z 

225889 13R50013 2 1007713 52014 18.99 D 

285709 13R50013 2 1007713 52014 -18.99 X 

285913 13R50013 2 1002318 52014 18.99 Z 

225890 13R50013 3 1007713 52014 0.01 D 

285710 13R50013 3 1007713 52014 -0.01 X 

285914 13R50013 3 1002318 52014 0.01 Z 

225901 13R50015 2 1007129 52014 -0.01 D 

285711 13R50015 2 1007129 52014 0.01 X 

285915 13R50015 2 1002318 52014 -0.01 Z 

225902 13R50015 3 1007129 52014 -0.01 D 

285712 13R50015 3 1007129 52014 0.01 X 

285916 13R50015 3 1002318 52014 -0.01 Z 

225903 13R50015 4 1007129 52014 -0.01 D 

285713 13R50015 4 1007129 52014 0.01 X 

285917 13R50015 4 1002318 52014 -0.01 Z 

225921 13R50019 1 1004501 52014 -0.01 D 

285714 13R50019 1 1004501 52014 0.01 X 

285918 13R50019 1 1002318 52014 -0.01 Z 



0









Poštovani, 

Napravljena je provjra podataka u bss_priprema : 

1) Ovi podaci su ipravni ali nemaju brugo u opisu knjiženja : 

Za 8 stavki koje imaju upisan racun(arhivk.protokol=bss_priprema.brdok= bss_vezar.protokol) preko bss_vezar 

određen brugo i idpart 

slog_id racun analitika idpart bss_kupac vbrugo 

305250 4630001302362 T000490 46074 46074 1001063 

305243 4630001309704 T002119 52391 52391 1002460 

305276 4630001309754 T003304 55946 55946 1003847 

305290 4630001310015 T000645 47499 47499 1001253 

305302 4630001313482 T002172 52397 52397 1002462 

305297 4630001314022 T001360 46004 46004 1001059 

305274 4630001315342 T003061 54470 54470 1003257 

305330 4630001317629 T000696 48258 48258 1001375 

Preostalih 87 imaju samo 1 ugovor sa nacpla=U za analitiku na koju je knjiženo - preko bss_vezau određen 

brugo i idpart za tu analitiku sa nacpla=U 

Među njima su i 4 stavke koje imaju upisan račun ali se odnose na STB (nacpla=R) : 

slog_id racun analitika idpart bss_kupac brugo 

287938 4630001200081 T000164 40217 40217 1000300 

289068 4630001200056 T000207 40330 40330 1000315 

290804 4630001307942 T006956 67552 67552 1008126 

305239 4630001308251 T007396 67115 67115 1007950 

2) Ovi podaci su mi završili u greškama: 

bss_greska nalogk red analitika iznpot jail 

042 13E50025 13 635160 -25.00 4137322 

042 13Z50048 6 635160 25.00 4137322 

039 12I50002 435 T000170 19.99 3884983 

Greška 042 : Ne može se odrediti ugovor (status=B) 

Knjiženo je na P 635160 (saldo=0) a za tog kupca nema veza u bss_vezak, bss_vezau, bss_vezar pa se nije 

moglo odrediti idpart,brugo za njega . 

Postoji 40 ugovora na analitici P 500072, za sve brugo 1000111,bss_kupac=39009 ? 

Da je knjiženo na P 500072 (isaco=D) koji je podređen P 635160 program bi odredio idpart i brugo i za ove 

stavke. 

Greška 039 : Nedozvoljena promjena podataka na kartici ( status= G) 

Za ovoga ne mogu otkriti što je mijenjano. 

Mijenjan je datum dospijeća u stavci -- (detalji u prilogu bss039.xls ) 



0









Poštovani, 

Analiziran je slučaj : Klaudije Kir 

Uplata i raču se ne zatvaraju dobro u slučaju kada je uplata manja od iznosa računa : 

Broj dokumenta VDK Datum dokumenta Datum dospijeća Datum knjiženja Nalog Opis/Originalni 

broj Duguje Potražuje 

46300-013-20612 BSS 31.3.2013 20.4.2013 31.3.2013 13I50021 

100012920130301 69,99 0,00 

nije dodijelio LB UPL 10.4.2013 10.4.2013 13E50054 

0,00 25,00 ** 

Razlog : 

nalogk datumk datumotv datumzat 

13I50021 31/03/2013 11/04/2013 12/04/2013 

13E50054 10/04/2013 11/04/2013 11/04/2013 

Program nije dodijelio LAUS broj kad je radio rasknjižavanje uplata po računima u nalogu 13E50054 

jer tad nije bilo proknjižene stavke računa 46300-013.20612 u nalogu 13I50021 te je zato rasknjižio uplatu u 

stavci bez laus broja (**) 

ZAKLJUČAK : 

Pogrešan redoslijed knjiženja : rasknjižavanje uplata po računima prije knjiženja računa. 

Nije programska greška 

U tijeku je analiza preostala 3 slučaja koje ste poslali 



0









Poštovani , 

Analiza svih slučajeva i rada programa /potrebnih dorada i izmjena u programu za rasknjižavanje uplata po 

dospijeću - u prilogu . 

ZAKLJUČAK : Program rasknjižavanja treba raditi ovako : 

Z1. Kod rasknjižavanja odrediti prvo treba na koji se ugovor odnosi uplata. Ako to nije moguće - nema 

rasknjižavanja. 

Z2. Ako je poznato o kojem se ugovoru radi , onda se gledaju samo računi vezani za taj ugovor ( opis_knjizenja 

[1,7]=brugo) 

unutar njih po dospjeću , unutar dospjeća po KIZ- kamate,DIG- stb na rate ,BSS -usluge) . 

Z3. upotrebljeni' računi kod rasknjižavanja uplata koje se upravo provodi se označe . 

Z4. Obavezno se upisuje LAUS broj za rasknjižene . 

Z5. Samo ako nema računa nerasknjiženih do kraja onda je stavka bez LB ,a li sa opis kao u Z5 tj E5 minusna 

Z6. Potrebno je uplate koje nisu zatvorene i nemaju LAUS broj u E5 nalozima potrebno je rasknjižiti po 

računima tj. uključiti u ciklus tekućeg rasknjižavanja 

-- MOlim potvrdu za opisani način rada potkrijepljen rezultatima ovakvog knjiženja za svaki poslani slučaj 

Status : Čeka se HP 

------------------------------ 

Važne napomene : 

Zatvaranje se radi automatski po jednakosti opisa i LB na zatiz_jf . 

Ako se radi normalnim redoslijedom (redoslijed je bitank faktor kod automatske obrade) , normalno se odvija 

rasknjižavanje uplata po dospijeću i zatvaranje starijih datuma dospijeće sa starijim uplatama. 

Dakle , normalan i preporučeni redoslijed provođenje obrada je slijedeći : 

1. proknjiži račune : dana za dan ( dok su ispunjeni potrebni uvjeti treba ih proknjižiti) 

2. proknjiži izvod ZR : dan za dan ( proknjiži neraspoređene uplate ) 

3. napravi rasknjižavanje uplata : ovo nije dan za dan tj. ne mora se radit svaki dan , ali je bitno da se radi od 

manjeg ka većem datumu plaćanja/uplate/izvoda. 

Preduvjet : proknjiženi su svi izdani računi 

Ako preduvjet nije ispunjen, neraspoređene uplate se nemaju na što rasknjižiti tj. ne postoje knjiženi računi na 

koje bi se uplate rasporedile 

a realno je pretpostavit da kupac plaća račun koji mu je izdan tj. da račun postoji i da nema realnog problema 

zbog kojeg ne bi bio proknjižen 

4. Nakon rasknjižavanja uplata po jednaom nalogu izvoda ZR pusti zatvaranje tih uplata. 

5. Ponavljaj 3. i 4. sve dok ima nerasknjiženih uplata . 




0







Poštovani, 


Tražili smo potvrdu za opisani način rada u zaključku u obradi 10 KZ-a . 

Poslali ste potvrdu za Z1,Z2,Z4 i Z5 te tražili pojašnjenje za Z3 i Z6 koje dajemo u nastavku . 

Molimo potvrdu opisanog načina rada i za Z3 i Z5 nakon pojašnjenja koje dajemo u nastavku potkrijeljno 

slučajevima koji su u prilogu obrade 10 10 KZ-a. 

Status : čeka se stav HP vezano za zaključke Z3 i Z6 

ZAKLJUČAK : Program rasknjižavanja treba raditi ovako : 

Z1. Kod rasknjižavanja odrediti prvo treba na koji se ugovor odnosi uplata. Ako to nije moguće - nema 

rasknjižavanja. 

HP : TOČNO (u opisu obavezno prvih sedam znamenaka BSS ugovora) 


[1,7]=brugo) 

unutar njih po dospjeću , unutar dospjeća po KIZ- kamate,DIG- stb na rate ,BSS -usluge) 

HP : TOČNO 


HP : TOČNO 

Z5. Samo ako nema računa nerasknjiženih do kraja onda je stavka bez LB ,ali sa opis kao u Z5 tj E5 minusna 

HP : ukoliko se ne može dodoijeliti LB, obavezno dodijeliti BSS broj ugovora 

-------POJAŠNJENJE : 


HP: molim pojašnjenje 

LAUS pojašnjenje : 

ovo se odnosi na slučaj 2 uplate u istom danu za isti ugovor( Ignac, zagorec) . Program je 2 puta uzeo isti 

račun/ratu : 

Isti račun : stavka redni broj 2 i 8 (ignac) , 4 i 12 (zagorec) 

ista rata : stavka redni broj 9 i 13 (ignac) , 2 i 10 (zagorec) 

zato što u toku rasknjižavanja ( nalog 13E50041 ignac, nalog 13E50055 ) nije označio te račune/stavke da su 

već 'upotrebljene' tj. za njih rasknjižena uplata . 

Z6. Potrebno je uplate koje nisu zatvorene i nemaju LAUS broj u E5 nalozima rasknjižiti po računima tj. uključiti 

u ciklus tekućeg rasknjižavanja 

HP : nije jasno kako se provodi slijedeće rasknjižavanje. 

LAUS pojašnjenje : 

ovo se odnosi na slučaj kad se rasknjižavanje uplata radi prije knjiženja računa ili kad je kupac platio više nego 

što je dužan po računima . Tad program ne može rasporediti uplatu ili dio uplate na račun jer računa nema 

(klaudije) ili je za svaki račun je rasknjižena uplata na iznos računa pa je 'nepotrošen' ostao dio uplate. 

Napr, kupac K1 za ugovr U1 ima ukupno računa na uiznos 450 a uplata je 500 . Kad se uplata rasknjiži po 

računima ostane 'nepotrošen' dio uplate 50 . 

Taj višak uplate nema LB, ali treba imati u opisu U1 brugo (Z5) te se kod slijedećeg rasknjižavanja uplata u 

nalog E5 treba i ova neraspoređene uplata za U1 uzeti u obzir a ne samo uplate koje su u Z5 nalogu za kojeg 

se tek treba napraviti rasknjižavanje . 

Napr, upravo se rasknjižavaju uplate iz naloga Z5 po računima (princip : ugovor,dospjeće, vrsta ) . Među njima 

je i uplata 100 za U1 . 

Program tada treba , osim 100 u Z5 nalogu za U1 uzeti u obzir i neraspoređenu uplatu 50 za ugovor U1 te prvo 

nju rasknjižiti (manji datum uplate) pa tek onda uplatu od 100 (veći datum uplate) . 

---------------------------- 

NAPOMENA : Sve pada u vodu : 

ako se ne knjiže računi 

ako se rasknjižavanje uplata ne radi od manjeg ka većem datumu izvoda 

ako se nakon savakog rasknjižavanja uplata ne radi zatvaranje uplata . 



0









Poštovani , 

Analiziran je slučaj : 

NENAD STRUGAR ( T001584 ) uplate rasknjižene u nalogu 13E50064 - U prilogu . 

Svodi se na ponovno knjiženje potrošenih stavki u slučaju više uplata na isti dan (Z3) i knjiženje bez LB (Z4) 

-- ništa novo u odnosu na već zaključeno. 

Treba utvrditi ima li još ovakvih slučajeva - radi se danas iza 16:00. 

Molimo stav HP vezano za termin te što treba za njih napraviti : 

a) razvaezivanje , storno te ispravno knjiženje ili 

b) samo ih locirati takve te ih dostaviti u HP u bss_priprema tablicu ili excel ili ..? 

Također, 

programske izmjene se ne rade jer čekamo potvrdu još za Z3 i Z6 za koje su poslana dodatna pojašnjenja 

STATUS : čekamo odgovore iz HP-a 


Poštovani, 

Ispravljena je kontrola kod prijenosa pripreme karitce za slučaj : 

-- sve je prošlo uredno za akcija=U -upis . Stavka tad nije bila zatvorena . 

Stavka ** je u međuvremenu 18.4.2013. zatvorena (arhivk) : 

jail konto analitika nalogk red 

4358783 120710 T000091 13I50008 24415 

---nakon zatvaranja stavka se nije prenijela sa akcija=I-izmjena a trebala je . 


Obavijestiti korisnika o preuzimanju novog LAUS FINK liba u utorka 6.5.2013. 



0









Poštovani , 

Na objektu bss_knj_jf Rasknjižavnje i zatvaranje uplata po dospijeću maknuto je polje Nalog izvoda budući je 

dodano da u rasknjižavanje ulaze samo one stavke koje imaju u opisu (prvi 7 znakova) upisan broj ugovora 

(bss_vezau.brugo). 

Točnije : stavke čija kombinacija vrsta nalitike, analitika i prvih 7 znakova opisa knjiženja (brugo) postoji u 

preuzetimm ugovorima iz BSS-a. 

Tako će u rasknjižavnje ući i stavke koje su ostale otvorene od zadnjeg rasknjižavanja (više plaćeno) koje imaju 

gore navedeno obilježje i dodatno ispunjavaju uvjete za nerasknjižene uplate : 

knjižene su na potražnoj strani konta DTVKK (dugpot=P) 

prazan im je LB (protokol) 

prazan im je broj zatvaranja (jail) 

Kod rasknjižavanja uplate po računima uzimaju se sve otvorene stavke na strani računa (dugpot=D, jail prazan) 

koje imaju popunjen LB (protokol) . 

Odobrenja ( vdok = ODO ) su izuzeta kod rasknjižavanja jer će za njih biti poslan poseban zahtjev ( prema 

dogovoru na sastanku 09.05.2013.) 

Zasad ih treba ručno povezivati s računom na koji se odnose tj kojeg umanjuju . Ako račun i odobrenje nisu 

povezani , u rasknjižavanje ulazi cijeli iznos računa ( u primjeru 100 ) , dok iznos odobrenja ne ulazi tj. kao da 

odobrenje ne postoji . 

NAPOMENA : izmjene/dorade vezano za ZAKLJUČAK : Program bss_knj_jf Rasknjižavnje i zatvaranje uplata po 

dospijeću (F1 Knjiži) treba raditi ovako : 


[1,7]=brugo) 

unutar njih po dospjeću , unutar dospjeća po KIZ- kamate,DIG- stb na rate ,BSS -usluge) 

HP : TOČNO : računi koji u bss_vezar imaju upravo taj brugo 


HP : TOČNO 

Z5. Samo ako nema računa nerasknjiženih do kraja onda je stavka bez LB ,ali sa opis kao u Z5 tj E5 minusna 

HP : ukoliko se ne može dodoijeliti LB, obavezno dodijeliti BSS broj ugovora ( opis_knjizenja[1,7]=brugo) 


Obavijestiti korisnika o preuzimanju novog LAUS FINK liba. Novi lIb je već na internetu. 

----------------------------------- 

Preporuka za povezivanje računa i odobrenja : 

Knjižiti 2 stavke na isti iznos c a različit predznak . c = a + b gdje je a>0 iznos računa a b









Poštovani , 

Isporučene su i programske izmjene vazane za ZAKLJUČAK : Rasknjižavnje i zatvaranje uplata po dospijeću 

(F1 Knjiži) treba raditi ovako : 

--Z1. Prvo treba odrediti na koji se ugovor odnosi uplata. Ako to nije moguće - nema rasknjižavanja. 


-Z6. Potrebno je uplate koje nisu zatvorene i nemaju LAUS broj rasknjižiti po računima tj. uključiti u ciklus 

tekućeg rasknjižavanja 

ovo se odnosi na slučaj kad se rasknjižavanje uplata radi prije knjiženja računa ili kad je kupac platio više nego 

što je dužan po računima . 

Status : preostaje još isporučiti programske izmjene vezane za : 


Ovo se odnosi na slučaj 2 uplate u istom danu za isti ugovor zato što u toku rasknjižavanja nije označio te 

račune/stavke da su već 'upotrebljene' 

tj. za njih rasknjižena uplata . 


Poštovani, 

Maknuta je poruka za obavezan unos oba naloga koja se javljala na objektu bss_knj_jf. 


Obavijestiti korisnika o preuzimanju novog LAUS FINK liba. Novi lib je već na internetu. 



Poštovani, 

Na ekranu bss_knj_jf vraćeno je filter polje Nalog izvoda ZR koje nije obavezno za unos. 

U slučaju da se nalog ne unese rasknjižavanje se radi po cjelom kontu. 

U slučaju da se nalog unese rasknjižavanje se radi samo za uplate u tom zadanom nalogu . 


Obavijestiti korisnika o preuzimanju novog LAUS FINK liba u četvrtak ujutro 16.5.2013. 

Za ostale dopune zahtjeva koje ste danas poslali ( pretplata, djelimično zatvaranje ) poslat ćemo pitanja . 



0









Poštovani, 

Na vaš zahtjev (Ivan telefonski) novi FINK lib je slinkan i nalazi se na internetu te ga možete preuzeti . 

Razlog : 

Na ekranu bss_knj_jf vraćeno je filter polje Nalog izvoda ZR koje nije obavezno za unos. 

U slučaju da se nalog ne unese rasknjižavanje se radi po cjelom kontu. 

U slučaju da se nalog unese rasknjižavanje se radi samo za uplate u tom zadanom nalogu . 

Ostale dopune zahtjeva koje ste danas poslali ( pretplata, djelimično zatvaranje ) smatramo adaptivnim 

održavanjem. 

Molimo suglasnost za otvaranje novog KZ sa istim vašim brojem zahtjeva HP 13321 , vrsta održavanja 

adaptivno ili pošaljite novi vaš broj . 

Napomena : ovaj KZ tj. HP 13321 ima vrstu održavanja korektivno . 



Poštovani, 

Napravljene su izmjene na objektu bss_knj_jf na način da se od dvije ili više otvorenih uplata ( jail='', dugpot=P) 

za isti : 

konto,analitika (kupac) ,opis[1,7] (ugovor) ,datumdok (datum uplate ) 

formira jedna minusna stavka i sa njom dalje ide u rasknjižavanje po računima tj. svodi se na slučaj 1 uplata zas 

isti : 




----------------------------------veza 

- ZAKLJUČAK Z3. 'upotrebljeni' računi kod rasknjižavanja uplata koje se upravo provodi se označe . 

ovo se odnosi na slučaj 2 uplate u istom danu za isti ugovor .Program je 2 puta uzeo isti račun/ratu jer nije 

označio te račune/stavke da su već 'upotrebljene' kod rasknjižavanja 1. uplate tj. za njih rasknjižena uplata 

nego su opet uzete u obzir kod rasknjižavanja 2.uplat e. 

Nakon testiranja na vašoj test bazi poslat ćemo povratne informacije 



0









Poštovani, 

Dogovreno s HP (Ivan , Vranić) : 

- treba testirati najnovije izmjene . 

Testiranje provesti na HP TEST bazi : u nalog 13E50008 rasknjižiti uplate u izvodu 13Z50019 

--- *** 

Napravljene su izmjene na objektu bss_knj_jf na način da se od dvije ili više otvorenih uplata ( jail='', dugpot=P) 

za isti : 


formira jedna minusna stavka i sa njom dalje ide u rasknjižavanje po računima tj. svodi se na slučaj 1 uplata za 

isti : 


--- 

Testiranje provedeno .ZAKLJUČAK : 

U prilogu T000124os.xls što je rasknjiženo po novom na test bazi nakon što je spušten novi fink lib sa *** za 

analitika T000124 . 

Sad ne duplira rate , dobro bira redoslijed kao što je radio prije - prilog T000124ots .xls 

Međutim , uplata je n-struka (n -broj ugovora sa nacpla=U za tu analitiku) 

Programske izmjene kojima se rješava/izbjegava multipliciranje iznosa uplate 

možete preuzeti sutra ujutro iza 6 sati kad će na internetu biti novi FINK lib 



Poštovani, 

Izmjenjen je upit za dohvat stavaka na objektu bss_knj_jf da bi se izbjeglo duplavanje iznosa za rasknjižavanje. 


Obavijestiti korisnika o pruzimanju novog LAUS FINK liba u petak 17.5.2013. iza 6:00 



Poštovani, 

u prilogu su upute za rad vezano za otvorene uplate i njihovo zatvaranje što je preduvjet urednog 

rasknjižavanja slijedećih uplata po računima 

te prijedlog rješenja za problematične slučajeve . 

Upute sadrže postupak kako zatvaranje otvorenih uplata provesti sad kroz aplikaciju na neautomatski način 

Molimo suglasnost za zatvaranje ovog zahtjeva - Riješen 

Molimo pošaljite novi zahtjev za automatsku podršku problematičnih slučajeva : 

pretplata (izuzeće kod rasknjižavanja pod 1) i 

podplata (djelomično zatvaranje pod 2, 3 te odobrenja) 



0









postoje 3 uplate nezatvorene : 

opis idin vdok datumk datumdok nalogk 

1009637-20130401 1.00 UPL 14/05/2013 14/05/2013 13Z50111 

1009637-20130401 -1.00 UPL 14/05/2013 14/05/2013 13E50087 

1009637-20130401 -1.00 UPL 15/05/2013 14/05/2013 13R50055 *** 

koje se dobiju za analitika A T009334 i opis =1009637-20130401 

Jedna od njih je u nalogu :nalogk 13R50055 , datumk 15/05/2013. 

U formiranje sume ulaze samo stavke knjižene u nalozima koji imaju u vrstnal upisan ziro/iban kao što je u 

DTVIB 

sifra DTVIB 

podatak HR4723900011500005667 

tekst IBAN IZVODA ZA DTV 

Z5 ŽIRO RAČUN EVO TV 

E5 KNJIŽENJE PO DOSPJEĆU 

Dakle, stavke u nalozima druge vrste koje nisu Z5 ili E5 ne ulaze u rasknjižavanje. 

U konkretnom slučaju radi se o korekciji koju je također trebalo knjižiti u E5 nalog . Isto tako nije jasan smisao 

korekcije jer je stvorila uplatu -1. Što snjom napraviti pod pretpostavkom da je u nalogu E5 knjižena ? 

Molimo suglasnost za zatvaranje ovog zahtjeva - Riješeno . 

Predlažemo za sve specijalne slučajeve (saldo uplata 0 ili saldo uplata < 0 ) , pretplata , podplata ,... rješavati 

kroz novi zahtjev u kojem će se specificirati što program u pojedinom slučaju treba napraviti . 


Poštovani, 

Predlažemo zatvaranje ovog zahtjeva 13321 - Riješen. 

Razlog : danas smo zaprimili novi zahtjev 13413 kroz kojeg će se rješavati dalje rasknjižavanje po dospjeću, a 

prema zapisniku sa satanka održanog jučer 28.5.2013 

---------- 

Z1 do Z6 su zaključci koji su doneseni nakon analize i realizirani kroz ovaj zahtjev i isporučeno : 

06.5.2013. Ispravljena je kontrola kod prijenosa pripreme karitce tj. greška: nakon zatvaranja stavka se nije 

prenijela sa akcija=I-izmjena a trebala je . 

10.5.2013. -Na objektu bss_knj_jf Rasknjižavnje i zatvaranje uplata po dospijeću maknuto je polje Nalog izvoda . 

- dodano da u rasknjižavanje ulaze samo one stavke koje imaju u opisu (prvi 7 znakova) upisan broj 

ugovora (bss_vezau.brugo). U vrstanal.ziro upisan IBAN kao u DTVIB 

Tako će u rasknjižavnje ući i stavke koje su ostale otvorene od zadnjeg rasknjižavanja. 

-Z1. Prvo treba odrediti na koji se ugovor odnosi uplata. Ako to nije moguće - nema rasknjižavanja. 


Dakle, ako dođe uplata u Z5 za koju ne postoji ugovor tj. arhivk.opis[1,7] 

||arhivk.vanalitika||arhivk.analitika ne postoji u bss_vezau za nacpla=U i to brugo[1,7]||vanalitika||analitika tu 

stavku iz Z5 (nalog izvoda) 

ne rasknjižavaj nego samo napravi storno u E5 (nalog rasknjiženja) . Te stavake kod pripreme za 

slanje kartice ubaci u bss_priprema sa status=B i bss_status sa greškom po istoj logici : 

ne postoji u bss_vezau ugovor na kojeg se uplata odnosi 

Preostale uplate u Z5 tj. storna u E5 za koje postoji ugovor u bss_vezau ulaze u rasknjižavanje . 

To se odnosi i na uplate opisane u Z6 . Za njih vrijede uvjeti : postoji brugo na kojeg se uplate odnose 

nemaju laus broj 

otvorene su 

nisu u nalogu E5 u kojem se trenutno radi rasknjižavanje nego u nekom drugom (nastale su prije) 

- Z2. Ako je poznato o kojem se ugovoru radi , onda se gledaju samo računi vezani za taj ugovor 

( opis_knjizenja[1,7]=brugo) 



0


Status: 

Poštovani, 






-završen, unutar Isporučen njih po dospjeću - Korisnik , potvrdio unutar dospjeća ispravnost po KIZ- kamate,DIG- stb na rate ,BSS -usluge) 

HP : TOČNO : računi koji u bss_vezar imaju upravo taj brugo 

- Z4. Obavezno se upisuje LAUS broj za rasknjižene . 

HP : TOČNO 

- Z5. Samo ako nema računa nerasknjiženih do kraja onda je stavka bez LB ,ali sa opis kao u Z5 tj 

E5 minusna 

HP : ukoliko se ne može dodoijeliti LB, obavezno dodijeliti BSS broj ugovora ( opis_knjizenja 

[1,7]=brugo) 

-Z6. Potrebno je uplate koje nisu zatvorene i nemaju LAUS broj u E5 nalozima rasknjižiti po 

računima tj. uključiti u ciklus tekućeg rasknjižavanja 

slučaj kad se rasknjižavanje uplata radi prije knjiženja računa ili kad je kupac platio više 

nego što je dužan po računima . 

Tad program ne može rasporediti uplatu ili dio uplate na račun jer računa nema ili je za 

svaki račun je rasknjižena uplata na iznos računa pa je 'nepotrošen' ostao dio uplate. 

Napr, kupac K1 za ugovr U1 ima ukupno računa na uiznos 450 a uplata je 500 . Kad se 

uplata rasknjiži po računima ostane 'nepotrošen' dio uplate 50 . 

Taj višak uplate nema LB, ali treba imati u opisu U1 brugo (Z5) te se kod slijedećeg 

rasknjižavanja uplata u nalog E5 treba i ova neraspoređene uplata za U1 uzeti u obzir a ne samo uplate koje su 

u zadanom Z5 nalogu 

14.5.2013. Maknuta je poruka za obavezan unos oba naloga koja se javljala na objektu bss_knj_jf. 

15.5.2013. Na ekranu bss_knj_jf vraćeno je filter polje Nalog izvoda ZR koje nije obavezno za unos. 

16.5.2013. Izmjenjen je upit za dohvat stavaka na objektu bss_knj_jf da bi se izbjeglo duplavanje iznosa za 

rasknjižavanje. 

Z3. 'upotrebljeni' računi kod rasknjižavanja uplata koje se upravo provodi se označe . 

ovo se odnosi na slučaj više uplata u istom danu za isti ugovor( Ignac, zagorec) . Program je 2 

puta uzeo isti račun/ratu 

Napravljene su izmjene na objektu bss_knj_jf na način da se od dvije ili više otvorenih uplata 

( jail='', dugpot=P) za isti konto,analitika,opis[1,7] ,datumdok 

formira jedna minusna stavka i sa njom dalje ide u rasknjižavanje po računima. (saldo uplata istog 

dana) 





0











Klijent: 





Hitnost: 

Vrlo hitno 


Glorija 


13320 



16.04.2013 13:04 

Upisao: 

Božo Mišeta 

Područje: 

EOBRRAC 


20.04.2013 


15.4. u eObradi je likvidiran i poslan u Laus 301 račun, a u prijenosu se pojavilo 278 računa (u greškama 

ništa). Ovih 278 računa dobilo je Laus broj. 23 komada računa odrađenih u eObradi nije se prenijelo u 

Laus. 16.4 korisnici se ne uspijevaju logirati u aplikaciju zbog dolje navedene greške. 



0









Poštovani, 

Analiziran je slučaj : 

15.4. u eObradi je likvidiran i poslan u Laus 301 račun, a u prijenosu se pojavilo 278 računa (u greškama ništa). 

Ovih 278 računa dobilo je Laus broj. 

23 komada računa odrađenih u eObradi nije se prenijelo u Laus. 

Zaključak : prenijelo se i ovih 23 ali 16/04/2013. Stanje uredno . 

Od 278 koji u eo_veze imaju datum 15.4.2013. čudna su ova 2 : 

000003-14 2013-04-15 11:59:21 15/04/2013 4630441302037 -- * u rednom broju godina 14 

017758-13 2013-04-12 15:49:01 15/04/2013 4630441301916 -- ** datum preuzimanja 12.4.2013 a u eo_veze 

15.4.2013 . Dakle 278-1=277 

dpreuz status (count(*)) 

12/04/2013 0 551 

15/04/2013 0 300----------> 300 : 277 preuzetih sa datum=15.4.2013 + 23 sa datum=16.4.2013. 

u eo_veze = 300 

16/04/2013 0 296---------> 

16/04/2013 1 1-------- greška 

17/04/2013 236 ---> nepreuzeto 

Greška koju ste poslali vezano za spajanje na aplikaciju rješava se 



Da li se greška koju ste naveli javila kod pokretanja same aplikacije ili nakon što je korisnik unio svoje parametre 

i kliknuo na 'Prijavi'? 



0









Poštovani, 

svih 21 račun su preuzeti : u eo_veze : datum=07/05/2013 bez interencije u programu i bazi . 

Zaključak : prijenos NIJE piuštan iza 16:18 dana 06.05.2013. tj 10 minuta nakon što je poslan u LAUS još 21 

račun . 

Ukoliko su zaključak i pojašnjenje dostatni molimo pošaljite suglasnost za zatvaranje zahtjeva - Riješen 

POjašnjenje : 

servis ima vremensku rezervu : prenosi sve što ima datum preuzimanja za 10 minuta manji od tekućeg 

(datumpreuzimanja < current -10 units minute ) 

Zadrška je ugrađena jer se znalo dogoditi da dođe zaglavlje a ne dođu stavke pa se tražilo da se onemogući ova 

situacija . 

zadnji prijenos 6.5.2013. u 16:15 . 

Nepreneseni a poslani računi dana 6.5.2013 imaju datumpreuzimanja 2013-05-06 16:08: koji ne udovoljava 

vremenskoj rezervi za taj zadnji prijenos 6.5.2013. te se zato nisu prenijeli . 

Bez problema bi se prenijeli u svakom prijenosu puštenom iza 16:19 dana 6.5.2013 kao što se i dogodilo kod 

slijedećeg prijenosa dana 7.5.2013. 

rednibroj id datumpreuzimanja protokol datum 

023654-13 134534 2013-05-06 16:08:25 4630441306176 07/05/2013 

023194-13 134532 2013-05-06 16:08:24 4630441306268 07/05/2013 

023485-13 134533 2013-05-06 16:08:24 4630441306165 07/05/2013 

023458-13 134531 2013-05-06 16:08:23 4630441306137 07/05/2013 

022860-13 134529 2013-05-06 16:08:22 4630441306174 07/05/2013 

023457-13 134530 2013-05-06 16:08:22 4630441306175 07/05/2013 

023442-13 134527 2013-05-06 16:08:21 4630441306188 07/05/2013 

023455-13 134528 2013-05-06 16:08:21 4630441306216 07/05/2013 

023404-13 134525 2013-05-06 16:08:20 4630441306202 07/05/2013 

023444-13 134526 2013-05-06 16:08:20 4630441306255 07/05/2013 

023078-13 134523 2013-05-06 16:08:19 4630441306215 07/05/2013 

023079-13 134524 2013-05-06 16:08:19 4630441306244 07/05/2013 

023462-13 134521 2013-05-06 16:08:18 4630441306173 07/05/2013 

023583-13 134522 2013-05-06 16:08:18 4630441306267 07/05/2013 

023570-13 134519 2013-05-06 16:08:17 4630441306266 07/05/2013 

023460-13 134520 2013-05-06 16:08:17 4630441306231 07/05/2013 

023577-13 134518 2013-05-06 16:08:16 4630441306254 07/05/2013 

023467-13 134517 2013-05-06 16:08:16 4630441306230 07/05/2013 

023573-13 134515 2013-05-06 16:08:15 4630441306200 07/05/2013 

023568-13 134516 2013-05-06 16:08:15 4630441306201 07/05/2013 

023465-13 134514 2013-05-06 16:08:09 4630441306214 07/05/2013 

dpreuz uradio datum vrijeme (count(*)) 

06/05/2013 SKRAMER 07/05/2013 15:42 21 

06/05/2013 SKRAMER 06/05/2013 16:14 136 

06/05/2013 SKRAMER 06/05/2013 16:15 12 


Poštovani, 




0











Klijent: 



Pitanje 


Hitnost: 

Vrlo hitno 


Glorija 


13317 

Riješen 


16.04.2013 11:25 

Upisao: 

Božo Mišeta 

Područje: 

LCSBI 


18.04.2013 


Kako da kod novog načina spajanja preko HP-a dođemo do izvještaja definiranih u MIS? Gornja slika je 

dosadašnji način spajanja, dok na donjoj je spajanje na novi način gdje ne vidim izvještaje. 


Poštovani, 

potrebno je u tab stripu u donjem lijevom kutu odabrati tab Folders - na screenshotu se vidi da je odabran tab My 

Documents. 



0











Klijent: 





dis_ban_fk 

Hitnost: 



višnja 


13319 



16.04.2013 10:39 

Upisao: 

Dajana Lekić 

Područje: 

LKROP 


03.05.2013 


07.05.2013 

Potrebno je kroz dis_ban_fk DISKETE ZA BANKE na ekranu dis_ban_fk dodati novi meni ISTARSKA 

KREDITNA BANKA D.D. i omogućiti izradu datoteke za plaću za: 

4063 ISTARSKA KREDITNA BANKA D.D. 

prema uputama u prilogu. 


Na objektu dis_ban_fk DISKETE ZA BANKE dodana je nova banka -> Istarska banka (zadnja u nizu).Datoteka 

za tu banku napravljena je prema uputama koje su nam dostavljene. 

krop lib od 03.05.2013 


Ispravljena je duljina prometnog sloga u datoteci za Istarsku banku. 

krop i base libovi su već na internetu 


Poštovani, 





0











Klijent: 






Nije hitno 


Glorija 


13318 



16.04.2013 07:23 

Upisao: 

Božo Mišeta 

Područje: 

LFINK 


30.06.2013 

Kod ispisa listi u financijskom dijelu Lausa kod opcije Excel-mail liste se u većini slučajeva formiraju na 

način da je kod numeričkih polja ponašanje kao u excelu (zarez je razdjelnik decimalnih mjesta, a točka je 

razdjelnik tisućica). Na primjeru ove liste je slučaj obratan tj. jednako je kao u Lausu. Potrebno je sve liste 

svesti na isti format (excel). 


Lista bilkon6_xls prilagođena formatu ispisa u csv datoteku sa decimalnim zarezom. 

Preuzeti novi LAUS FINK liba u petak 19.4.2013. 


Poštovani, 

Lista bilkon6_xls prilagođena formatu ispisa u csv datoteku sa decimalnim zarezom. 

Isporučeno 19.4.2013. 

Ispitivati koje sve od velikog broja listi u LFINK treba korigirati na isti način smatramo neracionalnim trošenjem 

vremena iako je zahtjev potpuno opravdan . 

Predlažemo radi racionalnijeg trošenja vremena i bržeg rješavanja : 

Uputite korisnicima ovih listi iz LFINK aple da kad primjete da lista koju su ispisivali opcijom ispisa Excel-mail 

ima decimalni znak točku a ne zarez 

proslijede na rješavanje tj. pošaljite novi zahtjev ako se treba ista korekcija napraviti na nekoj drugoj listi ( poslan 

već HP 13341 ) . 

Molimo povratne informacije/ suglasnost za zatvaranje zahtjev a- Riješen . 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Glorija 


13316 



15.04.2013 09:58 

Upisao: 

Božo Mišeta 

Područje: 

LFINK 


25.04.2013 


26.04.2013 







Poštovani 

Program za automatsko knjiženje izvoda ZR je prilagođen za knjiženje prema formatu poziva na broj odobrenja 




upisanu 

uputu za poziv na broj odobrenja 01-618754. 

U 1. novu uputu ide poziv na broj odobrenja 01-685748 , 

U 2. novu uputu ide poziv na broj odobrenja 01-649919 . 

Ostalo u pojedinoj kako ste napisali u zahtjevu . 



Molimo povratne informacije/ suglasnost za zatvranje zahtjeva - Riješen 


Poštovani, 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Glorija 


13315 

Riješen 


15.04.2013 09:48 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


25.04.2013 


1. Usluga Mali oglasi provodi se kroz šest usluga: 

44611 Večernji list 

44612 Novi list 

44613 Glas Istre 

44614 Varaždinske vijesti 

44615 24 sata 

44616 Zagorski list 

Svih šest usluga treba knjižiti po istom modelu. Trenutno se knjiže po tri modela. 

Knjiženje za svih šest usluga potrebno knjižiti po slijedećem modelu. 

MPV kao i do sada na 122300 za GOT i GR1, ili 122320 za VR1 

PDV na nivo 00000 

MPV umanjena za PDV na 229010, na poslovnog partnera i nivo 00000. 

Trenutno za uslugu 44611 i 44612 ne knjiži PDV, uslugu 44613 knjiži ispravno, ali vezano za ovaj zahtjev 

napravit izmjenu da knjiži 229010 umjesto 229000, 

Usluge 44614 i 44615 knjiži PDV na nivo 00000, iznos MPV umanjene za PDV knjiži pogrešno na nivo 

poštanskog ureda bez poslovnog partnera, a na konto 229010. 

2. Izmjena knjiženja stope PDV 5%, sada knjiži na konto 240000, izmjenu provesti da knjiži na konto 

240001. Stopa od 5% nalazi se u koloni zajedno sa stopom 10% pa je i treba knjižiti na konto na koji se 

knjiži stopa od 10% (240001). 

3. Na objektu knjts8.jas Knjiženje WEB brzojava izmijeniti : 

a) nivo knjiženja za PDV, nivo 41003 izmijeniti na nivo 00000. 

b) kod knjiženja konta 122330 knjižiti laus broj dokumenta 



0









Poštovani, 

Na objektu knjts8.jas Knjiženje WEB brzojava napravljene su izmjene: 

- nivo knjiženja za PDV je sada 00000. 

- kod knjiženja konta 122330se sada lknjiži i laus broj dokumenta 


Instalacija: Novi WIN FAUS lib će biti dostupan u utorak 14.05.2013 ujutro. 


Poštovani, 

Napravljena je izmjena knjiženja stope PDV 5%. (točka 2.) 

Sada se stopa 5% knjiži na konto 240001. 

Izmjena je napravljena na objektima: 

knjdig.jas - Digitalna TV 

knjkat.jas - Knjiženje prometa kataloške prodaje 

knjmips.jas - Knjiženje MIPS dokumenata 

knjts5.jas - Knjiženje poštanskih i novčanih usluga plaćenih virmanom 

knjts7.jas - Knjiženje poštanskih i novčanih usluga plaćenih gotovinom 

knjts8.jas - Knjiženje WEB brzojava 


Instalacija: NOvi WIN FAUS će biti dostupan u utorak 14.05.2013 ujutro. 


Poštovani, 

Za rješavanje točke 1 na knjts5 i knjts7 potrebno je dostaviti šifre partnera na koje ste trebaju knjižiti MPV-porez 

na konto 229010 za usluge : 

44614 Varaždinske vijesti 

44615 24 sata 

44616 Zagorski list 

kao što ste ranije dostavili i za usluge : 

usluga partner 

44611 Večernji list 676767 

44612 Novi list 615550 

44613 Glas Istre 650298 

Ako nisu poznate i u program ugrađene šifre partnera za njih, knjiži se na 229010 bez analitike. 

NAPOMENA: dostavljene šifre moraju biti aktivne i NSC 

Status : čeka se HP za dostavu šifri 


Napravljene su izmjene knjiženja malih oglasa na objektu Knjizenje postanskih i novcanih usluga placenih 

gotovinom (knjts7_fas). 

Ako možete pogledat jesu li izmjene ono što ste i tražili. 

Dali isti princip knjiženja treba biti i na objektu knjiženja virmana? Kod virmana se ne knjiži PDV malih oglasa 

posebno za usluge malih oglasa već se PDV proknjiži skupno na razini fakture. 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13314 

U rješavanju 


15.04.2013 09:45 

Upisao: 

Božo Mišeta 

Područje: 

LROBD 


19.04.2013 


Omogućiti: 

1.unos više barkodova za isti artikal i proširiti prijenos prema mips_laus bazi tako da se za jedan artikal 

prenosi više barkodova 

2.unos istog barkoda na različite šifre artikala 

(npr. Cigarete – jedan barkod je pridružen većem broju artikla) i proširiti prijenos prema mips_laus bazi tako 

da se za više artikala prenosi isti barkod. 



0









Poštovani, 

Tehnički su izvedive obje točke. 

Logična nije točka 2. jer može prouzročii pogreške kod zaduženja , razduženja, prodaje a pomoći neće nikome 

jer se ionako po barkodu ne može odrediti o kojem se točno artiklu radi jer ga ima više artikala 

Smatramo boljim rješenjem riješiti se cigareta po starim cijenama ili zadržati postojeći način : 1 barkod 

pouzdano određuje 1 artikal 


Na objektu artdd_ja Artikli - Dobavljač/Proizvođač omogučen je unos više različitih barkodova za isti artikal. 


Poštovani , 

Nakon analize i pokušaja rješavanja dijela zahtjeva koji se odnosi na : 

proširiti prijenos prema mips_laus bazi tako da se za jedan artikal prenosi više barkodova 

na način da se proširi postojeći prijenos artikala tj. postojeća tablica artikli zaključili smo da nije praktično 

rješenje . 

Razlog :artikli tablicu treba širiti za nepoznat broj polja za upis više barkodova za 1 artikal ili 

bez širenja tablice artikli poslati onoliko slogova za artikal koliko ima barkodova za njega 

Sad se prenosi 1 barkod za 1 artikal po načelu : 

MAX(barkod) FROM art_dob1 za artikal . 

i podatak se proslijedi u tablicu artikli.barkod . 

Budući da je zahtjev prenositi više barkodova za artikal i ne zna se koliko je to barkodova ( 2 ,3 10 ,..) 

predlažemo barkodove za artikle prenositi u posebnoj tablici .Strukturu nove tablice treba dogovriti s MIPS-om 

jer iz te nove tablice treba preuzeti podatke i proslijediti u MIPS aplikacije . 

Predlažemo sastanak LAUS-MIPS- HP IT ili da pošaljemo prijedlog strukture nove tablice / rješenja 

Status : čekamo stav HP 


Poštovani, 

Molimo povratne informacije vezano za : 

strukturu tablice 

opis prijenosa te 

potrebne kontrole kod ažuriranja veze artikal-barkod 

( prilogu navedeno) 

Status: usaglašavanje voditelj-klijent 

Napomena: 

Potrebno usaglasiti s MIPS-om jer iz te nove tablice treba preuzeti podatke i proslijediti u MIPS aplikacije . 



0











Klijent: 





bss ubrzanje 

Hitnost: 



ivan 


13313 



12.04.2013 19:44 

Upisao: 

Dajana Lekić 

Područje: 

LFINK 


15.04.2013 


22.04.2013 

Potrebno je optimizirati pripreme i prijenosa kartice kupca iz LAUSa u BSS preko objekta 'bss_kart_jf 

PRIJENOS KARTICE KUPCA LAUS – BSS' u BSS. 

Trenutno sami prijenos ne traje dugo ali kada se radi priprema podataka to traje od 3 do 10 sati. 


Napravljene su dorade za ubrzanje priprema podataka na objektu bss_kart_jf. 



Poštovani, 





0











Klijent: 





bss 

Hitnost: 

Vrlo hitno 


ivan 


Zahtjev 13312 ( u prilogu) 

13312 



12.04.2013 18:20 

Upisao: 

Dajana Lekić 

Područje: 

LFINK 


15.04.2013 


16.04.2013 

Kod pripreme i prijenosa kartice kupca iz LAUSa u BSS preko objekta 'bss_kart_jf PRIJENOS KARTICE 

KUPCA LAUS – BSS' u BSS se šalju krivi podaci. 

Po jednom broju ugovora (brugo) šalje se više analitika. Ako se u analizu uzmu i slogovi koji nisu preneseni 

ili su u grešci može biti i preko 70 različitih kupaca po nekom ugovoru. 

select distinct analitika,brugo,idpart from bss_priprema where status !='G' into temp ccc; 

select analitika,count(*) from ccc group by 1; 

select idpart,count(*) from ccc group by 1; 

select brugo,count(*) c from ccc group by 1 having count(*) >1 ; 

Prilog: problematične kartice koje nam je dostavio BSS. ( *LAUS.xlsx) 



0









Poštovani, 

Provedena je naliza ispravnosti svih slogova u bss_priprema . 

ZAJKLJUČAK : 

Za neke slogove u bss_priprema : 

pogrešan podatak brugo , idpart dobar podatak tj. priprema odgovara po analitici i opisu knjiženom 

brugo treba biti kao opis tj. kao bss_priprema.opis_knjizenja[1,7] 

Uglavnom se radi o : 

-- minusnim potražnim stavkama, bez protokola , vdok=UPL ( storno neraspoređene uplate u ZR ) opis= brugo : 

analitika i idpart točni, a pogrešan brugo . 

--- brugo! =opis_knjizenja[1,7] 

Ako je u arhivk.opis a kasnije i u bss_priprema.opis_knjiženje nešto drugo a ne broj ugovra (brugo) onda se 

dogodi greška kod određivanja brugo. 

Dakle, Svi slogovi kojima brugo!=opis_knjizenja[1,7] potencijalno su pogrešni 

- /home/admlaus/bss_err.txt ( 394 sloga) : neki su pogrešni a neki ne 

Ukupno slogova u bss_priprema sa status!=G 191085 

Molimo provjeru sa vaše strane za ovih 394 sloga . 

Prijedlog : ugraditi grešku ako u opisu knjiženja prvih 7 znakova nije postojeći broj ugovra (brugo) ? 

STATUS : Čekamo upute za daljnje postupanje 


Postavljena je kontrola na traženje broja ugovora iz tablice bss_vezau za prvih 7 znakova iz polja opis_knjizenja. 

Ukoliko nema broj ugovora upista će se nova greška 042 Ne može se odrediti ugovor. 

Potrebno je izvesti SQL za unos nove greške. 

INSERT INTO bss_greska 

values ('042','Ne može se odrediti ugovor'); 



Poštovani, 

zadnja obrada poslana je 17.4.2013 . - otad nema primjedbi na rad programa . 


Postavljena je kontrola na traženje broja ugovora iz tablice bss_vezau za prvih 7 znakova iz polja opis_knjizenja. 

Ukoliko nema broj ugovora upista će se nova greška 042 Ne može se odrediti ugovor. 

Potrebno je izvesti SQL za unos nove greške. 


values ('042','Ne može se odrediti ugovor'); 


Poštovani, 




0











Klijent: 





Hitnost: 



Glorija 


13311 



12.04.2013 13:14 

Upisao: 

Božo Mišeta 

Područje: 

LKROP 


30.04.2013 


19.04.2013 

Molim za izmjenu automatsko knjiženje plaća na objektu place_k_fk KNJIŽENJE PLAĆA promijeniti nivo 

knjiženja za konta obveza. 

Sada je nivo knjiženja 40013, a izmjenu napraviti na nivo 00000. 

Izmjenu provesti na grupi konta obveza 23 . . . . i 24 . . . . 


Poštovani, 

napraviti će se izmjena u programu knjiženja tako da se umjesto podatka 40013 koristi organizacijska jedinica 

koja predstavlja firmu (slog iz orgj gdje je istrukt = F i aktivnost = D) a to je kod Vas 00000. 

Međutim,kod formiranja virma također se koristi šifra 40013 a puni se u polje orgj u tablici virman i zajedno sa 

kontom čini poziv na broj zaduženja. 

Da li želite i u tom programu zamjenu 40013 sa 00000? 

Pozdrav 


Kod knjiženja plaća za stavke koje se knjiže zbrojno umjesto na org. jedinicu 40013 knjižiti će se na org. jedinicu 

firmu . 

Također kod formiranja virmana umjesto org. jedinice 40013 u poziv na broj zaduženja bilježiti će se org. jedinica 

firma . 

Firma je podatak iz tablice orgj koja ima podatak istrukt= F i aktivnost= D, a to je u Vašem slučaju org. jedinica 

00000. 

Preuzmite: krop lib od 18/04/2013 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Višnja 


13310 



11.04.2013 12:18 

Upisao: 

Božo Mišeta 

Područje: 

LKROP 


30.04.2013 


31.08.2013 

Potrebno je kroz slijedeće rekapitulacije iz arhiva izvršiti izmjene na način da se u koloni prikazuje stvarni 

neto, a ne dohodak (već je dio izmjenjen kroz zahtjev 12688): 

-rekga_fk REKAPITULACIJA PO GR.PRIMANJA IZ ARHIVA, kroz funkcijske tipke F2 Djelatn, F3 Orgj, 

F6 Nadorgj i F7 Rad.Mj 

- prpar_fk PREGLED PRIMANJA IZ ARHIVA, kroz funkcijske tipke F7 Isp-radn i F8 Isp-RO. 


Poštovani, 

U ovom zahtjevu radi se o izmjeni već postojeće funkcionanolnosti koja godinama postoji za HP i za se ostal 

ekorinsike. 

Sada tražene izmjene specifične su za Naručitelja, pa zahtjev spad au adaptivno. 

Za realizaciju zahtjeva potrebno je 30h, jer se radi o izmjeni na 7 lista. 

Molimo potvrdu procjen angažmana i odobrenje rada za isporuku do kraja 8/2013. 

Za Laus CC 

LJubo NIkolić 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Ivan 


13309 



11.04.2013 11:04 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


14.04.2013 


Potrebno je podesiti knjiženja preko objekta knjstb.jas da rade na način: 

•Konta prihoda (760111, 775330) potrebno je knjižiti nivo definiran u tablici lm_kat_stav.orgj 

•Ostala konta (120710,24000) potrebno je evidentirati na dosadašnji način (na nivo definiran u parametru 

DTVNE) 


Napravljena je izmjena knjiženja preko objekta knjstb.jas 

Sada se konta prihoda knjiže na nivo definiran u tablici lm_kat_stav.orgj 

Ostala konta (120710,24000) se evidentiraju na dosadašnji način (na nivo definiran u parametru DTVNE) 

Novi WIN FAUS će biti dostupan u utorak 23.04.2013 ujutro. 


Poštovani, 





0











Klijent: 





Hitnost: 

Vrlo hitno 


Glorija 


13308 



11.04.2013 07:22 

Upisao: 

Božo Mišeta 

Područje: 

LFINK 


12.04.2013 


Napraviti novu listu po uzoru na ”Popis otvorenih stavka” potvstav_jf za praćenje otvorenih stavaka evotv-a 

po dospijeću, listu nazvati “Popis otvorenih stavka za evo tv” 

1)Elementi zaglavlja ostaju s istim indikatorima kao i kod “Popisa otvorenih stavaka” , 

2)U prikazu prometa na novooformljenoj listi potrebno je kod dugovnog i potražnog prometa prikazivati i 

stavke koje nemaju laus broj. Ukoliko na dugovnoj ili potražnoj strani postoje stavke s laus brojem i bez 

laus broja, stavke se prikazuju odvojeno, (to je glavna razlika u odnosu na postojeći “Popis otvorenih 

stavaka” u kojem se ne prikazuju stavke bez laus broja” 

3) U stupcu "Originalni broj" staviti podatke iz opisa 

Pošto se pokazalo komplicirano dorada liste „Popis otvorenih stavka“ potvstav_jf za potrebe konta 120710, 

a da se ne poremeti dosadašnji način izvještavanja, dogovoreno je da se napravi nova lista „Popis 

otvorenih stavki za evotv“. Listu je potrebno napraviti po uzoru na 

Na postojeću listu potvstav_jf „Popis otvorenih stavki“ potrebno na ekran dodati filtar Bez Laus broja (D/N) 

– po defoltu bi bio N što bi značilo da se ne uzimaju stavke bez Laus broja, a ako se stavi D onda bi se 

uključile i te stavke. Bitno paziti da sadašnji način rada mora biti zadržan sa indikatorom N, a novi oblik sa 

indikatorom D. Pravilo se mora primijeniti na obje liste F6 i F7. Zahtjev hitan prioritet 1. 

Izrada liste nam je hitna. 



0









Poštovani, 

Promjene na potvstav_jf POPIS OTVORENIH STAVKI su napravljene i isporučene : 

Razrada stavaka N - radi kako je radilo ranije prije izmjena po zahtjevu HP13220 

Razrada stavaka D - radi kako je traženo po zahtjevu 13220 : 1 račun više stavaka (ovisno o knjiženim 

datumima dospijeća) 

Doraditi postojeću listu potvstav_jf sa opcijom Razrada stavaka D na način da se SVE stavke : 

2) prikazuju pojedinačno, uključivo i stavke bez laus broja 

3) U stupcu "Originalni broj" prikazuju podaci iz opisa knjiženja (arhivk.opis) a ne originalni broj računa 

(protokol.opis) 

zančilo bi napraviti još jednu listu knjigovdstvene kartice kakva već postoji . 

Predlažemo zatvaranje zahtjeva - neće se rješavati . 

Postojeće liste knjigovodstvenih kartica : 

arhpk_m_jf KNJIGOVODSTVENA KARTICA ili 

kar1_ff DEVIZNI IZNOS , VRSTA VALUTE I OPIS 

kar2_ff DATUM DOSPIJEĆA , NALOG I OPIS 

kar3_ff OPIS , NALOG I POZICIJA 

kar4_ff LISTA KARTICE PO ABECEDI 

kartica_ff LISTA KOMPLETNE KARTICE 

karps_ff KARTICA S PRETHODNIM STANJEM 

karpsn_ff KARTICA S PRETH.STANJEM PO NIVOIMA KNJIŽENJA 

karpsnhp_ff KARTICA S PRETH.STANJEM PO NIV. KNJIŽENJA HP 


Na objektu potvstav_jf dodan je novi indikator Bez Laus broja koji može imati vrijednosti D iili N (default). 

Ako je zadan indikator Razrad po stavakama D i Bez Laus broj D tada će na listama izlaziti stavke po dospijeću 

bez laus broja. 



Ispravljena je greška na objektu potvstav_jf kod listanja stavki na zadani datum dospijeća (od do). 




0









Poštovani, 

Izričito traženo : prikazati saldo minus dugovno kao potražni saldo . Razlog : saldo je uvijek pozitivan i u bilanci 

i kad se iskazuje saldo kartice i saldo prometa . 

Stavka sama po sebi može biti negativna (minusna ) . 

Tehnički/programski je lakše minus dugovno prikazat kao minus dugovno nego kao plus potražno ali smo 

napravili kako je IZRIČITO zahtijevalo knjigovodstvo / riznica . 

Kako promjenom programa tako da se saldo prometa prikazuje na jedan način a saldo kartice na drugi način 

ne bi stvorili nezadovoljstvo korisnika liste molimo pošaljite vaš konačan stav : Listu treba mijenjeti ili ne ? 

Status : čekamo stav HP 

------Napomene/pojašnjenja ---------------------------------- 

Saldo prometa čine stavke koje se dobiju po zadanim uvjetima za listu . 

Saldo kartice čine sve stavke na kartici neovisno ozadanim uvjetima za listu . 

Saldo prometa/kartice (za konta 12*) = Promet duguje - Promet potražuje = x . 

Ako je x>0 strana D , x











Klijent: 





Hitnost: 

Vrlo hitno 


Višnja 


13307 



09.04.2013 14:52 

Upisao: 

Božo Mišeta 

Područje: 

EPNAB 


15.04.2013 


Kroz ePlanNabave po spisu broj HP-10/2-007123/13 nije moguče poslati narudžbenicu broj 2/13 u LAUS: 

Kada korisnik pritisne Pošalji u LAUS ništa se ne odradi. Zašto? 



0









Poštovani, 

Otklonjena greška. Sada možete na spisu HP-10/2-007123/13 narudžbenicu broj 2/13 poslati u LAUS. Molimo 

potvrdu zatvaranja zahtjeva. 

Lp, 


Poštovani, 

Molimo da sad probate na spisu HP-10/2-007123/13 narudžbenicu broj 2/13 poslati u LAUS. 

Lijep pozdrav 

Mario Šemper 


Poštovani, 

Na spisu HP-10/2-007123/13 narudžbenicu broj 2/13 je poslana u LAUS. Molimo potvrdu zatvaranja zahtjeva. 

NApomena : 11.3.2013. nije vam greškom proslijeđen odgovor : 

Molimo da sad probate na spisu HP-10/2-007123/13 narudžbenica broj 2/13 poslati u LAUS 

pa smo se spojili na test i sami provjerili/poslali tu narudžbenicu u LAUS. 


Poštovani, 

Vezano za prigovor : 

Narudžbenica 2/13 po spisu HP-10/2-007123/13 kroz ePlanNabave na produkcijskoj bazi prebačena je u LAUS. 

Prebacivanje nije odradio nitko iz Ureda za javnu nabavu.Molimo da ubuduće sva statusiranja kroz ePlan na 

produkcijskoj bazi ne radi LAUS nego korisnik aplikacije, a sve obrade testirate na testnom ePlanuNabave. 

Nismo našli programsku zapreku nakon dorade te smo se htjeli uvjeriti zašto se konkretna narudžbenica ne 

može poslati u LAUS . 

Slanje u LAUS napravljeno je kroz aplikaciju - prošlo bez greške . 

Isprika zbog rada na produkcijskoj bazi bez prethodnog zahtjeva / suglasnosti HP-a - neće se ponoviti ubuduće. 




0









Poštovani, 

Molimo potvrdu zatvaranja zahtjeva. 

Lp, 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13306 



09.04.2013 13:17 

Upisao: 

Božo Mišeta 

Područje: 

LROBD 


10.04.2013 


Na dokumentu „Povrat robe dobavljaču“ prilikom pritiska na tipku F1-Upiši javlja se greška:“Datoteka nije 

JPL binarna datoteka..“. 


Ispravljen je unos povrata od dobavljača vrste dokumenta RPD. 

Potrebno je preuzeti nabd lib koji će biti na internetu 10.04.2013. 


Poštovani, 


- 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Glorija 


13305 



09.04.2013 10:05 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


16.04.2013 


Polje Način plaćanja je obavezno. Korisnik je uspis polje ne unijeti i račun likvidirati, bez upozorenja da 

mora unijeti Način plaćanja. 


Nadodana je kontrola da se kod unosa i izmjene fakture mora upisati način plaćanja. 

Instalacija: Novi WIN FAUS lib će biti dostupan u srijedu (10.04.2013) ujutro. 


Poštovani, 





0











Klijent: 





Hitnost: 

Vrlo hitno 


Glorija 


13304 



09.04.2013 09:52 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


16.04.2013 

Kod ispisa za neto cijene isključiti fakture tipa platni promet FAF i RUF. 



Kod ispisa za neto cijene (na objektu rucfak.jas) isključene su fakture tipa platni promet FAF i RUF. 



Poštovani, 





0











Klijent: 





Hitnost: 

Vrlo hitno 




13303 



08.04.2013 15:36 

Upisao: 

Boško Tokić 

Područje: 

LFINK 


20.04.2013 


Kod ispisa liste kartica.txt_ (objekt kartica_ff LISTA KOMPLETNE KARTICE) u excel dodati kolone šifru 

konta i naziv konta tako da se može pustiti i neka skupina (sada se može ali se ne vidi šta se odnosi na koji 

konto). 


Kod excel ispisa liste sa objekt kartica_ff LISTA KOMPLETNE KARTICE dodane su kolone šifre konta i naziv 

konta na početak liste, dok je filter podatak Konto i Naziv zadani na ekranu zadržan u zaglavlju liste. 



Poštovani, 





0











Klijent: 





Hitnost: 

Vrlo hitno 




13302 



08.04.2013 15:18 

Upisao: 

Boško Tokić 

Područje: 

LFINK 


10.04.2013 


Ulazne račune koji se evidentiraju i likvidraju u eObradi te prenose u Laus ubuduće treba evidentirati 

(dodijeliti laus broj) na orgj 46304 Sektor financija i računovodstva (do sada su se računi prenosili na orgj 

40013 Sektor računovodstva). 

Navedeno vrijedi za sve ulazne račune koji će se prenositi iz eObrade u Laus od trenutka rješavanja ovog 




0









Poštovani, 

Potrebno je evidentirati novi parametar EONER - EOBRADA NIVO EVIDENCIJE RAČUNA po uzoru na već 

postojeći parametar DTVNE u kojem će se nalaziti šifra organizacijske jedinice na koju će se evidentirati pristigli 

računi iz eObrade u LAUS. 

Progam za prijenos je prilagođen novom parametru. 



Molimo povratne informacije/ suglanost za zatvaranje zahtjeva - Riješen. 

NApomena : 

Paramtera je uveden kako bi se izbjegao hardcode tj. postigla fleksibilnost programa tako da kod slijedeće 

promjene nivoa evidencije računa iz eObradaRačuna treba samo ažurirati parametar EONER . Programske 

izmjene nisu potrebne 


Poštovani, 





0











Klijent: 



Pitanje 


Hitnost: 

Vrlo hitno 




13301 

Riješen 


08.04.2013 13:29 

Upisao: 

Boško Tokić 

Područje: 

LKEVP 


08.04.2013 


Prijenosom ERV-a u obračun plaće za 03/2013 za područje obračuna plaće PLUPR nije izvršen prijenos 

za radnika: 

40144 PERKOVIĆ SIMEONOV ŽELJKA 

Radniku su unesena evidencija radnog vremena za 03-2013, ali nije izvršen prijenos sati u unos primanja 

po obračunu plaće 03-2013. 

Molimo pojašnjenje. 


Poštovani, 

nismo ustanovili razlog greške, vjerojatno je netko greškom izbrisao unos primanja ovom radniku. 

Pregledali smo sve evidencije: rješenja, unos dodatnih primanja, ustroj orgj...Iste podatke ima i radnik 03705 koji 

također ima zatvoren menadžerski ugovor s 2013-02 kao i radnik 40144. 

Nakon neutvrđene bilo koje nepravilnosti u evidencijama ili programu, ponovo smo pustili prijenos kao korisnik 

AMIHOLY u 21:18 i svi podaci su uredno prebačeni. 

Napomena: Radnik 40144 treba imati i primanje I27 pa mu ih evidentirajte. 




0











Klijent: 





Hitnost: 

Vrlo hitno 




13300 



08.04.2013 11:29 

Upisao: 

Boško Tokić 

Područje: 

LNABD 


15.04.2013 


Kroz UGDul_jg UGOVOR S DOBAVLJAČEM potrebno je omogućiti unos originalnog broja ugovora u 

podatku ‘Ugovor’ u formatu strukture zapisa u bazi (40 znakova): 

boriginal char(40) 

Kako smo iz Ureda za javnu nabavu dobili zahtjev za proširivanjem orginalnog broj ugovora koji je vezan za 

donešenu odluku o utvrđivanju oznaka organizacijskih dijelova po kojoj više nisu u mogućnosti unositi takve 

oznake koje moraju pratiti brojeve spisa potrebno je izvršiti ekransko proširivanje formata upisa navedenog 

podatka. 


Na UGDul_jg UGOVOR SA DOBAVLJAČEM omogučen je unos originalnog broja UGOVORA odnosno polje 

borignal u tablicu protokol sa 40 znakova te ispih istog. 

Preuzmite nabd lib koji će biti na internetu 09.04.2013. 



0











Klijent: 





Hitnost: 





13299 

Poštovani, 

Za poslani zahtjev molim procijenu sati. 



08.04.2013 11:25 

Upisao: 

Boško Tokić 

Područje: 

LKROP 


30.04.2013 


30.04.2013 

Lijep pozdrav, Višnja Abija-Ivček, Odjel za implementaciju ERP rješenja 


Poštovani 

procjena za traženo izvješće je 1 radni dan,odnosno 8 sati. 

Pozdrav 


Napravljen je novi objekt rucni_jk Ručno unesena primanja koji prikazuje podatke iz unosa primanja koji su ručno 

uneseni (imaju indikator unosa = T). 

Sa pregleda se podaci mogu i ispisati.Objekt se nalazi na meniju ME1106 UNOS PRIMANJA - KONTROLNI 

PREGLEDI. 

Preuzmite: krop lib i objekt/meni-e (dostupno od 20/04/2013.) 



0











Klijent: 






Vrlo hitno 




13298 



08.04.2013 10:04 

Upisao: 

Boško Tokić 

Područje: 

LFINK 


Potrebno zahtjev hitno riješiti, jer ne može se raditi obračun kamata tj. program puca. 

Lp, Glorija Markovac, Odjel za implementaciju ERP rješenja 



0









Poštovani, 

Greška je ispravljena i novi LAUS FINK lib je prebačen na internet - možete odmah preuzeti verziju s ispravkom. 


Vezano za smanjen broj obračuna kamata u odnosu na 31.12.2012 . uzrok može biti : 

a) u 2012. godini knjiženo je na više pšifri partnera za jednog kupca a u 2013. knjiženje je svedeno na 1 šifru za 

kupca (NSC) pa je logična posljedica smanjen broj obračuna kamata 

b) ne znamo koji uvjeti su kod obračuna kamata ranije zadavani , ali ako je bio uvjet Minimalni iznos= 0 u ranijim 

obračunima a sad je 10 , logično je da je broj obračuna smanjen i zbog toga . Ukupna broj obrađenih kupaca 

(NSC) je 247 od čega : 

1 nema kamata (plaćeno u roku dospjeća ) 

241 ima kamate ispod Min.iznosa 10 kn 

5 ima kamate veće od 10 kn 

c) neki računi uopće nisu plaćeni pa kao takvi n isu niti zatvoreni te nisu obuhvaćeni obračunom jer se obračun 

radi na zatvorene stake . 

NAPOMENA : obračun kamata nije 'pukao' nego se greška javila nakon provedenog obračuna u trenutku kad su 

se trebali ispisati jer je pograšan naziv izvješća / reporta kam2_ff.rpt što je sad ispravljeno 

Ukoliko smatrate da se kamate nisu obračunale a trebale su za nekog kupca biti obračunate , molimo taj slučaj 

poslati na anlaizu s navedenom šifrom kupca , kontom i nivoom knjiženja . 


Poštovani, 

Na kontu 120000 analizirali smo slučajeve koje srte poslali koji nisu ušli u obračun 

Po evidenciji uplata P 617629 bi trebao imati obračun na 46307 , a nema 

Evo nekoliko analitika na nivou 11004 po kojima treba biti obračun kamata a nema ga, 600318,600725,600143 

Potrebno što hitnije omogućiti provedbu obračuna kamata 

slučaj 1 :nivo 46307 nema KIZ za P 617629 

****Razlog :uopće nema zatvorenih stavaka na ovoj analitici pa nema ni obračuna kamata 

Slučaj 2 : nivo 11004 nema KIZ za P 600318, 600725, 600143 

****Razlog : na zatvorene stavke kamate su ranije obračunate ili su negativne. Na otovrene stavke ne ide 

obračun . 

Napomena : 

Ako se radi o nekom drugom kontu a ne 120000 molimo pošaljite radi daljnje analize . 

Ako se iz gore navedenog ne može razjasniti zašto za neki račun kamate nisu obračunate , molimo pošaljite 

broj konkretnog računa i uplatu za njega na analizu. 

Obračun kamata ,, u odnosu na raniji način obračuna, uopće nije mijenjan nego samo ispis . 

Dakle, provedba obračuna je moguća kako je oduvijek i bila . 



0









Poštovani, 

Uočili ste nepravilnost za slučaj : : 

Kada se lista sa oznakom specifikacija D na kaml_ff (kampr_ff , F6 Ispis kam_l_ff opcija Pojedina ni ispis svih 

obra una na kam1_ff F6 Ispis ) suma je na ispisima po analitikama neispravna. U sluč aju da se lista 

obraÄčun na stari način, bez specifikacije suma je ispravna . 

Ispravljena je greška kod prikaza ukupnog iznosa kamata za listu obračuna kamata po specifikaciji D. 



Molimo povratne informacije / suglasnost za zatvaranje zahtjeva Riješen 

obzirom na poslana pojašnjenja u prethodnoj obradi i ispravk nepravilnosti kod ispisa 


Poštovani, 

Za najnovije poslan slučaj na analizu : 

konto 120000, nivo 11004 , analitika P 627801 

ne može se dalje analizirati jer poslani uvjeti na kamob_ff NORMALNI OBRAČUN - POJEDINAČNO 

nemaju uvjeta za Minimalni iznos 

kao što ima na kamsve_ff NORMALNI OBRAČUN - SVI KUPCI 

NAPOMENA: ako su obračunate kamate manje od minimalnog iznosa zadanag prije obračuna , onda se 

obračun izvršia li se ne ne upiše niti ažurira oznaka da je obračun uopće rađen 

Prijedlog : 

pustite obračun za P627801 na kamob_ff NORMALNI OBRAČUN - POJEDINAČNO sa uvjetima koje ste 

nam poslali pa se uvjerite je li iznos kamata manji od zadanog kao uvjet u Minimalni iznos kad ste puštali 

kamsve_ff NORMALNI OBRAČUN - SVI KUPCI 

ili 

pošaljite radi daljnje analize slučaja : 

a) uvjet za Minimalni iznos kod puštanja kamsve_ff NORMALNI OBRAČUN - SVI KUPCI 

b) suglasnost da na produkcijskoj bazi mi pustimo obračun za P627801 na kamob_ff NORMALNI 

OBRAČUN - POJEDINAČNO 



0











Klijent: 





fiskalizacija platni 

Hitnost: 

Vrlo hitno 


glorija 


13297 

Hitan zahtjev : provjera neispravne fiskalizacije. 

Ispravljene su fakture jer su morale ići kupcu. 



05.04.2013 17:06 

Upisao: 

Dajana Lekić 

Područje: 

LWINFAU 


08.04.2013 


08.04.2013 

Kod navedenog objekta ( u prilogu generiranje ožujak.docx : fakplN_fas Fakturiranje platnog prometa ) dio 

faktura se nije fiskalizirao (u prilogu). 

Polje fisk_nacpla nije se napunio sa T. Ostale fakture sa svim istim uvjetima su se normalno fiskalizirale. 

Prilozi: nema_napunjen_nacin_placanja.docx 



0









Poštovani, 

Molimo , radi daljnje analize, pošaljite ekran sa popunjenim SVIM potrebnim uvjetima ili odgovorite na pitanje : 

P1. dolje navedeno su uvjeti koji su bili zadani - pretpostavljam po podacima za račun 3536601300577 i 

vezani ugovor 35366R1100064 ? 

orgj 35366 

datum_dvo 31/03/2013 

datum_fak 05/04/2013 

datum_pla 15/04/2013 

datum_ood 01/03/2013 

datum_odo 31/03/2013 

placanje_rok 10 

placanje_tip K 

razina HP 

vr_usluga PLO 

Također, naknadnom analizom programa utvrđeno je da kod upisa u lm_usl_fak za uslugu TK prijenosa 

nedostaje upis fisk_nacpla=T -- ispravlja se . 

( provjereno : navedene fakture sadrže baš tu uslugu za TK prijenos :43191 

MOGUĆE JE , kao što smo i naglasili u obradama zahtjeva 13289, da se računi ne fiskaliziraju iz razloga što 

se i fakturiranje i fiskalizacija rade u jednoj transakciji a tablice za fiskalizaciju nisu bile dostupne . 

Ova mogućnost će se eliminirati kad se izmjeni fiskalizacija tj. ne bude u istoj transakciji kao i generiranje 

fakture (pitanja vezana uz to poslana danas kroz obradu zahtjeva HP 13289 , KZ 42270 ) 


Poštovani, 

Ispravljeno je automatsko generiranje faktura platnog prometa. Sada se i kod tk usluga puni fisk_nacpla (T) u 

tablici lm_usl_fak i provodi pravovremena fiskalizacija 


Instalacija: novi WIN FAUS lib će biti dostupan u utorak (09.04.2013) ujutro. 



Poštovani, 





0











Klijent: 





pri_ftr 


Vrlo hitno 




13296 



05.04.2013 13:29 

Upisao: 

Boško Tokić 

Područje: 

LCSBI 

Bok Damir, 

Vidim da si si ti superadmin na SAP portalu za nase proizvode i za nas account. 

Mozes li dodati marin.junusic@posta.hr zajedno sa mnom u grupu ? 



Dobili smo povratnu informaciju da će SAP otvoriti dva nova usera na koje će prenijeti ovlasti s usera Damira 

Konjevoda, a kojega će deaktivirati. 


Poštovani, 

dobili smo povratnu informaciju. Superadmin prava su riješena 

Both users have were changed and have superadmin rights. 

For Marin Junusic the credentials are: S0010707154 and Password: LWOY1LAQ 

For Goran Jaksic – please let me know if a password change is required. 

For Damir Konjevod I have removed all rights and authorizations. 





0











Klijent: 





ERV 


Vrlo hitno 




13295 

Riješen 


05.04.2013 13:11 

Upisao: 

Boško Tokić 

Područje: 

LKEVP 


Prijenosom ERV-a u obračun plaće za 03/2013 pogrešan je prijenos za radnike koji su 

djelatnici Sortirnice, a radili su na blagdan (Uskrs) i upravo su ti sati u višku.: 

(prilog) 


Poštovani, 

ispravljena je greška koja se dogodi kada je u pitanju blagdan (bilo koji) na zadnji dan u mjesecu. Ne bi se 

oduzeli sati blagdana od primanja A00 za radnike koji su radili na blagdan, pa su radnici ostali s većim fondom 

sati. 

Verzija je dostupna od 07/04/2013. 




0











Klijent: 






Vrlo hitno 




13294 

Zahtjev potrebno hitno riješiti. I dalje POS nije ispravan. 



05.04.2013 10:13 

Upisao: 

Boško Tokić 

Područje: 

LFINK 





0









Poštovani, 

Sve promjene na potvstav_jf POPIS OTVORENIH STAVKI napravili smo prema zahtjevu 13220 

Molimo odgovore na pitanja kako bi riješili zahtjev : 

P1: Listu na potvstav_jf vraćamo na staro tj. kako je bila prije zahtjeva 13220 ? 

P2: Za evo TV radi se nova lista (objekt) koja je zapravo po izgledu i sadržaju kao ova sad na potvstav_jf samo 

što treba dodati : 

ako je zavdano P bez šifre lista samo partnere ,a ako je zadano A da lista samo ostale analitike ? 

Status : Čekamo odgovre na P1 i P2 

NAPOMENA: 

Poučeni iskustvom i različitim potrebama za izgledom i sadržajem listi koje trebaju za EVO TV u odnosu na 

ostale , 

molimo NEMOJTE INZISTIRATIda se izmjene rade na postojećim objektima nego oblikujte zahtjeve na način : 

po uzoru postojeću na listu x napravit novu uvažavajući potrebe da se to i to prikaže na drugačiji način . 

-----------------Komentari i pojašnjenja ---------- 

HP :Nažalost opet nije dobar POS, sada se uplata prikazuje pojedinačno, a ne pripoji se fakturi, trebalo bi biti u 

jednom redu kako je bilo i prije, sada je u dva reda, posebno uplata posebno faktura, 

molim Vas što hitnije ispravak navedenog jer nam je POS kao lista potrebna u obavljanju svakodnevnih radnih 

zadataka. 

---- traženo prikazivanje u više redova po dospjeću po zahtjevu 13220 . Gdje prikazati uplatu tj. u kojem redu 

treba biti? stavili poseban red 

HP :Isto tako sada se ne može pustiti POS za sve partnere, jer ako se stavi oznaka P traži se šifru, a ako se ne 

stavi ništa tj. prazno polje kao prije, 

sada vrti i ostalu analitiku koja je nadodana za potrebe evo tv, što nije potrebno u određenim slučajevima. 

Znači filter je potrebno omogućiti i na vrstu analitike. 

--- traženo je da se omogući i za ostale analitike.Propust je da ako je zavdano P bez šifre lista samo partnere,a 

A da lista samo ostale analitike 

HP: Možda bi bilo najbolje da se kreira posebna lista za potrebe evo tv, o ono prije ostavi kako je bilo ukoliko 

niste u mogućnosti podržati na jednoj listi obje mogućnosti. 

-- rješenje je posbna lista za evo TV jer se za evo TV traži prikaz na 1 način ,a za ostalo na drugi način : ISTU 

listu na 2 načina niko još nije napravio. 

---------------------------------- 

Prema zahtjevu 13220 i primjedbama nakon isporuke traženo je : 

13220 :objekt : potvstav_jf POPIS OTVORENIH STAVKI 

Liste ne rade dobro za vrstu analitike A i konto 120710, jer se na kontu 120710 jedan te isti Laus broj dokumenta 

razbija po dospijeću. 

1. Ne povlači se ispravan naziv šifre analitike 

2. Laus broj dokumenta 46300-012-00047 razbijen po dospijeću, a lista IOS-a povukao je po dugovni promet 

istavke koje još nisu u dospijeću 

Obrada 2 iz zahtjeva 13220 : 

Molim hitno otklanjanje greške iz priloga vezano na zahtjev 13220. 

Primjedbe i greške: 

1) Kod vrste analitike A u koloni OIB ne ispisuje se OIB 

2) Jedan te isti laus broj ima različite datume dospijeća, u popisu otvorenih stavki stavke koje su u dospijeću 

spoji u jednu te istu stavku, što nije dobro jer su različiti datumi dospijeća 

jedan te isti laus broj treba prikazati zasebno jer se radi o različitim ratama i o različitim datumima dopsijeća 

(različiti broj dana kašnjenja) 

3) prikazivati cijeli opis, tako da se vidi broj rate 



0







Obrada 3 -završen, : Isporučen - Korisnik potvrdio ispravnost 

1. Omogućen je ispis OIB-a za vrstu analitike A 

2. Za jedan dokument omogućen je ispis onoliko stavaka koliko ima različitih datuma dospijeća dokument u 

stavaka (arhivk). 

3. Proširen opis 

----------------------------------------------------- 


Poštovanje, 

Na Vaš zahtjev 13220, obašnjeno je kako se lista otvorenih stavaka za EvoTV ne može dobiti na standardnom 

ispisu otvorenih stavaka. Kako je ipak inzistirano, napravljena je takva dorada. 

Sada je zaključak da listiu vraćamo na prethodnu verziju i radimo posebnu listu koja je zapravo po izgledu i 

sadržaju identična listi na objektupotvstav_jf uz slijedeće izmjene: 

ako je zadano P bez šifre lista samo partnere ,a ako je zadano A da lista samo ostale analitike 

Zbog navedenog ovaj zahtjev smatram adaptvnim održavanjem. 

Plan je zahtjev isporučiti tijekom sutrašnjeg dana 9.4.2012. 




Poštovani, 

Na objektu potvstav_jf dodan je indikator Razrada stavaka za razradu po datumu dospijeća iz stavka (arhivk). 

Ako je indikator postavljen na D onda će lista ići po dospijeću iz stavaka, a ako je postavljen na N onda lista ide 

po dospijeću iz zaglavlja (kako je radilo do sada prije izmjena po zahtjevu HP 13220 ). 

Omogućeno je listanje stavaka po vrsti analitike bez upisa konkretne šifre analitike. 

Ako se ne zada vrsta onda lista ide za sve analitike bez obzira na vrstu. 

Napomena: ako se zada filter vrste analitke P bez šifre onda se ne može uvažavati filter Hijerarhija za koju je 

potrebnu unijeti konkretnu šifru analitike. 





Poštovani, 





0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13293 



04.04.2013 13:24 

Upisao: 

Božo Mišeta 

Područje: 

EHPUR 


08.04.2013 


Prilikom spajanja na testnu eHPUR aplikaciju za administraciju korisničkih podataka (link na koji se 

spajamo:http://sv-1ot-eaptest.posta.int/eHPUR_Admin_Test/login.aspx?ReturnUrl=% 

2feHPUR_Admin_Test%2fdefault.aspx) javlja se slijedeća greška: vidi prilog 


Poštovani, 

Vaš zahtjev je riješen. 

Ukoliko možete pristupiti aplikaciji, predlažemo zatvaranje zahtjeva jer se radi o zahvatu na testnoj aplikaciji. 




0











Klijent: 





Hitnost: 



Katja 


Poštovani! 

13292 



04.04.2013 12:13 

Upisao: 

Božo Mišeta 

Područje: 

LTRAN 

U prilogu šaljem zahtjev sa istim problemom kao kod zahtjeva 

42193/1-originalni broj: [13274]- riješen 


08.04.2013 


Povrat robe broj 299/2013 od 13.03.2013 nije vidljiv u aplikaciji Laus. Naime u aplikaciji „MIPS“ prema 

izjavi kolegice sve je uredno proknjiženo, ali se u aplikaciji „LAUS“ dokument ne vidi odnosno nije generiran 

u e-Povrat ( ME1225 - RPMul_jd POVRATNICA IZ MALOPRODAJE – ekran RPMzg_fd U). Nedugo smo 

imali isti slučaj sa dokumentom 254/2013 koji je riješen uspješno. 

Molim da nam javite zašto se ovaj problem počeo ponavljati? 



0









Poštovani, 

Molimo suglasnost za zatbaranje zahtjeva - Riješen . 

Slijedi pojašnjenje vezano za situacije s prijenosom povrata mips-->laus . 

Dokument se nije uredno upisao u Laus zato što je prilikom preuzimanja dokumenta integracijskim servisom 

pukla veza na bazu eObradaRacuna . Dokument je u mips bazu upisan 2013-03-13 12:39:52 i odmah po upisu 

(u roku nekoliko sekundi) ulazi u prijenos. 

Međutim, upravo u vrijeme prijenosa je došlo do prekida rada integracijskog servisa i dokument se nije stigao 

upisati u Laus. 

Do greške ne dolazi zbog greške u integracijskom servisu nego zbog privremene nedostupnosti baze. 

Integracijski servis je jedan za prijenose između svih baza i radi na način ukoliko je jedna od baza uključenih u 

servis nedostupna, sevis se gasi tj. prestaje raditi sve prijenose, bez obzira na to što u ovom konkretnom 

slučaju baza eObradaRačuna nije povezana sa prijenosom povrata nego se isti odvija između laus i mips baze . 


Poštovani, 



NAPOMENA iz zadnje obrade : 







0











Klijent: 





toška 8 OS adaptivno 

Hitnost: 

Vrlo hitno 


visnja 


12603 



03.04.2013 16:10 

Upisao: 

Dajana Lekić 

Područje: 

EPNAB 


08.04.2013 

Točka 8 (adaptivni doio vrzan za OS) rješava se kroz ovakj KZ . 

Procjena 6 sati za rješavanje već poslana u HP 




0









Poštovani, 

Točka 8 zahtjeva 12603 (adaptivni doio vrzan za OS) rješava se kroz ovakj KZ . 

Procjena 6 sati za rješavanje već poslana u HP 


Poštovani, 

Dorade vezane za okvirne sporazume su prebačene na testni server. 

NAPOMENA: 

Broj, naziv, ponuditelj i evidencijska oznaka s okvirnog sporazuma se povlače na ugovor i narudžbenicu odmah 

pri otvaranja forme ugovora ili narudžbenice i moguće ih je editirati. 

Članovi zajednice i Podizvođači/Podisporučitelji se povlače s okvirnog sporazuma nakon akcije Spremi i moguće 

ih je editirati. Akciju spremi je ionako potrebno izvesti zbog dodavanja troškovnika. 

Lp, 


Poštovani , 

Dorade vezane za točku 8. Okvirni sporazumi navedene u ovom zahtjevu prbačene su na testni server 

22.4.2013. 



Poštovani, 

Dorade vezane za okvirne sporazume su prebačene na produkciju 

Broj, naziv, ponuditelj i evidencijska oznaka s okvirnog sporazuma se povlače na ugovor i narudžbenicu odmah 

pri otvaranja forme ugovora ili narudžbenice i moguće ih je editirati. 

Članovi zajednice i Podizvođači/Podisporučitelji se povlače s okvirnog sporazuma nakon akcije Spremi i moguće 

ih je editirati. Akciju spremi je ionako potrebno izvesti zbog dodavanja troškovnika. 

HP br.zahtjeva Laus CC broj zahtjeva 

12603 Točka 8 Adaptivno KZ 42287 


Ostale neriješene točke HP12603 1,9, 17 i 18 rješavaju se u drugom KZ 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Ivan 


13291 



03.04.2013 13:47 

Upisao: 

Božo Mišeta 

Područje: 

LTRAN 


05.04.2013 


Potrebno je doraditi objekt za prijenos prometa iz MIPSa (pri_ftr PRIJENOS PROMETA - MIPS / LAUS) 

za novi način preuzimanja podataka o zonama na slijedeći način: 

Podatak o zonama čitati iz tablice prom_pos_nov:zonacje. Moguće vrijednosti: 

•1, 2 ili 3 – to ujedno označava pismovnu zonu, 

•0 ili prazno (ostale vrijednosti) – radi se o stavkama prijamne knjige bez zone. 

U slučaju da je vrijednost polja zonacje 1,2, ili 3 taj podatak potrebno je puniti u LAUS u tablicu lm_nalog na 

način: 

•U polje tocpris puniti podatak 'Z' 

•U polje razrpos preslikati podatak iz polja zonacje. 

Podatak o zonama više se treba čitati iz tablice racun_zaj. 

Ovo sve vrijedi samo za zone (racun_zaj razrpos='1, 2,3', tocpris='Z') dok za ostale varijante (točke pristupa 

i sl.) sve ostaje kao do sada. 



0









Napravljene su dorade na objektu za prijenos prometa iz MIPSa (pri_ftr PRIJENOS PROMETA - MIPS / LAUS). 

Podatak o zonama se sada preuzima iz tablice prom_pos_nov (polje zonacje). 

U slučaju da je vrijednost polja zonacje 1,2, ili 3 taj podatak se puni u LAUS u tablicu lm_nalog na način: 

- u polje tocpris se puni podatak 'Z' 

- u polje razrpos se preslikava podatak iz polja zonacje. 

Greška 97 sada kontrolira da polje tocpris ako je zadano mora biti 1,2 ili D. 

Greška 96 kontrolira da razrpos ako je zadano mora biti D ili N. 

Preuzmite LAUS TRAN lib koji je već na internetu. 


Poštovani, 

Zahtjev je na popisu neriješenih zahtjeva koji je poslan kao prilog zapisniku sa sastanka IT-LAUS 

10.06.2013.g. 

Nismo dobili primjedbe nakon zadnje obrade zahtjeva 8.4.2013. : 

Napravljene su dorade na objektu za prijenos prometa. 


Trenutni status : čekamo stav HP 


Poštovani, 

po vašem nalogu zatvaramo zahtjev, 

s štovanjem 

Već sam poslao da se ovo može zatvoriti 

Ivan poldrugač 



0











Klijent: 





Hitnost: 



Glorija 


13290 



03.04.2013 13:43 

Upisao: 

Božo Mišeta 

Područje: 

LSLOD 


10.04.2013 


19.04.2013 

Kod službene odjeće na objektu - Dokumenti slod_ji za zapisnik TRA, kao što ima iza dokument TZD, 

omogućiti kod ispisa tekst Napomene. 


Kod službene odjeće na objektu - Dokumenti slod_ji za zapisnik TRA na ispisu se sada prikazuje i napomena. 

Preuzmite LAUS SLOD lib koji će biti dostupan u utorak (09.04.2013) ujutro. 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Glorija 


13289 



03.04.2013 12:37 

Upisao: 

Božo Mišeta 

Područje: 

LBASE 


03.04.2013 


Kontrolom formiranja fiskalnog broja uočeno je da se ne prati slijednost brojeva (datoteka u prilogu). 

Neispravni brojevi se nalaze na prodajnim mjestima koja imaju način plaćanja T i nisu otišli prema poreznoj 

kao i oni sa G koji su otišli prema poreznoj (51000, 21210). Veliki broj prodajnih mjesta ima neispravno 

formirane brojeve tj. brojač preskače po čitave tisuće brojeva. Potrebno programe kod formiranja fiskalnog 

broja ispraviti da rade ispravno, a za podatke koji su sada u bazi neispravni i koji podliježu reviziji i koji su 

poslani u poreznu tražimo hitni prijedlog rješenja problema. 



0









Poštovani, 

Fiskalni broj smo punili kroz bazu i bilo je ok (zahtjev 13079 - upis u prot_fisk - nacpla=T ) 

Pronašli smo grešku kod fiskalizacije računa kod fakturiranja (upis u prot_fisk - nacpla=T ) - ispravlja se . 

Za ostale načine plaćanja fiskalizacija radi ispravno : na razini poslovnog prostora dodjeljuje se slijedeći redni 

broj računa 

Pitanje 1 : 

što napraviti sa računima koji imaju neslijedni fiskalni broj ? 

Jesu li pošli van HP tj. smije li se mijenjati taj fiskalni broj ? 

Pitanje se odnosi na račune sa fisk_nacpla= T . Goovinski se ne smiju mijenjati . 

Pitanje 2 : 

Nakon što se isporuči automatska fiskalizacija do kraja ovog tjedna ( HP 13199 ) 

predlažemo : ukinuti fiskalizaciju prilikom fakturiranja jer se pokazala nepraktičnom. 

Slažete li se s prijedlogom ? 


Pitanje 1 : 

što napraviti sa računima koji imaju neslijedni fiskalni broj ? U zahtjevu smo tražili vaše mišljenje i prijedlog 

rješenja tog problema. Kako su računi s fiskalnim brojevima isporučeni kupcima, ne smatram da postoji druga 

opcija osim da ostavimo trenutno stanje, s dostavljenom vašom izjavom kako je do 'rupa' u brojevima došlo zbog 

programske greške, ali to još treba ostaviti za raspravu i dogovoriti konačno rješenje u suradnji sa Sektorom 

računovodstva. 

Jesu li pošli van HP tj. smije li se mijenjati taj fiskalni broj ? Kao što sam napisala, računi su isporučeni kupcima. 

Pitanje se odnosi na račune sa fisk_nacpla= T . Goovinski se ne smiju mijenjati . 

Pitanje 2 : 

Nakon što se isporuči automatska fiskalizacija do kraja ovog tjedna ( HP 13199 ) predlažemo : ukinuti 

fiskalizaciju prilikom fakturiranja jer se pokazala nepraktičnom. Do greške je došlo zbog neispravnog generiranja 

brojeva (ili zbog nečeg drugog!?), te molim da se to hitno riješi jer se sutra kreće s masovnim generiranjem 

faktura koje mogu dovesti do daljnih rupa, a što želimo u potpunosti izbjeći. 

Slažete li se s prijedlogom ? Ne razumijem prijedlog, pa molim pojašnjenje. Svaki račun mora dobiti fiskalni broj i 

ne vidim kako to drugačije riješiti. 

Renata Basrek 



0









Pozdrav Renata, 

Utvrđena je greška kod generiranja fiskalnih brojeva na programu za fakturiranje. Greška je ispravljena i lib je od 

jutro rasoloživ za preuzimanje na support web site-u. 

Do greške je došlo i zbog neispravnog generiranja brojeva ( max broj dodjeljivan na razini prot_fisk tablice bez 

uvažavanja poslovnog prostora ) i zbog nepraktičnosti provođenja fiskalizacije prilikom fakturiranja jer se radi o 

masovnim obradama i kod fakturiranja i kod fiskalizacije ( tablice nedostupne , zaključane ,..) 

Do kraja tjedna će se isporučiti i program za masovnu fiskalizaciju nefiskaliziranih računa. 

Prjedlog je izmijeniti i program za fakturiranje na slijedeći način, pa te molim potvrdu prijedloga: 

Fisaklizaciju računa/ faktura sa načinom plaćanja T raditi naknadno a ne unutar fakturiranja .Svaki će račun 

dobiti fiskalni broj ali ne kroz fakturiranje nego automatskom masovnom fiskalizacijom, koja se pokreće 

automatski nakon što su fakture kreirane. 

Kod pojedinačnih faktura to već radi na opisaninačin, ali kod masovog fakturiranja se gore opisani proces odvija 

u jednom koraku, koji b sada razdvojili u dva koraka. Korisnici neće primjetiti promjenu u sučelju i načinu 

korištenja programa za masovno fakturiranje. 

LP 




0









Molimo odgovre na pitanja i povratne informacije vezano za fiskalne brojeve nakon ispravke greške : 

Utvrđena, ispravljena i 4.4.2013. ispravljena je greška kod dodjele fiskalnog broja za račune sa nčinom plaćanja 

T-transakcijski račun prilokom masovnog fakturiranja . 

1-- Usuglašeno je dosad ovo : 

Fisaklizaciju računa/ faktura sa načinom plaćanja T raditi naknadno a ne unutar fakturiranja u jednom koraku : 

napravi se faktura i fiskalizira u istoj transakciji pa se onda radi slijedeća na isti način sve dok se ne odradi za 

sve 

Dakle, treba zamaskirati dio programa kod masovnih fakturiranja koji se odnosi na fiskalizaciju u istoj transakciju 

s generiranjem fakture 

2-- Potrebno usuglasiti : 

Svaki će račun dobiti fiskalni broj na način automatskom masovnom fiskalizacijom, koja se pokreće : 

a) automatski nakon što su fakture kreirane pa treba razdvojili u dva koraka fakturiranje i fiskalizaciju . 

Korisnici neće primjetiti promjenu u sučelju i načinu korištenja programa za masovno fakturiranje. 

Znači, fakturiranje ide kao proces posebno a nakon njega se pokreće druga procedura s dodjelom fisklnih 

brojeva – naravno bez ikakve intervencije korisnika. 

Ako se procedura dodjele fiskalnog broja ne može izvršiti pokrenut će se naknadno preko programa za masovnu 

fiskalizaciju nefiskaliziranih računa (HP zahtjev 13199 :fiskm.jas ) 

b) fiskalizacija se uopće ne radi unutar fakturiranja nego se nagon završetka fakturiranja radi masovana 

fiskalizacija faktura SAMO preko : 

fiskm.jas MASOVNA FISKALIZACIJA TRANSAKCIJSKIH RAČUNA 

Molimo odgovore na pitanja : 

P1. Na koji način a) ili b) treba programom podržati masovnu fiskalizaciju ? 

P2. Kad treba biti isporučena ta programska podrška obzirom da je fakturiranje u tijeku a novi program : 

fiskm.jas MASOVNA FISKALIZACIJA TRANSAKCIJSKIH RAČUNA(danas završeno) 

može biti na internetu tek 8.4.2013. netestiran s Vaše strane ? 

P3. Može se otvoriti novi KZ sa istim HP brojem 13289 , područje WinFaus za rješit pod 1 i 2 navedeno ili ćete 

slati novi zahtjev ? 



0









Poštovani, 


Utvrđena, ispravljena greška i 4.4.2013. isporučen ispravak greške kod dodjele fiskalnog broja za račune sa 

nčinom plaćanja T-transakcijski račun prilokom masovnog fakturiranja . 

Na sastanku dana 15.4.2013 dogovreno je : 

Fisaklizaciju računa/ faktura sa načinom plaćanja T radi se unutar fakturiranja u jednom koraku (kao i dosad) : 

napravi se faktura i fiskalizira u istoj transakciji pa se onda radi slijedeća na isti način sve dok se ne odradi za 

sve 

Razlog : dio programa kod masovnih fakturiranja koji se odnosi na fiskalizaciju u istoj transakciju s generiranjem 

fakture na zadnjem fakturiranju se dobro odradio : pravilna dodjela fisklanog broja. Nije bilo nefiskaliziranih koji 

se generiraju masovnim fakturiranjem ( samo 1 RUF - pojedinačna fiskalizacija ) 

Nema zasad potrebe razdvajati u dva koraka fakturiranje i fiskalizaciju . 

Ako se procedura dodjele fiskalnog broja ne izvrši , pokrenut će se naknadno preko programa za masovnu 

fiskalizaciju nefiskaliziranih računa 

(HP zahtjev 13199 :fiskm.jas ) 


Poštovani, 

Zahtjev zatvaramo uz vašu suglasnost- Riješen 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Glorija 


13288 



03.04.2013 08:57 

Upisao: 

Božo Mišeta 

Područje: 

LFINK 


04.04.2013 


U prilogu dostavljamo POS i IOS za jednog p.p. iz kojih je vidljivo da sada POS ne radi ispravno nakon 

isporučenih dorada na toj listi vezanih uz evotv . 

Molimo što hitniji ispravak NAVEDENOG. 

Greška je u tome da se ne prikazuje uplate povezane na laus broj fakture: 

Evo primjera: 

•FA 11009-012-05999 IMA UPLATE U IZNOSU OD 16.000,35 KN KOJE NA POS-u NISU PRIKAZANE 

•TAKOĐER I FA BROJ 11009-012-07472 NEMA ISKAZANU UPLATU U IZNOSU OD 12.476,39 KN 


Poštovani, 

Omogućen je prikaz uplata koje se nisu prikazivale na listi sa objekta potvstav_jf. 


Obavijestiti korisnika o preuzimanju novog LAUS FINK liba u četvrtak 4.4.2013. 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Glorija 


13287 



03.04.2013 07:27 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


02.04.2013 


03.04.2013 

Kod likvidiranja (izmjena statusa 2 u 3) javlja se dolje navedena kontrola. Potrebno je kontrolu prevesti u 

poruku: U stavkama fakture A postoji datum prometa za koji ugovor B ne vrijedi, Želite li likvidirati račun 

(d/n)? Ako se izabere d, onda provesti likvidiranje i fiskalizaciju po standardnim pravilima 


Poštovani, 

Na objektu za ručni unos faktura (rucfak.jas) promjenjena je poruka koja se javljala kod likvidiranja (izmjena 

statusa 2 u 3). 


Instalacija: U ponedjeljak 08.04.2013 će biti dostupan novi WIN FAUS lib. 



Poštovani, 





0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13286 



02.04.2013 11:28 

Upisao: 

Božo Mišeta 

Područje: 

WINTRAN 


05.04.2013 


Prilikom generiranja obračuna komisijske robe, korisnicima se često javlja poruka:” greška 243…”. 

Kako im se odmah ne bi javila ova poruka, molim da postavite wait mode na 120 sec. 


Prilikom generiranja obračuna komisone robe kom_obr.trn postavlje je lock wait 120 zbog učestalih zaklučavnja 

tablica odnosno 243 greške. 



Poštovani, 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Višnja 


13285 



02.04.2013 09:32 

Upisao: 

Božo Mišeta 

Područje: 

EPNAB 


04.04.2013 


U Registru ugovora potrebno je kroz ePlanNabave promijeniti broj ugovora bagatelne nabave HP-10/2- 

005226/3 u broj HP-10/2-005226/13 


Poštovani, 

U Registru ugovora promijenjen je broj ugovora bagatelne nabave HP-10/2-005226/3 u broj HP-10/2-005226/13. 


Lp, 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13284 



02.04.2013 07:09 

Upisao: 

Božo Mišeta 

Područje: 

EHPUR 


05.04.2013 


U transakciji T80 postoji polje je „Urudžbeni broj/Broj podneska“ te je zamišljeno da pretražuje urudžbeni 

broj i broj podneska (slika u prilogu). 

Trenutno se može pretraživati samo po urudžbenom broju ali ne i po broju podneska.Molim Vas da 

omogućite pretraživanje I po broju podneska. 



0









Poštovani, 




Poštovani, 

Molim pristup danas 24.04.2013. poslije 16.00 sati kako bismo prebacili zahtjeve: 13284, 13270 i 13196 na 

produkciju. 

Pristupati će Vjeran Livaić. 

Lp, 


Poštovani, 

Vaš zahtjev je prebačen na produkciju. 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja Kraljev 


13283 



29.03.2013 11:01 

Upisao: 

Boško Tokić 

Područje: 

LROBD 


08.04.2013 


Na ekranu RPD - Povrat dobavljaču (RPDzg_fd) prilikom unosa šifre dobavljača napraviti kontrolu kao i na 

RPP - Primci od dobavljača da se unosi isključivo krovna šifra dobavljača. 


Na dokument RPD Povrat od dobavljača omogučen je unos samo krovne šifre dobavljača. 



Poštovani, 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja Kraljev 


13282 



29.03.2013 10:31 

Upisao: 

Boško Tokić 

Područje: 

LROBD 


08.04.2013 


Na ekranu ROBNO KNJIŽENJE DOKUMENATA (prdk_fd) dodati filter korisničke šifre „URADIO“ i knjižiti 

dokumente koji pripadaju toj korisničkoj šifri. 


Na ekranu ROBNO KNJIŽENJE DOKUMENATA (prdk_fd) dodan jei filter korisničke šifre uradio, te omogućeno 

knjižiti dokumente koji pripadaju toj korisničkoj šifri. 

Preuzmite laus libove: rob0,rob1,rob2,rob3 irob4 koji će biti na internetu 06.04.2013. 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja Kraljev 


13281 



29.03.2013 10:29 

Upisao: 

Boško Tokić 

Područje: 

LROBD 


08.04.2013 


Na ekranu MASOVNI ISPIS DOKUMENATA (mid_fd) dodati filter i omogućiti unos korisničke šifre 

„URADIO“ koja je vezana uz dokumente. 


Na masovnom ispisu dokumenta mid_jd dodano je filter polje uradio kako bi se mogli ispisati samo dokumenti 

kojima je taj isti korisnik napavio zadnju izmjenu na dokumentu. 

Potrebno je preuzeti laus libove rob0,rob1,rob2,rob3 irob4 koji su na internetu 05.04.2013. 


Poštovani, 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja Kraljev 


13280 



29.03.2013 10:25 

Upisao: 

Boško Tokić 

Područje: 

LROBD 


08.04.2013 


Na ekranu Zahtjevnica skladištu (ZAHzg_ fd) omogućiti funkcijskom tipkom F3 MASOVNO 

GENERIRANJE RIM-ova, te nakon pritiska na tipku omogućiti filter OD DATUMA DO DATUMA za 

skladište. Također dodati filter „GRUPE PODRUČJA“ sa poštanskim uredima te grupe područja. 


Omogučeno je masovno generiranje izdatnica RIM-a iz zahtjevnice ZAH preko funkcijske tipke F3(GEN-RIM) na 

pregledu dokumenata ZAH na ekranu ZAHpd_pr_fg za dokumente koje se ispišu na tom istom pregledu. 

Korisničke upute u prilogu obrade dostaviti krajnjem korisniku. 

Potrebno je preuzeti laus libove rob0,rob1,rob2,rob3 i rob4 koji su bili na internetu 12.04.2013. 


Poštovani, 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja Kraljev 


13279 



29.03.2013 10:18 

Upisao: 

Boško Tokić 

Područje: 

LROBD 


05.04.2013 


Na ekranu Pregled dokumenata (ZAH pd_pr_fd) omogučiti po pretpostavljenom oznaku „O“ prije filtera 

organizacijske jedinice i da se omogući unos šifre grupe područja, te da se na pregledu dobiju svi poštanski 

uredi od te šifre grupe područja, te da se po pretpostavljenom omogući vidljivost dokumentata u statusu 

manjem od 4. 


Omogučeno je pregled zahtjevnica vrste dokumenta ZAH na ekrenu ZAHpd_pr_fd odnosno pregled poštanskih 

ureda -analitika po nadređenoj orgj jedinici na način ako se upiše na gore navedenom pregledu vrsta analitika Oorgj 

a u polje analitika šifra orgj na pregledu zahtjevnica dobt ćemo sve analitike - PU koje su podređene 

upisanoj orgj u polju analitika. 

Preuzmite laus libove rob0,rob1,rob2,rob3 i rob4 koji su na internetu 09.04.2013. 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja Kraljev 


13278 



29.03.2013 10:14 

Upisao: 

Boško Tokić 

Područje: 

LROBD 


04.04.2013 


Na ekranu Zahtjevnica skladištu (ZAH zg_fd) nakon pritiska tipke F1 - ZAH-RIM neka se otvori ekran na 

kojem treba omogućiti unos datuma koji će se preslikati u datum na dokumentu RIM - Izdatnica u 

maloprodaju. 

Na tom ekranu neka bude ponuđen trenutni datum. 


Prilikom generiranja RIM-a iz zahtjevince ZAH preko tipke F1(ZAH-RIM) otvara se ekran za promjenu datuma 

dokumenta ZAHrim_dok_fd te na F1(GEN-RIM) genriranje dokumenta RIM sa prije upisanim datumom 

dokumenta. 

Potrebno je preuzeti laus libove rob0,rob1,rob2,rob3 irob4 koji će bitina internetu 05.04.2013. 


Poštovani, 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja Kraljev 


13277 



29.03.2013 09:53 

Upisao: 

Boško Tokić 

Područje: 

LROBD 


04.04.2013 


Kada sa ekrana Stavke dokumenta (ZAHsp_pr_fd) tipkom F2 - IZMJENI uđemo na ekran Stavka 

zahtjevnice skladištu (ZAH st_fd) i nakon što napravimo izmjenu da se ponudi slijedeće stavka koja dolazi 

po rednom broju. 


Kada sa ekrana Stavke dokumenta (ZAHsp_pr_fd) tipkom F2 - IZMJENI uđemo na ekran Stavka zahtjevnice 

skladištu (ZAH st_fd) i nakon što napravimo izmjenu ponudi se slijedeća stavka koja dolazi po rednom broju. 

Preuzmite Laus libove rob0,rob1,rob2,rob3 i rob4 koji će biti na internetu 30.03.2013. 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja Kraljev 


13276 



29.03.2013 09:49 

Upisao: 

Boško Tokić 

Područje: 

LROBD 


04.04.2013 


Prilikom generiranja NRD-Narudžbe dobavljaču (zahg_fg) u stavkama narudžbe, treba biti zbrojena količina 

na nivou jedne šifre artikla. 


Prilikom generiranja NRD-Narudžbe dobavljaču (zahg_fg) u stavkama narudžbe zbrojena je količina na nivou 

jedne šifre artikla. 

potrebno je preuzeti nabd lib koji će biti na internetu 3.4.2013. 


Poštovani, 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja Kraljev 


13275 



29.03.2013 09:26 

Upisao: 

Boško Tokić 

Područje: 

EHPUR 


08.04.2013 

Najavljujemo promjene organizacijskih jedinica za cca 420 radnika HP-a. 

Podatke ćemo poslati u utorak 02.02.2013.g. do kraja dana. 




0









Poštovani, 

Procjena za zahtjev je 25 sati i postoji mogućnost povećanja procjene ukoliko se tijekom importa ispostavi da su 

podaci nedostatni. 

Molimo povratne informacije / potvrdu realizacije importa ili oduustajanje od importa. 


Poštovani, 

Prošli tjedan poslana je procjena sati za import rješavatelja te smo tražili potvrdu ili odustajanje od zahtjeva. 

Do danas nismo dobili povratne informacije, slijedom navedenog nismo započeli s realizacijom zahtjeva. 

Molimo povratne informacije. 


Poštovani! 

Odustali ste od zahtjeva br. 13275. Zahtjev zatvaramo - Neće se rješavati 



0











Klijent: 



Pitanje 


Hitnost: 

Vrlo hitno 


Katja 


13274 



28.03.2013 11:43 

Upisao: 

Božo Mišeta 

Područje: 

LTRAN 


03.04.2013 


Kako je PU 10101 Zagreb 1 , Jurišićeva 13 uključena u probni rad po e-Zahtjevnicama i e-Povratima u 

Depo Zagreb kod dokumenta Povrat robe broj 254/2013 od 04.03.2013 (.pdf 3990 001) naišli smo na 

problem. 

Naime u aplikaciji „MIPS“ prema izjavi kolegice sve je uredno proknjiženo, ali se u aplikaciji „LAUS“ 

dokument ne vidi odnosno nije generiran u e-Povrat ( ME1225 - RPMul_jd POVRATNICA IZ 

MALOPRODAJE – ekran RPMzg_fd U). 

Molim Vas za provjeru zašto navedeni document nije vidljiv u Lausu. 

mips_laus tablica: zahtjev_prijenos 



0









Ponovljen prijenos za mips dokument 254. U lausu je nastao RPM dokument 35358R1304652. 


Poštovani, 

Zahtjev zatvaramo uz vašu suglasnost . 

42193/1-originalni broj: [13274]- riješen. 

NAPOMENA : 

isti slučaj se ponovio i poslan je novi zahtjev HP 13292 , KZ 42303 : 

Povrat robe broj 299/2013 od 13.03.2013 nije vidljiv u aplikaciji Laus. Naime u aplikaciji „MIPS“ prema izjavi 

kolegice sve je uredno proknjiženo, ali se u aplikaciji „LAUS“ dokument ne vidi odnosno nije generiran u e-Povrat 

( ME1225 - RPMul_jd POVRATNICA IZ MALOPRODAJE – ekran RPMzg_fd U). Nedugo smo imali isti slučaj sa 

dokumentom 254/2013 koji je riješen uspješno. 

Molim da nam javite zašto se ovaj problem počeo ponavljati? 

Objašnjenje zašto se događaju ove situacije s povratima Bez toga zahtjev 13292 se ne može zatvoriti iako je i 

Povrat robe broj 299/2013 od 13.03.2013 naknadno uspješno generiran i vidljiv u LAUS aplikaciji. 


Poštovani, 

Zaprimili smo zahtjev : 

HP 13292 , KZ 42303 sa istim problemom kao kod zahtjeva KZ 42193-originalni broj: [13274]- riješen 

Objašnjenje zašto se događaju ove situacije s povratima poslat ćemo kroz zahtjev 13292 bez čega se ne može 

zatvoriti iako je i Povrat robe broj 299/2013 od 13.03.2013 naknadno uspješno generiran i vidljiv u LAUS 

aplikaciji. 

Međutim , iz vašeg odogoora zaključujemo da i ovaj zahtjev teba ostati nezatvoren sve dok se ne pošalje 

obajšnjenje vezano za povrate, bez obzira što se radi o istom problemu te stavljamo zahtjev u status : U 

rješavanju 


Poštovani, 

Molimo suglasnost za zatbaranje zahtjeva - Riješen . 

Slijedi pojašnjenje vezano za situacije s prijenosom povrata mips-->laus . 

Dokument se nije uredno upisao u Laus zato što je prilikom preuzimanja dokumenta integracijskim servisom 

pukla veza na bazu eObradaRacuna . Dokument je u mips bazu upisan 2013-03-13 12:39:52 i odmah po upisu 

(u roku nekoliko sekundi) ulazi u prijenos. 

Međutim, upravo u vrijeme prijenosa je došlo do prekida rada integracijskog servisa i dokument se nije stigao 

upisati u Laus. 







0









poštovani, 



NAPOMENA iz zadnje obrade : 







0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13273 



28.03.2013 09:24 

Upisao: 

Božo Mišeta 

Područje: 

LTRAN 


02.04.2013 


29.03.2013 

Proširiti mips_laus tablicu promet_pu za polje bkatalog ( 20 znakova) i omogućiti prijenos kataloškog broja 

iz laus baze (tablica art_dob, polje bkatalog)-akcije: unos i izmjena. 


Proširen je prijenos podataka o artiklima iz LAUS sustava u MIPS. Sada se prenosi i podatak o kataloškom broju 

(tablica art_dob, polje bkatalog). 


Instalacija: U utorak 02/04/2013 će biti dostupan novi LAUS TRAN lib. 

Potrebno je na MIPS bazi izvesti sql: 

alter table artikli add bkatalog char(20) before indikator_mips 

Potrebno je pripaziti da se i preuzme lib i izvede sql 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Ivan 


13272 



27.03.2013 14:25 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


28.03.2013 


Kod knjiženja preko objekta knjstb.jas program ne upiše datum dospijeća za ugovore koji imaju 24 rata na 

zadnju ratu (sve ostalo dobro napuni u arhivk). Primjer sa produkcije je u prilogu. 


Potrebno je napuniti radni kalendar za 2015 godinu. 


Poštovani, 

Zahtjev je na popisu neriješenih zahtjeva koji je poslan kao prilog zapisniku sa sastanka IT-LAUS 10.06.2013.g. 

Nismo dobili primjedbe nakon zadnje obrade 29.03.2013. Zahtjev smo zatvorili isti dan : 

Potrebno je napuniti radni kalendar za 2015 godinu. 


Trenutni status : Čekamo stav HP 


Poštovani, 


S štovanjem 





0











Klijent: 





Hitnost: 

Vrlo hitno 


Višnja 


13271 



27.03.2013 13:45 

Upisao: 

Božo Mišeta 

Područje: 

EPNAB 


29.03.2013 


Potrebno je za ugovor broj HP-10/2-022574/12 kroz ePlanNabave unijeti podizvođače: 

620808 DAUS TRUCK d.o.o. 

626052 AUTO SERVIS JURJEVIĆ d.o.o. 

692310 AUTOMAGISTER d.o.o. 

Kako je ugovor već poslan u LAUS, a nakon toga jedan podizvođač ispostavio račun, a tehnički nositelj 

pokušao taj račun provesti kroz 'eObraduRacuna' uočeno je da je potrebno tom ugovoru unijeti 

podizvođače. 

Prijenosom je potrebno omogućiti ažuriranje podizvođača za taj ugovor u LAUS-u. 



0









Poštovani, 

Procjena za ovaj zahtjev je 1 sat. 

Lp, 


Molimo pristup na produkciju u vezi zahtjeva 13271 

Pozdrav 


Poštovani, 

Podizvođaci su ručno dodani u bazu ePN jer se nakon slanja u LAUS ugovori ne nogu mijenjati kroz aplikaciju. 

Ali nisu dodani u staging bazu - Podaci već postoje u LAUS-u ** 

Uobičajenim prijenosom ePN --> LAUS ne mogu se prenijeti ako u staging bazu nisu zapisani. 

Danas provjereno ** : podaci svi na svom mjestu i ne treba ništa više raditi po ovom zahtjevu . 


NAPOMENA : Nije jasno tko je podatke upisao u mila i laus produkcijsku bazu 

PRETPOSTAVKA : HP morala ovjeriti račun (27.3.2013. poslan zahtjev ) pa ste sami upisali u bazu 

ndostajuće podizvođače (28.3.2013) 

------------------ 

epn_veze : 

protokol boriginal ugovor_id part datum 

41039R1300074 HP-10/2-022574/12 6445 613130 26/02/2013 

41039R1300074 HP-10/2-022574/12 6445 620808 28/03/2013 

41039R1300074 HP-10/2-022574/12 6445 626052 28/03/2013 

41039R1300074 HP-10/2-022574/12 6445 692310 28/03/2013 

ugovor_eolog i ugv_part : 

protokol boriginal dobavljac datum_upisa 

41039-R13-00074 HP-10/2-022574/12 613130 2013-02-26 11:47:16 

41039-R13-00074 HP-10/2-022574/12 620808 2013-03-28 13:15:54 

41039-R13-00074 HP-10/2-022574/12 626052 2013-03-28 13:15:54 

41039-R13-00074 HP-10/2-022574/12 692310 2013-03-28 13:15:54 


Poštovani, 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13270 



27.03.2013 13:42 

Upisao: 

Božo Mišeta 

Područje: 

EHPUR 


02.04.2013 


U aplikaciji eHPUR transakcija T2 kod ispisa spisa ne ispisuje cijelu organizacijsku oznaku. 

Potrebno je proširiti polje (razmak) za ispis organizacijskih oznaka. 

U prilogu dostavljamo grešku koja se događa kod dužih organizacijskih oznaka. 

Primjeri dužih oznaka: 

DPO-04/3/6 

DPO-06/3/2 

DP-04/1/2/2 

DP-04/1/1/4 


Poštovani, 




Poštovani, 


Lijep pozdrav 



0











Klijent: 





Hitnost: 



Ivan 


13269 

Urudžbiranje računa u aplikaciji „eObradaRačuna“: 



27.03.2013 08:16 

Upisao: 

Božo Mišeta 

Područje: 

EOBRRAC 


02.04.2013 


U transakcijama T1, i T3 potrebno je kod izbora ispisa “Prijemnog štambilja” omogućiti ispis štambilja na 

beskonačne naljepnice (tračne naljepnice). Potrebno je prilagoditi margine ispisa naljepnica te povećati o 

podebljati font znakova. 

Mjere naljepnica su 70 mm X 36 mm. 

U prilogu dostavljamo primjer ispisa na beskonačne naljepnice. 

Printer koji bi se koristio: 

STAR MICRONIS TSP700II. 

Prilog: 

Primjeri ispisa. 



0









Poštovani, 

Procjena utroška vremena za ovaj zahtjev je 9 sati. 

Lp, 


Poštovani, 




Poštovani, 




Poštovani, 

Sukladno Vašem zahtjevu, izvršene su dorade na prijemnom štambilju. 

Nadalje, prilikom podešavanja postavki ispisa molimo da odaberete Custom Scale 70% (prikaz u privitku). 

Lp, 


Poštovani, 






S štovanjem 





0











Klijent: 








Višnja 


13238 



26.03.2013 15:27 

Upisao: 

Dolores Lovrić 

Područje: 

LKROP 


Kroz kdan_jk KADROVSKI PODACI O RADNICIMA NA DAN na excel-mail listi kdan_rk.csv potrebno je 

-Ispraviti naziv divizije prema ustroju sukladno org jedinici po RS-u 

-Omogućiti ispravno izlistavanje radnika na dan po organizacijskoj grupi (kapezg, kadpdv, kamuzg….i dr) 

Kada izlistava radnike za cijeli HP sve je u redu , ispravan je broj radnika na dan ali ne izlaze ispravno po 

org grupama. Kad radnici u određenom razdoblju prelaze iz org grupe u drugu, izlist vrši prema onoj org 

grupi u kojoj je radnik danas a ne prema stanju na dan (ne prati povijest dok to sa neaktivnim radnicima 

uredno radi) 


Omogućeno je ispravno izlistavanje radnika na dan po organizacijskoj grupi djelatnika na objektu kdan_jk. 

Što se tiče naziva divizije to je već ispravljeno i isporučeno.Testirana je lista za grupu KADPDV na dan 

01/04/2013 i za radnike na org. jedinicama 41016 i 46308 ispravno se ispisuje naziv DIVIZIJA 

PODRŠKA.Primjer datoteke je /home/admlaus/kdan_rk.csv.Ukoliko nalazite da se i dalje ispisuje pogrešna 

divizija molimo primjer datoteke. 

Preuzmite: krop lib od 16/04/2013 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13268 

1.Urudžbiranje ulaznog podneska u aplikaciji „eHPUR“: 



26.03.2013 13:40 

Upisao: 

Božo Mišeta 

Područje: 

EHPUR 


02.04.2013 


U transakcijama T1, T2, T3 i T12 potrebno je kod izbora ispisa “Prijemnog štambilja” omogućiti ispis 

štambilja na beskonačne naljepnice (tračne naljepnice). Potrebno je prilagoditi margine ispisa naljepnica te 

povećati I podebljati font znakova. 

Mjere naljepnica su 70 mm X 36 mm. 

U prilogu dostavljamo primjer ispisa na beskonačne naljepnice. 

Printer koji bi se koristio: 

STAR MICRONIS TSP700II 

Prilozi: eHPUR - Prijemni stambilj naljepnice v2.docx, eHPUR - ispisani primjer na naljepnici prijemni 

stambilj 70x36.JPG 



0









Poštovani, 

Procjena utroška vremena za ovaj zahtjev je 9 sati. 

Lp, 


Poštovani, 




Poštovani, 

Jeste li probali ispisati prijemni štambilj na printer? 

Sliku koju ste poslali je rezultat je ograničenja HTML prikaza u web pregledniku, međutim ovo ne utječe na 

konačni ispis/izgled prijemnog štambilja. 

Ukoliko imate primjedbi, molim da nazovite kolegu Branimira Marjanovića na 091 2353 815 kako bismo skratili 

postupak prilagođavanja PŠ- a, u suprotnom predlažem prebacivanje dorada na produkciju. 

Zahvaljujem, 


Poštovani, 

prosljeđujem mail od programera i dostavljam u privitku kako kod nas izgleda ispis PŠ- a na naljepnice (mi 

imamo malo manje dimenzije naljepnica): 

Kod nas je ispis u redu na ZDesigner GK420t printeru. Koliko sam upoznat, printer u HP do sada nije korišten pa 

ga moraju konfigurirati prije upotrebe. Mogu predložiti da provjere da je za printer instaliran i koristi se "Raster 

mode driver", a ne "Line mode driver". 

Lp, 



0









Poštovani, 

U nastavku prosljeđujem komentare kolege Marjanovića po ovom zahtjevu: 

Iz privitka vidim da je podešavanje drivera u raster mode rješilo problem ispisa nedefiniranih znakova. Vidim i da 

je ispis napravljen korištenjem native drivera ugrađenog u web preglednik. Ugrađeni mehanizam ispisa nije 

pogodan za precizan ispis, jer ovisi o postavkama web preglednika (na primjer uvećanje pregleda). Na računala 

na kojima se ispisuju naljepnice potrebno je instalirati Adobe Reader, po mogućnosti noviju verziju, nakon čega 

bi se prilikom ispisa trebao pojaviti alat za ispis poput onoga iz priložene slike. Da se radi doista o Adobe 

mehanizmu ispisa može se potvrditi klikom na "Help" u desnog gornjem kutu, koji otvara Adobe stranicu. Kako je 

označeno, prilikom ispisa treba odabrati "Actual size". 

Moram napomenuti da ćemo za ostale upite po ovome zahtjevu morati povećati procjenu. 



Prilozi uz prethodnu obradu 


Prosljeđujem odgovor od kolege Marjanovića: 

Treba isključiti "Choose paper source by PDF page size" i "Print on both sides of paper". 

Ako i dalje u desnom dijelu iznad pregleda dokumenta piše "7,5 x 3,87 Inches" ili slično, treba ručno namjestiti 

dimenzije papira na stvarnu dimenziju naljepnice (treba biti kao i dimenzije dokumenta, što piše iznad: 

"Document: 3,1 x 1,8in") . 


Poštovani, 

U skladu s tehničkim specifikacijama (hardware manual nalazi se na instalacijskom cd- u) printera potrebno je 

kalibrirati printer, odnosno ispravno pozicionirati tzv. black mark kako bi printer ispravno mogao prepoznavati 

razmak između dviju uzastopnih etiketa. 

Nadalje, u prvom privitku Upute.docx se nalaze upute za podešavanje ispisa prijemnog štambilja na tračne 

naljepnice. 

Zbog neprecizne dokumentacije proizvođača i problema s nekalibriranim printerom (u privitku primjer.pdf je 

prikaz prijemnog štambilja iz kojeg je vidljivo da printer nije kalibriran, a ispod je slika pravilnog PŠ- a) povećana 

je procjena odnosno utrošak za 5 sati. 

Sutra 08.05.2013. u toku dana dostaviti ćemo Vaš printer na lokaciju Horvatova 82 i predati ga gđici Katji Kraljev. 



0









Poštovani, 

Printer je vraćen/dostavljen gđici Kraljev danas 08.05.2013. u 12:20 sati. 

Napravili smo sve što je moguće vezano uz podešavanje ispisa . 

Molimo kontaktirajte dobavljača printera kako bi dobili valjane upute / pomoć oko setiranja printera 

ili tražite neki noviji, podesiviji model . 

Status : Čeka se stav HP/ suglasnost za zatvaranje zahtjeva - Riješen 


Poštovani, 

Izvršene su korekcije na prijemnom štambilju i prebačene su na test. 

Molim Vas provjeru istih. 

Za dodatna pitanja i komentare molim Vas obratite se kolegi Branimiru Marjanoviću – 091 2353 815. 

Datum rješenja 

10.05.2013. 

Molimo povratne informacije / suglasnost za prebacivanje na produkciju 


Poštovani, 

Na testni server prebačene su dorade po ovom zahtjevu. 

U telefonskom razgovoru s gđicom Kraljev dogovoreno je testiranje istih za ponedjeljak 27.05.2013. te će imati 

telefonsku podršku s naše strane prilikom testiranja. 



Poštovani, 

Molim Vas da provjerite imate li na tom računalu instaliran Adobe Reader. 

O gore navedenom detaljnije je opisano u mailu koji smo slali 25.04.2013. godine: ˝Na računala na kojima se 

ispisuju naljepnice potrebno je instalirati Adobe Reader, po mogućnosti noviju verziju, nakon čega bi se prilikom 

ispisa trebao pojaviti alat za ispis poput onoga iz priložene slike. Da se radi doista o Adobe mehanizmu ispisa 

može se potvrditi klikom na "Help" u desnog gornjem kutu, koji otvara Adobe stranicu.˝ 

Nadalje, predlažemo da na stranici proizvođača preuzmete nove drivere. 


Poštovani, 

Možemo li zaključiti da je ispis Prijemnog štambilja u skladu s Vašim potrebama te se isti može prebaciti na 

produkciju? 

Lp. 



0









Poštovani, 

Printer STAR MICRONIS TSP700II koji smo zadužili na revers radi rješavanja ispisa prijemnog štambilja na 

beskonačne naljepnice vraćamo danas 

( Dajana : sastanak u 14:00 Horvatova ) 

Molimo povratne informacije/ suglasnost za prebacivanje na produkciju u petak 7.6.2013. iza 16:00 


Poštovani, 

Molimo omogućite danas iza 16:00 spajanje na produkciju eHPUR radi prebacivanja dorada po ovom zahtjevu. 



Poštovani, 





Poštovani, 

zatvaramo zahtjev po vašem odobrenju. 

S štovanjem 

Poštovani! 


Lp, Katja 


Poštovana, 

po vašem nalogu zatvaramo zahtjev po drugi put. Već smo ga zatvorili po vašem nalogu i vas obavjestili 

10.06.2013. 

S štovanjem 

Poštovani, 

Provjereno. Radi. Zahtjev možete zatvoriti. 

LP, 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13267 



26.03.2013 12:51 

Upisao: 

Božo Mišeta 

Područje: 

LROBD 


28.03.2013 


Nije moguće prebaciti u status 7 dokument RO2 (materijalna povratnica) 41041-R13-01320 kada se radi o 

artiklima koji nemaju cijenu (vidi privitak). 

Ostali RO2 dokumenti su uspješno prebačeni u status 7. 

Molim za rješenje problema. 


Za materijalnu povratnicu RO2 koja nema unesen broj izdatnice po kojoj se vraća materijal omogučeno je 

knjiženje po cijeni 0. 

Potrebno je preuzeti laus libove rob0.rob1,rob2,rob3 irob4 koji će biti na internetu 27.03.2013. 


Poštovani, 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Višnja 


13266 



26.03.2013 10:39 

Upisao: 

Božo Mišeta 

Područje: 

LKEVP 


27.03.2013 


Radnu 13756 JAKOPČEVIĆ MARTIN nije moguće izvršiti brisanje izostanka I-GO jer se javlja poruka: 


Poštovani, 

razlog nedozvoljenog brisanja na produkcijskoj bazi je što su id slogova već dužine 8, a na ekranu su polja bila 

dužine 7. 

Zato je na testnoj bazi uredno radilo brisanje. 

Potrebno je preuzeti verziju. 

kevp je na internetu od 27/03/2013. 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Ivan 


13265 



26.03.2013 09:44 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


27.03.2013 


Kod masovnog ispisa faktura preko objekta fakSTB.jas kada se zadaje uvjet za ispis više faktura na ispisu 

kod korisničkih podataka kod svih faktura naziv poštanskog broja jednak je nazivu poštanskog broja na 

prvoj fakturi koja se ispisuje. 


Ispravljen je prikaz grada kod masovnog ispisa faktura preko objekta fakSTB.jas 

Lib je na internetu (win faus) 


Poštovani, 





0











Klijent: 





Hitnost: 



Višnja 


Poštovani, 

13264 

Riješen 


26.03.2013 07:13 

Upisao: 

Božo Mišeta 

Područje: 

LBASE 


15.04.2013 


15.06.2013 

Po poslanom zahtjevu potrebno je poslati procjenu sati i rok isporuke. 

1. Kroz pust_jm PREGLED ORGANIZACIJSKE SHEME potrebno je: 

Na pregledu ustroja (ekran pst_fm) omogućiti unos filtera 'aktivnost' sa podacima: 'D' – sve aktivne, Nneaktivne, 

prazno – sve organizacijske jedinice 

izborom kojeg je potrebno omogućiti excel-mail listu sa podacima o šiframa i nazivima organizacijskih 

jedinica sa kompletnom njihovom hijerarhijskom strukturom (jedna organizacijska jedinica jedan red): 

-Šifra organizacijske jedinice – razina 1 - šifra divizije ili Uprave društva 

-Naziv organizacijske jedinice – razina 1 – naziv divizije ili Uprave društva 

-Šifra organizacijske jedinice – razina 2 - uredi, sektori, grupe područja, odnosno organizacijske jedinice 

kojima je nadređena divizija ili Uprava društva (razina 1) 

-Naziv organizacijske jedinice – razina 2 

-Šifra organizacijske jedinice – razina 3 organizacijske jedinice kojima je nadređena razina 2 


-Šifra organizacijske jedinice – razina 4 – organizacijske jedinice kojima je nadređena razina 3 


-Šifra organizacijske jedinice – razina 5 - organizacijske jedinice kojima je nadređena razina 4 

-Naziv organizacijske jedinice – razina 5 u obliku: 

RAZINA 1RAZINA 2 RAZINA 3 RAZINA 4RAZINA 5 

Razina 1 je nadređena razini 2 nadređena razini 3 itd (prilog ORGJ struktura.xlsx). 



0









Za navedenu listu potrebno je 16 sati rada te rok isporuke može biti 15.4.2013. 


Na objektu pust_jm na tipku F6 dodana je excel verzija ispisa ORGANIZACIJSKE STRUKTURE po razinama 

kako je traženo u zahtjevu. 

Na ekranu pst_fm u zadnju kolonu je dodan stupac A (aktivnost) u koji se može zadati D,N, ili prazno (sve orgj). 

Po defautu filter je postavljen na D. 

Lista se također može listati po ostalim filter poljima na ekranu. Svi zadani uvjeti po kojima se lista organizacijska 

struktura se ispisuju na listi. 

Preuzeti novi LAUS BASE liba. Novi lib se već nalazi na internetu. 


Napravljene su tražene dorade na excel ispis sa objekta pust_jm 

Novi LAUS BASE liba je na internetu. 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13263 



25.03.2013 15:19 

Upisao: 

Božo Mišeta 

Područje: 

WINTRAN 


28.03.2013 


Na rekapitulacijama za robu za promjena cijena je -163,00 kn, a u Knjizi popisa iz MIPS-a, u prijenosu 

došla su dva dokumenta 02.01.2013.g. 116,00 kn, a 03.01.2013.g. -93,00 kn, što iznosi ukupno 23,00 kn. 

– na rekapitulacija se ne prikazuje ispravno stanje nivelacije cijene. 

U excelu je ono što je došlo iz Mipsa i cjenici i kalkulacije za artikle. 

Pretpostavljamo da rekapitulacija ne prikazuje dobro situacije kada je isti dan došlo do plusa i minusa u 

nivelaciji. 

Molim Vas provjeru zašto je došlo do razlike. 



0









Kod generiranja prometa PU-a korz objekt ambz_jd omogučeno je da stavke iz PU koriste broj cjenika koji je 

poslan iz mipsa , jer se broj cjenika određivao u laus na datum mips dokumenta . 

Potrebno je preuzeti laus libove rob0,rob1,rob2,rob3i rob4 koji će biti na internetu 27.03.2013. 


Poštovana, 

treba spustiti robd libove, jer u njima je napravljena izmjena. Uzima se cijenik iz MIPS-a, a ne cijenik iz Laus-a 

koji je vrijedio na datum dokumenta. 

Zbog toga je dolazilo do razlika. 

S štovanjem 

Ovo je područje WIN TRAN, a vi ste odgovorili da možemo spustiti robne libove. 

Da li je zahtjev riješen i da li možemo, po ovom zahtjevu, spustiti win tran lib? 

Lp, 


Poštovani, 

potrebno je ponoviti pripremu za period koji se promatra (1 mjesec). 

Znači ponoviti sve predradnje s novom verzijom programa, kako bi se formirao točna rekapitulacija. 

S štovanjem 


Poštovani, 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13262 



25.03.2013 14:26 

Upisao: 

Božo Mišeta 

Područje: 

WINTRAN 


28.03.2013 


1) LISTA 1. POPIS ASORTIMANA SA ŠIFRAMA ARTIKALA – u polju „Status“ dodati *-svi statusi 


Na objektu asorl.trn LISTE ASORTIMANA za listu br 1. omogučen je ispis za * - Svi statusi. 



Poštovani, 

Na objektu asorl.trn LISTE ASORTIMANA odnosno listi 2) POPIS ASORTIMANA PO PU je omogučen ispis za 

točno određene statuse asortimana. 





Poštovani, 

Zahtjev zatvaramo uz vašu suglasnoxt - Riješen 



0











Klijent: 





RO2ul_jd RO2ulO_jd 

Hitnost: 



glorija 


13261 

RO2ul_jd RO2ulO_jd MATERIJALNA POVRATNICA 



22.03.2013 18:24 

Upisao: 

Dajana Lekić 

Područje: 

LROBD 


28.03.2013 


a.Na ekranu RO2 omogućiti prolaz polje „Izdatnica“ bez upisivanja broja izdatnice dok se ne omogući veza 

sa dokumentima zatvorenog skladišta 41042. 

Omogućiti da skladište 41041 prepozna dokumente ostalih organizacijskih jedinica – 41043, 

41044, 41045 , 41046 i 41049. 

Znači kod pridjeljivanja izdatnice da se može odabrati i ona na neaktivnoj orgj i na orgj koji nije 

skladište u koje se vraća. 

b.Na ekranu traži na Izdatnici RO2 omogućiti tipku „Detalj“ da se može ući u dokument i pogledati podatke i 

stavke. 

c.Omogućiti povlačenje Izdatnica na osnovno sredstvo u statusu manjem od 7. 

Kod statusiranja kontrola da ako je izdatnica povezana sa RO2 u statusu manjem od 7 da se 

cijena ne može povući dok se dokument ne statusira. 



0









a. Na dokumentu RO2 omogučen je unos izdatice bez obzira na šifru skladišta izdatnice. 

b. Na pregledu izdatnica ROM dokumenta RO2 omogučen je detlj dokumenta izdatnice F3(DETALJ) na ekranu 

YYYpd_pr_fd. 

c. Za dokumente RO2 povratnica osnovno sredstvo omogučen je unos izdatnice i u statusu 2 te onemogučeno je 

knjiženje RO2 ako izdatnica ROM nije prethodno materijalno proknjižena. 

Potrebno je preuzeti laus libove rob0.rob1,rob2,rob3 i rob4 koji će biti na internetu 29.03.2013. 


Na dokumentu RO2 bez obzira jeli na osonovno sredstvo omogučen je unos izdatnice u statusu manjem od 7 

odnosno u 2 . 

Pri unosu izdatnice kojoj skladište nije jednako skladištiu povrata ispiše se poruka "Skladište izabrane izdatnice 

(XXXX) nije jednako skladiçtu povrata (YYYY) !" te program omogučava daljni rad odnosno unos dokumenta. 



Poštovani, 





0











Klijent: 





Hitnost: 

Vrlo hitno 


Glorija 


13260 



22.03.2013 14:50 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


28.03.2013 


Za izradu računa vrste 4 za kupce oslobođene plaćanja PDVa treba iskazati iznos poreza ali vrijednost 

mora biti bez poreza. Izjava D ali ne stavljati u protokol I nego ostaviti u 5. 

U napomeni ispisivati: Kupac oslobođen plaćanja PDV-a 

Omogućiti automatsko knjiženje računa ruckat, vrsta 4. Napraviti poseban objekt. Princip knjiženja - knjts7 

(GOT,GR1) i knjts5 (VR1). 



0









Poštovani, 

Molimo pošaljite primjer računa iz 2013 u protokolu 0 kojem je kupac oslobođen plaćanja pdv-a (part_pdv=N) i 

napišite treba li i za vrstu računa 4 imati isti izgled ili ako treba nešto mijenjati napišite što . 

Molimo vaš stav na LAUS komentar 

HP traži : 

Za izradu računa vrste 4 za kupce oslobođene plaćanja PDVa ( Izjava D) ne stavljati u protokol I nego ostaviti u 

5. 

LAUS komentar : 

Računi vrste 4 na ruckat.jas odnose se na korekcije računa iz MIPS-a ( tj računi gotovinski i plaćen i virmanom 

izdani u PU koji se prenose u LAUS) 

Prijenos tih računa radi na način da se računi sa izjava=D svrstavaju u protokol I , sve neoporezivo u stupac 11 

knjige IRA . 

Analogno tome , smatramo da i ipravak računa iz MIPS-a treba slijediti gore opisanu logiku kod prijenosa (HP 

zahtjevala upravo tako ) . 

Dakle, mišljenja smo da ne treba mijnjati protokol I u protokol 5 

------------------------------------------------ 

Za protokol I ispraviti treba postojeće nepravilnosti 

a) kod evidencije : 

-- umjesto da se ukupan iznos računa razvrsta u kolonu 11, sve je greškom evidentirano po stopi 0%. 

-- U tablici protokol nije evidentiran vrij_p, u prot_pdv ušla stopa 0, a u prot_neop nije bila razrada u koloni 11. 

---Za izradu računa vrste 4 za kupce oslobođene plaćanja PDVa treba iskazati stopu poreza u stavkama 

računa 

ali vrijednost poreza (iznpdv) i ukupan iznos računa (posprz) mora biti bez poreza. 

b) kod ispisa 

U napomeni ispisivati: Kupac oslobođen plaćanja PDV-a 

Ukupno= neoporezivo . Osnovica i porez=0 na kraju računa (kao računi fak*za kupce kojima je part_pdv=N za 

protokol=0) 


Za potrebe knjiženja dokumenata iz MIPSa (vrsta 4) napravit će se novi objekt. 

Kako ćemo nazvati novi objekt i na koji meni ćemo ga zakačit? 


Napravljen je novi objekt za automatsko knjiženje dokumenata iz MIPSa (vrsta računa 4). 

Na objektu je omogućeno posebno knjiženje gotovine, virmana i gotovina R1. 

Novi objekt je knjmips.jas 

Potrebno je da korisnik na testnoj bazi pogleda knjiženje i javi eventualne primjedbe. 

U ponedjeljak (29.04.2013) ujutro će biti dostupan novi WIN FAUS lib. 

Preuzeti nove objekte i menie (Win) 



0









Poštovani, 


10.06.2013.g. 

Zahtjev po našoj evidenciji nije do kraja riješen 

Sataus : Čekamo stav HP 

----------vezano za protokol I : 

riješeno je knjiženje. 

Evidencija u protokolu I nije dobra i 

ispis ima greške koje nisu još ispravljene 

Odustajete li od rješavanja ? 

Ako ne, molimo pošaljite konkretan ispis za protokol I jer postoji dilema oko slijedećeg : 

ZA račun koji je u protokolu I 

- u stavkama na ispisu se prikazuju stope poreza , a iznos poreza je 0 ? 

- svi iznosi na ispisu koji se odnose na porez (iznos poreza, osnovica, oporezivo ) su jednaki 0 ? 

-- ukupno i svi zbirni iznosi ne sadrže porez ? 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13258 



22.03.2013 14:46 

Upisao: 

Božo Mišeta 

Područje: 

LTRAN 


26.03.2013 


AMBULANTNA DOSTAVA 

Omogućiti prijenos artikla sa pridruženim indikatorom ‘A-ambulantna dostava’ u mips_laus bazu. 


Ovaj zahtjev je riješen i isporučen u sklopu zahtjeva Laus broj 42080 HP 13257 

Molim potvrdu izvršenja 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Glorija 


13259 



22.03.2013 14:42 

Upisao: 

Božo Mišeta 

Područje: 

LFINK 


28.03.2013 


26.04.2013 

Kod automatskog knjiženja stavaka žiroračuna kod uplata kupaca trenutno se provjerava da je u pozivu na 

broj upisan Laus broj dokumenta i šifra partnera po OIBu. 

Potrebno je provjeravati i fiskalni broj računa. 

Znači kad imamo uplatu treba gledati da odgovara ili laus broj dokumenta ili fiskalni broj dokumenta i knjižiti 

uplatu po laus broju dokumenta za određenog partnera 



0









Poštovani, 

Procjena za ovaj zahtjev je 8 sati . Rok isporuke - očekujemo u petak 26.4.2013. 

Ovim načinom bit će obuhvaćene isključivo uplate ( oznakat='20' ) kojima je pozbo like '00%-1' nakon što se 

nisu automatski proknjižile po kriteriju : 

LB u pozbo 


Omogućeno je automatsko knjiženje izvoda žira ako je u pozivu na broj odobrenja upisan fiskalni broj. 



Ispravljena je kontrola na fiskalni broj kod automatskog knjiženja izvoda žira. 

Obavijestiti korisnika o preuzimanju novog LAUS FINK liba u srijedu 1.5.2013. 


Omogućeno je automatsko knjiženje izvoda žira za bilo koji model ako su u pozvi na broj nalazi fiskalni broj. 

Preuzeti novi LAUS FINK liba u ponedjeljak 6.5.2013. 


Poštovani, 





0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13257 



22.03.2013 14:36 

Upisao: 

Božo Mišeta 

Područje: 

LTRAN 


26.03.2013 


AMBULANTNA DOSTAVA 

U Laus aplikaciji omogućiti pridruživanje indikatora artiklu koji označava “ambulantnu dostavu”. 



0









Ovo su bile inicijano točke zahtjeva 13234 : 

2. U Laus aplikaciji omogućiti pridruživanje indikatora artiklu koji označava “ambulantnu dostavu” 

3. Omogućiti prijenos pridruženog indikatora u mips_laus bazu 

Traženo da se pošalje novi zahtjev ADAPTIVNO jer nije dio projekta Prihodi AC. 

Poslali su ovaj zahtjev 13257 : 

U Laus aplikaciji omogućiti pridruživanje indikatora artiklu koji označava “ambulantnu dostavu” 

PITANJA : 

P1 : treba li omogućiti prijenos pridruženog indikatora u mips_laus bazu ? 

P2 : Može li se indikator ambulantne dostave unositi kao AMB (AMBULANTANA DOSTAVA) .? 

Ako je za artikal upisan AMB sa Aktivnost= D-može se zaprimiti ambulantno 

Ako artikal nema upisan AMB ili mu je aktivnost N , onda se ne može zaprimiti ambulantno tj. u PU. 

P3 : Ako je na P1 odgovor DA , prijenos treba raditi po istom principu ako i za podatak NAR ? 

NAPOMENA : Zaprimanje na depou nema nikakve veze sa AMB : svi artikli se mogu zaprimiti na depo . 

Možete odmah početi ažurirati podatak/indikator bez programskih izmjena . 


Sve dokumente pa tako i ambulantne primke i povrate u svrhu izvještavanja može se ili ne videjti kroz izvještaje 

neovisno o slanju informacije uz artikal može li se ili ne ambulantno tj. u PU zaprimiti od dobavljača. 

Svrha uvođenja ovog indikatora je kontrola rada u PU tako da ne mogu provesti kao stavku u ambulantnoj primci 

artikle koji nemaju oznaku da se mogu zaprimiti u PU (ambulantna dostava). Ovo su tražili usmeno u sklopu više 

zahtjeva/sastanaka radi kontrole i smanjenja grešaka na amb. primkama (Antonio čubrić , Katica Franjić a sad 

evo i Brankica Ormuž ) 

Ranije je bio stav : dovoljno je postaviti u MIPS-u za koje šifre partnera/dobavljače se može napraviti primka u 

PU. 

Međutim , pokazalo se kao nedostatno jer : 

- 1 dobavljač dio asortimana dosatvlja u PU a dio u depo 

- svodili su se ugovri sobavljača na krovnu šifru a tako i primke a u PU su ostale stare veze dobavljač-artikal pa 

nema koristi 

Nadalje, svi su zaključili na sastanku u srijedu 13.3.2013. da se treba u LAUS-u omogućiti : 

- ažuriranje preko osobina artikala podatak može li se ili ne artikal zaprimiti ambulantno tj. u PU 

-- slanje tog podatka u MIPS 



0









Poštovani, 

Zanemarite iz prethodne obrade sve osim dolje navedenog jer smo u međuvremenu zaprimili zajhtjev broj 

13258 . 

(Omogućiti prijenos artikla sa pridruženim indikatorom ‘A-ambulantna dostava’ u mips_laus bazu. ) 

Molimo potvrdu prijedloga rješenja / suglasnost za zatvaranje zahtjeva - Riješen 

Međutim, ako se zahtjev ne treba rješavati po prijedlogu preko osobina artikala , nejasno je odnosi li se indikator 

na neki postojeći ili novi . 

----------------------------------------- 

PRIJEDLOG RJEŠENJA : 

------------------------------------------- 

Indikator ambulantne dostave unositi kroz OSOBINE ARTIKALA (kako je dosad na sastancima iskazano) kao 

AMB (AMBULANTANA DOSTAVA) 

Ako je za artikal upisan AMB sa Aktivnost= D-može se zaprimiti ambulantno 

Ako artikal nema upisan AMB ili mu je aktivnost N , onda se ne može zaprimiti ambulantno tj. u PU. 

NAPOMENA : Zaprimanje na depou nema nikakve veze sa AMB : svi artikli se mogu zaprimiti na depo . 

Ukoliko se slažete s predloženim, možete odmah početi upisivati uz artikle AMB samo ga je potrebno otvoriti 

preko : 

tipp_fm TIPOVI DODATNIH PODATAKA 

Šifra podatka AMB 

Naziv podatka AMBULANTNA_DOSTAVA 

Ukoliko vam ne odgovara oznaka AMB nego želite neku drugu , samo pošaljite obavjest koja je to oznaka . 

Na ovaj način programske izmjene nisu potrebne . 

NAPOEMNA : 

Preko artd_ja EVIDENTIRANJE ARTIKALA može se u Tip naru čivanja upisati : 

A Ambulantna dostava 

K Komisiona dostava 

C Dostava u središnje skladište 

D Dostava po svim skladi”tima 

- Nepoznato 

Međutim, ovo ne preporučujemo , jer se nehotično mogu promijeniti i neki drugi podaci za artikal a ne samo ovaj. 

Ako se radi preko osobina artikala , onda onaj ko ažurira indikator AMB ne mora imati dozvolu na promjene u 

šifarniku artikala nego samo mijenja osobine. 



0









Omogučen je prijenos dodatnog podatka artikala ambulatne dostave u mips hp_lm_jtr tj. onih artikala kojima je 

pridružem tip artikla AMB ambulatna dostava kroz osobine artikala . 

Potrebno je preuzeti tran lib koji će biti na internetu 26.03.2013 te izvesti sql -ove. 

drop trigger "l1base".mips_del_arttipp ; 

drop trigger "l1base".mips_ins_arttipp ; 

drop trigger "l1base".mips_upd_arttipp ; 

create trigger "l1base".mips_del_arttipp delete on "l1base".art_oso 

referencing old as old 

for each row 

when (((old.tipp = 'NAR' ) OR (old.tipp = 'STS' ) OR (old.tipp = 'AMB' ) ) ) 

( 

update "l1tran".l_mips_art set "l1tran".l_mips_art.azur 

= 1 where (artikal = old.artikal ) ); 

create trigger "l1base".mips_ins_arttipp insert on "l1base".art_oso 

referencing new as new 

for each row 

when (((new.tipp = 'NAR' ) OR (new.tipp = 'STS' ) OR (new.tipp = 'AMB' )) ) 

( 


= 1 where (artikal = new.artikal ) ); 

create trigger "l1base".mips_upd_arttipp update on "l1base".art_oso 


for each row 

when (((((pre.tipp != post.tipp ) OR (pre.aktivnost 

!= post.aktivnost ) ) AND ((pre.tipp = 'NAR' ) OR (post.tipp = 'NAR') )) 

OR (((pre.tipp != post.tipp ) OR (pre.aktivnost 

!= post.aktivnost ) ) AND ((pre.tipp = 'AMB' ) OR (post.tipp = 'AMB') )) 

OR (((pre.tipp = 'STS' ) AND (post.tipp = 'STS' ) ) AND (pre.tekst 

!= post.tekst ) ) ) ) 

( 


= 1 where (artikal = pre.artikal ) ); 

-- na mips_laus@mips_laus bazi 

alter table artikli add tipp_amb char(3) before indikator_mips ; 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13256 



22.03.2013 14:04 

Upisao: 

Božo Mišeta 

Područje: 

EHPUR 


26.03.2013 


Uočili smo grešku kod preuzimanja podataka u aplikaciji eHPUR. 

U prilogu šaljemo popis spisa kod kojih nisu ispravno preuzeti podaci za prvotnog rješavatelja (od jasminke 

frank i snježane kramer). 

Prvotni rješavatelj treba biti prvi zaduženi rješavatelj što u ovom slučaju nije Jasminka Frank ili Snježana 

Kramer. 



0









Poštovani, 

Možete li detaljnije objasniti koji je točno problem. 

Snježana Kramer i Jasmina Frank se prikazuju na tražilici kao prvotni rješavatelji, a u Dnevniku rada je drugačije 

stanje!? 

Točno je stanje ono iz Dnevnika rada? 

Na popisu spisa koji nisu ispravni je DPO-2/1-010651/12 gdje prvotni rješavatelj (gđa Kramer) odgovara 

podacima iz spisa. 


Poštovani, 




Poštovani, 

Uvidjeli smo razliku u podacima Prvotni rješavatelj i Dnevnik rada za slijedeće djelatnike: 

Prvotni rješavatelj Dnevnik rada 

MLADEN ĐAKULOVIĆ SPOMENKA ĐAKULOVIĆ 

ANĐELA ROGULJIĆ ANĐELA PADRENOSTRO 

Molimo informaciju koji od podataka/zapisa je točan. 

Ukoliko u toku dana dobijemo povratnu informaciju, molimo pristup produkciji 22.05.2013. za kolegu Livaića iza 

16.00 kako bi se izvršile promjene. 

Zahvaljujem. 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Glorija 


13255 



22.03.2013 13:42 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


23.03.2013 


Kod knjiženja kataloške javlja se poruka da postoji već knjiženje računa na nalog bez obzira što nisu 

proknjiženi i program puca i zaključa tablice. Potrebno navedenu grešku što hitnije otkloniti. Kod knjiženja 

kataloške prodaje javlja se poruka i jako dugo knjiži, datum ima 13 faktura, nakon sat vremena još uvijek 

ista poruka, na izbor No ne reagira, ne može se izaći iz ekrana 


Napravljene su izmjene na objektu knjiženja kataloške prodaje. 

Preuzmite novi WIN FAUS lib i provjerite jer sada knjiženje ok. 

Instalacija: novi WIN FAUS lib će biti dostupan u petak 12.04.2013. 


Poštovani, 





0











Klijent: 





DDRDG upute za 2013. 

Hitnost: 

Vrlo hitno 


Nada Martinović 


13249 

Riješen 


22.03.2013 13:36 

Upisao: 


Područje: 

LCSBI 


25.03.2013 


22.03.2013 

adaptivni dio HP zahtjeva 13249 koji je zaveden pod laus zahtjevim broj 42022 


Poštovani, 

izvršen je ispravak uputa za DDRDG za 2013. godinu (9. stupac uputa). ustanovljeno je da nakon ispravka nema 

uputa na konta koja ne postoje u 2013.godini tako da takve upute nisu trebale biti brisane. 

generiranje DDRDG hijerarhije i za 2013 je prošlo uredno. Sljedećim učitavanjem u LCS BI bi trebala biti vidljiva. 


Poštovani, 

podaci su prisutni, u navedenom screenshotu primjetno je da su stupci bili filtrirani (razdoblje knjiženja). 

Potrebno je samo da isključite ili izmijenite navedeni filtar. 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Glorija 


13254 

Greška prilikom deklariranja - 217 - vidi prilog 



22.03.2013 09:17 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


25.03.2013 



Ispravljena je greška koja se javljala kod pregleda na ekranu za unos podataka za R1. 


Instalacija: Novi WIN FAUS će biti dostupan u ponedjeljak 25.03.2013 ujutro. 


Poštovani, 





0











Klijent: 





Hitnost: 

Vrlo hitno 


Glorija 


13253 

Riješen 


22.03.2013 09:08 

Upisao: 

Božo Mišeta 

Područje: 

LCSBI 


30.03.2013 


Molim da se ispravi greška na r. br. 21 . Ostali poslovni rashodi na obrascu RDG od mjeseca rujna 2012. 

na ovamo, jer se podaci ne učitavaju ispravno. 


Poštovani, 

analizom uzroka ustanovljeno je da je razlika nastala zbog knjiženja izvan vremenskog obuhvata noćnog 

učitavanja podataka. Izvršen je ponovni load 9. mjeseca i sada podaci štimaju što se tog dijela tiče. 

Napominjemo da ETL postupak prebacivanja podataka iz LAUS-a u međubazu šalje upozorenje o pojavi 

knjiženja 12ZZ0120 izvan obuhvata noćnog loada, međutim mi nismo još zaprimili obavijest da se to ispravilozanemari-ili 

da napravimo ponovno učitavanje starijih podataka. (obavijest stiže na kontroling@posta.hr). 

Ukoliko bude još pitanja po ovom zahtjevu molimo kontaktirajte nas. Za sada ga smatramo riješenim. 

Srdačno 



0











Klijent: 





Hitnost: 



Glorija 


13252 



22.03.2013 07:51 

Upisao: 

Božo Mišeta 

Područje: 

LFINK 


27.03.2013 


Listu: fak2_jf potrebno je prilagoditi za listanje konta 120710 POTRAŽIVANJA PO OSNOVI UGOVORA ZA 

EVO-TV. 

Trenutno se lista može koristiti samo za vrstu analitike P (poslovni partner), treba je osposobiti za korištenje 

I kod ostalih analitika A. 

Specifičnost konta 120710: 

Ima dvije vrste analitike P i A,(kad se jednom zada uvjet listanja za konto 120710, neka izlista obadvije 

analitike i A i P) 

Jedan te isti laus broj razbijen je na više stavaka po dospijeću (rate), kod izlistanja po datumu dospijeća 

treba pripaziti da uzima u obzir samo stavke (rate) koje su u dospijeću, 

Ima 2 vrste dokumenta: DIG I BSS 

Na ekran liste nadodati još jedan filter “Vrsta dokumenta”, ostavljanjem nepopunjenog uvjeta lista kao I do 

sada sve vrste dokumenta, popunjavanjem uvjeta npr: “BSS” lista samo za dokumente (laus brojeve) s 

vrstom dokumenta “BSS”. 

Mijenjaju se samo Rekapitulacije po partnerima 1,2 i 3. vrsta dokumenta nije obavezna znači lista sa i bez, 

kao i do sadašnjih parametra – ključna riječ ili grupa….. da se ne pobrka kada se radi rekapitulacija za 

kupce. 



0









Poštovani, 

fak2_jf : Stanje obveza i potraživanja na datum ima dosta uvjeta/filtera od kojih bi za novu listu za EVOTV 

trebalo 

----------izbaciti 

: 

------------ 

Orgj ______ / uvijek je DTVNE 

Konto ______ / uvijek je DTVKK 

K Upišite K (kupci) ili D (dobavlja ič) / uvijek je K-Kupci 

Konto isklju enja D / suvišan zbunjujući uvjet 

Ključ na rije č _______________ 

Oblik vlasništva _ Grupa ___ Rbr _____ Hijerarhija D 

----------------- 

Zadržati : 

--------------- 

Datum knjişenja do 15/04/2013 Dospijeĺe na dan 15/04/2013 

Dospijeĺe do __30 dana do __60 dana do __90 dana 

Potraş/Obveze > od __________________ 

Oznaka prometa P Promet , S Saldo 

Analitika _______ 

--------------- 

Dodati : 

------------- 

Ispred analitike vrsta analitike A ili P . 

Ako je zadano vrsta bez šifre analitike , listaju se sve analitike zadane vrste . 

Ako nije zadana vrsta analitike listaju se sve vrste analitika 

Molimo potvrdite gore navedene stavove te pojasnite koju od lista na fak2_jf želite da se prva napravi : 

REKAPITULACIJA PO GRUPAMA 1 


REKAPITULACIJA PO SREDIŠTIMA POŠTA 1 


REKAPITULACIJA PO PARTNERIMA 1 



REKAPITULACIJA PO DIVIZIJAMA 1 


Molimo odradite pripremu i listanje za 1 kupca EVO TV ( vrsta analitike P) te pojasnite što na listama koje 

dobijete nije u skladu sa zahtjevom osim što se sad ne može listati vrsta analitike A . 

Napomena : prije listanja lista na fak2_jf radi se F1 priprema podataka jer se tražila posebna koncepcija / logiga 

ovih lista a ne jednostavni prikaz stavaka. 

Pojedinačno se (više dospijeća) i za sve analitike može dobiti stanje potraživanja na dan na listi 

potdug_jf DOSPJELA_I_NEDOSPJELA_POTRAŽIVANJA_-_KUNE 

Molimo povratne informacije - Čekamo stav HP hoće li se raditi nova lista ili ne 



0









Poštovani, 

Kako bismo riješili zahtjev ponavljamo Poslano datum i vrijeme: 15.4.2013 12:03:28 - obrada 2 . 

Status : Čekamo potvrdu/ odgovore 


trebalo 


: 

------------ 





Ključ na rije č _______________ 


----------------- 

Zadržati : 

--------------- 






--------------- 

Dodati : 

------------- 




Molimo potvrdite gore navedene stavove te pojasnite koju od lista na fak2_jf želite da se prva napravi : 










Molimo odradite pripremu i listanje za 1 kupca EVO TV ( vrsta analitike P) te pojasnite što na listama koje SAD 


Napomena : prije listanja lista na fak2_jf radi se F1 priprema podataka jer se tražila posebna koncepcija / logika 




0









Poštovani, 

Kako bismo riješili zahtjev ponavljamo Poslano: 

15.4.2013 obrada 2 te 

23.4.2013. obrada 5 

Status : Čekamo potvrdu/ odgovore 

Dakle , ne možemo dati rok niti riješiti zahtjev prije nego dobijemo odgovre/ potvrdu predloženog 


trebalo 


: 

------------ 





Ključ na rije č _______________ 


----------------- 

Zadržati : 

--------------- 






--------------- 

Dodati : 

------------- 




Molimo potvrdite gore navedene stavove te pojasnite koju od lista na fak2_jf želite da se naprave i po kojem 

prioritetu : 










Molimo odradite pripremu i listanje za 1 kupca EVO TV ( vrsta analitike P) te pojasnite što na listama koje SAD 


Napomena : prije listanja lista na fak2_jf radi se F1 priprema podataka jer se tražila posebna koncepcija / logika 




0









Poštovani, 

Zahtjev zatvaramo uz vašu suglasnost - neće se rješavati (radi se nova lista kad dođe zahtjev ) 



0











Klijent: 





Hitnost: 



Glorija 


13251 



21.03.2013 13:50 

Upisao: 

Božo Mišeta 

Područje: 

LROBD 


28.04.2013 


U prilogu dostavljam listu dokumenata RO2 (materijalna povratnica) koje nije moguće prebaciti u status 7 

(robno proknjižen) zbog javljanja greške kao u drugom prilogu. Potrebno kod slučaja neupisane Izdatnice 

povlačiti prosječnu cijenu. 


Omogučeno je knjiženje za vrstu dokumenta RO2 MATERIJALNA POVRATNIVCA NA SKLADIŠTE odnosno 

RPD POVRAT DOBAVLJAČU na materijalnim skladištima po prosječnoj trenutnoj cijeni na skladištu za one 

dokumente koje nemaju vezani pripadajući dokument odnoso izdatnicu ROM ili primku od dobavljača RPP. 



Poštovani, 





0











Klijent: 





Hitnost: 

Vrlo hitno 


Glorija 


13250 

Riješen 


20.03.2013 15:00 

Upisao: 

Božo Mišeta 

Područje: 

LFINK 


20.03.2013 


Ne dozvoljava se izmjena minimalnog datuma bez obzira što je korisnik SVEHAJDI koji ima parametrom 

definiran datum 31.12.2012. Prije spuštana FINK-a sve radilo ispravno, a nikakve izmjene nisu tražene po 

ovome. 



0









Poštovani , 

Promjena minimalnog datuma knjiženja za SVEHAJDI : 

Šifra MNDKN MINIMALNI DATUM KNJIZENJA 

Ključ SVEHAJDI 

Podatak 31/12/2012 

Sustav l1fink Zadnja Promjena 

Izmjena 

Po ključu Korisnik BILANCA 

Default ključ bilanca 

Default podatak 01/01/1994 Datum 20/03/2013 

Srijeda 

parm_fm LAUS_REF Vrijeme 12:51 

Terminal 10.3.15.30 

Kod pokušaja otvaranja naloga sa datumom knjiženja starijim tj. manjim od 01/02/2013 korisniku x ( vjerujemo 

da je SVEHAJDI iako se ne vidi ) javila se poruka da ne može.To je rađeno 20.3.2013 u 12:50 što se vidi na 

rubu ekrana . 

Razlog : za korisnika (ključ) SVEHAJDI bio je postavljen MNDKN na 01/02/2013 tada , a onda je u 12:51 

pomjenjeno na 31/12/2012 

Molimo suglasnost za zatvaranje zahtjeva - Riješen , vrsta održavanja perfektivno (nije greška u programu) 

VAŽNE NAPOMENE ZA PARAMETAR MNDKN : 

1. MNDKN parametar se čita kod prijave te da bi novi podatak 'počeo djelovati' treba se odjaviti iz LAUS-a i 

ponovo prijaviti 

Šifra MNDKN 

Izmjena D Po ključ u D Čitanje kod prijave D 

2. SVI MOGU KNJIŽITI sa 31.12.2012. osim korisnika kojima je po ključu korisnik upisan neki drugi datum . 

Smatramo ovo rizičnim i preporučujemo HITNO postavljanje na datum knjiženja za mjesec koji nije 

zaključen 

osim ako svi stvarno mogu knjižiti u 2012. godinu 

Ažuriranje pojedinih parametara 

Šifra MNDKN MINIMALNI DATUM KNJIZENJA 

Ključ * 

Podatak 31/12/2012 

Zadnja Promjena (Uradio F8) 

Korisnik BILANCA 

Datum 20/03/2013 Srijeda 

Vrijeme 12:51 

Terminal 10.3.15.30 



0









Poštovani, 

Zahtjev zatvaramo - Riješen . 

Dana 21.03.2013. u Branimirovoj 4 kod g-đe Franjić pojašnjene su kontrole kod otvaranja zatvorenog naloga . 

Vlasnik naloga je korisnik SVEHAJDI koji ima parametrom definiran datum 31.12.2012. 

Nalog ponovno otvara korisnik KATICAF koji ima parametrom definiran datum 01.02.2013. 

Nalog koji se želi otvoriti ima datum knjiženja 31.12.2012. 

Kod pokušaja otvaranja naloga , program kontrolira vrijednost parametra MNDKN za korisnika koji otvara nalog 

( u primjeru KATICAF) jer taj korisnik postaje novi vlasnik naloga . Potpuno je nevažno koju vrijednost parametra 

MNDKN ima korisnik koji je vlasnik naloga kojeg se želi otvoriti ( u primjeru SVEHAJDI) . 

Dakle, program ne dozvoljava da KATICAF otvori nalog sa datumom knjiženja 31.12.2012. i postane njegov 

valsnik jer je za korisnika KATICAF postavljeno u MNDKN da može raditi sa nalozima kojima je datum knjiženja 

veći ili jedank 01.02.2013. 



0











Klijent: 



Izmjena na podacima/bazi - uslijed 

greške u aplikaciji 


nova hijerarhija 

Hitnost: 



glorija 


13249 

Riješen 


20.03.2013 10:58 

Upisao: 

Dajana Lekić 

Područje: 

LCSBI 


22.04.2013 


26.03.2013 

S obzirom na to su upute i hijerarhija za 2012. i 2013. godinu u DDRDG-u ponovno nadograđene u odnosu 

na prethodno stanje, potrebno Laus /CS-a da se, pored standardnog učitavanja, 

učitati i najnoviju (zadnju) verziju : 

standardne hijerarhije za DDRDG, 

hijerarhija ANALITIKAPARTNER, i 

hijerarhija NIVO_KNJIZENJA. 



0









Poštovani, 

sve navedene hijerahrije su učitane. 

s ponedjeljka će hijerarhija za 2013 za ddrdg biti postavljena kao defaultna. Kada se postavi za defaultnu onda 

ćemo zatvoriti ovaj zahtjev. 


Poštovani, 

ustanovljeno je da 2013 hijerahija koja je učitana nešto ne štima pa će se i to istražiti... 


Poštovani, 

utvrđeno je da upute za DDRDG u stupcu za 2013. godinu su zadane s kontima iz 2012. godine. To je uzrok 

nepostojanja odnosno pogrešne hijerarhije za 2013. godinu. ovaj dio adaptivnog održavanja (ispravak uputa kroz 

bazu kako korisnik ne bi trebao potrošiti više od jednog dana mijenjajući tisuću redaka ručno) odraditi će se kroz 

drugih LAUS zahtjev s istim HP brojem zahtjeva. 


Poštovani, 

hijerarhije su učitane (prošli tjedan), isprike na zakašnjelom zatvaranju zahtjeva. 



0











Klijent: 





Hitnost: 

Nije hitno 


Glorija 


13248 



20.03.2013 09:20 

Upisao: 

Božo Mišeta 

Područje: 

LSLOD 


30.04.2013 

Sve ispise na navedenim objektima omogućiti na opciju listanja Excel-mail. 

Invs_fi,invp_fi 



Na objektu invs_fi napravljene su excel verzije ispisa. Ostaje još za napravit excel ispise na objektu invp_fi. 

Instalacija: U srijedu 10.03.2013 bit će dostupan novi LAUS SLOD lib. 


Na objektu invp_fi omogućen je ispis lista u excel. 

Instalacija: U četvrtak (11.04.2013) ujutro bit će dostupan novi LAUS SLOD lib. 


Na objektu invp_fi omogućen je excel ispis. 

U utorak 16.04.2013 bit će dostupan novi LAUS SLOD lib. 


Poštovani , 





0











Klijent: 





Hitnost: 



višnja 


12600 



19.03.2013 15:22 

Upisao: 

Dajana Lekić 

Područje: 

EPNAB 


31.10.2012 


U ovom KZ se rješavaju točke koje su inicijalno bile KZ 39036 , HP broj 12600 (korektivno) a po dogovru 

sa HP se odnose na adaptivno održavanje . 

Potrebno riješiti točke : 

2. Nakon poništenja postupka ne bi trebao zatvarati tab "Postupak" - to ostaje da se vidi… - 1 sat 

5. Plan nabave - Transakcija Izmjene i dopune (ili uređivanje) - Izmjene plana nabave koje neće biti 

zabilježene u dnevniku promjena. - 8 sati 

8. Jamstva - treba se pojaviti samo zapisi gdje je prethodno odabran neki "Nema", a ne svi 

ugovori... - 1 sat 

Odustalo se od rješavanja točaka : 

4. Kroz Evidencije - Potvrde o UIU - nedostaje inline attachment. 

6. Polje Interni status na Spis bagatelne, Spisu postupka i Pojedinačnom spisu po grupama u detail 

gridu Povijest statusa – MULTISELECT (mogućnost odabira više razloga poništenja). 



0









Poštovani, 

U ovom KZ se rješavaju točke koje su inicijalno bile KZ 39036 , HP broj 12600 (korektivno) a po dogovru sa HP 

se odnose na adaptivno održavanje . 

Potrebno riješiti točke : 

2. Nakon poništenja postupka ne bi trebao zatvarati tab "Postupak" - to ostaje da se vidi… - 1 sat 

5. Plan nabave - Transakcija Izmjene i dopune (ili uređivanje) - Izmjene plana nabave koje neće biti 

zabilježene u dnevniku promjena. - 8 sati 

8. Jamstva - treba se pojaviti samo zapisi gdje je prethodno odabran neki "Nema", a ne svi ugovori... - 1 

sat 

Odustalo se od rješavanja točaka : 

4. Kroz Evidencije - Potvrde o UIU - nedostaje inline attachment. 

6. Polje Interni status na Spis bagatelne, Spisu postupka i Pojedinačnom spisu po grupama u detail gridu 

Povijest statusa – MULTISELECT (mogućnost odabira više razloga poništenja). 


Poštovani, 

Naveli ste : 

1. Kako je rečeno da se za točku 2, 5, 6 i 8 zahtjeva otvara kod vas novi broj zahtjeva, napominjem da se od 

točaka 4 i 6 odustalo od rješavanja. 

1. Komentar: slažemo se s navedenim . 

2. Dakle u novi zahtjev ulaze sano točke 2, 5 i 8. 

2. Komentar : potrebno je i za točke 4 i 6 evidentirati vrijeme potrošeno na procjenu . Zato su i one sztavljene u 

ovaj novi KZ iako se od njih odustalo 


Poštovani, 

Izmjene su prebačene na testni server. 

Lp, 


Poštovani, 

Dostavljamo status po točkama zahtjeva : 

2. Riješeno Izmjene su prebačene na testni server (30.4.2013.) - molimo povratne informacije 

4. Odustalo se od rješavanja 

5. U rješavanju 





0









Poštovani, 

Danas smo zaprimili obavijest (Višnja) : 

Kako se po zahtjevu 13132 odustalo od riješavanja: 

Točka 2 - Plan nabave - inline uređivanje predmeta nabave - Rebalans, generalno funkcioniranje 

a po zahtjevu 12600 ima istu problematiku : 

Točka 5. Plan nabave - Transakcija Izmjene i dopune (ili uređivanje) - Izmjene plana nabave koje neće biti 

zabilježene u dnevniku promjena 

točku 5 zahtjeva 12600 nije potrebno riješavati. 







Dakle, samo točka 8 ostaje za riješiti 


Poštovani, 

Točka 8. zahtjeva je prebačena na test. Sada se u registru Jamstva, prikazuju samo oni ugovori koji na ugovoru 

imaju označeno da imaju jamstva. 






8. Riješeno . Izmjene su prebačene na testni server (06.05.2013.) - molimo povratne informacije 

Dakle, sve točke zahtjeva od kojih se nije odustalo su riješene i isporučene na testni server. 

Molimo povratne informacije/ suglasnost za prebacivanje na produkciju - Riješeno 



0









Poštovani, 

Točka 8 zahtjeva je prebačena na produkciju. 

Sada se u registru Jamstva, prikazuju samo oni ugovori koji na ugovoru imaju označeno da imaju jamstva. 


Nakon što postupak ode u status Nabava poništena i Nabava nije realizirana, ne sakriva se tab Postupak već 

ostaje vidljiv. 


2. Riješeno 8.5.2013. na produkciji 




8. Riješeno . 8.5.2013. na produkciji 

Dakle, sve točke zahtjeva od kojih se nije odustalo su riješene i isporučene na produkciju . 

Molimo povratne informacije/ suglasnost za zatvaranje zahtjeva - Riješeno 


Poštovani, 


Sada se u registru Jamstva, prikazuju samo oni ugovori koji na ugovoru imaju označeno da imaju jamstva. 


Nakon što postupak ode u status Nabava poništena i Nabava nije realizirana, ne sakriva se tab Postupak već 

ostaje vidljiv. 


2. Riješeno 8.5.2013. na produkciji 




8. Riješeno . 8.5.2013. na produkciji 

Dakle, sve točke zahtjeva od kojih se nije odustalo su riješene i isporučene na produkciju . 

Molimo povratne informacije/ suglasnost za zatvaranje zahtjeva - Riješeno 






Poštovani, 

Zahtjev zatvaramo uz vašu suglasnost - riješen 



0











Klijent: 






Vrlo hitno 




13247 

Riješen 


19.03.2013 13:52 

Upisao: 

Boško Tokić 

Područje: 

LWINFAU 


26.06.2013 

Molim doradu objekta art_fas u Uvjetima za pregled šifri artikala: 

-Po cijeni 

-Po datumu po pravilu „na dan pretraživanja“ i mogućnost upisa datuma OD - DO (kada je cijena važila) 

-s prikazom cijene u tablici 

-ispis artikala sa svim podacima prema uvjetima pregleda u excel-u 

(prilog) 


Napravljene su dorade na objektu art_fas. 

U uvjetima za pregled nadodana su polja za pregled po datumu kada važi cjenik te po cijeni. 

U pregledu se prikazuje datum od - do cjenika i maloprodajna cijena. 

Omogućen je i excel ispis podataka. 

U četvrtak 27.06.2013 bit će dostupan novi WIN FAUS lib. 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Višnja 


13246 

Riješen 


19.03.2013 11:36 

Upisao: 

Božo Mišeta 

Područje: 

LKROP 


29.03.2013 

Kroz izvj_clr_jk PORUKE IZ OBRAČUNA već je traženo da se: 

Neto iznos iskazan na listi umanji za NAKNADU PRIJEVOZA. 

Potrebno je izvršiti traženu izmjenu. 



Poštovani 

po LAUS zahtjevu 41110 a HP zahtjevu 13098 već je napravljeno slijedeće: 

Neto u porukama koje se odnose na brisanje obustava je izmjenjen tako da nije krajnji neto za isplatu već neto 

bez naknada, 

stoga nam nije jasno na koje se poruke točno misli.Molimo pojašnjenje. 

Pozdrav 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Ivan 


13245 



19.03.2013 07:46 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


31.03.2013 


Na objektu 

vrrab.jas Unos vrste rabata treba proširiti polje za unos Vrste rabata na tri slovna mjesta 



0









Na objektu vrrab.jas Unos vrste rabataprošireno je polje za unos Vrste rabata na tri znaka. 

Izmjena je napravljena i na ekranu za unos raspona rabata (usrtab_fas). 

Na ekranu za unos stavki ugovora (ugovor2_fas) proširena su polja Komercijalni rabata i HPX rabat na 3 znaka. 


Ttreba odraditi i sql-ove: 

ALTER TABLE lm_vr_rab MODIFY ( 

vr_rab char(3) not null ); 

ALTER TABLE lm_rab_ras MODIFY ( 

vr_rab char(3) not null ); 

ALTER TABLE lm_ugv_stav MODIFY ( 

rab_kom char(3), 

rab_hpx char(3)); 


Na ekranu pregleda stavki ugovora proširena su polja 'HPX' i 'KmR' na 3 znaka. 




Poštovani, 





0











Klijent: 





Hitnost: 



Ivan 


13244 



19.03.2013 07:44 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


31.03.2013 


Na objektu 

Spmt.jas : spmtis_fas Ispis masovni PU-zone dodati polje za masovni ispis rekapitulacija po mjestima 

troška za fakture po zonama. 

Masovni ispis rekapitulacija izgledom treba biti isti kao kod pojedinačnih ispisa faktura kroz polje Ispis PUzone. 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13243 



19.03.2013 07:39 

Upisao: 

Božo Mišeta 

Područje: 

LNABD 


22.03.2013 


Kod ispisa narudžbe dobavljaču, omogućiti ispis narudžbe (NRDzga3_rg) u excel - mail. 


Na ispisu narudžbe od dobavljača vrste dokumenta NRD (NRDul_jg) omogučen je ispis u excel 

NRDzga3_xls_rg . 

Potrebno je preuzeti laus nabd lib koji će biti na internetu 26.03.2013. 


Poštovani, 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13242 



18.03.2013 13:59 

Upisao: 

Božo Mišeta 

Područje: 

LNABD 


22.03.2013 


Kod objekta NRDul_jg NARUDŽBA DOBAVLJAČU trenutno nije moguće korisnicima dodijeliti dozvolu na 

određeni status, objekti za dodjelu statusa ne postoje u tablici nobjekt. 



0









Poštovani, 

na zadnjem razgovoru oko objekata NRD (predavanje u petak) nisam shvatio konačnu odluku - zahtjev. 

Osim statusa 1 - unos dokumenta, (skladište) treba li oformiti 

i statuse - faze obrade dokumenta 

status 2 - Skladište završilo NRD komercijala kontrolira (i dalje je moguć unos, izmjena , brisanje stavaka i 

dokumenta) 

status 3) - NRD kompletirana - poslana dobavljaču (dokument završen, nisu moguće bilo kakve izmjene 

ili je dovoljno da dokumenat ima samo statuse 1 i 2 

status 1 - unos 

status 2 - završen dokument 

S štovanjem 


Otvoren je novi objekt NRD1 UNOS NARUDŽBE. 


Potrebno je preuzeti laus objekte i meni-e koji će biti n ainternetu 22.03.2013. 


Otvorena su dva nova objekta NRD2 i NRD3 te je potrebno korisnicima dodjeliti dozvole. 

Kroz izvođenje modula objekt obj_fm potrebno je ažurirati sljedeće objekte odnosno njihove nazive : 

objekt tip naziv 

NRD2 G KOREKCIJA NARUDŽBE 

NRD3 G KOMPLENTIRANA NARUDŽBA 

NRD12 H KOREKCIJA NARUDŽBE 

NRD23 H KOMPLENTIRANA NARUDŽBA 

te ostale objekte koji počinju sa NRD i tipa H potrebno je izbrisati. 

Kroz objekt stu_ja UPUTE za prelazak status za vdok NRD je potrebno izbrisati. 



Na zaglavlju dokumenta NRD Narudžba od dobavljača u statusu 2 potrebno je izmjeniti key-set tipki preko tipke 

F7(TIPKE) dok se prikaže na F2(IZMJENA) da bi se omogučila izmjena dokumenta.. 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Glorija 


13241 



18.03.2013 13:56 

Upisao: 

Božo Mišeta 

Područje: 

LOSSA 

Prilikom izlistanja liste lsta_fo (početno stanje) javlja se greška. 


18.03.2013 



Ispravljena je greška na listi stankp_ro Ukupni iznosi po kontima (početna stanja). 

Preuzeti bovi LAUS OSSA liba u petak 22.3.2013 


Poštovani, 

zbog hitnosti riješavanja ovog zahtjeva, LAUS OSSA lib je prebačen na internet, možete ga preuzeti! 

S štovanjem 



Poštovani, 



Nakon zuadnje obrade 21.3.2013. nije bilo primjedbi : 

zbog hitnosti riješavanja ovog zahtjeva, LAUS OSSA lib je prebačen na internet, možete ga preuzeti! 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Ivan 


13240 



18.03.2013 13:54 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


20.03.2013 


Na objektima 

rucfak.jas Pregled i ručni unos faktura 

rucpred.jas Predračun bez ugovora 

polje „Briši“ treba imati funkciju prebacivanja evidentiranog dokumenta (dodijeljenog laus broja) u status 

nula „0“ 


Na objektima: 

rucfak.jas Pregled i ručni unos faktura 

rucpred.jas Predračun bez ugovora 

tipka „Briši“ promjeni status evidentiranog dokumenta u status 0. 

U petak 03.05.2013 bi će dostupan novi WIN FAUS lib. 


Poštovani, 





0











Klijent: 





Hitnost: 

Vrlo hitno 


Ivan 


13239 

Riješen 


18.03.2013 13:52 

Upisao: 

Božo Mišeta 

Područje: 

LROBD 


20.03.2013 


Potrebno je kod prijenosa podataka iz MIPSa preko objekta: 'amb_jd PRIJENOS PODATAKA IZ MIPS- 

A' omogućiti i prijenos polja mips_laus@mips_laus:promet_pu:serbrstb u LAUS sustav 


Omogučen je prijenos seriskog broja stb uređaja iz mips_laus@mips_laus:promet_pu.serbrstb -> hp0.serbrstb 

preko objekta amb_jd prijenos prometa podataka iz mipsa. 

Potrebno je preuzeti laus libove rob0,rob1,rob2,rob3 i rob4 koji će biti na internetu 4.4.2013 te izvesti sql. 


Poštovani, 

Molimo povratne informacije/ suglasnost za zatvaranje zahtjeva - Riješen . 





Omogučen je prijenos seriskog broja stb uređaja iz mips_laus@mips_laus:promet_pu.serbrstb -> hp0.serbrstb 

preko objekta amb_jd prijenos prometa podataka iz mipsa. 

Potrebno je preuzeti laus libove rob0,rob1,rob2,rob3 i rob4 koji će biti na internetu 4.4.2013 

izvesti sql : alter table hp0 add serbrstb char (32) before stavka 



0











Klijent: 





Hitnost: 



Višnja 


13238 



18.03.2013 13:46 

Upisao: 

Božo Mišeta 

Područje: 

LKROP 


30.03.2013 


19.04.2013 

Kroz kdan_jk KADROVSKI PODACI O RADNICIMA NA DAN na excel-mail listi kdan_rk.csv potrebno 

je izvršiti slijedeće izmjene: 

-Dodati stupac o radnom mjestu po RS-u iz stupaca ORG po RS-u 

-Popuniti prazne nazive u stupcima redom: 

Prezime i ime radnika, Naziv pošte, Naziv organizacijske jedinice po RS-u, Naziv radnog mjesta po RS-u, 

Naziv radnog mjesta po RP-u, Prezime i ime radnika zamjene, Naziv mjesta rada, Naziv županije rada, 

Naziv završene škole 


Na izvješću sa objekta kdan_jk dodano je radno mjesto stalnog rasporeda iza org. jedinice stalnog 

rasporeda.Provjerena su ostala polja.Ukoliko nalazite da se neki podaci ne ispisuju molimo da pošaljete primjer 

izvješća na kojem se vidi koji podaci nedostaju. 

Preuzmite: krop lib od 17.04.2013 


Na izvješću kdan_jk napravljene su dorade: 

- provjereno ispravljeno čitanje podataka za org. grupu 

- naziv divizije od sada se čita za org. jedinicu stalnog rješenja. 

Preuzmite: Krop lib (već je na internetu). 


Na excel izvješću sa objekta kdan_jk naziv stupca Radno mjesto izmijenjen je u Radno mjesto privremenog 

rasporeda. 

Preuzmite: krop lib (već je na internetu). 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13237 



18.03.2013 13:44 

Upisao: 

Božo Mišeta 

Područje: 

LROBD 


22.03.2013 


Na ekranu katpu_p_fa dodati funkcijsku tipku „KOPIRAJ“ kojom bi se izabrala kategorija PU sa svim 

pridruženim PU i kopirala u novu kategoriju PU s novim nazivom. 

Prije kopiranja ponuditi ekran za unos šifre kategorije PU koja automatski povlači i naziv. 


Na objektu katpu_ja Kategorija PU preko F6(TIPKE) na F1(KOPIRAJ) te pozicinoranjem na određenu 

kategorija pu omogučeno je kopiranje kategorije pu sa svojim pripadajućim pu-ima. 



Poštovani, 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13236 



18.03.2013 13:40 

Upisao: 

Božo Mišeta 

Područje: 

LROBD 


22.03.2013 


Na ekranu NRDpd_pr_fg kod pritiska tipke F5 – Pregled ne dobije se pregled narudžbi dobavljaču. 

Primjer sa testne baze: 

Naružbu možemo vidjeti samo ako na ekranu NRDzg_fg ukucamo njen broj+F1- Dalje 

Pazi!!! Ovo su probali samo na HP tesnoj bazi! 


Ispravljen je pregled narudžbi NRD na pregledu dokumenta vrste dokumenta NRD. 



Poštovani, 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13235 



18.03.2013 11:02 

Upisao: 

Božo Mišeta 

Područje: 

LROBD 


21.03.2013 


U dokumentu “Povrat robe iz maloprodaje” u polje originalni broj se sada puni originalni mips broj 

dokumenta. 

U istom polju, uz orginialni broj dokumenta, potreban je prikaz i godine i PU iz kojeg je došao povrat (vidi 

sliku). 

Npr. broj dokumenta – 29, godina – 2013, PU (mips broj PU) – 10139. 



0









Poštovani, 

U prijenosu ne postoji definirana mips šifra PU nego samo laus šifra. Veza između mips i laus šifre PU je 

definirana preko dodatnog podatka SS2 vezanog na laus org.jedinicu. Pošto je na jednu laus šifru preko 

dodatnog podatka vezano više mips šifri, ne možemo znati koju mips šifru PU trebamo uzimati 

Jedino ispravno rješenje je proširenje prijenosa sa mips šifrom PU i preuzimanje toga podatka u laus. 

Molimo vas da kontaktirate sa MIPS-om, te tražite da MIPS šifru PU šalju unutar sloga dokumenta Povrat u 

skladište iz PU. 

S štovanjem 


Poštovani, 

Tablica mips_laus_pu sadrži podatke sa dodatnim tipom SS2. 

Postoji po dva sloga za laus šifre_pu: 

laus_pu mips_pu aktivnost 

20013 10005 D 

20013 10006 D 

31012 10000 D 

31012 10989 D 

U slučaju da u prijenos dođu slogovi sa laus šifrom 20013 ili 31012 ne možemo znati koju mips šifru trebamo 

uzeti. Zašto ova dva laus PU imaju definirane po dvije mips šifre pu? 

S štovanjem 



0









Poštovani, 

Molimo stav HP vezano za rješavanje ova 2 slučaja : 

1.slučaj : nedostaju SS2 veze 

Prijedlog : upisati nedostajuće SS2 veze . 

2. slučaj : Za višestruke SS2 veze potrebno je navesti kriterij po kojem će se određivati mips šifra PU . 

Prijedlog : minimalni tekst** . Za orgj 31012 min(tekst) = 10000 pa se 10000 upisuje u mips_pu a druga SS2 

veza 10989 se zanemaruje . 

----------------------primjeri za 1. slučaj 

1. LAus šifre pu koje uz sebe nemaju mips šifru PU u prilogu HP-a mips_laus_pu.xls : 

31005 

31009 

31232 

31849 

31705 

35366 

31424 

31514 

Razlog : 

a) Nema ništa upisano u orgjdod.tekst za tipp=SS2 

orgj tipp tekst 

31005 SS2 

31009 SS2 

31232 SS2 

31849 SS2 

31705 SS2 

35366 SS2 

31424 SS2 

31514 SS2 

b) nema ništa upisano za njih u mips_laus@mips_laus:mips_laus_pu.mips_pu 

mips_pu laus_pu aktivnost 

31005 D 

31009 D 

31232 D 

31849 D 

31705 D 

35366 D 

31424 D 

31514 D 

-----------primjeri za 2.slučaj 

orgj tipp tekst 

20013 SS2 10005 ** 

20013 SS2 10006 

31012 SS2 10000 ** 

31012 SS2 10989 

Za orgj 31012 min(tekst) = 10000 pa se 10000 upisuje u mips_pu a druga SS2 veza 10989 se zanemaruje . 



0









Poštovani, 

Molimo odgovor na postavljeni upit po ovom zahtjevu. 

S šrovanjem 


Na dokumentu RPM Povrat iz maloprodaje (iz mips-a) na zaglavlju dokumenta u polju originalni broj ispisuje 

se mips broj u formatu mips broj dokumenta - godina dokumenta - šifra PU-a i ako takav vidi se na pregledu 

dokumenta . 

Potrebno je preuzeti laus libove rob0,rob1,rob2,rob3 i rob4 koji su na internetu 24.04.2013. 


Poštovani, 




0











Klijent: 





Hitnost: 

Vrlo hitno 




13233 

Riješen 


15.03.2013 15:14 

Upisao: 

Boško Tokić 

Područje: 

LKROP 


20.03.2013 


Kroz dis_ban_fk DISKETE ZA BANKE preko SBERBANK d.d. (VOLKSBANK) potrebno je ispraviti slog 

datoteke za neto plaću SBERBANK d.d. na način da se na kraju datoteke ukloni jedan prazan red (izgled 

priloga u tekstu ispod). 

Prilog: 

3201802634NADA BA IĈ PLAĈA 02/13 0000000299336 

3201662526KORNELIJA BARIĈ PLAĈA 02/13 0000000194860 


Datoteka za Sberbank je pregledana i ispravljena,sada ima jednom oznaku CRLF na kraju svake linije. 


krop i base libovi od 22.03.2013 


Problem je bio kod slanja mailom,dva puta se dodavao znak CRLF dok se kod slanja u datoteku to nije 

događalo.Sada je program z s lanje mailom ispravljen. 


BASE lib od 25.03.2013. 



0











Klijent: 





Hitnost: 

Vrlo hitno 




13232 



15.03.2013 14:43 

Upisao: 

Boško Tokić 

Područje: 

EPNAB 


18.03.2013 


Potrebno je korisnika Matiju Popovića unijeti kao korisnika u ePlanNabave po organizacijskoj jedinici: 

HP-03 - URED ZA UPRAVLJANJE PROJEKTIMA I ORGANIZACIJOM 

Korisnik je kroz administraciju ePlanaNabave otvoren kao korisnik sa ulogom Tehnički nositelj, ali ga nije 

moguće unijeti kroz: 

ePlanNabave->Administracija->Postavke svih korisnika jer nije moguće unositi korisnike već samo ažurirati 

korisničke postavke. 

Potrebno je omogućiti unos novih korisnika kroz ePlanNabave samo korisniku sa ulogom HP Administrator. 



0









Poštovani, 

Na testnom linku je omogućen je unos novih korisnika za aplikaciju ePlanNabave za korisnike s ulogom HP 

Administrator. Dodavanje se obavlja kroz aplikaciju za administriranje koja se nalazi na linku: 

http://sv-1ot-eaptest.posta.int/ePlanNabave_Admin_Test 



Poštovani, 

Nakon što dodate novog korisnika u aplikaciju za administriranje ePlanaNabave, potrebno se s njegovim 

korisničkim imenom i lozinkom ulogirati u 

aplikaciju ePlanNabave. Tek nakon toga korisnik postaje vidljiv u korisniičkim postavkama u aplikaciji 

ePlanNabave. Potrebno je odlogirati se kao korisnik i ulogirati kao HP administrator i tada se korisniku može 

dodijeliti organizacijska jedinica. 


Poštovani, 

Uz vašu suglasnost zahtjev zatvaramo - Riješen 



0











Klijent: 





Hitnost: 

Vrlo hitno 




13231 



15.03.2013 11:56 

Upisao: 

Boško Tokić 

Područje: 

LWINFAU 


25.03.2013 


Potrebno je oformiti novu listu kroz win sučelje za potrebe konta 120710. 

Specifičnost konta je velika količina podatka, vrsta analitike A i P, te jedan laus broj razbijen na više 

stavaka po datumu dospijeća. 

1)Lista mora imati import podataka u excel i sve elemente navedene u tablici (tablica excela bez proreda, 

sve tavke jedne transakcije u jednom redu), 

2)Mogućnost izbora parameter kod printanja ili importa u excel: 

Filteri: Konto, Analitika, Stavke, Godina, Datum balance, Datum dospijeća, Strana, Vrsta dokumenta 

(detaljniji opis u tablici u prilogu). 

3)Opis se mora vidjeti u cijelosti 

Prilozi: izvještaj_evotv 


Poštovani, 

Zahtjev zatvaramo uz vašu suglasnost - Neće se rješavati 



0











Klijent: 





Hitnost: 

Vrlo hitno 




13230 



15.03.2013 11:49 

Upisao: 

Boško Tokić 

Područje: 

LWINFAU 


18.03.2013 


Na objektu fakot_fas isti broj odobrenja, nema fiskalni broj. 

Fiskalni broj treba se ispisivati na mjestu sadašnjeg Laus broj odobrenja. 

Laus broj odobrenja treba se ispisivati lijevo, u ravnini s Matičnim podacima i adresom kupca. 

Kad se to bude napravilo, molila bi da se i 

-„Odobrenje br.“ centrira 

-Adresni dio od MB do kraja adrese, pomaknuti u desno, kako bi se u kuverti s desnim prozorom adresa 

mogla čitati 

-U zadnjem dijelu odobrnja „OBAVIJEST O ISPRAVKU PRETPOREZA“, smanjiti razmake između broja 

računa i datuma, zatim između datuma i „u svoti“, maknuti razmak do riječi „od“ , dodati crtu na koju će se 

ispisivati iznos do „kn“ , iza teksta „obavili smo dana“ dodati crtu za upis datuma. Kompletni tekst poravnati 

do margina. 

(prilog) 


Poštovani, 

Molimo suglasnost za aztvaranje zahtjeva - Riješen kroz druge zahtjeve 

Zahtjev je riješen kroz druge zahtjeve na tamu ispis fiskalnog broja kao glavnog broja na računu (umjesto LAUS 

broja) . 

Ako ipam ima primjedbi na ispis odobrenja na fakot_fas molimo pošaljite 

- pogrešne ispise kao pdf datoteke 

- LAUS broj odobrenja iz zahtjeva jer se u prilogu ne vidi te ne možemo provjeriti stanje u bazi. 

status : Čekamo stav HP-a 



0











Klijent: 





Hitnost: 





13229 



15.03.2013 11:33 

Upisao: 

Boško Tokić 

Područje: 

LWINFAU 


31.03.2013 


Na ispisu fakture 46277-012-03783 ne ispisuje se Dospijeće tj. iza Dospijeće fale : i nema datuma. Faktura 

iz predhodne godine tj. nije fiskalizirana. 


Poštovani, 

Faktura 46277-012-03783 je nastala kroz objekt natječajne dokumentacije. Na tom objektu postoji polje Plaćeno 

i datum koji se tu upiše se prikazuje na fakturi kao Dospijeće. To polje na ekranu nije obvezno za unos pa za ovu 

fakturu nije ni upisano. Zbog toga se ne prikazuje na fakturi. 

Ukoliko je objašnjenje dostatno molimo suglasnost za zatvaranje zahtjeva - Riješen te promjenu vrste 

održavanja u PERFEKTIVNO 

Ako je potrebno staviti da je to polje obvezno za unos ili da se na neki drugi način upisuje datum koji će se 

prikazivati kao dospijeće na ispisu 

molimo pošaljite zahtjev ADAPTIVNO . 


Poštovani, 




0











Klijent: 





asorl.trn 

Hitnost: 

Vrlo hitno 


katja 


13228 



14.03.2013 20:03 

Upisao: 

Dajana Lekić 

Područje: 

WINTRAN 


18.03.2013 


Veza zahtjev br.13100 

1)Kod liste asortimana (2.POPIS ASORTIMANA PO PU) : 

-Omogućiti ispis pojedinačnih i svih asortimana 

-Dodati labele datum od / do 

-omogućiti ispis pojedinačnih kriterija (asortiman, artikl, PU) 

-Kod unosa podatka PU omogućiti unos MIPS šifre PU po principu da u polje PU upisujemo mips šifru PU 

- Na listi: asorl2 preimenovati stupac “Naziv PU” u “PU” 

2.) Kod liste (3. POPIS KATEGORIJA PU) 

- Kod unosa podatka PU omogućiti unos MIPS šifre PU 

- Omogućiti ispis podataka i za kriterij "Kategorija" 

- Na listi: asorl3 preimenovati stupac “Naziv PU” u “PU” 


Na objektu asorl.trn LISTE asortimana omiogučeno je za listu 2.Popis asortimana po PU filtriranje po datumu od 

do kada vrijedi asortiman te ispis pojedinačni za asortiman,artikali PU. 

Za listu 3. Popis Kategoriju PU omogučeno je filtriranje po mips šifri PU i laus orgj te ispis za određenu 

kategoriju PU. 

Potrebno je preuzeti win tran lib koji je na internetu 21.03.213. 



0











Klijent: 



Pitanje 


hp_Pknj_jd 

Hitnost: 



glorija 


13227 



14.03.2013 19:31 

Upisao: 

Dajana Lekić 

Područje: 

LROBD 


20.03.2013 


20.03.2013 

hp_Pknj_jd PRIPREMA DOKUMENATA (PU) ZA KNJIŽENJE U GL.KN 

Nakon pripreme i knjiženja datuma 01.02.2013. ostao je neknjiženi dokument u prilogu. Dokument je 

depoa, a knjižen je kroz nalog 136D0044 od 22.02.2013. 


Prilikom pripreme dokumenta PU-a dodano je da samo ulaze dokumenti koji simaju vezu laus->mips dokument 

(mldok). 

Preuzeti laus libove rob0,rob1,rob2,rob3 i rob4 koji će biti na internetu 16.03.2013 te izvesti sql: 

delete from hp_pknj where protokol='35358R1302333' 



0











Klijent: 





odobrenja na rucfak i fakis 

Hitnost: 

Vrlo hitno 


ivan 


13226 



14.03.2013 19:27 

Upisao: 

Dajana Lekić 

Područje: 

LWINFAU 


15.03.2013 


15.03.2013 

Kod ispisa odobrenja preko objekta fakis.jas i rucfak.jas ispis ne radi dobro. 

Iznosi u zbronom dijelu fakture su prazni, nema broja fakture na koju se odobrenje radilo, nema napomene, 

nema odgovorne osobe …. 


Poštovani, 

Isprtavljena je greška koja se javljala kod ispisa odobrenja. Greška je bila kod odobrenja koja su fiskalizirana. 


: novi WIN FAUS je već na internetu 


Poštovani, 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Ivan 


13226 



14.03.2013 15:34 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


14.03.2013 


14.03.2013 

Kod ispisa odobrenja preko objekta fakis.jas i rucfak.jas ispis ne radi dobro. 

Iznosi u zbronom dijelu fakture su prazni, nema broja fakture na koju se odobrenje radilo, nema napomene, 

nema odgovorne osobe …. 


Poštovani, 

Greškom smo duplo evidentirali isti zahtjev i u KZ 41936 za kojeg smo već vezali RZ . 

Zato ovaj zatvarmo - dupli zahtjev 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Glorija 


13225 



14.03.2013 14:55 

Upisao: 

Božo Mišeta 

Područje: 

LBASE 


20.03.2013 


Prilikom likvidacije računa u eObradi unesen neispravan datum računa dobavljača Vindije i poslan je u 

LAUS. Račun je u LAUS-u dobio broj 40013-413-11559. 

Račun se vraća na korekciju datuma. Do nedavno su se takvi računi mogli bez problema ispravljati . 

Kod ovog računa je problem šje to kada promijeni se datum računa ( F2), program sam promijeni PDV i 

smanji ga za jednu lipu pa se ne može ispraviti. Ovo nije prvi slučaj, ali se to rješava na način da se ispravi 

datum i kada LAUS promijeni PDV – dođe se do iznosa PDV-a promijeni se ga i stisne enter pa F2 i tada 

program ispravno promijeni PDV. 

U prilogu šaljem račun prije ispravka = u LAUS-u je ispravna razrada PDV-a i nakon pokušanog ispravka 

=promijenjenog datuma računa- (F2) 



0









Poštovani, 

ovako je došlo iz eObrada za račun 40013-413-11559. : 

Ukupni iznos 468.67 

Neoporezivi dio 0.00 

Stopa Osnovica PDV Za odbiti 

Razrada 25.00 25.00 _________304.58 _________76.15 _________76.15 

PDV-a 5.00 _5.00 __________83.76 __________4.19 __________4.19 

388.34 80.34 

zbrojeno osnovice + porezi =388.34 + 80.34 = 468.68 što je za 1 lipu tj 0.01 kn veće od ukupnog iznosa računa 

468.67 

Kad se radi F2 Izmjena izmjena , odrade se i validaciej/kontrole pa se radi i kontrola pdv i izračuna se : 

304.58 *0.25 = 76,145 - zaokruženo daje 76.14 jer je 4 neparn ispred 5 . 

tako se PDV promijeni sa 76.15 na 76.14 tj. umanji za 0.01 kn pa se odobije : 

zbrojeno osnovice + porezi =388.34 + 80.33 = 468.67 što je jednako ukupnoom iznosa računa 468.67 (kako se 

vidi na prvom ekranu) 




Razrada 25.00 25.00 _________304.58 _________76.14 _________76.15 

PDV-a 5.00 _5.00 __________83.76 __________4.19 __________4.19 

388.34 80.33 

U polju Za odbiti iznos 76.15 se NE ažurira na 76.14 (kao PDV) jer ne smije biti veći od PDV-a . Ako je manji ili 

jedank PDV-u ne mijenja se. 

Ako je veći , postavi se kao PDV tj jedank PDV. (gleda se apsolutni iznos ) 

Ovo se u primjeru nije dogodilo sa F2 izmjena ,ali se uvijek dogodi po izlasku iz PDV polja ili F5 Kon/Lik i javi se 

poruka : 

Iznos za odbiti ne odgovara PDV-u ! 

Poruka : Prekontrolirajte iznose na računu! pretpostavljamo da se javila jer se mijenjao ukupni iznos računa 

(ne vidi se na slici) 

Ne možemo simulirati slučaj pa molimo suglasnost da telefonski kontaktiramo g-đu Snježanu Kramer ili koga 

HP odredi radi rješavanja zahtjeva 


Poštovani, 

dogovreno je : 

dozvoliti toleranciju +/- 0.03 kn kod odstupanja pdv-a u računu i onog koji se kontrolno provodi : 

osnovica*stopa/100 - (Kramer) 



0









Poštovani, 

Kod unosa iznosa PDV na ekranu prot1_fm ugrađene je tolerancija na iznos PDV-a +/- 3 lipe gdje program ne 

gazi unseneni iznos PDV-a. 


Preuzeti novi BASE lib s interneta 22.4.2013.nadalje 


------------------ 

Pojašnjenje slučaja iz primjera : 

ovako je došlo iz eObrada za račun 40013-413-11559. : 




Razrada 25.00 25.00 _________304.58 _________76.15 _________76.15 

PDV-a 5.00 _5.00 __________83.76 __________4.19 __________4.19 

388.34 80.34 

zbrojeno osnovice + porezi =388.34 + 80.34 = 468.68 što je za 1 lipu tj 0.01 kn veće od ukupnog iznosa računa 

468.67 

Kad se radi F2 Izmjena izmjena , odrade se i validaciej/kontrole pa se radi i kontrola pdv i izračuna se : 

304.58 *0.25 = 76,145 - zaokruženo daje 76.14 jer je 4 paran ispred 5 . 

tako se PDV promijeni sa 76.15 na 76.14 tj. umanji za 0.01 kn pa se odobije : 

----------> ovo smo mijenjali da ne 'gazi' upisani porez ako je unutar +/- 0.03 kn u odnosu na izračunati u kontrolli 

zbrojeno osnovice + porezi =388.34 + 80.33 = 468.67 što je jednako ukupnoom iznosa računa 468.67 (kako se 

vidi na prvom ekranu) 




Razrada 25.00 25.00 _________304.58 _________76.14 _________76.14 

PDV-a 5.00 _5.00 __________83.76 __________4.19 __________4.19 

388.34 80.33 

Test: Nakon što smo uveli toleranciju +/- 0.03 kn odstupanje pdv-a od onog izračunatog za oosnovicu po stopi : 

Dozvoli mi upisati 76.15 umjesto 76.14 i ne 'gazi' to kad se 'šetam' po ekranu. KOd Unos javi poruku : 

Prekontrolirajte iznose na računu 

jer ukupno NIJE jednako osnovice+pdv. OVO SE NE MOŽE MIJENJATI 

Kad ispravim na na 76.14 onda je unos uspješan ( ukupno= osnovica + pdv + neoporezivo) 


Poštovani, 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Glorija 


13224 



14.03.2013 13:20 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


15.03.2013 


Broj odobrenja 11005-013-02816 se kod prelaska statusa iz 2 u 3 nije fisklalizirao tj. nije dobio korisnički 

broj bez obzira što postoje upute. Kod pregleda nefiskaliziranih računa se ne vidi, bez obzira što nije 

fiskaliziran. 

Sada moramo na silu ubaciti broj, jer odobrenje mora ići 



0









Broj odobrenja 11005-013-02816 se nije fiskaliziro nit se može vidjeti na pregledu nefiskaliziranih jer u tablici 

lm_usl_fak nema popunjen način plaćanja polje fisk_nacpla. 


Poštovani, 

Ovo je ostalo neobuhvaćeno u zahtjevu 13079 . Za svaki slučaj prije rješavanja upisa način plaćanja i 

fiskalizacije za odobrenja molimo pošaljite odgovre vezano za : 

-------------- Odobrenja/terećnja fakot.jas - po konkretnom računu ----------- 

Kod punjenja dodatnih podataka odobrenja ( lm_usl_fak ) potrebno je popuniti i fisk_nacpla : 

a) preuzimanjem fisk_nacpla iz fakture na koju se odobrenje odnosi ili 

b) fiksno sa T ? 

Ako se odlučite za način pod a) potrebna provjera/popuna jer može biti odobrenja koja se odnose i na fakture 

prošlih godina . 

Ako je fisk_nacpla prazan u fakturi , bit će prazan i u odobrenju te se neće moći fiskalizirati . 

------------------------------Odobrenja odob.jas - rabati godišnji ---- 

***Upis odobrenja u radne tablice : protokol,prot_pdv,prot_neop,lm_fak_stav, lm_odob_prot 

Ne postoji tj. nije predviđen upis u lm_usl_fak tablicu ( dodatni podaci faktura/odobrenja ) 

Potrebno uključiti upis odobrenja i u lm_usl_fak tablicu jer se u nju sprema ,trajno pamti i kod fiskalizacije 

koristi fisk_nacpla . 

Molimo pošaljite primjer popune za ova odobrenja jer ne znamo što staviti u polja : 

fisk_nacpla char(1) 

nacpla char(1) 

placanje_rok decimal(4,0) 

ind_rab char(1) 

ugovor_laus char(17) 

ugovor_orig char(40) 

narudzbenica char(20) 

jer ova odobrenja za sebe mogu vezati više ugovora/faktura pa se ne mogu jednoznačno pročitati iz baze 

potrebni podaci 



0









Poštovani, 

--- Odobrenja/terećnja fakot.jas - po konkretnom računu ---- 

-- sve je jasno - nema više pitanja 

---Odobrenja odob.jas - rabati godišnji ---- 

-- Molimo potvrdu prijedloga 

PRIJEDLOG popune sadržaja : 

- fisk_nacpla =T fixno 

- ind_rab = N 

- narudžbenica = '' (prazno) 

- placanje_rok = 0 (radi se isključivo o odobrenju ne o terećenju te je rok neutralan podatak) 

Popuna ostalih polja ovisno o slučaju . 

1.slučaj : odobrenje se radi na 1 ili više faktura ali su sve vezane za 1 ugovor 

nacpla - čita se iz ugovora 

ugovor_laus - čita se iz ugovora 

ugovor_orig - čita se iz ugovora 

2. slučaj : odobrenje se radi za više faktura povezanih sa 2 ili više ugovora pa se ne mogu jednoznačno pročitati 

iz baze potrebni podaci 

nacpla = '' (prazno) 

ugovor_laus = '' (prazno) 

ugovor_orig = '' (prazno) 

NAPOMENA : nacpla je podatak koji se unosi u zaglavlje ugovra i označava način ovbračuna/fakturiranja . 


Napravljene su izmjene na objektu za unos skupnih odobrenja (odob.jas) UNOS SKUPNOG ODOBRENJA / 

TEREĆENJA. 

Kod likvidiranja odobrenja, odobrenje se puni i u tablicu prot_fisk. Tablica prot_fisk se puni i prilikom unosa 

odobrenja (ako se označi da se likvidira kod unosa). 

Kod unosa odobrenja sada se puni i tablica dodatnih podataka fakrure (lm_usl_fak). 

Ako je odobrenje napravljeno iz samo jedne fakture, tada se podaci čitaju iz dodatnih podataka za tu jednu 

fakturu. 

Ako odobrenje nastaje iz više faktura tada se u tablicu dodatnih podataka ne pune vrijednosti broja ugovora, 

originalnog broja ugovora i narudzbenice. Rok plaćanja se puni sa 0, a polje ind_rab sa vrijednosti 'N'. Datum od 

- do se puni sa datumom odobrenja, a datum_pla sa datumom dospijeća sa ekrana. 

Instalacija: u ponedjeljak (18.03.2013) ujutro će biti dostupan novi WIN FAUS lib. 


Napravljena je izmjena na objektu za unos odobrenja (objekt fakot.jas) 

Prilikom likvidiranja odobrenja, odobrenje se puni u tablicu prot_fisk. 

Instalacija: U ponedjeljak (18.03.2013) ujutro će biti dostupan novi WIN FAUS lib. 



0









Kod unosa odobrenja/terećnja (objekt fakot.jas) napravljeno je punjenje podatka fisk_nacpla fiksno sa T. 

Ako je odobrenje u statusu 3 onda se odobrenje i fiskalizira (ounu u tablicu prot_fisk). 

Potrebno za instalaciju i testiranje:Instalacija: Novi WIN FAUS lib će biti dostupan ujutro u ponedjeljak 

18.03.2013 


Kod unosa odobrenja/terećnja (objekt fakot.jas) napravljeno je punjenje podatka fisk_nacpla fiksno sa T. 

Ako je odobrenje u statusu 3 onda se odobrenje i fiskalizira (ounu u tablicu prot_fisk). 

Potrebno za instalaciju i testiranje:Instalacija: Novi WIN FAUS lib će biti dostupan ujutro u ponedjeljak 

18.03.2013. 



Poštovani, 




0











Klijent: 








Višnja 


13223 

U rješavanju 


14.03.2013 13:16 

Upisao: 

Božo Mišeta 

Područje: 

LKROP 


31.07.2013 

Zbog potreba ažuriranja potrebno je izdvojiti šifrarnik primanja uključenih u OSB listu na poseban 

meni – PRIMANJA ZA OSB LISTU (tablica prim_osb). 



0











Klijent: 





Hitnost: 



Višnja 


Poštovani, 

13222 

U rješavanju 

Za poslani zahtjev 13222 molim procjenu sati i rok isporuke. 


14.03.2013 12:34 

Upisao: 

Božo Mišeta 

Područje: 

LKROP 


31.03.2013 


21.06.2013 

Potrebno je omogućiti novu obračunsku kontrolu po nazivom 'Kontrola ukupnog neoporezivog 

iznosa radnika' kojom će se prije obračuna za unesene radnike kontrolirati ukupni neoporezivi iznos po 

radniku preko 1500 kn - zbrojeni neoporezivi iznos u unosu primanja sa isplaćenim neoporezivim iznosima 

u 2013 godini po radniku. 

Kontrola će sadržati popis svih radnika kojima je ukupan neoporezivi iznos veći od 1500,00 kn i koja će po 

radniku ispisati ostatak kako bi se u unosu primanja unijelo kao oporezivo primanje. 

Kontrola će prikazivati i ispisivati slijedeće podatke: 

-Šifra radnika 

-Ime i prezime radnika 

-Iznos oporezivog primanja 

Za šifrarnik neoporezivih primanja koja će se kontrolirati potrebno je omogućiti ažuriranje kroz poseban 

meni – NEOPOREZIVA PRIMANJA 

Za sada su to primanja: H55, H56, P43, P78, P81, U67, U69, U76, U81, U86 i U93. 



0









Poštovani 

za realizaciju traženog zahtjeva procjenjujemo 3 dana razvoja i testiranja a isporuka je moguća krajem travnja 

29.04.2013. 

Pozdrav 


Poštovani, 

Nismo zaprimili potvrdu procjenjenog angažmana 24 sata . 

Molimo povratne informacije kako bismo dostavili novi rok isporuke 

Status : Klijentu poslana ponuda / procjena - čeka se odgovor 





Poštovani 

za realizaciju traženog zahtjeva procjenjujemo 3 dana razvoja i testiranja a isporuka je moguća krajem travnja 

29.04.2013. 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13221 



14.03.2013 09:46 

Upisao: 

Božo Mišeta 

Područje: 

LROBD 


14.03.2013 


Molim da se provjeri rad intergracijskog servisa na testnoj bazi. 

Jučer je ukucan asortiman 000021 TESTNI ASORTIMAN 10789 koji vrijedi od 14/03/2013 do 31/03/2013, 

u status je 2, i napravljen je prijenos zah_jtr PRIJENOS MATIČNIH PODATAKA ZAHTJEVNICE PU, ali 

se asortiman nije prenio. 



0









Poštovana, 

Asortiman nije prenesen jer na LAUS tablici asortiman na TEST bazi nije izveden sql za kreiranje triggera. 

S štovanjem 


Trigeri su 'zaduženi' za određivanje koji asortimani idu u prijenos i s kojom akcijom. Zbog toga asortimani koji su 

aktivirani dok nije bilo trigera na tablici asortiman nisu ni ušli u međutablicu za prijenos. 

Podaci koji su evidentirani dok nije bilo trigera moraju se ručno upisati u međutablicu. 

insert into zah_asortiman ( 

asortiman, 

datum, 

red, 

akcija) VALUES ( 

'000021', 

'2013-03-13 14:00:00', 

'', 

'A') 


Za prijenos zahtjevnica na testnom serveru uredno je definirana klasa prijenosa i konekcijski stringovi. 

Vjerovatno niste primjetili ovu liniju u konfiguracijskoj datoteci. 

 

 


Poštovani, 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Glorija 


13219 



13.03.2013 12:32 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


17.03.2013 


19.03.2013 

Računi Vrste 4 

Molim da se na objektu Ručni unos računa: 

1. za partnera P619801 omogući Unos podataka za R1 -poslovnog partnera (znači GR1 i VR1) 

2. Kad se na računu unese količina -1 (minus jedan) onda ne računa vrijednost (kad se unese 1 onda 

računa vrijednost) – uvijek treba računati vrijednost 

3.Imamo slučaj kada je PU pogrešno kucao rabat,mi bi trebali stornirati taj račun i izdati novi. Međutim 

rabat iako iskaže na računu ne odbija ga od iznosa za uplatu. Poslali smo naš neispravan račun i jedan sa 

fakturiranja koji je ispravan. Ako može ispravka u programu. (prilog skeniranih računa u privitku maila) – 

ovo je već poslano kroz zahtjev ali nažalost još nije riješeno pa ponavljamo 



0









Napravljene su izmjene kod ručnog unosa Računa Vrste 4. 

Kada se upiše negativna količina sada se izračuna i vrijednost. 

Ispravljen je unos stavke za vrstu računa 4. Greška je bila kad bi se upisivao popust pa se nebi dobro izračunala 

vrijednost. 

Svi računi vrste 4 za koje je upisan popust u stavkama se moraju stonirati i opet upisati. 

Omogućen je unos podataka za R1 - poslovnog partnera (GR1 i VR1) za partnera 619810. 

Da bi se upisali R1 podaci potrebno je partnera 619801 upisati u parametra sustava po šifrom POSPA. 

Parametar: 

Sifra = POSPA, 

kljuc = '2', 

podatak = 619801 


Instalacija: Novi WIn faus lib će biti dostupan sutra (19.03.2013) ujutro. 


Ispravljen je izračun iznosa i poreza kod ručnog unosa računa vrste 4. 




Poštovani , 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Glorija 


13220 



13.03.2013 12:26 

Upisao: 

Božo Mišeta 

Područje: 

LFINK 


17.03.2013 


Liste ne rade dobro za vrstu analitike A i konto 120710, jer se na kontu 120710 jedan te isti Laus broj 

dokumenta razbija po dospijeću. 

1.Ne povlači se ispravan naziv šifre analitike 

2.Laus broj dokumenta 46300-012-00047 razbijen po dospijeću, a lista IOS-a povukao je po dugovni 

promet istavke koje još nisu u dospijeću 


Na listama sa objekta potvstav_jf ispravljeno je: 

- čitanje naziva analitike vrste A 

- iznosi dospijeća koje sa sada čitaju po datumu dospijeća iz stavaka (arhivk) uvažavajući zadane podatke 

Datum dospijeća od do zadane na ekranu 

Preuzeti novi LAUS FINK liba u petak 22.3.2013 


Poštovani, 

1. Omogućen je ispis OIB-a za vrstu analitike A 

2. Za jedan dokument omogućen je ispis onoliko stavaka koliko ima različitih datuma dospijeća dokument u 

stavaka (arhivk). 

3. Proširen opis 

Novi LAUS FINK liba u četvrtak 28.3.2013. 


Poštovani, 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Ivan 


13218 



12.03.2013 15:16 

Upisao: 

Božo Mišeta 

Područje: 

LFINK 


13.03.2013 


Kod knjiženja izvoda žira preko objekta iz_knj_ff KNJIŽENJE IZVODA ŽIRA program je proknjižio iznos 

na krivog partnera. 

Ja sam učitao sporni izvod na test i tamo ga proknjižio i opet mi je završio na krivom partneru (žiro – 

partner FINVEST, knjiženja - ULJANIK): 

Produkcija: 

select * from izvod_ziro where br_izv='060' and rnpri='HR1623900011100018674' 

and nazivd like '%FINVEST%'; 

select * from izvod_ziro1 where br_izv='060' and rnpri='HR1623900011100018674'; 

select * from arhivk where nalogk='13ZZ0060' and idin=3000; 

U slučaju da se to ispravi na testu postoji ti isti podaci samo proknjiženi u drugom nalogu: 

Test: 


and nazivd like '%FINVEST%'; 

select * from izvod_ziro where br_izv='060' and rnpri='HR1623900011100018674'; 


and iznos=3000; 

select * from arhivk where nalogk='13ZZ0022' and idin=3000; 



0









Poštovani, 

Nakon analize slučaja izmjenjen je način određivanja partnera NSC na kojeg se knjiži za pozbo(3,4) = 2257 ili 

2259 

ako ne postoji aktivan ugovor sa oib= HR||pozbo(14,13) 


------------------- 

// Dodano prema zahtjevu 27476 čitanje analitike za taj slučaj : 

# and a.part in (select analitika 

# from protokol p,lm_ugv_dod u 

# where vprotokol='R' and status='2' 

# and vdok='UGK' 

# and placanje_tip='A' 

# and p.protokol=u.protokol 

# and p.orgj=':x_orgj' ) 

--------zbog nedovoljno uvjeta dobije se više partnera među kojima i ULJANIK : 

613174 FINVEST CORP D.D. 

623942 ULJANIK ZAJEDNIŹKI POSLOVI D.O.O. 

623952 RIVIERA ADRIA D.D. 

623954 PLAVA LAGUNA D.D. POREŹ 

624275 PULJANKA D.D. 

627645 BRODOKOMERC NOVA D.O.O. 

sad se određuje po : 

DBMS SQL SELECT a.nadpart par_komitent 

from ustroj_part a, part b 

where b.part = a.nadpart 

and b.aktivnost='D' 

and b.isaco='D' 

and a.part in ( :quvjet_zirod ) 

-----------------------------quvjet_zirod 

se dinamički puni ovisno o sadržaju xzirod=zirod iz izvoda ( HR% --> iban , inače je ZR u zirod ) : 

if xzirod(1,2) = "HR" 

{ 

qzirod = xzirod(5,7) ## "-" ## xzirod(12,10) 

quvjet_zirod = " select part from partzir where iban=':xzirod' or ziror = ':qzirod' " 

} 

else 

quvjet_zirod = " select part from partzir where ziror =':xzirod' " 

---------------------- 


Obavijestiti korisnika o preuzimanju novog LAUS FINK liba u ponedjeljak 8.4.2013. 


Poštovani, 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13216 



12.03.2013 11:54 

Upisao: 

Božo Mišeta 

Područje: 

LROBD 


13.03.2013 


Kod unosa koeficijenata obrtaja i asortimana potrebno je omogućiti na ekranu artt_fb pregled artikala tipa 

‘R-roba’.Defaultno se trebaju prikazivati artikli tipa ‘R’. 


Omogučeno je filtriranje artikla po tipu artikla na ekranu za usno koeficijenta obrtaja artikla art_ko_fa odnosno po 

deafultu je postavljeno R- roba 

potrebno je preuzeti jam libove rob0,rob1,rob2,rob3,rob4 i base koji su već na internetu. - prije sutrašnje obuke 

obavezno! 


Na ekranu za unos artikala asortimana asort_st_fa za f4(TRAŽI( je po defaultu postavljno tip artikla R - Roba. 

Preuzeti base. lib sa datumom 19/03/2013 


Poštovani, 


- 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Ivan 


13214 

Riješen 


12.03.2013 11:47 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


20.03.2013 


30.04.2013 

Na objektu ugovor1.fas, kod upisa stavaka ugovor2.fas dodati novo polje Dodatna naknada na uslugu u 

koje će se uz određenu uslugu upisati podatak za obračun dodatne naknade na uslugu kao indikator 

PRAZNO/DA/NE. Upis slobodan. 

Ako će se označiti više usluga s DA- Dodatna naknada, ukupna vrijednost tih usluga s PDV-om nakon 

oduzimanja rabata će se ispisivati na fakturi kao Iznos za obračun naknade s postotkom. 

Postotak Dodatne naknade će se evidentirati kroz šifru usluge Dodatak na gorivo (nova usluga-zahtjev 

Odjela kontrolinga). 

Na objektima rekuslN_fas i rekr_fas u Ostalim uvjetima dodati novo polje Dodatna naknada (indikator 

PRAZNO/DA/NE za pregled usluga, kupaca, faktura, s oznakom ili bez Dodatne naknade). 



0









Na ekranu za dodatne podatke za usluge (usldod_ftr - panter) omogućeno je u polje Nefinancijska da se može 

upisati P. 

Vrijednost P se upisuje za uslugu na koju će se kod fakturiranja upisivati postotak dodatne naknade. 

Unos stavki u ugovor je proširen sa poljem Dodatak. Tu se upisom vrijednosti P označavaju usluge na koje se 

primjenjuje dodatna naknada. 

Napravljena je i kontrola da se prilikom upisa dodatka mora upisati i postotak naknade. 

U petak ujutro (26/04/2013) bit će dostupni novi WIN FAUS i LAUS TRAN libovi. 

Izvesti sql: 

ALTER TABLE lm_ugv_stav ADD ( 

dodatak char(1) BEFORE uradio); 


Na objektu za automatsko fakturiranje HPX usluga omogućeno je i fakturiranje dodatka za gorivo. 

Iznosi se evidentiraju na usluzi kojoj je u dodatnim podacima evidentirano da je nefinancijska =P, a suma iznosa 

se uzima sa usluga kojima je u stavkama ugovora evidentirano dodatak=P. 

Novi WIN FAUS će biti dostupan u četvrtak 02.05.2013 


Poštovani, 


Nismo dobili primjedbe nakon zadnje isporuke 30.04.3013 : 

Na objektu za automatsko fakturiranje HPX usluga omogućeno je i fakturiranje dodatka za gorivo. 

Iznosi se evidentiraju na usluzi kojoj je u dodatnim podacima evidentirano da je nefinancijska =P, a suma iznosa 

se uzima sa usluga kojima je u stavkama ugovora evidentirano dodatak=P. 

Novi WIN FAUS će biti dostupan u četvrtak 02.05.2013 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Ivan 


13213 



12.03.2013 11:43 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


15.03.2013 


Otvoriti novi status radnih naloga u kojima će se evidentirati usluge koje dolaze iz MIPS-a i HPX-aplikacije, 

a neće biti iskazane na fakturama i ne mogu biti u nefakturiranom prometu tj. statusu 2. 

Na objektima rucnal.js, rekbrou.jas, spamtrek.jas treba ugraditi novi status radnih naloga kod uvjeta 

pregleda i ispisa (običan i excel). 


Poštovani, 

Molimo pojašnjenja vezano za realizaciju zahtjeva : 

Otvoriti novi status radnih naloga 

-- Molimo predložite vi oznaku novog statusa kao ne bi pogađali koja vam oznaka odgovara jer ne znamo jkoje 

ste osim 1,2,3 i 9 koristili 

U tim nalozima će se evidentirati usluge koje dolaze iz MIPS-a i HPX-aplikacije, a neće biti iskazane na 

fakturama i ne mogu biti u nefakturiranom prometu tj. statusu 2. 

-- Zanči li to da već kod preuzimanja prometa naloge koje sadrže 'takve' usluge treba upisati u lm_nalog sa 

novom oznakom satatusa a ne sa status=2? 

Molim pojasnite o kakvim/kojim uslugama i obilježjima prometa se radi tj. koje specifične sadržaje imaju u 

prometnim tablicama ili drugim evidencijama u bazi . Napr, usluge vrste x ili usluge za ugovore sa stavke=P , ili 

usluge u prometu sa tip_slog= x ,... 

Na objektima rucnal.js, rekbrou.jas, spamtrek.jas treba ugraditi novi status radnih naloga kod uvjeta pregleda i 

ispisa (običan i excel). 

- ne treba pojašnjavati 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13217 



12.03.2013 11:11 

Upisao: 

Božo Mišeta 

Područje: 

LROBD 


12.03.2013 


Na testnoj bazi se prilikom prebacivanja dokumenta RIM u viši status javlja greška 

674. 

Navedena greška se pojavila nakon što su se po zahtjevu 12673 izvršili 

SQL-ovi za izmjenu procedura (vidi prilog). 

vidi prilog 



0









Potrebno izvesti sql-ove : 

drop trigger "l1fink".trad_prot_ins; 

create trigger "l1fink".trad_prot_ins insert on "l1base".protokol 


for each row 

(execute procedure "l1fink".protokol_dokit_ins(new.protokol ,new.vprotokol , 

new.vdok ,new.analitika ,new.boriginal ,new.status ,new.uradio ,new.datum )); 

drop trigger "l1fink".trad_prot_del; 

create trigger "l1fink".trad_prot_del delete on "l1base".protokol 


for each row 

(execute procedure "l1fink".protokol_dokit_del(old.protokol ,old.vprotokol , 

old.vdok ,old.analitika ,old.boriginal ,old.status ,old.uradio ,old.datum )); 

drop trigger "l1fink".trad_prot_upd; 

create trigger "l1fink".trad_prot_upd update on "l1base".protokol 

referencing old as old new as pre 

for each row 

(execute procedure "l1base".okini_proto(pre.protokol ,pre.vdok ,pre.status , 

pre.uradio ,pre.datum ), 

execute procedure "l1fink".protokol_dokit_upd(pre.protokol ,pre.vprotokol , 

pre.vdok ,pre.boriginal ,pre.analitika ,pre.status ,old.protokol ,old.vprotokol , 

old.vdok ,old.boriginal ,old.analitika ,old.status )); 


Potrebno izvesti sql-ove : 

drop trigger "l1fink".trad_prot_ins; 

create trigger "l1fink".trad_prot_ins insert on "l1base".protokol 


for each row 

(execute procedure "l1fink".protokol_dokit_ins(new.protokol ,new.vprotokol , 

new.vdok ,new.analitika ,new.boriginal ,new.status ,new.uradio ,new.datum )); 

drop trigger "l1fink".trad_prot_del; 

create trigger "l1fink".trad_prot_del delete on "l1base".protokol 


for each row 

(execute procedure "l1fink".protokol_dokit_del(old.protokol ,old.vprotokol , 

old.vdok ,old.analitika ,old.boriginal ,old.status ,old.uradio ,old.datum )); 

drop trigger "l1fink".trad_prot_upd; 

create trigger "l1fink".trad_prot_upd update on "l1base".protokol 

referencing old as old new as pre 

for each row 

(execute procedure "l1base".okini_proto(pre.protokol ,pre.vdok ,pre.status , 

pre.uradio ,pre.datum ), 

execute procedure "l1fink".protokol_dokit_upd(pre.protokol ,pre.vprotokol , 

pre.vdok ,pre.boriginal ,pre.analitika ,pre.status ,old.protokol ,old.vprotokol , 

old.vdok ,old.boriginal ,old.analitika ,old.status )); 



0









Poštovani, 

Izvedite i uporedite vlasnike procedura sa navedenim valsnikom za njih u trigger-ima koji ih pozivaju : 

dbschema -f ime_procedure -d ime_baze > ime_datoteke 

na laus test bazi (ime_baze= laus@laustest ) stavljajući redom : 

ime_procedure = protokol_dokit_ins 

protokol_dokit_del 

protokol_dokit_upd 

okini_proto 

Ako ime proceure , što uključuje i vlasnika, nije navedeno u trigger-u koji poziva proceduru POTPUNO jednako 

kao što se dobije izvođenjem gornjih SQL-ova ,javi se greška -674 jer trigger poziva proceduru 

"informix".protokol_dokit_del koja NE postoji . 

Postoji proceudra "l1fink".protokol_dokit_del . 

Dakle ,ako u triggeru stoji da poziva proceduru "informix".ime_procedure a proceura je pod 

"l1fink".ime_procedure javi se greška -674 

NAPOMENA: 

U okviru KZ-a 41296 , HP broj 13126 ( Poslano datum i vrijeme: 18.2.2013 10:34:20 ) dostavljeni su sql-ovi za 

drop/create PROCEDURA koje uključuju i RP3 dokumente ( u prilogu) Ne znamo hoćete li kad ćete njih staviti 

na test ili su već na testu . 

Nevezeno za to triggere bi trebali kreirati ponovo pazeći pruii tome na vlasnika pojedine procedure tj izvesti sqlove 

poslane u obradi 1 ovog KZ-a 


Katja : Ne javlja se više greška 674. ( mail od 12 Mar 2013 14:59:19 


Poštovani! 

Zahtjev zatvaramo uz Vašu suglasnost - Riješen 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13215 

Opisi problema kod izbora rješavatelja. 

Primjer u transakciji T65 – Prosljeđivanje spisa 

POJEDINAČNO PROSLJEĐIVANJE 

Odaberemo spis za pojedinačno prosljeđivanje 



12.03.2013 10:57 

Upisao: 

Božo Mišeta 

Područje: 

EHPUR 


13.03.2013 




0









Poštovani, 

Ovo je povezano također jednim dijelom sa zahtjevom 13209. 

Prilikom importa obje org. jedinice su bile aktivne i tako su importirane: 

10014 

10001 

SEKTOR PRODAJE 

DP-02 

D 

11003 

10014 

SLUŽBA PRODAJE 

DP-02 

D 

Nakon importa je Služba prodaje označena kao neaktivna te se sukladno tome ne prikazuju ostali rješavatelji 

koji su po dostavljenim podacima pripadali 11003 – Službi prodaje. 

Iako se radi o istoj transakciji prikaz nije isti odnosno radi se o dva različita ekrana. 

U ovom zbirnom je ostao ˝stari˝ način prikaza - prikaz rješavatelja odabrane nadležnosti i svih rješavatelja ispod 

te odabrane. Također na tom ekranu nije postavljen uvjet da ne prikazuje rješavatelje koji su pod orgj koja je 

označena kao neaktivna kao na ekranu E2 (forma spisa) – potrebno dodati ovaj uvjet od strane Dokument IT- a. 


Želite li da na ekranu zbirnog proslijeđivanja se prikazuje kao i na formi spisa samo rješavatelji odabrane orgj, a 

ne i onih ispod nje kao što je sada? 



0










Poštovani, 

Riješen je i prebačen na test dio koji je Dokument IT bio dužan odraditi po ovome zahtjevu: 

Želite li da na ekranu zbirnog prosljeđivanja se prikazuje kao i na formi spisa samo rješavatelji odabrane orgj, a 

ne i onih ispod nje kao što je sada? 

Odgovor pisarnice: 

Da. Želimo da se prikazuju samo oni rješavatelji iz odabrane orgj. 

Molimo povratne informacije/ suglasnost za prebacivanje na produkciju i zatvaranje zahtjeva - Riješen 


Poštovani, 

Potvrđen zahtjev prebačen je na produkciju. 



Poštovani! 




0











Klijent: 



Pitanje 


Hitnost: 

Vrlo hitno 


Glorija 


13212 

Riješen 


11.03.2013 15:21 

Upisao: 

Božo Mišeta 

Područje: 

AFINK 


13.03.2013 


Molim da se omogući ažuriranje uputa na r.br. 117 obrasca RDG u Argosyiu za konto 405100 što je 

trenutno onemogućeno. U nastavku je slika ekrana s porukom greške. Konto 400310 je deaktiviran s 

31.12.2011. godine. Nakon tog datuma u aplikaciji laus ne vide se knjiženja. 

Također molim da se utvrdi zašto se konta 668000 i 668100 navode u poruci koju prosljeđujem s obzirom 

na to da su upute za njih na r.br. 39 Bilance uredno zadane za godine u kojima su predmetna konta bila 

aktivna. 



0









Poštovani, 

u vezi RDG-a i konta 400310 kao upute za 2012, objasnili smo u obradama vezanim za isto pitanje: za tekuću 

godinu kontni plan u međubazi se preuzima kao sva konta koja su u tablici konto u LAUS-u (bez obzira na datum 

prestanka važenja). Kada se pređe u novu godinu, naravno, stara godina se uzima iz tablice konto_godina iz 

LAUS-a - ako tamo ne postoji dotični konto, onda naravno uputa koju je korisnik zadao na taj konto u toj godini 

za izvještaj na međubazi je nevalidna - i validacija ispravno reagira i ukazuje na pogrešku. Ukoliko takva uputa 

nikad nije ni trebala postojati (najčešći slučaj), onda ju je dovoljno ukloniti. Najjednostavniji način kako ju korisnik 

može ukloniti je da, u ovom slučaju, pođe na ćeliju u tom istom retku (8) i stupcu za 2012 godinu, otvori upute u 

dijaloškom ekranu za zadavanje uputa po kontima, stisne "prihvati" i pređe u novi red (time aktivirajući 

pohranjivanje i validaciju svih uputa iz tog retka). Tim činom se automatski uklanjaju sve nevalidne upute u toj 

ćeliji, pa je time onda dozvoljeno unošenje novih uputa u drugim ćelijama istog retka. Molimo prenesite ovu 

uputu korisniku. Ovo je učinjeno sada za taj redak. 

u vezi poruke o pojavi knjiženja na kontima za koje ne postoje upute. Ta poruka je točna. Na žalost pojavila su 

Vam se knjiženja, izgleda tamo gdje možda niste očekivali. Evo dokaza: 

ovo su upute koje postoje na rečenim kontima u bilanci: 

IzvjestajMatricaUputaBrojRetkaIzvjestajMatricaUputaBrojStupcaIzvjestajMatricaUputaRbrUpute 

IzvjestajMatricaUputaTekstIzvjestajMatricaUputaDatumOdIzvjestajMatricaUputaDatumDo 

IzvjestajMatricaUputaFirmaIzvjestajMatricaUputaKojiKontoIzvjestajMatricaUputaGodina 

IzvjestajMatricaUputaKonto 

40232NULL2007-01-01 00:00:00.0002007-12-31 00:00:00.00000000T2007668000 

40332NULL2008-01-01 00:00:00.0002008-12-31 00:00:00.00000000T2008668000 

40432NULL2009-01-01 00:00:00.0002009-12-31 00:00:00.00000000T2009668000 

40535NULL2010-01-01 00:00:00.0002010-12-01 00:00:00.00000000T2010668000 

40640NULL2011-01-01 00:00:00.0002011-12-01 00:00:00.00000000T2011668000 

40233NULL2007-01-01 00:00:00.0002007-12-31 00:00:00.00000000T2007668100 

40333NULL2008-01-01 00:00:00.0002008-12-31 00:00:00.00000000T2008668100 

40433NULL2009-01-01 00:00:00.0002009-12-31 00:00:00.00000000T2009668100 

40536NULL2010-01-01 00:00:00.0002010-12-01 00:00:00.00000000T2010668100 

40641NULL2011-01-01 00:00:00.0002011-12-01 00:00:00.00000000T2011668100 

(referentni upit bio je 

SELECT 

[IzvjestajMatricaUputaBrojRetka] 

,[IzvjestajMatricaUputaBrojStupca] 

,[IzvjestajMatricaUputaRbrUpute] 

,[IzvjestajMatricaUputaTekst] 

,[IzvjestajMatricaUputaDatumOd] 

,[IzvjestajMatricaUputaDatumDo] 

,[IzvjestajMatricaUputaFirma] 

,[IzvjestajMatricaUputaKojiKonto] 

,[IzvjestajMatricaUputaGodina] 

,[IzvjestajMatricaUputaKonto] 

FROM [hp4lcs].[dbo].[tFinkIzvjestajMatricaUputa] 

where [IzvjestajMatricaUputaSifra]='BILANCA' 

AND [IzvjestajMatricaUputaKonto] IN ('668000', '668100') 

ORDER BY [IzvjestajMatricaUputaKonto],[IzvjestajMatricaUputaGodina]) 

a ovo su knjiženja po godinama koje postoje na dotičnim kontima: 

GODINAKONTO 

2000668000 

2001668000 

2002668000 

2003668000 

2004668000 

2005668000 



0







2006668000 -završen, Isporučen - Korisnik potvrdio ispravnost 

2007668000 

2008668000 

2009668000 

2010668000 

2011668000 

2012668000 

2000668100 

2001668100 

2002668100 

2003668100 

2004668100 

2005668100 

2006668100 

2007668100 

2008668100 

2009668100 

2010668100 

2011668100 

2012668100 

(referentni upit: 

SELECT DISTINCT GODINA,KONTO 

FROM LCS.VBILANCA 

WHERE KONTO IN ('668000', '668100') 

ORDER BY KONTO, GODINA) 

iz ovoga je razvidno da nedostaju upute barem za 2012 godinu za oba konta. 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Ivan 


13211 



11.03.2013 15:06 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


12.03.2013 


13.03.2013 

U prijenosu imamo RNB za hpekspres usluge, ali za iste nije moguće napraviti fakturu s vrstom usluge 

HPX. 

OBN je omogućen za vrstu usluge POS jer hpx do sada nismo imali. 

Treba omogućiti OBN i za usluge hpx-a (na objektu fakhp.jas) koje dolaze kao RNB prema modelu na koji 

se izrađuje OBN za pos usluge. 


Kod fakturitanja HPX usluga omogućeno je generiranje faktura OBN. 



Poštovani, 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13210 



11.03.2013 14:37 

Upisao: 

Božo Mišeta 

Područje: 

EHPUR 


13.03.2013 


Nije riješen problem koji se pojavljuje u transakciji T26-surješavanje spisa. Kod obrade u polju „Surješeni 

spis“ ne nudi sve spise koji pripadaju odabranom rješavatelju te ne pretražuje po zadanim uvjetima. 

Evo primjer spisa: 

Broj HP-9-002720/13 je zadužen na N.Kušlan ali kod pretraživanja izbacuje nelogičan izbor 10 različitih 

spisa. Prilog print screen: 



0









Poštovani, 

Izvršene su dorade po ovom zahtjevu i prebačene na testni server. 



Poštovani, 

Potvrđen zahtjev prebačen je na produkciju. 



Poštovani! 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13209 



11.03.2013 14:13 

Upisao: 

Božo Mišeta 

Područje: 

EHPUR 


13.03.2013 


B.Jakušić je unesena u DP-02 (što se vidi u zbirnom pretraživanju i u uređivanju atributa djelatnika),ali je 

ne prikazuje u transakciji T2. 



0









Poštovani, 


10014 

10001 


DP-02 

D 

11003 

10014 


DP-02 

D 






0









Poštovani, 


10014 

10001 


DP-02 

D 

11003 

10014 


DP-02 

D 





Poštovani, 

Može li se zatvoriti ovaj zahtjev? 

Poslano pojašnjenje 13.3.2013 : 


10014 10001 SEKTOR PRODAJE DP-02 D 

11003 10014 SLUŽBA PRODAJE DP-02 D 





0









Poštovani, 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Glorija 


13208 

4630701300250 RUF46307 05.03.2013.27276,383 

4630701300251 RUF46307 05.03.2013.54056,853 

4630701300252 RUF46307 05.03.2013.834,1 3 

4630701300253 RUF46307 05.03.2013.445,49 3 

4630701300257 RUF46307 28.02.2013.22776,93 

4630701300260 RUF46307 28.02.2013.4125 3 

4630701300261 RUF46307 28.02.2013.5122,4 3 

4630701300264 RUF46307 06.03.2013.21800,943 

4630701300266 RUF46307 28.02.2013.1650 3 

4630701300268 RUF46307 28.02.2013.2062,53 

4630701300269 RUF46307 28.02.2013.24753 

4630701300271 RUF46307 28.02.2013.13753 

4630701300272 RUF46307 28.02.2013.1482,253 

4630701300274 RUF46307 28.02.2013.15085,133 

4630701300275 RUF46307 28.02.2013.11003 

4630701300276 RUF46307 28.02.2013.38503 

4630701300277 RUF46307 28.02.2013.4262,53 

4630701300278 RUF46307 28.02.2013.90533 

4107901300018 RUF41079 28.02.2013.4782,173 

4107901300019 RUF41079 28.02.2013.607,53 

4107901300020 RUF41079 28.02.2013.211,683 

4107901300021 RUF41079 28.02.2013.498,373 

11003H1300010 RAV11003 28.02.2013.22633 

Zatvoren-riješit će se po drugom zahtjevu/zadatku 


11.03.2013 14:07 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


20.03.2013 


Provjerom nefisklaliziranih računa na temelju uputa uočavamo ovih 23 (izuzeti su GOT, GR1, VR1 I KIZ). 

Pošto nismo kroz aplikaciju u mogućnosti da napravimo fiskalizaciju bez da se mijenja korisnik i vrijeme, 

potrebno je i ove račune provesti da su fiskalizirani. 



0









Poštovani, 

Zahtjev uz vašu suglasnost zatvaramo - Zatvoren-riješit će se po drugom zahtjevu/zadatku 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Ivan 


13207 



11.03.2013 14:04 

Upisao: 

Božo Mišeta 

Područje: 

LFINK 


12.03.2013 


27.03.2013 

Potrebno je doraditi objekt 'bss_ugv_jf PRIJENOS UGOVORA BSS – LAUS' da kod preuzimanja ugovora 

iz BSS radi prijenos za sve neprenesene ugovore koji imaju definirane (tj. za njih postoje) kupce u LAUSu: 

SQL: 

select * from bss_laus@mips_laus:bss_ugovor 

where (indikator_laus='' or indikator_laus is null) 

and idpart in (select bss_kupac from bss_vezak); 

Bilo bi dobro da se takva ili slična kontrola ugradi i kod automatskog prijenosa podataka između BSSa i 

LAUSa (zahtjev 12745). 


Na objektu bss_ugv_jf PRIJENOS UGOVORA BSS – LAUS dodano je da u prijenos ne ulaze oni ugovori za 

koje ne postoji evidentiran kupac u LAUS-u. 

Napomena: Za ove slučajeve je već postojala kontrola na grešku 009 Nepostojeći/neučitan kupac u ugovoru. 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Višnja 


13206 

Riješen 


11.03.2013 13:28 

Upisao: 

Božo Mišeta 

Područje: 

LKROP 


15.03.2013 


Kroz izvj_clr_jk PORUKE IZ OBRAČUNA uočeno je da je pogrešan broj preostalih rata i isplata radnika na 

plaći za 02/2013. 

Primjer je radnik 13274 RUPAR MIRJANA kojoj su obračunate obustave: 

HPB D.D. 71138.29 1,226.53 

HSP-HRVATSKI SINDIKAT 1.30% 64.65 

RSRH-ČLANARINA 1.50% 74.59 

RSRH RIJEKA-SIND. POZA 5000.00 1,000.00 

HSP-HRVATSKI SINDIKAT 13000.00 500.00 

Ukupno obustave 4,018.75 

Radnici 13274 nakon obračunatih obustava u iznosu 4,018.75 ostaje 954.17. U porukama iz obračuna su 

preostale rate i isplate koje se ne podudaraju sa preostalim ratama i isplatama po zajmodavcima iz 

evidentiranih obustava: 

Datum 08/03/2013 

PORUKE IZ OBRAČUNA 

Šifra Kod Tekst 

============================================================== 

13274 RUPAR MIRJANA 11 Brise se obustava rata 600.00 ,isplata -545.83 

13274 RUPAR MIRJANA 11 Brise se obustava rata 1500.00 ,isplata 954.17 


13274 RUPAR MIRJANA ? OBUSTAVE 6168.75 vece od primanja 4972.92 



0









Poruke iz obračuna za navedenog radnika su u redu i ne nalazimo nepravilnosti. 

Sve rate koje su prikazane postoje u evidenciji obustava za djelatnika. 

Na ovom popisu jedino redoslijed prikaza brisanja obustava nije dobar,naime prvo se brisala obustava od 50, 

zatim ona od 600 pa tek onda ona od 1500 kn i to će biti ispravljeno za slijedeću plaću. 


13274 RUPAR MIRJANA 11 Brise se obustava rata 1500.00 ,isplata 954.17 


13274 RUPAR MIRJANA ? OBUSTAVE 6168.75 vece od primanja 4972.92 

Podaci iz evidencije obustava tj. iz obus_ev: 

part obustava rata dat_od dat_do ind_akt datum 

11 O236 600.00 01/02/2013 D 07/03/2013 

11 O236 1500.00 01/02/2013 N 11/03/2013 

11 O247 50.00 01/02/2013 D 28/02/2013 

kako se vidi obustava od 1500 kn je naknadno mijenjana 11/03/2013 i sada ima aktivnost N. 


Poruke iz obračuna prikazuju ispravne podatke za navedenog radnika ali redoslijed prikaza nije dobar.Stoga je 

na 

izvješću izvj_rk sa objekta izvj_clr_jk PORUKE IZ OBRAČUNA izmjenjen redoslijed prikaza poruka za radnika, 

tako da se poruke prikazuju redoslijedom kojim su nastale. 

Kod brisanja obustava u iz_sumk_jk je dodano da briše i po uvjetu na radnika i part osim po rowid-ju jer se radi o 

velikoj tablici. 


krop lib od 15/03/2013 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Ivan 


13205 



11.03.2013 11:15 

Upisao: 

Božo Mišeta 

Područje: 

LFINK 


12.03.2013 


Kod pripreme kartice kupca preko objekta 'bss_kart_jf PRIJENOS KARTICE KUPCA LAUS – BSS' neki 

podaci su završili u grešakama te nisu preneseni: 

SQL za podatke koji nisu preneseni (za sve njih radio sam pripremu 8.3.2013): 

select s.bss_greska ,g.naziv,k.analitika anlx,p.* 

from bss_status s ,bss_greska g,bss_priprema p,outer bss_vezak k 

where s.tablica='bss_priprema' 

and g.bss_greska=s.bss_greska 


--and p.analitika='T000062' 

--and p.datdos='20.03.2013' 

and k.bss_kupac=p.idpart 

into temp gry ; 

SQL za pronalaženje početnog sloga za kojeg je slana izmjena 

select b.* from bss_priprema b, gry g 

where b.idpart=g.idpart 

and b.nalogk=g.nalogk 

and b.red=g.red 

and b.iznpot=g.iznpot 

order by idpart,nalogk,red,status,slog_id into temp gry2; 

Uglavnom primjetio sam dva slučaja; 

1)Kod zatvaranje stavki izmjena se javila kao greška svi drugi parametri su ispravni 

Npr.; select * from bss_priprema where analitika='T002041' order by nalogk,red 

2)Kod zatvaranje stavki dva puta su došla isti podaci sa akcijom 'I' 

select * from bss_priprema where analitika='T000170' order by nalogk,red,slog_id; 



0









Poštovani , 

Intenzivno se radi na analizi poslanih slučajeva za koje smatrate da su se trebali prenijeti a nisu . 

Ukoliko se do ponedjeljka ne bude moglo isporučiti programske izmjene , može se nakon puštanja pripreme za 

karticu kupca a prije prijenosa iste u BSS napraviti slijedeće za sve slogove koje želite prenijeti u BSS (prenijet 

će se u bss_kart tablicu ) : 

u bss_priprema tablici kroz bazu postaviti status na '' ili NULL 

Inače, kod pripreme sa status G u bss_priprema označe svi slogovi u kojima je utvrđena nedozvoljene izmjena 

podataka pa ne idu u prijenos : 

--- samo se jail smije mijenjati za stavke koje su već poslane (postoje u bss_poslano) 

------------------------------------------------- 

AKO se utvrdi da nije jednako : 

-----------------------------------------------qkonto 

!= ekonto 

|| qprotokol != eprotokol 

|| qvrdok != evrdok 

|| qdatizr != edatizr 

|| qdatdos != edatdos 

|| qiznpot != eiznpot 

|| qdugpot != edugpot 

|| qdatumk != edatumk 

|| qnalogk != enalogk 

|| qred != ered 

|| qopis != eopis 

|| qvanalitika != evanalitika 

|| qanalitika != eanalitika 

e* iz bss_priprema od prije poslano 

q* i iz arhivk kakvi su sad a mijenjao im se jail 


Poštovani, 

Ispravljena je greška kod slučaja krivog dodjeljivanja statusa G za ispravne slogove u tablici bss_priprema. 

Slučaj 1) Kod zatvaranje stavki izmjena se javila kao greška svi drugi parametri su ispravni 

Onemogućen je daljni ponovni prijenos već poslanih slogova kartice kupca u tablicu priprema (bss_priprema) 

slučaj 2)Kod zatvaranje stavki dva puta su došla isti podaci sa akcijom 'I' 






0









Poštovani, 

Zadnja obrada poslana je 17.4.2013 . : 

Ispravljena je greška kod slučaja krivog dodjeljivanja statusa G za ispravne slogove u tablici bss_priprema. 

Slučaj 1) Kod zatvaranje stavki izmjena se javila kao greška svi drugi parametri su ispravni 

Onemogućen je daljni ponovni prijenos već poslanih slogova kartice kupca u tablicu priprema (bss_priprema) 

slučaj 2)Kod zatvaranje stavki dva puta su došla isti podaci sa akcijom 'I' 

Nakon toga nismo diobili primjedbe na rad programa 



Poštovani, 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Ivan 


13204 



11.03.2013 10:14 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


12.03.2013 


13.03.2013 

Objekt 'knjdig.jas KNJIŽENJE DIGITALNE TV' ne knjiži na partnere koji su nositelji SK-a već na partnere 

iz faktura. 

Primjer: 

select * from part where part='500072'; nije nositelj 

select * from part where part='635160'; - nositelj SK 

select * from ustroj_part where part='500072'; 

select * from protokol where analitika='500072' and vprotokol='0'; 

Sve je proknjiženo na analitiku 500072. 

select * from arhivk where analitika in ('500072','635160') and vdok in ('DIG','BSS'); 


Na objektu knjdig.jas KNJIŽENJE DIGITALNE TV nije bila ugrađena kontrola na nositelja salda konta. 

Sada je i na ovom objektu napravljeno da se ne knjiži na partnere iz faktura nego na partnere nositelje salda 

konta. 

Novi WIN FAUS lib će biti dostupan sutra (13.03.2013) ujutro. 


Poštovani, 




0











Klijent: 





BO 

Hitnost: 



Višnja 


13203 

Riješen 


11.03.2013 10:11 

Upisao: 

Božo Mišeta 

Područje: 

LKEVP 


30.03.2013 


26.04.2013 

Kroz rjes_jke RJEŠENJA potrebno je preko F6 omogućiti pregled i ispis svih radnika koji imaju upisano 

rješenje (porodiljni, roditeljski, njega djeteta SRV, skraćeni rodiljni …). 

Lista bi trebala sadržavati podatke: 

-Šifra radnika 

-Prezime i ime radnika 

-Početni datum po rješenju 

-Završni datum po rješenju 

Šifru i naziv bolovanja 


Napravljen je novi objekt Pregled rješenja za bolovanja - przb_jke. 

Objekt je smješten na meniu ME1029 pozicija 10. 

Preuzmite: 

LAUS KEVP lib i objekt/meni-e (dostupno od sutra 16/04/2013). 


Poštovani, 

Potrebno je spustiti novi lib koji je već na internetu. 

S štovanjem 


Poštovani, 

nova verzija će biti dostupna 17/04/2013. 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Višnja 


13202 

Riješen 


11.03.2013 09:45 

Upisao: 

Božo Mišeta 

Područje: 

LKROP 


13.03.2013 


Kroz dis_ban_fk DISKETE ZA BANKE potrebno je izvršiti izmjenu naziva banke: 

VOLKSBANK D.D. ZAGREB u 

Sberbank d.d. 


Na objektu dis_ban_fk DISKETE ZA BANKE izmjenjen je naziv Volksbank u: SBERBANK d.d. (VOLKSBANK). 

Do daljnjega, radi bržeg snalaženja korisnika ostavljen je i naziv Volksbank. 

krop lib od 13.03.2013 



0











Klijent: 





Hitnost: 



Glorija 


13201 

U rješavanju 


08.03.2013 09:56 

Upisao: 

Božo Mišeta 

Područje: 

LSLOD 


15.03.2013 


Kod izmjene na pravilniku ugraditi kontrolu da se pri upisu Količine kotrolira pravilnik i u slučaju da količina 

upisana prelazi onu definiranu pravilnikom da se javi poruka: Upisana količina je veća od količine definirane 

pravilnikom. Želite li upisati podatak (d/n)? 



0











Klijent: 





Hitnost: 



Glorija 


13200 



08.03.2013 09:46 

Upisao: 

Božo Mišeta 

Područje: 

LWSLOD 


15.03.2013 


03.05.2013 

U excel listu iza stupca Voditelj potrebno ubaciti stupac Datum promjene (podatak datum iz tablice 

pravodd). 



0









Poštovani, 

Zahtjev je i kod nas neriješen- područje LWSLOD a u popisu neriješenih WinFaus. 

-- Zanemarite ranije poslano : 


10.06.2013.g. 

Zahtjev nije riješen . 

Odustajete li od zahtjeva ? 

Status: Čekamo stav HP 

Isprika zbog pogreške 


Poštovani, 

za ovaj zahtjev dobili ste slijedeću obradu 14.06.. Možemo li zatvoriti ovaj zahtjev. 

S štovanjem 

Na excel listi objekta lista3.jsl UPISANI PRAVILNICI PO DJELATNIKU nakon stupca Voditelj dodan je stupac 

Datum promjene (pravodd.datum). 

Preuzeti novi WIN SLOD liba u ponedjeljak 17.6.2013. 


Poštovani, 

za ovaj zahtjev dobili ste slijedeću obradu 14.06.. Možemo li zatvoriti ovaj zahtjev. 

S štovanjem 

Na excel listi objekta lista3.jsl UPISANI PRAVILNICI PO DJELATNIKU nakon stupca Voditelj dodan je stupac 

Datum promjene (pravodd.datum). 

Preuzeti novi WIN SLOD liba u ponedjeljak 17.6.2013. 



Možete zatvoriti. 

Lp 




0











Klijent: 





Hitnost: 



Katja 

Riješen 


07.03.2013 15:04 

Upisao: 

Božo Mišeta 

Područje: 

LROBD 


15.03.2013 




0









Poštovani! 

Zakazana je obuka djelatnika iz depo-a 15.03.2013.g. u Horvatovoj 82 (08:00-16:00 h), za rad sa 

dokumentima koji dolaze iz PU i idu prema PU(zahtjevnica, narudžba dobavljaču, izdatnica, povratnica..). 

Temeljem Ugovora broj HP-10/2-11432/12 potpisanog od strane Mipsa (Laus podizvođač) u članku 11. 

definirana edukacija djelatnika (15 djelatnika – 30 radnih sati). Također je u članku 12 definirana obuka 

Informatičara (8 djelatnika – 35 sati). 

Molim Vas da nam javite tko će, od strane tvrtke Laus CC, održati obuku djelatnika? 

Lp, 

From: Antonio Čubrić 

Sent: Friday, March 01, 2013 1:39 PM 

To: Ljiljana Kučić; Ljiljana Šegović Pivac 

Cc: Ljiljana Katančić; Brankica Ormuž; Blaženka Periša; Katja Kraljev; Vesna Ževrnja; Renata Basrek; 

Anita Skypala; Stipe Roguljić; Branka Mihaljević 

Subject: UUM - planogram za nastavka aktivnosti na temu produkcija e-zahtjevnice 

Poštovane kolege – sudionici u projektu e-zahtjevnica, 

Nastavno na zaključke radnog sastanka u Sektoru maloprodaje, a sve na temu e-zahtjevnica 

aktivnosti u nastavku na znanje vam stavljam kao slijedi; 

1. 4.3/2013 Odjel maloprodaje će oformiti i/ili samo ažurirati asortiman za tri PU koji su već u produkciji. 

Asortimane formirati sa 10 artikala, a na način da se obuhvate svih pet temeljnih asortimana (osnovni, 

prošireni, cjeloviti + akcijski, mikrolokacijski). U tom smislu obvezno je da predmetna tri ureda figuriraju kao 

ured kategorije A, B i C (nevezano za njihov stvarni status u kategorizaciji). Aktivirati asortimane i kategorije 

gore navedenih sa 4.3/2013 tako da se u periodu od 5.3/2013 pa do daljnjega izvode stvarne transakcije 

između predmetna tri PU i depoa ZG. Dnevno provoditi minimalno 3 transakcije po PU i to u oba smjera 

(zahtjevnica/RIM/primka u PU, odnosno Povrat iz maloprodaje/RPM). Nositelj ovog zadatka je OM u smislu 

definiranja asortimana, odnosno OUDC u smislu poticanja PU na provedbu dokumenata i samo provođenje 

operative u depou. Podrška u procesu Periša/MIPS, odnosno Kraljev/LAUS. 

2. Odjel maloprodaje će do 8.3/2013 izvesti predložak SVIH asortimana u perspektivi (osnovni, 

prošireni, cjeloviti, akcijski 1, akcijski 1, akcijski „n“ …, mikrolokacijski 1, mikrolokacijski 2, mikrolokacijski 

„n“ … ), odnosno oformiti grupe poštanskih ureda u smislu osnovne klasifikacije (A, B i C) odnosno ostalih 

grupa poštanskih ureda koje će po proizvoljnoj volji spajati sa navedenim asortimanima. Predmetno izvesti 

u xls. formi, predati ID na verifikaciju, 12-13.3/2012 imati usuglašen asortiman ispred Sektora. 

3. 12.3/2012 (Horvatova) planira se sastanak u smislu edukacije operative depoa (prijem dokumenata 

iz MIPS-a, obrada i plasman obrađenih dokumenata u aplik. LAUS). Molim Kraljev/Periša rezervirati i 

organizirati edukaciju na cca. 8 mašina (testno okruženje, LAUS, operativa u depou), naravno ovdje 

govorimo da jedna mašina figurira kao PU (u testnom okruženju, a prije edukacije prenijeti kategorizaciju i 

asortimana tri PU koji produkciju danas vrše, nadalje na ta tri predmetna PU napraviti stanje i prodaju 



0







zaliha iz definiranog -završen, Isporučen asortimana, - Korisnik odnosno potvrdio napraviti ispravnost stanje na depou). Ono što se ovim djelom želi postići 

jest stvarana operativa na edukaciji – želimo izbjeći situaciju da na edukaciji radimo pripremu PU i depoa 

(testno okruženje). 

4. 18.3/2013 na produkciju stavljamo stvarni asortiman i kategorizaciju SVIH PU HP (veza toč. 2), no 

produkciju radimo i dalje SAMO na tri PU koji će do tada raditi na produkciji. 

5. 1.4/2013 u produkciju bi stavili SVE PU županije karlovačke, a u opciji gdje bi produkciju PU 

karlovačke žup. ocijenili pozitivnom 15.4/2013 sa produkcijom bi išli na sve PU HP 

6. VAŽNO; prije stvarne produkcije potrebno je definirati okružnicu/glasnik s kojim ćemo staviti van 

snage dio uputa za rad iz sadržaja UPUTE za blagajničko i računsko poslovanje (naime, dio sadržaja iste je 

kontradiktoran sa budućim procedurama u radu sa e-zahtjevnicom, konkretno; dio oko zaduženja sa 

stvarno prispjelim količinama, dakle sadašnje upute propisuju zaduženja sa količinama iz Izdatnice u 

maloprodaju, a buduća praksa je zaduženja sa stvarno prispjelim količinama, odnosno formiranje 

automatskog zapisnika za razliku …). U tom smislu definirano je sa kolegicom Perišom da se sazove 

sastanak (drugi tjedan) povjerenstva koje je donijelo postojeće UPUTE za blagajničko i računsko 

poslovanje te da se u skladu sa zaključcima na temu nove procedure donese novo tehnološko rješenje, a 

iste ispred Sektora maloprodaje (u suglasju sa Odjelom računovodstva) pusti na teren u vidu okružnice i/ili 

Glasnika. 

Vezano za gore ŽUTO predlažem; 

a) Krenuti sa 15.4/2014 sa svim PU pod depoom ZG – razlog; tada nećemo obaviti obuku za SVE 

referente i operativu depoa ostalih depoa 

Za eventualna pitanja/pojašnjenja stojim na dispoziciji. 

Srdačan pozdrav, 

Antonio Čubrić 



0









Poštovani, 

Na tesnoj bazi u pripremi podataka za obuku djelatnika skladišta u petak, 15/03/2013 

potrebno je otkloniti grešku -674 koja se javlja na dokumentima ZAH i RIM. 

Treba dati dozvolu korisniku MASTER na tablicu zahtjev_projenos_MIPS. 

Nakon davanja dozvole, obavjestiti Laus, te odobriti Laus-u kreiranja 20tak dokumenata ZAH, 

koji trebaju poslužiti za obuku djelatnika! 

S štovanjem 


Poštovani, 

obuku će održati naš djelatnik Božo Mišeta. 

Molimo vas da pripremite dokumente za rad na obuci (ZAH) ili date odobrenje Laus-u da to napravi. 

S štovanjem, 

Zakazana je obuka djelatnika iz depo-a 15.03.2013.g. u Horvatovoj 82 (08:00-16:00 h), za rad sa dokumentima 

koji dolaze iz PU i idu prema PU(zahtjevnica, narudžba dobavljaču, izdatnica, povratnica..). 


definirana edukacija djelatnika (15 djelatnika – 30 radnih sati). Također je u članku 12 definirana obuka 

Informatičara (8 djelatnika – 35 sati). 

Molim Vas da nam javite tko će, od strane tvrtke Laus CC, održati obuku djelatnika? 


Poštovani, 

Izvršena obuka 15.03.2013. 

U prilogu izvještaj o izobrazbi. 

S štovanjem 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Glorija 


13199 



07.03.2013 13:44 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


10.03.2013 


Potrebno u filter i na pregled staviti polje Korisnik (uradio iz protokola) . Omogućiti masovno fiskaliziranje 

svih računa na pregledu sa kontrolom da se prebace samo računi koje je generirala osoba identična 

prijavljenoj. Znači kod masovne fiskalizacije potrebno da je polje Korisnik obavezno upisano, te da je 

prijavljena osoba identična upisanom korisniku inače poruka: Ne možete fiskalizairati račune koje niste 

fakturirali! Potrebno definirati parametar u kojemu će biti upisan Korisnik koji će biti izuzetak od navedenog 

pravila tj. smjeti će fiskalizirati račune i koje nije on izradio. Kod naknadne fiskalizacije uvijek uradio i 

vrijeme čitati iz protokola, a ne upisivati korisnika koji fiskalizira i vrijeme kada se fiskalizira. Pošto u 

protokolu nema sekunde može se staviti 00. 



0









Poštovani, 

Masovna fiskalizacija moguća je samo za račune koji imaju načim plaćanja za fiskalizaciju T- transakcijski 

račun . 

Jednom fiskaliziran račun ne može biti na pregledu za masovnu fiskalizaciju jer je već fiskaliziran 

------------------------------------------------------------------------------------------------------------------------------------------------------ 

---------- 

Molimo vaš stav : ostajete pri zahtjevu da se pregled i fiskalizacija oslanjaju na protokol tablicu ili se radi po 

varijanti ** (dolje navedeno) ? 

Lakše je napraviti kako tražite , ali se podaci ispisuju na fakturi po upisanom u prot_fisk (uradio,datum,..) . 

Ako to mora biti fakturist , varijanta ** je rješenje . 

------------------------------------------------------------------------------------------------------------------------------------------------------ 

---------- 

Tražili ste : 

Potrebno u filter i na pregled staviti polje Korisnik (uradio iz protokola) . 

- može se napraviti ovako kako tražite * , ali je bilo prijedloga i razgovora i o varijaniti ** : 

podatak korisnik iz rad_prootkol tablice koji je dokument prvi satvio u status>=3 . Napr : 

00041300009 RUL 1 MASTER 2013-02-12 08:00:00 

00041300009 RUL 3 MARKO 2013-02-12 00:12:00----> ** ovaj račun dobije korisnik MARKO na 

pregledu , a ostali ne i on ga može fiskalizirati 

00041300009 RUL 2 ANA 2013-02-12 00:15:00 

00041300009 RUL 3 ANA 2013-02-14 00:09:00 

00041300009 RUL 9 PETAR 2013-03-22 00:08:00---> * ovaj račun dobije PETAR i on ga može 

fiskalizirti 

Račun koji slijedi ne dobije na pregledu niti jedan korisnik jer mu status nikad nije bio 3 - nije zreo za 

fiskalizaciju 

00041300011 RUL 1 MASTER 2013-03-22 00:00:00---> ovaj račun 

00041300011 RUL 2 IVAN 2013-02-12 00:00:00 

00041300011 RUL 0 GLORIJA 2013-02-12 00:00:00 

00041300011 RUL 1 VEDRAN 2013-03-22 00:00:00 

Omogućiti masovno fiskaliziranje svih računa na pregledu sa kontrolom da se prebace samo računi koje je 

generirala osoba identična prijavljenoj. Znači kod masovne fiskalizacije potrebno da je polje Korisnik obavezno 

upisano, te da je prijavljena osoba identična upisanom korisniku inače poruka: Ne možete fiskalizairati račune 

koje niste fakturirali! 

Pretpostavljamo da se računi koji su jednom prošli status 3 ili veći neće vraćati u niže statuse . 

Ako imap hoće, potrebno je dodatno uvjetovati pregled i fiskalizaciju na način da je zadnji/trenutni status >=3 . 

PREPORUKA:_ račun koji je jednom u status3 ili većem nije mudro vraćati u niže statuse jer se nameće 

problem: 

Što napraviti s računom koji bio u status 3, fiskaliziran je a neko ga je vratio u niži status : osteje li ili se briše 

zapis o fiskalizaciji na njemu ? 

-------------------------------- 

Potrebno definirati parametar u kojemu će biti upisan Korisnik koji će biti izuzetak od navedenog pravila tj. smjeti 

će fiskalizirati račune i koje nije on izradio. Kod naknadne fiskalizacije uvijek uradio i vrijeme čitati iz protokola, a 

ne upisivati korisnika koji fiskalizira i vrijeme kada se fiskalizira. Pošto u protokolu nema sekunde može se staviti 

00. 

Ovo se može napraviti parametrom FISKAL : KORISNIK KOJI SVE MOŽE MASOVNO FISKALIZIRATI . 

Napomena : korisnik=MASTER podliježe svim kontrolama kao i ostali korisnici, osim ako nije upisan u 

parametar FISKAL 

------------------------------ 



0


Status: 








Poštovani, 

Napravljen je novi objekt fiskm.jas MASOVNA FISKALIZACIJA TRANSAKCIJSKIH RAČUNA na kojemu se 

pojavljuju svi nefiskalizirani transakcijski računi koje je prijavljeni korisnik generirao. 

Popis računa se za prijavljenog korisnika dobija se iz tablice u kojoj se nalazi povijest dokumenta evidentiranog u 

LAUS sustavu (rad_protokol) i to za prvi evidentirani slog u statusu >= 3. 

Upravo podaci iz tog sloga (korisnik,datum,vrijeme) će se zapisivati prilikom fiskalizacije računa u tablicu 

prot_fisk. 

Iznimka je korisnik koji ima pridružen parametar KFISK - KORISNIK KOJI SMIJE FISKALIZIRATI SVE RAČUNE 

koji će dobiti pregled svih nefiskaliziranih računa sa načinom plaćanja za fiskalizaciju T-transakcijski račun bez 

obzira da li ih je on generirao ili ne, 

ali će se prilikom fiskalizacije također će se zapisivati podaci (korisnik,datum,vrijeme) od korisnika koji je stvarno 

generirao dokumenta ne korisnik iz KFISK (pokrenuo fiskalizaciju) 

Za evidentiranje ovog korisnika potrebno je upisati i ažurirati novi LAUS parametar : 

KFISK - KORISNIK KOJI SMIJE FISKALIZIRATI SVE RAČUNE 

sa podacima: Sustav l1base Izmjena D Po ključu N Čitanje kod prijave N 

Na postojeći meni ME4321 dodan novi objekt fiskm.jas MASOVNA FISKALIZACIJA TRANSAKCIJSKIH 

RAČUNA na sljedeću slobodnu poziciju. 


Preuzeti novi WIN FAUS liba, objekate i menije s interneta u ponedjeljak 8.4.2013. 

Prijaviti i ažurirati novi parametar KFISK 



Izvedni su SQL-ovi koji se nalaze u samom progamu na test bazi bez uvjeta na korisnika i dobili smo samo 

jedan dokument koji je prikazan u prilogu zahtjeva, dakle stvarno ima samo jedan dokument koji zadovoljava sve 

uvjete za fiskalizaciju koji su za ovaj objekt sljedeći: 

1. mora imati upute za fiskalizaciju , nacpla = T, ind = N. 

2. mora imati evidentiran poslovni prostor i radno vrijeme 

3. mora imati upisan fisk_nacpla = 'T' u lm_usl_fak 

4. status dokumenta mora biti >= 3 

Potrebno je provjeriti da li su zadovoljeni svi ovi uvjeti za dokumente koji bi trebali izaći na pregledu za masovnu 

fiskalizaciju transakcijskih računa. 

Npr. spomenuti protokol 35358H1300001 nema upisan slog u lm_usl_fak. 


Poštovani, 





0











Klijent: 





Hitnost: 



Glorija 


13198 



07.03.2013 11:10 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


15.03.2013 


29.04.2013 

Molimo da se objektima rucfak_fas, fakis_fas i fakot_fas, spamt_fas omogući uvjet pregleda, uz postojeći 

Laus broj računa, pregled po fiskalnom broju računa. 

Na objetu rucfak_fas fiskalni broj odvojiti u tri polja: redni broj, poslovni prostor i naplatni uređaj, te ga u 

tablici pregleda prikazati u koloni iza statusa. 

Na objektu rekr_fas dodati uz laus broj računa novi stupac fiskalni broj računa te dodati kod ispisa na pisač 

i u excel-u (zbirni pregled po partnerima i uslugama, pregled po fakturama, zbirni pregled usluga). 

Kod ispisa prijemne knjige na pisač i ispis Prijamne knjige – Izvješće za ePK ispisivati fiskalni broj računa. 



0









Na objektu rucfak.jas dodana su filter polja za pretraživanje fiskalnog broja po rednom broju,poslovnom prostoru 

i prodajnom mjestu(naplatnom uređaju). 

Sva tri polja dodana su kao tri nova stupca u pregledu iz polja status. 

Na objektu rekr.jas doadano je polje Fiskalni broj (u foramtu redni broj-poslovni prostor-prodajno mjesto) u 

pregledu iz polja Broj računa. 

U istom formatu dodano je polje Fiskalni broj na ispise rekr_ras i rekr_xls. 

Na objektima fakis.jas,fakot.jas,spmt.jas na polju Faktura gdje se upisuje Laus broj dokumenta otvara se na F4 

Traži ili na dvostruki klik 

ekrani faksto1_fas ili fakot1_fas na koji su dodana filter polja za pretraživanje fiskalnog broja po rednom 

broju,poslovnom prostoru i prodajnom mjestu. 

Sva tri polja dodana su kao tri nova stupca u pregledu iz polja Iznos. 

Na objektu fakis.jas za masovni ispis faktura dodana su filter poja za pretraživanje fiskalnog broj po rednom 

broju od-do, poslovnom prostoru i prodajnom mjestu. 

Na ispisima Prijamne knjige i Izvješća za ePK dodan je ispis fisklanog broja u formatu redni broj-poslovni prostor 

-prodajno mjesto na kraj ispisa. 

Preuzeti novi WIN FAUS liba u utorak 30.4.2013. 


Poštovani , 

Greška je učena i ispravljena : nove verzije ekrana su prebačene u isporuku što pretjhodno nije bio slučaj . 

Potrebno za instalaciju /testiranje : 

Preuzeti novi WIN FAUS lib u utorak 2.5.2013. 



Kod ispisa prijamne knjige u excel Izvješće za ePK stupcima u kojima se ispisuju Laus broj i Fiskalni broj su 

zamjenjena mjesta. 

Preuzeti novi WIN FAUS liba u ponedjeljak 6.5.2013. 


Poštovani, 





0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13197 



07.03.2013 10:50 

Upisao: 

Božo Mišeta 

Područje: 

EHPUR 


08.03.2013 


18.03.2013 

Kod surješavanja ponovnom evidencijom u P8 - T63 omogućiti povlačenje oznake zadnje 

zadužene/proslijeđene nadležnosti. 



0









Poštovani , 

Procjena neće preći 8 sati . 

U rješavanju je ovaj zahtjev, isporuka danas ili 18.03.2013. 


- 

Poštovani, 




Molimo danas 20.03.2013. pristup na produkciji kolegi V. Livaiću od 16.00 – 17.00 sati kako bi se prebacili 

potvrđeni zahtjevi: 13197, 13210 i 13215. 

Zahvaljujemo. 

Lp, 



Poštovani, 

Prebačeno na produkciju. 



Poštovani! 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Renata Basrek 



07.03.2013 07:45 

Upisao: 

Božo Mišeta 

Područje: 

LROBD 


08.03.2013 




0









Poštovani, 

Molim da prema dolje navedenom provedete edukaciju za djelatnike maloprodaje koja će se održati u 

petak, 08.03.2013 u Horvatovoj od 13-16 h. 

Očekujem potvrdu termina. 


Renata Basrek 

Voditelj odjela za implementaciju ERP rješenja 

Služba za razvoj i implementaciju IT rješenja 

Sektor IT 

Hrvatska pošta d.d. 

Horvatova 82 

10000 Zagreb 

Tel: +385 1 6626 310 

Faks: +385 1 6626 301 

GSM: +385 98 223 249 

e-mail: renata.basrek@posta.hr 

www.posta.hr 

From: Brankica Ormuž 

Sent: Wednesday, March 06, 2013 12:20 PM 

To: Renata Basrek 

Cc: Odjel za implementaciju ERP rješenja; Ljiljana Šegović Pivac; Nikola Holubek 

Subject: RE: edukacija za unošenje asoritmana 




0







definirana -završen, edukacija Isporučen djelatnika - Korisnik (15 djelatnika potvrdio – 30 ispravnost radnih sati). Navedenu edukaciju nismo konzumirali. 

Također je u članku 12 definirana obuka Informatičara (8 djelatnika – 35 sati). 

Pozdrav, 

Brankica Ormuž 

Referent 

HP-Hrvatska pošta d.d. 

Sektor maloprodaje 

Odjel maloprodaje i usluga 

tel. 01/4981-184 

faks 01/4981-240 

mob. 098/309-626 

brankica.ormuz@posta.hr 

From: Renata Basrek 

Sent: Wednesday, March 06, 2013 11:17 AM 

To: Brankica Ormuž 

Cc: Odjel za implementaciju ERP rješenja; Ljiljana Šegović Pivac; Nikola Holubek 

Subject: RE: edukacija za unošenje asoritmana 

Brankice, 

Da li navedena edukacija ide na teret ugovora o nabavi, tj. da li je prema ugovoru osigurana edukacija, a do 

sada nije realizirana? 

Lp, 

Renata Basrek 



Sektor IT 



0


Status: 








Horvatova 82 

10000 Zagreb 

Tel: +385 1 6626 310 

Faks: +385 1 6626 301 

GSM: +385 98 223 249 

e-mail: renata.basrek@posta.hr 

www.posta.hr 

From: Brankica Ormuž 

Sent: Wednesday, March 06, 2013 8:50 AM 

To: Odjel za implementaciju ERP rješenja 

Subject: FW: edukacija za unošenje asoritmana 

Poštovani, 

S obzirom da je projekt e-narudžbe pri samom kraju i prethodi produkcija na sve PU, iskazala se potreba za 

službenom edukacijom unosa asortimana i kategorija PU za djelatnike Odjela maloprodaje. 

Molim Vas da omogućite obuku u terminu petak od 13-16 sati u Horvatovoj i da isprintate upute za 7 

osoba, 

Pozdrav, 

Brankica Ormuž 


Poštovani, 

na kojoj bazi će se raditi obuka korisnika? 

Na radnoj bazi obuke, molim korisničku dozvolu za sve sudionike, koja korisnicima omogučuje rad sa svim 

modulima e-zahtjevnice- narudžbe,a bilo bi dobro da mogu koristiti sve module robd područja. 

S štovanjem 


Odrađena obuka za referente maloprodaje 08/03/2013 

U prilogu izvještaj o izobrazbi 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13196 



06.03.2013 13:57 

Upisao: 

Božo Mišeta 

Područje: 

EHPUR 


11.03.2013 


Trenutno je u aplikaciju eHPUR u T37 Unos djelatnika - moguće dva puta unijeti (aktivirati) istog djelatnika 

(pod istom laus šifrom). 

Potrebno je doraditi unos da se: 

- javi poruka upozorenja “ već postoji aktivan djelatnik pod istom laus šifrom” ili 

-onemogućiti aktiviranje jedno te istog djelatnika (ista laus šifra) više puta. 


Poštovani, 




Poštovani, 





0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13195 



06.03.2013 10:50 

Upisao: 

Božo Mišeta 

Područje: 

LFINK 


08.03.2013 


Prilikom ažuriranja minimalnog datuma knjiženja dozvolio je izmjenu minimalnog datuma zvjezdica * na 

01.02.2013. godine, a da su otvorena dva naloga iz 2012.godine. 

Prilikom mijenjanja minimalnog datuma na zvjezdici postojala je kontrola odnosno nije dozvolio izmjenu 

ukoliko bi bilo otvorenih naloga s datumom manjim od minimalnog. 



0









Poštovani, 

Pretpostavljamo da se parametar MNDKN mijenjao na produkcijskoj bazi a nalozi gledali na test bazi. 

Stanje u obje baze je uredno . 

Inače, MNDKN može se postaviti za ključ = * na datum d1 a da ima naloga sa manjim datumom knjiženja dn











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13194 



06.03.2013 10:44 

Upisao: 

Božo Mišeta 

Područje: 

LROBD 


08.03.2013 


Kod testiranja pripreme dokumenata za knjiženje ( dokument RC8) javlja se programska greška: loše polje 

ili argument… 


Poštovani, 

Ispravljeno je knjiženje za pripremu dokumenta Pu u glavnu knjigu za vrstu dokumenta RC8 Nivelacija cijene na 

PU. 


S štovanjem 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13186 



06.03.2013 10:23 

Upisao: 

Božo Mišeta 

Područje: 

EHPUR 


08.03.2013 


Tajnica Ivana Habuš pripada orgj 40015 SEKTOR INFORMACIJSKIH TEHNOLOGIJA. 

Ne može obavljati neke radnje: 

-postavljanje zahtjeva 

-zbirno pretraživanje novijih spisa 

-pretraživanje prema prvotnom rješavatelju 

-zaduživanje spisa koji su proslijeđeni iz drugih odjela, sektora divizija (nema uvid u ulazne spise) 

ukratko rečeno ne može raditi gotovo ništa u aplikaciji, pogotovo kada su u pitanju spisi iz 2013 godine. 

Npr. 

DPO-04-004695/13- ne vidi ga u popisu i ne možu proslijediti tj. nikakve radnje po spisu nije u mogućnosti 

napraviti jer nije dostupan u aplikaciji. 

DPO-04-005271/13- -„- 

DPO-04-005267/13- -„- 

DM-2/1-002513/13- proslijeđen prema DPO-04, ali ga ne vidi i ne možu zaduživati na rješavatelja unutar 

ORGJ DPO-04 

Napomena: 

Po starije unesenim spisima je moguć rad (spisi od prije desetak dana), a po svim nastalim nakon tog 

perioda, nije. 



0









Poštovani, 

Jučerašnjim prebacivanjem dorada po zahtjevu 13157 (05.03.2013.) na test, smatramo da su točke koje ste 

naveli po ovome zahtjevu (13186) neposredno riješene. 

U rješavanju je dio koji niste naveli, a potrebno je riješiti (možemo kroz ovaj zahtjev): 

· Zbirno pretraživanje – prikazuje kao rezultat pretrage samo nove spise (samo kod uloge – Tajnica) 

· Prvotni rješavatelj – prikazuje kao rezultat pretrage samo nove spise (kod svih uloga) 

Lp, 


Poštovani, 

Riješeno je i prebačeno na test: 

· Zbirno pretraživanje – prikazuje kao rezultat pretrage samo nove spise (samo kod uloge – Tajnica) – 

SADA PRIKAZUJE I NOVE I STARE 

· Prvotni rješavatelj – prikazuje kao rezultat pretrage samo nove spise (kod svih uloga) – SADA 

PRIKAZUJE I NOVE I STARE 

Smatramo da je riješeno sve po ovom zahtjevu. 


Lp, 



0









Poštovani, 

Javlja li se greška identična kao jučer ili neka druga? 

Mi smo se probali ponovno spojiti: 

1. direktno na serveru , link (http://localhost/eHPUR_Test) 

2. preko vanjskog linka (http://sv-1ot-eaptest.posta.int/eHpur_test) 

U oba slučaja smo uspjeli pristupiti aplikaciji kao tajnica Ivana Habuš (ihabus; ihabus). 

Predlažemo slijedeće: 

1. očistiti history u browseru – IE i potom pristupiti aplikaciji 

2. pristupiti aplikaciji s drugog računala 

3. ukoliko korisnica ne uspije na gore navedena dva načina, molimo Print Screen cijelog ekrana na kojem se 

vidi i link aplikacije, cjelokupna greška i sl. 

Lp, 


Poštovani, 

Možemo li zaključiti slijedeće: 

· Nema primjedbi po zahtjevu 13157 – može se prebaciti na produkciju 


· Izvršiti će se na produkciju prebacivanje već potvrđenih zahtjeva: 12695, 12696, 12706, 12761 i 12790 

· Može se zatvoriti zahtjev 13191 




0









Poštovani, 

Danas 08.03.2013. u 16.00 sati započeti će se sa prebacivanjem na produkciju svih prethodno potvrđenih 

zahtjeva (jedan dio će se započeti i odraditi ranije, ali ne utječe na rad aplikacije) stoga molimo da korisnici 

prestanu sa radom u 16.00 sati. 

Zahvaljujemo, 

Lp, 


Poštovani, 

Prebačene su dorade po ovom zahtjevu na produkciju - 8.3.2013 iza 16:00 . 

Zahtjev zatvaramo - Riješen 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Ivan 


13193 



06.03.2013 10:17 

Upisao: 

Božo Mišeta 

Područje: 

EOBRRAC 


06.03.2013 


Kod ovjere računa za podgrupu troškova 2013-16,1,1 ne pušta orgjedincu 31009 grupa područja za 

upravljanje mrežom, a u postavkama u Lausu definirane su sve razine troškova. 

Promjene su prošle kroz LAUS i MILA bazu. 

U eObradi na detalju naveden epodgrupe vidi se da su definirane sve razine ovjere dok se na skupnom 

pregledu vide samo 2 razine ovjere. 



0









Za HP: 

Molim pristup na produkciju za Tvrtka Matoševića vezano za zahtjev 13193 

Vedrana Bukovšek 

Voditeljica Odjela realizacije 

projekata posebne namjene 

mob: 091/2353-803, 01/5393-906 

www.dokumentit.hr 


Molim da pristup za Tvrtka Matoševića vezano za zahtjev 13193 ostane aktivan i tokom sutrašnjeg dana. 



Podaci u zajedničkoj bazi ne odgovaraju dogovorenom načinu rada. Dogovoreno je da se za 

TipTroskaRazinaAkcija koristi šifra I (insert) i D (deactivate). 

Kako bi se navedene greške riješile potrebno je poslati retke sa sifrom akcije (I), a ne (U)! 

TipTroskaRazinaID TipTroskaRazinaPodgrupaTroska TipTroskaRazinaRazinaSifra 

TipTroskaRazinaAkcija TipTroskaRazinaDatumVrijemeUpisa TipTroskaRazinaAktivnost 

1265 2013-16.1.1 1 D 

2013-02-01 10:12:38.627 N 

1266 2013-16.1.1 2 D 

2013-02-01 10:12:38.657 N 

1267 2013-16.1.1 3 D 

2013-02-01 10:12:38.683 N 

1277 2013-16.1.1 1 U 

2013-03-04 10:15:22.110 D 

1278 2013-16.1.1 2 U 

2013-03-04 10:15:22.230 D 

1279 2013-16.1.1 3 U 

2013-03-04 10:15:22.287 D 



0









Kod akcije aktiviranja neaktivnog sloga za tip razine onemogućen je upis akcije U (update) već se upisuje akcija I 

(insert). 






S štovanjem 





0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13192 



06.03.2013 10:16 

Upisao: 

Božo Mišeta 

Područje: 

LROBD 


08.03.2013 


U korisničkoj uputi (eUputa za rad /projekt eNarudžba- Zahtjevnica, Verzija: 3.00 30.12.2012., str. 6) piše: 

“U status 3 – dezaktiviran automatski se prebacuju asortimani kojima istekne datum Do, ako ih nismo 

„ručno“ prebacili.” - ova automatika ne radi, pa vas molimo da je ispravite. Dakle, kada asortimanu istekne 

datum do, da se automatski prebaci u status 3 – dezaktiviran. 


Prilikom prijenosa asortimana u mips dodano je da se i sam asortiman prebaci u staus 3 Dezaktiviran ako su 

sve njegove stavke u statusu 3 DEZAKTIVIRANE. 

Potrebno je preuzeti pather tran lib koji će biti na internetu 08.03.2013. 


Poštovani, 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13191 



06.03.2013 10:02 

Upisao: 

Božo Mišeta 

Područje: 

EHPUR 


08.03.2013 


Djelatnica Ivana Habuš (tajnica) se nije uspjela spojiti na vašu testnu bazu (korisnik: ihabus, 

lozinka:ihabus). 

Javlja joj se „server error“ – nemate ovlaštenja za pristup transakciji P9T30. 

-- KOREKTIVNO----> PERFEKTIVNO 



0









Poštovani, 

Ne možemo se spojiti na testni server HP- a (privitak). 

Do prije pola sata pristupali smo testu bez problema. Probali smo pristupiti sa dva različita korisnička računa. 

Molimo povratne informacije, kako bismo mogli pristupiti rješavanju 13191. 

Zahvaljujemo, 

Lp, 


Poštovani, 

Upravo smo se uspjeli spojiti na testni server. 

Također, bez problema smo korisničkim podacima: user: ihabus, pass: ihabus pristupili aplikaciji. 

Molimo da probate ponovno. 

Ukoliko je sve u redu, predlažemo zatvaranje zahtjeva. 


Poštovani, 

ne možemo Vam odgovoriti na postavljeno pitanje budući da do same aplikacije ne možemo ni doći jer ne 

možemo pristupiti remote- om na testni server kao što smo naveli u prošlom mailu. 

Lp, 



0









Poštovani, 

Upravo smo se uspjeli spojiti na testni server. 

Također, bez problema smo korisničkim podacima: user: ihabus, pass: ihabus pristupili aplikaciji. 

Molimo da probate ponovno. 

Ukoliko je sve u redu, predlažemo zatvaranje zahtjeva. 

Lp, 

DA 

- 

NE 



0









Poštovani, 

Javlja li se greška identična kao jučer ili neka druga? 

Mi smo se probali ponovno spojiti: 

1. direktno na serveru , link (http://localhost/eHPUR_Test) 

2. preko vanjskog linka (http://sv-1ot-eaptest.posta.int/eHpur_test) 

U oba slučaja smo uspjeli pristupiti aplikaciji kao tajnica Ivana Habuš (ihabus; ihabus). 

Predlažemo slijedeće: 

1. očistiti history u browseru – IE i potom pristupiti aplikaciji 

2. pristupiti aplikaciji s drugog računala 

3. ukoliko korisnica ne uspije na gore navedena dva načina, molimo Print Screen cijelog ekrana na kojem se 

vidi i link aplikacije, cjelokupna greška i sl. 

Lp, 


Poštovani, 








Poštovani, 




0









Poštovani! 


Lp, 


Poštovani, 

Molimo da se ovom zahtjevu promjeni vrsta održavanja u perfektivno. 

Lp, 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13185 



06.03.2013 09:51 

Upisao: 

Božo Mišeta 

Područje: 

EHPUR 


08.03.2013 


Molimo da dostavljene podatke o rješavateljima importirate u aplikaciju eHPUR bez razmaka (space-a) 

između imena i prezimena. 



0









Poštovani, 


Lijep pozdrav 


Poštovani, 

Molimo pristup produkciji za kolegu V. Livaića danas 22.03.2013. od 16.00 – 17.00 sati, a vezano za zahtjev 

13185. 

Zahvaljujemo, 

Lp. 


Poštovani, 


Molimo povratne informacije/ suglasnost za zatvaranje zahtjeva - Riješen kao i za sve zahtjeve iz eHPUR koji su 

danas prebačeni na produkciju 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Ivan 


13190 



06.03.2013 09:47 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


06.03.2013 


Kod generiranja faktura preko objekta fakpl.jas sve fakture nisu dobile fiskalni broj. 

Primjer: 

select * from protokol where orgj='35366' and uradio ='SVESUROI' and datum='05.03.2013' and 

vrijeme='14:54' into temp vbv; 

select * from protokol where orgj='35366' and uradio ='SVESUROI' and datum='05.03.2013' and 

vrijeme='14:54'; 

select * from prot_fisk where protokol in 

(select protokol from vbv); 

Potrebno je provjeriti sve fakture koje su napravljene a nemaju fiskalni broj te ih fiskalizirati. 

Potrebno je doraditi objekt da se ovakve stvari ne događaju. 

Potrebno je također provjeriti objekte za fakturiranje HPX i POS usluga te njih doraditi. 



0









Poštovani, 

zahtjev je riješen kroz druge zahtjeve ( računi za TK usluge se nisu fiskalizirali - zahtjev HP 13297 riješen ) 

kao i dopuna : 

Kod masovno ispisa faktura za HPX usluge (FAH) ne ispisuje se dobro fiskalni broj. 

Također potrebno je podesiti da se LAUS broj ispisuje sa crticama xxxxx-xxx-xxxxx. 

Molimo povtratne informacije/ suglasnost za zatvaranje zahtjeva - Riješen 


Poštovani, 

Ponavljamo poslano 19.4.2013 17:56:17 

zahtjev je riješen kroz druge zahtjeve ( računi za TK usluge se nisu fiskalizirali - zahtjev HP 13297 riješen ) 

kao i dopuna : 

Kod masovno ispisa faktura za HPX usluge (FAH) ne ispisuje se dobro fiskalni broj. 

Također potrebno je podesiti da se LAUS broj ispisuje sa crticama xxxxx-xxx-xxxxx. 

Molimo povtratne informacije/ suglasnost za zatvaranje zahtjeva - Riješen 


Poštovani, 

po vašm nalogu zatvaramo zahtjev. 

S štovanjem 

Zatvoriti. 

Lp 




0











Klijent: 








Višnja 


13189 

Riješen 


05.03.2013 15:54 

Upisao: 

Božo Mišeta 

Područje: 

LKROP 


17.05.2013 

Kroz radis_fk UKUPNA ISPLATA RADNIKU potrebno je listu radis_rk.txt doraditi na način da se: 

1.Naslov liste: 

Ukupna isplata radniku za period od – do izmijeni u 

Ukupne isplate radnika u periodu od – do 

jer se isplate radnika odnose na isplate U PERIODU. 

2.Na kraju liste izvrši sumiranje podataka UKUPNO po VRSTAMA ISPLATE - sada u stupcima koji trebaju 

sadržavati podatke o satima, iznosima itd. upisane su sve NULE. Molimo da se kao što je predviđeno u 

navedenim stupcima ispišu sumirani podaci o isplatama u traženom periodu. 



0









Naslov liste radis_fk je izmjenjen prema zahtjevu.Krop lib je na internetu od 27.03.2013. 

Da bi lista ispravno radila bilo je potrebno prema uputama napisanim u obradi LAUS zahtjeva 20709 orig. broj 

9386 iz 2009. godine ažurirati tablice glista i gpodaci.U Vašoj bazi podataka tablica gpodaci nije popunjena stoga 

lista ne prikazuje sumarne podatke na dnu liste.Potrebno je ažurirati podatke prema poslanim uputama i onda 

testirati listu. 

Pozdrav 


Poštovani , 


Ranije smo poslali pojašnjenje : 

Naslov liste radis_fk je izmjenjen prema zahtjevu.Krop lib je na internetu od 27.03.2013. 

Da bi lista ispravno radila bilo je potrebno prema uputama napisanim u obradi LAUS zahtjeva 20709 orig. broj 

9386 iz 2009. godine ažurirati tablice glista i gpodaci.U Vašoj bazi podataka tablica gpodaci nije popunjena stoga 

lista ne prikazuje sumarne podatke na dnu liste.Potrebno je ažurirati podatke prema poslanim uputama i onda 

testirati listu. 






Poštovani, Zahtjev je adaptivni 

- radi se o izmjenama naziva na postojećoj listi 

- analizirani podaci na kornsičkoj instalaciji i utvrđeno kako nisu evidentirane upute. 

Molim promijeniti vrstu održavanja. 




Poštovanio, 

Molimo odobrenje za zatvaranje ovog zahtjeva. Zaključci poslani 29.4. ukazuju na potrebu ažuriranja uputa. 

LP 



Sukladno odgvooru od gdje Višnje Abija Ivček, zatvaramo zahtjev. 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Glorija 


13188 

U rješavanju 


05.03.2013 14:32 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


20.03.2013 


Kod upisa organizacijske jedinice kod izlaznih računa potrebno je napraviti kontrolu da li ona prijavljena kao 

poslovni prostor. 

•Rucfak.jas 

•Racfakd.jas 

•Ruckat.jas 

•Rucfil.jas 

•Storniranje računa 

•Masovno generiranje faktura (fakt.jas, fakpl.jas, fakhp.jas) 

•Kamate 

Znači potrebno je onemogućiti izradu izlazne fakture koja podliježe fiskalizaciji, a nije prijavljena kao 

poslovni prostor niti su za nju definirane upute 



0









Poštovani, 

Jasna je svrha zahtjeva : 

Kod upisa organizacijske jedinice kod izlaznih računa potrebno je napraviti kontrolu da li ona prijavljena kao 

poslovni prostor. 

Znači potrebno je onemogućiti izradu izlazne fakture koja podliježe fiskalizaciji, a nije prijavljena kao poslovni 

prostor niti su za nju definirane upute 

Međutim smatramo da neke od navedenih kontrola/ zabrana nije dobro ili nije potrebno podržati . 

Molimo odgovor na komentare po pojedinim točkama . 

Status : Čekamo stav HP 

a) Rucfak.jas 

-- nema pitanja , osim što smatramo da storniranje ne treba imati ovu kontolu 

b)Racfakd.jas 

-- nema pitanja, osim što kod storniranja ne treba imati ovu kontrolu 

c)Ruckat.jas 


d) Rucfil.jas 


e)Storniranje računa 

-- kod storniranja ne treba imati ovu kontrolu . Razlog: što ako se stari račun treba stornirati a na orgj je koja nije 

poslovni prostor ? 

f)Masovno generiranje faktura (fakt.jas, fakpl.jas, fakhp.jas) 

-- kontrolu treba staviti na aktiviranje ugovora s kupcem a ne na masovno generiranje . 

Razlog: kasno je kontrolirati a i dugotrajno kad već ide fakturiranje . 

Bolje je kontrolu uvesti u raniju fazu obrade tj. u ugovor s kupcem jer faktura 'naslijedi' orgj iz ugovora 

g) Kamate 

-- imamo infromaciju da se kamate 'sele' protokol F --> 1 (predračuni ) koji se ne fiskalizira niti ide u knjigu 

IRA/PDV 

U tom slučaju ova kontrola nije potrebna 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Ivan 


13187 

Riješen 


05.03.2013 13:55 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


05.03.2013 


Kod masovnog ispisa faktura krivo se ispisuju fakture koje su na više stranica. 

Također odmah promijeni da se broj računa ispisuje na ovaj način: 11009-013-01241.(Ispis za ove uvjete 

je u prilogu) 


Ispravljen je masovni ispis faktura. Broj fakture se sada ispisiva s crticama. 



Poštovani, 


Nismo dobili primjedbe nakon zadnje obrade 5.3.2013 . : 

Ispravljen je masovni ispis faktura. Broj fakture se sada ispisiva s crticama. 




0











Klijent: 



Pitanje 


Hitnost: 

Vrlo hitno 


Katja 


13184 



05.03.2013 08:12 

Upisao: 

Božo Mišeta 

Područje: 

EHPUR 


08.03.2013 


Molim informaciju, da li se kroz aplikaciju mogu ručno unijeti veze 

stara organizacijska jedinica – nova organizacijska jedinica (koja ju nasljeđuje), kako bi u budućnosti mogli 

riješiti eventualne probleme koji bi se mogli javiti ako se organizacijske jedinice ispravno ne povežu? 



0









- 

Poštovani, 

Trenutno u aplikaciji nije podržana ta mogućnost. 

Ukoliko je potrebno omogućiti, molimo pošaljite zahtjev ili isti vežite za ovaj uz kategorizaciju vrste održavanja 

kao adapti 


Poštovani, 


Promjene su izvršene/vidljive u T34 - Uređivanje org. jednice. 

Ako želite da nova org nasljedi ˝staru/neaktivnu˝ odaberite novu aktivnu i u polju ˝Poveži neaktivne 

organizacijske jedinice na postojeću aktivnu˝. 

Također, možete i odabrati neaktivnu orgj i u polju ˝ Poveži aktivne organizacijske jedinice na postojeću 

neaktivnu ˝ odabrati neaktivnu orgj. 



Poštovani, 

Prema dopisu od HP ( Renata Basrek) dana 6.3.2013. : 

Osnovni problem koji ste naveli s promjenom organizacije je povezivanje novih sa starim organizacijskim 

jedinicama, a sada nam napišete da to niste podržali kroz aplikaciju!? 

Molim da to učinite kao perfektivno održavanje s dostavljenim točnim uputama za rad u aplikaciji kada dođe do 

promjene organizacijske strukture ili ako to niste podržali prilagodite aplikaciju da ispravno radi bez tih veza. 

promijenjena je vrsta održavanja u PERFEKTIVNO 

Molimo povratne informacije/ suglasnost za prebacivanje na produkcij 

(30.4.2013. zahtjev je riješen i prebačen na testni server ) 


Poštovani, 

Izvršene su korekcije po ovome zahtjevu i prebačene na testni server . 

molimo provjeru. 



0









Poštovani, 

Molim Vas informaciju o statusima potonje navedenih zahtjeva odnosno mogu li se isti zatvoriti: 

1. eHPUR 

* 13184 

* 13256 

* 13332 

* 13345 

* 13397 

* 13401 

* 13268 – je li zahtjev u redu i mogu li se dorade izvršiti i na eObradi računa (Zahtjev 13269) 

2. Upisnik 

* 12714.16 

3. ePN 

* 12603.6 

* 13132.3 

* 13356 

* 13393 

4. eObrada računa 

* 13386 – je li zahtjev u redu? 

Unaprijed zahvaljujem na povratnim informacijama. 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13183 



05.03.2013 08:08 

Upisao: 

Božo Mišeta 

Područje: 

EHPUR 


08.03.2013 


Molimo da za polje “Poseban popis gradiva”, omogućite pretraživanje u transakciji T66-Izlučivanje 

arhivskog gradiva, po nazivu i klasifikacijskoj oznaci (broju). 



0









Poštovani, 

Molimo Vas informaciju na koji podatak se misli kada kažete pretraživanje po klasifikacijskoj oznaci (broju). 

Mislite li na podatak ˝Redni broj˝ (prva kolona)? 


Poštovani, 

Zasada ovo polje "trajno" je informativno polje (ne utječe na arhiviranje i računanje rokova) 

Tako je dogovoreno i napravljeno : kontakt Pisarnica. 



U transakcijama: 30, 66 i 67 potrebno je na tražilici ugraditi filter polje ˝Vrsta arhivskog gradiva˝ u kojem će se 

moći pretraživati po rednom broju i nazivu? 

Time zatvaramo 12706 i ostavljamo ovaj zahtjev. 

Lp, 


Po dogovoru sa sastanka održanog 16.04.2013 u Jurišićevoj 13, u prilogu vam dostavljam tablicu Posebnog 

popisa arhivskog i registraturnog gradiva HP-a. 

Molim vas odgovor na slijedeće upite: 

1. Da li je potrebno raditi aplikacijske dorade vezane uz import ovih podataka iz priloga? 

2. Ako nisu potrebne apl.dorade, koliko vam je potrebno da importirate podatke i do kada bi ih mogli importirati? 

2. Da li se navedeni popis može unijeti kroz aplikaciju? Ako može, molim Vas da nam navedete preko koje 

trensakcije je moguć unos? 

Lp, 


Poštovani, 

Ovaj zahtjev je vezan isključivo za ugradnju polja za pretragu u T66 te Vas molim da otvorite novi zahtjev za novi 

import podataka i sve vezano uz to. 

Molimo Vas informaciju jeste li dosadašnje spise povezivali sa starim/trenutnim podacima iz ovog polja? Naime, 

ako jeste, potrebno je onda pronaći sve te spise i ˝namapirati˝ na nove podatke koje se dostavili. Ako je tako, 

onda nam treba poveznica sa starih na nove ili eventualno označiti stare zapise kao neaktivne. 

Nakon ovog podatka možemo dati procjenu. 

Nije moguće kroz aplikaciju unijeti podatke. 

Lp, 

Branka 



0









Poštovani, 




Poštovani, 

Omogućena Vam je pretraga po zatraženom, međutim, ista se izvršava u filter polju ˝Vrsta arhivskog gradiva˝ po 

oba kriterija. 

Primjer u privitku. 



Poštovani, 

Molimo Vas pristup na produkciju za kolegu Vjerana Livaića danas, 20.05.2013. od 16.00 sati. 

Prebacivali bi se slijedeći zahtjevi: 

· 13183 

· 13184 

· 13256 

· 13332 

· 13372 

· 13374 


Lp, 


Poštovani, 

Vezano za jučerašnje prebacivanje zahtjeva, za manji dio zahtjeva potreban nam je backup baze podataka s 

produkcije za aplikaciju eHPUR. 

Nastavno na napisano, molimo i danas 21.05.2013. pristup za kolegu Livaića poslije 16.00 sati. 

Molimo povratne informacije u folderu gdje će se backup nalaziti. 

Unaprijed zahvaljujemo. 



0









Poštovani, 





0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


Poštovani! 

13182 



04.03.2013 13:27 

Upisao: 

Božo Mišeta 

Područje: 

LTRAN 


04.03.2013 


Molim Vas hitno otklanjanje greške iz priloga kako bi danas u 16 h mogli prenijeti asortimane koji vrijede od 

sutra. 

Unaprijed hvala! 

LP, 

Katja Kraljev 


Ispravljena je greška koja se javila prilikom prijenosa kategorija PU. 

Instalacija: Novi LAUS TRAN je već na internetu. 


Poštovani, 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Ivan 


13179 



04.03.2013 10:06 

Upisao: 

Božo Mišeta 

Područje: 

LFINK 


05.03.2013 


Molimo Vas kod izvještaja na objektu opo.hp.ff kod prebacivanja liste u excel tablicu na ispis pojedinačno 

po dokumentima - doda ugovor iz kojeg je faktura izrađena, šifru zadužene osobe iz ugovora, te naziv (ime 

i prezime) zadužene osobe. Za fakture za koje ne postoji taj podatak polja :ugovor,radnik,naziv ostaviti 

prazna. 

--- dopuna (Ivan 5.3.2013. ) :Ovo se odnosi na zahtjev HP broj 13179 : 

Krivi objekt nam je korisnica napisala u zahtjevu. Potrebno je to omogućiti na objektu: opos_jf. 



0









Poštovani, 

Nakon što se napravi F5 Pregled na opo_hp_ff Opomene za Male/Srednje/Velike kupce 

i dobije opo1_hp_ff Opomene - Pregled I Ispis 

omogućeno je/ postoji više ispisa opomena : 

Excel1 F1 opo_exc1 O P O M E N A na dan 31/12/2012 ( za analizu) 

Excel2 F2 opo_exc2 PREGLED PLAĆANJA POSLIJE OPOMENA 

Ispis F3 opo1_hp_rf OPOMENE Dospjela potraživanja od do 

Opomene F6 opo_hp O P O M E N A na dan 31/12/2012 (za slanje kupcu) 

Pretpostavka : 

zahtejv za dopunom excel ispisa odnosi se na ispis na tipki F1 Excel (opo_exc1) ? 

Molimo potvrdu pretpostavke ili navedite na koji ispis se zahtjev odnosi . 


Na excel ispisu opos2_xls_rf ISPIS POJEDINAČNO PO DOKUMENTIMA koji se nalazi na objektu opos_jf 

dodani su stupci Ugovor,Radnik,Naziv (radnika). 

Preuzeti novi LAUS BASE i FINK liba u četvrtak 7.3.2013. 


Dodan je ugovor ali ne i radnik te ime i prezime radnika. 

Primjer u prilogu. 

Lp, 

Ivan 


Ispravljen je prikaz širfe i naziva radnika na excel listi opos2_xls. 



Poštovani, 

ispravljen je prikaz širfe i naziva radnika na excel listi opos2_xls. 









0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13181 



04.03.2013 08:24 

Upisao: 

Božo Mišeta 

Područje: 

LROBD 


06.03.2013 


Potrebne su nam ažurirane korisničke upute za rad (PROJEKT E-NARUDŽBA – ZAHTJEVNICA) sa 

naknadno izvedenim doradama u aplikaciji: 

(npr. Dodano stanje u depu na ekranu ZAHst_fd, storno dokumenta RIM - što se dešava kad se izdatnica 

stornira, dorade na povratnici iz maloprodaje RPM itd. ) 


Poštovani, 

u prilogu obrade nalaze se ažurirane upute sa isporučenim nadogradnjama do 01.03.2013 

S štovanjem 



0











Klijent: 





Hitnost: 



Katja 


13180 



04.03.2013 08:20 

Upisao: 

Božo Mišeta 

Područje: 

EHPUR 


15.03.2013 


Sukladno dogovoru s sastanka koji je održan dana 27.02.2013 godine u prostorijama pisarnice, 

najavljujemo ponovni import rješavatelja s pridruženim organizacijskim jedinicama, a u svrhu pripreme 

navedenog importa. 

Import rješavatelja predviđen je sredinom ožujka, nakon dostave podataka od Ureda za upravljanje 

ljudskim resursima. 



0









Poštovani, 

Molimo odgovore na slijedeća pitanja: 

1. Slijedi novi import samo rješavatelja (org. jedinice ostaju iste)? 

2. Importirati će samo novi rješavatelji ili svi? 

3. Ukoliko će se importirati svi rješavatelji: 

a) postojeći će se deaktivirati i izvršava se ˝insert˝? 

b) nad postojećima se vrši ˝update˝? 

Lp, 



0









Poštovani, 

Prošli tjedan poslan je upit na temu importa podataka u aplikativno rješenje eHPUR koji je predviđen za sredinu 

ožujka 2013. godine. Do sada nismo dobili povratne informacije. 

Predviđena je od strane HP- a dostava isključivo rješavatelja 5 radnih dana ranije od dana isporuke istih na 

testni server, time možemo zaključiti da ukoliko sve potrebne podatke dostavite sutra 12.03.2013. godine import 

rješavatelja će biti izvršen 19.03.2013. godine. 

Molimo povratne informacije kako bismo pristupili procjeni zahtjeva te osigurali sve potrebe resurse na vrijeme. 

Zahvaljujemo. 

Lp, 

DA 

- 

NE 



0









Poštovani! 

Zahtjevi13180 zatvaramo uz Vašu suglasnost. Rješava se dalje kroz novi zahtjev HP broj 13275 



0











Klijent: 





RM1--> RM2 

Hitnost: 

Vrlo hitno 


kučuk 




01.03.2013 14:21 

Upisao: 

Dajana Lekić 

Područje: 

LROBD 


01.03.2013 


01.03.2013 

1074 artikla u dokumentu RM1 tj više od 999 ne može se prebaciti u vezni dokument RM2 

-- BUG 

41041-R13-01285 RM2 nema stavki sa rednim brojem većim od 999 , stavu rb 1000 iz povezanog 

dokumenta preslokao u 0 

41042-R13-00578 RM1 

Trebalo bi SVE stavke iz 41042-R13-00578 RM1 prebaciti u dokument 41041-R13-01285 RM2 i ispraviti 

program 

Zvao Kučuk : 01 / 2351 864 , 095 8313 795 



0









Poštovani, 

Molimo pošaljite službeni broj zahtjeva za rješavanje slučaja opisanog u KZ-u . 

Potrebno omogućiti kopiranje više od 999 stavaka iz RM1 u RM2 . 

Sad postoji ograničenje na 999 


Dokument RM2 41041-R13-01285 su dodane stavke koje nisu postojale na samom dokumenta a bile su na 

dokumentu 41042-R13-00578 te je omogučen za rad kroz program do 2000 stavaka . 

potrebno je preuzeti laus libove rob0,rob1,rob2,rob3 i rob4 koji će biti dostupni na internetu 08.03.2013. 


Poštovana, 

dana 01.03. upučen je zahtjev da se dodjeli HP broj. 

Nije još dostavljen. 

S štovanjem 

Poštovani, 

Da li ste za ovo dobili od nas zahtjev? Vidim da nema originalnog broja. 


Renata Basrek 



0











Klijent: 





Hitnost: 

Vrlo hitno 




13171 



01.03.2013 10:31 

Upisao: 

Boško Tokić 

Područje: 

EPNAB 


28.02.2013 


Potrebno je prema priloženoj datoteci izvršiti import podataka Plana nabave za 2013 u aplikaciju 

ePlanNabave. 

Kako se prema internim aktima HP d.d. radi o podacima koji su označeni poslovnom tajnom potrebno 

je odrediti osobu koja će izvršiti import i koja će u direktom kontaktu sa Uredom za javnu nabavu dobiti 

ovlaštenja za pristup poslanim podacima. 



0









Poštovani, 

Iako je Višnja poslala ovaj zahtjev 27.2.2013. na support i uz zahtjev .rar prilog (oko 85 KB velik ) uopće nismo 

dobili taj mail . 

Uzrok istražujemo kod nas . 

Zahtjev smo danas dobili bez .rar priloga. 

Smatramo da je .rar prilog nepotrebno salti . Potrebno i dovoljno samtramo postupiti po HP požurnici : 

U što kraćem roku dostaviti : 

procijenu sati 

rok isporuke 

ime osobe koja će odraditi import podataka u ePlanNabave 


Poštovani, 

Vezano za slučaj : 

Iako je Višnja poslala ovaj zahtjev 27.2.2013. na support i uz zahtjev .rar prilog (oko 85 KB velik ) uopće nismo 

dobili taj mail . 

Istražili smo i otkrili uzrok : 

U originalnom mailu je postojao PASSWORD PROTECTED RAR... 

Našem MailScanneru je to jako 'sumnjivo' kad ne može 'zavirit' unutra . 

Sigurnosne postavke ne možemo mijenjati radi sigurnosti. 

Molimo priloge koji su PASSWORD PROTECTED ne šaljite na support@laus.hr . 

Preporuka: datoteke s Vašim podacima uvijek kad je to moguće ostaviti na nekom od Vaših servera . 

Dovoljno je napisati gdje se datoteka nalazi , pa kad se odobri pristup da to osoba koja radi s datotekom može 

naći i koristiti . 



0









Poštovani, 

Procijena za rješavanje ovog zahtjeva je 20 sati. 

U privitku je excel tablica koju bi trebalo popuniti u HP s podacima koji će se importirati. Žuto označena polja su 

obavezna. 

Import će raditi kolega Vjeran Livajić. Prvo planiramo importirati na test. 

Rok isporuke nismo u mogućnosti dostaviti jer ovisi o brzini/načinu popune tablice iz priloga. 

Napomena : 

ako se podaci koje trebamo za import već naloze u dooteci na serveru sv-1ot-lauswtest.posta.int u direktoriju 

C:\. 

molimo odgovor na pitanja o preuzimanju datoteke : 

-- Trebamo li nazvati Ured za javnu nabavu ili će oni zvati nas tj. kolegu Vjerana Livaića ? 

--- Ako mi trebamo zavti , molimo kontakt osobu i telefon te vrijeme u koje teba zvati 

-- Tko treba reći kako se zove datoteka ? 

-- ima li kolega Vjeran Livaić pristup na serveru sv-1ot-lauswtest.posta.int u direktoriju C:\. ? 

Status: čekamo upute za postupanje 


Pokusali smo se spojiti na server (sv-1ot-lauswtest.posta.int ) radi preuzimanja podataka za plan nabave za 

2013., no nas user nema pravo spojiti se remote desktop-om. 


Poštovani, 

Preuzeli smo datoteku ZO_41656_4_803_HP zahtjev 13171. 


Poštovana, 

Plan nabave za 2013. nalazi se na testnom sustavu. 

Tablica s planom nabave koju ste nam dostavili ne sadrži iste podatke kao aplikacija. Pri tome mislim na 

generičke podatke kao što su vrsta troška, vrsta nabave, kategorija plana i CPV oznaka. 

Na testnom klijentu ne postoje svi identični matični podaci za klasu, planirani početak postupka, organizacijsku 

jedincu i tehničkog nositelja. 

Podatak o planiranom početku postupka je također unesen mimo definiranog pravila u aplikaciji. 

Provjerite podatke na testnom klijentu i matične podatke koji se nalaze u planu nabave, odnosno postoje li svi 

potrebni matični podaci na produkcijskom klijentu. 

Ukoliko želite da mi to učinimo ujutro će nam trebati pristup produkciji kako bismo mogli povući navedene 

matične podatke s produkcije radi analize. 

Javite nam rezultate vaše analize podataka na testnom klijentu, te želite li da mi umjesto vas utvrdimo hoće li se 

podaci moći unijeti na produkciju. Odgovor nam svakako pošaljite što prije kako bismo mogli postupiti u skladu s 

vašim zahtjevom. 

Podaci koje ste nam dostavili u planu nabave ne bi se mogli niti ručno unijeti na produkcijsku okolinu zbog 

odstupanja od sadržaja generičkih šifrarnika. 


Lea Gagulić 



0









Poštovani, 

Importiran je Plan nabave za 2013. godinu i dignut je na testni server. 

Lp, 


Poštovani, 

Utvrđeno : 8.3.2013 , 14:00 : 

Za ovaj zahtjev povećavamo procjenu za 10 sati, tako da je ukupna procjena 30 sati. 

Preuzeli smo novu tablicu za import, ali u istoj nedostaje 6 kolona u odnosu na prvobitnu tablicu.Nedostaju 

kolone: 

Registarska oznaka 

Porez 

Vrijednosni prag 

Broj postupaka 

Opis/Napomena 

Referentna vrijednost 

Također je jedan redak (predmet nabave) manje nego u prvobitnoj tablici pa ne znamo da li je to greška. 

Kontaktirana Višnja telefonski (dajan) radi upita za daljnje postupanje : raditi ili ne import. Uputila nas je na g 

Marića . 

Konzultiran Odjel za planiranje nabave, g. Stjepana Marić 4981 146. 

Dogovoreno : Dostavit će se nova datoteka za import iza vikenda . 

Status : čekamo upute vezano za preuzimanje nove datoteke za import 

čekamo prihvaćanje mnove procjene : 30 sati 



Poštovani, 

Preuzeli smo novu tablicu za import plana nabave za 2013. 

Molili bi pristup na produkciju za Vjerana Livajića radi importa. 


Poštovani, 

Plan nabave za 2013. je importiran i nalazi se na produkciji. 


Lp, 

Ovaj mail je poslan i jučer, ponavljam danas! 



0











Klijent: 





Hitnost: 

Vrlo hitno 




13178 



28.02.2013 15:27 

Upisao: 

Boško Tokić 

Područje: 

LWINFAU 


04.03.2013 


01.03.2013 

I dalje se kod ugovora sa kupcem javlja poruka. Traženo je da se makne sa svih ekrana. 

(Prilog) 


Poštovani, 

Sa ekrana je maknuta kontrola za nositelja salda konta. 


Instalacija: Novi WIN FAUS lib će biti dostupan u ponedjeljak 04.03.2013. 

Molimo povratne in formacije/suglasnost za zatvaranje zahtjeva - Riješen 


Poštovani, 





0











Klijent: 





ERV 

Hitnost: 





13177 



28.02.2013 13:38 

Upisao: 

Boško Tokić 

Područje: 

LKEVP 


15.03.2013 


01.06.2013 

Radnu 40199 na 31.01.2013 omogućen je upis druge prisutnosti za isti datum rada sa oznakom D – 

dvokratno. 

Potrebno je ugraditi kontrolu kojom ako prva upisana prisutnost nema oznaku D za dvokratni rad, program 

ne dozvoljava mogućnost upisa druge prisutnosti sa oznakom D za dvokratni rad. 

(Prilog) 


Poštovani, 

za realizaciju ovog izvještaja u Panther verziji potrebno je 40 radnih sati. Rok isporuke 01/07/2013. 



Poštovani, 

ispričavamo se, navedena procjena odnosila se na zahtjev 13161. 

Procjena zahtjeva 13177 je 4 sata, a krajnji rok isporuke 01/06/2013. 



Poštovani, 

ugrađena je dodatna kontrola za dvokratan rad. 

Molimo da nam potvrdite postoji li kod vas ograničenje za dvokratan rad ako je prethodni dan radnik radio noćnu 

smjenu tj. odlazak od prethodnog dana završava na dan nove evidencije - dvokratnog rada. 

Imate li po planovima rada mogućnost za takvu kombinaciju? Po sadašnjim kontrolama se takav rad može 

evidentirati. 

Preuzmite kevp lib koji je dostupan od 17/05/2013. 



0











Klijent: 





Hitnost: 

Vrlo hitno 




13176 



28.02.2013 13:28 

Upisao: 

Boško Tokić 

Područje: 

LKROP 


06.03.2013 


Radniku 32029 Rato Miškić neispravan je IP obrazac za 2012 (prilog). 

Radnik ima raskid 17.03.2010 (radni odnos je 'R') i naknadno su mu isplaćene sudske presude u 2012. 

godini. Na IP obrascu za 2012 pod Identifikatorom 3 radniku nije iskazan porez iako je isti obračunat i 

uplaćen. To se može vidjeti na sljedećim obračunima 2010-12 65 i 2009-12 55 (isplata 23.04.2012.). 

Molim da se to ispravi i da podaci budu iskazani u skladu s navedenim obračunima. 


IP obrazac sa objekta lpkarhp_fk IP OBRAZAC - HP i IP XML datoteka sa objekta dpornhp_fk IP DISKETA- 

HP koji se listaju za 

indikator 3 su ispravljeni u dijelu čitanja poreza i prireza za radnike sa radnim odnosom R (koji jse nalazi u 

parametru POVPR). 

Uzimaju se u obzir i obračuni čiji opis počinje sa IP3 bez obzira imaju li radnici taj radni odnos. 

Korekcija je napravljena na obrascima za godine >= 2009. 

Preuzmite: krop lib od 08.03.2013 



0











Klijent: 





BO 

Hitnost: 

Vrlo hitno 




13175 

Riješen 


28.02.2013 11:24 

Upisao: 

Boško Tokić 

Područje: 

LKEVP 


06.03.2013 


19.04.2013 

Kroz primvu_jke NAKNADE ZA BOLOVANJA - DODATNI PODACI kod ažuriranja limita naknada 

bolovanja preko F2 potrebno je u tablici prim_v_uzr osim podatka '18 mj.-50% ' ažurirati podatke: 

-datum 

-vrijeme 

-korisnik 

-terminal 


Poštovani, 

prilikom izmjene evidencije primanje - uzrok ugrađeno ažuriranje traženih podataka (datum, vrijeme, korisnik, 

terminal). 

kevp lib je dostupan na internetu 20/04/2013. 




0











Klijent: 





ruckat.jas 

Hitnost: 

Vrlo hitno 




13174 



27.02.2013 15:47 

Upisao: 

Boško Tokić 

Područje: 

LWINFAU 


04.03.2013 


Imamo slučaj kada je PU pogrešno kucao rabat, mi bi trebali stornirati taj račun i izdati novi. Međutim rabat 

iako iskaže na računu u stavci ne odbija ga od iznosa za uplatu. Poslali smo naš neispravan račun i jedan 

sa fakturiranja koji je ispravan. Potrebna ispravka programa . 



0











Klijent: 





Hitnost: 

Vrlo hitno 




13173 



27.02.2013 15:38 

Upisao: 

Boško Tokić 

Područje: 

LBASE 


04.03.2013 


Molim na pregledu protpi_fm dodati polje „Pregled po fiskalnom broju za izlazne račune“. 

(vidi prilog) 



0









Poštovani, 

Molimo potvrdu prijedloga rješenja / dopunu /komentar / vašu specifikaciju 

poziciju na protpi_fm Pregledi na koju treba staviti novi Pregled po fiskalnom broju za izlazne račune 

Prijedlog rješenja : 

Stupci pregleda : 

Broj dokumenta God. Red.br. Pos.pr. PM NP VD. Datum dok. Komitent Iznos S 

Stupci * : God. Red.br. Pos.pr. PM NP kao kod : fisk_jm PREGLED POVIJESTI SLANJA 

RAČUNA NA FISKALIZACIJU 

Ostali stupci kao na prot_fm , F5 Pregled otvara protpi_fm , izbor --> FINANCIJSKI DOKUMENTI 

Filteri /uvjeti : 

Stupci * : može se zadati filter iznad stupca i rade svi po principu = zadano tj. nema po principu like % 

Ostali stupci : filtirranje kao na prot_fm , F5 Pregled otvara protpi_fm , izbor --> FINANCIJSKI DOKUMENTI 

Mora se zadati : 

orgj+vprotokol+godina ili Komitent ili Red.br 

Ne može se zadati : 

vprotokol za kojeg je vprotokol.uliz različito od I (neizlazni dokument) 

Redoslijed : 

po protokol.godina DESC , protokol.orgj , protokol.vprotokol , protokol.bprotokol DESC ( čine Broj dokumenta) 

ili po Red.br ( porezni broj) 

Naziv pregleda: 

Poslani naziv : Pregled po fiskalnom broju za izlazne račune je predug. 

Predlažemo naziv : Pregled IRA po fiskalnom broju 


Napravljen je novi ekran protf_fm PREGLED DOKUMENATA PO FISKALNOM BROJU kao nova opcija pregleda 

dokumenata sa ekrana protpi_fm. 

Pregled ima sljedeće stupce na kojim je napravljena i filter opcija pretraživanja: 

1. Broj dokumenta = orgj+vrsta protokola+godina evidencije dokumenta+redni broj dokumneta 

2. Godina = godina fiskalizacije 

3. Fiskalni broj = redni broj na razini godine i poslovnog prostora + poslovni prostor + prodajno mjesto 

4. Način plaćanja 

5. Vrsta dokumenta 

6. Datum dokumenta 

7. Komitent = vrsta + šifra analitike 

8. Iznos 

9. Status dokumenta 

Novi LAUS BASE liba preuzeti u petak 8.3.2013. 


Poštovani, 





0











Klijent: 





kamob_ff, kamsve_ff 

Hitnost: 





13172 



27.02.2013 15:29 

Upisao: 

Boško Tokić 

Područje: 

LFINK 


15.03.2013 


Na izlazne fakture obračuna kamata (KIZ) potrebno je na ispisima kod navedenih objekata umetnuti u gornji 

desni ugao, iznad datuma obračun, mjesto izdavanja – VARAŽDIN i datum, te vrijeme izdavanja. U 

zaglavlje staviti Način plaćanja kao kod ostalih izlaznih faktura. Potrebno je kada se ti računi likvidiraju 2 u 3 

da se zapisuju u prot_fisk sa načinom plaćanja iz upute T transakcijski račun. 



0









Za rješavanje zahtjeva predlažemo : 

a) organizirati sastanak vezano za dokumente KIZ - kamate kupcima 

b) poslati primjer KIZ u kojem je više računa koji su knjiženi na 1 šifru partnera (NSC) a evidentirani na više 

šifri . 

Razlog : 

a) na sastanku želimo dogovoriti /usaglasiti budući način obrade KIZ 

b) na primjeru 1 obračuna želimo pojasniti prijedlog rješenja . 

Obrade za KIZ za koje treba dogovoriti novi / potvrditi pšostojeći način : 

- obračuna kamata 

- evidencija dokumenta KIZ 

- statusiranje , posebno opcije sa i bez mogućnosti ponovnog obračuna za status>=3 

- automatska fiskalizacija 

- ispis 

- knjiženje 

Molim pošaljite 

a) termin . 

b) primjer 

Status : čekamo HP 

NAPOMENA : ako smatrate nepotrebnim održavanje sastanka ,molimo pošaljiite primjer obračuna kamata 


Poštovani, 

Danas smo zaprimili obavijest : 

Sektor kontrolinga suglasan je s dogovorenim na sastanku i promjenom protokola iz 0 u F. 

Mirna Mendaš 

Molimo konačnu potvrdu /suglasnost za prelazak KIZ (zatezne kamate ) iz protokola 0 u protokol F kako bismo 

vam poslali upute za provođenje ove promjene . 



0









Poštovani, 

Zahtjev zatvaramo uz vašu suglasnost 

Sve dorade u obračunu kamata voditi će se kroz otvoreni zahtjev HP broj 13068. 

Napomena : Za prelazak evidentiranja i knjiženja KIZ u protokolu F potrebno je : 

a) podesiti parametar VPZOK : umjesto 0 upisati F 

Parametar VPZOK čita se kod prijeve pa se treba odjaviti i ponovo prijaviti da bi radio sa novom vrijednošću 

b) podesiti protup_ff UPUTE ZA EVIDENTIRANJE DOKUMENATA 

tj dodati uputu za KIZ na protokol F kao što sad postoji za prootkol 0 

Postaviti vrstu analitike * (sve analitike) a ne P-partner jer se KIZ radi za vrstu analitike A - ostale analitike 

Ne brisati postojeće upute jer se stari KIZ u protokkolu 0 i dalje trebaju moći vidjeti, pregledavati , statusirati.... 

c) podesiti upute za knjiženje KIZ vdokkon_ff VEZA KONTO-DOKUMENT tako da se zada vrsta protokola * 

umjesto 0 i vrsta analitike * ili ? 

kako bi se knjižili KIZ u protokolu 0 (stari) i u protokolu F (novi) a na vrstama naliteke P i A a ne samo P 

Sve gore navedene promjene preporučujemo provesti na test okruženju, pustiti obračun KIZ sa vrstom analitike 

P , A. Proknjižiti . 

Molimo za daljnje rješavanje KIZ pozvati se na zahtjev HP broj 13068 jer ovaj zatvaramo 



0











Klijent: 





Hitnost: 

Vrlo hitno 




13170 



27.02.2013 11:14 

Upisao: 

Boško Tokić 

Područje: 

LWINFAU 


27.02.2013 


Molimo da nam zahtjev što hitnije riješiti danas, jer sutra ide novi winfaus na produkciju. Potrebno provjeriti 

da se kod kataloške vuče svuda izabrani način plaćanja (ispis, porezna, pregled i slično), jer uz gotovinu 

može biti i kartica. 



Poštovani, 

Napravljena je izmjena na objektu kataloške prodaje. Kod izbora 1 – Kataloška dozvoljeno je da se način 

plaćanja proizvoljno upisuje. 


Instalacija: Novi WIN FAUS je već na internetu. 



Poštovani, 

Zahtjev zatavaramo uz vašu suglasnost - Riješen 



0











Klijent: 






Vrlo hitno 


Katja Kraljev 


13169 



27.02.2013 10:22 

Upisao: 

Boško Tokić 

Područje: 

LROBD 


TESTNA BAZA 

Generiranjem dokumenta Povrat dobavljaču klasa 63, Povrat u depo klasa 63 i 64 iznos 0,00. Molim Vas 

da to ispravite. 

(dalje u prilogu) 


Dokumenti koji su generirani prije 25/02/2013 nemaju vrijednost prikazani na prd_ul_jd PREGLED 

DOKUMENATA. 



0











Klijent: 





Hitnost: 

Vrlo hitno 




13168 

Riješen 

Kroz: 

lvrec_jk VREĆICE RADNIKA IZ OBRAČUNA 

lvrea_jk VREĆICE IZ ARHIVA 


26.02.2013 15:49 

Upisao: 

Boško Tokić 

Područje: 

LKROP 


06.03.2013 


14.03.2013 

potrebno je za radnike koji imaju PASIVNO DEŽURSTVO u stavci OSTVARENI SATI RADA izvršiti izmjenu 

na način da se sati PRIP ne zbrajaju u navedenoj stavci jer: 

-Sati pripravnosti NE čine ostvarene sate radnika, te su i u uputama za ERV definirani kao PRIP = odrada 

( ne ulazi u fond sati) 

-U UPUTAMA ZA PRIMANJA primanje PRIP je definirano da NE KUMULIRA SATE ( ne ulazi u fond sati). 


Na vrećicama iz obračuna i arhiva iz polja Ostvareni sati rada isključeni sati PRIP (pripravnosti). 

Lib krop je na internetu. 



0











Klijent: 





prd_ul_jd 

Hitnost: 

Vrlo hitno 


Katja Kraljev 


13167 



26.02.2013 12:25 

Upisao: 

Boško Tokić 

Područje: 

LROBD 


28.02.2013 


TESTNA BAZA 

1.Kada sam pustila generiranje dokumenta PC za datum 02.01.2013. godine vrti ažuriranje s porukom 

ažuriranje hp0 sa protokolom za PU 10450 orgj 31064 , brzinom da mogu pročitati svaki ured koji ažurira, 

prije je puno brže vrtio. 

Generiranje dokumenta PC trajalo je 45 minuta, za jedan datum. 

Nakon generiranja na pregledu za neke dokumenate u koloni iznos vrijednost 0,00. 

(dalje u prilogu) 


Prilikom generiranje laus dokumenta iz prometa PU nije ništa izmjenjeno što bi utjecalo na brzinu generiranja 

dokumenata . 

Postoji mogučnost čitanja istih tablica te je predviđeno vrijeme generiranja dokumenta iza radnog vremena. 



0











Klijent: 





SI u upotrebi 

Hitnost: 



Glorija markovac 


13166 



26.02.2013 11:01 

Upisao: 

Boško Tokić 

Područje: 

LROBD 


15.03.2013 


U sitnom inventaru u upotrebi kod modula : sidok_jd Pregled si po dokumentima - ispis u excelu, omogućiti 

zbrajanje stupaca količine i vrijednosti - urediti točku i zarez. 


Na excel ispisu na objekt sidok_jd Pregled SI po dokumentima odnosna na stupcima količna i vrijednost 

zamjenjeni su točka i zarez. 

Preuzmite laus libove: rob0, rob1, rob2, rob3 i rob4, koji će na internetu biti 01.03.2013. 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja Kraljev 


13165 


U stavkama dokumenta RPM ne puni se polje MPC1 – 

primjer dokumenta RPM 35358-R13-03070 : 

(vidi prilog uz KZ) 


25.02.2013 14:54 

Upisao: 

Boško Tokić 

Područje: 

LROBD 


27.02.2013 




0









Točka 1. 

Što se tiče brzine generiranja dokumenta nivelacije iz PU nije ništa ispravljano da bi utjecalo na brzinu. 

Dokumenti nivelacije iz PU-a odnosno laus dokumenti RC8 imaju neki vrijednost 0 zbog toga što su u mips-u 

također sa iznosom 0 . 

P.S. Možda ne trebamo prenositi u laus takve dokumente sa iznosom 0 ali mislim da nam ne utječu za knjiženje 

odnosno kod pripreme dokumenata nećemo ih uzimati u obzir. 

Točka 2. 

Prema uputama odnosno vezi mips -> laus vdok nije moguće da se generira RD4 Povrat u depo nego se 

generirao dokument RD5 Povratu drugi PU 

jer prema uputi analitika ima dodatni podatak SSD i popunjeno je polje koli_rnad . 

Točka 3. 

Ako je vrsta mips dokumenta PR nije moguće da se za tu vrstu dokumenta generira povrat iz poštanskog ureda 

nego prema uputi veza mips->laus vdok generirat ce se primka. 


Samo odgovor. 


Napravljene dorade na integracijskom servisu. 

Sada se automatski čitaju i cijene RPM dokumentima koji dolaze iz MIPS-a. U slučaju da artikal nema važeću 

cijenu, tada se prenosi sa cijenom 0. 

Potrebno za instalaciju i testiranje: Samo odgovor korisniku. 



0











Klijent: 





Hitnost: 





13164 

U rješavanju 


25.02.2013 13:36 

Upisao: 

Boško Tokić 

Područje: 

LSTAN 


15.03.2013 


10.07.2013 

Potrebno napraviti dvije excel liste (dvije tipke) i kod Ispisa oformiti dva excel ispisa Plan otplate i Stvarno 

stanje duga. ... 

Zahtjev u prilogu. 




0









Poštovani, 

Procjena angažmana : 12 sati 

Rok isporuke : 10.5.2013. 

za napraviti 2 excel liste iz zahtjeva . 

Molimo odgovre na pitanja kako bi uspjeli zahtjev riješiti u roku . 

1. PLAN OTPLATE 

Za izabrani ugovor na ekranu u excelu u zaglavlju dati podatke o tom ugovoru : 

Stan, Kupac, Ugovor, Ukupna obročna otplata, Iznos rate i slično, a u redcima ispisivati : 

Rata Datum uplatnice Iznos (KN) Iznos (EUR) Datum plaćanja Iznos plaćeno (KN) 

- Planiramo u zaglavlju prikazati sve podatke iz zaglavlja ugovora . 

Pitanja : 

P1. Poda rata se treba prikazati redni broj rate ? 

P2. Datum uplatnice uvijek prikazivati prvi dan u mjesecu ? 

P3. Iznos kn i EUR je ugovreni s tim da fiksno mogu biti euri (uglavnom) a mogu i kune . Nefiksni iznos e 

preračunava po tečaju na datum ispisa (sistemski) jer se za buduće rate ne može predvidjeti tečaj ? 

P4. Što prikazati pod datum plaćanja u planu otplate ? 

P5. Što prikazati u Iznos plaćeno u planu otplate ? 

2. STVARNO STANJE DUGA 

Za izabrani ugovor također formirati zaglavlje kao u prvom slučaju, a onda dati podatke i pravo stanje sa dva 

konta ( 082100 i 126701). 

Znači potrebno je gledati bilancu za tu analitiku po oba konta i dati stanje po obje valute s time da na 126701 

nema eura, već bi se rata trebala uzeti iz ugovora. 

- Planiramo u zaglavlju prikazati sve podatke iz zaglavlja ugovora . 

- Planiramo u zaglavlju prikazati saldo bilance na oba konta u kunama i valuti . 

- Planiramo prikazati sve formirane uplatnice u zadanom periodu sa podacima : 

Rata Datum uplatnice Iznos (KN) Iznos (EUR) Datum plaćanja Iznos plaćeno (KN) 

Ako je rata/uplatnica fromirana a nije plaćena , onda će datum plaćanja biti prazan a iznos plaćeno=0 . 

Nećemo radit provjere točnosti ali ćemo oba konta uzeti u obzir : formirana uplatnica umanjuje saldo na kontu 

082100 te povećava saldo na 126701. 

Uplata umanjuje saldo na 126701 . Kako vrijeme prolazi tako na 082100 ostaje sve manji saldo (ostatak duga) a 

raste saldo na 126701 (dospjelo za platiti) . Ako se uredno otplaćuje stan onda se i saldo na 126701 smanjuje. 

Stan je otplaćen kad je saldo na oba konta =0 . 

Euri i kune će se uzimati iz uplatnica ,a datum i iznos plaćeno sa ovih konta tj. do 2012-10 sa konta 082100 , a 

od 2012-11 nadalje sa konta 126701. 

Molimo potvrdu planiranog za točku 2. 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja Kraljev 


13163 



25.02.2013 11:43 

Upisao: 

Boško Tokić 

Područje: 

EHPUR 


27.02.2013 


Kod T38 Uređivanje transakcije djelatnika, na pregledu se ne vide aktivni djelatnici na novim 

organizacijskim jedinicama? 

Npr. Štefanija Prandić-Pigac treba biti na orgj HP-02/2 Odjel kadrovske operative. 

... vidi prilog. 


Poštovani, 

Pretraga i prikaz rješavatelja u ovom slučaju Štefanija Prandić-Pigac ne prikazuje aktivnog djelatnika jer 

dostavljeni podaci (sheet radnik_orgj) sadrže razmake (space) između imena i prezimena. Ukoliko recimo 

upišete samo ˝Štefanija˝, prikazati će Vam se sve po toj pretrazi, ako upišete ˝Štefanija Prand˝, prikazati će Vam 

se samo neaktivna jer ona nije sadržavala razmake. 

Ukoliko želite da se uklone razmaci između zapisa molimo da pošaljete novi zahtjev ili ako Vam odgovara 

možemo ga vezati za ovaj uz vrstu održavanja – adaptivno. 

Izmjene se neće moći izvršiti danas 05.03.2013. već u naknadnoj iteraciji. 



Poštovani, 




0











Klijent: 





Hitnost: 

Vrlo hitno 




Poštovani, 

Hitan zahtjev u prilogu. 

13162 



25.02.2013 11:28 

Upisao: 

Boško Tokić 

Područje: 

LFINK 



28.02.2013 

Prilog: 

Molim na objektu aknj_ul_jf AUTOMATSKO KNJIŽENJE PDV-A 

dodati stopu 5% kod automatskog knjiženja PDV-a. 



Poštovani, 

Na objektu aknj_ul_jf omogućen je unos stope PDV-a od 5%. 


preuzmite novi LAUS FINK lib u utorak ujutro 26.02.2013. 



Poštovani, 





0











Klijent: 






Vrlo hitno 




Grupe Internet trgovine: 

12640-dopuna 



25.02.2013 11:21 

Upisao: 

Boško Tokić 

Područje: 

LTRAN 


08.03.2013 

Kod Pregleda staviti filter na aktivnost koji bi po defoultu bio D. Omogućiti na pregledu Sort grupa po 

abecedi, pa po nadređenosti – defoult nadređenost 

Ispis po trebno da prati pregled sa ekrana i da idu nadređene pa unutar njih grupe 

Šifru grupe i nadređene grupe staviti na 20 znakova – proširiti u prijenosu 

Evidencija atributa: 

U pregled po defultu staviti Aktivnost D. 


Glorija navela 12660,a odnosi se na 12640 - mijenjam 



0









Poštovani, 

Dopuna zahtjeva 12640 vodi se pod novim KZ 41533 . 

Grupe Internet trgovine: 

Kod Pregleda staviti filter na aktivnost koji bi po defoultu bio D. Omogućiti na pregledu Sort grupa po abecedi, pa 

po nadređenosti – defoult nadređenost 

Ispis po trebno da prati pregled sa ekrana i da idu nadređene pa unutar njih grupe 

Šifru grupe i nadređene grupe staviti na 20 znakova – proširiti u prijenosu 

Evidencija atributa: 

U pregled po defultu staviti Aktivnost D. 

NAPOMENA : poslano kao dopuna 12660 ,a odnosi se na 12640 


Poštovani, 

Prema dopuni zahtjeva poslanoj 25.2.2013 (Glorija) napravljeno je : 

Na ekranu evidencije grupa internet trgovine nadodano je filter polje aktivnost i izmjenjen je izgled ispisa. 

Polja grupe i nadređene grupe internet trgovine su proširena na 20 zakova. Izmjena je napravljena i kod 

evidencije grupa (WIN područje) i kod prijenosa artikala u web (Panter Tran područje). 


Instalacija: Novi WIN FAUS i LAUS TRAN lib su već na internetu. JAviti korisniku da preuzmu ta dva liba i izvedu 

sql-ove: 

--WEB 

ALTER TABLE web_artikal ADD ( 

ponuda char(20) before koli_s ); 

ALTER TABLE web_artikal MODIFY ( 

web_grupa char(20) not null, 

web_grupa1 char(20)); 

--LAUS 

ALTER TABLE web_grupa_art ADD ( 

web_grupa1 char(20) before artikal, 

ponuda char(20) before aktivnost ); 

ALTER TABLE web_grupa_art MODIFY ( 

web_grupa char(20) not null); 

ALTER TABLE pweb_grupa_art ADD ( 


ponuda char(20) before akcija ); 

ALTER TABLE pweb_grupa_art MODIFY ( 


ALTER TABLE web_grupa MODIFY ( 


nad_web_grupa char(20) not null); 

create trigger "l1faus".ins_webgrupa_art insert on "l1faus".web_grupa_art 




0







for each row -završen, Isporučen - Korisnik potvrdio ispravnost 

( 

insert into "l1faus".pweb_grupa_art (web_grupa,web_grupa1,artikal, 

trziste,tezina,ponuda,akcija,datum,prebacen) 

values (new.web_grupa,new.web_grupa1,new.artikal, 

new.trziste,new.tezina,new.ponuda ,'U',CURRENT,'N') 

); 

DROP PROCEDURE "l1faus".azur_webgrupa_art; 

CREATE PROCEDURE "l1faus".azur_webgrupa_art 

(pre_grupa CHAR(20),post_grupa char(20), 

pre_grupa1 CHAR(20),post_grupa1 char(20), 

pre_artikal CHAR(13),post_artikal char(13), 

pre_trziste CHAR(1),post_trziste char(1), 

pre_tezina CHAR(1),post_tezina char(1), 

pre_ponuda CHAR(20),post_ponuda char(20), 

pre_akt char(1) ,post_akt char(1)) 


THEN 

insert into "l1faus".pweb_grupa_art (web_grupa,web_grupa1,artikal,trziste, 

tezina,ponuda,akcija,datum,prebacen) 

values (post_grupa,post_grupa1,post_artikal,post_trziste,post_tezina, 

post_ponuda,'A',CURRENT,'N'); 

END IF 


THEN 




post_ponuda,'D',CURRENT,'N'); 

END IF 

IF pre_akt==post_akt 

THEN 




post_ponuda,'I',CURRENT,'N'); 

END IF 


create trigger "l1faus".azur_webgrupa_art update on "l1faus".web_grupa_art 


for each row 

( 

execute procedure "l1faus".azur_webgrupa_art(pre.web_grupa ,post.web_grupa, 

pre.web_grupa1 ,post.web_grupa1 , 

pre.artikal ,post.artikal , 

pre.trziste ,post.trziste, 

pre.tezina ,post.tezina, 

pre.ponuda ,post.ponuda, 

pre.aktivnost,post.aktivnost) 

); 




0







Na ekranu -završen, evidencije Isporučen grupa internet - Korisnik trgovine potvrdio nadodano ispravnost je filter polje aktivnost i izmjenjen je izgled ispisa. 

Polja grupe i nadređene grupe internet trgovine su proširena na 20 zakova. Izmjena je napravljena i kod 

evidencije grupa (WIN područje) i kod prijenosa artikala u web (Panter Tran područje). 

Preuzmite: novi WIN FAUS i LAUS TRAN lib koji su već na internetu. 

Izvedite sql-ove: 

--WEB 

ALTER TABLE web_artikal ADD ( 

ponuda char(20) before koli_s ); 

ALTER TABLE web_artikal MODIFY ( 


web_grupa1 char(20)); 

--LAUS 

ALTER TABLE web_grupa_art ADD ( 


ponuda char(20) before aktivnost ); 

ALTER TABLE web_grupa_art MODIFY ( 


ALTER TABLE pweb_grupa_art ADD ( 


ponuda char(20) before akcija ); 

ALTER TABLE pweb_grupa_art MODIFY ( 


ALTER TABLE web_grupa MODIFY ( 


nad_web_grupa char(20) not null); 

create trigger "l1faus".ins_webgrupa_art insert on "l1faus".web_grupa_art 


for each row 

( 

insert into "l1faus".pweb_grupa_art (web_grupa,web_grupa1,artikal, 

trziste,tezina,ponuda,akcija,datum,prebacen) 

values (new.web_grupa,new.web_grupa1,new.artikal, 

new.trziste,new.tezina,new.ponuda ,'U',CURRENT,'N') 

); 

DROP PROCEDURE "l1faus".azur_webgrupa_art; 

CREATE PROCEDURE "l1faus".azur_webgrupa_art 

(pre_grupa CHAR(20),post_grupa char(20), 

pre_grupa1 CHAR(20),post_grupa1 char(20), 

pre_artikal CHAR(13),post_artikal char(13), 

pre_trziste CHAR(1),post_trziste char(1), 

pre_tezina CHAR(1),post_tezina char(1), 

pre_ponuda CHAR(20),post_ponuda char(20), 

pre_akt char(1) ,post_akt char(1)) 


THEN 




0







-završen, Isporučen tezina,ponuda,akcija,datum,prebacen) 

- Korisnik potvrdio ispravnost 


post_ponuda,'A',CURRENT,'N'); 

END IF 


THEN 




post_ponuda,'D',CURRENT,'N'); 

END IF 

IF pre_akt==post_akt 

THEN 




post_ponuda,'I',CURRENT,'N'); 

END IF 


create trigger "l1faus".azur_webgrupa_art update on "l1faus".web_grupa_art 


for each row 

( 

execute procedure "l1faus".azur_webgrupa_art(pre.web_grupa ,post.web_grupa, 

pre.web_grupa1 ,post.web_grupa1 , 

pre.artikal ,post.artikal , 

pre.trziste ,post.trziste, 

pre.tezina ,post.tezina, 

pre.ponuda ,post.ponuda, 

pre.aktivnost,post.aktivnost) 

); 



0











Klijent: 





Hitnost: 





13161 



25.02.2013 10:55 

Upisao: 

Boško Tokić 

Područje: 

LKEVP 


15.03.2013 


01.07.2013 

Poštovani, Potrebno je poslati procijenu sati za poslani zahtjev 13161. 

Lijep pozdrav, Višnja Abija-Ivček, Odjel za implementaciju ERP rješenja 

Potrebno je omogućiti evidenciju radnog vremena radnika po danima na mjesečnoj bazi, po organizacijskim 

jedinicama i radnom mjestu radnika u formatu excel-mail. 

Primjer excel-mail liste je u prilogu. 



0









Poštovani, 

Molim pojašnjenje, traži li se zahtjevom mogućnostu unosa evidencije radnog vremena prema priloženoj strukturi 

tablice ili se traži samo ispis podataka u excel obliku. 


Ljubo nIkolić 


Poštovani, 

za realizaciju ovog izvještaja u Panther verziji potrebno je 40 radnih sati. Rok isporuke 01/07/2013. 



Poštovanje, 

U tijekuje izrada programske podrške za ovaj zahtjev. Zahtjev nije moguće realizrati dostunim alatima na 

platformi LAUS/Panther/Informix kakvu sada koristi HP. Stoga pripremamo realizaciju iz LAUS6 verzije aplikacije 

na način da će se ovakav izvještaj moći pokrenuti na jedan od slijedećih načina: 

- pokretanjem LAUS6 pregleda i exportom u Excel iz LAUS6 instance aplikacije koja se koristi za potrebe veze 

prema MISu 

- pokretanjem LAUS6 pregleda i exportom u Excel iz LAUS6 instance aplikacije koja se koristi za produkciju 

HPP/HPA 

- pokretanjem Reporting Services izvješća nad jednom od baza (laus6 baza za MIS ili LAUS6 baza za 

HPP/HPA) 

Očekivani završetak dorada po ovom zahtjevu je 1.7.2013. 

Očekujem da će nakon naše isporuke biti potrebno još cca dva dana da se predmetni izvještaj postavi na 

produkcijsko okruženje. 

Za LAUS CC 




0









Završena je izrada reporta i potrtebnih servisa po ovom zahtjevu. 

Report se može pokrenuti kao MS SQL Reporting Services report, nad MS SQL Server bazom podataka. Podaci 

se u bazu podataka nad kojom se radi report prenose iz LAUS baze podataka. Sukladno navedenome 

predlažemo da se za ovu namjenu koristi LAUS MIS međubaza. 

Preduvjeti: 

1. Konfiguracija reporting services 

Potrebno je na LAUS MIS među bazi iskonfigurirati MS SQL Server Reporting Services i omogućiti nam pristup 

na Report Manager za potrebe instalacije reporta i konfiguriranje Data Sourceova. 

Nakon postavljanjareporta na reprt server, podesit ćemo i servis za prijenos podataka koji će podatke iz LAUS 

baze potrebne za ova report prenositi jednom mjesečno, nakon zaključenja ERV-a za protekli mjesec. Navedenu 

dinamiku moguće je naknadno dodatno podešavati. 

Ovisno o načinu na koji želite korisnicima omogućiti korištenje reporta, potrebno je ili omogućiti http pristup na 

konfigurirani report manager ili reporting services ikonfigurirati s mogućnošću slanja mailova, kako bi korisnik koji 

se pretplati dobio mail s reportom. 

Primjer izvješća exportiranog u excel format je u privitku. 

Reportu se kao obvezni filtri zadaju 

- mjesec, godina 

- organizacijska grupa 

- jedna ili više organizacijskih jedinica 

2. Priprema uputa za vezu grupa vrsta rada 

S obzirom da su vrste rada grupirane u grupe prema zahtjevu potrebno je definirati vrste rada koje ulaze u grupe 

od 4-7. 

Veza vrsta rada-stupac se evidentira na objektu erpro_jke VEZA - VRSTA RADA / STUPAC ISPISA za listu 

ERVRS. 

Prve tri grupe nije potrebno vezati na ovaj način jer već postoje odgovarajući indikatori u samom šifarniku. 


Poštoanje, 

Očekujete li aktoivnosti po ovome zahtjevu od nas.Zahtjev je završen 1.7. Nakon toga nemamo povratnih 

informacija o pripremi nnužne infrastrukture. 


LJubo 



0











Klijent: 





Hitnost: 

Vrlo hitno 




13160 



25.02.2013 10:21 

Upisao: 

Boško Tokić 

Područje: 

LWINFAU 


25.02.2013 

Molim da mi danas do kraja dana pošaljete procjenu i rok za ovaj zahtjev. 

Lp, Ivan Poldrugač, Odjel za implementaciju ERP rješenja 


Prilog: Primjer rekapitulacije 

Molim procjenu sati i rok izvedbe za dolje navedeno : 

Potrebno je u LAUSu napraviti rekapitulaciju u CSV formatu prema priloženoj datoteci (rekapitulacije za 

STB račune za zadani period): 

U bazi moraju biti sadržani svi varijabilni podaci koji se ispisuju na računu (Neziv korisnika i adresa, svi 

datumi, br. računa, svi nazivi stavki, količine, iznosi, itd.) Ukoliko je središnja tablica sa stavkama statična tj. 

svi korisnici imaju iste stavke onda svi podaci za jednog korisnika mogu biti u jednom redu baze. Ako je 

tabela dinamična, razliciti korisnici imaju različit broj i vrstu stavki na računu onda baza mora imati više 

radova po korisniku (multiple record). U ovom drugom slučaju csv datoteka treba sadržavati više redova po 

jednom korisniku a svaki red u prvom polju mora imati oznaku o kojoj vrsti podataka se radi u tom redu. 

Npr. svaki korisnik mora imati jedan red koji počinje slovom H (header) i u njemu su podaci koji su izvan 

nekih tablica na računu (naziv i adresa, datumi, podaci za uplatnicu itd.) zatim isti taj korisnik ima jeda ili 

više redova D (details) u koje se upisuju podaci koji se prikazuju u tablici tj. nabrajaju se kao stavke na 

računu to su podaci kao naziv stavke, količina, cijena, popust itd. Za svaku stavku na računu treba biti 

jedna D linija u datoteci. Ovih linija može biti i više ako ima više tablica na računu ili ako se unutar jedne 

tablice postoji još neka pod tablica. 

Svaka nova H linija označavanovi rekort tj. korisnika tj. kuvertu. 

U prilogu je primjer jedne takve baze samo u umjesto stvarnih podataka napisani nazivi podatka koji bi se 

tu trebao nalaziti. Podatci koje ćete vi stavljati u bazu ne moraju biti ovakvi tj. oni ovise o samom izgledu 

računa koji želite dobiti. 



0









Poštovani, 

Procjena potrebnohg vremena i rokova za isporuku repota prema Vašem zahtjevu 

1. Izrada reporta u LAUS WinPanther - 12h 

2. Testiranje - 2h 

3. Priprema i isporuka liba - 0,5h 

4. Ažuriranje dokumentacije - 0h 

Ukupno 14,5h 

Mogući rok isporuke, sukladno sa sadašnjim prioritetima: utorak 5.3. do kraja dana. 




Poštovani , 

Zahtjev zatavarmo uz vašu suglasnost : Rješavat će se po novom zahtjevu 

U ovom zahtjevu je samo procjena koju smo poslali 



0











Klijent: 





Fluktuacija i NTI 

Hitnost: 

Vrlo hitno 




13159 

Riješen 


25.02.2013 09:38 

Upisao: 

Boško Tokić 

Područje: 

LCSBI 


27.02.2013 


U modulima Fluktuacija i NTI u MIS-u još uvijek nisu raspoložive tablice s podacima za 2013. godinu. 


Poštovani, 

linkovi na tražene Excel izvještaje su dodani. 



0











Klijent: 






Vrlo hitno 




13147 



25.02.2013 09:35 

Upisao: 

Boško Tokić 

Područje: 

LROBD 


Kako je u nastavku planirano u periodu od 25.02. do 01.03.2013. godine ponovo odraditi popis količina 

(inventuru) na DEPOU ZAGREB molim Vas da nam pomognete u dijelu sravnjenja eventualno 

neproknjiženih artikala kroz RC3ul_jd NIVELACIJA CIJENE NA SKLADIŠTU - TERET KRAJNJEG 

KORISNIKA za period 01.01.2012. – 31.12.2012. kao i za period 01.01.2013. do 18.02.2013., kako bi u 

trenutku pristupanja prebrojavanju imali evidencijski sređene podatke, odnosno da li možete provjeriti samo 

koji artikli nisu nivelirani u tim periodima. 

Nivelaciju prema Vašem popisu za sporne artikle odradili bi u Depou, odnosno ako se eventualno može 

„pozadinski“ kroz aplikaciju nivelirati bili bi Vam zahvalni. 



0









Za artikle 

306634,307997,307998,308486,308593,308601,309797,310992,312301,313362,314117,314330,315582,31582 

3,316882,316922,316964,317420 

je potrebno provjeriti robnu karticu odnosno potvrditi da li je potrebno raditi nivelaciju zbog toga što je možda 

treablo raditi čak 2011 i ranije. 

Upit koji je postavljen radi potrebe inventure i za koji su smo dobili gore navedene artikle je usporedba cijene na 

stanju sa trenutno važećom cijenom i da cijena na stanju nije jednaka cijeni na 31/12/2012 za one stavke kojih 

ima na stanju. 

sql ; 

select artikal,cije_skl,cije_skl cijena,cije_skl cc, 

koli_s from stanje_r 

where robskl='35358' 

into temp tt with no log ; 

update tt set cijena =( 

select cijena 

from ccjeniks 

where ind_akt in ('2','3') 

and datum_od ='25022013' or datum_do is null 

or datum_do ='') 

and kalk_el='MPC1' 

and ccjeniks.artikal=tt.artikal) 

; 

update tt set cc =( 

select cijena 

from ccjeniks 

where ind_akt in ('2','3') 

and datum_od ='31122012' or datum_do is null 

or datum_do ='') 

and kalk_el='MPC1' 

and ccjeniks.artikal=tt.artikal) 

select distinct artikal from tt 

where cije_skl !=cijena 

and koli_s!= 0 and cije_skl != cc 



0











Klijent: 






Vrlo hitno 




13158 



22.02.2013 13:57 

Upisao: 

Boško Tokić 

Područje: 

LFINK 


Na temelju dogovora sa Dajanom otvaramo zahtjev koji bi trebalo u ovoj fazi pogledati na koji način povući i 

interpretirati podatke iz Mipsa za povrate. Nakon snimanja situacije možete nam poslati koje promjene će 

se izvesti u Lausu, pa ćemo to provesti kao dopunu zahtjeva. 

U dogovoru sa Mipsom je odlučeno da se ne mijenjaju polja prijenosa, već 

da iznos u polju izndom (tablica prom_anaupu – mila baza) bude negativan, npr -100 za uputnice u 

povratu. 

Na produkciji su napunjeni podaci za 18.01.2013 na ovaj način. Jedan slog je u minusu, pa možete li 

napraviti provjeru što je potrebno da ovo knjižite na druga (bilo uplata ili isplata) konta. Konta šaljemo 

naknadno ili ćete staviti na ekran npr. Konta za povrat. 

prom_postup 

11419018.01.2013.25100017630,68100221 

prom_anaupu 

1141902 ETMODK01 11680061387 31978192,261440,03 

1141902 SBPORSBG130114RS00010 902625771 21978-100-763 

1141902 POFICHBE130114HR0010 130114HR37361137 21978724,175427,65 



0









Program za knjiženje je prilagođen na traženi način. 



Poštovani, 

vezano za upit : DOPUNA ZAHTJEVA 13158 

Međunarodne uputnice - povrati 

Kako je dospjela stavka 146 koja je upravo razlika na nalogu 13YY0003 ? 

Proknjižen je na test 18.01.2013 sa jednim storno. 

Zaključili smo slijedeće : 

stavka red=144 jest povrat : 

UPL -763 P 229502 144 

duplo po iznosu ali suprotnog predznaka je ova viška stavka ** 

IPL 1526 D 229562 146 

koje nama u prometu ,a da je ima onda bi iznos u lm_uputnice bio kao u lm_upstav za PU 51000 . 

Smatramo za višak stavku ** : 

da ne treba biti ni u prometu ni u knjiženju. 

da je bila u prometu pa da je obrisana. 

da se treba obrisati iz knjiženja 

Status : čekamo daljnje upute za postupanje : treba li ili ne mijenjati program ? 

nalogk red posta iznos oznakat slog_id tablica 

13YY0003 22 51000 7630.68 10 114190 lm_uputnice 

13YY0003 143 51000 1440.03 10 114190 lm_upstav 

13YY0003 144 51000 -763.00 10 114190 lm_upstav 

13YY0003 146 51000 5427.65 10 114190 lm_upstav 

nedostaje u prometu red=145 u lm_upstav (obrisano) .sporna stavka u nalogu ima red=146 

nalogk red posta iznos oznakat slog_id tablica 

13YY0003 149 51280 749.00 10 114193 lm_upstav 

13YY0003 148 51216 762.00 20 114192 lm_upstav 

13YY0003 147 51118 990.60 20 114191 lm_upstav 

13YY0003 146 51000 5427.65 10 114190 lm_upstav ova stavka u knj. nalogu ima red=145 a 

u prometu 146 

13YY0003 144 51000 -763.00 10 114190 lm_upstav 

13YY0003 143 51000 1440.03 10 114190 lm_upstav 

13YY0003 142 48000 344.27 20 114189 lm_upstav 

13YY0003 141 47108 1143.00 20 114188 lm_upstav 

13YY0003 140 47000 101.35 20 114187 lm_upstav 



0









Poštovani, 

Knjiženje međunarodnog prometa prilagođeno je za stavke sa negativnim iznosom (povrati) u dijelu formiranja 

stavke razlike / zaokruženja (bez partnera) 

Stavka se formira ako promet ukupni ne odgovara prometu po uputnicama . Prije prilagodbe se za slučajeve u 

kojima se javlja povrat formirala stavka zaokruženja na dupli iznos povrata jer je povrat sa iznos











Klijent: 






Vrlo hitno 


Katja Kraljev 


13157 



22.02.2013 13:46 

Upisao: 

Boško Tokić 

Područje: 

EHPUR 


1.Pojavili su se problemi nakon importa organizacijskih jedinica kod transakcije Zbirno pretraživanje, te kod 

transakcije Surješavanje spise, na koje smo naišli u radu (ostaje pitanje da li će se pojaviti još problema 

vezanih na import u ostalim transakcijama): 

ZBIRNO PRETRAŽIVANJE: 

-Kod pregleda po rješavatelju, aplikacija nudi samo spise otvorene prije importa novih organizacijskih 

jedinica (privitak – zbirno pretraživanje po rješavatelju), 

-Kod pregleda po rješavatelju + nadležnost, aplikacija nudi samo spise otvorene nakon importa 

organizacijskih jedinica i spise po kojima je rađena neka obrada nakon importa org. Jedinica, (privitak: 

rješavatelj+nadležnost) 

-U slučaju rješavtelja Štefanije Prandić Pigac (jedan rješavatelj), može se izabrati između dva imena istog 

rješavatelja Štefanije Prandić Pigac i aplikacija nudi u jednom slučaju spise otvorene prije importa org. 

Jedinica, a u drugom spise otvorene poslije importa org. Jedinica (privitak: Štefanija Prandić Pigac1 i 

Štefanija Prandić Pigac2) 

Potrebno je da nakon pretraživanja po rješavatelju, aplikacija nudi sve spise tog rješavatelja bez obzira na 

import org. Jedinica, također je potrebno da nakon pretraživanja po nadležnosti aplikacija nudi sve spise te 

organizacijske jedinice. 

SURJEŠAVANJE SPISA: 

-Kod surješavanja aplikacija nudi spise otvorene nakon importa org. Jedinica i spise po kojima je rađena 

obrada nakon importa org. Jedinica (privitak: surješavanje spisa i surješavanje spisa2) 

Potrebno je da aplikacija nudi sve spise zadužene tom rješavatelju. 

Prilozi: RJESAVATELJ+NADLEŽNOST.docx, surješavanje spisa2.docx, SURJEŠAVANJE SPISA.docx, 

štefanija prandić pigac1.docx, štefanija prandić pigac2.docx, zbirno pretaživanje po rješavatelju.docx 



0









Poštovani, 

Molimo Vas odmah pristup za kolegu Vjerana Livaića, a vezano uz zahtjev 13157 (nije moguće trenutno 

procijeniti do kojeg vremena nam pristup treba dok ne vidimo stanje stvari na produkciji). 


Poštovani, 

Za rješenje ovog zahtjeva tražili smo da se dostavi back-up produkcijske baze eHPUR . 

Molimo pošaljite informaciju gdje se isti nalazi (na kojoj lokaciji/linku) kad bude spreman za preuzimanje 

Status : čekamo back-up 



0









Poštovani, 

U iščekivanju zapisnika sa sastanka koji je održan 26.2.2013 u Jurišećvoj 13 nismo dosad proslijeđivali 

navedeno pod 1*. 

U privitku dostavljamo ( prema 1*) tablicu sa popisom org. jednica koje su neaktivne, a za koje nam nedostaje 

njihova nova org. jedinica, novi sektor i naziv pa molimo da te kolone/podatke unesete. 

Ukoliko nije dostavljena org. jedinica koja nasljeđuje staru, rezlultirati će time da nećete moći pronaći spise koji 

su bili na toj staroj nadležnosti. 

Što se tiče situacije kada se neaktivna nadležnost razdijelila u 3 nove nadležnosti , trebate dostaviti polja 

orgj,naziv,sektor od svih novih razdijeljenih nadležnosti te ih upisati u excel tablicu u odgovarajući redak stare 

nadležnosti. 

Vezano uz ograničenja, polja smiju sadržavati znakova: 

· Naziv – max 100 

· Orgj – max 50 znakova 

· Sektor – max 20 znakova 

Nadalje, polja: Ur. broj i Broj podneska sastoje se od zbroja 3 polja – oznake org. jedinice (HP-2/1) + rednog 

broja (000001) + godina (/13) te sveukupan broj znakova kod generiranja istih ne smije prelazi 30 znakova. 

Ključ po kojem se vrše sve radnje vezane uz import i sl. je Laus šifra orgj i Laus šifra radnika. 

Molimo pošaljite službeni zapsnik sa sastanka 

---------------------------na sastanku u Jurišićevoj 14-15 dana 267.02.2013 : dogovoreno : 

1* DokIT će poslati što nedostaje da bi se stare orgj povezale sa novima (naslijeđivanje nadležnosti ) 

Očekuje se do kraja ovog tjedna slanje nedostajućih veza u HP na popunu .Obavezno poslati : 

a) pojašnjenje što HP treba napisati kod popune za slučaj : 

1 staru orgj naslijeđuje n novih orgj : napr , stara orgj T-1 sad se razdijelila u 3 nove orgj/nadlažnosti : T-01, T- 

02, T-03. 

Po kojem ključu (rješavatelj ili neki drugi pojam ) se neki spisi od T-1 naslijeđuju /vežu za novu orgj T-01 ,a 

aneki drugi za novu orgj T-02 ,... 

b) ograničenja na duljine ,tip i sadržaj polja ako se u excel-u rade priprma podataka za import - Branka će 

poslat što sve treba popuniti i duljine,tip i sadržaj polja , svakako bez specijalnih znakova, napr jednostruki 

navodnik) i kontrolnih nevidljivih znakova ,... 

Kad se napravi za sve stare orgj 'nove' orgj sljednice tj upišu u bazu potrebne veze rješit će se većina problema 

opisanih zahtjevom. . 

2* HP treba odmah poslati zahtjev za novi import koji se očekuje sredinom 3. mjeseca 2013 - Čeka se odluka . 

Očekuje se import samo novih rješavatelja , orgj bez promjene 

3* Još neke situacije koje treba riješiti : 

-- tajnica ( Ivana Habuš DPO-04) ne vidi kod slanja na potpis rješavatelja kojeg bi trebala vidjeti ( Ksenija Matan- 

Jelić DPO) 

-- rješavatelji se ne vide ili se duplo vide 

-- nakon importa neko treba biti u pisarnici ( Jadranko) . Može , samo ako dođe zahtjev od HP-a (Dajana) 

-- ubuduće zahtjev za import slati barem 5 dana prije očekivanog datuma import-a 



0









Poštovani, 

Molimo Vas da se očitujete o svim zahtjevima koji su prebačeni na testni server: 12695, 12696, 12706, (odobrili 

ste za prebacivanje na produkciju: 12761, 12790). 

Naime, kako bismo Vam isporučili na testni server izmjene koje smo izvršili nakon importa org. jedinica i 

radnika/rješavatelja moramo dignuti verziju koja je jednaka onoj na produkciji, a to znači da ne sadrži izmjene 

koje čekaju Vaše odobrenje (one sa testa). 

Predlažemo dvije opcije: 

1. da u što kraćem roku (npr. danas) provjerite izmjene na testu kako bismo mogli podignuti ispravke nastale 

nakon importa 

2. da odmah dignemo verziju aplikacije koja sadrže ispravke nakon importa (ista kao na produkciji), ali bi s 

time ˝pregazili˝ verziju koja sadrži zahtjeve koje trebate odobriti 

te nakon što odobrite i provjerite ispravke nakon importa, da vratimo verziju sa zahtjevima koji čekaju 

odobrenje. 

Ukoliko odaberete opciju 1., promjene ćemo prebaciti na test kad potvrdite da je sve u redu s zahtjevima koje 

smo isporučili na test . 



Poštovani, 

U privitku slijedi osvrt/primjedbe na zapisnik dostavljen od strane Pisarnice. 

Molimo ubuduće zatražite verifikaciju istoga s naše strane kao što i mi tražimo od Vas 


Poštovani, 

Prema dogovorenom na sastanku 27.02.2013. povezivanje nadležnosti trebalo je biti izvršeno po principu jednu 

stara (neaktivna) na jednu novu (aktivnu) ,uz iznimku da se nova (aktivna) nadležnost moze granati na vise 

novih nadležnosti te bi se stara (neaktivna) povezala na sve razgranate nove(aktivne) nadležnosti. 

Međutim excel file koji smo zaprimili od strane HP- a je upravo suprotno od dogovorenog. Više starih 

nadležnosti je povezano na jednu novu nadležnost. 

Da bi se realizirala ovakva situacija potrebno je dorađivati view OJVeze u bazi podataka te mijenjati strukturu 

same tablice, eventualno dodati međutablicu , drugim riječima prepravljati već napravljeno. 

Ukoliko želite realizaciju gore opisanog, molimo dostavite novi adaptivni zahtjev. 


Poštovani, 

Nastavno na dogovor s današnjeg sastanka, ovim putem Vas obavještavamo da će se 05.03.2013. do kraja 

dana na testni server prebaciti promjene vezane uz ovaj zahtjev. 

Ukoliko iste budu potvrđene, biti će prebačene naknadno i na produkciju. 



0









Poštovani, 

Nastavno na zapisnik od 27.02.2013. i sastanka održanog 04.03.2013. na testnoj verziji na Vašem serveru kao i 

našem u T63 izvršili smo više puta akciju surješavanja ponovnom evidencijom i oznaka org. jedinice odnosno 

početak ur. broja koji se odnosi na orgj nije se promjenio već je ostao isti. 

Ur. brojevi u aplikaciji (mislimo na dio oznake orgj) su se dosada mijenjali jedino ručno kroz bazu kada je to bilo 

neophodno. 

U privitku (T63) dostavljamo primjer s našeg testa i na Vašem testu smo izvršili tu akciju na spisima i oznaka orgj 

se nije promijenila: 

D4/1-002462/07 => D4/1-000855/07 

D4/1-003101/07 => D4/1-000856/07 

D-P/3-007921/09 => D-P/3-000857/13 


Poštovani, 

Slažemo se s Vašim prijedlogom. Molimo da predloženo izvršite i javite nam gdje se backup file baze nalazi (na 

testu). 


Poštovani, 

Na test su prebačene izvršene dorade po ovome zahtjevu. 

Smatramo da su riješene sve primjedbe iz zapisnika od 27.02.2013. i ostale koje su se vezale na ovaj zahtjev. 

Na dio koji se odnosi na ur. brojeve (T63), razmake odnosno uređivanje atributa djelatnika smo se već u prošlim 

prepiskama očitovali. 

Za potrebe našeg testiranja, na testu je korisnici Ivani Habuš promijenjena lozinka u ihabus (nismo znali lozinku). 



Poštovani, 

Vezano uz surješavanje ponovnom evidencijom u P8 - T63 utvrđeno je prema Vašem dostavljenom primjeru da 

se radi o spisu koji je importiran kao takav prije početka produkcije prošle godine (isporuka je bila u listopadu 

2012.godine). 

Vidimo da se radi o akciji koja je izvršena u ˝staroj˝ aplikaciji (Datum 09.01.2012.). 

U aplikaciji generiranje urbroja prema orgj u zadnjem statusu zadužen/prosljeđen nije podržana, kako smo 

pokazali u primjerima na našem i Vašem testnom linku aplikacije. 

Ukoliko želite da isto bude podržano, molimo pošaljite novi zahtjev. 

Lp, 



0









Poštovani, 








Poštovani, 




Zahvaljujemo, 

Lp, 


Poštovani, 

Prebačene su dorade po ovom zahtjevu na produkciju. ( 8.3.2013. iza 16:00) 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja Kraljev 


13156 



22.02.2013 13:33 

Upisao: 

Boško Tokić 

Područje: 

LROBD 


22.02.2013 


22.02.2013 

Prilikom prebacivanja dokumenta RIM u status 7 javlja se ova dolje greška: (u prilogu) 


Radi se o prebacivanju dokumenta u mips_laus bazu iz koje se dalje podaci preuzimaju u MIPS sustav. 

Prebacivanje je neuspješno zato što korisnik nema dozvolu na mips_laus bazu. 



0











Klijent: 





Hitnost: 

Vrlo hitno 




13155 



22.02.2013 13:09 

Upisao: 

Boško Tokić 

Područje: 

LFINK 


28.02.2013 


04.03.2013 

Potrebno je kroz pna_kot_jf PRIJENOS PUTNIH NALOGA KOTAČ / LAUS omogućiti ispis u formatu 

excel-mail: 

1.Preko F2 Greške -> Pregled grešaka prijenosa podataka KOTAC -> LAUS 

2.Preko F3 Veze -> Pregled veza putnih naloga KOTAC -> LAUS. 



0









Poštovani, 

Procjena angažmana za rješavanje ovog zahtjeva : 6 sati 

Planirani rok isporuke : ponedjeljak 4.3.2013. 

Molimo suglasnost na pocjenu sati i rok isporuke 


Na objektu pna_kot_jf PRIJENOS PUTNIH NALOGA KOTAČ / LAUS na tipkama F2 Greške i F3 Veze 

omogućen je ispis u formatu excel-mail. 

Preuzmite LAUS FINK liba u srijedu 6.3.2013. 


Poštovani , 



Poštovani, 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja Kraljev 


13154 



22.02.2013 11:59 

Upisao: 

Boško Tokić 

Područje: 

LROBD 


22.02.2013 


22.02.2013 

1.)12.02.2013.g. je poslana zahtjevnica iz PU (broj 3), koja je stigla u depo – laus broj dokumenta 35358- 

Q13-02758. 

Navedeni dokument obrađen, te po generiranom dokumentu RIM 35358-U13-04988 artikli plasirani prema 

PU.Kako nije bio definiran prijelaz statusa iz 2 ->7 izdatnica nije prenesena u mips_laus bazu u tablicu 

zahtjev_prijenos_mips. Potrebno je ažuriranje tablice zahtjev_prijenos_mips na produkcijskoj bazi. 


Dokument upisan u zahtjev_prijenos_mips tablicu. 


Dokument 35358U1304988 upisan u mips bazu. 



0











Klijent: 






Vrlo hitno 




13153 



22.02.2013 10:48 

Upisao: 

Boško Tokić 

Područje: 

LROBD 


Na objektu knjiženje robno-materijalnih dokumenata omogućiti knjiženje materijalnih dokumenata s 

posebnom vrstom naloga 6S. Skladišta su odvojena sa oznakom da li je robno ili materijalno skladište. 

(prilog) 


Preuzmite: fink lib koji će biti na internetu 23.02.2013. 

Na objektu hp_knj_jf KNJIŽENJE ROBNO_MATERIJALNIH DOKUMENTA DEPO-A U GL. KNJIGU omogučeno 

je da za robna skladišta se knjižu prema vrsti naloga zadano parametru NALDE dok materijalna skladišta prema 

novo otvorenom NALMA . 

Potrebno je otovriti parametar sustava korz objekt pars_fm PARAMETRI SUSTAVA na sljedeći način : 

Šifra NALMA 

Tekst TIP_NALOGA_ZA_KNJI¦ENJE__-MATERIJALNO_____________ 

Sustav l1base ADMINISTRACIJA SUSTAVA 

Korisnik ________ 

Izmjena D Po kljuźu N Čitanje kod prijave N 

Default kljuź ____________________ 

Default podatak 6S________________________________________________ 

i ažurirati kroz objekt parm_fm A¦URIRANJE POJEDINIH PARAMETARA na način : 

Šifra NALMA 

Tekst TIP_NALOGA_ZA_KNJI¦ENJE__-MATERIJALNO_____________ 

Sustav l1base ADMINISTRACIJA SUSTAVA 

Korisnik ________ 

Izmjena D Po kljuźu N ¬itanje kod prijave N 

Default kljuź ____________________ 

Default podatak 6S________________________________________________ 



0











Klijent: 






Vrlo hitno 


Katja Kraljev 


13152 



22.02.2013 09:38 

Upisao: 

Boško Tokić 

Područje: 

LROBD 


1. Kada se upiše datum_do pristine tipka izmjena javlja se ova dolje greška (vidi prilog). 

Kada se otkloni ova greška molimo provjeru da li ispravno radi preslikavanje datuma_do na stavke 

dokuementa. 

Prije nego se pojavila ova greška - kod kopiranja asortimana promijenjen je datum asortimana automatski 

na zaglavlju i u stavkama, to je ok - kad se stavi datum do kada vrijedi asortiman u statusu 1 to se ne 

preslika na stavke. 


Ispravljena je IZMJENA na zaglavlju asortimana asort_ja. 

Libovi su već prebačeni. 



0











Klijent: 






Vrlo hitno 


Katja Kraljev 


13151 



22.02.2013 09:19 

Upisao: 

Boško Tokić 

Područje: 

EHPUR 


Otvaranje novih spisa sada radi, međutim problem je u spisima koji su jučer otvoreni (podatci u privitku) i 

koji su u statusu prazan spis. Kod tih spisa nije moguće unijeti ulazni podnesak u postojeći spis (greška u 

nastavku) kao smo jučer dogovorili. Radi se o 10 spisa. Molim ŽURNO otklanjanje greške kako bi i te spise 

mogli pustiti u obradu. 


Poštovani, 

Zahtjev je povezan sa HP broj 13148. Maloprije je to riješeno i poslan odgovor . 

Zahtjev HP broj 13151 je od jutros 07:55 kada to još nije bilo riješeno. 

Mogu se unijeti podnesci u prazne spise od jučer. 

Smatramo i ovaj zahtjev riješenim. 



Poštovani! 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13150 



21.02.2013 11:31 

Upisao: 

Božo Mišeta 

Područje: 

EHPUR 


25.02.2013 


Molim te da se na spisu broj DPO-8-003678/13 promjeni organizacijska oznaka DPO-003678/13 te se isti 

zaduži na Kseniju Matan Jelić. 

Na navedenom broju spisa potrebno je promijeniti i predmet spisa „Arhiva EVOTV“ u predmet Nabava STB 

uređaja. 

Također želim istaknuti kako je navedene promjene potrebno žurno obavit budući je spis potreban tokom 

današnjeg dana. 



0









Poštovani, 

Na zahtjev HP-a odnosno Pisarnice zatraženo je slijedeće i zahtjev kao takav je implementiran od samih 

početaka: 

ü Spis je moguće uređivati u statusima: Evidentiran i Signiran 

ü Spisi se mogu stornirati u svim statusima (osim: Arhiviran, Izlučeno arhivsko gradivo, Surješen i Zadužen 

(Surješen)), jedini uvjet jest da spis sadrži samo jedan podnesak. Nije moguće stornirati spis koji ima dva ili više 

podnesaka. 

ü Stornirati spis može jedino Administrator pisarnice odnosno gosp. Jadranko Holetić 

Spis koji spominjete je u statusu Zadužen što isključuje prvu mogućnost, a jedino se može stornirati (sadrži 

jedan podnesak) što pretpostavljam ne želite. 

Svrha Vaša i naša je bila da se isključi manipulacija podacima koje spis sadrži od samog otvaranja do arhiviranja 

istog. 

Kada se izvrši izmjena biti ćete obaviješteni (vidimo da nam je otvoren pristup – Vjeran Livaić će izvršavati 

korekciju spisa). 

Molimo još informaciju - U polju Nadležnost podatak ostaje isti? 

Naime spominjete promjenu ur. broja, ali ne i organizacijske jedinice. 

Lp, 


Poštovani, 

Na spisu su promijenjeni podaci na produkcijskoj bazi . 

Molimo povratne informacije/ suglasnost za zatvaranje zahtjeva- Riješen 


Poštovani! 

zatvorili smo ovaj zahtjev uz Vašu suglasnost - Riješeno 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13149 



21.02.2013 09:06 

Upisao: 

Božo Mišeta 

Područje: 

LROBD 


25.02.2013 


Prilikom ispisa više dokumenata kroz objekat „ mid_jd MASOVAN ISPIS DOKUMENATA (HP)“ na istima 

ne prikazuje artikle sa pripadajućom količinom (vidi privitak).- ISPIS MATERIJALNIH DOKUMENATA 

(XXXzga7MHP_rd) 

Molim da se problem što prije riješi. 


Poštovani, 

Masovni ispis dokumenta, predviđen je za ispis proknjiženih dokumenata (status 7), te je u vašem primjeru 

javljao poruku da ne postoji cijena i prikazivao na ispisu zaglavlje dokumenta bez stavaka koje nemaju cijenu. 

Na objektu mid_jd MASOVNI ISPIS DOKUMENATA dodan je ispis XXXzga1HP pa izborom ispisa ISPIS 

MATERIJALNIH DOKUMENATA za dokumente koji nisu u statusu 7 odnosno koji nisu materijalno proknjiženi 

tako da se čitaju stavke sa skladišne kartice , a ne sa materijalne. 


S štovanjem 


Poštovani, 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13148 



21.02.2013 08:31 

Upisao: 

Božo Mišeta 

Područje: 

EHPUR 


25.02.2013 


Nakon jučerašnje implementacije novim podataka stvorio se problem kod Urudžbiranja podneska u novi 

spis, tj. kreiranja novog spisa. 

Nakon unosa prvih podataka, naziv spisa i naziv pošiljatelja, te nakon akcije „Spremi“ javlja se greška čiji 

print Scrn dostavljam u nastavku. 

Kod zbirnog pretraživanja utvrđeno je da je kreiran prazan spis DP-02/1-004476/13. 

Molim ŽURNO otklanjanje problema. 



0









Poštovani, 

Molimo za kolegu Vjerana Livaića pristup kako bismo krenuli na rješavanje zahtjeva 13148. 



Da li se greška javila isključivo na ovom jednom predmetu ili na više njih? 


Poštovani, 

Vaš zahtjev je riješen. 

Prilikom dostave tablice orgj_radnik_19022013, na prvom listu u koloni ˝Oznaka˝ nalazili su se skriveni kontrolni 

znakovi te prilikom generiranja ur.broja odnosno broja podneska javljala se greška jer je za iste maksimalan broj 

znakova 30. 

Sve promjene izvršene su direktno na produkciji. 

Ukoliko nema primjedbi, predlažemo zatvaranje zahtjeva. 

NAPOMENA : 

specijalni skriveni kontrolni znakovi nikome ne trebaju - smatramo greškom HP-a što ih je poslao 

nismo radili posebno ispitivanje ima li tih znakova jer su neočekivani - smatramo našom greškom 

Prijedlog : 

1 .Zahtjev tretirati kao PERFEKTIVNO a ne KOREKTIVNO održavanje jer je greška obostrana 

2. Dogovoriti se o potrebnom formatu / standardu (ISO ili neki drugi) u kojem trebaju biti datoteke koje se 

učitavaju u bazu 

3. Dogovoriti se o postupcima koje treba provesti ako datoteka za učitavanje ne odgovara dogovorenom : 

a) ne učitava se nego se vraća u HP kao neispravna te se čeka ispravna datoteka 

b) radimo ispravak prije učiotavanja i to spada u adaptivno ili perfektivnio ili korektivno održavanje ili ima 

održavanje kao zahtjev za učitavanje 


Poštovani, 

Molimo povrtane informacije : može li se ovaj zahtjev zatvoriti a primjedbe/probleme u radu aplikacije eHPUR 

rješavati kroz zahtjev HP 13157 ? 

Ukoliko nema primjedbi, predlažemo zatvaranje zahtjeva. 


Poštovani, 

Zahtjev zatvaramo uz vašu suglasnost - Riješen. 



0









Poštovani, 

Smatramo da se zahtjev ne može zatvoriti sa zaključnim korektivnim održavanjem kada su greške nastale zbog 

skrivenih kontrolnih znakova u xls.- u. 

Može se eventualno zatvoriti kao perfektivno, a ne korektivno . 

Prilikom dostave tablice orgj_radnik_19022013, na prvom listu u koloni ˝Oznaka˝ nalazili su se skriveni kontrolni 

znakovi te prilikom generiranja ur.broja odnosno broja podneska javljala se greška jer je za iste maksimalan broj 

znakova 30. 

Sve promjene izvršene su direktno na produkciji. 

Ukoliko nema primjedbi, potvrdite zatvaranje zahtjeva pod Perfektivno održavanje. 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Glorija 


13146 



21.02.2013 08:24 

Upisao: 

Božo Mišeta 

Područje: 

LBASE 


22.02.2013 


30.06.2013 

Kod evidentiranja međunarodnih faktura u LAUS(priljevi i plaćanja), prilikom potvrđenja unosa na F1 javlja 

se ikona „prekontrolirajte iznos na računu“(kopija u privitku), ne možemo nikako završiti unošenje fakture 

tj. dobiti broj Laus evidencije.Ovo nam se nije ranije događalo. Problem je što se Ukupni iznos ne slaže sa 

izračunom osnovica + pdv tj. razlika prilikom preračuna. 



0









Poštovani, 

Kod deviznih izlaznih računa pretpostavlja se da je neoporezivo sve tj izvoz a kod kunskih računa se ne popuni 

plavo polje u Neoporezivo-razrada . 

Riješeno tako da princip kod deviznih računa bude isti kao kod nedeviznih : 

Ne popunjava se ništa pa niti plavo polje na prot11_fm osim ukupan iznos 

Nakon unosa deviza , preračunati iznos kuna se upiše samo u ukupni iznos računa. 

------------------------------------------------------------------------------------------------------------------------------------------- 

Korisnik sam mora napraviti razradu na neoporezivo ili oporezivo kao kod bilo kojeg drugog dokumenta kojeg 

evidentira neautomatski preko prot_fm 

------------------------------------------------------------------------------------------------------------------------------------------- 

NAPOMENA: 

Sve bi trebalo biti u Neoporezivo - ostalo (stupac 11 knjige IRA) kao što su evidentirani ostali MOP u protoklu I. 

Potrebno za instalaciju /testiranje : 

Preuzeti BASE lib koji je na internetu od 22.02.2013. nadalje 

Molimo povrtane informacije/suglasnost za zatvaranje zahtjeva - Riješen 



0









Poštovani , 

Kontrolom PDV-a za protokol I utvrđene su nepravilnosti za : 

protokol I - međunarodni obračuni na orgj 10018 u statusu 1 imaju porez : 

protokol stopa osnovica porez odbiti 

10018I1301405 25.00 344.09 86.02 0.00 

10018I1301406 25.00 751.37 187.84 0.00 

10018I1301407 25.00 48410.55 12102.64 0.00 

10018I1301408 25.00 98.31 24.58 0.00 

10018I1301409 25.00 1834.41 458.60 0.00 

10018I1301410 25.00 4508.21 1127.05 0.00 

10018I1301411 25.00 266.84 66.71 0.00 

10018I1301412 25.00 42.14 10.53 0.00 

---- javiti korisnicima da isprave i stave u neoporezivo (stupac 11) 

pdv_Iprot.sql u /home/admlaus 

Riješit će se uskoro kroz ovaj zahtjev na način : 

Na ekranu prot11_fm pri izlasku iz Neoporezivo - razrada : napuniti neoporezivi dio za protokol 9 i I u potrebnu 

knjigu IRA : 

vprotokol puni se 

9 prot_neop.iznos8= idin , ostala iznos* polja u prot_neop =0 

I prot_nop.iznos11=idin , ostala iznos* polja u prot_neop =0 

U oba slučaja vrijedi : 

protokol.vrij_p = protokol.idin (sve je neoporezivo) 

idinp=0 (porez=0 tj. nema razrade poreza po stopama tj. ne puni se prot_pdv ) 

Kontrola : ako se radi o protokolu 9 ili I program ne treba dozvoliti unos ili izmjenu ako korisnik upiše bilo 

osnovicu bilo porez tj. ako nije zadovoljeno ukupno= neoporezivo . Javiti poruku : Ukupan iznos je neoporezivupišite 

razradu neoporezivog. 

NAPOMENA : 

za ostale devizne protokole 2 i 6 neće se raditi automatika jer je ovakva je situacija sa neoporezivima: 

Protokol 9 - uvijek je sve neoporezivo i to ide u stupac 8 knjige ira (izvoz) – on ide iz wina i sjeda automatski, ali 

može se 9 vezati sa stupac 8 

Protokol 6 – nije vezan za pdv obrazac ni knige ura i ira a i maska za unos dokumenata nema nikakve razrade 

Protokol 2 - dokumenti koji se ovdje evidentiraju mogu biti oporezivi i neoporezivi tako da ne može biti nikakvog 

automatizma. 

Protokol I -U protokolu I nalaze se isključivo neoporezivi dokumenti (kunski i devizni) koji se nalaze u stupcu 11 

knjize IRA. 



0









Poštovani, 


10.06.2013.g. 

Molimo uvrstite ga u neriješene jer postoji dio koji nije riješen te se ne može zatvoriti bez vaše suglasnosti . 



knjigu IRA : 










NAPOMENA : 






automatizma. 


knjize IRA. 



0









Poštovani, 

Zbog novog Pravilnika o PDV-u ( zahtjev HP broj 13472 ) pogrešno je napraviti kako je pisano u zadnjoj 

obradi . 

Molimo povratne informacije/suglasnost za zatvaranje ovog zahtjeva - Riješen . 

-------Zadnja obrada 12.6.2013. : 


10.06.2013.g. 

Molimo uvrstite ga u neriješene jer postoji dio koji nije riješen te se ne može zatvoriti bez vaše suglasnosti . 



knjigu IRA : 










NAPOMENA : 






automatizma. 


knjize IRA. 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Višnja 


13145 



20.02.2013 11:07 

Upisao: 

Božo Mišeta 

Područje: 

EPNAB 


25.02.2013 


Kroz ePN potrebno je ispraviti slijedeće originalne brojeve: 

1.Za spis HP-10-021567/12 stoji „# 1 HP-10-021567/12“, a treba biti „HP-10-021567/12“ 

2.Za spis HP-10/2-021624/12 stoji „HP- 10/2-021624/12“ (razma je suvišan), a treba biti „HP-10/2- 

021624/12“. 



0









Poštovani, 

Molio bi pristup na produkciju za Vjeran Livaić dana 21.02.2013. od 16 do 17 sati radi ispravka po zahtjevu 

13145. 

Pozdrav 


Poštovani, 

Ispravljeni su brojevi ugovora na produkciji. 



Poštovani, 








Poštovani, 









Obavještavamo vas da po vašem nalogu zatvaramo zahtjev. 

Poštovani, 

Možete zatvoriti zahtjev. 


----------------------------------------------------- 




0











Klijent: 



Zakonska promjena 


Hitnost: 

Vrlo hitno 


Višnja 


13144 

U rješavanju 


20.02.2013 10:43 

Upisao: 

Božo Mišeta 

Područje: 

LKROP 


28.02.2013 


Objavljen je Pravilnik o izmjenama i dopunama pravilnika o porezu na dohodak prema kojemu će 

poslodavci umjesto dosadašnjih nekoliko obrazaca predavati jedinstveni obrazac za izvješćivanje o 

isplaćenim primicima, obračunanim i uplaćenim doprinosima za obvezna osiguranja, porezu na dohodak i 

prirezu poreza na dohodak - Obrazac JOPPD. 

Potrebno je formirati navedeni obrazac. 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Glorija 


13143 



19.02.2013 15:12 

Upisao: 

Božo Mišeta 

Područje: 

LFINK 


28.02.2013 





2.Uplate (transakcija 20) s oznakom poziv na broj odobrenja 

00 760111 – oznaka poštanskog ureda – DDMMGG knjižiti na konto 122300, nivo poštanskog ureda 

Divizija Mreža, u opis knjižiti poziv na broj odobrenja 

3.Isplate (transakcija 10) s oznakom poziv na broj zaduženja 

00 120709 – oznaka poštanskog ureda – DDMMGG, knjižiti na konto 

120709, nivo 00000, u opis knjižiti poziv na broj zaduženja 



0









Omogućeno je automatsko knjiženje izvoda za slučajeve iz zahtjeva preko : 

iz_knj_ff KNJIŽENJE IZVODA ŽIRA 

Preduvjet : zadati upute preko izvod_up_jf UPUTE ZA KNJIŽENJE IZVODA ŽIRA 

Obavezno upisati kako je navedeno za svaki od slučajeva : 

RB OT Konto Broj zaduženja Broj odobrenja 

1. 20 259905 01-618754 

2. 20 122300 00760111 

3. 10 120709 00120709 

Za sva 3 slučaja upisati : 

Opis ________________________________________ 

Pozicija ______ 

Aktivnost D 

Protokol N 

Ind. opis P 

Dodatni podatak ___ ______________________________ 

RB- redni broj točke zahtjeva tj. oznaka na koji slučaj se uputa odnosi 

OT - oznaka transkcije 10-isplata, 20-uplata 

Ostali elementi u uputi ( nivo , strana,analitika i predznak knjiženja) prema potrebi posla 

Preuzeti novi LAUS FINK liba u srijedu 20.3.2013. 


Poštovani, 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Glorija 


13048 



19.02.2013 14:31 

Upisao: 

Božo Mišeta 

Područje: 

LBASE 


25.01.2013 

Molimo da se omogući izmjena datuma PDV-a za dokumente u statusu 3. 

Ali samo da se izmjena omogući za dokumente protokola 9 i vrste IRI. 




0









Poštovani, 

Datum pdv-a može se i sad promijeniti za slučaj da je dokument u statusu 3 na način : 

KORLD korisnik vrati dokument u status 2 

napravi se kontrolirana izmjena podataka ( kontrolira se sve što je potrebno , uključivo i minimalni datum PDVa 

) 

dokument se vrati u staus 3 nakon promjena 

Ovo je moguće za : 

- neizlazne dokumente bez izuzetka (vprotokol.uliz != I) 

- za sve izlazne dokumente koji se ne fiskaliziraju ( nemaju uputu za fiskalizaciju upisanu u fisk_up) 

- za sve izlazne dokumente koji kod fiskalizacije ne dobiju ZKI i JIR tj ne šalju se u FINA-u (fisk_up.ind=N) 

Dakle, 

Za kombinaciju protokol=9 , vdok=IRI nekad se može a nekad ne može raditi promjena statusa 3-->2 obzirom 

da u fisk_up stoji : 

vdok vprotokol orgj nacpla ind 

IRI 9 01400 O D 

IRI 9 01400 C D 

IRI 9 01400 G D 

IRI 9 01400 K D 

IRI 9 01400 T N 

Dakle, zahtjev je : 

--------------------------------------------dozvoliti 

samo promjenu datuma PDV-a za dokument IRI bez promjene statusa neovisno o upisanom u 

fisk_up.ind . 

-------------------------------------------- 

Zahtjev se grubo kosi sa postavljenim pravilima obrade dokumenta. MOže napraviti jedino hardcode kontrolama 

jer je iznimka od pravila . 

Molimo odgovore na dolje postavljena pitanja kako rješavanje zahtjeva ne bi bilo na način koji niste 

željeli /očekivali . 

PITANJA : 

P1. Idalje se kontrolira MDPDV tj. ne dozvoljav da novi datum PDV-a bude manji od minimalnog ? 

P2. Ostali podaci ostaju nepromijenjeni bez obzira što korisnik upiše/izmijeni na ekranu ? 

P3. Ako se dozvoljava promjena i ostalih podataka , koji podaci se mogu još mijenjati te u kakvoj vezi su 

moguće izmjene sa fisk_up.ind ? 

NAPOMENA : ne bi treblo mijenjati podatke koji se šalju u FINA-u na fiskalizaciju . 

P4. Treba li ipak izmijeniti sistemske podatke : uradio,datum,vrijeme,terminal tj. zapamtiti u protokol koji korisnik 

je zadnji radio po dokumentu ? 

P5. Dozvolu za mijenjanje datuma PDV-a na IRI treba imati 

Korisnik KORLD samo ? ili 

Korisnik koji ima dozvolu na prot_fm EVIDENTIRANJE DOKUMENATA ? ili 

Korisnik koji ima dozvolu na prot_lkv_jm LIKVIDIRANJE DOKUMENATA ? 

Mišljenja smo da zahtjevu ne bi trebalo udovoljiti , osim ako se radi o jako velikom broju pogrešaka vezano za 

datum pdv-a koje treba naknadno ispravljati. 

Ako se radi o pojedinačnim slučajevima /iznimkama pravila se uvijek mogu zaobići intervencijom na bazu . 

Postoji realna opća opasnost : ako se omogući programom ova znimka da će ih vremenom biti sve više i da će 

postati pravilo . 

MOžda je bolje , onda razmisliti o globalnom rješenju za promjenu datuma PDV-a a ne samo za IRI 

Postavljena pitanja vrijede i za globalno riješenje . 



0









Poštovani, 

Na ekranu prot1_fm dozvoljena je izmjena datuma PDV-a za dokumente vrste protokola 9, vrste dokumenta IRI 

koji se nalaze u statusu 3. 

Izmjenu može radii samo korisnik koji se nalazi u parametru KORLD. 

Zadržana je kontrola na minimalni datum PDVa koji se nalazi u parametrau MDPDV. 

Dakle, dozvoljena je samo promjenu datuma PDV-a za dokument IRI bez promjene statusa neovisno o 

upisanom u fisk_up.ind . 


LAUS BASE lib je većna internetu 



Poštovani, 

Provjeren je rad programa na našim bazama - uredno se ponaša tj. ne dozvoljava izmjnu u statusu 3 nijednog 

podatka osim datuma pdv-a a i to ako novi datum prolazi kontrolu da je veći ili jednak minimalnom (MDPDV) . 

Molimo pošaljite radi daljnje analize : 

o kojem se računu radi - LAUS broj računa 

na kojoj bazi se dogodilo (test, produkcija ) i kad 

NAPOMENA: 

računi u statusu manjem od 3 se mogu mijenjati , a u većem ne mogu osim za korisnika KORLD kombinacija 

protokol 9 i vdok IRI - dozvoljena promjena datuma pdv-a . Programski kod uopće ne sadrži izmjenu bilo kojeg 

drugog polja osim protokol.datumuliz 


Poštovani, 

Zahtjev zatvaram uz vašu suglasnost - Riješen 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Glorija 


13142 



19.02.2013 13:45 

Upisao: 

Božo Mišeta 

Područje: 

WINTRAN 


20.02.2013 

Onemogućen je unos artikla u Laus narudžbenice- printscreen u nastavku 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Ivan 


13141 



19.02.2013 13:39 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


25.02.2013 


U ugovorima s kupcima u kojima je način plaćanja određen oznakom Z-zonski cjenik treba uvesti kontrolu 

prilikom generiranja faktura, pod uvjetom da se kod šifri usluga kod kojih su upisane zone I,II i III, 

primjenjuje obračun po zonama. Kod usluga na kojima u ugovoru nije upisana zona, zonski cjenik se ne 

primjenjuje, bez obzira što podatak s zonom dolazi iz MIPS aplikacije. 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13139 



19.02.2013 13:25 

Upisao: 

Božo Mišeta 

Područje: 

LROBD 


22.02.2013 


Kod kopiranja asortimana u novi asortiman ekran nudi novi asortiman pod novim brojem, ali datum na 

početnom ekranu kao i datum sa stavkama ostaje od starog asortimana. Prošli tjedan je novi asortiman 

davao datum od sutra, a stavke su bile sa starim datumom. 

Potrebno je da asortiman nudi novi datum od sutra i datum do prazno da ga mi ukucamo, a kad ga 

ukucamo, isti se mora odmah preslikati u stavke. 


Prilikom kopiranja asortimana F3(KOPIRAJ) na objektu asort_ja datum od novog nastalog asortimana i 

njegovih stavaka jednak sutrašnjem datumu a datum do ostaje prazan i potrebno je upistai željeni datum sa F2 

(IZMJENA). 

Izmjena je u robd libovima od 20.02.2013 


Poštovani, 




0











Klijent: 





fak* Zone 

Hitnost: 



ivan 66 26 313 


13141 



19.02.2013 13:18 

Upisao: 

Dajana Lekić 

Područje: 

LWINFAU 


25.02.2013 


Evo ponovno zahtjeva za doradom konrola god generiranja faktura po zonskom cjeniku. 





- ranije poslan pod HP brojem 13114 , KZ 41203 kojeg sam zatvorila 


Napravljena je dodatna kontrola god generiranja faktura po zonskom cjeniku. 

Da bi usluga iz naloga ušla u fakturu s podatkom o zoni mora biti zadovoljeni: 

- usluga mora biti u stavkama ugovora definirana da se za nju primjenjuje zonski rabat 

- za uslugu mora biti definiran podatak i u evidenciji raspona rabata (tablica lm_rab_ug) 

Ako ovo uvijeti nisu zadovoljeni tada se za uslugu neće u fakturi upisivati podatak o zoni bez obzira ako usluga u 

nalogu ima upisanu zonu. 

Instalacija: novi WIN FAUS lib će biti dostupan u ponedjeljak (18.03.2013) ujutro. 


Poštovani, 





0











Klijent: 





Hitnost: 

Vrlo hitno 


Ivan 


13138 



19.02.2013 07:41 

Upisao: 

Božo Mišeta 

Područje: 

LFINK 


19.02.2013 


Kod slanje liste na email sa objekta knirN_jf KNJIGA IZLAZNIH RAČUNA (PDV) - 25% javlja se greška 

sa sllike: 


Ispravljena je greška kod ispisa na F6 kod knjige izlaznih računa. 

Preuzimite novi LAUS FINK liba u srijedu 20.2.2013. 


Poštovani, 

ispravljena je greška kod ispisa na F6 kod knjige izlaznih računa. 

Preuzimite novi LAUS FINK liba u srijedu 20.2.2013. 





Mlimo suglasnost za zatvarnje zahtjeva - Riješen 


Poštovani, 




0











Klijent: 






Vrlo hitno 


Glorija 


13137 



19.02.2013 07:37 

Upisao: 

Božo Mišeta 

Područje: 

LFINK 


28.02.2013 

Potrebno omogućiti ispis opomena za vrstu analitike A., sada javlja grešku - vidi prilog 



0









Poštovani, 

PREDLAŽEMO : 

Na opo_hp_ff napraviti da se mora iza labele Pos. partner: zadati : 

a) P sa šifrom partnera ako se traži za 1 šifru partnera pregled/ispis 

ili 

b) * ako se traži za sve partnere pregled/ispis 

Dakle, 

1. opo_hp_ff Opomene za Male/Srednje/Velike kupce ( pregled i ispis opomena ) se oslanja na poslovne 

partnere : 

- Hijerarhija 

- tip kupca su navezani na part tablicu : 

- ugovor s kupcem je na šifri posl.partnera (zahtjev HP 13179 ) 

pa se na njemu mogu dobiti pregled/ispis opomena samo za poslovne partnere . 

2. Na opo_hp_ff ne treba omogućavati pregled i ispis kamata za ostale vrste analitika - samo poslovni partneri 

3. Za ostale analitike (vanalitika=A) omogućiti na opo_ff tj ukloniti grešku koju ste poslali . 

Molimo vaš stav u vezi predloženog 


Na objekt opo_hp_ff ostavljena je samo mogućnost lista opomena za Partnere. Ako se ne zada šifra partnera 

pregled ide za sve partnere. 

Na objektu opo_ff dodana je mogućnost listanja opomena za ostale analitike (bez partnera). Za konkretnu šifru 

zadaja se vrsta i šifra, a za sve ostale analitike zadaje se vrsta * zvjezdica. Način listanja opomena na ovom 

objektu je zadržan kao i do sada (u datoteku ili izravno na printer ovisno o parametru ISKAM). 



Poštovani, 





0











Klijent: 





Hitnost: 

Vrlo hitno 


Glorija 


13136 

Riješen 


18.02.2013 15:27 

Upisao: 

Božo Mišeta 

Područje: 

LCSBI 


18.02.2013 


U izvještaju RDG ne mogu se zadati upute za novootvorena konta. 

Sustav javlja grešku i traži da se zada uputa za konto 419130 za 2012. godinu koji je neaktivan od 

01.01.2011. godine. 



0









Poštovani, 

molimo dozvolu za spajanje na produkcijsku bazu (međubaza za HP MIS i LAUS baza) kako bi ispitali poruku 

koju ste prijavili kao grešku. 

hvala 


Poštovani, 

kao što je u prvoj obradi navedeno, baze na koje se trebamo spojiti su produkcijska međubaza za HP MIS i 

LAUS, 

osobe koje će se spajati: Damir Ivan Konjevod na HP MIS, možda na LAUS, Željan Šilje, možda na HP MIS i 

LAUS 

Srdačno 


Poštovani, 

obzirom da nismo dobili odobrenje za spajanje od 19.2. možemo li smatrati da je zahtjev zatvoren? 

hvala 


Poštovani, 

što se tiče što bi se radilo na serveru nije moguće precizno odgovoriti osim "ustanovljavati uzrok prijavljenog 

problema". 

što se tiče tko bi se spajao i gdje, ponavljamo 3. obradu zahtjeva: 

Poštovani, 

kao što je u prvoj obradi navedeno, baze na koje se trebamo spojiti su produkcijska međubaza za HP MIS i 

LAUS, 

osobe koje će se spajati: Damir Ivan Konjevod na HP MIS, možda na LAUS, Željan Šilje, možda na HP MIS i 

LAUS 

Srdačno 



0









Poštovani, 

ANALIZA 

ustanovljeno je da je razlog pojavljivanja rečene poruke neispravnost podataka ili drukčije tumačenje podataka 

kontnog plana u LAUS-u: 

- mehanizam za prebacivanje podataka kontnog plana iz LAUS u međubazu, kako je postavljen od početka, 

funkcionira na način da za kontni plan tekuće godine uzima >>SVA









Dana su vam admin prava za Damira Konjevodu na serveru sv-1ot-lausmis. Pošto taj server nije u domeni, za 

spajanje na njega koriste se lokalni korisnici. Svi korisnici i lozinke (administrator i admargosy) postavljeni su od 

strane tvrtke Laus i nisu mijenjani. Upute uklonite ako je rješenje problema. 

Moja pretpostavka je da znate lozinke za ova dva korisnika. Ako ima problema možete kontaktirati sistema 

administratora Marina Junušića. 

Lp 



Poštovani, 

problematične upute su uklonjene. Za upute na bilanci nisam mogao točno provjeriti jer nisam imao konkretni 

konto kojeg trebam gledati. Provjereno je tako što kroz ekran za zadavanje uputa na retku 039 bilance za 2012 i 

2013 se pritisnulo "prihvait" na postojeće upute i validacija je odrađena bez greške. 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Glorija 


Protokol 5 HP ukupno 1.1.-31.1.2013. 

13135 



18.02.2013 15:23 

Upisao: 

Božo Mišeta 

Područje: 

LBASE 


18.02.2013 


Na protokolu 5 zbroj po svim stupcima (7-18) = 32.059.595,00 , trebao bi biti jednak stupcu 6 

=32.929.515,64 

Razlika je 869.920,64 više u stupcu 6 nego zbroj stupaca (7-18) 

Primjer LB 31013-513-00002 

Na računu je ukupan iznos =4.114,70 

Neoporezivo (kolona 10) =1.740,10 

Osnovica 25% =1.687,17 

Pdv 25% =421,83 

Zbrojeno stavke: neoporezivo , osnovica i pdv =3.849,10 što je za 265,60 manje nego je ukupan iznos 

računa 

Potrebno hitno ispraviti račune protokola 5, koji nisu ušli u tablicu prot_pdv sa stopom 5, te u protokolu polje 

porez je također neispravno 



0









Poštovani, 

U periodu 01.01.2013 nadalje utvrđeno je da se promet preuzet iz PU dobro upisao ui prezne evidencije : 

osnovica stopdv oo porez pdv 

342416.68 10.00 342416.68 34210.78 34210.78 

12 712932.40 25.00 12 712932.40 3 178408.94 3 178408.94 

196.40 0.00 1114.40 0.00 0.00 

osim promet stope 5 kojeg nije uopće bilo u razradi PDV-a po stopama pa sam upisala u prot_pdv : 

osnovica porez - svi računi 01.01.2013 u protokolu 5 nevezano za status : 

1 269 550.91 63469.06 

Greška je kod punjenja prot_pdv tablice iz gotovinaskog prometa PU (lm_usl_stav) koja se puni kod prijenosa 

mips_laus . 

Program se ispravlja : 

indikator tip_slog (count(*)) 

PRO 5 4 

PRO 7 42418 

Nakon upisa prometa po stopi 5 u razradu poreza po stopama Prijava PDV 2013-01 :Ukupni iznosi knjige 

izdanih (izlaznih) računa : 

Iznos s porezom (stupac 6) 32,929,515.64 

suma po stupcima : 32,920,511.46 

razlika 9 515.64 - 511.46= 9004.18 u neoporezivo 

Fiskalizirani : nisu mijenjani jer nisu imali stopu 5 a i da jesu ne mogu se mijenjati. 

protokol br_fisk pospr prod_mj 

3100551300001 1 31005 1 

3100551300002 2 31005 1 

3100551300003 3 31005 1 

3535851300001 2 35358 1 

3535851300002 3 35358 1 

3535851300003 4 35358 1 

3535851300004 5 35358 1 


Poštovani , 

Pronađeno i insertirano u prot_pdv razrada po stopi 5 u protokolu 5 (promet PU iz MIPS-a ) za slučaj kad su u 

računu samo usluge/artikli po stopi 5 : 

uk neoporezivo porez osnovica 

32929515.64 16517281.64 3122757.45 13289476.55 zaglavlje 

16517281.64 3122328.66 13280901.16 razrade neoporezivog i pdv-a 

razlike 0 428.79 8575.39 manje u razradi po stopi 5 

stopdv rr pdv 

5.00 8575.39 428.79-- ubačeno sad - protokol 5, stopa 5 

Molimo provjeru za knjigu IRA , sad bi trebalo biti u redu 

Planiramo isporuku ispravka programa za preuzimanje prometa iz PU danas iza 16:00 (LAUS TRAN lib) o čemu 

ćete dobiti obavjest 



0









Poštovani, 

U vremenu od 17-19 sati 20393 dokumenata kontrolirano nevezano za status . 

>> -- protokol 5 i 0 sa stopom 5 %, od 01.02.2013 do 28.02.2013. 

stopdv tiptar tarfbr osn pdv 

5.00 1 P05 691.59 34.61 

5.00 691.59 34.61 11 

ukupno 726.20 - stopa 5 ubacila . datum=19.02.2013 , datumuliz= 18/02/2013 ubačena stopa 5 za : 

protokol stopdv osn. pdv 

3107451301217 5.00 128.57 6.43 

3108451301562 5.00 141.90 7.10 

3116551302487 5.00 89.90 4.50 

3165551301194 5.00 18.95 0.95 

3190751300403 5.00 46.67 2.33 

3166951300334 5.00 18.95 0.95 

3114851300244 5.00 18.95 0.95 

3165751300106 5.00 57.14 2.86 

3196651300388 5.00 18.95 0.95 

3118151300364 5.00 113.71 5.69 

3165551301193 5.00 37.90 1.90 

program ispravljen ranije : prijenos MIPS-->LAUS stopa 5 razrada 

Za slučajeve dolje navedene molimo odgovr na pitanja : 

>> -- Razradu neoporezivog nemaju : 

protokol vdok idin vrij_p uradio status 

4627701300248 ODO -3249.79 -3249.79 SVESLUNJ 3 

P1 :Kako je ovaj nastao ? 

>> --- kataloška - vrsta računa 4 - nemaju razradu neoporezivog : 

analitika protokol vdok idin vrij_p datum s 

31045 3104551301225 GOT -11.28 -11.28 11/03/2013 2 

31278 3127851300059 GOT -65.64 -65.64 04/03/2013 2 

31468 3146851302675 GOT -280.00 -280.00 04/03/2013 2 

31476 3147651301159 GOT -57.00 -57.00 04/03/2013 2 

31529 3152951300980 GOT -80.00 -80.00 05/03/2013 2 

31548 3154851300137 GOT -80.00 -80.00 04/03/2013 2 

31765 3176551305658 GOT -331.40 -329.60 04/03/2013 2 

35261 3526151300056 GOT -15.00 -15.00 11/03/2013 2 

633710 3146951301831 GOT -10.00 -10.00 11/03/2013 2 

634007 3164751300040 GOT -16.00 -16.00 25/02/2013 3 

634007 3167951300319 GOT -1.80 -1.80 25/02/2013 3 

634007 3195251301277 VR1 -1720.00 -1720.00 22/02/2013 9 

634007 3195251301278 VR1 1720.00 1720.00 22/02/2013 9 

634007 3195251301279 VR1 -1720.00 -1720.00 22/02/2013 3 

634007 3535651300054 GOT -16.00 -16.00 25/02/2013 3 

P2 : što s njima treba na napraviti ? 


Poštovani, 

Ispravljena je razrada neoporezivog na objektu za ručni unos kataloške prodaje za vrstu računa 4. 


Novi WIN FAUS je već na internetu 



0









Poštovani, 

Ispravljen je program prijenosa prometa HPX usluga MIPS -> LAUS. 


U ponedjeljak 18.03.2013 će biti dostipan novi LAUS TRAN lib. 

U razradi poreza po stopama nije bilo stope 25 . 

Odnosi se na promet HPX-->LAUS : 

lm_usl_stav za protokol 5 : 

god mj stopdv vdok indikator uk pdv 

2013 2 25.00 GOT HPX 78907.75 15781.55 

2013 2 25.00 GR1 HPX 51975.90 10395.18 

2013 2 25.00 VR1 HPX 6092.45 1218.49 

11.3.2013. iza 17 sati upisana razrada po stopi 25 --insert into prot_pdv 1072 sloga 

--unload je u hpx25.unl 

Danas iza 17 sati ponovo za 2013-03 i svaki dan dalje dok ne potvrdite da se prijenos odvija uredno . 

Problem je bio popuna podatka tarfbr sadržajem 0 a ne '' 

Ispravljena je i razrada neoporezivog na objektu za ručni unos kataloške prodaje za vrstu računa 4. 

Ako ispravke ranije nastalih računa bez razrade neoporezivog radimo mi , molimo za svaki račun pošaljite gdje 

se treba upisati razrada neoporezivog. 



0









Poštovani 

Kontrola knjige IRA za 2013-02 za protokol 5 napravljena je danas iza 18 sati. 

Ispravljenie su uočene nepravilnosti kao što ste tražili : 

--- stopa 5 za 2013-02 ubačena za 494 računa : 

--load to st5pr52013-02.txt 

stopdv rr pdv bb 

5.00 49139.39 2456.91 494 

datum datumuliz 

19/02/2013 18/02/2013 

-- neoporezivo za vr.računa 4 sve tiptar=3 --> ubačeno u stupac10 knjige IRA za 14 računa : 

--unload to pr5neo2013-02.txt 14 

---------------------------------------------------------------------------------------------- 

Provjera nakon ubacivanja : 

ZAglavlje : 

ukupno osnovica porez neoporezivo 

31 899 444.78 12 804 627.91 2 990 518.69 16 104 298.18 

Razrada : 

osnovica porez neoporezivo 

12 804 627.91 2 990 518.69 16 104 298.18 

ZAKLJUČAK : 

Stanje u knjizi IRA je uredno za sve račune,nevezano za status , kojima je : 

datumuliz between'01022013' and '28022013' and vprotokol = '5' 

Ostalo je provjeriti račune u knjizi IRA iza 2013-02 što će seradit kasnije tj nakon što se dobije potvrda od HP-a 

da su na produkciju prebačene programske izmjene koje su uzrokovale ove nepravilnosti : 

--- poslano kroz obradu ovog KZ-a 15.3.2013. : 

a) Ispravljena je razrada neoporezivog na objektu za ručni unos kataloške prodaje za vrstu računa 4. 

b) Ispravljen je program prijenosa prometa HPX usluga MIPS -> LAUS. 

--- Ranije ispravljen program : stopa 5 prijenos MIPS-->LAUS i svi pogrešni podaci osim za 

datumuliz=18.2.2013 što je sad napravljeno 

Molimo povratne informacije - Čeka se HP 


Poštovani, 

Ostalo je provjeriti račune u knjizi IRA iza 28.2.2013 preuzete iz HPX-a i upisati im razradu PDV-a za stopu 25 

nakon što se dobije potvrda od HP-a da su na produkciju prebačene programske izmjene koje su uzrokovale 

ove nepravilnosti : 

--- poslano kroz obradu ovog KZ-a 15.3.2013. : 

a) Ispravljena je razrada neoporezivog na objektu za ručni unos kataloške prodaje za vrstu računa 4. 

b) Ispravljen je program prijenosa prometa HPX usluga MIPS -> LAUS. 

--- Ranije ispravljen program : stopa 5 prijenos MIPS-->LAUS i svi pogrešni podaci osim za 


Molimo povratne informacije , poželjno danas , kako bismo mogli provesti provjere/ispravke na vrijeme 



0









Poštovani, 

Molimo povratne informacije , poželjno danas , kako bismo mogli provesti provjere/ispravke na vrijeme 

Ili pošaljite termin kad možemo provesti kontrole pdv-aza 2013-03 

----------------------------------------------- 





> Ostalo je provjeriti račune u knjizi IRA iza 28.2.2013 preuzete iz HPX-a i upisati im razradu PDV-a za stopu 

25 

> nakon što se dobije potvrda od HP-a da su na produkciju prebačene programske izmjene koje su uzrokovale 

ove nepravilnosti : 

> --- poslano kroz obradu ovog KZ-a 15.3.2013. : 

> a) Ispravljena je razrada neoporezivog na objektu za ručni unos kataloške prodaje za vrstu računa 4. 

> b) Ispravljen je program prijenosa prometa HPX usluga MIPS -> LAUS. 

> --- Ranije ispravljen program : stopa 5 prijenos MIPS-->LAUS i svi pogrešni podaci osim za 


> 

> Molimo povratne informacije , poželjno danas , kako bismo mogli provesti provjere/ispravke na vrijeme 


Prema : 

** zaključku u obradi 12 KZ-a od 22.3.2013 : 

Ostalo je provjeriti račune u knjizi IRA iza 28.2.2013 preuzete iz HPX-a i upisati im razradu PDV-a za stopu 25 

nakon što se dobije potvrda od HP-a da su na produkciju prebačene programske izmjene koje su uzrokovale 

ove nepravilnosti 

i 

** dopuna zahtjeva 13135 (19.4.2013.) 

Molimo ispravite protokol 5 radi prijave poreza za 3.mjesec.: 

razlika je 151.722,50 ima više ukupno nego što mi je zbrojeno po stupcima 7-18 a to treba biti isto. 

podaci u bazi ispravljeni. 

ubacila sam u razradu poreza po stopi 25 (prot_pdv) račune koji se nalaze se u 

/home/admlaus/hpx25.txt (stupci : protokol,stopa,osnovica,porez,odbiti ; delimiter pipe ) 

Radi se o 1280 računa HPX sa stopom 25 sa tarfbr=0 nastastalih prijenosom HPX--> LAUS u periodu : 

min max 

2013-03-05 18:10:30 2013-03-16 10:43:12 

koji su nastali prije programskih izmjena kojima je uzrok neispravnosti otklonjen : 

program prijenosa HPX--> LAUS prilagođen neočekivanom podatku tarfbr=0 . 

Očekivao se tarfbr='' za promet sa matsta='' tj. bez artikla nema ni tarifnog broja/porezne grupe za artikal 

( poslano kroz obradu ovog KZ-a 15.3.2013. ) 

Molimo povratne infromacije/ sufglasnost za zatvaranje zahtjeva - Riješen 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Ivan 


13134 

Riješen 


15.02.2013 11:25 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


20.02.2013 

U prilogu je primjer excel ispisa Rekapitulacije po uslugama po uvjetima 

01/01/12-31/12/2012 

Kupac 

Status 3 

1.PO UVJETU „poredak po ORGJ PU“ 

2.PO UVJETU „poredak po MIPS PU“ 


Po zadanom ispisu i polju „ispis“ – excel, po oba zadana uvjeta, dobijemo iste podatke sortirane po ORGJ 

PU. 

Po uvjetu iz točke 2. „poredak po MIPS PU“ u excel-u, u koloni MIPS PU treba se ispisivati broj 

poštanskog ureda. Sada je ta kolona prazna. 

Molim ispravak. 



0









Na excel ispisu Rekapitulacija po uslugama (sa Pregleda po fakturama) nadodan je prikaz mips đifre poštanskog 

ureda. 

Ispravljen je i redosljed podataka kod excel ispisa. 



Poštovani, 


Nakon zadnje obrade nismo dobili primjedbe . 

zadnja obrada : 

Na excel ispisu Rekapitulacija po uslugama (sa Pregleda po fakturama) nadodan je prikaz mips đifre poštanskog 

ureda. 

Ispravljen je i redosljed podataka kod excel ispisa. 




0











Klijent: 





bss_ugovor 

Hitnost: 

Vrlo hitno 


ivan 


13095 



15.02.2013 11:14 

Upisao: 

Dajana Lekić 

Područje: 

LFINK 


20.02.2013 


Molimo aplikativno rješenje za automatizaciju prijenosa podataka o kupljenim STB uređajima kroz 

kupoprodajni ugovor sa HPom, 

iz aplikacije BSS u aplikaciju LAUS te na osnovu prenesenih podataka (sa podacima o korisniku, laus 

šifrom proizvoda, brojem rata te ukupnim terećenjem automatsko generiranje računa i ispis svih računa 

kroz jednu transakciju. 

Kroz ovaj KZ rješava se dio zahtjeva HP 13095 koji se odnosi na proširenje/izmjene prijenosa ugovora iz 

BSS-a kako bi se omogućila automatska izrada računa za STB na rate 



0









Poštovani , 

Molimo predložite na koje menije treba staviti nove objekte po zahtjevu 13095 : 

win Faus , KZ 41071 : 

AUTOMATSKO GENERIRANJE FAKTURA ZA STB NA RATE 

ISPIS FAKTURA ZA STB NA RATE 

FINK , KZ 41356 

Veza broj rata - usluga 

Napomena : Proširenje prijenosa ugovora iz bss-a radi se preko postojećeg objekta 


Napravljen je novi objekt brusl_jf za evidenciju veza broj rata i Usluga. 

Mogu se evidentirati samo aktivne Usluge koje su nositelji prometa. 

Broj rata mora biti veći od 0. 

Kreiran je nova tablica brusl: 

CREATE TABLE "l1fink".brusl 

( 

brrata integer, 

usluga char(13) NOT NULL, 

aktivnost char(1) NOT NULL, 

uradio char(8) NOT NULL, 

datum date NOT NULL, 

vrijeme char(5) NOT NULL, 

terminal varchar(30,8) NOT NULL 

); 

grant all on brusl to public AS l1fink; 

create unique index brusl1 on brusl (brrata,usluga); 

Napomena: 

Za potrebe testiranja novi objekt se može izvoditi kroz izvođenje modula. 



Na objektu bss_ugv_jf proširen je prijenos ugovora iz BSS-a u LAUS sa podatkom artikal za STB ugovore na 

rate. 

Potrebno je evidentirati novi parametar LAUS sustava DTVUS - USLUGA ZA PRODAJU UREĐAJA DTV-a po 

uzoru na parametar za DTVNE. 

Trenuto to je usluga 44131 Prodaja uređaja za evotv. 

Potrebno je izvesti sljedeće SQLove za insert dvije nove greške koje će se kontrolirati prilikom prijenosa: 


values ('040','Neaktivna ili nepostojeća šifra artikla'); 


values ('041','Artikal nije u klasi DTVKL'); 

Preuzeti LAUS FINK liba u četvrtak 21.02.2013. 



0









Poštovani, 

Prijavljen je novi objekt : 

brusl_jf STB na rate - veza broj rata i Usluga 

i stavljen na meni ME4023 na 4. mjesto 

Potrebno za instalaciju : 

Preuzmite objekte i menije sutra 27.2.2013 . s interneta i provedite instalaciju 


Poštovani, 





0











Klijent: 





Hitnost: 

Vrlo hitno 


Višnja 


13113 

Riješen 


15.02.2013 10:49 

Upisao: 

Božo Mišeta 

Područje: 

LKEVP 


16.02.2013 


Kroz odog_jke ODOBRENJA - GENERIRANJE IZ PLANA GO za grupu KAPEST za 03/2012 nije 

moguće izvršiti generiranje odobrenja jer se javlja poruka: 


Poštovani, 

navedena poruka se javlja jer u šifarniku tipova odluke ( tip_jke, OPĆI PODACI) zaista nema navedene šifre. 

Taj šifarnik se inače automatski generira ručnim unosom odobrenja i nemate ga potrebe sami ažurirati. 

Međutim, nema u ga u šifarniku niti postoji ijedno odobrenje do sada s ovom šifrom tipa odluke. 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13053 



15.02.2013 08:09 

Upisao: 

Božo Mišeta 

Područje: 

LROBD 


18.02.2013 


Na listi RPMul_jd POVRATNICA IZ MALOPRODAJE, ulaz u prazni prozor (RPMzg_fd U), pritiskom tipke 

F8 ulazimo u novi pregled ( YYYpd_pr_fd) na istome omogućiti polje u funkciji filtera kojima će korisnici 

programa biti u mogućnosti pretraživati elektronski kreirane dokumente RPMul_jd POVRATNICA IZ 

MALOPRODAJE. Dokumente na ovom prozoru je moguće pretraživati u svim statusima i na svim Org. 

Jed.. Kriterij za pretragu je sintaksa izvedena iz rednog broja dokumenta / poslovne godine / broja 

poštanskog ureda (vidi sliku No. 3). Obratiti pozornost da se sintaksa formira bez interpunkcijskih znakova, 

odnosno praznih polja. 



0









Poštovani, 

1)na navedenom ekranu (YYYpd_pr_fd) omogučeno je pretraživanje po originalnom broju - (tipkom F9-alt 

pomiče se kursor u desnu stranu ekrana, gdje je polje originalni broj). Od prije već postoji i polje godina, kao i 

polje O - analitika gdje se može ukucati Laus šifra PU. Na osnovu ta tri podatka već sada možete dobiti sve RPM 

dokumente za određenu godinu, org. jedinicu i originalni MIPS broj dokumenta. 

2)MIPS broj se sastoji od rednog broja dokumenta ( nema ograničenja znamenki) u mipsu, godine (4 znamenke) 

i mips šifre PU (5 znamenaka). 

Zbog varijabilnog prvog dijela broja dokumenta nemoguće je riješiti zahtjev na opisani način. 

Stoga predlažemo : 

a)polje godina već postoji - za pretraživanje po godini 

b)polje analitika - da omogučimo da se nakon F4 -traži uđe na ekran orgj na kojem se može tražiti orgj po MIPS 

šifri 

(riješenje koje ste zahtjevali i napravljeno je za modul kategorije PU) 

c)polje mips šifra - originalni broj - da se omoguči unos 1. - 2. - 3 ili više znamenaka od početka mips broja 

dokumenta 

Ova tri filtera omogučila bi sve kombinacije pretraživanja. 

Npr. ako se unese godina 13, i originalni broj 29, dobio bi se pregled svih dokumenata koji započinju s brojem 

29 u 2013 godini. 

Npr. ako se ostavi godina prazna i unese MIPS-LAUS šifra PU a originalni broj dokumenta ostavi prazan, dobili 

bi se svi dokumenti traženog PU iz svih godina, itd. 

U očekivanju vašeg odgovora na naš predlog, 

srdačan pozdrav 


Na pregledu dokumenta RPM POVRATNICA IZ MALOPRODAJE omogučeno je u polju analitika odnosno orgj 

na F4(TRAŽI) pretraživanje po mips šifri PU-a. 

Potrebno je preuzeti laus libove rob0,rob1,rob2,rob3,rob4 koji će biti na internetu 20.02.2013. 

I dalje očekujemo pojašnjenje, da li treba nadograditi pregled pretragom po djelu originalnog broja dokumenta, 

opisano u zadnjoj obradi pod zadnjom točkom! 

S štovanjem 


Poštovani, 

Na pregledu dokumenta RPM omogučeno filtriranje originalnog broja po upisanim 1,2,3 .... znamenkama. 


S štovanjem 


Poštovani! 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13053 



14.02.2013 16:30 

Upisao: 

Božo Mišeta 

Područje: 

LROBD 


18.02.2013 


Na listi ZAHul_jd ZAHTJEVNICA SKLADIŠTU, prozoru unutar iste pod nazivom ZAHsp pr fd 1 

omogućiti uvid na ekranu sa podatkom stanje depoa za sve stavke na prikazu (vidi sliku No. 1), isto tako 

prikazati stanje depo na prozoru ZAHst_fd I (vidi sliku No. 2). Predmet je sadržaj promemorije sastanka iz 

prosinca/2012 (Tuesday, November 27, 2012 3:55 PM) i ne predstavlja novu doradu u programu. 


Poštovani, 

Na zahtjevnici skladištu ZAHul_jd odnosno na preglediu stavaka ZAHsp_pr_fd i na ekranu stavke dokumenta 

ZAHst_fd dodan je stupac Stanje-DEPO u kojem se ispisuje trenutno skladišno stanje artikla na skladištu. 

Postojeće polje Stanje izmjenjen je u Stanje_PU. 


S štovanjem 


Poštovani, 




0











Klijent: 



Pitanje 


Hitnost: 

Vrlo hitno 


Katja 


13053 



14.02.2013 16:17 

Upisao: 

Božo Mišeta 

Područje: 

LROBD 


15.02.2013 


12.02.2013.g. je poslana zahtjevnica iz PU (broj 3), koja je stigla u depo – laus broj dokumenta 35358-Q13 

-02758. 

Navedeni dokument obrađen, te po generiranom dokumentu RIM 35358-U13-04988 artikli plasirani 

prema PU. 

Zbog razlika u količinama nisu svi artikli povučeni u RIM, već su razlike povučene u dokument NRD 

Narudžba dobavljaču. 

Zašto se u mips_laus bazi u tablici zahtjev_prijenos ne puni polje laus dokument? 

Lp, 

----------------------------------------------------- 

Katja Kraljev 



0









Poštovani, 

Tablica zahtjev_prijenos se odnosi na dokumente (zahtjevnica, povratnica) koji se iz MIPS-a šalju u LAUS. U toj 

tablici se polje laus_dokument ne puni jer se u LAUS dokument u polje protokol.boriginal puni mips broj 

dokumenta. Također ne postoji u LAUS-u nikakvi pregledi zahtjev_prijenos tablice pa nije bilo potrebe da se 

polje laus_dokument puni. 

Tablica zahtjev_prijenos_mips se odnosi na LAUS dokumente (RIM) koji se prilikom knjiženja u status 7 prenose 

u MIPS. U tu tablicu se uredno puni polje laus_dokument i taj podatak dalje MIPS preuzima. 

Da li postoji potreba da se u zahtjev_prijenos tablici puni laus broj zahtjevnice? Ako da, onda je potrebno da 

doradimo integracijski servis da ažurira i polje laus_dokument. ( u tom slučaju potrebno je tražiti od MIPS-a da 

preuzima LAUS broj iz nekog dokumenta koji je nastao na osonovu laus dokumenta i taj broj šalje u navedenu 

tablicu) 

S štovanjem 


Poštovani, 

1) U zahtjev_prijenos_mips tablicu se prenose RIM izdatnice u PU sa statusom definiranim prijelazom statusa na 

objektu stu_ja. 

Na tom objektu je definiran prijelaz statusa iz 1->7 da odrađuje prijenos izdatnica u zahtjev_prijenos_mips 

tablicu. Navedena izdatnica nije ušla u prijenos jer je mjenjala statuse iz 1->2 pa iz 2->7 a na tom prijelazu nema 

definirane upute. Da bi se pokrili svi mogući slučaji prijelaza statusa potrebno je zakačiti modul rim_mips_jd i na 

prijelazu statusa 2->7 (po uzoru na uputu za prijelaz statusa iz 1 u 7). 

Da li je potrebno ažuriranje tablice zahtjev_prijenos_mips na produkcijskoj bazi nakon što se odradi sve pod 

točkom 1? 

2) Tablica zahtjev _prijenos se inicijalno ne puni sa laus_dokumentom, danas su se napunile isključivo radi 

analize rada prijenosa integracijskim servisom i više se to polje ne puni. 

Da li Vam je to potreban podatak? Ako da, potrebno je dogovoriti sa MIPS-om da laus broj dokumenta šalje u 

tablicu zahtjev_prijenos. 

S štovanjem 


Poštovani, 

Zahtjev uz vašu suglasnost zatvaramo - Riješen 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13053 



14.02.2013 16:13 

Upisao: 

Božo Mišeta 

Područje: 

LROBD 


19.02.2013 


U aplikaciji LAUS, menu' ME1225 u poslovima obrade e-zahtjevnice omogućiti nad dokumentima RIMul_jd 

IZDATNICA U MALOPRODAJU poslovnu radnju STORNO. Provedbom storna doc. RIMul_jd sadržaj 

predmetnog dokumenta vratiti na robnu karticu skladišta na kojem je izveden dokument RIMul_jd, odnosno 

dokument ZAHul_jd ZAHTJEVNICA SKLADIŠTU postaviti u status u kojem je bio prije transformacije u 

doc. RIMul_jd u statusu 2. Time će omogućuje da djelatnici nad samom Zahtjevnicom skladištu ponove 

postupak obrade, odnosno po završetku je opetovano prebace u viši status. 

Nadalje, stornirane doc. RIMul_jd prenositi na međubaznu, no ondje ih upariti sa osnovnim 

dokumentom i kao takve izuzimati sa međubaze. Prethodno navedeno podrazumijeva da se dva uparena 

dokumenta ne mogu naći na listi dokumenata koje je PU u mogućnosti povući u Primku od depoa. 

Poštovani! 

12.02.2013.g. je poslana zahtjevnica iz PU (broj 3), koja je stigla u depo – laus broj dokumenta 35358-Q13 

-02758. 

Navedeni dokument obrađen, te po generiranom dokumentu RIM 35358-U13-04988 artikli plasirani prema 

PU. 

Zbog razlika u količinama nisu svi artikli povučeni u RIM, već su razlike povučene u dokument NRD 

Narudžba dobavljaču. 

Zašto se u mips_laus bazi u tablici zahtjev_prijenos ne puni polje laus dokument? 

Lp, 

----------------------------------------------------- 

Katja Kraljev 



0









Poštovani, 

Tablica zahtjev_prijenos se odnosi na dokumente (zahtjevnica, povratnica) koji se iz MIPS-a šalju u LAUS. U toj 

tablici se polje laus_dokument ne puni jer se u LAUS dokument u polje protokol.boriginal puni mips broj 

dokumenta. Također ne postoji u LAUS-u nikakvi pregledi zahtjev_prijenos tablice pa nije bilo potrebe da se 

polje laus_dokument puni. 

Tablica zahtjev_prijenos_mips se odnosi na LAUS dokumente (RIM) koji se prilikom knjiženja u status 7 prenose 

u MIPS. U tu tablicu se uredno puni polje laus_dokument i taj podatak dalje MIPS preuzima. 

Da li postoji potreba da se u zahtjev_prijenos tablici puni laus broj zahtjevnice? Ako da, onda je potrebno da 

doradimo integracijski servis da ađurira i polje laus_dokument. 

S štovanjem 


Poštovani, 

Omogućen prijenos storniranih RIM dokumenata. Prenosi se parni dokument sa negativnom količinom. 

Da bi se dokumenti preuzimali potrebo je: 

- preuzeti laus libove rob0,rob1,rob2,rob3 irob4 koji će biti 16.02.2013 na internetu. 

- na objektu stu_ja UPUTE ZA PRELAZAK STATUSA potrebno je definirati slog za prijelaz statusa sa sljedećim 

vrijednostima: 

Vrsta dokumenta: RIM 

Stari status: 7 

Novi status: 9 

Tip: Z 

Modul: rim_mips9_jd 

Uputa:( prazno) 

Komentar: Prijenos storno dokumenata u MIPS 

Da bi se omogućilo storniranje uzdatnice RIM iz status 2 u 9 i 7 u 9 potrebno j napraviti sljedeće : 

- kroz izvođenje modula odnosno objekt obj_fm unijeti objekt RIM29 tipa H ; 

- na objektu stu_ja UPUTE ZA PRELAZAK STATUSA za postojeće upute 2->9 i 7->9 ,vdok=RIM gdje je 

procedura XXXsn_jd potrebno je unijeti u polje uputa NE tako da se ne stornirani vezani dokument u ovom 

slučaju vezana zahtjevnica. 

- također kroz objekt stu_ja UPUTE ZA PRELAZAK STATUSA potrebno je unijeti za korisnik POSTA ,vdok 

RIM,status stari 2 i 7 ,novi status 9,tip I -dodatni unijeti proceduru RIM_9_jd i u opisu upisati AŽURIRANJE 

ZAHTJEVNICE. 

S štovanjem 


Poštovani! 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Višnja 

13132 



14.02.2013 16:08 

Upisao: 

Božo Mišeta 

Područje: 

EPNAB 


15.02.2013 




0











0


Status: 







1.Zabraniti mijenjanje detaljnog statusa na Spisu ako je prethodno bila aktivirana akcija „Vrati na doradu“ 

sve dok ZZN nije vraćen u UJN. Ako je trenutni detaljni status "Na doradi" , poslati poruku upozorenja „ZZN 

je na doradi, molimo pošaljite ga u Ured za javnu nabavu“. Sada se dešavalo da se postupak poništi, a ZZN 

ostane visiti u statusu „Na doradi“... 

2.Plan nabave - inline uređivanje predmeta nabave - Rebalans, generalno funkcioniranje 

a.Plan nabave sadrži kolone koje su nužne za rad Ureda i njihov djelokrug rada je unutar ureda, ali nisu 

potrebne za službenu verziju Plana 

b.Prijedlog je da Plan bude uvijek otvoren za inline uređivanje preko transakcija Unos, Uređivanje, Brisanje 

predmeta nabave (te transakcije vidi samo administrator), a Izmjene/Dopune, odnosno Rebalans da bude 

uvjet jedino kada se radi o službenim zahvatima i to bi funkcioniralo na način kako i sada radi. 

c.Dakle, Transakcije Unos, Uređivanje i Brisanje omogućavaju neograničeno inline uređivanje podataka u 

gridu. Plan je uvijek otvoren za uređivanje i sve se može mijenjati, a kada želimo te izmjene zabilježiti, onda 

ga stavimo u Rebalans i one se bilježe u Dnevnik 

d.Da bi se uredio troškovnik potrebno je otvoriti pop-up tog predmeta i to bi radilo na gumb Otvori. Double 

click otvara inline uređivanje predmeta nabave za kolone koje su sadržane na gridu. Svi podatci na pop-up 

-u su mogući za odabir na gridu Plana nabave 

3.Primjer excel datoteke za import - maknuti primijenjenu naredbu "Freeze Panes" - to je nepotrebno i na 

naš zahtjev to nije stavljeno 

4.Omogućiti export troškovnika u excelu sa ZZN-a u svim njegovim statusima (npr. postupak se poništi i 

potrebno je ponovno napraviti ZZN...ako ga nije exportirao dok je bio u statusu Unesen, nepovratno se 

ostalo bez njega) 

5.Importiranje excela na ponudi - ponekad ima tisuće stavki koje je lakše importirati nego unositi, barem na 

ovaj način, npr. Napraviš jednu formulu i iskopiraš ju na sve stavke i importiraš excel na ponudi...npr. struja 

4000 stavki, a sve stavke imaju istu šprancu izračuna) 

6.ZZN – trenutno rješenje dovodi do grešaka. Sada funkcionira na taj način da kada TN pošalje ZZN on je 

odmah Zaprimljen, što nije točno. Sada ne postoji mogućnost odbijanja tog ZZN-a i vraćanja na doradu. 

Između Unesen i Zaprimljen potrebno je staviti status Poslan u UJN. U tom statusu Admin može izvršiti 

dvije Akcije : Vrati na doradu i Storniraj, ali isto tako ostaje da ako je ZZN Poslan u UJN da ga se može 

staviti pod spis i tek kada ga Admin stavi pod spis on postaje Zaprimljen 

a. Kada ga TN pošalje na odobrenje, onda je Poslan u UJN, a kada se stavi pod spis onda je Zaprimljen 

b.Ako je sve u redu sa ZZN-om, Admin će ga staviti pod spis 

c.Ako nije sve u redu, Admin ima mogućnost vratiti ga na doradu (prije nego je stavljen na spis ili ga ima 

mogućnost stornirati ako je skroz promašen) 

d.Ne utječe na izmjene dosadašnjeg flow-a nego ga samo širimo...tj. uvodimo novi status Poslan u UJN na 

kojemu se mogu izvršiti dvije akcije i mijenja se status pod kojim se ZZN stavlja pod spis 

7.Ponuda - PDV na 4 decimale jer ga nekad treba namjestiti zbog zaokruživanja u aplikaciji 

8.Registar ugovora - nedostaje kolona vrsta provedenog postupka 

9.Plan nabave za TN-ove - omogućiti im da vide Evidnecijski broj nabave 

10.Kod Okvirnih Sporazuma, ako se u Ponudi izmijene stavke troškovnika, to se ne reflektira u OS-u na 

troškovniku 

11.Broj spisa sa Info prenijeti u Broj ugovora na Ugovor – u 9x % slučajeva je isto 

12.Dodatne kolone za proširenje troškovnika na ZZN-u, samo tekstualna polja nemaju utjecaja na 

aplikaciju, služe za bolji opis i strukturu troškovnika, dostupna na Odabir kolona, po defaultu se ne nalaze 

na gridu 

-Model 

-Tip 

-Proizvođač 

-Lokacija 

-Vrsta održavanja 

-Broj dijela 

-Kataloški broj 

-Godina proizvodnje 

-Oznaka 

-Adresa 

-Vrsta radova 

13.Ugovor – Aneks, ne radi drop-down polje...ne prikazuje niti jedan ugovor te se ne može vezati za već 

postojeći ugovor 

14.Plan nabave – Print – Odabrani zapis se može printati iz Plana direktno, ne preko Izvezi, a sve kolone 

koje su u tom trenutku odabrane se automatski napravi resize, odnosno wrap teksta da sve stane na A4 

landscape... 



0









Poštovani, 

Molimo odgovore na dolje postavljena pitanja vezano za navedene točke zahtjeva : 

13132 Točka 5 

S obzirom da se zahtjeva importiranje troškovnika na ponudu, da li to znači da se troškovnik više ne će povlačiti 

sa ZZN-a na ponudu ? 

13132 Točka 8 

Da li kolona Vrsta postupka treba dodati samo u Registrima ugovora postupka nabave ili i u Registrima 

bagatelne nabave ? 

13132 Točka 12 

Sada u troškovniku ZZN-a postoje kolona oznaka/tip/model. Da li je mičemo i stavljamo model, tip i oznaka ili 

ostavljamo kolonu oznaka/tip/model i dodajemo ove tri i da li se nove kolone dodaju samo na ZZN ili i na 

ponudu, ugovor i narudžbenicu? 


Poštovani, 

Točke 2 i 14 smatramo da ne treba rješavat. 

Točka 12 jako puno angažmana 

Molimo pošaljite za njih hoće li se rješavat točke 2,12 i 14 ili neće . 

Točke 3,5 i 13 su još na procjeni 

Molimo suglasnost za sate za procjenjene točke 

1. Zabraniti mijenjanje detaljnog statusa na Spisu ako je prethodno bila aktivirana akcija „Vrati na doradu“ sve 

dok ZZN nije vraćen u UJN. Ako je trenutni detaljni status "Na doradi" , poslati poruku upozorenja „ZZN je na 

doradi, molimo pošaljite ga u Ured za javnu nabavu“. Sada se dešavalo da se postupak poništi, a ZZN ostane 

visiti u statusu „Na doradi“... 

Procjena za ovu točku – 1,5 sati 

2. Plan nabave - inline uređivanje predmeta nabave - Rebalans, generalno funkcioniranje 

a. Plan nabave sadrži kolone koje su nužne za rad Ureda i njihov djelokrug rada je unutar ureda, ali nisu 

potrebne za službenu verziju Plana 

b. Prijedlog je da Plan bude uvijek otvoren za inline uređivanje preko transakcija Unos, Uređivanje, Brisanje 

predmeta nabave (te transakcije vidi samo administrator), a Izmjene/Dopune, odnosno Rebalans da bude uvjet 

jedino kada se radi o službenim zahvatima i to bi funkcioniralo na način kako i sada radi. 

c. Dakle, Transakcije Unos, Uređivanje i Brisanje omogućavaju neograničeno inline uređivanje podataka u 

gridu. Plan je uvijek otvoren za uređivanje i sve se može mijenjati, a kada želimo te izmjene zabilježiti, onda ga 

stavimo u Rebalans i one se bilježe u Dnevnik 

d. Da bi se uredio troškovnik potrebno je otvoriti pop-up tog predmeta i to bi radilo na gumb Otvori. Double 

click otvara inline uređivanje predmeta nabave za kolone koje su sadržane na gridu. Svi podatci na pop-up-u su 

mogući za odabir na gridu Plana nabave 

-------------------------------- 

Za ovu točku smatramo da je poslovno nelogična jer se žele vršiti izmjene koje se ne bi zabilježile. 

Sadašnji način rada omogućuje izmjene koje se bilježe. Ovo bi zahtijevalo veliki angažman. 

Molimo povratnu informaciju - hoće li se raditi ? 

------------------------------------ 

3. Primjer excel datoteke za import - maknuti primijenjenu naredbu "Freeze Panes" - to je nepotrebno i na naš 

zahtjev to nije stavljeno 

Na procjeni 

4. Omogućiti export troškovnika u excelu sa ZZN-a u svim njegovim statusima (npr. postupak se poništi i 

potrebno je ponovno napraviti ZZN...ako ga nije exportirao dok je bio u statusu Unesen, nepovratno se ostalo 



0







bez njega) -završen, Isporučen - Korisnik potvrdio ispravnost 

Procjena za ovu točku – 2,5 sata 

5. Importiranje excela na ponudi - ponekad ima tisuće stavki koje je lakše importirati nego unositi, barem na 

ovaj način, npr. Napraviš jednu formulu i iskopiraš ju na sve stavke i importiraš excel na ponudi...npr. struja 4000 

stavki, a sve stavke imaju istu šprancu izračuna) PITANJE :S obzirom da se zahtjeva importiranje troškovnika na 

ponudu, da li to znači da se troškovnik više ne će povlačiti sa ZZN-a na ponudu ? 

HP ODGOVOR : Ne znači! Zašto se ne bi povlačio, trenutno imamo jednu opciju, želimo mogućnost druge 

na procjeni 

6. ZZN – trenutno rješenje dovodi do grešaka. Sada funkcionira na taj način da kada TN pošalje ZZN on je 

odmah Zaprimljen, što nije točno. Sada ne postoji mogućnost odbijanja tog ZZN-a i vraćanja na doradu. Između 

Unesen i Zaprimljen potrebno je staviti status Poslan u UJN. U tom statusu Admin može izvršiti dvije Akcije : 

Vrati na doradu i Storniraj, ali isto tako ostaje da ako je ZZN Poslan u UJN da ga se može staviti pod spis i tek 

kada ga Admin stavi pod spis on postaje Zaprimljen 

a. Kada ga TN pošalje na odobrenje, onda je Poslan u UJN, a kada se stavi pod spis onda je Zaprimljen 

b. Ako je sve u redu sa ZZN-om, Admin će ga staviti pod spis 

c. Ako nije sve u redu, Admin ima mogućnost vratiti ga na doradu (prije nego je stavljen na spis ili ga ima 

mogućnost stornirati ako je skroz promašen) 

d. Ne utječe na izmjene dosadašnjeg flow-a nego ga samo širimo...tj. uvodimo novi status Poslan u UJN na 

kojemu se mogu izvršiti dvije akcije i mijenja se status pod kojim se ZZN stavlja pod spis 

7. Ponuda - PDV na 4 decimale jer ga nekad treba namjestiti zbog zaokruživanja u aplikaciji 

Procjena za ovu točku – 1 sat 

8. Registar ugovora - nedostaje kolona vrsta provedenog postupka 

PITANJE :Da li kolona Vrsta postupka treba dodati samo u Registrima ugovora postupka nabave ili i u 

Registrima bagatelne nabave ? 

HP ODGOVOR :Samo u registrima Postupka nabave, bagatelna nema postupak... 


9. Plan nabave za TN-ove - omogućiti im da vide Evidnecijski broj nabave 

Procjena za ovu točku – 1 sat 

10. Kod Okvirnih Sporazuma, ako se u Ponudi izmijene stavke troškovnika, to se ne reflektira u OS-u na 

troškovniku 


11. Broj spisa sa Info prenijeti u Broj ugovora na Ugovor – u 9x % slučajeva je isto 


12. Dodatne kolone za proširenje troškovnika na ZZN-u, samo tekstualna polja nemaju utjecaja na aplikaciju, 

služe za bolji opis i strukturu troškovnika, dostupna na Odabir kolona, po defaultu se ne nalaze na gridu ... 

PITANJE:Sada u troškovniku ZZN-a postoje kolona oznaka/tip/model. Da li je mičemo i stavljamo model, tip i 

oznaka ili ostavljamo kolonu oznaka/tip/model i dodajemo ove tri i da li se nove kolone dodaju samo na ZZN ili i 

na ponudu, ugovor i narudžbenicu? 

HP ODGOVOR :Dakle, uništavamo postojeću kolonu i od nje pravimo tri...Trebaju se prenositi sve kolone dalje 

jer su sastavni dio troškovnika... 

-------------------------------- 

Ova točka zahtjeva dosta veliki angažman jer se osim izmjena na ZZN-u , izmjene moraju izvršiti i na: 

Predmetu nabave, Narudžbenici, Bagatelnom ugovoru, Ugovoru u postupka nabave, Okvirnom sporazumu, 

Ugovoru po okvirnom sporazumu i Ponudi. 

Molimo povratnu informaciju. : hoće li se raditi ili ne ? 

----------------------------- 

13. Ugovor – Aneks, ne radi drop-down polje...ne prikazuje niti jedan ugovor te se ne može vezati za već 

postojeći ugovor 

Na procjeni 



0







14. Plan -završen, nabave – Isporučen Print – Odabrani - Korisnik zapis potvrdio se može ispravnost printati iz Plana direktno, ne preko Izvezi, a sve kolone koje 

su u tom trenutku odabrane se automatski napravi resize, odnosno wrap teksta da sve stane na A4 landscape... 

---------------------------------- 

U aplikaciji se zapis može obilježiti te opcijom copy-paste može postići isto. Molimo povratnu informaciju : hoće li 

se raditi ili ne ? 

----------------------------------- 


Poštovani, 

Šaljemo procjenu za dosad neprocjenjene točke zahtjeva : 

Točka 3 Procjena za ovu točku je 1 sat. 

Točka 5 Procjena za ovu točku je 11 sati. 

Točka 13 Procjena za ovu točku je 1,5 sati. 


Poštovani , 

Vezano za : 

Točka 2 

Za ovu točku smatramo da je poslovno nelogična jer se žele vršiti izmjene koje se ne bi zabilježile. 

Sadašnji način rada omogućuje izmjene koje se bilježe. Ovo bi zahtijevalo veliki angažman. 

Molimo povratnu informaciju - hoće li se raditi ? 

Točka 12 jako puno angažmana 

Ova točka zahtjeva dosta veliki angažman jer se osim izmjena na ZZN-u , izmjene moraju izvršiti i na: 

Predmetu nabave, Narudžbenici, Bagatelnom ugovoru, Ugovoru u postupka nabave, Okvirnom sporazumu, 

Ugovoru po okvirnom sporazumu i Ponudi. 

Molimo povratnu informaciju. : hoće li se raditi ili ne ? 

Točka 14 : 

U aplikaciji se zapis može obilježiti te opcijom copy-paste može postići isto. 

Molimo povratnu informaciju : hoće li se raditi ili ne ? 

TMolimo navedite za svaku gore navedenu točku trebamo li poslati procjenu ili ne treba za to trošiti vrijeme jer 

se odustaje od rješavanja ? 



0









Poštovani, 

Status zahtjeva po pojedinim točkama jest : 

1. Procjena za ovu točku – 1,5 sati 

2. Korisnik odustao od zahtjeva 

3. Procjena za ovu točku - 1 sat. 

4. Procjena za ovu točku – 2,5 sata 

5. Procjena za ovu točku - 11 sati. 

6. Procjena za ovu točku - 30 sati 

7. Procjena za ovu točku – 1 sat 






13 Procjena za ovu točku - 1,5 sati. 


Ukupno za rješavanje zahtjeva potrebano 54 sata , od toga više od pola ( 30 sati ) za rješavanje točke 6. 

Budući se radi o zahtjevu u sklopu adaptivnog održavanja , molimo pošaljite potvrdu procjene / suglasnost za 

rješavanje . 

Status : čekamo Vaš stav . 


Poštovani, 

Točke 7 i 8 iz zahtjeva su prebačene na testni server. 

Lp, 


Poštovani, 

Točke 7 i 8 iz zahtjeva su prebačene na testni server. 

Lp, 


Poštovani, 

Molimo pristup na produkciju za Vjeran Livajić. 



0









Poštovani, 

Točka 10 iz zahtjeva je prebačena na testni server. 

Lp, 


Poštovani, 

Točka 7 i 8 zahtjeva je prebačena na produkciju. 

Lp, 


Molimo pristup na produkciju za Vjeran Livajić. 

Lijep pozdrav 


Poštovani, 

Ova točka zahtjeva je prebačena na produkciju. (5.4.2013 u 7:19 ) 

Točka 10 


Poštovani, 

Točka zahtjeva je prebačena na test. U primjeru datoteke za import troškovnika, maknuto je Freeze Panes. 



0









Poštovani, 

dostavljamo status po točkama zahtjeva : 



3. Riješeno ( 6.5.2013. na test-u ) 

4. Procjena za ovu točku – 2,5 sata 

5. Procjena za ovu točku je 11 sati. 


7. Riješeno (4.4.2013. na produkciji) 






13 Procjena za ovu točku je 1,5 sati. 


Molimo za neriješene točke 1,4,5 ,6,9,11 i 13 pošaljite prioritete ako želite utjecati na redoslijed rješavanja . 


Poštovani, 

Točka 3 zahtjeva je prebačena na produkciju. U primjeru datoteke za import troškovnika, maknuto je Freeze 

Panes. 

Molimo potvrdu zatvaranja ove točke 3 zahtjeva. 


Poštovani, 

Ova točka 4 zahtjeva je prebačena na test. 

Ugrađen je export troškovnika u troškovniku na ZZN-u u transakciji Tražilica ZZN-a u bagatelnoj nabavi, 

postupku nabave i nabavi po grupama, 

obzirom da se tamo prikazuju ZZN-ovi u svim statusima. 

Molimo povratne informacije/suglasnost za prebacivanje na produkciju točke 4. 




3. Riješeno ( 8.5.2013. na produkciji ) 

4. Riješeno - (9.5.2013. na testu ) 











Molimo za neriješene točke 1,5 ,6,9,11 i 13 pošaljite prioritete ako želite utjecati na redoslijed rješavanja . 



0









Poštovani, 

Može li na produkciju i i točka 4. zahtjeva 13132. ? 

Onda bi sve točke s testa prebacili na produkciju : 

KZ 40881, HP 12603 točke 11 i 13 te 

KZ 41336 , HP 13132 točka 4 

Molimo povratne informacije / mogućnost spajanja za Vjeran Livaić na produkciju ePN 

NAPOMENA : Zahtjev 13132 točka 4 dana 9.5.2013. je prebačena na test : 

Ugrađen je export troškovnika u troškovniku na ZZN-u u transakciji Tražilica ZZN-a u bagatelnoj nabavi, 

postupku nabave i nabavi po grupama, 

obzirom da se tamo prikazuju ZZN-ovi u svim statusima. 


Poštovani, 

točka 4 zahtjeva je prebačena na produkciju. Ugrađen je export troškovnika u troškovniku na ZZN-u u 

transakciji Tražilica ZZN-a u bagatelnoj nabavi, postupku nabave i nabavi po grupama, s obzirom da se tamo 

prikazuju ZZN-ovi u svim statusima. 






4. Riješeno - (14.5.2013. na produkciji ) 














0









Poštovani , 

Molimo povratne informacije/ formalnu potvrdu zatvaranja riješenih i na produkciju isporučenih točaka zahtjeva : 

3,4,7,8 i 10 


















Poštovani, 

Točka 13 

Ova točka zahtjeva je prebačen na test. Na ekranu ugovora kada je označeno aneks, u polju Ugovor omogućen 

je prikaz svih postojećih ugovora. 

Lp, 


Poštovani, 

Točka 1 

Ova točka zahtjeva je prebačen na test. Zabrano je mijenjanje detaljnog statusa na Spisu (u bagatelno nabavi, 

postupku nabave i nabavi po grupama) ako je prethodno bila aktivirana akcija „Vrati na doradu“ , sve dok ZZN 

nije vraćen u UJN. Ako je trenutni detaljni status "Na doradi" , pojavljuje se poruka upozorenja „ZZN je na doradi, 

molimo pošaljite ga u Ured za javnu nabavu“. 

Lp, 


Poštovani, 

Točka 11 

Ova točka zahtjeva je prebačen na test. Broj spisa sa Info se prenosi na ugovor u polje Broj ugovora. 

Lp, 



0









Poštovani, 

Točka 9 

Ova točka zahtjeva je prebačen na test. U Planu nabave je ulozi Tehnički nositelj omogućeno da vidi 

Evidencijsku oznaku. 

Lp, 


Poštovani, 

Za točke zahtjeva koje su isporučene na test molimo povratne informacije/ suglasnost za prebacivanje na 

produkciju 

HP prioriteti :13, 1, 11, 6, 5, 9. 

na test-u : 13, 1, 11, 9 

Neriješeno : 6, 5 


1. Isporučeno ( na testu 11.7.2013.) 












13 Isporučeno ( na testu 11.7.2013.) 



Poštovani, 

Sada se broj spisa sa Info prenosi u polje Broj ugovora na ugovoru u postupku nabave i nabavi po grupama. 

Ova točka zahtjeva je prebačen na test. 

Lp, 



0









Molimo pristup na produkciju za Tvrtka Matoševića radi prebacivanja na produkciju zahtjeva 13132.11, 13132.9, 

13132.13, 13369, 13457, 13467. 

Pozdrav 


Poštovani, 

Molimo za danas pristup na produkciju ePlanNabave za Tvrtka Matoševića. Također vas molimo backup baze 

produkcije ePlanNabave. 


Mario Šemper 


Poštovani, 

Točka 9, 13, 11 

Ova točka zahtjeva je prebačena na produkciju. Molimo potvrdu zatvaranja ove točke zahtjeva. 

Lp, 


Poštovani, 

Točka 1 

Ova točka zahtjeva je prebačen na produkciju. Zabranjeno je mijenjanje statusa spisa na Spisu (u bagatelnoj 

nabavi, postupku nabave i nabavi po grupama), ako je prethodno bila aktivirana akcija „Vrati na doradu“ , sve 

dok ZZN nije vraćen u UJN. Ako je trenutni detaljni status "Na doradi" , pojavljuje se poruka upozorenja „ZZN je 

na doradi, molimo pošaljite ga u Ured za javnu nabavu“. 

NAPOMENA: Dio koji se odnosi na zabranu mijenjanja detaljnog statusa ukoliko je ZZN na doradi se rješava te 

će biti prvo dignut na test. 



0









Poštovani, 

Ova točka zahtjeva je prebačena na test. 

Zabranjeno je mijenjanje detaljnog statusa na Spisu (u bagatelnoj nabavi, postupku nabave i nabavi po 

grupama) ukoliko je prethodno bila aktivirana akcija „Vrati na doradu“ sve dok ZZN nije vraćen u UJN. Ako je 

trenutni detaljni status "Na doradi" , dobije se upozorenje „ZZN je na doradi, molimo pošaljite ga u Ured za javnu 

nabavu“. Nakon što se ZZN vrazi tj. ode u status Zaprimljen, detaljni statusi se mogu mijenjati. 

Lp, 


Katja, 

Sljedeći zahtjevi su prebačeni na produkciju 24.7. i potrebna im je potvrda o zatvaranju: 

§ 13132.9 

§ 13132.11 

§ 13132.13 

§ 13369 

§ 13457 

§ 13461 

§ 13467 

Pozdrav, 

Lea Gagulić 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13131 



14.02.2013 15:36 

Upisao: 

Božo Mišeta 

Područje: 

EHPUR 


18.02.2013 


Potrebno je importirati nove organizacijske jedinice za njihovim novim oznakama u aplikaciju eHPUR, ako 

je moguće što prije. 

Stare je potrebno dezaktivirati. 

Molim i da nam pošaljete sql-ove, kako bi slijedeći put mogli isto sami odraditi. 



0









Poštovani, 

Molim slijedeće informacije: 

1. Gdje će se izvršavati zatražene promjene, test ili produkcija? 

2. Ako je spis na org. jednici koja ne postoji više, a ne postoji ni nova org. jednica (nema je u poslanoj 

tablici) , da li ostaje na staroj org. jed? 

3. Svi spisi dobivaju/nasljeđuju nadležnost org. jedinice koja je poslana u tablici eHPUR_ORGJ_14022013? 


Još jedno pitanje: 

Na testu smo vidjeli da ima cca 1800 rješavatelja/radnika dok u tablici koja je poslana ima cca 1400? 

Što sa preostalima? 

Hvala. 


Molim Vas da nam objasnite razliku između prvog i drugog lista u tablici eHPUR_ORGJ_14022013. 

Također, u tablici org. jedinica nedostaje kolona koja će označavati nadređenu org. jedinicu = nadorgj. 

Molimo jednu tablicu koja će sadržavati sve potrebe podatke. 

Zahvaljujemo, 

Lp, 


Poštovani, 

Organizacijske i Radnici koji su poslani u excelu , da li samo njih treba „deaktivirati“ te onda importirati nove iz 

excela ili deaktiviramo sve postojece OJ i radnike te importiramo nove iz excela. 

S štovanjem 



0









Poštovani, 

PLANIRAMO izvršit tražene promjene 

1. Samo na produkciji 

2. Ako je spis na org. jednici koja ne postoji više, a ne postoji ni nova org. jednica (nema je u poslanoj tablici**) . 

Spis ostaje na staroj org. jed. Rješava pisarnica proslijeđivanjem/surješavanjem/zaduživanjem ... 

3. Spisi ne dobivaju/ne nasljeđuju nadležnost nove org. jedinice koja je poslana u tablici za učitavanje . 

Spisi ostaju na staroj orgj jed. Rješava pisarnica proslijeđivanjem/surješavanjem/zaduživanjem ... 

4. Organizacijske jedinice i Radnici koji su poslani u excelu importiraju se kao aktivni . 

5. Deaktiviramo sve postojece OJ i radnike . 

Molimo suglasnost za obim i način provođenja promjena te termin u kojem se mogu izvršiti . 

** Katja poslala 18.2.2013. tablice po kojima se radi import : 

u prilogu orgj_eHPUR_18_02_2013 su nove orgj. jedinice ( sa nadređenom orgj) koje treba importirati – stare 

treba dezaktivirati. 

U prilogu radnik_eolog18022013 su radnici sa pridruženim (novim) organizacijskim jedinicama. 


Procjena za ovaj zahtjev je 7h (do sada je utrošeno 2h i 45 min.) 

Molimo povratnu informaciju, slažete li se sa procjenom i možemo li početi pripremati sve za import. 

Također, ukoliko je gore navedeno potvrdno, molimo pristup od 16.00 sati danas, 18.02.2013. za kolegu Vjerana 

Livaića. 

Zahvaljujemo na odgovorima. 


Poštovani, 

Označeni zapisi imaju u stupcu nadorgj upisane vrijednosti kojih nema u stupcu orgj , pa sukladno tome ne 

mogu ostvariti parent/child vezu. 

Molimo pošaljite nedostajuće veze za ove nadređene , njihove oznake i njima nadređene orgj sve do 00000 tj 

najnadređenije krovne orgj kako bi se proveo import 

Napr za nadorgj= 41039 treba poslati sve veze kojih nema u već poslanima 

orgj nadorgj naziv 

41039 40001 SEKTOR ODRŚAVANJA I SKLADIćNOG POSLOVANJ---> treba poslati jer nedostaje 

40001 00000 DIVIZIJA PODRćKA---------------------------------------------------> ne mora se slati jer već postoji veza 

(DPO) 

00000 00000 HP-HRVATSKA POćTA D.D.------------> ne mora se slati jer već postoji veza (HP ) 

u prilogu su sve nadorgj kojih nema u stupcu orgj . 



0









Nakon ponovljenog slanja excel-a za učitavanje : Opet nije dobro. 

Npr. U fileu "orgj_radnik_19022013" , u stupcu orgj postoje zapisi 41041 , 12070 , 41049 , 41069, 11779 itd . 

Takvih zapisa tj orgj nema u fileu "orgj_eHPU_18_02_2013" u stupcu orgj. 

Prijedlog 1 : 

Kad HP detaljno provjeri oba excel fila , neka pošalje uredne podatke za učitavanje 

Prijedlog 2 : 

HP ne dalje ne provjerava i ne šalje ponovo podatke za učitavanje. Učitava se što se može . 

Šalje se u HP što nije učitano i uz svaki neučitani slog ide objašnjenje 

(napr, radnik nije upisan kao rješavatelji jer se orgj na kojoj je radnik ne veže za neku orgj nadležnu za 

rješavanje spisa ) 

Molimo stav HP-a : po kojem prijedlogu postupamo ? 


Poštovani, 

U priloženom excelu se nalaze radnici sa nepostojećom OJ. 

Ostale podatke ćemo poslije 16.00 sati importirati stoga molimo pristup od 16.00 sati za kolegu Vjerana Livaića. 

Hvala. 


Poštovani, 

Sukladno dostavljenim tablicama izvršen je import podataka u aplikaciju eHPUR na produkcijskom serveru. 

Molimo povratne informacije / suglasnost za zatvaranje zahtjeva- Riješen 


Poštovani, 









0









Poštovani, 



Poštovani, 




Zahvaljujemo, 

Lp, 


Poštovani, 

Zahtjev zatvaramo uz Vašu suglasnost ( 7.3.2013.) - Riješeno . 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Ivan 


Poštovani, 

13130 



14.02.2013 12:56 

Upisao: 

Božo Mišeta 

Područje: 

EOBRRAC 


14.02.2013 

Molim vas provjeru ugrađenih parametara kod likvidiranja računa u eObradi. 

Prema zahtjevu u prilogu zadane kontrole kod likvidiranja računa su: 

a)OIB, originalni broj, iznos, godina (uzima se iz datuma računa) 

b)Šifra partnera, originalni broj,iznos, godina (uzima se iz datuma računa). 

Uvjet prolaska je da jedan parametara u uvjetu mora biti različit 


Imamo slučaj kod računa pod rednim brojem 007114-13, račun se ne može likvidirati jet program javlja da 

postoji račun pod red.br 005904-12 s istim parametrima, iako im je godina u računu različita. 

Molim vas možete li provjeriti o čemu se rad, i da li su mijenjani parametri kontrole. 



0









Poštovani, 

Molimo omogućite sutra 15.02.2013 pristup na produkciju za Tvrtka Matoševića vezano za zahtjev 13130. 

Nema potrebe za prekidanjem rada u aplikaciji tj ostali korisnici se ne moraju odjavljivati radi rješavanja ovog 

zahtjeva / provjere 


Molim da nam se pošalje točna poruka koju javlja aplikacija kad se želi izvršiti likvidacija računa 007114-13. 


Poštovani, 

kod likvidiranja računa u eObradi. ugrađene se zadane/potrebne kontrole kod likvidiranja računa su: 

a)OIB, originalni broj, iznos, godina (uzima se iz datuma računa) 

b)Šifra partnera, originalni broj,iznos, godina (uzima se iz datuma računa). 

Uvjet prolaska je da jedan parametara u uvjetu mora biti različit 

slučaj kod računa pod rednim brojem 007114-13, račun se ne može likvidirati jet program javlja da postoji račun 

pod red.br 005904-12 s istim parametrima, iako im je godina u računu različita. 

NAPOMENA: takve kontrole su od prije kod urudžbiranja bile pa su sad jednake i kod likvidiranja . 

Ispravak je prebačen na testni server gdje je potrebno provjeriti valildaciju u T9. 

MOlimo povratne informacije - obavjest kad se može prebaciti na produkciju 


Da li se mogu zatvoriti slijedeći zahtjevi, tj. da li je HP javio da se zahtjevi mogu prebaciti sa testa na produkciju? 

12625 

12658 

12691 

12268 

13130 

13126 





Poštovani, 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Ivan 


13129 



14.02.2013 10:18 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


15.02.2013 


01.03.2013 

Potrebno je na objektu rekuslN.fas kod' Ostali uvjeti' omogućiti odabir prema vrsti usluge. 


Poštovani, 

Na objektu rekuslN.fas kod' Ostali uvjeti' nadodano je filter polje vrsta usluge. 


Instalacija: u ponedjeljak ujutro 04.03.2013. bit će dostupan novi WIN FAUS lib 



Poštovani, 





0











Klijent: 





Hitnost: 

Vrlo hitno 


Ivan 


13128 



14.02.2013 10:02 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


15.02.2013 


Potrebno je u LAUS sustavu uz postojeće izračune rabata koji se primjenjuju na ugovorima/fakturama 

omogućiti i sljedeći izračun: uvjet za dobivanje rabata je određena količina definiranih usluga a rabat se 

primjenjuje i na dodatne usluge. 

Npr. Ugovor1: 

•usluga 1 - 

•usluga 2 – količine za rabat, primjena rabata (postotak xy%) 

•usluga 3 - količine za rabat, primjena rabata (postotak xy%) 

•usluga 4 - primjena rabata (postotak xy%) 

•usluga 5 

Ako u ugovoru1 sumarne količine usluga 2 i 3 (količina usluge 2 + količina usluge 3) zadovolje uvjete za 

dobivanje rabata tada je potrebno primijeniti rabat (određeni definirani postotak xy%) na usluge 2,3 i 4. Na 

usluge 1 i 5 mogu se primijeniti neki drugi već definirani rabati. 

Potrebno je ovo prvo primijeniti na fakturiranje i ugovore HPX usluga. 



0









Kod automatskog fakturiranja HPX usluga omogućen je i novi način obračuna rabata. 

Uvjet za dobivanje rabata je određena količina definiranih usluga a rabat se primjenjuje i na dodatne usluge. 

Npr. Ugovor1: 

•usluga 1 - 

•usluga 2 – količine za rabat, primjena rabata (postotak xy%) 

•usluga 3 - količine za rabat, primjena rabata (postotak xy%) 

•usluga 4 - primjena rabata (postotak xy%) 

•usluga 5 

Ako u ugovoru1 sumarne količine usluga 2 i 3 (količina usluge 2 + količina usluge 3) zadovolje uvjete za 

dobivanje rabata tada se primijenjuje rabat (određeni definirani postotak xy%) na usluge 2,3 i 4. Na usluge 1 i 5 

mogu se primijeniti neki drugi već definirani rabati. 

HP je već preuzeo novi WIN FAUS lib. 


Poštovani, 





0











Klijent: 



Pitanje 


Hitnost: 

Vrlo hitno 


Katja 


13127 



13.02.2013 15:07 

Upisao: 

Božo Mišeta 

Područje: 

LROBD 


15.02.2013 


Molim Vas za pomoć za navedenu poslovnu radnju, a vezanu za knjiženje dokumenta 

- RC3ul_jd NIVELACIJA CIJENE NA SKLADIŠTU - TERET KRAJNJEG KORISNIKA, a odnosi se na 

nivelaciju broj 35352-00066 i 35352-00067 (slika kartice u privitku). Prema zapažanju kolegica iz 

knjigovodstva postoji nejasnoća uz navedeni dokument odnosno postoji neslaganje u cijeni. 

Na skladištu 35352 je 31.01.2013. napravljen document RC3 35352-R13-00067 za artikle 310113 i 

311914. Kako automatskim knjiženjem ta nivelacija nije točno odrađivana, analizirajući robnu karticu uočili 

smo nelogičnosti. Stara cijena je bila 127,00 a nivelirana je cijena 101.60. koja vrijedi od 01.02.2013. 

01.02.2013. rađena je nivelacija sa 127,00 na 101,60 tako da je sada MPC za taj artikl 127,00. Molim 

hitno rješenje. 

RC3 35352-R13-00066 – datum dokumenta 01.02.2013 

stara cjnova cj 

310113207 

311914127101.6 

novi cjenik od 01.02.2013 

RC3 35352-R13-00067 – datum dokumenta 31.01.2013 

-rađena nivelacija za iste artikle iako nije došlo do promjene cijena, nije bilo novih cjenika?? 



0









Nivelacija na skladištu RC3 35352-R13-00066 je suvišna odnsono nije dobro napravljenna na 31/01/2013 t dok 

RC3 35352-R13-00066 je uredu koja je nastala na datum 01/02/2013 kada je i došlo do promjene cijene za 

artikle 310113,311914 . 


Poštovani, 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Ivan 


13126 



13.02.2013 14:22 

Upisao: 

Božo Mišeta 

Područje: 

EOBRRAC 


15.02.2013 


U prijenosu podataka Laua eObrada potrebno je prenositi i primke od dobavljača koje nastaju direktno u 

MIPS-u (ambulantna dostava). 

Primke će se povezivati s računima dobavljača kao I standardne primke do sada. 

Primke iz MIPSa prenose se u LAUS te se formira dokument RP3, protokol X. 



0









Poštovani, 

Napravljeno je proširenje procedura koje se izvode na triggere tablice protokol za obuhvaćanje vrste dokumenta 

RP3 i vrste protokola X. 

SQL-ovi za izmjenu procedura: 

drop procedure protokol_dokit_ins; 

create procedure "l1fink".protokol_dokit_ins(new_protokol char(15), 

new_vprotokol char(1), new_vdok char(3), 

new_analitika char(7), new_boriginal nvarchar(40), 

new_status char(1), new_uradio char(8), new_datum date ) 

insert into rad_protokol (protokol,vdok,status,korisnik,datum) 

values (new_protokol ,new_vdok ,new_status ,new_uradio ,new_datum ); 

IF (new_vdok in ('RPP', 'TPR') AND new_vprotokol='P') OR (new_vdok = 'RP3' AND new_vprotokol='X') 

THEN 

insert into primka_eolog(protokol, dobavljac, 

akcija, datum_upisa) 

select protokol[1,5]||'-'||protokol[6,8]||'-'||protokol[9,13], 

analitika, 'I', 

current year to second 

from protokol 

where protokol = new_protokol 

and analitika in (select part from part where drzava='191'); 

END IF 

IF (new_vdok in ('UGD') AND new_vprotokol='R' AND new_status = '2') 

THEN 

insert into ugovor_eolog(protokol, boriginal, dobavljac, 

aktivnost, akcija, datum_upisa) 


boriginal, analitika, 'D', 'I', 


from protokol 

where protokol = new_protokol; 

END IF 


drop procedure protokol_dokit_del; 

create procedure "l1fink".protokol_dokit_del(old_protokol char(15), 

old_vprotokol char(1), old_vdok char(3), 

old_analitika char(7), old_boriginal nvarchar(40), 

old_status char(1), old_uradio char(8), old_datum date ) 

delete from rad_protokol where (protokol = old_protokol ); 

IF (old_vdok in ('RPP', 'TPR') AND old_vprotokol='P') OR (old_vdok = 'RP3' AND old_vprotokol='X') 

THEN 



values (old_protokol[1,5]||'-'||old_protokol[6,8]||'-'||old_protokol[9,13], 

old_analitika, 'D', current year to second); 

END IF 



0







IF (old_vdok -završen, in ('UGD') Isporučen AND old_vprotokol='R' - Korisnik potvrdio AND ispravnost old_status = '2') 

THEN 



values (old_protokol[1,5]||'-'||old_protokol[6,8]||'-'||old_protokol[9,13], 

old_boriginal, old_analitika, 

'D','D',current year to second); 

END IF 


drop procedure protokol_dokit_upd; 

create procedure "l1fink".protokol_dokit_upd(pre_protokol char(15), 

pre_vprotokol char(1), pre_vdok char(3), pre_boriginal nvarchar(40), 

pre_dobavljac char(7), pre_status char(1), old_protokol char(15), 

old_vprotokol char(1), old_vdok char(3), old_boriginal nvarchar(40), 

old_dobavljac char(7), old_status char(1) ) 

IF (((pre_vdok in ('RPP', 'TPR') AND pre_vprotokol='P') 

or (old_vdok in ('RPP', 'TPR') AND old_vprotokol='P')) 

OR ((pre_vdok = 'RP3' AND pre_vprotokol='X') 

or (old_vdok = 'RP3' AND old_vprotokol='X'))) 

THEN 




analitika, 'U', 


from protokol 

where protokol = pre_protokol 

and analitika in (select part from part where drzava='191'); 

END IF 

IF (((pre_vdok in ('UGD') AND pre_vprotokol='R') 

or (old_vdok in ('UGD') AND old_vprotokol='R')) 

AND (pre_status = '2')) 

THEN 




boriginal, analitika, 'D', 'I', 


from protokol 

where protokol = pre_protokol; 

END IF 

IF (((pre_vdok in ('UGD') AND pre_vprotokol='R') 

or (old_vdok in ('UGD') AND old_vprotokol='R')) 

AND (pre_status = '2' AND old_status = '2')) 

THEN 




boriginal, analitika, 'D', 'U', 


from protokol 

where protokol = pre_protokol; 



0


Status: 

END IF 

Poštovani, 








S štovanjem 


Poštovani, 

Molimo povratne informacije/suglasnost za zatvaranje zahtjeva - Riješen . 

Napravljeno je proširenje procedura koje se izvode na triggere tablice protokol za obuhvaćanje vrste dokumenta 

RP3 i vrste protokola X. 

SQL-ovi za izmjenu procedura - Poslano datum i vrijeme: 18.2.2013 10:34:20 





Da li se mogu zatvoriti slijedeći zahtjevi, tj. da li je HP javio da se zahtjevi mogu prebaciti sa testa na produkciju? 

12625 

12658 

12691 

12268 

13130 

13126 







0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13125 



13.02.2013 13:47 

Upisao: 

Božo Mišeta 

Područje: 

LROBD 


15.02.2013 


U pripremi knjiženja Depo-a 35352 period 01.01.2013. – 31.01.2013. klasa 62 ima dokumenat RC3 35352- 

R13-00067 koji iz nama nepoznatog razloga ne odgovara Uputama o automatskom knjiženju (isti iznos 

knjižen na Osnovni konta – MPC 663000 i na 1 Protu konto PDV 664200, a na 2. Protukonto je pridružio 

neodgovarajući iznos). 

Napominjem da je dokumente RC3 u 2012. I na Pripremi 35358 klasa 62 od 01.01.2013.-.11.01.2013. 

odradio točno (Pripreme u privitku). 

Molim rješenje. 


Poštovani, 

Nivelacija na skladištu RC3 35352-R13-00066 je suvišna odnsono nije dobro napravljenna na 31/01/2013 te je 

kao takva izbrisana kao dokument ,sa robne kartice ,pripreme za knjiženje,obračunske tablice te prenosne 

tablice hp1d_stav. 


S štovanjem 


Poštovani, 




0











Klijent: 





ruckat, vr4 

Hitnost: 



visnja, glorija 

13080 



13.02.2013 12:20 

Upisao: 

Dajana Lekić 

Područje: 

LWINFAU 


15.02.2013 




0









Radi se o dopunama po zahtjevu 13080 : 

Dopuna: 5.2.2013 (Glorija ) 

a1. Kod unosa analitike (Kupac) na ruckat za vrstu računa 4 potrebno omogućiti i vrstu analitike O ako je 

vdok GOT ili GR1 ( upisivati će se PU na kojega se odnosi) 

NAPOMENA : za VR1 analitika mora biti P . 

a2. Toj mogućnosti upisa vrste analitike O prilagoditi sve preglede, ispise na objektu ruckat. 

a3. Na ekranu Pregleda potrebno omogućiti pretragu i po vrstu Vrsti računa. 

Na ispis nema nikakve ugradnje Vrsta računa samo da se omogući pretraga po njima jer sada se 

zapravo dobiju različite kombinacije svakakvih računa iz evidencije. 

a potrebno je na pregledu dobiti , napr, GOT od kataloške što se bez filtera vrsta računa ne može . 

Dopuna 13.02.2013 u privitku vezano za dorade za račune vrste 4 Evidencija MIPS dokumenata na 

objektu ruckat_fas 

1. Omogućiti izmjenu cijene kod unosa stavaka za račun – prilikom unosa artikla ponuditi cijenu iz 

trenutno važećeg cjenika, ali omogućiti izmjenu ako je potrebno (nije logično da na računu piše 1 x 

40,00=50,00), te računati vrijednost=količina*cijena 

2. Ugraditi kontrolu da za izabranu vrstu usluge nudi samo artikle koji su za tu uslugu (sada dopušta za 

izbor usluge 44131 „Prodaja uređaja za EVO tv“ izabrati artikl 320904 „F12 Minerali i stijene XXX“ a to nije 

logično) 

3. Za tip cijene P omogućiti zadavanje iznosa i računati vrijednost=(iznosxkoličinaxcijena)/100 

4. U pregledu (tražilici) za šifre usluga (F4) omogućiti pisanje malim slovima jer su usluge u izborniku 

napisane malim slovima. 

5. Kod unosa cijena tj. vrijednosti zarez na numeričkoj tipkovnici ne radi (ako unesem 15,50 on prikazuje 

1.550,00 – ispravno se zabilježi 15,50 tek kad se unese točka sa slovnog dijela tipkovnice) – može li se 

omogućiti da radi zarez na numeričkom dijelu tipkovnice? 

6. Kod unosa zaglavlja računa dodati analitiku O – organizacijsku jedinicu (sada može samo A i P, možda 

je ovaj zahtjev već poslan) 

7. Na objektu knjkat_fas omogućiti posebno knjiženje za vrstu računa 4 Evidencija MIPS dokumenata – 

upute za knjiženje kao za tip 1 – ili napraviti novi ekran za automatsko knjiženje računa vrste 4 (ovisno što 

je jednostavnije) 

8. Ako nema prepreka do sada izvršene izmjene na objektu ruckat_fas prenijeti na produkcijsku bazu 

kako bi se što ranije moglo početi s izradom dokumenata za mjesec siječanj. Za potrebe fiskalizacije unijeti 

sve organizacijske šifre poštanskih ureda mreže (ne treba ih ponovno prijavljivati prema Poreznoj upravi jer 

su već prijavljeni kao prodajna mjesta kroz MIPS, u uputama staviti indikator da su prijavljeni). Za svaku 

orgj vezati uputu za fiskalizaciju. 



0









Poštovani, 

Vezano za uvođenje kontrole pod : 

2. Ugraditi kontrolu da za izabranu vrstu usluge nudi samo artikle koji su za tu uslugu (sada dopušta za izbor 

usluge 44131 „Prodaja uređaja za EVO tv“ izabrati artikl 320904 „F12 Minerali i stijene XXX“ a to nije logično) 

Predlažemo : 

varijanta 1 : 

kontolu na prva 2 znaka klase artikla (hardcode) za sve usluge kojima je obavezan artikal. 

Kontrolirati da li je artikal u klasi koja počinje kao navedena uz uslugu : 

usluga pripadnost nazive klasa artikala uz uslugu 

3611 SS1 Poçtanske marke 61 

3612 SS1 Doplatne marke 66 

411334 SS3 Poklon uz brzojav 62 i 63 

44111 SS2 Prodaja vlastite trgovake robe 62 

44112 SS2 Prodaja filatelije za pretplatnik 62 i 63 

44113 SS2 Prodaja biljega 62 

4412 SS2 Prodaja komisione trgovake robe 63 

44131 SS2 Prodaja ure|aja za evotv 64 

9193 SS3 POPODNEVNA DOSTAVA 62 i 63 

varijanta 2 : 

finija i flexibilnija kontrola : uvesti parametar po ključu gdje bi ključ bila usluga a podatak klasa tj početak šifre 

klase u kojoj su artikli za tu uslugu uz mogućnost višestrukog upisa usluge a samo jedanput kombinacije uslugaklasa 

. Promjenom ključa i podatka mijenja se ponašanje kontrole pa ne treba dorađivati programe ako s 

ejavljaju nove usluge, klase ili pravila povezivanja nego se jednosstavno pravila upišu u parametar. 

napr, za uslugu 44112 i upisano u parametar : 

ključ podatak 

44112 627 

44112 628 

44112 638 

kontrola dozvolila uz uslugu 44112 upis artikala koji su u klasama 627% ili 628% ili 638% a zabranila upis 

artikala ostalih klasa . 

627 MARKE I VRIJEDNOSNICE ZA FILATELIJU R.H. 

628 INOZEMNE MARKE I OSTALI FILATELISTIŹKI A 

638 FILATELISTIŹKI ASORTIMAN 

Molimo vaš stav u vezi predloženog : rješava se po varijanti 1 ili 2 ili na neki drugi način ? 


Poštovani, 

Kod preuzimanja računa iz BSS-a puniti polje način plaćanja za fiskalizaciju sadržajem T 

Kod slanja na fiskalizaciju onih računa koji imaju vdok=BSS ista se neće izvršiti ako u uputama nema 

kombinacije sa vdok=BSS. 

Poruka : račun nije fiskaliziran - nije u uputama 

-- rješeno kroz HP zahtjev broj 13115 . 

PITANJE : 

Treba li omogućiti prikaz i pregled pod nova vrsta računa 5- Računi preuzeti od BSS pregled tih računa ? 

-- ranije su se vidjeli kao vrsta računa 2 (vdok DIG, indikator DG* . Sad se uopće ne mogu vidjeti . 

Ako treba , specificirajte koje mogućnosti su za njih dozvoljene : 

(unos,izmjena,briši , status, fiskaliziraj ) ili navedite 

Omogućiti Samo uvid , pregled , izbor s pregleda i stavke bez mogućnosti ažuriranja/promjene podataka 



0









Poštovani, 

vezano za slučaj : 

Potrebna hitna provjera fiskalizacije računa zbog stavljanja na produkciju: 

Za potrebe unosa gotovinskih računa napunjene su tablice fisk_pospr i fisk_radvr i fisk_up. 

Uputa je postavljena na O jer se račun formira sa načinom plaćanja O. 

Ali svjedno fiskalizacija na TESTU ne prolazi tj. javlja neuspješno fiskaliziranje. 

Provjereno : 

verzije programa na TEST-u vezano za fiskalizaciju su od 15.2.2013 . 

servis za fiskalizaciju na TEST okruženju podešen je na novi način rada ( jučer 19.2.2013 nakon sastanka ) : 

-- koji je adekvatan promjenama u isporukama od utorka ujutro (19.02.2013) WIN FAUS lib 

-- za kojeg treba proširiti tablicu lm_usl_fak :ALTER TABLE lm_usl_fak ADD ( fisk_nacpla char(1) BEFORE 

nacpla ); 

-- za kojeg treba popuniti fisk_nacpla ako je račun nastao prije instaliranja programskih izmjena od 19.2.2013 a 

koji se sad treba fiskalizirati 

Verzije programa na PRODUKCIJI vezano za fiskalizaciju su stare 

Servis za fiskalizaciju na PRODUKCIJI je ostao nepromijenjen tj podešen je za stari način rada tako da tu nema 

problema s fiskalizacijom . 

Sve potrebnoo za instaliranje NOVE verzije na TEST-u detaljno šaljemo u KZ 40942 , HP 13079 


Račune vrste 4 želite evidentirati na različite poslovne prostore a time i različit fiskalni broj što je uredno . 

Za sve te različite poslovne prostore (oko 1200 ili više ) želite da se ispiše neki fiksan naziv za Mjesto izdavanja 

(Osijek ) što nije uredno. 

Poslat ćemo prijedloge rješenja . 

Unaprijed se ograđujemo od posljedica koje eventualno mogu nastupiti u slučaju ako PU bude našla da je gore 

navedeno prekršaj. 



0









Poštovani, 

Napravljene su izmjene na objektu kataloške prodaje kod evidentiranja dokumenata iz MIPS-a. (vrsta računa 4) 

Kod unosa analitike omogućen je unos vrste analitike O za vrste dokumenta GOT i GR1. 

Za vrstu dokumenta VR1 analitika može biti samo P. 

Pregled, ispis i ispis u excel su prilagođeni da ispisuju podatke za vrstu analitike O. 

Na zaglavlju ekrana je nadodano filter polje Vrsta računa. 

Kod unosa stavki računa za dokumente iz MIPS-a omogućeno je prekucavanje cijene artikla. 

Napravljen je i novi ekran TRAŽI na poljima usluge. 

Na tom ekranu je omogućeno filtriranje malim slovima po nazivu usluge. 


Instalacija: preuzmite novi WIN FAUS lib koji je već na internetu. 


Još se rade pojedine točke zahtjeva a za neke od njih trebamo i konačne dogovre jer su nedorečene . 

Prijedlog : veza usluga-klasa artikla u kojoj trba biti artikal koji se veže uz uslugu napraviti preko dodatnih 

podataka za usluge : 

ako je obavezan artikal uz uslugu , omogućiti upis klase kojoj mora pripadati artikal . Radi na 'klasa like' 

principu kod kontrola 

Molimo Vaš stav 


Poštovani, 

Vezano za jučer prijavljene greške na ruckat riješeno je : 

1. Poruka : Greška ... se javljala za račune koji nemaju upisanu vrijednost načina plaćanja (novo polje 

fisk_nacpla) 

Potrebno je popuniti polje fisk_nacpla u tablici lm_usl_fak za sve račune kataloške i filatelije što je jučer iza 

16:30 napravljeno ( veza zahtjev 13079 ). 

2. Kada se izabere vrsta analitike O sada se otvara ekran organizacijskih jedinica. 

3. Omogućeno je pretraživanje malim slovima kod pretrage usluga. 

4. Ispravljen je prikaz naziva načina plaćanja na ispisu. 


Instalacija: Preuzmite novi WIN faus lib je već na internetu. 




0









Poštovani 

U nastavku status pojedinih točaka ovog zahtjeva - molimo vaš stav 

Dopuna: 5.2.2013 (Glorija ) 

----- sve riješeno i isporučeno ---------------a1. 

Kod unosa analitike (Kupac) na ruckat za vrstu računa 4 potrebno omogućiti i vrstu analitike O ako je vdok 

GOT ili GR1 ( upisivati će se PU na kojega se odnosi) 

NAPOMENA : za VR1 analitika mora biti P . 

a2. Toj mogućnosti upisa vrste analitike O prilagoditi sve preglede, ispise na objektu ruckat. 

a3. Na ekranu Pregleda potrebno omogućiti pretragu i po vrstu Vrsti računa. 

Na ispis nema nikakve ugradnje Vrsta računa samo da se omogući pretraga po njima jer sada se zapravo 

dobiju različite kombinacije svakakvih računa iz evidencije. 

a potrebno je na pregledu dobiti , napr, GOT od kataloške što se bez filtera vrsta računa ne može . 

Dopuna 13.02.2013 (Brnaka/Katica/Zvjezdana) vezano za dorade za račune vrste 4 Evidencija MIPS 

dokumenata na objektu ruckat_fas 

----- riješeno i isporučeno ---------------- 

1. Omogućiti izmjenu cijene kod unosa stavaka za račun – prilikom unosa artikla ponuditi cijenu iz trenutno 

važećeg cjenika, ali omogućiti izmjenu ako je potrebno (nije logično da na računu piše 1 x 40,00=50,00), te 

računati vrijednost=količina*cijena 

4. U pregledu (tražilici) za šifre usluga (F4) omogućiti pisanje malim slovima jer su usluge u izborniku napisane 

malim slovima. 

6. Kod unosa zaglavlja računa dodati analitiku O – organizacijsku jedinicu (sada može samo A i P. zahtjev već 

poslan a1 i a2 gore 

----- ne odnosi se na LAUS aplikaciju ---------------- 




8. Ako nema prepreka do sada izvršene izmjene na objektu ruckat_fas prenijeti na produkcijsku bazu kako bi 

se što ranije moglo početi s izradom dokumenata za mjesec siječanj. Za potrebe fiskalizacije unijeti sve 

organizacijske šifre poštanskih ureda mreže (ne treba ih ponovno prijavljivati prema Poreznoj upravi jer su već 

prijavljeni kao prodajna mjesta kroz MIPS, u uputama staviti indikator da su prijavljeni). Za svaku orgj vezati 

uputu za fiskalizaciju. 

--- Rješava se ----------------- 


----- Potrebno poslati nove zahtjeve ---------------- 



Razlog zbog kojeg treba poslati kao novi zahtjev : 

Kontrola je globalna i ne odnosi se samo na ruckat nego na sve obrade u kojima se veže usluga i artikal pa je 

potrebno i globalno sagledati i odabrati najbolje rješenje 

7. Na objektu knjkat_fas omogućiti posebno knjiženje za vrstu računa 4 Evidencija MIPS dokumenata – upute 

za knjiženje kao za tip 1 – ili napraviti novi ekran za automatsko knjiženje računa vrste 4 (ovisno što je 

jednostavnije) 


Knjiženje se ne rješava na ruckat. Smatramo da knjiženje vrste računa 4 trbe biti po principu knjts7 i 5 (gotovina 

u PU) samo što se iz drugih tablica radi a ne kao za vrstu računa 1 Kataloška jer su drugačija konta 12* . 



0









Poštovani , 

-- Rješava se još jedina preostala nerješena točka zahtjeva : 


Ostale točke zahtjkeva su već riješene ili ih ne treba kroz ovaj zahtjev rješavati : 

---- ne odnosi se na LAUS aplikaciju ---------------- 




-- prema objašnjenju korisnik (Zvjezdana) treba poslati mail na help desk da se to omogući pod WinPanter. Na 

putty emulaciji je omogućeno 

----- Odustalo se od zahtjeva : 




Kontrola je globalna i ne odnosi se samo na ruckat nego na sve obrade u kojima se veže usluga i artikal pa je 

potrebno i globalno sagledati i odabrati najbolje rješenje 

----- Poslan novi zahtjev 13260 za : 

7. Na objektu knjkat_fas omogućiti posebno knjiženje za vrstu računa 4 Evidencija MIPS dokumenata – upute 

za knjiženje kao za tip 1 – ili napraviti novi ekran za automatsko knjiženje računa vrste 4 (ovisno što je 

jednostavnije) 


Knjiženje se ne rješava na ruckat. Smatramo da knjiženje vrste računa 4 trbe biti po principu knjts7 i 5 (gotovina 

u PU) samo što se iz drugih tablica radi a ne kao za vrstu računa 1 Kataloška jer su drugačija konta 12* . 


Poštovani, 

Napravljena je izmjena kod unosa stavki u domumente MIPS-a. 

Za tip cijene P omogućeno je zadavanje iznosa.Vrijednost se izračuna kao vrijednost=(iznos x količina x 

cijena)/100 



Ovim su riiješene i isporučene sve točke zahtjeva . 



Poštovani, 


Radi se o dopunama zahtjeva 13080 koji je rješavan kroz KZ 40945 ( Riješen) a dopune kroz ovaj zahtjev . 


Možete zatvoriti ... 

Lp 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Ivan 


13124 



13.02.2013 12:18 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


13.02.2013 


Kod kreiranje faktura po zonskom cjeniku (POS usluga )javlja se greška 284 za uvjete sa slike: 



0









Poštovani, 

Do greške je došli jer se u ugovor 11003-R12-00315 dva puta evidentira isti podatak (usluga 24424). Potrebno je 

iz stavki ugovora izbrisati jedan podatak. 

S štovanjem 


Poštovani, 

Ranije smo poslali pojašnjenje vezano za grešku -284 : 

Do greške je došli jer se u ugovor 11003-R12-00315 dva puta evidentira isti podatak (usluga 24424). Potrebno je 

iz stavki ugovora izbrisati jedan podatak. 

Predlažemo : 

Spriječiti pojavu ove greške na način : kreirati unique index na lm_ugv_stav (protokol,usluga) 

Napomena : prije kreiranje unique index-a potrebno provjerit postoje li još neki ugovri u kojima je ista usluga 2 

put upisana : 

select protokol,usluga,count(*) bb from lm_ugv_stav 

group by 1,2 having count(*) >'1' into temp o ; 

-- za sve kombinacije protokol i usluga iz tablice o urediti tako da ostene samo 1 put usluga u ugovoru . 

-- unique index postaviti kad tablica o bude prazna tj. nema ugovra u kojima je ista usluga 2 ili više puta 

upisana . 

Molimo Vaš stav / suglasnost za zatvaranje zahtjev a- Riješen 


Poštovani, 





0











Klijent: 





Hitnost: 

Vrlo hitno 


Višnja 


13123 



12.02.2013 13:39 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


13.02.2013 


12.02.2013 

Kroz rucfak_fas Pregled i unos stavaka fakture javlja se greška: 


Ispravljena je greška koja se javljala kod ručnog unosa stavkei faktura. Greška je bila jer je polje Iznos bila 

premalo. 

Instalacija: sutra 13.02.2013 bit će dostupan novi WIN FAUS lib. 


Poštovani, 





0











Klijent: 





Hitnost: 

Vrlo hitno 


Višnja 


13122 



12.02.2013 12:36 

Upisao: 

Božo Mišeta 

Područje: 

LKROP 


13.02.2013 


Kroz osb_fk LISTA OSTVARENI SATI BODOVI za organizacijsku grupu IDGR2, plaća 01-2013 

preko F1 Ispis javlja se greška: 


Povećana su polja za iznose na osb listi pa se navedena greška više neće javljati. 

Preuzmite: krop lib od 13.02.2013. 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13121 



12.02.2013 10:17 

Upisao: 

Božo Mišeta 

Područje: 

LROBD 


15.02.2013 


Djelatnici, kod unosa artikala, ne upisuju ručno nazive artikala već ih kopiraju iz nekog dokumenta. 

Prilikom kopiranja se unesu i “čudni” znakovi. U Mipsu se, kod prijenosa, oni pretvaraju u "?" i javi im se 

greška. 

Molim Vas da nam ponudite rješenje kako da se spriječi unos takvih znakova. 

Za detalje pogledajte prilog - zapis_naziva_artikala.doc 



0









Poštovani, 

Na osnovu excel datoteke koju ste nam poslali, uočili smo da razmaci između riječi naziva artikla, sadrže 

neispravne znakove, koji su došli u excelu, a ti znakovi, nevidljiva za večinu aplikacija, prave smetnje u Mips 

bazi. 

Problem je što se neispravni znakovi za razmak nalaze u Excel-u. 

Potrebno je ispraviti podatke u Excelu prije copy past. (na način da razmak mora biti razmak, a ne "nekakav" 

znak) 

U LAUS-u se ovo ne može ispraviti. 

S štovanjem 


Poštovani, 

Analizom "čudnih" znakova utvrđeno je slijedeće: 

- čudni znakovi su excel nbsp (non braking space) 

- znak se na našim emulacijama interpretira ko "zvrčka" i uočljiva je na ekranu 

- znak se na Putty emulaciji interpretira kao obični blank, pa se na uoči na ekranu 

Prijedlog rješenja 

- ispraviti u samom Excelu (searc and replace tih znakova prije kopiranja) 

- ili 

- napraviti prilagodbu kod slanja podataka u MIPS da se očiste ovakvi znakovi (znači tvrdo kodiranje hex oznaka 

znakova koji se čiste) 

Rješenje koje je Ljubo predložio na sastabnku sa HP, 18.2. o postavljanju maske kojom će se omogućiti unos 

alfanumeričkih znakova nije izvedivo, jer se taj nbsp znak na emulaiciji u HP tretira kao obični blank, a ne kao 

specijalni znak. 

Molimo odluku o načinu rješavanja koji preferirate. 

LP 



Poštovanje, 

Zadatak za izmjeu slanja šifarrniak prema MISP sustavu je u obradi. Očekivana isporuka je do 11.3.2013. 




Prilikom prijenosa podataka iz lausa u mips hp_lm_jtr odnsono pri prijenosu naziva artikla hp_art_jtr 

prilagođeno je na način da se "čudni" znakovi izbrišu. 




Poštovani, 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13120 



11.02.2013 15:11 

Upisao: 

Božo Mišeta 

Područje: 

LTRAN 


14.02.2013 


Potrebno je omogućiti prijenos promjene dobavljača u mips_laus bazu. 

Primjer: 

Promjena dobavljača kod artikala se ne prenosi u mips_laus bazu. 

Primjerice 31.01.2013 smo promijenili šifru dobavljača kod svih artikala (D: Naša djeca) – tablica art_dob, 

sa 606994 NAŠA DJECA D.O.O. (nadređena 633979) na 633979 NAŠA DJECA D.O.O. i artikli su ostali 

na staroj šifri 606994 (u Mipsu). 



0









Napravljena je izmjena kod prijenosa artikala iz LAUSa u MIPS. Sada se prenosi i podatak o promjeni 

dobavljača. 


Instalacija: novi LAUS TRAN lib je već na internetu. 


create trigger "l1base".art_dob_del delete on "l1base".art_dob 


for each row 

( 

update "l1tran".l_mips_art set "l1tran".l_mips_art.azur = '1' 

where artikal = old.artikal 

); 

create trigger "l1base".art_dob_ins insert on "l1base".art_dob 


for each row 

( 


where artikal = new.artikal 

); 

create trigger "l1base".art_dob_upd update of artikal,analitika, 

barkod,bkatalog,tip,aktivnost on "l1base".art_dob referencing 

old as old new as new 

for each row 

when ((((((((old.artikal != new.artikal ) OR (old.analitika 

!= new.analitika ) ) OR (old.bkatalog != new.bkatalog ) ) OR (old.barkod 

!= new.barkod ) ) OR (old.bkatalog != new.bkatalog ) ) OR (old.tip 

!= new.tip ) ) OR (old.aktivnost != new.aktivnost ) ) ) 

( 


where artikal = old.artikal 

); 


Poštovani, 

Zahtjev zatvaramo uz vašu suglasnost - Riješen . 

Izmjena partnera se nije prenosila zato što nadređene šifre nisu imale unesen dodatni podatak UGK. 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


Poštovani! 



11.02.2013 15:03 

Upisao: 

Božo Mišeta 

Područje: 

LROBD 


11.02.2013 


U tablici asortiman_art se ne zapisuje asortiman u kojem je artikl prije bio (polje pre_asortiman je prazno) 

iako je npr. artikl 306034 već bio u prethodnom asortimanu br. 000005. 

veza projekt e-zahtjevnica 


Poštovana, 

poslali ste nam netočne podatke. Asortiman broj 000006 vrijedi od 12/02/2013 (a ne od 01/02/2013), pa prema 

tome nije mogao ni upisati 

ništa u asortiman broj 000005 koji vrijedi od 01/02/2013 do 10/02/2013, a asortiman broj 000005 nije ništa 

mogao upisati u asortiman broj 00001 koji vrijedi od 22/01/2013 do 29/01/2013. 

S štovanjem 


Poštovani, 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Ivan 


13119 



11.02.2013 11:15 

Upisao: 

Božo Mišeta 

Područje: 

LFINK 


11.02.2013 


Kod rasknjižavanja uplata po dospijeću preko objekta bss_knj_jf program nije zatvorio sve stavke. 

Nalog izvoda: 13Z50009 

Nalog izvoda: 13E50001 

Evo jednog primjera: 

--izvod 

select * from izvod_ziro where rnpri='HR4723900011500005667' and dat_izv='25.01.2013' and 

pozbo='011000210-20121201-7'; 

-- proknjiženi izvod 

select * from arhivk where nalogk='13Z50009' and analitika='T000272'; 

--rasknjižene uplate 

select * from arhivk where nalogk='13E50001' and analitika='T000272'; 

--kartica kupca 

select * from arhivk where analitika='T000272'; 

select * from arhivk where (datumdos='28.01.2013' or datumdok='25.01.2013') and analitika='T000272'; 



0









Poštovani , 

Zatvorene stavke na cijeloj kartici 120710 , analitika A T00272 su 3 stavke : 

46300-012-00089 46300 DIG 31/12/12 28/01/13 28 12I50002 31/12/12 1000210 - 19.99 0.00 

19.99 D 

46300-012-00457 46300 DIG 31/12/12 28/01/13 28 12I50004 31/12/12 1000210201 1.00 0.00 

20.99 D 

46300 UPL 25/01/13 13Z50009 25/01/13 1000210 0.00 

20.99 0.00 P 

----------------------------------------------------------------------------------------------------------------------------------- 

Ukupno za konto: 120710 POTRAŽIVANJA PO OSNOVI UGOVORA ZA EVO-TV 

20.99 20.99 0.00 

Sve su zatvorene RUČNO sa istim brojem zatvaranja : 

Broj zatvaranja 3868508___ Datum zatvaranja 28/01/2013 Obračunate kamate N 

Broj obračuna kamata 

Konto 120710 POTRAŽIVANJA PO OSNOVI UGOVORA ZA EVO-TV 

Nivo knjiženja 46300 ODJEL ZA OPERATIVNE POSLOVE 

Analitika A T000272 JAGODA URODA 

VD. Broj dokumenta Datum dok. Datum dos. Opis Iznos kuna 

--- ----------------- ---------- ---------- ------------- ---------------- - 

DIG 46300-012-00089 31/12/2012 28/01/2013 1000210 - Rat 19.99 D 

DIG 46300-012-00457 31/12/2012 28/01/2013 1000210201212 1.00 D 

UPL 25/01/2013 1000210 20.99 P 

Koja neispiunjena očekivanja su izražena rečenicom : 

Kod rasknjižavanja uplata po dospijeću preko objekta bss_knj_jf program nije zatvorio sve stavke. ? 

Program kod rasknjižavanja uplata prvo proknjiži storno uplate (vi ste ju obrisali ili uopće niste knjižili ) . 

Onda treba proknjižiti stavke rasknjiženja sa brojem računa na kojeg se odnosi po kriteriju najmanjg datuma 

dospjeća . 

( i te stavke ste obrisali ili uopće niste knjižili ) 

Ako je UPL iz izvoda zatvorena ručno sa 1 ili više eračuna , onda se ona NEĆE rasknjižavati jer je već povezana 

(zatvorena) s računima na koje se odnosi . 

Preporuka: razvežite stvake zatvorene brojem zatvaranja 3868508. 

Pustite rasknjižavanje uplata . program bi trebao generirati 3 stavke : 

UPL 25/01/2013 1000210 -20.99 P 

UPL 46300-012-00089 25/01/2013 1000210 - Rat 19.99 P 

UPL 46300-012-00457 25/01/2013 1000210201212 1.00 P 

Kod zatvaranja naloga u kojeg su knjižene program će napraviti automatsko zatvaranje i to sa 2 broja 

zatvaranja : 

1.jail : 

DIG 46300-012-00089 31/12/2012 28/01/2013 1000210 - Rat 19.99 D 

UPL 46300-012-00089 25/01/2013 1000210 - Rat 19.99 P 

2.jail : 

DIG 46300-012-00457 31/12/2012 28/01/2013 1000210201212 1.00 D 

UPL 46300-012-00457 25/01/2013 1000210201212 1.00 P 

a ručno se zatvarju sa 3.jail : 

UPL 25/01/2013 1000210 20.99 P 

UPL 25/01/2013 1000210 -20.99 P 



0









Poštovani, 

Na laus@laustest analizirano : 

vdok nalogk red idin dp protokol 

UPL 13Z50009 21 20.99 P -- nema protokola jer se uplata u izvodu tako knjiži 

UPL 13E50001 25 -20.99 P -- nema protokola jer je ovo storno gornje stavke bez protokola 

UPL 13E50001 26 19.99 P 4630001200089 - ima protokol i to je ok 

UPL 13E50001 27 1.00 P -- nema protokol i to NIJE ok jer treba biti protokol= 4630001200457 

nalogk red idin protokol opis 

13E50001 27 1.00 1000210 - Rata 2 *** 

13E50001 26 19.99 4630001200089 1000210 - Rata 1 * 

13E50001 25 -20.99 1000210 

13Z50009 21 20.99 1000210 

ZAKLJUČAK : 

* Program je dobro odabrao opis,protokol i iznos 1.stavke rasknjiženja na račun (red=26) po kriteriju najmanjeg 

dospjeća 

*** Program je dobro odabrao iznos 2.stavke rasknjiženja na račun (red=27) 

Pogrešan je protokol (prazno) a treba biti 4630001200457 jer taj račun ima najmanje dospjeće 28.01.2013 

Pogrešan je opis (1000210 - Rata 2) a treba biti 1000210 ili kao u *** 

protokol vdok idin datumdok datumdos opis 

4630001200089 DIG 19.99 31/12/2012 28/01/2013 1000210 - Rata 1 * 

4630001200457 DIG 1.00 31/12/2012 28/01/2013 100021020121201 *** 

4630001200089 DIG 19.99 31/12/2012 20/02/2013 1000210 - Rata 2 

..... 

Program nije zatvorio nijednu stavku jer : 

* saldo po računu 4630001200089 nije 0 jer je tek plaćena 1.rata . Može se ručno zatvoriti rata 1 i uplata za ratu 

1 

*** knjižena uplata bez protokola pa se ne može zatvoriti automatski nego ručno. 

PRIJEDLOG POBOLJŠANJA :Automatsko zatvaranje rata sa uplatama : 

- raditi preko zatiz_jf ZATVARANJE STAVKI PO IZNOSU po uvjetu : 

Kontrola na opis N Opis smije biti prazan D 

- ispraviti greške u stavci *** : radi se 


Na objektu bss_knj_jf Ispravljena je greška kod rasknjižavanja stavki po datumu dospijeća. 

Novi LAUS FINK liba je na internetu. 


Poštovani, 

Čekamo HP da odluči : 

doraditi postojeće zatiz_jf ZATVARANJE STAVKI PO IZNOSU pa onda koristit i na ostalim kontima a ne 

samo na DTVKK 

ili 

raditi novo (tipka na bss_knj_jf ) kako je prvotno bilo potrebno . 



0









Poštovani , 

Dakle, u konačnici će na isti način raditi Zatvori na bss_knj_jf kao i Zatvori na zatiz_jf osim što će kod 

bss_knj_jf biti dodatni uvjet za nalog . 

NAPOMENA: 

1) Kroz postojeći objekt 'zatiz_jf ZATVARANJE STAVKI PO IZNOSU' omogućiti ćemo : 

- zatvaranje stavki suprotnih iznosa (saldo=0) a jednakih opisa : 

stavke koja je proknjižena u iz izvoda žira (Z5 nalog) : + iznos P 

sa protustavkom koja je rasknjižena (E5) malog : - iznos P 

jer se dosad nisu zatvarale stavke sa istim opisom zato što im je iznos različit tj. suprotan iako je saldo =0 :napr 

100 uplata i -100 storno uplate 

- dodatno opciju : Kontrola na protokol , default D 

- dodatno opciju : Protokol može biti prazan , default D 

Sad postoji za Opis pcija : 

Kontrola na opis N----> postaviti default=D ? 

Opis smije biti prazan D 

Kroz ovaj objekt bi se pustilo zatvaranje otvorenih stavaka za cijeli konto. 

Pitanje : Treba li onda raditi zatvaranje po istim principima na bss_knj_jf ali samo za 1 nalog ? 

----- odnosi se na Zahtjev pod 2) : 

Kroz objekt 'bss_knj_jf Rasknjižavnje i zatvaranje uplata po dospijeću' omogućiti automatsko zatvaranje 

stavaka kod zatvaranja naloga (potrebno je zatvoriti rasknjižene uplate sa potraživanjima te izvod žira iz Z5 

naloga sa protustavkom u – iz E5 naloga). 

Kroz ovaj objekt zatvarala bi se potraživanja na kontu samo sa rasknjiženim uplatama iz odabranog E5 naloga. 

Ako treba radit pod 2) može se napraviti ovako : 

- na posebnoj tipki na bss_knj_jf Rasknjižavnje i zatvaranje uplata po dospijeću omogućiti zatvaranje neovisno 

o statusu naloga E5 . 

- kod zatvaranja naloga koje se radi na nalozi_jf Knjigovodstveni nalozi (F4 Zatvori) ne kanimo raditi promjene . 


Poštovani, 

Omogućeno je automatsko zatvaranje stavki po sumarnom iznosu gdje je saldo nula za ključ : 

orgj,konto,vanalitika,analitka,opis i dugpot 

Ovakvo zatvaranje radi se na : 

zatiz_jf ZATVARANJE STAVKI PO IZNOSU 

ako se postavi : 

Kontrola na opis D (D/N) 

Opis smije biti prazan N (D/N) 

Pogodno za zatvaranje stavki sa vdok=UPL na kontu 120710 na istoj strani knjiženja : 

1. stavka izvoda žira (uplata) + iznos P (nalog ZR neraspoređena uplata ) 

2. storno stavka stavke 1. - iznos P (nalog rasknjižavanja uplata po računima) 


U rješavanju je : 

-- rasknjižavanje uplata po prioritetu : dospjeće (već tako radi) još i po vrsti dokumenta (dodatni kriterij) 

-- raspodjela uplata po računima za slučaj 2 računa po istom ugovru palćena isti dan 



0









Omogućeno je zatvaranje uplata unutar istog datuma dospjeća po redosljedu: 

1. kamate (KIZ) 

2. račun za STB (DIG) 

3. račun za uslugu (DIG,BSS) 

Obavijestiti korisnika o preuzimanju novog LAUS FINK liba u srijedu 3.4.2013 



0









Poštovani, 

Vezano uz ovaj zahtjev status je slijedeći : 

slučaj1 :Na laus@laustest : 

* Program je dobro odabrao opis,protokol i iznos 1.stavke rasknjiženja na račun (red=26) po kriteriju najmanjeg 

dospjeća 

*** Program je dobro odabrao iznos 2.stavke rasknjiženja na račun (red=27) 

Pogrešan je protokol (prazno) a treba biti 4630001200457 jer taj račun ima najmanje dospjeće 28.01.2013 

Pogrešan je opis (1000210 - Rata 2) a treba biti 1000210 ili kao u *** 

.....riješeno 

slučaj 2 : 

Rasknjižavanje sve na jedan račun 

za slučaj kad su 2 uplate na isti ugovor u istom izvodu 

napravi dobro knjiženje izvoda 

napravi dobro minusnu stavku kod rasknjižavanja po dospjeću 

ne napravi dobro knjiženje na račune jer obje stavke/uplate proknjiži na isti račun (protokol) a treba rasporediti 

uplatu na oba računa . 

Inače, po 1. je u pretplati (višak uplata) a po drugom je dužan (nema uplate) a stvrno stanje je da je plaćen i 1. i 

2. račun tj nema ni pretplate niti duga . 

----- nije još riješeno 

slučaj 3 : 

ne zatvaraju se neraspoređena stavka/uplata u izvodu i njen storno 

-- riješeno 

zatiz_jf ZATVARANJE STAVKI PO IZNOSU Izmjenjeno je zatvaranje stavki po iznosu na način da je dodano 

i zatvaranje stavki po sumarnom iznosu gdje je saldo nula za ključ orgj,konto,vanalitika,analitka,opis i dugpot. 

slučaj 4 : 

Prema obradi 5 KZ-a treba izmmijeniti : 

bss_knj_jf Rasknjižavnje i zatvaranje uplata po dospijeću 

Zatvaranje prema dospijeću treba realizirati prema zapisniku kako je treženo: 

a) Stavke će se zatvarati za uplate kojima je poziv na broj 01-brugo (BSS broj ugovora) prema sljedećoj 

hijerarhiji: 

· Ugovor 

o datum dospijeća 

§ vrsta dokumenta (prema prioritetu) 

1. KAMATE (KIZ) 

2. račun za STB (DIG) 

3. račun za uslugu (DIG,BSS) 

Dakle, ako imaju isti ugovor i dospijeće računi za STB i račun za uslugu uplatom se prvo zatvara račun za STB 

(rata) a ako ostane 'nepotrošena' uplata ostatk se proknjiži na račun za uslugu . 

Sad sad se ne uvažava vrsta dokumenta . 

--- riješeno 

Unutar istog datuma dospjeća sad se uvažava i vrsta dokumenta tj. način plaćanja jer račun za stb na rate i neki 

računi za usluge imaju isti vdok DIG : 

Readoslijed rasknjižavanja uplate je : po datumu dospijeća ,a unutar istog datuma dospijeća po prioritetu : 

1- KIZ, 2 - STB na rate, 3- ostalo tj. računi za usluge DIG+BSS 



0









Poštovani, 

U ovom zahtjevu neriješen je ostao slučaj 2 : 

Rasknjižavanje sve na jedan račun za slučaj kad su 2 uplate na isti ugovor u istom izvodu 

Svi ostali slučajevi navedeni u ovom zahtjevu su riješeni. 

Predlažem zatvaranje ovog zahtjeva - Riješen . 

Neriješeni slučaj 2 rješavati kroz zahtjev HP broj 13321 : 

poslali ste primjere ( slučaj 2 iz 13119 i ovdje se javlja pod 3) Zagorec u zapisniku sa sastanka 16.4.2013 ) 



Poštovani, 



Napomena: rasknjižavanje uplata po dospijeću rješava se dalje kroz 13321 i 13413 . 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Renata 




11.02.2013 10:56 

Upisao: 

Sven Krile 

Područje: 

LROBD 

Na izborniku ME1247 Robno i materijalno knjigovodstvo u HP 

potrebno je izmjeniti imena sljedećih objekata: 

hp_knj_jd PRIPREMA DOK. ZA KNJIŽENJE U GL. KNJIGU 


11.02.2013 

treba biti PRIPREMA DOKUMENATA (DEPO) ZA KNJIŽENJE U GL.KNJ 

hp_Pknj_jd PRIPREME DOKUMENATA (PU) ZA KNJIŽENJE U GL.KN 

treba biti PRIPREMA DOKUMENATA (PU) ZA KNJIŽENJE U GL.KNJ 

uputaHP_jd UPUTA ZA KNJIŽ. SKLADIŠNIH DOK. U GL. KNJIGU 

treba biti UPUTE ZA KNJIŽENJE DOKUMENATA (DEPO) U GL.KNJ 

uputaPHP_jd UPUTA ZA KNJIŽ. ROBNIH DOK. U GL. KNJIGU 

treba biti UPUTE ZA KNJIŽENJE DOKUMENATA (PU) U GL.KNJ 




0









Poštovani, od sutra preuzeti menu-e i objekte 

Na izborniku ME1247 Robno i materijalno knjigovodstvo u HP 

napravljena je tražena izmjena sljedećih objekata: 

hp_knj_jd PRIPREMA DOK. ZA KNJIŽENJE U GL. KNJIGU 

treba biti PRIPREMA DOKUMENATA (DEPO) ZA KNJIŽENJE U GL.KNJ 

hp_Pknj_jd PRIPREME DOKUMENATA (PU) ZA KNJIŽENJE U GL.KN 

treba biti PRIPREMA DOKUMENATA (PU) ZA KNJIŽENJE U GL.KNJ 

uputaHP_jd UPUTA ZA KNJIŽ. SKLADIŠNIH DOK. U GL. KNJIGU 

treba biti UPUTE ZA KNJIŽENJE DOKUMENATA (DEPO) U GL.KNJ 

uputaPHP_jd UPUTA ZA KNJIŽ. ROBNIH DOK. U GL. KNJIGU 

treba biti UPUTE ZA KNJIŽENJE DOKUMENATA (PU) U GL.KNJ 

S štovanjem 


Poštovani, 

možemo li zatvoriti ovaj zahtjev? 

S štovanjem 


Poštovani, 

Može li se zahtjev zatvoriti ? 

NApomena : zahtjev nema službeni HP broj ali su izmjene naziva na meniju napravljene (11.2.2013) 







0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13118 



11.02.2013 10:37 

Upisao: 

Božo Mišeta 

Područje: 

WINTRAN 


13.02.2013 


Prilikom obračuna prodaje komisijske robe i stanja zaliha komitenta 694087 OBRT TISAK MORE nisu 

štimala stanja zaliha. 

Utvrdila sam da kod PU 10000 Zagreb nisu dobro prenesene završna stanja od 31.12.2012. kao početna 

stanja 01.01.2013. za šifre : 

313135 ZS 1 PS 0 

318298 ZS 1 PS 0 

318299 ZS 5 PS 4 

Molim da se utvrdi zašto je to tako i ispravi greška. 



0









Poštovani, 

Stanje na datum 31/12/2012 je rezultat prezbrajnaja počentog stanja na 01/01/2012 sa prometom u 2012 godini 

pa tako nije moguće usporediti sa početnim stanjem na 01/01/2013 odnosno ustvrditi grešku koja ja 

nastala.Pošto program za računaja stanja u Laus-u radi već duže vrijeme potrebno se kozultirati sa MIPS-om 

oko početnog stanja za 2013 godinu. 

S štovanjem 


Poštovani, 

stanje 31.12.2012. (zbroj promjena u 2012 ) ne slaže sa početnnim stanjem na 01.01.2013 (poseban slog PS ) 

Razlog : 

prikaz stanja na 31.12.2012 na listi je isti kao koli_ps u bazi na datum 01/01/2013 tj slažu se završno i početno 

stanje . 

Prikaz stanja na 31.12.2012 na listi i prikaz stanja Ostatak od prošlog razdoblja 01/01/2013 se ne slažu jer u 

Ostatak od prošlog razdoblja , osim početnog stanja ulaze i sve ostale evidentirane količine na datum 

01.01.2013 ( u primjeru se radi o prodaji koli_rprb ) 

( U PRILOGU ) 

Smatramo adaptivnim održavanjem je se ne radi o greški nego načinu rada programa kakav je tražen i već 

dugo u primjeni . 

Mi ne smijemo mijenjati podatke u bazi koje MIPS pošalje niti smijemo mijenjati program u odnosu na postojeći 

način rada bez da pošaljete zahtjev za izmjenu . 

Dakle, po postojećem načinu rada problem su (ako postoje) slučajevi za koje se stanje na 31.12.2012 ne slaže 

sa upisanim u hp1.koli_ps na datum 01/01/2013. 



Poštovani, 

Zahtjev zatvaramo uz vašu suglasnost - Riješen, Adaptivno 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Ivan 


13117 



11.02.2013 08:11 

Upisao: 

Božo Mišeta 

Područje: 

LFINK 


11.02.2013 


Kod pripreme podataka za prijenos preko objekta: bss_kart_jf PRIJENOS KARTICE KUPCA LAUS - BSS 

program nije popunio polje brugo za slijedeće korisnike: 

select distinct analitika,idpart from bss_priprema where origbr='STB' and brugo is null and date 

(datum_pripreme)='08.02.2013'; 

analitikaidpart 

T00045144300 

T00058547578 

T00092649837 

T00107550373 

T00120251153 

T00121151170 

T00125750825 

T00179842484 

T00197152014 

T00225451306 

T00244452698 

T00244952836 

T00246951987 

T00247352365 

T00252852634 

T00261252808 

T00403752954 

To su korisnici koji imaju više od jedne fakture za STB na rate. 

Potrebno je za te korisnike u LAUS i BSS_LAUS bazi u tablicama bss_priprema i bss kartica popuniti polje 

brugo. 

Također potrebno je otkloniti tu grešku sa objekta bss_kart_jf 



0









Poštovani, 

izvedeni sql-ovi : bss_brugo i bss_brugo_k kojima se u brugo upisao bss broj ugovora za kojeg je vezan 

račun . 

Veza računa ( bss_priprema.brdok ) i originalnog bss broja ugovora (bss_priprema.brugo ) nađe se preko 

lm_usl_fak tablice u kojoj je veza računa ( lm_usl_fak.protokol ) i laus broja ugovora ( lm_usl_fak.ugovor_laus) . 

Onda se preko protokol tablice dođe do originalnog broja ugovora (protokol.boriginal) . 

Programske izmjene kod punjenja bss_priprema tablice za stavke računa za STB na rate su u tijeku . 

Molimo povratne informacije vezano za upis brugo na produkcijskoj laus i DBAZA bazi . 


Poštovani, 

Na objektu bss_rac_jf Prijenos podataka BSS -> LAUS kod evidencija računa izmjenjena je vrsta dokumenta sa 

DIG u BSS. 

Naći plaćanja vezan sa fiskalizacijom postavljen je na T. 

Preuzeti LAUS FINK liba u utorak 12.2.2013. 

S štovanjem 


Poštovani, 


----------------------------------------------------------------------------------------- 





Na objektu bss_rac_jf Prijenos podataka BSS -> LAUS kod evidencija računa izmjenjena je vrsta dokumenta sa 

DIG u BSS. 

Naći plaćanja vezan sa fiskalizacijom postavljen je na T. 

Preuzeti LAUS FINK liba u utorak 12.2.2013. 


Poštovani, 




0











Klijent: 





prijenos računa iz BSS 

Hitnost: 

Vrlo hitno 


ivan 


13115 



08.02.2013 16:41 

Upisao: 

Dajana Lekić 

Područje: 

LFINK 


11.02.2013 


Prilikom prijenosa faktura za uslugu evoTV iz Billinga u Laus, fakture je u Lausu potrebno evidentirati na 

novootvorenu vrstu dokumenta BSS. 

Što znači da će fakture za STB na rate biti evidentirane kao I do sada na vrstu dokumenta DIG, a fakture 

uslugu na vrstu dokumenta BSS. 

S evidencijom faktura na vrstu dokumenta BSS treba započeti odmah s fakturama za obračunsko razdoblje 

od 01.01. do 31.01.2013. 



0









Poštovani, 

Za novi vdok=BSS potrebno je zadati sve kao što je zadano za vdok=DIG : 

vdokkon_ff VEZA KONTO-DOKUMENT 

protup_ff UPUTE ZA EVIDENTIRANJE DOKUMENATA 

NApomena : vezati DIG i BSS za konto poreza 240* jer sad nisu vezani 

Provjerite sa BSS-om hoće li biti problema kod preuzimanja kartice kupca ako se javi vrdok=BSS 


S evidencijom faktura na vrstu dokumenta BSS treba započeti odmah s fakturama za obračunsko razdoblje od 

01.01. do 31.01.2013. 


--------postoje samo računi koje smo već preuzeli i koji se odnose na 2012. godinu . 

Ne dobije se niti jedan račun koji se odnosi na razdoblje 2013-01 kad se izvede : 

select protokol,datumdok,godina,status,vdok,datum from protokol 

where protokol in (select protokol from bss_vezar) 

------ ne postoje računi koje nismo preuzeli 

select * from bss_laus@mips_laus:bss_zaglavlje 

where brdok not in (select brdok from bss_vezar) 

Zasad se nema što mijenjati na bazi. 

Ukoliko programske izmjene ne budu isporučene prije preuzimanja računa iz BSS-a za obračunsko razdoblje od 

01.01. do 31.01.2013. potrebno je preuzeti račune kao što se i dosad radilo te naknadno izvesti : 

update protokol set vdok='BSS' 

where protokol in (select protokol from bss_vezar) and godina='13' ; 

pod uvjetom da je značenje navoda 'za obračunsko razdoblje od 01.01. do 31.01.2013. ' zapravo računi u 

2013.godini . 



0









Poštovani, 

Na objektu knjiženja knjdig.jas se sada knjiže i podaci s vrstom dokumenta BSS čime je riješeno dolje navedeno 

pod 2. 

NAPOMENA :Za knjiženje računa za STB na rate koristiti knjstb.jas 


Instalacija: sutra 15.02.2013 će bit dostupan novi WIN FAUS lib. 

Ranije riješeno i isporučeno pod 1. i 3. : 

1. U prijenosu računa iz BSSa u LAUS automatski dodijeliti vrstu dokumenta BSS računima za uslugu 

2. Preko objekta knjdig.jas KNJIŽENJE DIGITALNE TV omogućiti knjiženje vrsta dokumenta BSS umjesto 

DIG 

3. Priprema i slanje kartice kupca iz LAUSa u BSS tih računa 

Vezano za zahtjevano : 

S evidencijom faktura na vrstu dokumenta BSS treba započeti odmah s fakturama za obračunsko razdoblje od 

01.01. do 31.01.2013. 

potrebno je za fakture iz 2013 godine tj račune sa protokol.godina=13 koje su u bss_vezar (preuzeti iz bss-a ) 

priomijeniti 

-- protokol.vdok = BSS 

-- lm_kat_stav.indikator=BSS 

Molimo povbratne informacije / suglasnost za zatvaranje zahtjeva - Riješen 


Poštovani, 




0











Klijent: 



Pitanje 


Prijenos ERV 

Hitnost: 

Vrlo hitno 


višnja 


13116 

Riješen 


08.02.2013 14:31 

Upisao: 

Dajana Lekić 

Područje: 

LKEVP 


08.02.2013 


Prijenosom ERV-a u obračun plaće za 01-2013 za radnike koji rade u organizacijskoj jedinici 12077 

(dodatni podatak ZRA) nije se prenio dodatak za zračenje K08. 

Molim hitnu izmjenu. 


Poštovani, 

nije ustanovljen razlog zašto se ne bi ažurirao dodatak na zračenje K08. 

Korisnik JBABICY koji je puštao prijenos ima dozvolu na PLZG a orgj 12077, koja ima dodani podatak ZRA 

pripada tom središtu. 

Provjerom prijenosa na testnoj bazi nismo uspjeli simulirati grešku. 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Ivan 


13114 



07.02.2013 15:46 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


15.02.2013 







Poštovani, 

Ovaj zahtjev zatvaramo - rješava se po zahtjevu s ispravnim HP brojem kojeg je Ivan danas poslao : 13141 


Subject: zahtjev 13141 

Date: Tue, 19 Feb 2013 10:15:23 +0000 

From: Ivan Poldrugač 

To: support@laus.cc , dajana.lekic@laus.cc 

CC: Odjel za implementaciju ERP rješenja 

Dajana, 

Evo ponovno zahtjeva za doradom konrola god generiranja faktura po zonskom cjeniku. 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Ivan 


13114 



07.02.2013 15:39 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


15.02.2013 


Na objektu rucfak.jas Pregled i ručni unos faktura prilikom izrade faktura (FAP, FAH, FAO, OBN, FAS) za 

koje je uvjet Ugovor u kojem su evidentirani popusti na uslugama, treba se primijeniti obračun,iskazivanje i 

ispis popusta na računu: 

-Za komercijalni rabat 

-Za hpekspres rabat i posebne vrste rabata (pojedinačno za kupca) 

Za ugovorni rabat - zonski rabat 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Ivan 


Prilog: računi sa testnog win lausa 

13112 

Riješen 


07.02.2013 15:36 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


08.02.2013 


Račun broj 24090-013-00006 napravljen je prema ugovoru broj 24090-R13-00034., izrađen preko Ručnog 

unosa radnih naloga – rucnal.jas i generiran u objektu Fakturiranje hpekspres usluga. 

Na ispisu računa preko objekta fakis_fas Ispis faktura – mjesečni rabat je iskazan lijevo od zbirnog 

obračuna. U obračunu nema rabata (privitak račun pod 1) 

Na ispisu računa preko objekta Pregled i ručni unos faktura, ispis računa ne radi dobro jer oduzima porez 

od obračunatih iznosa (količina * upisana neto jedinična cijena), ali je na tom računu iskazan mjesečni rabat 

lijevo od zbirnog i u zbirnom obračunu 



0









Poštovani, 

molimo pošaljite ispis računa iz zahtjeva kako bismo jasnije idjeli o čemu se radi 


Poštovani, 

Prilog koji je poslan uz zahtjev ne odnosi se na ispis računa ( i sad šaljemo u prilogu ove obrade) 

Molimo pošaljite ispis računa iz zahtjeva kako bismo jasnije idjeli o čemu se radi . 

Ukoliko je zahtjev u međuvremenu riješen kroz druge zahtjeve , molimo suglasnost za zatvaranje zahtjeva - 

Riješen 

--------------------- 






Na objektu za ručni unos faktura omogućeno je generiranje i neto fakture. 

Novi WIN FAUS je već preuzet od strane HP-a. 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Višnja 


13110 



07.02.2013 12:19 

Upisao: 

Božo Mišeta 

Područje: 

LKEVP 


15.02.2013 


Potrebno je provjeriti ispravnost ugrađene kontrole da se u istom danu NE MOGU upisati dvije vrste 

odsutnosti jer je evidentičar na dan 1.1.2013 radnici 20639 mogao za isti datum upisati 8 sati I-BL i 8 sati I- 

BO. 


Provjerene su kontrole po svim ekranima za unos odsutnosti. 

Moguće su bile evidencije na isti datum u slučaju kombinacije pojedinačnog unosa na jedan datum a zatim od 

istog tog datuma masovni unos druge vrste odsutnosti. Također je bilo moguće unijeti više dozvoljenih vrsta 

odsutnosti preko ekrana za unos koji se pozove s pregleda podataka po radniku. 

U obje kombinacije je dodana ista kontrola. 

Preuzmite lib: kevp 



0











Klijent: 





ERV 

Hitnost: 

Vrlo hitno 


Višnja 


13111 

Riješen 


07.02.2013 12:17 

Upisao: 

Božo Mišeta 

Područje: 

LKEVP 


15.02.2013 


30.04.2013 

Prijenosom ERV-a u obračun plaće za 01/2013 opet nam se u slučaju dvojice vozača pojavljuje na kontroli 

„ponovne provjere radnih sati“ višak i manjak sati, 

unatoč ispravnom prijenosu i završnoj kontroli na kojoj se nitko nije pojavio. 

-36061 Bezina Ante – u ERV-u u redu, satovi izjednačeni na 184; na unosu primanja ima 156 sati 

-39385 Vidović Ivan – u ERV-u na 184, na unosu 190 sati 

Potrebno je izvršiti ispravak. 


Poštovani, 

ispravljene su navedene kombinacije prijenosa. 

kevp će biti dostupan 04/05/2013. 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Višnja 


13109 

Riješen 


07.02.2013 10:58 

Upisao: 

Božo Mišeta 

Područje: 

LKEVP 


15.02.2013 


Kroz odl40_jke ODLUKA O RASPOREDU I TRAJANJU GO na odluci odl40p_rke.txt potrebno je u dijelu 

Odluku dostaviti izmijeniti: 

2. Odjelu kadrovskih poslova 

u 

2. Odjelu kadrovske operative 


Poštovani, 

izmijenjen je navedeni tekst. 

kevp je dostupan od 08/02/2013. 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


Poštovani, 

13108 


na obračunima i stanjima zaliha bi trebalo napraviti korekcije: 


07.02.2013 10:42 

Upisao: 

Božo Mišeta 

Područje: 

WINTRAN 


11.02.2013 


1.Obračun - nije prikazana rekapitulacija za PDV 5%, a na SVEUKUPNO je uredno iskazan, 

2.Stanje zaliha – u stanjima kupi i zalihe artikala čije je stanje 0. 

molim za ispravak. 



0









Poštovaani, 

U zahtjevu je konstatirano : 

2.Stanje zaliha – u stanjima kupi i zalihe artikala čije je stanje 0. 

bez da je precizno naveden 1 ili više kriterija po kojima bi se iz stanja zaliha izbacivali artikli . 

Molimo odaberite neki od navedenih kriterija ili sami opište željeni kriterij po kojem artikal ne ulazi u stanje 

zaliha : 

a) ako je početno i završno stanje 0 

b) ako je početno i završno stanje 0 ali i prodaja je 0 

c) ako su svi stupci količina na stanju zaliha jednaki 0 : 

Stanje na početku razdoblja 

Primljeno od dobavljača 

Primljeno / nadoslano izvan depo-a 

Prodano 

Vraćeno dobavljaču 

Ukupno stanje zaliha 

d) zadovoljeno sve kao pod c) i još Ukupna vrijednost MPC = 0 

Također, odlučite da li se po odabranom kriteriju korigira samo stanje zaliha za dobavljača ili i stanje zaliha - 

radna verzija 


Poštovani, 

Na listi obračune komisisone robe za komitenta dodano je ukupno za poreznu stopu od 5 %. 

Na listama stanje zaliha radna i komitenta dorađena je na način da se ne ispisuju artikli kojima su svi stupci 

količina na stanju zaliha jednaki 0 : 

Stanje na početku razdoblja 

Primljeno od dobavljača 

Primljeno / nadoslano izvan depo-a 

Prodano 

Vraćeno dobavljaču 

Ukupno stanje zaliha 

te im je još i Ukupna vrijednost MPC = 0 






0











Klijent: 





Hitnost: 

Vrlo hitno 


Višnja 


13107 



07.02.2013 09:57 

Upisao: 

Božo Mišeta 

Područje: 

LFINK 


15.02.2013 





2.Uplate (transakcija 20) s oznakom poziv na broj odobrenja 

00 760111 – oznaka poštanskog ureda – DDMMGG knjižiti na konto 122300, nivo poštanskog ureda 

Divizija Mreža, u opis knjižiti poziv na broj odobrenja 

3.Isplate (transakcija 10) s oznakom poziv na broj zaduženja 

00 120709 – oznaka poštanskog ureda – DDMMGG, knjižiti na konto 

120709, nivo 00000, u opis knjižiti poziv na broj zaduženja 


Poštovani , 

Zaprimili smo potpuno isti zahr+tjev HP broj 13143 . 

Molimo suglasnost za zatvaranje ovog zahtjeva - Zatvoreno /Dupli zahtjev 


Poštovani , 

Zahtjev zatvaramo uz vašu suglasnost - Zatvoreno /Dupli zahtjev 

(veza zahtjev HP broj 13143 ) . 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Višnja 


13106 



07.02.2013 09:50 

Upisao: 

Božo Mišeta 

Područje: 

LKEVP 


15.02.2013 


01.06.2013 

Prijenosom ERV-a u obračun plaće za 01/2013 pogrešan je prijenos za radnika 40827, koji u 01-2013 ima 

promijenu radnog vremena sa nepunog na puno. Radnik je do 3.1.2013 radio nepuno radno vrijeme – 5 

sati, a od 4.1.2013 je na punom radnom vremenu – 8 sati. 

Evidencija dolazaka i odlazaka za radnika je provedena ispravno, ali Pregled rada na dan prikazuje 

pogrešan fond sati, 115 (treba 175 sati) i tako je preneseno u obračun: 

Potrebno je izvršiti ispravak 


Poštovani, 

ispravljen je izračun mjesečnog fonda sati za radnike koji tijekom mjeseca po rješenjima promijenu radno vrijeme 

s Nepunog na Puno i obratno. 

Iz tog razloga navedenom radniku nisu bili dobro generirani sati preraspodjele za tekući i sljedeći mjesec 

(PRIJ/DONO). 

Preuzmite kevp lib koji će biti dostupan 21/05/2013. 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13105 

Riješen 


07.02.2013 09:32 

Upisao: 

Božo Mišeta 

Područje: 

LFINK 


08.02.2013 


-međunarodne uputnice 

Kako su izbrisane stavke iz knjigovodstvenog naloga za datum 30.01.2013, molim Vas da nam pošaljete 

što treba promijeniti u tablicama eg_zag i eg_upl, kako bi se transakcije mogle evidentirati i upariti. 


Buduće je došlo do brisanja knjigovodstvenih stavki koje su već evidentirane i uparene potrebno je samo 

izmjeniti status stavki kroz bazu pomoću dole navedenih SQLova i to za tablicu eg_zag iz statusa K u status E te 

za tablicu eg_upl iz statusa K u status U. Nakon toga na objektu eg_knj_jf će se ponovno pojaviti stavke za 

knjiženje za datum plaćanja 30.1.2013. 

Potrebno je izvesti sljedeće SQLove: 

update eg_zag set status = 'E' 

where datum_pla = '30/01/2013' 

and status = 'K'; 

update eg_upl set status = 'U' 

where datum_pla = '30/01/2013' 

and status = 'K'; 



0











Klijent: 





pna_kot_jf 

Hitnost: 

Vrlo hitno 


višnja 


13103 

Riješen 


06.02.2013 13:26 

Upisao: 

Dajana Lekić 

Područje: 

LFINK 


07.02.2013 


Potrebno je kroz pna_kot_jf PRIJENOS PUTNIH NALOGA KOTAČ / LAUS preko F1 Prijenos omogućiti 

prijenos novog tipa troška za dnevnice iz KOTACA: 

Novi tip troška dnevnica KOTACNovi tip troška dnevnica - LAUS 

D D7K 


Poštovani, 

Na objektu pna_kot_jf PRIJENOS PUTNIH NALOGA KOTAČ / LAUS preko F1 Prijenos omogućen je prijenos 

novog tipa troška dnevnice D7K iz KOTACA. 

Preuzeti novi LAUS FINK lib u četvrtak 7.2.2013. 

S štovanjem 



0











Klijent: 





fakis.jas nova lista 

Hitnost: 



ivan 


13102 



05.02.2013 16:38 

Upisao: 

Dajana Lekić 

Područje: 

LWINFAU 


07.02.2013 


13.02.2013 

Prilog: excel tablica 

Potrebno je preko objekta fakis.jas omogućiti novi ispis u excel prema priloženoj tablici: 

Smjernice za popunjavanje: 

1. Prvi red ne mora sadržavati zaglavlje kao datoteka u privitku, može biti prazan. Ne smije sadržavati 

podatke o pošiljci jer se prvi red zanemaruje, 

2. Naziv datoteke je proizvoljan, 

Polja koja treba popuniti: 

B – 'U' za unutarnji promet, 'M' za međunarodni promet, 1 znak (primatelj iz RH-a je U, i izvan RH-a je M) 

C – ISO oznaka odredišne države (obavezno 'HR' za unutarnji promet, za međunardno ostaje prazno), 2 

znaka 

D – ovo polje popuniti brojem računa, inače polje nije obavezno, do 30 znakova (broj protokola) 

E – popuniti fiksno sa znakom 'R' (preporučena pošiljka), 1 znak 

K – naziv firme/primatelja (prvih 30 znakova ) – naziv iz tablice part, 

L – dodatni naziv (od 31 znaka do 60 ako naziv ne stane u polje K), 

N – broj PU, obavezno za unutarnji promet, do 5 znakova za unutarnji, 20 za međunarodni promet 

(part.posta), 

O – naziv PU (unutarnji promet, nije obavezno posta.naziv) ili mjesto (međunarodni promet, obavezno 

part.grad), do 30 znakova, 

P – adresa (može s ili bez kućnog broja), do 30 znakova,part.adresa 

Q – kućni broj (ako nije unesen u polje P), do 10 znakova 

Crveno označena polja obavezna su (obratiti pozornost da je polje N obavezno samo za unutarnji promet, a 

polje O samo za međunarodni promet). 



0









Poštovani, 

Na objektu za ispis faktura (fakis.jas) napravljen je novi ispis u excel. 

Ispis je zakačen pod meni ISPISI - Izvješće za ePK 

Instalacija: Novi WIN FAUS će biti dostupan sutra 13.02.2013 

S štovanjem 


Poštovani, 





0











Klijent: 





ruckat 

Hitnost: 

Vrlo hitno 


ivan 


13104 



05.02.2013 16:34 

Upisao: 

Dajana Lekić 

Područje: 

LWINFAU 


06.02.2013 


06.02.2013 

ruckat 

Kod izmjene datuma (dokumenta,dospijeća, PDV) preko ruckat.jas javlja se greška sa slike (za fakturu u 

statusu 2). 

Potrebno je omogućiti mijenjanje datuma za fakture (3 Digitalna TV na rate) u statusu 2. 

--- mijenja se >HP broj u 13104 (Višnja 6.2.2013 ) : 

Kod nas u evidenciji zahtjeva nema zavedenog tog zahtjeva već je pod 13103 upisan ovaj moj zahtjev. 

Morate promijeniti broj Ivanovog zahtjeva u 13104 kojeg je poslao Ivan (13103_LAUS.doc ) 


Poštovani, 

Ispravljena je greška koja se javljala kod izmjene datuma na objektu ruckat.jas 

Instalacija: novi WIN FAUS lib će od sutra 07/02/2013. bit na internetu 

S štovanjem 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Višnja 


13101 



05.02.2013 10:44 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


11.02.2013 


Kroz kzfpp.jas AUTOMATSKO KNJIŽENJE ZBIRNIH FAKTURA PLAT.PR. za potrebe knjiženja obveze 

prema HPB-u po fakturama platnog prometa za HZMO u iznosu od 21% (novi omjer podijele prihoda 

između HP-79% i HPB-21%), otvoren je konto: 

229830 FAKTURE-OBVEZE PREMA HPB ZA HZMO-PLAT.PROMET 

Potraživanje po fakturi knjižiti na konto: 

120530 FAKTURE ZA PLATNI PROMET-OSTALI KORISNICI 

Ugovor sa HZMO unesen je na organizacijskoj jedinici 30013 – Sektor financijskih usluga. 



0









Poštovani, 

u prilogu je prijedlog rješanja . 

Molimo vaš stav te odgovore na pitanja 

Status : Usaglašavanje s HP 


Poštovani, 

Molimo žurni odgovor na prijedlog rješenja kojeg ponovo šaljemo u prilogu a kojeg smo ranije poslali te još 

nismo dobili potvrdu 





u prilogu je prijedlog rješanja . 

Molimo vaš stav te odgovore na pitanja 

Status : Usaglašavanje s HP 


Na objektu knjiženja kzfpp.jas AUTOMATSKO KNJIŽENJE ZBIRNIH FAKTURA PLAT.PR. napravljena je 

tražena izmjena za potrebe knjiženja obveze prema HPB-u po fakturama platnog prometa za HZMO. 



Poštovani, 





0











Klijent: 





Hitnost: 



Katja 


13100 



04.02.2013 12:41 

Upisao: 

Božo Mišeta 

Područje: 

WINTRAN 


11.02.2013 


. Potrebno je napraviti listu broj 1 (Lista asortimana sa šiframa artikala) s niže navedenim kolonama: 

Šifra artikla; Naziv artikla; Broj asortimana; Naziv asortimana; Status asortimana; 

Rok valjanosti asortimana; 

•Omogućiti filter status asortimana s prioritetom status 2 (default da bude status 2) 

•Omogućiti filter broj asortimana 

•Omogućiti mogućnost odabira: jedan artikl ili svi artikli, jedan asortiman ili svi 

2. Potrebno napraviti listu broj 2 (Popis asortimana po PU) s niže navedenim kolonama: 

Šifra PU (mips šifra); Naziv PU;Broj asortimana; Naziv asortimana; Status asortimana; Rok valjanosti 

asortimana; 

Lista treba imati mogućnost pregleda za jedan PU po odabiru ili svi PU s mogućnošću odabira: svi 

pripadajući asortimani u svim statusima ili odabir jednog statusa po izboru s prioritetom asortiman u statusu 

2. 

3. Potrebno napraviti listu broj 3 (Popis kategorija PU) s niže navedenim kolonama: 

Šifra PU (mips); Naziv PU; Broj kategorije; Naziv kategorije; 

Za sve tri liste omogućiti ispis u excel. 

Navedene liste možete napraviti kroz jedan objekt sa mogućnošću zadavanja uvjeta preko filter polja. 

Traženu listu/liste smjestite na ME5691 LISTE ZA KOMERCIJALU ispod objekta konr_ul.trn. 



0









Poštovani, 

Napravljen je novi objekt asorl.trn LISTE ASORTIMANA i stavljen na ME5691 poziciju 10 na kojemu je moguće 

ispisati liste : 

1. POPIS ASORTIMANA SA ŠIFRAMA ARTIKALA 

2. POPIS ASORTIMANA PO PU 

3. POPIS KATEGORIJA PU. 

Potrebno je preuzeti win tran te preuzeti objekte i meni-e koji će biti na internetu 20.02.2013 

Evidentiran je novi objekt: 

- asorl.trn LISTE ASORTIMANA (P, l1tran, PWin) i stavljen na ME5691 poziciju 10. 

S štovanjem 


Poštovani, 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Višnja 


13099 

Riješen 


04.02.2013 10:44 

Upisao: 

Božo Mišeta 

Područje: 

LKEVP 


07.02.2013 


Kroz odl40_jke ODLUKA O RASPOREDU I TRAJANJU GO na odluci odl40p_rke.txt potrebno je skratiti 

zagradu u točki: 

3. Godišnji odmor može ukupno iznositi najviše 30 ( trideset) dana. 

u 

3. Godišnji odmor može ukupno iznositi najviše 30 (trideset) dana 


Riješeno prema zahtjevu, 

kevp će biti dostupan na internetu 05/02/2013. 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Višnja 


13098 

Riješen 


04.02.2013 10:34 

Upisao: 

Božo Mišeta 

Područje: 

LKROP 


07.02.2013 


25.02.2013 

Kroz izvj_clr_jk PORUKE IZ OBRAČUNA uočeno je da je redoslijed ispisa radnika svaki mjesec drugačiji 

(nema pravila). 

1.Molimo da se lista ispisuje svaki puta na isti način tj. da sort bude po ABECEDI ( PREZIME ) 

2.Neto iznos iskazan na listi potrebno je umanjiti za NAKNADU PRIJEVOZA. 


Prema zahtjevu redoslijed ispisa na izvješću poruke iz obračuna je izmjenjen tako da se sada radnici ispisuju po 

abecedi. 

Neto u porukama koje se odnose na brisanje obustava je izmjenjen tako da nije krajnji neto za isplatu već neto 

bez naknada. 

Lib je na internetu krop lib 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Višnja 


13097 

Riješen 


04.02.2013 10:25 

Upisao: 

Božo Mišeta 

Područje: 

LKROP 


07.02.2013 


25.02.2013 

Kroz obev_jk EVIDENCIJA OBUSTAVA PO DJELATNIKU kod unosa zajmodavca preko F4 Pregled, na 

ekranu 'Pregled Zajmodavca' potrebno je omogućiti pretraživanje po žiro računu i pozivu na broj: 

vidi prilog 

jer pretraga samo po šifri i nazivu zajmodavca nije dovoljna. 


Na pregledu koji se dobije prilikom traženja poslovnog partnera sa objekta obev_jk EVIDENCIJA OBUSTAVA 

PO DJELATNIKU omogućeno je 

pretraživanje po broju računa i pozivu na broj. 

Ovo vrijedi za korisnike koji poslovne pratnere pretraživaju iz tablice obus_part kao što su HP i HZZO. 

krop lib bit će dostupan od 12.02.2013 



0











Klijent: 





hp_lm_jtr PRIJENOS ŠIFARNIKA 

U MIPS 

Hitnost: 



katja 


13096 



01.02.2013 16:50 

Upisao: 

Dajana Lekić 

Područje: 

LTRAN 


05.02.2013 


Izmjena dodatnog podatka STS kod prijenosa šifrarnika LAUS->MIPS (hp_lm_jtr ) 

se ne prenosi u mips_laus bazu. 

Podatak STS se nalazi u tablici art_oso where tipp='STS'. 

Molim vas da omogućite prijenos izmijenjenog podatka STS u mips_laus bazu. 



0









Poštovani, 

Prijenos nije dobro prošao jer na tablici dodatnih podataka za artikal (tablica gdje se definira STS šifra za artikal - 

art_oso) 

nisu ispravni triggeri (produkcija) ili uopće ne postoje (test ) 

NAPOMENA: ovo nije prvi slučaj da su triggeri /procedure koje ih koriste nestali ili promijenjeni . 

Molimo kod slijedećeg brisanja/ izmjene pošaljite obavijest ako ste ih svjesno i namjerno mijenjali/brisali . 

Također , kad se radi export/import baze triggeri ,view-ovi ,.. se ne kreiraju kod importa nego ih je potrebno 

naknadno kreirati. 

Molimo povrtane informacije nakon kreiranja triggera/ suglasnost za zatvaranje zahtjeva - Riješen 

Potrebno je izvesti sql-ove: 

Na produkciji obavezno / na testu kako hoćete : 

drop trigger "l1base".mips_del_arttipp; 

drop trigger "l1base".mips_ins_arttipp; 

drop trigger "l1base".mips_upd_arttipp; 

create trigger "l1base".mips_del_arttipp delete on "l1base".art_oso 


for each row 

when (((old.tipp = 'NAR' ) OR (old.tipp = 'STS' ) ) ) 

( 

update "l1tran".l_mips_art set "l1tran".l_mips_art.azur = 1 

where (artikal = old.artikal ) ); 

create trigger "l1base".mips_ins_arttipp insert on "l1base".art_oso 


for each row 

when (((new.tipp = 'NAR' ) OR (new.tipp = 'STS' ) ) ) 

( 


where (artikal = new.artikal ) ); 

create trigger "l1base".mips_upd_arttipp update on "l1base".art_oso 


for each row 

when (((((pre.tipp != post.tipp ) OR (pre.aktivnost 

!= post.aktivnost ) ) AND ((pre.tipp = 'NAR' ) OR (post.tipp = 'NAR' 

) ) ) OR (((pre.tipp = 'STS' ) AND (post.tipp = 'STS' ) ) 

AND (pre.tekst != post.tekst ) ) ) ) 

( 


where (artikal = pre.artikal ) ); 



0











Klijent: 





bss, DTV 

Hitnost: 

Vrlo hitno 


ivan 


13095 

Molim procjenu i rok za zahtjev iz priloga. 



01.02.2013 16:42 

Upisao: 

Dajana Lekić 

Područje: 

LWINFAU 


01.02.2013 


Molimo aplikativno rješenje za automatizaciju prijenosa podataka o kupljenim STB uređajima kroz 

kupoprodajni ugovor sa HPom, iz aplikacije BSS u aplikaciju LAUS te na osnovu prenesenih podataka (sa 

podacima o korisniku, laus šifrom proizvoda, brojem rata te ukupnim terećenjem automatsko generiranje 

računa i ispis svih računa kroz jednu transakciju. 



0









Poštovani, 

Kako bismo mogli procjeniti potreban angažman i rok isporuke HP treba odgovoriti na navedena pitanja . 

status : Usaglašavanje sa HP 

PITANJA : 

P1 automatsko generiranje računa i ispis svih računa kroz jednu transakciju 

Zapravo znači : generiranje svih dosad negeneriranih računa za STB na rate odjednom tj. ne zadaje se kod 

generiranja 1 po 1 ugovor ? 

(status ugovora=2 , računa nema u lm_usl_fak sa boriginal=brugo) 

ispis svih generiranih računa odjednom tj. ne zadaje se za ispis 1 po 1 račun ? 

P2. Računi će završiti u statusu 2 pa će se fiskalizirati/dobiti porezni broj kod prelaska u status 3 

ili Računi će završiti u statusu 3 i fiskaliziraju se / dobiju porezni broj kod automatskog fakturiranja ? 

P3. Koji način plaćanja za fiskalizaciju trebaju imati ovi računi obzirom da je bilo dvojbi trebaju li ili ne imati ZKI i 

JIR jer se plaćaju rate općim uplatnicama koje se tiskaju uz račune za usluge DTV ? 

P4. Način plaćanja za fiskalizaciju obavezno zadaje korisnik kod automatskog generiranja po svojoj želji ili 

program upisuje po defaultu bez mogućnosti intervencije korisnika ? 


Poštovani, 

Vezano za poslane odgovore kao pojašnjenje : 

Dodatno: U svaki račun osim šifre artikla iz ugovora treba dodati i određenu usluga (kamate) ovisno o broju rata 

– predlažem veznu tablicu s upisom broja rata, šifrom usluge koja ide uz taj broj rata, te indikatorom aktivnosti 

(uz uradio, datum i sl.). Naime, postoji mogućnost da u jednom trenutku više ne računamo dodatne kamate za 

ugovore na rate, pa ako u veznoj tablici nema aktivnih slogova za određeni broj rata neće se niti dodavati 

posebna usluga za kamate. 

--- zahvaljujemo i konstatiramo da se pojašnjenje slaže sa zaključcima analize koju smo proveli vezano za 

dodavanje usluge za kamate . 

Naš zaključak je bio : uslugu za kamate odrediti sql_om : 

select usluga,nazive,aktivnost a from lm_usluga 

where usluga in (select usluga from lm_usl_dod where vr_usluga='DIG') 

and nazive like '%24%' and aktivnost='D' 

Zaključke analize / prijedlog rješenja nismo vam još dostavili - poslat ćemo zajedno s procjenom . 

Molimo pošaljite stav HP : gornji sql za određivanje usluge za kamate je pouzdan/dostatan 

ili nije tj. treba raditi veznu tablicu : broj rata- usluga 



0









Poštovani, 

Napravljen je novi objekt za automatsko generiranje računa za STB na rate. Objekt je fakSTB.jas. 

Kod generiranje je obavezno za upisat datum od i do. Filter polja su Šifra kupca, Broj ugovora i Broj rata. 

Fakturiraju se svi ugovori u statusu 1 ili 2 s tipom plaćanja R. Po jednom ugovoru može nastati samo jedna 

faktura (osim kada se faktura stonira). 

Organizacijska jedinica se gleda iz parametra DTVNE, a vrsta dokumenta je DIG. 

Automatski se puni prot_fisk s načinom plačanja T (transakcijski). 

Na objektu je omogućen i pregled generiranih faktura te pregled stavki u fakturama. 


Korisnik mora poslati ime novog objekta te na koji meni da se novi objekt zakači. 

S štovanjem 


Poštovani , 

Riješeno je prema zahtjevu ( obrada 6 pod 2) ) 

Potrebno je na na meni-u; ME560 - HP USLUGE - PRIJENOS I FAKTURIRANJE; 

Otvoriti novi meni: 'DIGITALNA TV' te na njega staviti slijedeće objekte prema donjem rasporedu: 

1) ugvr.jas – Pregled ugovora za usluge 

2) novi objekt za fakturiranje STB-a na rate - fakSTB.jas 

3) ruckat.jas – Računi bez ugovora 

4) 

5) 

6) knjdig.jas KNJIŽENJE DIGITALNE TV 

7) knjstb.jas KNJIŽENJE RAČUNA ZA STB NA RATE 

Kada se ovo gore napravi potrebno je sa meni-a ME567 maknuti: 

knjdig.jas KNJIŽENJE DIGITALNE TV 

knjstb.jas KNJIŽENJE RAČUNA ZA STB NA RATE 


Preuzmite nove objekte i menije s interneta u ponedjeljak ujutro (25.2.2013) 

provedite instalaciju objekata i menija 

NAPOMENA: 

Masovni ispis računa za STB na rate planiramo isporučiti u ponedjeljak 25.2.2013. 



0









Poštovani, 

Napravljeni su SQL-ovi za upis artikla i usluga u ugovre za STB na rate 

koji su se već preuzeli iz BSS-a sa upisanim artiklom 

za koje još nije napravljen račun 

kojima nisu upisane stavke 

kojima nije upisan artikal 

SQL-ovi (/home/admlaus na serveru) : 

---Pripremni SQL-ovi : 

bss_ubacistav 

bss_ubacistav2 

---Završni SQL-ovi : 

bss_ugart 

bss_ugvst 

NAPOMENA : 

U ugovor se ubacuju stavke sa : 

-- usluga DTVUS=44131 USLUGA ZA PRODAJU UREĐAJA DTV 

-- usluga uz vezne tablice brusl (brrata i usluga) 

Tablica laus@laustest:brusl je prazna pa se neće upisati usluga vezana za broj rata . 

Preporuka : 

Ako ima malo ugovora kojima se ipak treba upisati usluga vezana za broj rata , 

onda za njih račune napraviti ručno bez upisivanja te stavke u ugovor nego samo u račun 

Ako je poznat granični datum ugovora (datumkr) do kojeg uključivo treba ići usluga vazana za broj rata , onda 

se može napraviti ovako : 

-- popuniti vezu brrata-usluga sa aktivnost=D i javiti u LAUS da je popunjeno 

-- upistai uslugu vezanu za rate samo onima kojima je DATUMKRE









Na objektu za generiranje masovnih faktura STB omoguće je rad i s ostalom analitikom. 

Izmjena je napravljena kod fakturiranja, te ba pregledima i listama. 

Novi WIN FAUS lib je već isporučen. 


Fakture se generiraju za period od kada vrijedi ugovor. 

Omogućena je i izrada faktura i kada postoji po ugovoru izrađena faktura koja je u statusu 0. 

Novi WIN FAUS lib je već isporučen. 


Kod fakturiranja STB na rate cijene usluga se uzimaju za datum koji je korisnik upisao u polje Datum dokumenta. 

WIN FAUS lib je već isporučen. 


Na objektu automatsko generiranja faktura STB omoguće je ispis faktura. 

Fakturu je moguće ispisati pojedinačno ili masovno. 

WIN FAUS lib je već isporučen. 


Kad masovnog i pojedinačnog ispisa se u polje Broj korisniničkog računa upisuje serijski broj uređaja 

(lm_ugv_dod.serbrstb). 

Na masovnom ispisu je ispravljen prikaz broja stranica. 



Poštovani, 

Molimo povratne informacije za isporučene funkcionalnosti . 

Zadnje isporučeno : 

Kad masovnog i pojedinačnog ispisa se u polje Broj korisniničkog računa upisuje serijski broj uređaja 

(lm_ugv_dod.serbrstb). 

Na masovnom ispisu je ispravljen prikaz broja stranica. 

Novi WIN FAUS lib je na internetu od 6.3.2013. 

Ostaje još za riješiti : 

Kod otvaranja ugovora, ugovori se mogu pretraživati samo po partnerima a ne i po ostalim analitikama 

- potrebno omogućiti pretragu ugovora i po ostalim analitikama 


Poštovani, 

Zahtjev zatvaramo uz vašu suglasnost -( Ivan 9.4.2013.) - Riješen 



0











Klijent: 



Pitanje 


učitavanje podataka 

Hitnost: 

Vrlo hitno 


glorija 


13094 

Riješen 


01.02.2013 16:18 

Upisao: 

Dajana Lekić 

Područje: 

LCSBI 


02.02.2013 


05.02.2013 

U privitku dostavljam dokument sa statusom podataka na današnji dan –iz kojeg se vidi da 31.01.2013. nije 

napravljeno učitavanje podataka iz Lausa u LCS BI sustav. 

Prilozi: LSBI report na dan 01.02.2013.pdf 


Utvrđeno je kako je ostalo visjeti dosta konekcija na bazu Te konekcije onemogućavale su punjenje, jer za 

punjenje baze trebamo ekskluzivni pristup bazi. 

Konekcije koje su ostale visjeti su zatvorene, te će se učitavanje nastaviti redovnom dinamikom. 

U suradnji sa CS traži se razlog zašto neke konekcije ostaju nezatvorene. 


Load job u međubazu nije išao jer je CubeServ držao otvorene konekcije na bazu. Nakon što su te konekcije 

koje su ostale visiti ubijene, job se nastavio izvoditi. 



0











Klijent: 





ispis računa 

Hitnost: 

Vrlo hitno 


glorija 


Zahtjev prioritetan u prilogu. 

13093 



01.02.2013 15:13 

Upisao: 

Dajana Lekić 

Područje: 

LWINFAU 


01.02.2013 


04.02.2013 

Molimo da se na sve izlazne račune koji nastaju u Laus aplikaciji naprave izmjene na način da se uvede tzv 

„Korisnički broj račun“. 

Navedeno polje formira se prema pravilima postavljenim Zakonom o fiskalizaciji, i trenutno se koristi na 

objektu ruckat.jas (Računi bez ugovora – računi za katalošku i web promjenu-prilog). 

Također je potrebno zamijeniti mjesta tako da se u polju „RAČUN br.“ upisuje broj formiran za fiskalizaciju, 

a na mjestu „Korisnički broj računa“ (ili na neko drugo mjesto ovisno o mogućnostima programa) da se stavi 

dosadašnji način numeriranja računa – protokol. 

Potrebno je dakle zadržati i dosadašnje označavanje računa (npr. 31005-513-00001) jer se tako formirani 

brojevi i dalje zadržavaju kod evidencije u Knjizi izlaznih računa, kod svih knjiženja, pregleda i 

rekapitulacija. 

Sve navedeno za sada se neće odnositi samo na račune koje nastaju u Billingu. 



0









Poštovani, 

Obzirom da se kod računa za filateliju način plaćanja ispisivati na engleskom ( veza zahtjev 13079) trebamo 

pojašnjenja vezano za ispis labela : 

- Fiskalni broj 

- Datum izdavanja 

- Fakturirao 

- Način plaćanja . 

PITANJE: labele se također ispisuju na engleskom jeziku ? 

Ako da , molimo pošaljite engleske nazive za labele . 


Poštovani, 

Vezano za navod : 

Sve navedeno za sada se neće odnositi samo na račune koje nastaju u Billingu. 

Potrbna su pojašnjenja : 

Računi koji nastaju u billing-u ne smiju moći ispisati u LAUS-u ? 

Računi koji nastaju u billing-u ne smiju se moći fiskalizirati u LAUS-u ? 


Poštovani, 

Napravljene su izmjene na objektu za ispis faktura (fakis.jas - pojedinačni i masovni ispis), te na objektu za ručni 

unos računa (rucfak.jas). 

Za račune koje su fiskalizirani se u polju RAČUN br. ispisuje broj formiran za fiskalizaciju, a u zaglavlju ispisa je 

nadodano novo polje Broj računa gdje se prikazuje LAUS broj računa (protokol) . 

Za račune koji nisu fiskalizirani (stari) ispis je ostao nepromijenjen 


Instalacija: preuzmite od sutra ujutro 06.02.2013 novi WIN FAUS lib sa interneta . 



Napravljena je izmjena ispisa faktura na objektima ručnih unosa faktura (rucfak.jas i rucfakd.jas) 

U polje RAČUN br. se upisuje broj formiran za fiskalizaciju (ako postoji), a na mjestu Broj računa se prikazuje 

broj ralčuna. 

Ako je račun fiskaliziran u zaglavlju ispisa se polja datum izdavanja, fakturirao i način plaćanja čitaju if prot_fisk 

tablice. 

Instalacija: Sutra ujutro 07/02/2013 će biti dostupan novi WIN FAUS lib. 



0









Poštovani, 

U prethodnoj obavjeti po obradi 8 ovog KZ-a poslali smo : 

Kod unosa uputa omogućen je unos više kombinacija načina plaćanja za isti vrtsu dokumenta, vrstu protokola i 

orgj. 

Kod fiskalizacije računa postavljeno je da se način plaćanja čita iz tablice lm_usl_fak koje se nalazi u polju 

fisk_nacpla. 

Također prilikom fiskalizacije je postavljena kontrola na postojanje ključa (vdok,vprotokol,orgj, nacpla) u uputama 

za fiskalizaciju. 

Čekati trenutak isporuke kada odobri HP nakon završetka tekućeg fakturiranja. 

Prilikom isporuke potrebno je preuzeti novi LAUS BASE, LAUS FINK i WIN FAUS lib, koji su od sutra na 

internetu. 

----------------------------- 

Sad šaljemo ispravk obrade 8: 

Čekati trenutak isporuke kada odobri HP nakon završetka tekućeg fakturiranja. 

Prilikom isporuke potrebno je preuzeti novi LAUS BASE, LAUS FINK i WIN FAUS lib. 

Dakle, preuzimanjem navedenih libova sutra nećete dobiti ove promjene jer još nisu u isporuci nego u razvoju . 

Razlog : 

- mora isporučiti zajedno sa funkcionalnostima koje se traže po zahtjevu HP 13079 , KZ 40942 jer bi inače 

programi fakturiranja 'pucali'. 

- mora se prije isporuke kod nas testirati 

- moramo s vama dogovoriti termin isporuke obzirom da 

- nije dobro ove značajne izmjene kod izrade i fiskalizacije izlaznih računa /faktura instalirati u jeku 

fakturiranja 

- treba za već nastale izlazne račune/fakture u LAUS-u treba popuniti način plaćanja za fiskalizaciju u 

proširenoj lm_usl_fak tablici kad za to dođe vrijem 


Na objektu za ručni unos računa filatelijenapravljena je izmjena na ispisu. 

Ako je račun fiskaliziran, u zaglavlju se prikazuhe broj formiran za fiskalizaciju. 

Instalacija: sutra 19.02.2013 bit će dostupan nov WIN FAUS lib 


Poštovani, 

Na objektu za ručni unos računa kataloške prodaje (ruckat.jas) napravljena je izmjena na ispisu. 

Ako je račun fiskaliziran, u zaglavlju se prikazuje broj formiran za fiskalizaciju. 


Instalacija: od 19.02.2013 ujutro nadalje novi WIN FAUS lib. 

Molimo povraten informacije / suglasnost za zatvaranje zahtjev a- Riješen 



0









Poštovani, 

Zahtjevom 13093 ješavan je ispis računa po novim pravilima vezanim za fiskalizaciju . 

ISPIS riješeno -- 13093 : 

RZ 53960 Napravljena je izmjena ispisa faktura na objektima ručnih unosa faktura (rucfak.jas i rucfakd.jas) 

U polje RAČUN br. se upisuje broj formiran za fiskalizaciju (ako postoji), a na mjestu Broj računa se prikazuje 

broj ralčuna. 

Ako je račun fiskaliziran u zaglavlju ispisa se polja datum izdavanja, fakturirao i način plaćanja čitaju if prot_fisk 

tablice. 

Nije riješeno : 

FISKALIZACIJA kod status 2--->3 na rucfak i rucfakd jer nismo dobili zahtjev da treba a moguće je fiskalizirati 

račune i na drugi način . 

Rješava se dalje kroz 13079 gdje i ostali automatski načini fiskalizacije koji nisu na tipku Fiskaliziraj . 

Potrebno je kod izlaznih računa pojedinačne fakrure : rucfak i rucfakd 

za nastale dokumente/račune formirati fiskalni/porezni broj na prelazu sttusa 2 -->3 te ga zapamtiti /upisati u 

prot_fisk . 

Način plaćanja automatski puniti kao T-Transakcijki račun 

Storno preslikava način plaćanja originalne fakture. 

Molimo povratne informacije/komentare u vezi gore navedenog . 


Poštovani, 

zahtjev zatvaramo uz vašu suglasnost - Riješen 



0











Klijent: 





upute za konta u uputama za 

generiranje konsolidiranih izvještaja 

Hitnost: 

Vrlo hitno 


glorija 


13092 



01.02.2013 13:11 

Upisao: 

Dajana Lekić 

Područje: 

AFINK 


02.02.2013 


Već se nekoliko dana ne može pristupiti ekranu za zadavanje novih uputa po godinama kod financijskih 

izvještaja u Argosy međubazi. U prilogu je slika: 


Poštovani, 

Grešku koju navodite nismo uspjeli ponoviti na našim test bazama i našoj razvojnoj okolini. Molim dozvolu za 

spajanje na produkcijsku okolinu za Argosy međubazu, kako bi utvrdili razloge i otklonili grešku. 




Razlog greške su nezatvorene konekcije na bazi. Te konekcije onemogućavale su punjenje, jer za punjenje baze 

trebamo ekskluzivni pristup bazi. 

Konekcije koje su ostale visjeti su zatvorene, te će se učitavanje nastaviti redovnom dinamikom. 

U suradnji sa CS traži se razlog zašto neke konekcije ostaju nezatvorene /rješava se u okviru zagtjeva 41067 

(HP broj 13094) 



0











Klijent: 






Vrlo hitno 




13091 



01.02.2013 09:47 

Upisao: 

Boško Tokić 

Područje: 

LSTAN 


Zahtjev potrebno HITNO riješiti (danas) jer se uplatnice ne mogu generirati, a trebaju ići van (znači već 

kasnimo 1 dan). 

Lp, Glorija Markovac 


Poštovani, 

Omogućeno je generiranje uplatnica. 


preuzimite WIN STAN lib. Lib je na internetu. 




0











Klijent: 






Vrlo hitno 




13090 

Riješen 


31.01.2013 13:56 

Upisao: 

Boško Tokić 

Područje: 

LWINFAU 


Knjiženjem na objekima knjts5.jas i knjts7. jas Knjiženje poštanskih i novčanih usluga plaćenih gotovinom i 

virmanim uočena je greška neispravnog knjiženja PDV. 

Na knjigovodstvenim nalozima 135K0001 – 135K0003 ne zatvara se knjigovodstveni nalog iz slijedećih 

razloga: 

1.Na knjiži PDV za usluge Mali oglasi, šifra artikla 44611 i 44612, za šifru 44613 je proknjižio PDV, molim i 

provjeru za knjiženja usluge 44614-44616, knjižiti na nivo 00000. 

2.U rekapitulaciji naplaćenih usluga i prodaje ne kupi stopu poreza 5% i ne knjiži je. 

3.Molim ispravak knjiženja nivoa PDV-a za sve vrste dokumenta GOT, GR1, VR1, PGH umjesto nivoa 

41008 na nivo 00000. 



0









Poštovani, 

programske izmjene sa ispravkom navedenih grešaka bit će dostupne u ponedjeljak ujutro (4.2.2013. ) na 

internetu 


Poštovani, 

Riješene su prve dvije točke iz zahtjeva 

Ispravljeno je knjiženje PDV-a na objektima za knjiženje gotovine i virmana (objekti knjts5.jas i knjts7.jas). 

U rekapitulacijama naplaćenih usluga i prodaje nadodan je i prikaz poreza po stopi 5%. 


Instalacija: novi win faus lib je na internetu. 


Poštovani, 

Knjiženja nivoa PDV-a za sve vrste dokumenta GOT, GR1, VR1, PGH je sada umjesto nivoa 41008 nivo 00000. 


Instalacija: novi WIN FAUS lib je na internetu. 

S štovanjem 



0











Klijent: 





RUDul_jd 




katja 


RUDul_jd na test bazi : 

13089 


Za RUD – u dokumentu ne povlači MPC nego NC 

Npr. RUD 35358-U13-02468 Artikal 321416 

RDU 35358-U13-02469 Artikal:301318 


30.01.2013 15:57 

Upisao: 

Dajana Lekić 

Područje: 

LROBD 


04.02.2013 


Poštovani, 

Potrebno je za vrstu dokumenta RUD na objektu kojec_ja DEFINIRANJE CIJENA ZA DOKUMENTE unijeti 

upute na uzoru za dokumenat RIM. 

Korisnik POSTA__________ 

Vdok RUD__ IZDATNICA U DORADU 

Orgj ______ 

Tip orgj _____ 

Cijena 1 NC___ Nabavna cijena 

Cijena 2 MPC1_ Maloprodajna cijena 1 

Cijena 3 _____ 




0











Klijent: 





asortiman 

Hitnost: 

Vrlo hitno 


katja 


asort_ja ASORTIMAN 

13087 

Greška: loše polje ili argument u liniji 62 u asort_s_del_ja: 

create index :xtmp on :xtmp(artikal) 



30.01.2013 15:29 

Upisao: 

Dajana Lekić 

Područje: 

LROBD 


30.01.2013 



Poštovani, 

Ispravljena greška prilikom brisanja stavke asortimana. 


Već ste preuzeli programske izmjene . 

Molimo povrtane informacije / suglasnost za zatvaranje zahtjeva- Riješen 


Poštovani, 




0











Klijent: 





pna_kot_jf 

Hitnost: 

Vrlo hitno 


Višnja 


13070 



30.01.2013 15:13 

Upisao: 

Tomislav Musić 

Područje: 

LFINK 


30.01.2013 


30.01.2013 

Potrebno je uključiti navedenu proceduru pna_gres1_ff za uvid u detalj greške kroz Pregled grešaka 

prijenosa podataka KOTAC-LAUS: 


Poštovani, 

Otvorili smo ovaj KZ s vašim brojem 13070 u kojem se rješava korektivni dio zahtjeva ( nedostaje ekran detalja 

pna_gres1_ff ) 

Na ekranu pna_gres_ff nakon pozicioniranja na stavku u pregledu omogućen je uvid u detalj sloga sa greškom 

na tipku F1 Detalj. 


Poslati obavijest korisniku o preuzimanju novog LAUS FINK liba u četvrtak 31.1.2013. 



Poštovani, 

Naziv ekrana pna_gres1_ff izmjenjen je u "Detaljni pregled naloga sa greškom". 






0











Klijent: 





ugovori 

Hitnost: 

Vrlo hitno 


višnja 


13088 



30.01.2013 11:17 

Upisao: 

Dajana Lekić 

Područje: 

EPNAB 


30.01.2013 


30.01.2013 

Potrebno je u ePN za spis „HP-10/2-023043/12“ u Registru ugovora postupka nabave izvršiti izmjenu: 

- broj ugovora „HP-10/2-023043“, u broj ugovora „HP-10/2-023043/12“ 

--- mijenjam KOR u ADA vrstu održavanja 


Poštovani, 

Zahtjev je realiziran na produkciji ( intervencija u bazi ) 

Molimo povratne informcije/ suglasnost za zatvaranje zahtjeva - Riješen 


Poštovani , 

ovdje se radi o Adaptivnom održavanju s obzirom da mijenjamo podatke radi greške u unosu 


Poštovani, 




0











Klijent: 





RIMul_jd 

Hitnost: 

Vrlo hitno 


katja 


13086 



29.01.2013 16:09 

Upisao: 

Dajana Lekić 

Područje: 

LROBD 


29.01.2013 


29.01.2013 

Izvještavam da DEPO RIJEKA nije u mogućnosti statusirati dokument RIM. Molim Vas da otklonite kvar. 

GREŠKA: Unos primke argosy1 -387 



0









poštovani, 

Smatramo da je ovo adaptivno održavanje (intervencije na prdukcijskoj bazi korisnika). 

Mi ne trebamo i ne možemo 'otklanjati kvar' jer nemamo ovlasti DBA koje su za to potrebne. 

Potrebno : DBA (database administrator ) treba grantati /proslijediti CONNECT privilegije/dozvole unix 

korisniku kojem se javila ova poruka (greška -387) jer isti nema dozvolu za spajanje na bazu argosy1 

-387 No connect permission. 

You cannot access the database that this statement requests because you have not been granted CONNECT 

privilege to it. Contact a person who has 

Database Administrator privilege to that database and ask to be granted CONNECT privileges to it. 

Molimo suglasnost za zatvaranje zahtjeva- Riješen 


Potrebno : DBA (database administrator ) treba grantati /proslijediti CONNECT privilegije/dozvole unix 

korisniku kojem se javila ova poruka (greška -387) jer isti nema dozvolu za spajanje na bazu. MILA ma 

produkcijskom MILA serveru. 

-387 No connect permission. 

You cannot access the database that this statement requests because you have not been granted CONNECT 

privilege to it. Contact a person who has 

Database Administrator privilege to that database and ask to be granted CONNECT privileges to it. 

Kod izmjene statusa RIM dokumenta, aplikacija upisuje podatke u MILA bazu. Potrebno je svim korisnicima koji 

koriste promjenu statusa RIM dokumenta dodijeliti dozvole spajanja, upisa, izmjene i brisanja podataka u MILA 

bazi. U konkretno ovom slučaju potrebno je brisanje tablice zahtjev_prjenos_mips u MILA bazi. 


Poštovanje Renata, 

U okviru zahtjeva 38208 (HP broj 12490) dostavljene su upute i odgovoreno je na sva pitanja oko kreiranja 

tablica na mips laus bazi. Konkretno pitanja vezana uz ovu mejsto kreiranja tablice zbog koje je program javio 

grešku su rješena 11.10. (obrada 19 zahtjeva 28208). 

U okviru ovog zahtjeva poslani su svi SQLovi i upute za kreiranje tablica. 

Niti u jednom zahtjevu, Laus CC ne obrađuje kojim HP korisnicima treba dati siszemske dozvole za spajanje na 

bazu (što je ovdje uzrok problema). 

Naš angažman na otklanjanju ovdje prijavljene greške, svodi se na analizu stanja na produkcii, pa je stoga 

adaptivnog karaktera. 

Slažem se da programjavi grešku na neprimjern način (spominje se argosy1 i broj greške). U poruci o greški nz 

znakova "Argosy1" je suvišan, no greška -327 nedvosmisleno upućuje na urok greške (nepostojanje dozvole za 

spajanje na bazu). 

Ljubo 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Glorija 


13085 



29.01.2013 14:54 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


30.01.2013 


30.01.2013 

Kod storno dokumenta ne preslikaju se polja Gross weight i Net weight sa originalnog dokumenta. 


Poštovani, 

Ispravljeno je da se kod storno dokumenta evidentiraju i polja Gross weight i Net weight. 


Instalacija: sutra ujutro 30.1.2013 će biti dostupan novi WIN FAUS lib. sa promjenama 

Molimo povratne informacije /suglasnost za zatvaranje zahtjeva- Riješen 


Poštovani, 

Ispričavam se zbog pogrešno navedenog datuma u prethodnoj obradi : sutra znači 31.1.2013 a ja (Dajana) sam 

stavila 30.1.2013 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Ivan 


13084 



29.01.2013 14:30 

Upisao: 

Božo Mišeta 

Područje: 

LROBD 


29.01.2013 


Kod prijenosa podataka iz mips u laus preko objekta 'amb_jd PRIJENOS PODATAKA IZ MIPS-A' dio 

podataka završi u greškama. 

Greška za sve neprenesene podatke je ista: '10 – Neispravni tarifni brojevi' 

U tablici promet_pu za njih je tarifni broj ' P05' – koji je kod nas definiran u LAUS i MILA bazi u tablici 

'lm_pdv'. 



0









Poštovani, 

Kod prijenosa podataka iz mips u laus preko objekta 

amb_jd PRIJENOS PODATAKA IZ MIPS-A 

kod grešaka tipa 10 tarifni brojevi sada se kontroliraju preko tablice lm_pdv polje pdvmips. 


preuzeti laus libove rob0,rob1,rob2,rob3,rob4 koji će biti na internetu 30.01.2013. 



Poštovani , 

greška -206 : The specified table is not in the database. 

javlja se jer ne postoji tablica promet_pu_veza u MBAZA . Mi nemamo ovlasti na MBAZA koje omogućuju 

kreiranje tablica pa molimo , ako već nije izveden, izvedite na MBAZA (mips_laus) bazi dolje navedeni SQL 

za kreiranje nedotajuće tablice . 

Ponovno pustite prijenos i povratne informacije/ suglasnost za zatvaranje zahtjeva - Riješen 

NAPOMENA: radi greške -206 nije potrebno preuzimati nove verzije programa . 

create table "l1base".promet_pu_veza 

( red integer not null , 

mips_dokument char(20) not null , 

datum_dokumenta date not null , 

posta char(6) not null , 

vdok_mips char(3) not null , 

osngrp char(3) not null , 

tip_veze char(2) not null , 

veza_dokument char(20) not null , 

veza_datum_dokumenta date, 

veza_posta char(6), 

veza_vdok_mips char(3), 

indikator_mips char(1) not null , 

indikator_laus char(1), 

akcija char(1) not null , 

korisnik_dos char(16) not null , 

dat_vri_dos datetime year to second not null , 

korisnik_obr char(16), 

dat_vri_obr datetime year to second, 

slog_id serial not null ); 

revoke all on "l1base".promet_pu_veza from "public"; 

create unique index "l1base".i_promet_pu_veza1 on "l1base".promet_pu_veza 

(red,mips_dokument,datum_dokumenta,posta,vdok_mips,osngrp) ; 

create unique index "l1base".i_promet_pu_veza2 on "l1base".promet_pu_veza (slog_id) ; 

grant all on "l1base".promet_pu_veza to "public"; 



0









Poštovani, 

provjerite te ako nije izvedeno, izvedite na laus bazi dolje navedene SQL za kreiranje tablica hp0_veza i 

hpveza_greska 


Potrebno izvesti sql-ove ; 

create table "l1robd".hp0_veza 

( 

red integer , 

mips_dokument char(20) not null , 

datum_dokumenta date not null , 

posta char(6) not null , 

vdok_mips char(3) not null , 

osngrp char(3) not null , 

tip_veze char(2) not null , 

veza_dokument char(20) not null , 

veza_datum_dokumenta date , 

veza_posta char(6) , 

veza_vdok_mips char(3) , 

indikator char(1) , 

slog_id integer not null , 

korisnik varchar(20,10) 

default user, 

datum_ucitavanja date 

default today, 

vrijeme_ucitavanja datetime hour to minute 

default current hour to minute 

); 

create index "l1robd".hp0_veza on 

"l1robd".hp0_veza(slog_id) ; 

create index "l1robd".hp0_veza1 on 

"l1robd".hp0_veza (datum_dokumenta,mips_dokument,posta,vdok_mips,osngrp) ; 


"l1robd".hp0_veza (veza_datum_dokumenta, 

veza_dokument,veza_posta,veza_vdok_mips,osngrp) ; 


"l1robd".hp0_veza(red) ; 

grant all on "l1robd".hp0_veza to public; 

create table "l1robd".hpveza_greska 

( 

tip smallint, 

tekst varchar(30,4), 

datumdok date, 

datum_pre datetime year to second, 

slog_id integer 

); 

create index "l1robd".hpveza_greska on 

"l1robd".hpveza_greska (slog_id) ; 

create index "l1robd".hpveza_greska2 

on "l1robd".hpveza_greska (datumdok) ; 

grant all on "l1robd".hpveza_greska to public; 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Ivan 


13083 



29.01.2013 10:18 

Upisao: 

Božo Mišeta 

Područje: 

EOBRRAC 


29.01.2013 


U eobradi ne vidi se podgrupa troška 2013-9.7. Poslana je u MILA bazu i preuzeta je od strane 

integracijskog servisa. 

Ne vidi se niti na pregledu za unos predmeta 


Poštovani , 

Za rješavanje zahtjeva molimo omogućite pristup na produkciju Tvrtku Matoševiću te o istom nas obavjestite 

kad bude omogućeno 


Poštovani, 

Molimo povratne informacije za podgrupa troška 2013-9.7 / suglasnost za zatvaranje zahtjeva - Riješen 

Vidi li se sad u eObradaRačuna ? 


Poštovani, 

Zahtjev zatvaramo uz vašu suglasnost (Poldrugač) - Riješeno 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Glorija 


13081 



29.01.2013 07:17 

Upisao: 

Božo Mišeta 

Područje: 

LBASE 


02.02.2013 


Potrebno je onemogućiti korisniku koji mogu mijenjati statuse računa iz 3 u 2 (likvidirane račune može 

mijenjati samo posebno definirani korisnik) zabrani takav rad zbog provedbe fiskalizacije i činjenice da su 

računi u statusu 3 prijavljeni u poreznu upravu. Znači bilo koji račun koji je u statusu 3, a podliježe 

fiskalizaciji ne bi se smio vraćati u status 2. 



0









Poštovani, 

Molimo samo pojašnjenje /stav HP : 

zahtjev odnosi na račune : 

a) koji imaju imaju evidentiran ZKI i JIR 

b) koji imaju evidentiran ZKI bez obzira na JIR 

c) koji u uputama za fiskalizaciju imaju indikator slanja prema FINI postavljen na D dok oni sa indikatorom N koji 

samo dobivaju fiskalni broj ali ne i ZKI i JIR se mogu vraćati iz 3 u 2 (KORLD) 

d) koji su zapisani u prot_fisk bez obzira na sve ostalo 

e) koji se nalaze u uputama za fiskalizaciju bez obzira na indikator slanja prema FINI i postojanje zapisa u 

prot_fisk 


Poštovani, 

Riješeno na način : 

Ne mogu se vraćati iz statusa 3 u 2 računi koji u uputama za fiskalizaciju imaju indikator slanja prema FINI 

postavljen na D 

dok oni sa indikatorom N koji samo dobivaju fiskalni broj ali ne i ZKI i JIR se mogu vraćati iz 3 u 2 

Inače, dozvolu za vraćanje statusa 3 u 2 nemaju svi korisnici nego samo korisnik iz parametra KORLD 

Dakle, 

Za račune koji u fiskalizaciji dobivaju ZKI i JIR (indikator slanja u FINU postavljen na D) onemogućena je izmjena 

statusa 3 u 2 i za korisnika koji ima dozvolu za izmjenu statusa tih dokumenata (KORLD). 


Preuzmite BASE lib koji je na internetu jutros 1.2.2013 



Poštovani, 

Ispravljena je kontrola na prelazak statusa za korisnika KORLD. 

Novi LAUS BASE liba je na internetu. 

S štovanjem 


POŠTOVANI, 

MOLIMO SUGLASNOST ZA ZATVARANJE ZAHTJEVA - RIJEŠEN 


Poštovani, 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


Nadopuna zahtjeva 13082! 

Svakve neprenesenih cjenika: 

321944 –novi artikl 

321945—novi artikl 

321944 

319980 

13082 



29.01.2013 07:13 

Upisao: 

Božo Mišeta 

Područje: 

LTRAN 


29.01.2013 


Danas, kod puštenog prijenosa hp_lm_jtr PRIJENOS ŠIFARNIKA U MIPS (F1- SVE),nisu nam se 

prenijeli slijedeći cjenici: 

1300045 

1300046 

1300047 

1300048 

Cjenici su aktivni, vrijede od sutra, imaju svaki po jedan artikal koji je aktivan, imaju podatak STS, imaju 

upisanog dobavljača…. 

Razlog njihovog neuspjelog prijenosa nismo našli, pa vas molimo da pogledati gdje je zapelo. 



0


Status: 








Stranica: 

872/108 

0











Klijent: 





Hitnost: 



Glorija 


13080 



28.01.2013 10:50 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


10.02.2013 


Molimo da se navedeni objekt Ručni unos faktura prilagodi (ili da se napravi novi objekt po uzoru na 

navedeni) za izradu storno računa iz MIPS aplikacije. 

Orgj – svi poštanski uredi (šifre Divizije mreža iz org. strukture, dodatni podatak SS2). Zbog knjige PDVa 

računi moraju u protokolu imati orgj poštanskog ureda. 

Morati će se pridijeliti oznake poslovnog prostora, ali se neće prijavljivati prema poreznoj, jer su već 

prijavljene, već će se samo unijeti kao da su prijavljeni. Također za sva ta prodajna mjesta će se definirati 

upute za fiskalizaciju (HP). 

Vrsta protokola – 5 

Vrsta dokumenta – GOT, GR1, VR1, KAR, KR1 

Vrsta računa – 4 Evidencija MIPS dokumenata 

Način plaćanja – čitati iz veze sa vrstom dokumenta i po uputi fiskalizirati 

Otpremnica – izmijeniti na način da polje bude obavezno za unos ali da se ovdje upisuje originalni broj iz 

MIPSa (znači samo vrstu 4 proizvoljan upis u polje). 

Izmijeniti naziv polja u npr: Otpremnica/orig.broj 

Prilikom unosa stavki dokumenta omogućiti unos svih stavki/transakcija kao u MIPS aplikaciji ili omogućiti 

slobodan unos (bez povlačenja šifri). 

Za potrebe fiskalizacije – trenutno se provodi automatska fiskalizacija računa prilikom likvidiranja – to nije 

dobro jer se trebaju fiskalizirati samo računi koji su fiskalizirani u MIPSu - na osnovi podatka da li je 

originalni dokument fiskaliziran ili ne korisnik donosi odluku mora li fiskalizirati storno računa ili ne. 

Zbog toga za Vrstu računa 4 ne provoditi automatsku fiskalizaciju, već preko tipke Fiskaliziraj operater sam 

može fiskalizirati račun. 



0









Poštovani, 

Dakle radimo opciju : na ekranu ruckat sa vrsta računa 4 

O2. unos stavki ( lm_kat_stav ili neka druga tablica sa indikator RUC ručni unos) 


Vrsta dokumenta – GOT, GR1, VR1 --- zasad se ne radi KAR, KR1 


Način plaćanja – čitati iz veze sa vrstom dokumenta i po uputi fiskalizirati (zahtjev 13079 ) 

Broj naplatnog uređaja ostaje 1 (kao kod svih Laus fisklaiziranih računa) 

Otpremnica – izmijeniti na način da polje bude obavezno za unos ali da se ovdje upisuje originalni broj iz MIPSa 

(znači samo vrstu 4 proizvoljan upis u polje). 

Izmijeniti naziv polja u npr: Otpremnica/orig.broj. 

PITANJE : Obavezno ili nije obavezno za popunit ? 

Prilikom unosa stavki dokumenta omogućiti unos svih usluga i roba koje su definirane u LAUSu. 

PITANJE: koje postoje kao aktivne i nekativne bez obzira jesu li došle iz MIPSA ili ne ? 

Datumom dokumenta regulira se cijena iz cjenika koji je unutar Laus i Mipsa jedinstven tj. na taj datum treba biti 

jednak . 

PITANJE : Što ako PU nije preuzeo taj jednaki cjenik tj treba stornirati račun sa pogrešnom cijenom x ? 

drugim riječima treba li ili ne uvijek 'vući' važeće cijene iz cjenika roba/usluga ili ne ? 

za Vrstu računa 4 ne provoditi automatsku fiskalizaciju na prelazu statusa , već preko tipke Fiskaliziraj 

PITANJE : u kojem status je dozvoljeno fiskalizirati račun vrste 4 ? 1, 2 bilo kojem ,... 


Poštovani, 

Ostalo je još nedorečeno : 

Storniranje računa vrste 4 ( računi iz MIPS-a) na ruckat : 

a) je zabranjeno 

b) je dozvoljeno i odrađuje se fiskalizacija automatski kao i za ostale kod storniranja 

c) je dozvoljeno ali samo se događa promjena statusa 3-->9 za račun koji se stornira , ne nastaje novi storno 

dokument automatski nego se unosi ručno i fiskalizira sa Fiskaliziraj 

d) je dozvoljeno i automatski nastaje storno dokument ali se ne fiskalizira automatski nego preko Fiskaliziraj 

Molimo odredite kako to treba podržati 



0









Poštovani, 

Molimo pojašnjenje navoda : 

Morati će se pridijeliti oznake poslovnog prostora, ali se neće prijavljivati prema poreznoj, jer su već prijavljene, 

već će se samo unijeti kao da su prijavljeni. Također za sva ta prodajna mjesta će se definirati upute za 

fiskalizaciju (HP). 

Razlog : ne znamo treba li mijenjati postojeću kontrolu za račune vrste 4 

Sad program kod slanja na fiskalizaciju za slučajeve fisk_up.ind=D (šalje se u poreznu ZKI i JIR) fiskalizacija se 

neće obaviti : 

a) ako poslovni prostor nema pospr.ind=D 

b) ako za njega nije evidentirano radno vrijeme tj. ne postoji za njega niti jedan slog u fisk_radvr koji zadovoljava 

( datum_do = '' or datum_do is null ) 


Poštovani, 

Na objektu ruckat.jas kod promjene statusa za fakture koje imaju vrstu računa 4 (evidencija MIPS dokumenata) 

postavljeno je da se ne odrađuje automatska fiskalizacija ukoliko faktura ulazi u dokumente koje se prema 

uputama šalju na fiskalizaciju. 


Obavijestiti korisnika o preuzimanju novog WIN FAUS liba. Lib je na internetu. 



0









Poštovani, 

Na objektu ruckat.jas je omogućena izrada storno računa iz MIPS aplikacije. 

Kod evidentiranja takvog računa potrebno je na polju Vrsta računa odabrati 4 - Evidencija MIPS dokumenta. 

račun se evidentira na poštanski ured. U polje otpremnica se upisuje originalni broj iz MIPS-a (nije obvezan za 

unos). 

Za račune kojima je izjava=D evidentira se vrsta protokola I, inače se evidentira vrsta protokola 5. 

Kod unosa usluga u račun, usluga mora biti definirana u cjeniku, ali se cijena na ekranu može prekucat (jedini 

uvijet je da cijena mora birti veća od nule). 

Dozvoljen je unos količine i vrijednosti u minusu. 



Mollimo povratne informacije . 

NAPOMENA : 

Ostalo je još napraviti storniranje za vrstu računa 4 - zasad ne koristiti ako originalni račun nije bio fiskaliziran . 

Storniranje je dozvoljeno i odrađuje se fiskalizacija automatski kao i za ostale kod storniranja - ali automatski 

fiskalizacija može samo u slučaju ako program prepoznaje da li je originalni račun bio fiskaliziran - ako je 

fiskaliziran original mora fiskalizirati i storno, ako original nije fiskaliziran onda ne smije biti ni storno računa 

fiskaliziran . 

Prema dogovrenom je napravljeno : 

unos stavki ( lm_kat_stav ili neka druga tablica sa indikator RUC ručni unos) 

## HP: Može lm_kat stav i indikator RUC. 

Orgj – svi poštanski uredi sa dodatni podatak SS2. Zbog knjige PDVa računi moraju u protokolu imati orgj 

poštanskog ureda. 


Vrsta dokumenta – GOT, GR1, VR1 --- zasad se ne radi KAR, KR1 


Otpremnica – isamo vrstu 4 proizvoljan upis u polje.Izmijeniti naziv polja u npr: Otpremnica/orig.broj. 

##HP: Može. 

PITANJE : Obavezno ili nije obavezno za popunit ? 

## HP: Nije obavezno. 

Prilikom unosa stavki dokumenta omogućiti unos svih usluga i roba koje su definirane u LAUSu. 

PITANJE: koje postoje kao aktivne i nekativne bez obzira jesu li došle iz MIPSA ili ne ? 

## HP: Svih – nema kontrole. 

Datumom dokumenta regulira se cijena iz cjenika koji je unutar Laus i Mipsa jedinstven tj. na taj datum treba biti 

jednak . 

PITANJE : Što ako PU nije preuzeo taj jednaki cjenik tj treba stornirati račun sa pogrešnom cijenom x ? 

drugim riječima treba li ili ne uvijek 'vući' važeće cijene iz cjenika roba/usluga ili ne ? 

## HP: Nema kontrole – upisuje se količina i proizvoljna vrijednost. Iz cjenika se prema datumu čita da li ima 

PDV i koliko ili nema. 



0









Poštovani, 

Opis obrade: 

Napravljeno je kod storniranja za novi storno račun de se odradi automatska fiskalizacija samo u slučaju ako je 

fiskaliziran original. 

Ako original nije fiskaliziran onda neće biti ni storno računa fiskaliziran. 


Obavijestiti korisika o preuzimanju novog WIN FAUS lib. Novi lib je na internetu. 


Poštovani, 

Isporučene su sve tražene funkcionalnosti po izvornom zahtjevu . 


Vezano za dopune koje ste naknadno poslali , molimo pošaljite novi HP broj zahtjeva . 

Možemo otvoriti novi KZ sa istim HP brojem 13080 ali mislim da to nikome ne odgovara . 

Molimo pošaljite što ste odlučili 

Radi se o dopunama : 

Dopuna_v1: 5.2.2013 

Kod unosa analitike (Kupac) potrebno omogućiti i bez analitike -, te tome prilagoditi sve preglede, ispise i 

objekte. 

Na ekranu Pregleda potrebno omogućiti pretragu i po vrstu Vrsti računa. 

Dopuna_v2: 5.2.2013 

Promjena plana … ne otvarati – bez analitike već O (upisivati će se PU na kojega se odnosi) i onda se da se na 

nju mogu raditi GOT i GR1 samo vrstu računa 4 dok naravno za VR1 je P 

… napravite kada stignete mi testiramo kod korisnika i isporuka 

Misli se samo na ovaj objekt ruckat ako se o njemu govori i naravno pregledi i ispisi koji se sa njim vezani … 

do sada se u evidenciji ti računi GOT I GR1 vodili sa - a VR1 sa P i sve je normalno odsjedalo u IRA 

Na ispis nema nikakve ugradnje Vrsta računa samo da se omogući pretraga po njima 

jer sada se zapravo dobiju različite kombinacije svakakvih računa iz evidencije. Tj. kako na pregledu npr. dobiti 

GOT od kataloške ili ovaj ili neki … 


Poštovani, 

Dogovoreno je s g-đom Brankom Mihaljević termin za testiranje : 

utorak 12.02.2013 u 9:00 , Branimirova 4 , soba 407 na 4. katu ( Računovodstvo ) 

Pripremit će primjere koje bi trebali provesti na ruckat sa opcijom vrsta računa 4 - storno računa iz MIPS-a 


Poštovani, 

Isporučene su sve tražene funkcionalnosti po izvornom zahtjevu 13080 , KZ 40945 . 


Za rješavanje dopuna zahtjeva 13080 koje ste naknadno poslali , otvorili smo KZ 41292 sa istim HP brojem 

13080 . 



0









Poštovani, 

Zahtjev 13080 /40945 inicijalni zatvaramo uz vašu suglasnost . 

Zahtjev 13080 /41292 dopuna ostaje otvoren jer nije još sve riješeno za gotovinske po zapisniku. 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Glorija 

13079 



28.01.2013 09:54 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


02.02.2013 




0









Definirati šifarnik načina plaćanja prema u kojemu bi se vodili samo propisani načini plaćanja zakonom. 

Omogućiti da se naziv tog načina plaćanja može upisati na hrvatskom i engleskom, te previdjeti njegovo 

vezivanje sa vrstama dokumenata. Za potrebe fiskalizacije potrebno je na objektima za izradu izlaznih 

računa, za sve račune u HP-u dodati polje način plaćanja. 

Prema Zakonu oznake načina plaćanja su: - novčanice 

- kartica 

- ček 

- transakcijski račun 

- ostalo 

Kod računa za katalošku, digitalnu i filatelističku prodaju (ruckat.jas i rucfil.jas) omogućiti unos tog polja i 

njegovo ispravno ispisivanje na računu, te fiskaliziranje po izabranom načinu plaćanja. Kod izlaznih računa 

koji nastaju generiranjem iz naloga taj način plaćanja automatski puniti kao Transakcijki račun (fakt.jas, 

fakpl.jas, fakhp.jas). Storno fakture (faksto.jas) preslikava način plaćanja originalne fakture. Kod ručnih 

unosa faktura (rususl.jas, rucfak.jas i rucfakd.jas) potrebno omogućiti unos definiranih načina plaćanja. Kod 

računa za filateliju način plaćanja ispisivati na engleskom. 

vidi prilog 

Ako se izabere Vrsta računa 2 ili 3 (digitalna) vrsta dokumenta je DIG (staviti na ekran ali sivo), a vrsta 

protokola 0 ili 5 (kao i do sada). Jedino polje Način plaćanaj izmijeniti da se upisuju samo načini plaćanja 

definirani zakonom . Kod dokumenta DIG ostaviti operateru za slobodan upis. Kakav upis načina tako se 

mora ispisati i na ispisu računa. Kod objekta (rucfil.jas) dokument IRI slijediti jednaku logiku tj. otvoriti polje 

Način plaćanja i operateru dozvoliti upis i ispis na računu, jedino što u tom slučaju ispis naziv načina mora 

biti na engleskom. 

Kod objekta za katalošku, izbor vrste računa 1, potrebno dozvoliti izbor polja Vrsta dokumenta. Ovisno o 

tom polju automatski puniti način plaćanja 

GOT, GR1 – „Novčanice“ 

VR1 – „Transakcijski račun“ 

KAR, KR1 – „Kartica“ 

Kod uputa za fiskalizaciju sada se za kombinaciju orgj, vrsta dokumenta i vrsta protokola može izabrati 

samo jedan način plaćanja. To nije dobro jer npr. za IRI, protokol 9 i nivo 01400 može biti bilo koji način 

plaćanja, a mi možemo definirati koji ćemo slati na fiskalizaciju putem indikatora. Potrebno upute izmjeniti 

na način da se mogu razne kombinacije provesti ( fisk_up_jm UPUTE ZA FISKALIZACIJU). 



0









Poštovani, 

Molimo poašljite odgovore na pitanja . 

Status : čeka se pojašnjenje HP-a 

Kod ručnih unosa faktura (rususl.jas, rucfak.jas i rucfakd.jas) potrebno omogućiti unos definiranih načina 

plaćanja. 

PITANJE : na koji način (prelaz statusa, Fiskaliziraj ili pregled nefisk. računa , prot_fm evidencija dokumenta ) 

će se ovi računi fiskalizirati ? 

Kod računa za filateliju način plaćanja ispisivati na engleskom. 

--- rješava se po zahtjevu 13093 

Kod računa na ruckat definiran je rad programa za slučejeve izbora vrste računa : 

1 katalošlka prodaja 

2 ili 3 digitalna TV 

PITANJE za vrsta računa 4 (strorno računa iz MIPS-a) program treba raditi na neki novi način ili kao što je 

definirano za vrsta računa 1 ? 

Definirano za vrsta računa 1 : 

Ovisno o vrsti dokumenta automatski puniti način plaćanja 

GOT, GR1 – „Novčanice“ 

VR1 – „Transakcijski račun“ 

KAR, KR1 – „Kartica“ 


Poštovani, 

Na objektima automatskog generiranja faktura iz naloga (fakt.jas, fakpl.jas, fakhp.jas) kao i kod storno fakture 

(faksto.jas) 

napravljeno je da se za nastale račune (vrsta prootkola 0) formira i fiskalni/porezni broj (upiše se u tablicu 

prot_fisk). 

Način plaćanjase puni kao T-Transakcijki račun. Storno preslikava način plaćanja originalne fakture. 


Instalacija: sutra 05.02.2013 bit će dostupan novi WIN FAUS lib. 

S štovanjem 


Poštovani, 

Napravljen je šifarnik načina plaćanja. Objekt je fnacpla_jf. 

Šifarnik je u panther FINK-u . 

Predlažemo : 

a) smjestiti ga meni: 

Financije i knjigovodstvo, Opći podaci, Osnovni šifarnici 

b) nazvati ga : 

fnacpla_jf NAČINI PLAĆANJA ZA FISKALIZACIJU 

Molimo pošaljite vaš stav 



0









Poštovani, 

Napravljen je šifarnik načina plaćanja u kojemu će se voditi samo propisani načini plaćanja zakonom. 


Sutra preuzeti novi laus/fink lib. 

Izvesti sql: 

create table "l1fink".fisk_nacpla 

( 

fisk_nacpla char(1) not null, 

naziv nchar(70) not null, 

nazive nchar(70) not null, 

aktivnost char(1) not null, 

uradio char(8), 

datum date, 

vrijeme char(5), 

terminal varchar(30,8) 

); 

grant all on "l1fink".fisk_nacpla to "public"; 

create unique index "l1fink".fisk_nacpla on 

"l1fink".fisk_nacpla (fisk_nacpla); 

Opis radnog zadatka: 

Definirati šifarnik načina plaćanja prema u kojemu bi se vodili samo propisani načini plaćanja zakonom 

Oznaka načina plaćanja char 1 

naziv na hrvatskom char 60 

naziv na engleskom char 60 

--uradio,datum,vrijeme









Poštovani, 

Molimo još odgovor na pitanje : 

Kod računa na ruckat definiran je rad programa za slučejeve izbora vrste računa : 



PITANJE za vrsta računa 4 (strorno računa iz MIPS-a) program treba raditi na neki novi način ili kao što je 

definirano za vrsta računa 1 ? 


Poštovani, 

Za potrebe testiranja fiskalizacije postavili smo mogućnost slanja računa na fiskalizaciju na : 

prot_fm EVIDENTIRANJE DOKUMENATA (F1 Dalje, F8 Dod., FISKALIZACIJA) 

fiskn_jm Pregled neposlanih ra una na fiskalizaciju (F1 Fiskaliziraj) 

fisk_jm Pregled slanja fiskalizacije ra una (F3 Šalji) 

Obzirom na specifične potrebe automaticajie fiskalizacije koje ste iskazali naknadnim zahtjevima kao što je ovaj 

te obzirom da se neki od računa uvjetno fiskaliziraju (vrsta računa 4 na ruckat) smatramo nužnim ukinuti 

fiskalizaciju na : 

prot_fm EVIDENTIRANJE DOKUMENATA (F1 Dalje, F8 Dod., FISKALIZACIJA) 

NAPOMENA : Ako smatrate nepotrebnom / štetnom i neku drugu gore navedenu mogućnost slobodno navedite 

status : čekamo stav HP-a u vezi gore navednog kao i termin isporuke promjena vzano za fiskalizaciju 


Poštovani, 

Molimo stav HP vezano za upis načina plaćanja za fiskalizaciju kod : 

a) rususl.jas 

PTANJE : upisuje se T-transakcijski račun ili treba omogućiti fakturisti da sam upiše ili program treba temeljem 

vdok ili drugih podataka upisati odgovarajući ? 

b) računa preuzetih iz BSS-a - DTV 

(veza zahtjev 13093 : Sve navedeno za sada se neće odnositi samo na račune koje nastaju u Billingu. ) 

-- dosad pojašnjeno : 

LAUS: Računi koji nastaju u billing-u ne smiju moći ispisati u LAUS-u ? 

HP :Mogu li se ispisati igdje računi preuzeti iz BSS-a ? 

LAUS: mogu na ruckat . 

PITANJE : Treba li zabraniti ispis računa iz BSS-a ili ispis treba ostati samo za internu upotrebu tj. ne šalje se 

izvan HP ? 

LAUS :Računi koji nastaju u billing-u ne smiju se moći fiskalizirati u LAUS-u ? 

HP: DA , ne smiju se fiskalizirati u LAUS-u 

LAUS Kako bi se spriječila njihova fiskalizacija u LAUS-u predlažemo : 

Kod preuzimanja računa iz BSS-a puniti polje način plaćanja za fiskalizaciju sadržajem X (lm_usl_fak) . 

Kod slanja na fiskalizaciju (vrsta računa 2 i 3) onih račuuna koji imaju način plaćanja za fiskalizaciju =X ista se 

neće izvršiti 

ako u uputama nema kombinacije sa način plaćanja X . 

Poruka : račun nije fiskaliziran - nije u uputama . 

NAPOMENA : računi preuzeti iz BSS nalaze se u bss_vezar tablici . Ako treba ispisjuju se i fiskaliziraju u BSSu 

. 



0









Poštovani , 

Vezano za prijedlog u prethodnoj obradi 11 za slučaj 

Računi koji nastaju u billing-u ne smiju se moći fiskalizirati u LAUS-u 

------------ 

Prijedlog 1 iz obrade 11 : 

LAUS Kako bi se spriječila njihova fiskalizacija u LAUS-u predlažemo : 

Kod preuzimanja računa iz BSS-a puniti polje način plaćanja za fiskalizaciju sadržajem X (lm_usl_fak) . 

Kod slanja na fiskalizaciju (vrsta računa 2 i 3) onih računa koji imaju način plaćanja za fiskalizaciju =X ista se 

neće izvršiti 

ako u uputama nema kombinacije sa način plaćanja X . 


--------------------- 

Imamo novi prijedlog a vezan je za novi HP zahtjev broj 13115 od danas : 

Prilikom prijenosa faktura za uslugu evoTV iz Billinga u Laus, fakture je u Lausu potrebno evidentirati na 

novootvorenu vrstu dokumenta BSS... 

-------------------- 

Prijedlog 2 : 

Kod preuzimanja računa iz BSS-a puniti polje način plaćanja za fiskalizaciju sadržajem T,G,C,K ili O 

(lm_usl_fak) . 

Kod slanja na fiskalizaciju (vrsta računa 2 i 3) onih računa koji imaju vdok=BSS ista se neće izvršiti 

ako u uputama nema kombinacije sa vdok=BSS. 


----------------- 

Molimo izjasnite se koji prijedlog prihvaćate te ako je to prijedlog 2 odredite način plaćanja za fiskalizaciju BSS 

računa 

jer se formalno mora popuniti iako se ne fiskaliziraju u LAUS-u . 


Poštovani. 

Na objektu rucfil.jas nadodano je polje način plaćanja. 

Unos računa sada ide i u tablicu lm_usl_fak i u tu tablicu se zapisuje podatak o načinu plaćanja. 

Izmjene su napravljene kod unosa, izmjene, brisanja i storna računa. 

Instalacija: U utorak ujutro (19.02.2013) isporučiti novi WIN FAUS lib. 

Korisniku poslati sql: 

ALTER TABLE lm_usl_fak ADD ( 

fisk_nacpla char(1) BEFORE nacpla ); 

S štovanjem 



0









Poštovani , 

Na objektu za ručni unos računa kataloške prodaje (ruckat.jas) omogućen je unos i načina plaćanja. Zbog toga 

se ovi računi pune i u tablicu lm_usl_fak. 

Za vrste računa 1 i 4 način plaćanja se automatski puni ovisno o vrsti dokumenta: 

GOT, GR1 – „Novčanice“ G 

VR1 – „Transakcijski račun“ T 

KAR, KR1 – „Kartica“ K 

Za vrste računa 2 i 3 korisnik sam upisuje način plaćanja iz šifarnika. 


Instalacija: u utorak ujutro (19.02.2013) preuzmite novi WIN FAUS lib. 


NAPOMENA : 

ruckat definiran je rad programa za slučejeve izbora vrste računa : 



4 strorno računa iz MIPS-a) 

Upisuju se samo načini plaćanja definirani zakonom tj ponuditi iz šifarnika fisk_nacpla 

Podatak se upisuje prot_fisk kod fiskalizacije i tako se mora ispisati i na ispisu računa. 

Šalje li se ili ne ZKI za kombinaciju orgj-vdok-fisk_nacpla iz računa čita se iz uputa za fiskalizaciju (fisk_up) 



0









Poštovani, 

U prilogu je rekapitulacija isporučenih programskih izmjena vezano za dorade na fiskalizaciji prema specifičnim 

potrebama korisnika . 

Većina je isporučena - detaljno u prilogu .j 

Prije stavljanja na produkciju potrebno je : 

a) istestirati u prilogu opisane isporučene funkcionalnosti 

b) izvesti intervencije nad podacima u bazi koje trebamo usaglasiti/dogovoriti a vezano za popunu podataka za 

fiskalizaciju : 

b1 - fisk_nacpla : način plaćanja za fiskalizaciju u računima u tablici lm_usl_fak 

b2 - prot_fisk : generiranje fiskalnog/ poreznog broja računa kako je propisala PU : rbr-orgj-1 

Načelno predlažemo popuniti : 

b0 - upisati ako ne postoji u lm_usl_fak slog za račune koji su 2013 godina nastali u LAUS-u (protokol 0) ili 

nastali na ruckat,rucfil 

b1- prema odrednicama kako su opisane u dokumentu u prilogu za sve dokumente kojima je vprotokol.uliz=I i 

godina=13 a nisu gotovina iz PU 

(postoje u lm_usl_fak ) upisati fisk_nacpla 

b2- za sve kojima je upisan b1 upisati slog u prot_fisk , osim za : 

o1--preuzete iz BSS-a 

o2 --vrsta računa 4 na ruckat (indikator=RUC) 

o3 - račune koji se prema uputi šalju u FINA-u (fisk_up.ind=D) sa ZKI i dobivaju JIR 

o4 - rčune koji su već upisani u prot_fisk 

Kod upisa b2 koristiti podatke : 

-- iz rad_protokol i to iz min(datum) za status >=3 : korisnik ---> uradio 

datum --> datum,datum_p,datum_isp 

- iz lm_usl_fak.fisk_nacpla ---> nacpla 

protokol ---> protokol 

godina '2013' 

br_fisk slijedeći u godini za prod_mj i pospr 

pospr '1' 

prod_mj iz šifranika 

zki '' jir '' ind N 

NAOMENA : upisom sloga za račun u prot_fisk tablicu mijenja se izgled računa u ispisu prema zahtjevu 13093 

pa ako to želite spriječiti potrebno je navesti ograničenja (osim o1,o2 , o3 i o4 ) koja treba uzeti u obzir kod upisa 

u prot_fisk tablicu 



0









Poštovani, 

Predložili ste provođenje aktivnosti na produkcijskoj bazi dana 27.2.2013. : 

· 1. Unos poslovnih prostora za izlazne fakture (HP) do 14:00 

· 2. Unos potrebnih uputa (HP) do 14:00 

· 3. Unos šifarnika načina plaćanja (HP) do 14:00 

· 4. Unos korisničkog broja (tablice prot_fisk i potrebno) za sve račune 01.01.2013 koji nisu dobili broj a 

defrinirani uputom (LAUS) od 16:00 - za ovo treba biti proširena lm_usl_fak poljem fisk_nacpla i treba biti za 

račune u 2013 fisk_nacpla popunjen 

· 5 Alteri tablice i kreiranje šifarnika (HP) poslije 16:00 -- treba prije punjenja prot_fisk 

· 6 . Spuštenje libova (HP) ujutro prije 8:00 

Pitali ste : 

Da li Laus može ovo odraditi u srijedu 27.02.2013? 

Preduvjeti: 

1) Ispravak u winfausu poslane greške – na ispisu kataloške i digitalne, gorovina O prije fiskalizacije - 

-------- ovo nije prebitno jer račun neće slati nefiskaliziran vani,a ako se ne fiskalizira uopće (neki računi vrste 

4 ) onda nije ni bitno što piše 

2) Kod gotovinskih računa tipa još nije dozvoljena analitika O 

---------- dopuna 13080 može biti u srijedu 27.2.2013. isporuka tokom dana . 

Odgovor : 

Može samo bi trebalo zamijeniti redoslijed navedenog pod 4. i 5 . (oboje može izvesti LAUS) 

Molimo povratne informacije vezano za redoslijed izvođenja aktivnosti kao i suglasnost da se iste provedu iako 

ne stignemo isporučiti preduvjet pod 1) 


Poštovani, 

Vezano za : 

Ručnu fiskalizaciju kod evidencije potrebno ukinuti, jer zapravo sve je uglavnom definirano da se fiskalizira kroz 

upute pri prelasku iz statusa 2 u 3. 

Ukoliko nešto nije prošlo naknadno se fisklalizira putem pregleda nefiskaliziranih računa. Zbog toga ovo nema 

smisao niti je ikad korišteno. 

Napravili smo : 

Kad se preko prot_fm EVIDENCIJA DOKUMENATA hoće napraviti fiskalizacija : 

-na način 1 : F6 Dod. i sa veza_fm FISKALIZACIJA 

-na način 2 : F1 Dalje , F8 Dod. i sa veza_fm FISKALIZACIJA 

Javi se poruka : Proces fiskalizacije ra un se odrađuje u WIN aplikaciji ! 

Dakle , za INSTA=POSTA ne može se napraviti fiskalizacija računa preko evidencije (prot_fm) 

Potrebno za instalaciju : 

Već je isporučen panther BASE lib na internet 



0









Vezano za pitanja koja ste poslali : 

1. U ovom slučaju br_fisk jednak – da li je ispravno ? 

13758 4630701300074 74 46307 1 

13823 4630701300141 74 46307 1 

2. Također broj korisnički koji se kreirao se prikazuje u – da li je ispravno ? 

198 4630001301910 -11329 46300 1 

anlaizirali smo i zaključili : 

Slučaj 1: 

dva računa imaju isti br_fisk za istu godinu,pospr i prod_mj 

godina pospr prod_mj br_fisk bb 

2013 46307 1 74 2 

2013 35366 1 264 2 

Zaključak : 

Storno ovih dokumenta ne radi dobro : 

umjesto da u prot_fis upiše novi br_fisk za storno račun (minusni račun) , 

upiše se ISTI br_fisk kao kod računa koji je storniran . 

NAPOMENA : dokumenti koji se šalju na fiskalizaciju (imaju zki i jir) nemaju nepravilnost navedenu u slučaju 1 . 

Pitanje : na koji način su stornirani dokumenti 35366-013-00264 i 46307-013-00074 ? 

STATUS: Čekamo odgovor na pitanje kako bismo riješili slučaj 1 

Slučaj2 - minusni br_fisk 

Javio se na pospr za koje je upis rađen 27.2.2013 i to na orgj na kojima je već bilo fiskaliziranih : 

35358 ------------> + 6 

46300 ---------> + 103 

Zaključak : 

greška nije programska . Za te slogove br_fisk sam greškom promijenila tj. nisam ih izuzela iz obrada u pripremi 

za upis novih tako da su postali









Poštovani, 

Na Vaš zahtjev : 

Dokumenti koji su danas 28.2.2013 nastali statusa većeg od 2 i imaju definirane upute za fiskalizaciju, nisu u 

tablici prot_fisk 

– potrebna provjera i njih je potrebno povezati, jer će doći do problema sa slijednošću brojeva 

napravili smo provjeru za slijedeće i zaključili : 

1. Dokument koji i dalje nije u prot_fisk :1100301300322 vdok= KIZ . 

Kamate se rješavaju kroz 13172 . 

STATUS: Poslat ćemo pitanja vezano za KIZ dokumente kroz obrade zahtjeva 13172 

2. danas ujutro 1.3.2013. su ubačeni u bazu (dajana) ostali koje ste naveli (nastaju fakturiranjem) : 

1100301300304 ODO 

4630701300140 RUF 

3536601300262 FAF 

3536601300263 FAF 

3536601300264 FAF 

3536601300265 FAF 

4630701300142 OBN 

3536601300266 FAF 

4630701300143 OBN 

4630701300144 OBN 

PITANJE: Kad se i na koji način** (ekran/tipka) promjeni status iz 2 u 3 za ove dokumente ? 

NAPOMENA: 

Ako se radi o ručnim fakturama napravljenim na ruc* ekranima , onda to još nismo isporučili- rješava se u okviru 

zahtjeva HP 13079 : 

Potrebno je kod izlaznih računa pojedinačne fakrure : rucfak i rucfakd 

za nastale dokumente/račune formirati fiskalni/porezni broj na prelazu sttusa 2 -->3 te ga zapamtiti /upisati u 

prot_fisk . 

U prot_fisk ne može biti dokument sa status3 omogućiti fiskalizaciju napišite 

--------detalji analize u prilogu ------------------------------- 


Na objektu ruckat.jas za ručni unos faktura omogućena je fiskalizacija na promjeni statusa te na objektu 

faksto.jas kod storniranja.ručno unesenih faktura. 

Preuzeti novi WIN FAUS liba u srijedu 6.3.2013. 


Na objektu rucfakd.jas za ručni unos faktura za natječajnu dokumentaciju omogućena je fiskalizacija na promjeni 

statusa. 

Nova verzija WIN FAUS liba je već na internetu. 



0









Poštovani , 

Sve , za HP specifičene dorade , vazano za fiskalizaciju smo napravili (u prilogu specifikacija po zahtjevima ) 

osim za KIZ 

--- rješava se kroz zahtjev 13172 

Danas iza 16 sati ćemo provesti na produkcijskoj LAUS bazi sve potrebne ispravke brojeva korisničkih računa 

te upisati one koji po uputama nedostaju. O svemu učinjenom poslat ćemo zapisnik. KIZ dokumente nećemo 

dirati (dogovor Glorija-Dajana ) 


Poštovani , 

Sve , za HP specifičene dorade , vazano za fiskalizaciju smo napravili ( jučer poslana specifikacija po 

zahtjevima ) osim za KIZ 

--- rješava se kroz zahtjev 13172 

Jučer iza 16 sati intervencijom na produkcijskoj LAUS bazi provedeno: 

a) ispravke brojeva korisničkih računa ( 5 duplih brojeva zbog greške koja je isprsvljena: storno račun je 

greškom imao isti broj kao i stornirani račun) 

b) upisani u prot_fisk računi koji su nedostajali ( 135 nastalih računa preko rucfak* prije nego je omogućena 

automatska fiskalizacija kod : status 2-->3 ) 

Upisani računi imaju obilježja : 

-- po uputama nedostaju tj. nisu fiskalizirani a pstoji uputa po kojoj se trebaju fiskalizirati (fisk_up) 

-- koji imaju status >=3 

-- koji nemaju vdok=KIZ 

-- koji imaju nacpla=T transakcijski račun 

Detalji provedenih izmjena su u prilogu 

Molimo povratne informacije / suglasnost za zavaranje zahtjeva- Riješen 


Na masovnom ispisu faktura FAH sada se prikazuje labela Dospijeće. 

Već je isporučeno. 


Kod ispisa neto faktura sa objekta ručnog unosa faktura (rucfak.jas) nadodan je prikaz fiskalnog broja. 

Izmjena je napravljena i kod pojedinačnog ispisa faktura sa objekta Ispisa faktura (fakis.jas). 

Već je isporučen novi WIN FAUS lib. 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Glorija 


13078 



28.01.2013 09:25 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


10.02.2013 


1. Kod pregleda fiskaliziranih računa (fisk.jas) dodati da se vide svi podaci koji se šalju prema poreznoj i 

sve preuzete povratne informacije. 

2. Također na postojećem pregledu računa za fiskalizaciju omogućiti mogućnost pretraživanja po Datumu 

dokumenta od – do, Datumu fiskalizacije od – do, Vrsti dokumenta, Vrsti protokola i Organizacijskoj jedinici. 

3. Kod načina plaćanja Gotovina promijeniti naziv u Novčanice (definirano zakonom), te taj naziv koristiti u 

svim pregledima i ispisima. 



0









Poštovani, 

Na objektu fisk.jas dodana su polja za pretraživanje po Datumu dokumenta od – do, Datumu fiskalizacije od – 

do, Vrsti dokumenta, Vrsti protokola i Organizacijskoj jedinici. 

Naziv načina plaćanja se sada čita iz šifarnika načina plaćanja za fiskalizaciju (fnacpla_jf). 

Preuzeti novi WIN FAUS liba u utorak 19.2. 

S štovanjem 


Poštovani, 

Nije još riješena točka: 

1. Kod pregleda fiskaliziranih računa (fisk.jas) dodati da se vide svi podaci koji se šalju prema poreznoj i sve 

preuzete povratne informacije. 

Točke 2. i 3. su riješene i isporučene 18.2.1013. 

Problemi vezano za fiskalizaciju riješeni su i isporučeni kroz 13079 (rucfak, rucfakd, faksto te provjera u bazi ) 


Poštovani, 





0











Klijent: 



Pitanje 


Hitnost: 

Vrlo hitno 


Glorija 


13076 

Ako se zadaju ovi podaci lista se dobije. 

vidi prilog 

Riješen 


28.01.2013 07:19 

Upisao: 

Božo Mišeta 

Područje: 

WINTRAN 


29.01.2013 

A ako se zada grupa GOTST u kojoj je ova orgj i aktivna je podaci se ne dobiju. 



Poštovani, 

Ispravlejn je ispis kontrolnih lista konr_ul.trn kada se radi o ispisu ZA ZADUŽENJE OD DEPO-a sa uvjetom na 

organizacjsku grupu. 


S štovanjem 



0











Klijent: 





PDV obrasci 2013 

Hitnost: 

Vrlo hitno 


ivan, kramer 


13077 

Potrebno podržati zakonsku promjenu obrazaca za PDV 



25.01.2013 17:34 

Upisao: 

Dajana Lekić 

Područje: 

LFINK 


05.02.2013 


Ministarstvo financija, Porezna uprava, objavilo je nove obrasce knjige ira, ura i pdv koji se koriste od 

01.01.2013., 

u Lausu bi ih trebalo staviti pod novi objekt ME2365 PDV_POREZ NA DODANU VRIJEDNOST (OD 

01.01.2013.) 

(http://www.porezna-uprava.hr/propisi/obrasci.asp?sel=PDV&sid=16&str=2&id=b04d3 ) 



0









Poštovani, 

za obrsce PDV-a računi po stopama 5 i 10 kao i 22 i 23 idu u isti stupac 

Na svim ispisima službenih obrazaca (papirnato i elektronski ) te knjiga URA/IRA rade se potrebne izmjene u 

skladu s tim. 

Međutim, 

radi lakše kontrole i obračuna PDV-a predlažemo odvojen prikaz podataka za svaku stopu PDV-a na kontrolnim 

ekranima/tipkama ( u prilogu) 

koji su radni i pomažu kod obračuna a ne šalju se izvan firme. 

Prijedlog potaknut analogijom kao kod promjene PDV obrazac za 01.03.2012 po zahtjevu HP 12095 

Čekamo Vaš stav vezano za prikaz različitih stopa na kontrolnim ekranima 

- kontakt u HP : Snježana Kramer 


Poštovani , 

Zbog zakonske promjene u sustavu PDVa napravljeni su novi obrasci za prijavu PDV-a te ispisi knjiga URA/IRA 

(PDV). 

Novi ispisi i obrasci koji vrijede od 1.1.2013 su zakačeni na novom meniju : 

ME2365 PDV - POREZ NA DODANU VRIJ.(OD 01.01.2013.). 

koji je prijavljen na postojećem ME236 , izbor 9 . 

Promijenjen je naziv objekta ME2364 . 

Novi naziv: PDV - POREZ NA DOD.VRIJ.(01.03.2012.-31.12.2012.) 

Prijavljeni su na ME2365 novi objekti : 

objekt naziv 

knirN_jf KNJIGA IZLAZNIH RAČUNA (PDV) - 25% 

knurN_jf KNJIGA ULAZNIH RAČUNA (PDV) - 25% 

ob_pdvN_jf PDV - OBRAZAC 

ob_pdkN_jf PDV - K OBRAZAC 

te još i postojeći objekti : 

ldp_jf - KONTROLNI PREGLED DOKUMENATA ZA PDV 

ppd_jf - RAZLIKE PDV-A PO IZLAZNIM I ULAZNIM RAČUNIMA 

NAPOMENA : 

knirN_jf - KNJIGA IZLAZNIH RAČUNA (PDV) - 25% 

knurN_jf - KNJIGA IZLAZNIH RAČUNA (PDV) - 25% 

F2 Ukupno : kontrolne sume su razdvojene po stopama 0, 5,10,22,23 i 25 

ob_pdvN_jf - PDV - OBRAZAC 

ob_pdkN_jf - PDV - K OBRAZACkontrolni pregled ukupnih iznosa F1 Izlaz i F2 Ulaz razdvojeni su po stopama 

0, 5,10,22,23 i 25 

NA ispisima knjige URA/IRA kao i na obrascima stope su grupiranje prema zakonskim odredbama : 

0 te 25 svaka zasebno prikazana 

a 5 i 10 te 22 i 23 zajedno prikazane 


Preuzmite novi LAUS FINK lib koji je na internetu od 13.2.2013. ujutro 

Preuzmite nove objekte i menije koji su na internetu od 13.2.2013. 




0









Poštovani, 

Ispravljene su uočene greške na novom obrascu za PDV kao i kod ulaska na objektima za knjige 

ulaznih/izlaznih računa. 


preuzmite novi LAUS FINK lib koji je na internetu. 



Poštovani, 




0











Klijent: 





Hitnost: 

Vrlo hitno 












Klijent: 





Hitnost: 

Vrlo hitno 


Glorija 


13074 

Riješen 


25.01.2013 11:35 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


25.01.2013 


Kod unosa ugovora sa kupcem potrebno je svuda maknuti Poruku da partner nije nositelj saldakonta. 



0









Poštovani, 

Ovaj zahtjev spada u domenu adaptivnog održavanja, jer se radi o promjeni poslovnih pravila koju LAUS sustav 

mora podržati. 

Načelo defnirano na sastanku 24.1.: 

- za dobavljače: račun i ugovr moraju bit na nositelju salda-konta 

- za kupce : račun i ugovor u pravilu nisu na nositelju salda-konta (promjena u odnsu na dosadašnju praksu ) 

Zbog izmjene poslovnih pravila mijenjat će se nekoliko obrada, od kojih su za neke poslani, a za neke 

očekujemo zahtjeve. 

- izmjene u obračunu kamata zahtjev HP broj 13068 

- izmjene zahtjeva vezano za knjiženje na nositelja salda-konta, a da to nije analitika iz dokumenta (još nije 

definiran zahtjev) 

- obrada opomena (još nije deifniran zahtjev) 

- priprema i listajne IOS (još nije definriran zahtjev) 

- prikaz top kupaca u HP MIS (još nije definiran zahtjev) 

Molim da sve ove zahtjeve definiramo kao adaptivno održavanje. 



Kod unosa ugovora sa kupcem maknuta je kontrola da partner mora biti nositelj saldakonta. 

Instalacija: novi WIN FAUS lib će bit na internetu sutra 07/02/2013. 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Ivan 


13073 



25.01.2013 08:11 

Upisao: 

Božo Mišeta 

Područje: 

LFINK 


25.01.2013 


Molimo da se na ispisu opomena kupcima (Opo_hp_ff) nadoda iza žiro računa HP – a IBAN HP – a HR 

1623900011100018674 


Poštovani, 

Kod ispisa opomena na ekranu opo1_hp_ff na tipku F6 Opomene u listi opo_hp se ispisuje žiro račun sa ekrana 

koji se prilikom ulaska na ekran čita iz dodatnih podatak korisnika za tip dodatnog podatka ZIR. 

Kako ziro račun ovisi o dodatnim podacima korisnika fiskno upisan tekst IBANa ne bi bilo dobro rješenje jer se 

može dogoditi da ZR i IBAN ne odgovarju 1 drugom . Osim toga , fleksibilnije je čitai podatak iz baze nego hard 

code za slučaj da se mijenja . 

prijedlog je da se IBAN čita također iz dodatnih podataka korisnika gdje je tip dodatnog podataka IBN. 

Molimo također da nam pošaljete točan primjer teksta u djelu rečenie gdje želite ispisivati ŽR i IBAN. 

Trenutno u teksu stoji "žiro račun broj: 2390001-1100018674". 

Najbolje poslati primjer ispisa opomena sa upisanim IBAN na točnom mjestu gdje i program treba ispisati 

Molimo vaš stav u vezi predloženog te primjer ispisa sa upisanim IBAN 


Poštovani, 

U ispisu opomena opo_hp podatak IBAN je dodan u liniji ispod broja žiro računa te se čita iz tipa dodatnog 

podatka IBN za korisnika. 


Obavijestiti korisnika o preuzimanju LAUS FINK liba. Lib je na internetu. 

Molomo povratne informacije/ suglasnost za ztvaranje zahtjeva - rIješen 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Glorija 


13072 



24.01.2013 13:59 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


24.01.2013 


Na testu napravljena faktura u valuti 840 dolar 0140091300004 koja je neispravno legla u tablice. U polju 

protokol vrij_p nema podatka, valutni dio je kunski, idev u protdev je 0, u prot_neop nema ničega. Kada se 

faktura stornira (tipka Storno u Poslovima) nastane dokument 0140091300004 koji je samo u tablici 

protokol i lm_fil_stav sa negativnim iznos a nije podatak uopće vidljiv na pregledu jer ga nema u tablicama 

protdev i prot_neop. Znači storno treba preslikati originalnu fakturu po svim tablicama. 


Poštovani, 

Ispravljena je evidencija iznosa u tablici protokol kao i zapis storno sloga u tablicama protdev i prot_neop. 

Lib je na internetu WIN FAUS liba . 

S štovanjem 


Poštovani, 

Ispravljeno je i punjenje iznosa prilikom prijenosa artiikala iz otpremnice. 


Preuzmite : novi WIN FAUS lib će biti dostupan sutra. 26.1.2013 

Molimo suglan ost za zatvaranje zahtjeva - Riješen 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Glorija 


13071 



24.01.2013 13:30 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


24.01.2013 


Kod unosa računa za filateliju u valuti dolar (840) dolazi do neispravnog punjenja kunskog iznosa u tablice 

protokol, prot_neop i slanje za fiskalizaciju. Umjesto preračuna za valutu dolar (840) napuni se iznos sa 

potpuno krivim izračunom tečaja po partneru, tečajnoj listi i valuti bez obzira što je u tablici prot_dev 

ispravna valuta i tečajna lista. 

Račune ćemo stornirati, jer nikakvi ispravci po njima nisu mogući zbog fiskalizacije, te ćemo nakon 

instalacije ispravnog programa napraviti ponovno račune sa ispravnim iznosom (sva sreća što ih je samo 

5). 

select * from protokol 

where protokol='0140091300002'; 

select * from prot_neop 


select * from protdev 


select * from lm_fil_stav 



Poštovani, 

Ispravljena je greška kod izračuna kunskog iz deviznog iznosa po valuti na koju je evidentirana faktura. 


Preuzimite WIN FAUS lib u petak 25.1. ujutro. 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Višnja 


13070 



24.01.2013 11:33 

Upisao: 

Božo Mišeta 

Područje: 

LFINK 


28.01.2013 


Potrebno je kroz pna_kot_jf PRIJENOS PUTNIH NALOGA KOTAČ / LAUS preko F2 Greške ekran 

pna_gres_ff Pregled grešaka prijenosa podataka KOTAC -> LAUS proširiti podatkom 'Originalni 

broj' (podatak boriginal u tablicama kotac_nalog i kotac_stavke) i omogućiti ispis tog podatka kroz listu 

pna_gres_rf: 


Poštovani, 

kroz ovaj KZ rješava se dio zahtjeva 13070 - adptivno održavanje 

Na objektu pna_kot_jf PRIJENOS PUTNIH NALOGA KOTAČ / LAUS preko F2 Greške ekran pna_gres_ff 

Pregled grešaka prijenosa podataka KOTAC -> LAUS dodano je novo polje 'Originalni broj' u pregledu/ispisu sa 

filter poljem za pretraživanje. 



Molimo povratne informacije/suglasnost za zatvaranje zahtjeva - riješen 


Poštovani, 

Ispravljena je greška dupliranje podataka na ekranu pregleda grešaka prijenosa naloga KOTAC -> LAUS. 

Preuzeti novi LAUS FINK liba u srijedu 6.2.2013. 

S štovanjem 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13069 



24.01.2013 11:30 

Upisao: 

Božo Mišeta 

Područje: 

LROBD 

Napravljen je ispis liste „Usporedba prodaje za dva razdoblja“. 

Sporno razdoblje je 01.10.2012- 31.10.2012 


25.01.2013 


Uočeno je da se kod nekih artikala npr. artikl 311640, na listi koja je danas izvučena,ukupno prodano 0.00 

kom, dok je na listi iz 11 mjeseca prodaja prikazana ovako: 

U hp1 tablici ukupna prodaja za navedeni artikl (10 mj 2012.) iznosi 1220 kom 

Molim hitan ispravak. 


Poštovani, 

Prodaja drugog razdoblja ( objekt udr_ul.trn USPOREDBA PRODAJE ZA DVA RAZDOBLJA) ispravljena za 

slučaj kada prodaja artikla drugog razdoblja se razlikuje po maloprodajnoj cijeni ili marži . 


S štovanjem 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Glorija 


13068 



24.01.2013 11:28 

Upisao: 

Božo Mišeta 

Područje: 

LFINK 


31.01.2013 


Izlazne fakture obračuna kamata (KIZ) trebaju pratiti evidenciju izlaznih faktura na koje se kamate 

obračunavaju, tj . fakture kamata moraju glasiti na istog partnera (šifru analitike) na koju glase i izlazne 

fakture. 

Na ekranima potrebno uvesti Indikator obračuna gdje bi se odabirom K (knjiženje) zadržao postojeći način 

formiranja obračuna kamata prema šiframa analitike iz knjiženje, a indikator E (evidencija ) bi značilo da se 

promijeni način formiranja dokumenta obračuna prema evidenciji izlaznih faktura tj. šifra analitike izlazne 

fakture bi odgovarala obračunu. 



0









Za rješavanje zahtjeva predlažemo : 

a) organizirati sastanak vezano za dokumente KIZ - kamate kupcima 

b) poslati primjer KIZ u kojem je više računa koji su knjiženi na 1 šifru partnera (NSC) a evidentirani na više 

šifri . 

Razlog : 

a) na sastanku želimo dogovoriti /usaglasiti budući način obrade KIZ 

b) na primjeru 1 obračuna želimo pojasniti prijedlog rješenja . 

Obrade za KIZ za koje treba dogovoriti novi / potvrditi pšostojeći način : 

- obračuna kamata 

- evidencija dokumenta KIZ 

- statusiranje , posebno opcije sa i bez mogućnosti ponovnog obračuna za status>=3 

- automatska fiskalizacija 

- ispis 

- knjiženje 

Molim pošaljite 

a) termin . 

b) primjer 

Status : čekamo HP 

NAPOMENA : ako smatrate nepotrebnim održavanje sastanka ,molimo pošaljiite primjer obračuna kamata 



0









Poštovani, 

Potvrđujemo dolazak Dajane Lekić na sastanak sutra u 14:00 . 

Obrade za KIZ postojeći način : 

1. obračuna kamata : radi se temeljem knjigovodstvenih podataka tj stavki proknjižnih računa i uplata povezanih 

brojem zatvaranja : analitika=NSC 

2. evidencija dokumenta KIZ : radi se na parnera na kojem su proknjižene stavke : analitika =NSC 

3. statusiranje , posebno opcije sa i bez mogućnosti ponovnog obračuna za status>=3 : dozvoljene su 

promjene u status >=3 

4. automatska fiskalizacija : nije podržana 

5. ispis : radi se na parnera na kojem su proknjižene stavke : analitika =NSC 

6. knjiženje : radi se na parnera na kojem je obračun tj. na onog jkoji mu e NSC : analitika =NSC , protokol= KIZ 

Molimo pošaljite primjer KIZ u kojem je više računa koji su knjiženi na 1 šifru partnera (NSC) a evidentirani na 

više šifri . 

Razlog :na primjeru 1 obračuna želimo pojasniti prijedlog rješenja . 

PRIJEDLOG rješenja : 

1. obračuna kamata : bez promjene 

2. evidencija dokumenta KIZ : bez promjene 

3. statusiranje : potrebno zabraniti promjene za status >=3 ? 

4. automatska fiskalizacija : potrebno omogućiti nako što se postigne dodgovor u kojem statusu , pod kojim 

uivjetima, na kojim ekranima,... 

5. ispis : bez promjene postojećeg + dodatna opcija ispisa po analitici računa (slično kao kod izlaznih računa 

specifikacija po mjestu troška tj.orgj kupca) 

6. knjiženje : analitika=NSC bez promjene .Treba li rasknjižiti KIZ po računaima ? 



0









Poštovani, 

Obzirom na : 

*** postojeći način obrade za KIZ : 

1. obračuna kamata : radi se temeljem knjigovodstvenih podataka tj stavki proknjižnih računa i uplata povezanih 

brojem zatvaranja : analitika=NSC 

2. evidencija dokumenta KIZ : radi se na parnera na kojem su proknjižene stavke : analitika =NSC 

3. statusiranje , posebno opcije sa i bez mogućnosti ponovnog obračuna za status>=3 : dozvoljene su 

promjene u status >=3 

4. automatska fiskalizacija : nije podržana 

5. ispis : radi se na parnera na kojem su proknjižene stavke : analitika =NSC 

6. knjiženje : radi se na parnera na kojem je obračun tj. na onog jkoji mu e NSC : analitika =NSC , protokol= KIZ 

***prihvaćeni prelazak KIZ iz protokola 0 u protokol F 

PRIJEDLOG rješenja jest : 

1. obračuna kamata : bez promjene 

2. evidencija dokumenta KIZ : bez promjene na NSC u protokol F 

3. statusiranje : bez promjene tj. nema zabrana . Storniranje : omogućiti automatsko nastajanje minusnog 

dokumenta 

4. automatska fiskalizacija kao ni fiskalizacije uopće : nije potrebna 

5. ispis : bez promjene postojećeg + dodatna opcija ispisa po analitici računa (slično kao kod izlaznih računa 

specifikacija po mjestu troška tj.orgj kupca) 

6. knjiženje : analitika=NSC bez promjene . Zasad se ne treba rasknjižiti KIZ po računaima . 

7. Na pregledu KIZ po uzoru na prikaz po broju zatvaranja napraviti prikaz KIZ po šifri partnera i broju 

računa. Šifra partnera je iz evidencije računa 

Dakle, 

Promjene se svode na rješavanje : 

2. rješava se kroz zahtjev HP 13172 

3. ,5. i 7 - rješava se po ovom zahtjevu 

------------------Molimo Vaš stav vezano za prijedlog 

Uskoro šaljemo , za obračun 11004-012-36755 ( u prilogu) izgled za točke : 

5. opcija ispisa po analitici računa 

7. Prikaz/Detalj KIZ po šifri partnera i broju računa 

To je obračun kojeg smo na sastanku dobili kao primjer KIZ u kojem je više računa koji su knjiženi na 1 šifru 

partnera (NSC) a evidentirani na više šifri . 



0









Poštovani, 

Za prelazak evidentiranja i knjiženja KIZ u protokolu F potrebno je : 

a) podesiti parametar VPZOK : umjesto 0 upisati F 

Parametar VPZOK čita se kod prijeve pa se treba odjaviti i ponovo prijaviti da bi radio sa novom vrijednošću 

b) podesiti protup_ff UPUTE ZA EVIDENTIRANJE DOKUMENATA 

tj dodati uputu za KIZ na protokol F kao što sad postoji za prootkol 0 

Postaviti vrstu analitike * (sve analitike) a ne P-partner jer se KIZ radi za vrstu analitike A - ostale analitike 

Ne brisati postojeće upute jer se stari KIZ u protokkolu 0 i dalje trebaju moći vidjeti, pregledavati , statusirati.... 

c) podesiti upute za knjiženje KIZ vdokkon_ff VEZA KONTO-DOKUMENT tako da se zada vrsta protokola * 

umjesto 0 i vrsta analitike * ili ? 

kako bi se knjižili KIZ u protokolu 0 (stari) i u protokolu F (novi) a na vrstama naliteke P i A a ne samo P 

Sve gore navedene promjene preporučujemo provesti na test okruženju, pustiti obračun KIZ sa vrstom analitike 

P , A. Proknjižiti . 

Poslano datum i vrijeme: 19.3.2013 9:47:18 i kroz obardu KZ 41592, HP broj 13172 




Prijedlog Detalja KIZ po broju računa koji su ušli u obračun kao i ispisa po analitici računa šaljemo u toku dana 



0









Poštovani, 

Na primjeru obračuna 11004-012-36755 šaljemo prijedlog izgleda za : 

1. Prikaz/Detalj KIZ po šifri partnera i broju računa : 

a) Zaglavlje prikaza/detalja : 

Datum dokumenta 31/12/2012 Datum dospijeća 30/01/2013 

Analitika P 649538 CENTAR ZA SOCIJALNU SKRB ZAGREB 


b) Razrada po računu : 

racun vdok vanalitika analitika kamata 

1100401234672 FAP P 629713 8.82 

1100401234674 FAP P 629715 17.07 

1100401234675 FAP P 629716 31.36 

1100401234677 FAP P 629718 25.63 

1100401234682 FAP P 629723 29.28 

1100401234748 FAP P 630844 24.66 

c) prikaz/detalj napraviti na kampr_ff PREGLED OBRAČUNA - KUPCI 

umjesto sadašnjeg F2 Detalj ili još na F2 Deralj staviti razradu po računima 

STATUS : HP treba poslati nadopunu za nedostajuće podatke u zaglavlju ili razradi (napr, naziv nalitike u 

razradi,..) 

Stav u vezi s prijedlogom 

------------------------------------------------------------- 

2. opcija ispisa po analitici računa tj Ispis KIZ po računima (u prilogu) : 

a) Ne mijenja se struktura izvještaja , podaci za HP , podaci za kupca tipa OIB ( ostaje isto crveno označeno) . 

b) Mijenja se za svaku novu analitiku računa idu i njene generalije tipa naziv,adresa,.. (novo žuta podloga u 

prilogu) 

c ) za svaku novu analitiku ide nova stranica i zbroj kamata za nju po svim njenim računima u KIZ 

( iz baze pročitano za svaku analitiku računa točne generalije radi što zornijeg prikaza ispisa kojeg 

predlažemo) 

d) Ispis s opcijom po analitici računa napraviti na kampr_ff PREGLED OBRAČUNA - KUPCI 

uz mogućnost zadavanja opcije ispisa prije samog ispisa na F6 Ispis ( KIZ zbirno tj.postojeći ili KIZ po 

računima tj. novi) 

NAPOMENA:Postojeći ispis ostaje bez promjene (zadnja stranica u prilogu) tj. ide kao i dosad na analitiku KIZa 

i njene generalije . 

STATUS : HP treba poslati stav u vezi s prijedlogom 


Na objektu kampr_ff dodana je tipka F10 DetAna za pregled obračuna po analitici iz evidencije računa na koju se 

otvara novi ekran kamana_ff. 

Na novom ekranu moguć je ispis obračuna kamta po analitici iz evidncije računa (svaka na svoju stranicu). 

Preuzimite LAUS FINK lib u utorak 2.4.2013. 


Na ispisu obračuna kamata (kam1) podaci o analitici: vrsta i šifra analitike ,matični broj i oib su prebačeni na 

desnu stranu prema uzoru na poslani primjer. 

Preuzmite LAUS FINK lib u utorak 2.4.2013. 



0









Poštovani , 

Smatramo ovo potvrdom ispravnosti pojedinačnog izlista kako ste tražili, uključivo i pomjeranje podataka 

partnera desno (OIM, MB,..) 

Preporuka je listanje svim kupcima ukupnog obračuna kamata na kamsve_ff kao i dosad. 

Potom, za kupce koji tako traže/zahtjevaju poslati specifikaciju obračuna kamata po analitikama iz evidencije 

faktura . 

To se sad može pojedinačno bez problema. ZA najefikacije rješenje koje odgovara potrebama posla nije dobro 

niti potrebno listati za sve obračune specifikaciju. 

-- Dakle, sutra ili prekosutra kao ste i planirali možete provesti obračun kamata po traženom zahtjevom, 

jedino se neautomatski radi ispis specifikacija 

Za automatizacijuispisa specifikacija smatramo da potrbama više odgovara prijedlog pod b) jer je upravljivo, a 

za prijedlog pod a) korisnik opet mora birati treba li ili ne treba listati specifikaciju. 

Molimo stav HP u vezi prijedloga kako bismo udovoljili potrebi da ye automatizacija ispisa specifikacija KIZ 

ispšoruči do kraja tjedna 

PRIJEDLOZI : 

a) Glorija :Na pregledu kamata kampr_ff ako neka faktura ima više analitika, vidi se to tek kada se stisne tipka F 

10. 

ispred broja obračuna staviti * ako obračun ima pod sobom više šifri analitika 

b) ili omogućiti ispis specifikacije KIZ po analitikama računa samo za one partnere na koje se upiše dodatni 

podatak , napr KIS - KIZ - SPECIFIKACIJA . 

Podatak KIS=D bi se upisivao na NSC (INA) jer je na njoj obračun kamata ,a dobila bi se specifikacija KIZ za sve 

račune koji su ušli u KIZ tj. knjiženi na INA a evidentiorani na INA1, INA2 ,... 

NA kampr_ff bi se mogao dobiti pregled i ispis specifikacija po uvjetu Specifikacija=D samo za KIZ kupaca 

kojima je upisan dodatni podatak KIS=D 

na način : svaka šifra analitike u računu nova stranica i posebno zbroj kamata za svaku kao što je već i 

napravljeno i isporučeno (pojedinačni ispis) 



0









Poštovani, 

Naveli ste : 

Još jednom ponavljamo želimo automatski listati obračune kamata i to po specifikacijama ukoliko obračun pod 

sobom ima više analitika. Ne treba zadavati nikakve dodatne parametre, a ovakav sada način nije upotrebljiv niti 

praktičan. Od 4000 obračuna kamata, kako pronaći one kojima treba specifikacija? 

-- Omogućit će se lna kamsve_ff kako ste i tražili istanje obračuna kamata na 2 načina : 

a) kao i dosad ako je zadano specifikacija N 

b) na novi način tj. specifikacija ako je zadano specifikacija D 

Akose izabere način pod b) bit će zadovoljeno što ste naveli : 

Znači kada djelatnik radi obračun odmah se obračuni rade po starom, ali listaju po novom ako obračun ima više 

šifri, ako nema naravno da je jedna šifra, ali izgled isti. Kupci ne traže niti zahtijevaju već je to uvjetovano 

ugovorom, na kojem se nivou radi faktura. 

Dalje ste naveli : 

** Mislimo da je dovoljni kompromis što zahtjevom se odustalo od težnje da obračun bude na nivou analitike, 

--- ne radi se o kompromisu koji stte napravili da bi nama bilo lakše nego da bi dobili točan obračun kao što ste i 

navikli dobiti budući da postoje zatvaranja stavaka na više analitika pa je obračun kamata na nivou analitike 

neprovediv tj. bio bi netočan . 

** a sada se ne može dobiti niti automatski ispis po traženim kriterijima. 

Na sastanku je jasno definirano od strane korisnika što se želi bez ikakvih daljnjih komplikacija. 

-- moći će se dobiti sve što ste tražili samo što bi brže i smatramo brže bilo listanje na način kako smo predložili . 

No nije neizvediv ni ovaj na kojem inzistirate. 

NAPOMENA : ispis na kamsve_ff NORMALNI OBRAĽUN - SVI KUPCI je jednokratne prirode pa smo 

predlagali da se opcija ispisa Specifikacija D-da ili N-ne radi na kampr_ff PREGLED OBRAĽUNA - KUPCI 

gdje se može ponavljati ispis sa različitim opcijama kolkio god puta je potrebno . 

Dakle, zahtjev je zapravo omogućiti opciju ispisa Specifikacija D/N na oba navedena ekrana što nije ušlo u 

procjenu zahtjeva kao niti naknadno traženo pomjeranje generalija kupca udesno . Sve navedeno povećava 

potrebno vrijeme i rokove isporuke . 

Trenutno se radi na omogućavanju ispisa specifikacija D/N na kamsve_ff kako je traženo . Kad se potvrdi 

ispravnost , isto će se omogućiti i na kampr_ff . 


Poštovani, 

Na objektu kamsve_ff omogućeno je listanje obračuna kamata po specifikaciji (po analitici iz evidencije). 

Za opciju listanja specifikacija potrebno je indikator Specifikacija postaviti na D, inače ide lista kao i dosada. 




Na objektu kampr_ff prilikom F6 Ispis na opciji Pojedinačni ispis svih obračuna gdje se otvara ekran kam1_ff 

dodano je polje Specifikacija za listanje obračuna po analitici iz evidencije (po uzor na objekt kamsve_ff). 



Poštovani, 





0











Klijent: 





ZZN 

Hitnost: 

Nije hitno 


višnja 

12603 



24.01.2013 10:28 

Upisao: 

Dajana Lekić 

Područje: 

EPNAB 


31.10.2012 




0









Pod novim brojem KZ a istim HP brojem 12603 rješavt će se točke zahtjeva koje su adaptivno održavanje : 

Dorade s procjenom – na njima se ne radi dok se ne potvrdi procijenjeni angažman (adaptivno ) 

3. ZZN - tražilica - prilagoditi je gridu ZZN-a, dakle maknuti sva polja za traženje koja se tamo 

nalaze a pripadaju pod dodatno. – 30 minuta 

4. ZZN- grid - maknuti sve kolone s grida koje se ne nalaze na tabu Osnovno, a staviti one koje se 

ne nalaze - 30 minuta 

5. ZZN - tab "Dodatno". Kod polja Dinamika izvođenja radova/isporuke robe/izvođenja usluga, Rok, 

način i uvjeti plaćanja, Rok trajanja ugovora/okvirnog sporazuma, Mjesto izvođenja radova/isporuke 

robe/izvođenja usluga postoje ograničenja duljine unosa. Bilo bi dobro unaprijed znati vrijednosti tih 

ograničenja (npr. negdje u Uputama), kako bi se izbjegle "metode Pokušaja". – 1 sat 

6. ZZN, importiranje troškovnika iz excel-a. U slučaju neuspješnog importa korisnik nema nikakvu 

informaciju o razlozima neuspjeha. Trebalo bi "programske kontrole" dopuniti odgovarajućim porukama. – 2 

sata 

9. Kartica i transkacija na gridovima spisa --> Arhiviraj (mogu se arhivirati svi spisi gdje nije nabava 

u tijeku) da se ne opterećuje aktivni grid postupaka i nabava. – 2 sata 

10. Ograničenje attachmenta je 10MB, moralo bi se povećati na 20MB, tako bi riješili 99% ugovora 

zbog potrebe attachiranja PDF-ova! – 1 sat 

11. Zamijeniti 02 - investicije i 01 - Troškovi jer trenutno gleda po vremenu stvaranja zapisa, a ne po 

nekom kriteriju slijeda. – 1 sat 

13. Export i print statusa, export troškovnika sa ZZN-a i s ugovora, i narudžbenica… - 3 sata 

14. Kod bagatelne nabave kada ide ugovor nedostaje polje datum odluke o odabiru. – 30 minuta 

18. Postojeći način ažuriranja matičnih podataka (Organizacijske jedinice, Ponuditelji, Jedinice mjere, 

Izvori sredstava, Institucije, Vrste predmeta nabave, Kategorija plana nabave) je riješen odvojenim izborima 

menija - Unos, Uređivanje, Brisanje. Praktičnije rješenje bilo bi kada bi iz svakog pregleda bilo omogućen 

Unos, Uređivanje i Brisanje. – 2 sata 

Čekaju procjenu 

1. Potrebno je implementirati filter iz excela na svaku kolonu zaglavlja u svim pregledima spisa i 

Registra ugovora da se možemo riješiti „gore“ grida Tražilice koji sadrži filtere, jer zauzima previše mjesta 

na ekranu 

17. Kocka – nužno je da se implementira kocka u posebnom tabu Izvješća. 



0









Poštovani, 

Potrebno da HP potvrdi procjenu za realizaciju ovdje navedenih točaka zahtjeva HP broj 12603 jer smatramo da 

se radi o adativnom održavanju . 

Procjena za točke pod : 1. i 17 bit će naknadno poslana . Za ostele točke zahtjeva procjenjeni angažman je 

naveden uz svaku pojedinu točku 

NAPOMENA: ukoliko se odustaje od realizacije pojedine točke zahtjeva , molimo to navedite pozivajući se na 

broj točke 


Poštovani, 

Dorade su prebačene na test, molimo povratnu informaciju vezano za točke : 

10. Ograničenje attachmenta je 10MB, moralo bi se povećati na 20MB, tako bi riješili 99% ugovora zbog 

potrebe attachiranja PDF-ova! – 1 sat 

14. Kod bagatelne nabave kada ide ugovor nedostaje polje datum odluke o odabiru. – 30 minuta 


Poštovani ,, 

Molimo javite kad pšristup bude omogućen na produkciju - spaja se kolega Vjeran Livaić. 

Također navedite koje točno dorade po tiočkama treba prebaciti na produkciju : 

točka 7 - ostaje na test-u tj ne prebacivati na produkciju ? 

točka 10 - prebaciti na produkciju 

točka 14 - prebaciti na produkciju ? 


Poštovani, 

Molimo da nam omogućite pristup za prebacivanje dorada danas 12.02.2013. u periodu od 16.00 – 17.00 sati za 

kolegu Vjerana Livaića. 

Prebacivanje možemo odraditi i sada, ali onda molimo da korisnici prestanu sa radom. 


Lp, 

Mario Šemper 


Poštovani, 

Dorade su prebačene na produkciju vezano za točku 10 i 14 



0









Poštovani, 

Vezano za ovaj zahtjev ostale su neprocjenjen dvije točke : 

Točka 1 : 

Kako bi mogli dati procjenu za ovu točku, potrebno je definirati raspon podataka koji bi se nudio u filteru za svaku 

kolonu. 

Točka 17 : 

Kako bi mogli dati procjenu za ovu točku, potrebno je definirati dimenzije i mjere za kocku. 


Poštovani, 

Čeka se odgovor od HP-a kako bi mogli dati procjenu za : 

Točka 1 : 

potrebno je definirati raspon podataka koji bi se nudio u filteru za svaku kolonu. 

Točka 17 : 

potrebno je definirati dimenzije i mjere za kocku. 

Procjena ranije potvrđena od strane HP-a za rješavanje : 

3. 0,5 sata 

4. 0.5 sata 

5. 1 sat 

6. 2 sata 

9. 2 sata 

10. 1 sat 

11. 1 sat 

13. 3 sata 

14. 0,5 sata 

18. 2 sata 

Ukupno 13,5 sati 

Riješeno i isporučeno na produkciju : 

Točka 10 

Točka 14. 


Poštovani, 

Kroz ovaj KZ 40881, isti HP broj 12603 - ADAPTIVNO dalje se rješavaju dorade vezano za Okvirne sporazume. 

Točeka 8 - Registar okvirnih sporazuma - dorade adaptivno održavanje. 

Procjena za ovo je 6 sati. HP potvrdila procjenu. 

8.1. Broj ugovora : neka se povlači broj OS-a i moguće je uređivanje - NE RADI 

8.4. Naziv ugovora : neka se povlači naziv OS-a i moguće je uređivanje - NE RADI 

8.6. Registarska oznaka : višak, treba maknuti, na to mjesto staviti Evidencijska oznaka koja se povlači s OS-a 

- NIJE ISPUNJENO 

8.7. Ponuditelj : povlači se s OS-a - NIJE ISPUNJENO 

8.9. Zajednica Ponuditelja, Članovi zajednice, Podizvoditelji/Podisporučitelji - Preslikati s OS-a, omogućiti 

editiranje - NIJE ISPUNJENO 



0









Poštovani, 

Točka 3 iz zahtjeva je prebačena na produkciju. 

Lp, 


Poštovani, 

Točka 4 zahtjeva je prebačena na produkciju. (05.04.2013 u 7:30) 


Poštovani, 

Točka 6 zahtjeva je prebačena na test. Na zahtjevu za nabavu je pored kartice Troškovnik dodana kartica 

Povijest importa troškovnika, u kojoj se prikazuje da li je import troškovnika uspješan ili neuspješan, s naznakom 

u kojem retku i kojoj koloni je podatak zbog kojeg je import neuspješan. 

Npr. Greška u podacima u kartici Sheet1 --> | Redak: 3 Kolona: Jedinica mjere - U šifrarniku ne postoji zapis s 

nazivom: miligram. 

Status po točkama zahtjeva : 

Riješene točke u ovom KZ : 3,4,5,6,10 i 14 

Neriješene točke u ovom KZ : 1,9,11,13,17 i 18 

Ostale točke izvornog zahtjeva HP 12603 rješavaju se ili su riješene kroz 

KZ 42287 :Točka 8 (adaptivni doio vrzan za OS) 

Status: Dorade vezane za okvirne sporazume su prebačene na testni server. Molimo suglasnost za 

prebacivanje na produkciju - Riješeno 

KZ 39040 :Smatramo riješenim sve točke zahtjeva koje nisu adaptivno održavanja :2,7,8,12,15 i 16 . 

Status : Molimo suglasnost za zatvaranje ovog KZ-a - Riješen 



0









Poštovani, 

Točka 6 zahtjeva je prebačena na produkciju. Na zahtjevu za nabavu je pored kartice Troškovnik dodana kartica 

Povijest importa troškovnika, u kojoj se prikazuje da li je import troškovnika uspješan ili neuspješan, s naznakom 

u kojem retku i kojoj koloni je podatak zbog kojeg je import neuspješan. Npr. Greška u podacima u kartici 

Sheet1 --> | Redak: 3 Kolona: Jedinica mjere - U šifrarniku ne postoji zapis s nazivom: miligram. 

Molimo potvrdu zatvaranja ove točke zahtjeva. 


Poštovani, 


Ugrađen je export podataka u Status postupaka kod Evidencija. Moguće je exportirati u pdf, rtf i xls. format. 

Ugrađen je export troškovnika u xls. formatu u troškovniku na ZZN-u 

u transakcijama Unos i Uređivanje ZZN-a u bagatelnoj nabavi, postupku nabave i nabavi po grupama, 

u registru ugovora bagatelne nabave, 

u registru ugovora postupka nabave, 

u registru narudžbenica, 

ugovorima i narudžbenicama u registru okvirnih sporazuma. 

ugovorima i narudžbenicama na Spisu u bagatelnoj nabavi, 

ugovorima i okvirnim sporazumima na Spisu u postupku nabave, 

ugovorima na Pojedinačnom spisu u postupku nabave. 



Poštovani, 


Sada kod Vrste troška prvo prikazuje 01 – Troškovi, a zatim 02 - Investicije. 

Molimo povrtne informacije /suuglasnost za prebacivanje na produkciju 


Status po točkama zahtjeva 12603 : 

Riješene točke u ovom KZ : 3,4,5,6,10,11,13 i 14 

Neriješene točke u ovom KZ : 1,9,17 i 18 








Poštovani, 

Molimo pristup na produkciju za Vjerana Livajića. 

Razlog: točke 11 i 13 zahtjeva 



0









Poštovani, 


Sada kod Vrste troška prvo prikazuje 01 – Troškovi, a zatim 02 - Investicije. 



Ugrađen je export podataka u Status postupaka kod Evidencija. Moguće je exportirati u pdf, rtf i xls. format. 

Ugrađen je export troškovnika u xls. formatu u troškovniku na ZZN-u u transakcijama Unos i Uređivanje ZZN-a u 

bagatelnoj nabavi, postupku nabave i nabavi po grupama, u registru ugovora bagatelne nabave, u registru 

ugovora postupka nabave, u registru narudžbenica, ugovorima i narudžbenicama u registru okvirnih 

sporazuma. ugovorima i narudžbenicama na Spisu u bagatelnoj nabavi, ugovorima i okvirnim sporazumima na 

Spisu u postupku nabave, ugovorima na Pojedinačnom spisu u postupku nabave. 


Neriješene su ostale točke HP12603 : 1,9, 17 i 18 koje se rješavaju kroz ovaj KZ 40881 (adaptivno) 

Sve riješeno za HP12603 po KZ 39040 ( perfektivno) te KZ 42287 ( OS adaptivno) 


Poštovani, 

Molimo povratne informacije/ formalnu potvrdu zatvaranja riješenih i na produkciju isporučenih točaka zahtjeva : 

3,4,5,6,10,11,13 i 14 

1. nema procjene 

3. 30 minuta 4.4.2013 na produkciji 


5. 1 sat 5.5.2013 na produkciji 

6. 2 sata 8.5.2013. na produkciji 

9. 2 sata 

10. 1 sat 12.2.2013. na produkciji 

11. 1 sat 14.5.2013 na produkciji 

13. 3 sata 14.5.2013 na produkciji 


17. nema procjene 

18. 2 sata 

Molimo pošaljite prioritete za neriješene točke u ovom KZ : 1,9,17 i 18 









0









Poštovani, 

Točka 9 (UPISNIK) 

Ova točka zahtjeva je prebačena na test. Dodana je mogućnost arhiviranja spisa u bagatelnoj nabavi, postupku 

nabave i nabavi po grupama. U Uređivanju spisa je pored kartice Spisi (u kojoj su aktivni spisi) dodana kartica 

Arhivirani spisi (u kojoj se nalaze spisi koji su arhivirani). Spisi u bagatelnoj i postupku nabave se arhiviraju na 

način da se na spisu u kartici Info klikne na gumb Arhiviraj. Mogu se arhivirati svi spisi osim onih u statusu 

Nabava u tijeku. Kod nabave po grupama arhivira se na način da se na spisu (glavnom spisu, ne pojedinačnom 

spisu za grupe) u karici Info klikne na gumb Arhiviraj. Mogu se arhivirati svi spisi kojima neki od pojedinačnih 

spisa za grupe nije u statusu Nabava u tijeku. 





Prema dogovoru, Upisnik se ne prebacuje na produkciju . 



Poštovani, 

Status po točkama zahtjeva : 

Riješene točke u ovom KZ na produkciji : 3,4,5,6,10,11,13 i 14 

22.5.2013. HP :Neriješene točke u ovom KZ poredano po prioritetu rješavanja :9, 18, 17, 1. 

Ostalo za riješiti točke : 18,17 i 1 

Točka 9 u međuvremenu riješena već isporučena na test 17.6.2013. 

Molimo povratne informacije/suglasnost za prebacivanje točke 9 na produkciju 


Poštovani, 

Ova točka zahtjeva je prebačena na produkciju. Molimo potvrdu zatvaranja zahtjeva. 

Lp, 



0









Poštovana, 


§ 12603.9 

§ 13408 

§ 13409 



Poštovani, 

Procjena za zahtjev 12603.17 je 40 radnih sati. 

Riječ je o zahtjevu da se omogući funkcionalnost kocke za izvješćivanje. 


Lea Gagulić 


Poštovani, 

Ova točka zahtjeva je prebačen na test. 

Izmijenjen je postojeći način ažuriranja matičnih podataka. Sada se klikom na matični podatak (Organizacijske 

jedinice, Ponuditelji, Jedinice mjere, Izvori sredstava, Institucije, Vrste predmeta nabave, Kategorija plana 

nabave) otvara jedan ekran u kome se mogu unositi, uređivati, brisati i pretraživati podaci. 

Lp, 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Glorija 


13067 



23.01.2013 14:23 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


29.01.2013 


24.01.2013 

Na objektu iza polja Gross weight i Net weight staviti malo slovo g (kao oznaku grama). Jednako napraviti i 

na ispisu računu (predračun nema ta polja). 

Kod ispisa predračuna (PID) umjesto PROFORMA pisati PROFORMA INVOICE. 



0









Poštovani, 

Na objektu za ručni unos računa filatelije iza polja Gross weight i Net weight je stavljeno malo slovo g. Isto je 

napravljeno i na ispisu računa. 

Kod ispisa predračuna (PID) umjesto PROFORMA sada piše PROFORMA INVOICE. 

Instalacija: novi WIN FAUS lib će biti dostupan sutra ujutro. 

S štovanjem 


poštovani, 

Stavljeno je da se i na ekranu prikazuje slovo g iza polja Gross weight i Net weight 


Instalacija: novi WIN FAUS lib će biti dostupan sutra ujutro. 26.1.2013 



Poštovani, 

Sa je I kod ispisa računa stavljeno je da se prikazuje malo slovo g iza polja Gross weight i Net weight. 


U ponedjeljak ujutro 25.02.2013 bit će dostupan novi WIN FAUS lib. 

Molimo povratne informacije / suglasnost za zatvaranje zahtjev a- Riješen 


Poštovani, 

Zahtjev zatvaramo uz Vašu suglasnost - Riješeno 



0











Klijent: 





Hitnost: 



Katja 


13066 



23.01.2013 10:51 

Upisao: 

Božo Mišeta 

Područje: 

LROBD 


29.01.2013 


U aplikaciji LAUS na meniju ME1222, objektu; RPDul_jd POVRAT ROBE DOBAVLJAČU izvesti doradu, 

a koja će u tom smislu po provedbi iste omogućiti kako slijedi; 

a)Na predmetnom objektu (RPDul_jd) omogućiti (NOVI) izbornik koji će nuditi mogućnost (postaviti pravilo 

„obveznog odabira“ s tim da je „SFP“ difoltna postavka) dvaju odabira u smislu slijedećih poslovnih 

događaja 

1.Stvarni fizički povrat, oznaka „SFP“, odnosno 

2.Fiktivni povrat na ime otuđenja, oznaka „FP“ 

U slučaju opisanom toč. (1.) Stvarni fizički povrat, oznaka „SFP“, aplikacija će nastaviti ispisati 

sadržaj iz pripremljene napomene „Klauzula o odricanju od odgovornosti“ („Vozar potvrđuje primitak gore 

navedenih količina robe. Dobavljač može podnijeti prigovor na zaprimljenu količinu i o tome odmah 

obavijestiti HP, a najkasnije u roku od 8 dana, inače gubi pravo koje mu pripada po toj osnovi.“ Isto tako i 

polja „Isporučio i Primio“ sa mjestima za unos „ime i prezime, potpis te registarska oznaka“), odnosno u 

slučaju opisanom toč. (2.) Fiktivni povrat na ime otuđenja, oznaka „FP“ aplikacija NEĆE ispisivati 

pripremljenu napomenu iz sadržaja „Klauzula o odricanju od odgovornosti“. 

Nadalje, prostor za upis proizvoljne „Napomene“ sa momentalnih 120 znakova proširiti za dodatnih 

60 znakova, dakle 180 znakova ukupno. 



0









Poštovani, 

da li DOISTA tražite to što je napisano u zahtjevu? 

Da li ste svijesni posljedica legaliziranja fiktivnih dokumenata, kao načina poslovanja? 

S štovanjem 


Poštovani, 

Procjenu sati za izradu unos, izmjenu i brisanje tablice "dodatni tekst" (300 znakova) 7h 

(tekst se ispisuje samo ako je indikator SFP). 

Prociena izrade polja na ekranu Poslovni događaj, koje povlači tekst SFP ili FP. 4h 

Procjena izrade polja isporučio i primio na ekranu RPD (MOLIM DOSTAVITI DUŽINE TIH POLJA) 4h 

Procjena ispisa (MOLIM DOSTAVITI ISPISE NA KOJIMA TREBA NAPRAVITI TRAŽENE NADOPUNE ISPISA) 

1.5h po ispisu 

Ukupno 15h + 1,5h po svakom ispisu! 

Molim dostaviti tražene podatke (UPISANE KAO UPIT U ZAGRADAMA UZ SVAKU PROCJENU). 

S štovanjem 


Poštovani , 

Zahtjev zatvaramo uz vašuu suglasnost - Odustaje se od zahtjeva 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13065 



23.01.2013 10:47 

Upisao: 

Božo Mišeta 

Područje: 

LROBD 


23.01.2013 


23.01.2013 

Kolega iz Depoa Split uočio je jednu moguću nepravilnost. 

Na knjiženju inventure u Depou Split LAUS šifra Depoa 35348 na dan 31.12.2012. artikl 306354 E ČEST. 

(1) B/NG-2.50-100001 EUROPOT unesen je sa stanjem 0 

Na skladišnoj kartici ( slika 2.) stanje pokazuje u -100 što nije prema kolegi točno. 

Na pregledu sks2_ul_jd TRENUTNO SKLADIŠNO STANJE također aplikacija prikazuje stanje -100 


Ažuriano je skladišno stanje za artikal 306354 na skladištu 35348 (razlika je bila zbog neispravnog predznaka na 

storno protokol RPM 35348-R12-00837 100 kom) . 




0











Klijent: 





knjdig.jas i knjstb.jas 

Hitnost: 



ivan 


13064 



22.01.2013 17:30 

Upisao: 

Dajana Lekić 

Područje: 

LWINFAU 


24.01.2013 


Potrebno je na objektima knjdig.jas i na knjstb.jas dodati dodatne uvjete za knjiženju kao i kod automatskog 

knjiženja faktura (na slici). 

S time da je potrebno omogućiti osim odabira partnera odabir ostale analitike. 



0









Poštovani, 



10.06.2013.g. 

Nakon zadnje obrade nismo dobili primjedbe na rad programa : 

Na objektima za knjiženje digitalne TV i STB (knjdig.jas i knjstb.jas) nadodana su filter polja Partner i broj 

protokola od - do. 

Instalacija: sutra 05/02/2013 će biti dostupan novi WIN FAUS lib. 


Poštovani, 



10.06.2013.g. 

Nakon zadnje obrade nismo dobili primjedbe na rad programa : 

Na objektima za knjiženje digitalne TV i STB (knjdig.jas i knjstb.jas) nadodana su filter polja Partner i broj 

protokola od - do. 

Instalacija: sutra 05/02/2013 će biti dostupan novi WIN FAUS lib. 

Nadopuna odgovora : sve navedeno se odnosi i na ostale analitika kako ja traženo zahtjevom 



0











Klijent: 





fakture tiptar=8 

Hitnost: 

Vrlo hitno 


ivan 


13063 



22.01.2013 13:43 

Upisao: 

Dajana Lekić 

Područje: 

LWINFAU 


23.01.2013 


Za potrebe izrade faktura u skladu sa zakonskim propisima u aplikaciji za fakturiranje otvori novi tarifni 

razred prema sljedećem: 

•tip tarife (šifra): 8 

•opis: Pravilnik o PDV-u, čl. 87. 

•Knjiga izdanih računa: stupac 11 OSTALO (OSLOBOĐENO POREZA) 

•tekst napomene na računu: oslobođeno plaćanja PDV-a temeljem čl. 3. Zakona o PDV-u i čl. 87. 

Pravilnika o PDV-u 



0









Poštovani, 

Potrebno je razjasniti pojmove i definirati očekivanja/potrebe vezano za ovaj zahtjev 

Pod tip tarife misli se na novi tiptar= 8 ? 

Zasad se u stupac 11 knjige IRA upisuju računi za koje je kupac oslobođen plaćanja poreza po izjavi 

a) za fakture nastale u laus-u : lm_ugv_dod.part_pdv=N u ugovru 

b) za R! račune plaćene gotovinom ili virmanom u PU ( lm_usl_r1.izjava=D) 

Treba li u fakurama pod a) u stavke fakture upisati tiptar=8 iako je u nalozima ili za usluge /robe vezan neki 

drugi tiptar u cjeniku ? 

Treba li kod preuzimanja računa pod b) upisati tiptar=8 iako je u prometu poslan neki drugi tiptar ? 

Treba li ugraditi kontrolu/grešku : ako je izjava=D a tiptar!=8 greška kod preuzimanja R1 računa iz MIPS-a i HPX 

-a ? 


Poštovani, 

Hvala na brzom odgovru . Zasad je potrebno izvesti SQL : 

insert into lm_pdv(vporez ,tgrup ,pdvmips, tiptar ,opis) 

values ( '','','','8', 'Pravilnik o PDV-u, čl. 87. ' ) ; 

Planiramo realizirati : 

kod ručnog upisa cijene u cjenik usluga za usluge izvan MIPS-a ( počinju sa 9 ) omogućiti upis tiptar= 8. 

Kod izrade faktura na rucfak omogućiti upis usluga sa tiptar=8 i upisati u tom slučaju u napomenu 2. red : 

Oslobođeno plaćanja PDV-a temeljem čl. 3. Zakona o PDV-u i čl. 87. Pravilnika o PDV-u 

Usluge sa tiptar=8 su neoporzive/osobođene od PDV-a pa im je porez=0 , osnovica=0 a neoporezivo kod 

razrade neoporezivog ide u stupac 11 knjige IRA/PDV (prot_neop.iznos11) 

Molimo specificirajte : 

treba li na još nekom objektu fakturiranja omogućiti isto kao što planiramo na ruckat ? 


Poštovani, 

Molimo navedite u kojim slučajevima prometa usluga/roba očekujete tiptar=8 kako bismo prije riješili zahtjev. 

Naime, ima dosta prijenosa prometa te načina fakturiranja pa ugrađivanje u sve vrste poreznog tretmana može 

potrajati a vjerovatno i nije potrebno nego samo kod nekih slučajeva . 


Poštovani, 

Na objektu za ručni unos faktura rucfak.jas sada se novi tiptarife 8 evidentira u stupcu 7 NE PODLIJEŽE 

OPOREZIVANJU Knjige IRA. 

Instalacija:preuzeti novi WIN FAUS lib u utorak (19.02.2013) ujutro 

S štovanjem 



0









Poštovani, 





0











Klijent: 





eo_vrac 

Hitnost: 

Vrlo hitno 


ivan 


13062 



22.01.2013 11:57 

Upisao: 

Dajana Lekić 

Područje: 

LFINK 


22.01.2013 


Potrebno je podesiti podatke za 2013g. za podgrupe troškova koje se prenose u eObradu. (Podesite 

ispravne razine za ovjeru) 

Podgrupe su unesene u tablicu eo_vrac: 

select * from eo_vrac where podgrupa_tr like '2013%'; 



0









Poštovani , 

Bilo bi dobro da ne ide još prijenos LAUS--EO jer za 45 slučajeva je ur_klasa 'kratka' u tip_eolog : 

ur_klasa char(16) tip_eolog 

ur_klasa char(20) eo_vrac 

pa nedostaje u tip_eolog 1 znak - broj 3 koji u eo_vrac postoji ../13 

Treba proširiti polje ur_kalsa u tablici tip_eolog u laus i mips bazi : 

alter table tip_eolog modify ur_klasa char(20) ; 

Kad izvedete proširenje molimo povratnu informaciju kako bismo i za njih 45 pripremili slogove u tip_eolog i 

tip_razina_eolog tablicama 

ili sami izvedite dolje navedene sql-ove te pošaljite povratnu informaciju/suglasnost za zatvaranje zahtjeva - 

Riješen 

--tip_eolog : 

INSERT INTO tip_eolog ( 

podgrupa_tr, orgj_tn, ur_klasa, radnik, koordinator, 

grupa_tr,ovjera, aktivnost, ugovor, akcija, datum_upisa) 

select podgrupa_tr, orgj_tn, ur_klasa, radnik, kord, 

grupa_tr,ovjera , 'D', ugovor, 'I', current year to second 

from eo_vrac 

where grupa_tr!=podgrupa_tr and aktivnost='D' 

and podgrupa_tr not in (select podgrupa_tr from tip_eolog ) 

an d podgrupa_tr like '2013%'; 

---tip_razina_eolog 

select podgrupa_tr, orgj_tip1 razina , aktivnost 

from eo_vrac where podgrupa_tr like '2013%' 

union select podgrupa_tr, orgj_tip2, aktivnost 

from eo_vrac where podgrupa_tr like '2013%' 

union select podgrupa_tr, orgj_tip2, aktivnost 

from eo_vrac where podgrupa_tr like '2013%' into temp w ; 

--- sredi w tako da orgj_tip1='' ili null obrišeš a za * ostaviš * (sve ra 

delete from w where razina='' or razina is null ; 

INSERT INTO tip_razina_eolog ( 

podgrupa_tr, razina, aktivnost, akcija, datum_upisa) 

select podgrupa_tr, razina, aktivnost, 'I' , current year to second 

from w where podgrupa_tr||razina not in (select podgrupa||razina from tip_razina_eolog ) ; 


Poštovani , 

Sad je skup zapisa koji se žalju prema eAplikacijama za nove podgrupe troškova za 2013 godinu upotpunjen te 

se može pustiti prijenos (eo_mila_jf) 

z13062e.sql izveden nakon obavjesti HP-a (Ivan) :Polje je prošireno. Možeš pustiti SQL 




0









Poštovani, 

Molim Vas što prije pristup za kolegu Tvrtka Matoševića kako bi se izvršio zahtjev 13062. 

Nakon što omogućite pristup zahvat će trajati do sat vremena. 


Lp, 


Poštovani, 

Izvršen je upit na bazi koji je proširio broj znakova sa 16 na 20 za polje TipTroskaOznakaOrgj u laus.TipTroska 

tablici. 

Također, prebačen je dll u kojem je prilagođen objektni model baze podataka. 

Ukoliko je sve u redu, molimo potvrdu za zatvaranje zahtjeva. 

Lp, 


Poštovani, 

Molimo povrtane informacije /suglasnost za zatvaranje zahtjeva - Riješen 

nakon proširenja polja ur_klasa na svim potrebnim tablicama . 

PITANJE : 

vide li se sve podrupe troškova za 2013 godinu u eObradi računa ? 


Poštovani, 

Izveden z13062f.sql kojim su ponovo formirani slogovi sa akcija =I (insert) za spornih 45 podgrupa troškova 

(tip_eolog) kojima je Ur.klasa bila dulja od 16 znakova kao slogovi sa akcija=I za pripadajuće razine ovjere 

(tip_razina_eolog) . 

Sve odrađeno na laus produkcijskoj bazi prema dogovru (Ivan) . 


nakon puštanja prijenosa eo_mila_jf (LAUS-->eObrada 


Poštovani 

Zatvaramo zahtjev - Riješen uz vašu suglasnost 



0









Poštovani , 

Molimo omogućite pristup za Tvrtka Matoševića na produkciju eOR radi rješavanja zahtjeva 13062 

i obavjest o tome da je omogućeno 


Poštovani, 

Greška se dogodila iz razloga koji je Dajana navela (Može bit da je redoslijed upisa na eObrada strani bio 

tip_razina_eolog pa onda tip_eolog uzrok greške jer je to pogrešan redoslijed). 

Rješenje problema: 

Neka se ponovo pošalju podaci iz tablice za TipTroškaRazina. (tip_razina_eolog) za 2013 

PITANJE : Ponovni upis slogova u tip_razina_eolog sa akcija=I napravit će HP ili LAUS ? 

Detaljnije: u prilogu 

LAUS -> DOKUMENTIT laus.TipTroskaRazina ---> 10:59:08.740 

DOKUMENTIT -> eObradaRacuna (Sve što je bilo preneseno do trenutka pokretanja servisa) ----> 10:59:11.583 

- Error 107 -> Ne postoji TipTroška za TipTroskaRazinu 

LAUS -> DOKUMENTIT laus.TipTroska ---> 10:59:12.877 - USPJEŠNO PRENESEN (2013-01-23 11:08:59.997) 


Poštovani, 

Upisani su u laus produkcijsku bazu (tip_razina_eolog) ponovo razine ovjere za sve tipove/ podgrupe troška u 

2013 godini sa akcija=I (insert) 

Potrebno je pustiti prijenos eo_mila_jf i provjeriti vide li se sad razine ovjere za tipove trošak u 2013 za koje se 

nisu vidjele 



Poštovani, 




0











Klijent: 





iz_bss_ff 

Hitnost: 

Vrlo hitno 


ivan 


13061 



22.01.2013 10:26 

Upisao: 

Dajana Lekić 

Područje: 

LFINK 


22.01.2013 


Ne radi dobro knjiženje izvoda za digitalnu TV preko objekta ‘iz_bss_ff - Automatsko knjiženje izvoda DTV’; 

Uplaćeno je 234,43KN 

dat_izv br_izvrnpri 

21.01.2013.005HR4723900011500005667 

A proknjiženo je: 606,78 kn u nalogu ‘13Z50005’. Izgleda da ima duplanja podataka kod knjiženja za iznose 

veće od 1KN. 



0









> Poštovani, 

> 

> Ispravljeno je dupliranje iznosa kod automatskog knjiženje izvoda DTV za stavke uplata na konto kupca. 

> Višestruko knjiženje događalo se za slučaj da u jednom izvodu postoji više uplata koje se odnose na istog 

kupca./ugovor 

> 

> Potrebno za instalaciju i testiranje: 

> Preuzimite novi LAUS FINK liba od 23.1. ujutro 

> 

> Molimo povratne informacije nakon testiranja/ suglasnost za zatvaranjezahtjeva - Riješen 

PITALI STE : 

> A što da radimo sa postojećim nalogom gdje je krivo proknjiženo? 

> Kakve upute da dam računovodstvu? 

PREDLAŽEMO : 

nema ništa za ovaj nalog u BSS tablica,ma : 

--lect * from bss_poslano 

--ere nalogk='13Z50005' ; 

--lect * from bss_laus@mips_laus:bss_kartica 

--ere nalogk='13Z50005' ; 

pa se može ovo izvesti intervencijom na bazu : 

--lete from arhivk 

--ere nalogk='13Z50005' ; 

--date izvod_ziro1 set nalogk='' 

--ere nalogk='13Z50005' ; 

--update izvod_ziro set status='O' 

--ere br_izv='005' and rnpri='HR4723900011500005667' ; 

Proknjižiti ponovo nakon instalacije na produkciju novog FINK lib-a 



0











Klijent: 





ispisi NARul 

Hitnost: 



glorija 


13060 



22.01.2013 10:15 

Upisao: 

Dajana Lekić 

Područje: 

LNABD 

NARul_jg NARUDŽBA KUPCA ZA KATALOŠKU PRODAJU 


31.01.2013 


Na ispisu stupce Cijena I Količina zamijeniti tj. da prvo ide JMJ pa onda bi trebala biti količina pa sve 

ostalo . 


Na ispisima narudžbenice NAR u excel i standardni zamjenjeni su stupci količina i cijena tako da se sada ispisje 

artikal,naziv,jmj,količina,cijenta itd. 

Potrebno je preuzeti nabd lib koji će biti na internetu 23.01.2013 



0











Klijent: 





udr_trn 

Hitnost: 

Vrlo hitno 


katja 


13057 

udr_trn Usporedba prodaje za dva razdoblja 

Greška prilikom ažuriranja na qclr_pom broj -284 isam(0) 

sve org grupe *****, period 0d 1 do11 mjesec 2011 i 2012 

Molim VAS HITNO otklanjanje greške 284. 



22.01.2013 09:46 

Upisao: 

Dajana Lekić 

Područje: 

WINTRAN 


22.01.2013 


22.01.2013 



0









Poštovani, 

Provjerom liste udr usporedbe za dva razdoblja 01/11/2011-30/11/2011 i 01/01/2012-30/11/2012 nije mougće 

simulirati / dobiti uvid u grešku jer se greška -284 više ne javlja. 


Ništa , obzirom da je nestao uzrok pojave ove greške : 

-284 A subquery has returned not exactly one row. 

vraća više od 1 vrijednosti za nešto što se očekuje 1 vrijednost 

( napr 1 cijena i dobavljač za isti datum i artikal a vraća se više ...) 

Molimo pošaljite suglasnost za zatvarnje zahtjeva - riješeno 


Na objketu udr_ul.trn usporedba za dva razdoblje za godinu 2011 i 2012 je ispravljena greška 284 koja se javila 

zbog toga što artikal za istu maloprodajnu cijenu postoje dvijje različite marže u prvom razdoblju odnosno 2011 

godini dok u 2012 potoji samo jedna marža. 

Sada je to ispravljeno na način da za zadnju maloprodajnu cijenu iz prvog razdoblja ispsuje promet drugog 

razdoblja iste maloprodajne cijene i iste marže. 

Lib je preuzet. 



0











Klijent: 





rekg_ji 

Hitnost: 

Vrlo hitno 


glorija 


13058 


rekg_ji REKAPITULACIJA PO GRUPAMA ARTIKLA 

Ne može se napraviti ispis zbog navedene greške. 

Greška čitanja stanjem -255 


22.01.2013 09:36 

Upisao: 

Dajana Lekić 

Područje: 

LSLOD 


22.01.2013 


22.01.2013 


Poštovani , 

Zahtjev je ranije riješen i isporučen. 


Instalacija: sve je već isporučeno. 



Ispravljen je ispis na objektu rekg_ji REKAPITULACIJA PO GRUPAMA ARTIKALA. 

Preuzmite u utorak (09.04.2013) ujutro LAUS SLOD lib. 



0











Klijent: 





rucfil.jas 

Hitnost: 

Vrlo hitno 


katja 


13059 



22.01.2013 09:04 

Upisao: 

Dajana Lekić 

Područje: 

LWINFAU 


22.01.2013 


Za kupca ANATOLY SEMENOVSKY napravljen je predračun (u prilogu) ali u adresi se ne vidi država. 

U šifarniku partnera je država upisana - 644268 MR.ANATOLIY SEMENOVSKY. 

Država 804 Ukrajinska SSR. 

Prilozi: Mr Semenovsky PROFORMA inv no 38.pdf 


Poštovani, 

Potrebno je popuniti nazive (naziv na engleskom jeziku ) u šifarniku država jer se za račune u valuti (rucfil.jas) 

čitaju nazivi na engleskom. 

U slučaju računa kojeg ste poslali 01400-213-00038 za pratnra 644268 MR.ANATOLIY SEMENOVSKY. je 

upisana država 804 koja u nazive ima upisanu crticu (-) te se ista ispisuje na računu . 

drzava 804 

kratica 

nazivh UKRAJINSKA SSR 

nazive - 

telefon 997 

valuta 280 

dnevnica 

Molimo pošaljite suglasnost za zatvaranje zahtjeva - riješen 


Poštovani, 

Zahtjev zatvaram - Riješen uz vašu suglasnost 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Glorija 


13056 



21.01.2013 14:05 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


31.01.2013 


1. Na ekranu omogućiti prikaz broja izvoznog zaključka (redni broj iz nadzorne knjige/godina) . 


Poštovani, 

Na ekranu Rucfil.jas Računi u valuti (filatelija)omogućen je prikaz broja izvoznog zaključka (redni broj iz 

nadzorne knjige/godina) . 


Preuzmite novi WIN FAUS će biti dostupan sutra ujutro. 

Molimo povratne informacije nakon testiranja/ suglasnost za zatvranje zahtjeva - Riješen 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Glorija 


13055 



21.01.2013 12:51 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


21.01.2013 


23.01.2013 

U aplikaciji WIN - LAUS na listi „Pregled i ručni unos računa (kataloška i WEB prodaja)“ izvesti programsku 

doradu provedbom koje će se korisnicima aplikacije na spomenutom objektu, na polju „Otpremnica“ 

omogućiti automatski doseg te formiranje minusnog računa, a putem poziva na broj dokumenta RKP 

(Povratnica od kupca kataloške prodaje). Aplikacija odabirom ciljanog dokumenta prepisuje sadržaj (stavke, 

količina, korisnik, sl.) i nadnevak odabranog dokumenta te formira istovjetan minusni račun. 

Nadalje, a u korist preventive eventualnih problema u perspektivi u polje „Otpremnica“ 

predviditi/omogućiti unos te formiranje RAČUNA po unesenoj vezi na otpremni dokument za SVE 

dokumente u robno skladišnom poslovanju koji su kao takvi podloga za izradu računa. 


Poštovani, 

Na objektu za ručni unos kataloške prodaje u otpremnicu je omogućen unos dokumenta RKP. 

Stavke koje se upisuju u takav dokument se evidentiraju u minusu. 

Instalacija: sutra ujutro će biti dostupan novi WIN FAUS lib. 

S štovanjem 



0











Klijent: 



Pitanje 


Hitnost: 

Vrlo hitno 


Glorija 


13054 



21.01.2013 11:01 

Upisao: 

Božo Mišeta 

Područje: 

LBASE 


21.01.2013 


Svi Laus partneri Hrvatske šume u sustavu imajku oblik vlasništva T I upisanu grupa GRO. Kada se sad 

aide upisati grupa novoj šifri 644499 javlja se gore navedena poruka. 

Grupa GRO ne odgovara tipu vlasništva T 


Poštovani, 

Omogućeno je vezivanje grupe GRO i tipa vlasništva T. 


Preuzmite novi LBASE lib koji je već na internetu . 

Molimo povratne informacije sa testiranja/suglasnost za zatvaranje zahtjeva - Riješen 



0











Klijent: 





ZAHTJEV 19 

Hitnost: 

Vrlo hitno 


katja 


12714 



18.01.2013 17:17 

Upisao: 

Dajana Lekić 

Područje: 

EHPUR 


01.01.2013 


Kroz ovaj KZ se rješava dio zahtjeva HP broj 12714 a koji se (prema prilogu ZAHTJEV 19 ) odnosi na : 

ZAHTJEV 19 

Transakcija T19 – Unos nabave 

• Rok za dostavu ponude podijeliti na „datum“ i „vrijeme“ (zasebno), odnosno dva polja. 

Transakcija T20 – Pretraga i uređivanje nabave 

• Kod pretraživanja dodati kolone i polja u tražilicu „Rok za dostavu ponuda“ (datum i vrijeme od-do, 

zasebne kolone). 

Transakcija T21 

• Kod pretraživanja dodati kolone i polja u tražilicu „Rok za dostavu ponuda“ (datum i vrijeme od-do, 

zasebne kolone). 



0









Poštovani, 

Je li nužno djeliti polja na dva, odnosno od polja ˝Rok za dostavu ponuda˝ kao i filter polja od – do, dijeliti ih na 

datum i vrijeme? 

Naime, već sada imate funkcionalnost da u jednom polju možete unositi i datum i vrijeme. 


Poštovani, 


Ugrađeno je novo polje/kolona Vrijeme za dostavu ponuda kako na formi nabave, tako i na ekranima za pretragu 

odnosno tražilici. 




0











Klijent: 





ZAHTJEV 18 

Hitnost: 

Vrlo hitno 


katja 


12714 



18.01.2013 17:10 

Upisao: 

Dajana Lekić 

Područje: 

EHPUR 


01.01.2013 



ZAHTJEV 18 


Kod ispisa svih potvrda ne povlači zadani izbor: uzorci, mijenjana, dopunjena, povučena. Ako zadamo 

jedan od navedenih izbora isti treba povlačiti na ispis potvrde. (slika 8.a, 8.b i 8.c u prilogu) 



0









Poštovani, 

Ovaj zahtjev smatramo adaptivnim održavanjem. 

PROCJENA: 9h 


Poštovani, 




Da li uz dopunjenu ponudu moraju obavezno ići uzorci i broj komada ili može ići bez tih podataka? 



* 13410 

* 13411 

* 13412 

* 13436 

* 12714, zahtjev 9 

* 12714, zahtjev 18 


U prilogu je potvrda koja se ispisuje kada se označi da dodatak ponude ima slijedeća svojstva: dopunjena, uzorci 

su označeni i naveden je broj komada. 

Molim da probate ispisati dopunjenu potvrdu kao što sam gore navela. 

Ukoliko se potvrda dobro ispisuje predlažem zatvaranje zahtjeva. 



0











Klijent: 





ZAHTJEV 17 

Hitnost: 

Vrlo hitno 


katja 


12714 



18.01.2013 17:06 

Upisao: 

Dajana Lekić 

Područje: 

EHPUR 


01.01.2013 



ZAHTJEV 17 

Veza Upisnik-eHPUR Podaci koji se unose u modul „Upisnik o zaprimanju ponuda“ povezani su sa eHPUR 

-om te se isti bilježe kao podnesci, odnosno isti su vidljivi u dnevniku rada. Evidenciju koju aplikacija 

automatski odrađuje potrebno je urediti: 

Prilikom ispisa Upisnika o zaprimanju ponuda isto se mora automatski bilježiti u aplikaciji „eHPUR“ kao 

ulazni podnesak : 

a. Upisnik o zaprimanju zakašnjelih ponuda 

I. U polju Opis podneska: 

Dodatak Upisniku o zaprimanju ponuda/zahtjeva za sudjelovanje, izvadak broj ____/_____ s ponudom 

_________________.(naziv ponuditelja) 

II. U polju Pošiljatelj/Primatelj: 

Služba pisarnice 



0









Poštovani, 


PROCJENA: 4h 


Poštovani, 


Molimo povratne informacije/ suglanost za prebacivanje na produkciju 


Poštovani, 

Na testnom linku ne primjećujemo nedostatke. 

U privitku je primjer kako se preslikao opis podneska i svi podaci su zabilježeni. 

Pretpostavljam da ste testirali na način da niste nakon ručnog zatvaranja nabave ispisali obrazac Upisnik o 

zaprimanju ponuda 

i zatim ste unijeli zakašnjelu ponudu. 

Potrebno je ispisati navedeni obrazac na kojem se ujedno i generira broj izvatka kako bi se isti prenio u opis 

podneska. 



Poštovani, 

U redu. Svi testni podaci nabave i ponuda će biti izbrisani i krenuti će aplikacija od broja 1/2013. 

Pritom ne mislimo brisati, naravno, matične podatke (npr. odgovorne osobe….). 


Poštovani, 

Svi testni podaci nabave/ponuda su izbrisani i generiranje brojeva nabave počinje iznova odnosno od 1/2013. 

Odnosi se na Laus CC broj zahtjeva 40766 i 40767 , HP: 12714 




0











Klijent: 





ZAHTJEV 16 

Hitnost: 

Vrlo hitno 


katja 


12714 



18.01.2013 17:01 

Upisao: 

Dajana Lekić 

Područje: 

EHPUR 


01.01.2013 



ZAHTJEV 16 

Veza Upisnik-eHPUR Podaci koji se unose u modul „Upisnik o zaprimanju ponuda“ povezani su sa eHPUR 

-om te se isti bilježe kao podnesci, odnosno isti su vidljivi u dnevniku rada. Evidenciju koju aplikacija 

automatski odrađuje potrebno je urediti: 

Prilikom ispisa Upisnika o zaprimanju ponuda isto se mora automatski bilježiti u aplikaciji „eHPUR“ kao 

ulazni podnesak : 

a.Upisnik o zaprimanju ponuda /zahtjeva za sudjelovanje mora bilježiti : 

I.U polju Opis podneska: 

Upisnik o zaprimanju ponuda /zahtjeva za sudjelovanje, izvadak broj . ___ /____ s ____ 

ponuda. 

A u koliko su u istom zaprimljeni i uzorci, izmjene ili dopune na kraju je potrebno bilježiti 

„/uzorci“,“ /izmjene“, „/dopune“. 

II.U polju Pošiljatelj/Primatelj: 

Služba pisarnice 



0









Poštovani, 


PROCJENA: 5 h 


Poštovani, 

Molimo Vas popunjeni prikaz teksta za oba slučaja: 

a)Upisnik o zaprimanju ponuda /zahtjeva za sudjelovanje, izvadak broj . ___ /____ s ____ ponuda. 

b) A u koliko su u istom zaprimljeni i uzorci, izmjene ili dopune na kraju je potrebno bilježiti „/uzorci“,“ /izmjene“, 

„/dopune“. 


Poštovani, 




Poštovani, 

Vezano za pitanje : 

Što je po ovom zahtjevu riješeno? Mislim da ste pobrkali zahtjeve br. 16 i 17? 

Da li se 16 ili 17 odnosi na import podataka iz starog "Upisnika o zaprimanju ponuda"? 

u nastavku je pojašnjenje . 

Riješeno je prema zahtjevu 16 :Ne radi se o importu već o vezi između Upisnika i HPUR- a. 

Znači kada se npr. ispiše upisnik o zaprimanju ponuda isti se preslikava u eHPUR kao ulazni podnesak (to je već 

i prije radilo) u formatu i s podacima kako su tražili (novi je tekst i sl…). 

Prebačeno na test 8.5.2013. Provjereno na testu : sve se preslikalo u HPUR-u (ono što ste testno napravili). 

NAPOMENA : sav import se vodi pod starim brojem KZ 39879 (zahtjev 2) HP 12714 za kojeg je HP poslala 

prilog upisnik.zip 

Molimo povratne informacije za točku 16 


Poštovani, 

Na testnom linku ne primjećujemo nedostatke. 

U privitku je primjer kako se preslikao opis podneska i svi podaci su zabilježeni. 

Dodatke kao što su uzorci/izmjene/dopune, nisu zabilježene jer ih u ponudi nije ni bilo. 

( detalji u prilozima) 




0









Poštovani, 

Prilikom prebacivanja dorada na test u više navrata i brisanja postojećih testnih podataka, brojevi su se 

˝restartali˝ na obrascu i krenuli su ispočetka, dok su na gridu/formi nastavili dalje (kao da i dalje postoje ti 

stari/izbrisani podaci) niz te je uslijed navedenog nastala nepodudarnost. 

Ukoliko želite, možemo prilikom nekog od slijedećih prebacivanja preostalih zahtjeva za upisnik restartati 

brojeve. 



Poštovani, 

U redu. Svi testni podaci nabave i ponuda će biti izbrisani i krenuti će aplikacija od broja 1/2013. 

Pritom ne mislimo brisati, naravno, matične podatke (npr. odgovorne osobe….). 


Poštovani, 

Svi testni podaci nabave/ponuda su izbrisani i generiranje brojeva nabave počinje iznova odnosno od 1/2013. 

Odnosi se na Laus CC broj zahtjeva 40766 i 40767 , HP: 12714 




0











Klijent: 





ZAHTJEV 15 

Hitnost: 

Vrlo hitno 


katja 


12714 



18.01.2013 16:56 

Upisao: 

Dajana Lekić 

Područje: 

EHPUR 


01.01.2013 



ZAHTJEV 15 

Transakcija T26 – Unos Žalbe /Zahtjeva 

Prema naputku Ureda za javnu nabavu nema potrebe za ovom transakcijom. Ovu transakciju potrebno 

ukloniti. 



0









Poštovani, 


PROCJENA: 1h 

Pretpostavljamo da želite onda ukloniti sve transakcije u tom procesu, njih 3!? 


Poštovani, 

Ponavljamo upit, da li to znači da je potrebno ukloniti sve tri transakcije iz poslovnog procesa P3 - Žalbe/Zahtjevi 

(T26, T27 i T33)? 


Poštovani, 

Izvršene su dorade po ovom zahtjevu i prebačene na Vaš testni server. 

Molimo povratne informacije/ suglasnost za prebacivanje na produkciju i zatvaranje zahtjeva- Riješen 


Poštovani , 

Ne postoji produkcija za Upisnik o zaprimanju ponuda . Kada se zahtjev isporuči na test i HP potvrdi da je 

zahtjev riješen, samo ga zatvorimo... 

Razlog : Upisniko zaprimanju ponuda je samo na testu. 

Molimo suglasnost za zatvanje ovog zahtjeva bez prebacivanja na produkciju - Riješen 

jer je isporučen na test i od starne HP potvrđeno da je riješen : 

18.3.2013 (Katja) : Provjereno na testu. Zahtjev je riješen. Dorade možete prebaciti na produkciju i zatvoriti 

zahtjev. 

Za sve nejasnoće možete kontaktirati : 


Poslovni analitičar 

mob: 091/2353-814 

e-mail : bgorup@dokumentit.hr 



0











Klijent: 





ZAHTJEV 14 

Hitnost: 

Vrlo hitno 


katja 


12714 



18.01.2013 16:53 

Upisao: 

Dajana Lekić 

Područje: 

EHPUR 


01.01.2013 



ZAHTJEV 14 

Transakcija T25 – Unos zakašnjelih ponuda 

Kod ispisa „Potvrda o zaprimanju zakašnjele ponude“ treba urediti obrazac: 

Kod ispisa navedene potvrde ne povlači zadani izbor: uzorci, zatvorena, otvorena, oštećena, alternativa. 

Ako zadamo jedan od navedenih izbora isti treba povlačiti na ispis potvrde. (slika 9.a i 9.b u prilogu) 



0









Poštovani, 


PROCJENA: 12 h. 


Poštovani, 

Zahtjev koji ste naveli ne može biti dio zahtjeva 12714 (Zahtjev 14), jedina veza s njim je što se radi o 

Zakašnjelim ponudama. 

Molimo da otvorite novi adaptivni zahtjev . 

Unaprijed zahvaljujem. 

Lp, 

U modulu Upisnik kod transakcije „T25 – Unos zakašnjele ponude“ nakon unosa zakašnjele ponude treba 

omogućiti ispis „Upisnik o zaprimanju ponuda - Zakašnjele“ 

kao u transakciji T20 kod pregleda nabave gdje su unesene zakašnjele ponude. 


Poštovani, 




Poštovani, 



Točku 14. zahtjeva 12714 koja se vodi u ovom KZ 40764 smatramo riješenom . 

Molimo suglasnost za zatvaranje ovog KZ tj. točke 14 . zahtjeva HP broj 12714 


Poštovani, 


S štovanjem 

Poštovani! 

Možete zatvoriti ZAHTJEV 14. 

Lp, 



0











Klijent: 





ZAHTJEV 13 

Hitnost: 

Vrlo hitno 


katja 


12714 



18.01.2013 16:51 

Upisao: 

Dajana Lekić 

Područje: 

EHPUR 


01.01.2013 



ZAHTJEV 13 


Kod unosa ponuda polje „Datum zaprimanja ponude“ treba povlačiti trenutni datum i vrijeme, te dopuštati 

izmjenu datuma i vremena. 


Kod unosa ponuda polje „Datum zaprimanja ponude“ treba povlačiti trenutni datum i vrijeme, te dopuštati 

izmjenu datuma i vremena, odnosno treba omogućiti ručni unos datuma i vremena. 


Poštovani, 




Poštovani , 


bez prebacicvanja na produkciju . 

Upisnik o zaprimanju ponuda je samo na test okruženju 

------------------------------------------ 

18.3.2013. potvrđena je ispravnost na test okruženju 



0











Klijent: 





ZAHTJEV 12 

Hitnost: 

Vrlo hitno 


katja 


12714 



18.01.2013 16:47 

Upisao: 

Dajana Lekić 

Područje: 

EHPUR 


01.01.2013 



ZAHTJEV 12 


Kod unosa ponuda polje „Zatvorena“ i polje „Otvorena“ potrebno spojiti u jedno polje s padajućim 

izbornikom (izbor Zatvorena ,Otvorena) pod nazivom „Omotnica pristigla“ 



0









Poštovani, 


PROCJENA: 6h 


Poštovani, 




Poštovani, 


bez prebacivanja na produkciju . 

Upisnik se zasad ne prebacuje na produkciju nego je samo na test-u . 

15.3.2013 : Izvršene su dorade po ovom zahtjevu i prebačene na test server 


Poštovani, 




0











Klijent: 





ZAHTJEV 11 

Hitnost: 

Vrlo hitno 


katja 


12714 



18.01.2013 16:43 

Upisao: 

Dajana Lekić 

Područje: 

EHPUR 


01.01.2013 



ZAHTJEV 11 


a. Kod ispisa „Potvrda o zaprimanju dodatka ili izmjene “ treba urediti obrazac. 

I. Na crtu „…izvadak broj:“ treba povlačiti redni broj nabave (upisnika). (slika 7. u prilogu) 


Poštovani, 


Molimo povratne informacije / obavijest za prebacivanje na produkciju 


Poštovani, 



4.3.2013 potvrđena ispravnost na testu. Upisnik se zasad ne prebacuje na produkciju nego je samo na test-u 



0











Klijent: 





ZAHTJEV 10 

Hitnost: 

Vrlo hitno 


katja 


12714 



18.01.2013 16:41 

Upisao: 

Dajana Lekić 

Područje: 

EHPUR 


01.01.2013 



ZAHTJEV 10 


Nije dopušteno da izbor istovremeno bude povučena i dopunjena ili povučena i mijenjana. 


Poštovani, 




Poštovani, 






0











Klijent: 





ZAHTJEV 9 

Hitnost: 

Vrlo hitno 


katja 


12714 



18.01.2013 16:36 

Upisao: 

Dajana Lekić 

Područje: 

EHPUR 


01.01.2013 



ZAHTJEV 9 

Transakcija T23 – Evidentiranje dodataka ponude 

a. Unesene dopune ili izmjene u Upisniku se trebaju tretirati kao ponude vezano uz redni broj zaprimanja. 

Unesene dopune ili izmjene ponuda trebaju nastaviti niz rednih brojeva od zaprimljenih ponuda. 

I. U točku 7. Upisniku „Br. Omotnice“ upisuje redni broj izmjene ili dopune ponude prema redoslijedu 

zaprimanja, odnosno naredna zaprimljena ponuda koja se upisuje u točku 6. Upisnika treba imati „Br. 

Omotnice“ koji slijedi nakon zaprimljene naprijed navedene izmjene ili dopune ponude. (slika 11. u prilogu) 

II. U točku 7. Upisnika je također potrebno prikazati podatak „Omotnica pristigla –Zatvorena, Otvorena, 

Oštećena“ na identičan način kao i u točki 6. Upisnika. (slika 11. u prilogu) 



0









Poštovani, 


PROCJENA: 11 h. 


Pitanje za HP 

1. Prilog 'Upisnik o zaprimanju ponuda' je primjer upisnika kakvog smo dobili od vas i tamo je drugačiji 

redoslijed generiranja brojeva od ovog što sada tražite (crveno označeno). 

Da li i dalje stojite pri ovom novom načinu evidentiranja? 

2. Prilog 'Upisnik o zaprimanju ponuda' je primjer upisnika kakvog smo dobili od vas i tamo je zeleno 

označeno u točki 7. da je i prije stajao tekst 'Ponuda/zahtjev za sudjelovanje pristigla….' 

Da li i dalje stojite pri ovom novom načinu evidentiranja? 

3. Procjena za ov ajzahtjev je 11 sati ADAPTIVNO . 

Da li se slažete s procjenom i načinom održavanja ? 

Čekamo pojašnjenja 



Zahtjev da se podatak V. iz točke 6. prikazuje i u točki 7. je nemoguće izvršiti osim da se cijeli obrazac stavi na 

landscape, a pretpostavljam da se od nijednog podatka iz točke 7. ne može odustati. Molim neki drugi prijedlog. 

Iz zapisnika o testiranju: 

6. Transakcija T23 – Evidentiranje dodataka ponude 

'U točku 7. Upisnika je također potrebno prikazati podatak „Omotnica pristigla –Zatvorena, Otvorena, Oštećena“ 

na identičan način kao i u točki 6. Upisnika.' 



0









Poštovani, 

Jeste li dobili informaciju od Nabave, a vezano za naš upit: Zahtjev da se podatak V. iz točke 6. prikazuje i u 

točki 7. je nemoguće izvršiti osim da se cijeli obrazac stavi na landscape, a pretpostavljam da se od nijednog 

podatka iz točke 7. ne može odustati. Molim neki drugi prijedlog. 

Lp, 


Ako će se na obrascu i za točku 7. evidentirati podaci kao u točki 6. (podatak „Omotnica pristigla –Zatvorena, 

Otvorena, Oštećena“) onda je potrebno u kartici gdje se evidentiraju dodaci ponuda dodati još kolone 'Omotnica 

pristigla ' (zatvorena/otvorena) i 'Oštećena' (Da, Ne). 

Ako se s time slažete molim da pošaljete zahtjev za istim. 


Poštovani, 

Zahtjev stoji na čekanju odgovora od HP 

Ako će se na obrascu i za točku 7. evidentirati podaci kao u točki 6. (podatak „Omotnica pristigla –Zatvorena, 

Otvorena, Oštećena“) onda je potrebno u kartici gdje se evidentiraju dodaci ponuda dodati još kolone 'Omotnica 

pristigla ' (zatvorena/otvorena) i 'Oštećena' (Da, Ne). 

Ako se s time slažete molim da pošaljete zahtjev za istim. 







* 13410 

* 13411 

* 13412 

* 13436 

* 12714, zahtjev 9 

* 12714, zahtjev 18 



0











Klijent: 





ZAHTJEV 8 

Hitnost: 

Vrlo hitno 


katja 


12714 



18.01.2013 16:35 

Upisao: 

Dajana Lekić 

Područje: 

EHPUR 


01.01.2013 



ZAHTJEV 8 


a. Kod ispisa „Potvrda o zaprimanju ponude“ treba urediti obrazac: 

I. Na crtu „…izvadak broj:“ treba povlačiti redni broj nabave (upisnika. (slika 5. u prilogu) 

Kod ispisa svih potvrda ne povlači zadani izbor: uzorci, zatvorena, otvorena, oštećena, alternativa. Ako 

zadamo jedan od navedenih izbora isti treba povlačiti na ispis potvrde. 



0









Poštovani, 

U prilogu se nalazi primjer Potvrde o zaprimanju ponude/zahtjeva za sudjelovanje. 

Da li vam odgovara tekst '…dostavio naručitelju ponudu/zahtjev za sudjelovanje……'? 

U donjem dijelu potvrde bi stavili tekst 'Redni broj omota', 'Uzorci' itd. za koje bi se podaci povlačili iz aplikacije. 

Molimo povratne inforamcije 


Poštovani, 




Poštovani, 



Točku 8. zahtjeva 12714 koja se vodi u ovom KZ 40758 smatramo riješenom . 

Molimo suglasnost za zatvaranje ovog KZ tj. točke 8. zahtjeva HP broj 12714 


Po vašem nalogu zatvaramo zahtjev 

Poštovani! 

Možete zatvoriti ZAHTJEV 8. 

Lp, 



0











Klijent: 





ZAHTJEV 7 

Hitnost: 

Vrlo hitno 


katja 


12714 



18.01.2013 16:32 

Upisao: 

Dajana Lekić 

Područje: 

EHPUR 


01.01.2013 



ZAHTJEV 7 


Omogućiti ručno zaključivanje ranije definiranog roka za dostavu ponude, nakon čega nam aplikacija nudi 

ispis „Upisnika o zaprimanju ponuda“, odnosno nakon ispisa „Upisnika“ navedenu nabavu definirati u status 

„Istekao rok za dostavu ponuda“. 

Razlog: u slučaju da nam dođe 3 ponuditelja minutu prije isteka roka, nismo fizički u mogućnosti to odraditi 

u tekućoj minuti (napominjemo da je isto u staroj aplikaciji omogućeno). 


Poštovani, 


Javit ekad treba na produkciju prebaciti 


Poštovani, 






0











Klijent: 





ZAHTJEV 6 

Hitnost: 

Vrlo hitno 


katja 


12714 



18.01.2013 16:28 

Upisao: 

Dajana Lekić 

Područje: 

EHPUR 


01.01.2013 



ZAHTJEV 6 

Transakcija T21 – „Unos ponude“ 

Kod unosa ponuda polje „Zatvorena“ i polje „Otvorena“ potrebno spojiti u jedno polje s padajućim 

izbornikom (izbor Zatvorena; Otvorena) pod nazivom „Omotnica pristigla“. 



0









Poštovani, 


PROCJENA: 6h 


Poštovani, 




Poštovani , 

18.3.2013 (Katja) : 

Provjereno na testu. Zahtjev je riješen. Dorade možete prebaciti na produkciju i zatvoriti zahtjev. 

Danas je stiglo pojašnjenje : 

Ne postoji produkcija za Upisnik, kada potvrde da je zahtjev riješen, samo ga zatvorimo... Upisnik je samo na 

testu! 

Molimo suglasnost za zatvanje zahtjeva bez prebacivanja na produkciju - Riješen 




mob: 091/2353-814 



Poštovani, 



18.3.2013 i 8.4.2013. potvrđena ispravnost na testu. Upisnik se zasad ne prebacuje na produkciju nego je samo 

na test-u 



0











Klijent: 





ZAHTJEV 5 

Hitnost: 

Vrlo hitno 


katja 


12714 



18.01.2013 16:20 

Upisao: 

Dajana Lekić 

Područje: 

EHPUR 


01.01.2013 



ZAHTJEV 5 

Transakcija T20 – Pretraga i uređivanje nabave 

a. Ispis obrasca „Upisnik o zaprimanju ponuda“ treba urediti. 

I. Obrazac upisnika urediti s kvačicama. (slika 1. u prilogu) 

II. Ispis u PDF ispisuje dobro, a „običan“ ispis ne ispisuje dobro. 

(slika 2.u prilogu) 

b. Ispis obrasca „Upisnik o zaprimanju ponuda - Zakašnjele“ treba urediti. 

I. Preimenovati obrazac u „Popis zakašnjelih ponuda/zahtjev za 

sudjelovanje br.____/20__“ .(Slika 10. u prilogu) 

II. Obrazac upisnika urediti s kvačicama. (slika 3. u prilogu) 

III. Ispis u PDF ispisuje dobro, a „običan“ ispis ne ispisuje dobro. 

(slika 4. u prilogu) 



0









Poštovani,, 

Molimo detaljnije objašnjenje, što se misli pod ˝običnim˝ ispisom. Objasniti postupak. 


Poštovani, 


A vezano za dio: ˝Ispis u PDF ispisuje dobro, a „običan“ ispis ne ispisuje dobro.˝ - rješenje: Instaliranjem 

Adobe® Reader plug-ina. 

Da bi se održala konzistencija ispisa potrebno je instalirati plugin za browser (Adobe Acrobat), ako već nije 

instaliran na korisničko računalo 


Poštovani , 

Zahtjev zatvaramo ( ZAHTJEV 5) - korisnik potvdio ispravnost. 

NAPOMENA: Upisnik zasad ne ide na produkciju . 

Inicijani zahtjev KZ 39879 ostaje u statusu U rješavanju. (ZAHTJEV 2) 

Pojedine točke zahtjeva vode se po posebnim KZ i njih zatvaramo nakon što se na TEST-u potvrdi ispravnost . 

Status pojedinih KZ-a vezanih za HP 12714 (Upisnik) šaljemo u prilogu . 



0











Klijent: 





kontni plan 






laus 40603 

Riješen 


18.01.2013 16:20 

Upisao: 


Područje: 

AFINK 


adaptivni dio rješavanja problema uz zahtjev 40603. Ustanovljeno je da na međubazi ne dozvoljava 

izmjernu retka na uputi na konto koje više ne postoji u kontnom planu za 2012 - zbog toga što je netko u 

LAUS-u izbrisao konto. 


Ustanovljeno je da na međubazi ne dozvoljava izmjernu retka na uputi na konto koje više ne postoji u kontnom 

planu za 2012 - zbog toga što je netko u LAUS-u izbrisao konto. 



0











Klijent: 





bexweb 






Dražene, 

Riješen 


18.01.2013 16:15 

Upisao: 


Područje: 

LCSBI 


ne mogu pristupiti BEx web-u, sustav javlja niz grešaka (vidi sliku ekrana). Jučer se DDRDG uopće nije 

mogao učitati! 



Divizija podrška 

Sektor kontrolinga 


Jurišićeva 13 

10000 Zagreb 

Tel.: +385 1 498 1149 

Faks: +385 1 498 1282 

GSM: +385 98 983 7460, VPN 8099 

e-mail: nada.martinovic@posta.hr 

www.posta.hr 



0











Klijent: 





ZAHTJEV 4 

Hitnost: 

Vrlo hitno 


katja 


12714 



18.01.2013 16:13 

Upisao: 

Dajana Lekić 

Područje: 

EHPUR 


01.01.2013 



ZAHTJEV 4 

Transakcija T19 – Unos nabave 

U polje „Odgovorna osoba za nabavu“ treba povlačiti sve rješavatelje koji se nalaze u nadležnosti 

organizacijskoj jedinici HP-10, HP-10/1 i HP-10/2 (eHPUR). 



0









Poštovani, 


PROCJENA: 

Postoji šifrarnik/matični podaci "ODGOVORNA OSOBA" koji se popuni s odgovornim osobama, ako DokIT bude 

unosio ove podatke odnosno ne bude povezivanja za naknadne odg. osobe onda je procjena 1h. 


Poštovani, 

Možete li pojasniti točku : 

Naime postoji šifrarnik/matični podatak ˝Odgovorna osoba˝ i kada se upisuje (pomoću 3 znaka) u to polje 

podatak, ukoliko postoji unesen u isti, osoba će se moći odabrati. 


Poštovani, 

Želite da to polje po defaultu bude popunjeno sa svim rješavateljima iz tih orgj koje ste naveli ili da možete kao 

do sada odabrati jednog od, ali da se referencira na matični podatak Djelatnici? 


Poštovani, 

Nastavno na dosada napisano, molimo odgovore na slijedeća pitanja: 

1. Koliko postoji osoba koje rade u HP-10, HP-10/1 i HP-10/2 (prema našoj evidenciji ima ih 12)? 

2. Znači li to da će se sve te osobe onda povlačiti na obrascima koji se trebaju ispisivati uz aplikacije, npr. 

Upisnik o zaprimanju ponuda? 

3. Kada dođe do promjena u odgovornim osobama (npr. novi djelatnici, preseljenje djelatnika u druge org. 

jedinice koje nisu HP-10.., ) da li ćete Vi ažurirati promjene u matičnom podatku Odgovorna osoba na način da 

ćete unositi nove, deaktivirati stare? 



0









Poštovani, 

1. Od početka je zamišljeno da se u šifrarnik 'Odgovorna osoba' evidentiraju sve osobe koje će se moći 

odabrati u polju ' Odgovorna osoba za nabavu'. 

Vi ste u zapisniku od 29-11-2012 naveli, citiram "U polje „Odgovorna osoba za nabavu“ treba povlačiti sve 

rješavatelje koji se nalaze u nadležnosti organizacijskoj jedinici HP-10, HP-10/1 i HP-10/2 (eHPUR) ". 

Naše pitanje je nakon toga bilo da li želite da u tom polju sami birate osobe iz tog šifrarnika ili se automatski 

moraju povlačiti svi iz tih jedinica, s obzirom da je Vaša točka iz zapisnika sugerirala drugačiju funkcionalnost. 

Zaključak nakon nekoliko prepiski je da je aplikacija od početka bila postavljena sukladno dogovorenom i da nije 

bilo potrebe za nikakvom promjenom. 

2. Na obrascu se povlače odgovorne osobe za nabavu, a ne za ponudu, kao što kaže i istoimeno polje. S 

obzirom na nedoumice koje smo objasnili u točki 1. bilo je potrebno postaviti pitanje vezano za obrazac. 

-- u prilogu primjer 


Poštovani, 

Izvršene su dorade po ovom zahtjevu, a vezano uz: ˝ Nismo u mogućnosti provjeriti traženo zbog greške koja 

nam se javlja pri pokušaju unosa ponude u T19 – testna baza.˝ 



Poštovani, 



Upisnik se zasad ne prebacuje na produkciju nego je samo na test-u . 

15.3.2013 : Izvršene su dorade po ovom zahtjevu, a vezano uz: 

˝ Nismo u mogućnosti provjeriti traženo zbog greške koja nam se javlja pri pokušaju unosa ponude u T19 – 

testna baza.˝ 


Poštovani, 




0











Klijent: 





ZAHTJEV 3 

Hitnost: 

Vrlo hitno 


katja 


12714 



18.01.2013 16:06 

Upisao: 

Dajana Lekić 

Područje: 

EHPUR 


01.01.2013 



ZAHTJEV 3 

1. Transakcija T19 – Unos nabave 

a. Status „Istekla nabava“ preimenovati u „Istekao rok za dostavu ponuda“. 

b. Status „Unesena nabava“ preimenovati u „U tijeku rok za dostavu ponuda“. 

c. Polje „Broj objave“ preimenovati u „Registarski broj“. 

d. Odgovorna osoba za nabavu“ je obavezno polje 

2. Transakcija T21 – „Unos ponude“ preimenovat u „Unos ponude/Nabave u tijeku“ 

3. Transakcija T21 - Kod unosa ponude polje „Alternativa“ je neobavezno polje. 

4. Transakcija T25 – Unos zakašnjelih ponuda - Kod unosa ponuda „Alternativa“ je neobavezno polje. 



0









Poštovani, 




Poštovani, 






0











Klijent: 





ZAHTJEV 1 

Hitnost: 

Vrlo hitno 


katja 


12714 



18.01.2013 16:00 

Upisao: 

Dajana Lekić 

Područje: 

EHPUR 


01.01.2013 



ZAHTJEV 1 

Redni broj nabave mora sadržavati redni broj i tekuću godinu (___/2012), te isti početkom svake nove 

godine započinje niz od broja 1. 



0









Poštovani, 


PROCJENA: 4,5h 


Poštovani, 


Molimo povratne informacije/ obavjest za prebacivanje na produkciju 


Poštovani , 




Molimo suglasnost za zatvanje ovog zahtjeva bez prebacivanja na produkciju - Riješen 

jer je isporučen na test i od starne HP potvrđeno da je riješen : 

4.3.2013 (Katja) : Provjereno na testu. Zahtjev je riješen. Dorade možete prebaciti na produkciju i zatvoriti 

zahtjev. 




mob: 091/2353-814 



Poštovani , 




zatvamo zahtjev bez prebacivanja na produkciju - Riješen 

jer je isporučen na test i od starne HP potvrđeno da je riješen 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13053 



18.01.2013 15:12 

Upisao: 

Božo Mišeta 

Područje: 

LROBD 


18.01.2013 


1. Napravljen je prijenos zah_jtr PRIJENOS MATIČNIH PODATAKA ZAHTJEVNICE PU (SVE F1) 

ali mi se nisu prenijele kategorije PU ( vidi tablicu u mips_laus bazi: tablica kategorija_pu) – 

prazna, iako su unesene kategorije PU u laus bazu (tablica kategorija_pu). 

2. Molim ispravak da se prilikom unosa asortimana u status 1 podaci mogu mijenjati (uključujući i 

datum_od), jer trenutno nije moguća izmjena datuma_od 

Lp, 

----------------------------------------------------- 

Katja Kraljev 



0









Poštovani, 

Točka 2 ovog zahtjeva stavljena je u rad. 

Točka 1 redosljed događanja: 

a) napraljen prijenos podataka u MIPS, svi podaci preneseni osim asortimana (asortiman nije prenešen jer 

nijedan od asortimana nije bio u statusu 2) 

b) asortimani prebačeni u status 2 i obrisana tablica sa prethodnim prenosima u međubazi LAUS - MIPS 

c) ponovljen prenos podataka u MIPS, svi podaci preneseni ali tablica kategorija_pu ostala prazna - nisu 

kategorije prenesene 

Razlog neprenošenja je taj što su 4 kategorije dobile indikator da su prenesene i zato nisu prenesene po drugi 

put 

Da li smijemo mi intervenirati na bazu, kako bismo skinuli navedeni indikator, te kako bi se prenos mogao 

ponoviti! 

Molim odobrenje! 

S štovanjem 


Poštovanje, 

Ovaj zahtjev spada u adaptivno održavanje iz slijedećih tazloga: 

Prvi dio zahtjeva zahtjeva našu intervenciju nad podacima u bazi (analizu stanja i popis koraka koje trebate 

napraviti), nakon brisanja podataka korištenjem SQL naredbi, a ne kroz program. 

Drugi dio zahtjeva odnosi se na izmjenu isporučene funkcionalnosti. 

Stoga molim da u svojim evidencijama promijenite razlog zahtjeva i vrstu održavanja. 




Poštovani, 

Da bi se kategorije ponovo prenjele u mips bazu nakon brisanja podataka u Mips bazi, potrebno je u LAUS 

tablici zah_asortiman za sve kategorije koje se žele prenjeti polje red staviti da je '' (blank). 

Polje akcija se treba staviti na vrijednost 'U' ako se radi prvi put o unosu, a vrijednost 'I' ako se radi o izmjeni. 

Ako se radi o akciji unosa (akcija='U') treba pripaziti da kategorija sa akcijom unosa nema istovremeno podatak 

za akciju izmjena. 

S štovanjem 



0









Poštovanje, 

Laus nije ništa radio po produkcijskoj bazi vezano za ovaj zahtjev. Dobili ste samo traženi odgovor na pitanje 

koje ste postavili! 

Ponavljam: Podaci se ne prenose jer su jednom već preneseni, a potom izbrisani kroz bazu (ne Laus već netko 

iz HP-a). 

Nakon toga kad se ponavlja prenos, podaci se ne prenose jer treba izmjeniti u tablici indikatore prenosa. 

Dobili ste odgovor na postavljeno pitanje. 

Za sve vaše upite stojimo vam na raspolaganju. 

S štovanjem 

U zahtjevu nisu tražene nikakve vaše intervencije po bazi, već samo informacija koji je to indikator koji se puni 

prilikom prijenosa matičnih podataka zahtjevnice PU tj.kategorije PU. 

Što se tiče drugog dijela zahtjeva, smatrali smo da postoji postimplementacijski period, u kojem je još moguće 

tražiti dorade koje ulaze u ugovor. 

Lp, 

Katja Kraljev 


Poštovani, 

Da bi se kategorije ponovo prenjele u mips bazu, potrebno je u LAUS tablici zah_katpu_posta za sve podatke 

koji se žele prenjeti polje red staviti da je '' (blank). 

Polje akcija se treba staviti na vrijednost 'U' ako se radi prvi put o unosu, a vrijednost 'I' ako se radi o izmjeni. 

Potrebno je pripazita da se za podatak koji je već prenesen u mips ne mijenja ništa u tablici zah_katpu_posta. 

S štovanjem 



0









Poštovani, 

zaboravio sam napisati ovu obradu koja je spuštena s libovima (mislim u petak). 

Napravljena je nadogradnja da se asortimanu može mjenjati datum OD dok se asortiman nalazi u statusu 1. 

Prenjeti krajnjem korisniku: da je prilikom unosa artikala u asortiman tražena funkcionalnost provjere, da li se taj 

artikl nalazi u nekom drugom asortimanu. 

Stoga će se nakon izmjene datuma OD, modul za svaki artikl ponovo postavljati upit nalazi li se artikl u nekom 

drugom asortimanu i tražiti potvrdu unosa. 

S ovom traženom kontrolom korisnik je želio postići kontrolu unosa, kako se greškom nebi unosili artikli koji već 

postoje u nekim drugim asortimanima. Potvrdom unosa i aktiviranjem asortimana (status 2) automatski se iz 

prvog asortimana vrši "izbacivanje-dezaktiviranje" kako bi se zadovolji traženi princip "jedan artikl jedan 

asortiman". 

U nastavku sql-ovi koji brišu sve podatke iz svih tablica. Nakon izvođenja sql-ova a prije nastavka rada na 

unosu, molim obavjestite nas kako bi provjerili jesu li obrisani svi podaci. 

Sql-ovi: 

--LAUS baza 

DELETE FROM asortiman WHERE 1=1; 

DELETE FROM kategorija_pu WHERE 1=1; 

DELETE FROM artikal_ko WHERE 1=1; 

DELETE FROM asortiman_art WHERE 1=1; 

DELETE FROM katpu_posta WHERE 1=1; 

DELETE FROM katpu_asortiman WHERE 1=1; 

DELETE FROM zah_asortiman WHERE 1=1; 

DELETE FROM zah_kategorija_pu WHERE 1=1; 

DELETE FROM zah_artikal_ko WHERE 1=1; 

DELETE FROM zah_asortiman_art WHERE 1=1; 

DELETE FROM zah_katpu_posta WHERE 1=1; 

DELETE FROM zah_katpu_asortiman WHERE 1=1; 

--MIPS baza 

DELETE FROM asortiman WHERE 1=1; 

DELETE FROM kategorija_pu WHERE 1=1; 

DELETE FROM artikal_ko WHERE 1=1; 

DELETE FROM asortiman_art WHERE 1=1; 

DELETE FROM katpu_posta WHERE 1=1; 

DELETE FROM katpu_asortiman WHERE 1=1; 



0









Poštovani, 

pokušao sam ovo simulirati, ali nemogu ponoviti situaciju. Pretpostavljam (razgovarali smo kad si probala), 

ponavljam pretpostavljam, da jedan korisnik drži asortiman na ekranu s statusu 2, dok drugi istovremen isti 

asortiman ima na ekranu u statusu 1 prije aktiviranja i pokušava ga prebaciti u veći status, a to nije 2 već tri - 

dezaktivacija asortimana. 

Prilikom aktivacije i dezaktivacije asortimana artikli se automatski aktiviraju i dezaktiviraju u drugim asortimanima 

iz kojih su potekli. U ovom slučaju imamo situaciju da se pokušava aktivirati ili dezaktivirati artikl, a to je moguće 

učiniti sa datumom dan ranije - a taj dan je prošao 21.01.2013. 

Korisnički zahtjev je takav. Ovakve situacije će morati riješavati sa dezaktiviranjem asortimana, njihovim 

kopiranjem i prilagođavanjem datuma OD. 

Situacija da se aktiviraju dva asortimana, sa istim datumom OD koji je mlađi za 1 dan od tekučeg datuma, je 

nekorektna. Jer korisnik nije poštovao pravilo da isti artikl nemože biti u dva asortimana istovremeno, na što ga 

je upozorio program prilikom unosa artikla u asortiman, porukom artikl postoji u asortimanu tom i tom!! 

Komplicirano je neznam bolje objasniti! 

S štovanjem 


Zahtjevnice se ne prenose informacijskim servisom jer na produkciji nije instalirana najnovija verzija prijenosa 

(copy/paste datoteke ArgosyIntegrator/eObradaRacuna.dll sa testnog servera na produkcijski). 

Također nije kreiran konekcijski string za spajanje na laus produkcijsku bazu. Naziv konekcijskog strina bi trebao 

biti InformixLaus. 

Nakon instalacije potrebno je u ArgosyIntegrator/Servis.exe.config datoteci uključiti prijenos tako da se doda 

linija 

 

Sve promjene je potrebno napraviti nakon što se stopira integracijski servis! 



0









Poštovana, 

"Pa vi (laus) trebate kreirati konekcijski sting na bazu. Zašto to nama šaljete?" 

Za svaku intervenciju, bez obzira o čemu je riječ, ja moram upoznati HP i dobiti dozvolu. 

Gornju primjedbu shvatio sam kao nalog, i zaposlio sistemaša koji će to odraditi. 

No niste mi odgovorili na ostatak: 

Da li ćete vi instalirati najnoviju verziju prijenosa, i uključiti prijenos? 

S štovanjem 

Zahtjevnice se ne prenose informacijskim servisom jer na produkciji nije instalirana najnovija verzija prijenosa 

(copy/paste datoteke ArgosyIntegrator/eObradaRacuna.dll sa testnog servera na produkcijski). 

Također nije kreiran konekcijski string za spajanje na laus produkcijsku bazu. Naziv konekcijskog strina bi trebao 

biti InformixLaus. 

Nakon instalacije potrebno je u ArgosyIntegrator/Servis.exe.config datoteci uključiti prijenos tako da se doda 

linija 

 

Sve promjene je potrebno napraviti nakon što se stopira integracijski servis! 


Poštovani, 

odrađen string, pokrenut servis. U depo-u Zagreb oformljene dvije zahtjevnice u statusu 1. 

Molim provjeriti da li je bilo još zahtjevnica koje je servis trebao prenjeti. 

S štovanjem 



0









Poštovani, 

prelasci statusa za dokument ZAH: 

ZAH1 G l1robd EVIDENTRIRANA ZAHTJEVICA 

ZAH15 H l1robd ZAKLUźIVANJE ZAHTJEVNICE 

ZAH2 G l1robd NIJE U CIJELOSTI ISPORU¬ENA 


ZAH3 G l1robd NIJE U CIJELOSTI ISPORU¬ENA - 


ZAH4 G l1robd ISPORU¬ENA SVA ZAHTJEVANA KOLI 

ZAH5 G l1robd ZAKLJU¬ENA ZAHTJEVNICA 

ZAHul_jd P l1robd ZAHTJEVNICA 

Priikom pritiska tipkom na zahtjevnici ZAH F1(ZAH-RIM) prebacuje se ZAH u status 2 . 

Potrebno zakačiti ispis ISPul_jm 

Objekt: ZAHzg_fd__ 

Objekt Rb Naziv Procedura 

__________ ___ ______________________________ ____________________ 

ZAHzg_fd 1 ZAHTJEVNICA ZAHzg_isp_jd 

Definirati vrstu dokumenta ZAH na šifarniku za evidencioju dokumenta. 

Upistai upute za robne dokumente vdr_p_jd UVJETI ZA ROBNE DOKUMENTE . 

Upute za evudentiranje doklumenata protup_ff 

S štovanjem 


Poštovani, 

1. Upute Za Prelazak Statusa (stu_ja) - NIJE POTREBNO 

Na dokumentu ima funkcijska tipka (mislim da je F1 - formiraj RIM) tada modul ovisno o tome je li u RIM - 

izdatnici, sva zahtjevana količina, automatski prebacuje u status 2 ili 4, isto to vrijedi za NAR koji prebacuje ZAH 

u status 3 - naručeni artikli! 

2. Uvjeti za robne dokumente (vdr_p_jd) 

rsta dokumenta ZAH ZAHTJEVNICA 

Status 1 

Vrsta protokola Q NARUD¦BA PRIMLJENA (ULAZNA) 

Vrsta prodaje R 

Ulaz/Izlaz N 

Knji§enje (m,n) N ( da li se pri knji§enju mijenja predznak D/N ) 

AMBALA¦A 

Aut.stavka N (Da li sa pri unosu stavke robe automatski generira stavka amb.) 

Vrsta izl.dok. ___ 

Tip analitike _ 

Tip orgj _ 

Status izl.dok. _ 

Promjena stanja _ 

3. Uvjeti za dokumente protup_ff VEĆ DEFINIRANI 

S štovanjem 



0









Poštovani, 

adaptivno, korektivno ili perfektno, to nije moja obaveza da presuđujem, već nadležnih osoba, meni nadređenih. 

S štovanjem 


Poštovanje, 

Zahtjevom se traži 

- izmjena isporučene funkcionalnosti vezano za izmjenu datuma do u asortimanima u statusu 1 

- intervencija na produkcijskoj okolini u cilju pokretanja isporučenog rješenja koje je uspješno testirano na test 

okolini 

Oba zahvata su adaptivnog karaktera, pa stoga je i cijeli zahtjev adaptivni. 

Ukoliko smatrate da neke zahvata u okviru ovog zahtjeva spadaju u drugačiju vrstu održavanja, molimo pošaljite 

drugi zahtjev s naznakom o kojim se aktivnostima radi, a koje ne bi spadale u adaptivno održavanje. 




Poštovana, 

sve što mi je palo napamet poslao sam kroz obrade. Neka odrade te dvije zahtjevnice, izgeneriraju izdatnicu,. 

Kroz rad će isplivati svi problemi. Zato se to i radi na ova tri PU. 

S štovanjem 


Poštovani, 

Na objektu obj_fm potrebno je unijeti objekt RIM27 tip H da bi se omogučio prijelaz statusa dokumenta RIM iz 

statusa 2 u status 7. 


S štovanjem 



0









Poštovana, 

ponavljam obradu od jučer, po vašem zadnjem zahtjevu. 

Kroz objekt obj_fm potrebno je unijeti sljedeće objekte : 


Poštovana 

Upis dokumenta u mila bazu je riješen preko upute za prelazak statusa (objekt stu_ja). Potrebno je upisati slog 

za RIM dokument, prijelaz statusa iz 1 u 7, tip P, a kao modul upisati rim_mips_jd. 

S štovanjem 


Poštovani! 

Molim Vas informaciju/pomoć za slijedeći slučaj: 

PU je naručio neke artikle koji su u povratu (PU ne bi smio imati mogućnost naručivanja artikala koji su u 

povratu,a ima tu mogućnost) i sada bi trebali stornirati izdatnicu (35358-U13-02848). Da li je možemo stornirati? 

Da li će nešto završiti na zahtjevnici, ovisi o koeficijentu obrtaja koji korisnik pridružuje artiklu. 

Na zahtjevnici nebi smijeli biti artikli koji su u povratu. 

a) Mislim da trebate MIPS-u definirati zahtjev, jer on generira zahtjevnicu. 

(koje povrate mora uzimati u obzir, samo današnje ili za neki vremenski period unazad. Osim povrata koje 

dokumente još netreba uzimati u obzir. 

B) Mislim da je to standarna funkcija storno dokumenta, nevidim razloga da se ne koristi! 

S štovanjem 

ZAH1 G l1robd EVIDENTRIRANA ZAHTJEVICA 


ZAH2 G l1robd NIJE U CIJELOSTI ISPORU¬ENA 


ZAH3 G l1robd NIJE U CIJELOSTI ISPORU¬ENA - 


ZAH4 G l1robd ISPORU¬ENA SVA ZAHTJEVANA KOLI 

ZAH5 G l1robd ZAKLJU¬ENA ZAHTJEVNICA 

ZAHul_jd P l1robd ZAHTJEVNICA 

Priikom pritiska tipkom na zahtjevnici ZAH F1(ZAH-RIM) prebacuje se ZAH u status 2 . 

Potrebno zakačiti ispis ISPul_jm 

S štovanjem 



0









Poštovani, 


Molim Vas da prebacite dokument RIM 35358-U13-02466 u mips_laus tablicu zahtjev_prijenos_mips. Dokument 

je u statusu 7. 

Upisan je slog za RIM dokument, prijelaz statusa iz 1 u 7, tip P, a kao modul upisati rim_mips_jd. 

Riješeno je intervencijom na produkcijskoj bazi : 

Dokument RIM 35358-U13-02466 prebačen u mips_laus tablicu zahtjev_prijenos_mips. 

Budući da nemamo otvorene radne zadatke po ovom zahtjevu molimo pošaljite suglasnost za zatvaranje 

zahtjeva - Riješen . 


Poštovana, 

poslali ste nam netočne podatke. Asortiman broj 000006 vrijedi od 12/02/2013 (a ne od 01/02/2013), pa prema 

tome nije mogao ni upisati 

ništa u asortiman broj 000005 koji vrijedi od 01/02/2013 do 10/02/2013, a asortiman broj 000005 nije ništa 

mogao upisati u asortiman broj 00001 koji vrijedi od 22/01/2013 do 29/01/2013. 

S štovanjem 


Umanjenje angažmana po ovom zahtjevu za 3h koja se odnose na izmjenu tretmana datuma_od u asortimanu, 

poslan 18.1.2013, a temeljem razgovora na sastanku 19.2. i korespodencije s Anotnio Čubrić i Renatom Basrek: 

Umanjenje angažmana po ovom zahtjevu za 3h, temeljem razgovora na sastanku 19.2. i korespodencije s 

Anotnio Čubrićem: U nastavku: 

Poštovanje Antonio, 

Hvala na Vašem odgovoru. Sporna stavka Z: 40745 R:53594/1 odnosi se na zahtjev za izmjenom tretmana 

datuma_od u asortimanu, poslan 18.1.2013 

„2. Molim ispravak da se prilikom unosa asortimana u status 1 podaci mogu mijenjati (uključujući i 

datum_od), jer trenutno nije moguća izmjena datuma_od“ 

U zapisniku od 27.11. koji navodite, točka 1 se odnosi na tretman datuma do u asortimanu. 

„1. Na objektu Asortiman na polju datumskog raspona na kućici „DO“ kontrolirati unos datuma, unos 

postaviti kao imperativ, odbijati spremanje bez zadovoljenog unosa“ 

Ta funkcionalnost je isporučena 5.12.2012 

Stoga stojim da se radi o novo zahtjevu koji nije bio definran u radnim sastancima. 

No da ne duljimo i nepotrebno kompliciramo daljnje aktivnosti na ovu temu, jer o potrošenih 3h stvarnog 

angažmana raspravljamo skoro isto toliko vremena, predlažem da za ta 3h umanjim angažman na našim 

aktivnostima po zahtjevi 13053. 

Napravit ću korekciju u specifikaciji sa umanjenjem ta 3h, ao i sa umanjenjem ostalih zeleno označenih stavi na 

specifikaciji, pa kolegama u HP Sektor IT poslati konačnu specifikaciju. 



........................................................... 


pomoćnik direktora 

E: ljubo.nikolic@laus.cc 

T: +385 20 352 802 



0







M: +385 91 -završen, 22 55 002 Isporučen - Korisnik potvrdio ispravnost 

S: ljubo.nikolic.laus.cc 

Vukovarska 14, 20000 Dubrovnik 

tel: +385 20 352-800, fax: +385 20 352-822 

www.laus.cc 

From: Antonio Čubrić [mailto:antonio.cubric@posta.hr] 

Sent: Friday, February 22, 2013 8:01 AM 

To: Ljubo Nikolic 

Cc: Renata Basrek; Ljiljana Šegović Pivac 

Subject: RE: Dorade na projektu eZahtjevnica nakon isporuke na test okolinu 

Poštovani gosp. Nikolić, 

Nastavno na radni sastanak 19.2.'13, zaključke izvedene iz istog prenosim stavove nad kojima smo se 

obostrano usuglasili, dakle svi elementi osnovnog zahtjeva, materijali i zaključci sa radnih sastanaka koji su dio 

službenih promemorija te elementi koji se prema logici stvari nadovezuju na prethodno neće biti osnovom za 

dodatno fakturiranje. 

U svezi s tim u prilogu gore po osnovi dodatnih angažmana na temu projekta e-zahtjevnica imamo stavku 

pod evidencijom Z: 40745 R:53594/1 (crveno) koja je predmet terećenja, a za koju držimo da nije osnovana iz 

razloga što je korekcija dio sadržaja službene promemorije od 27.studenog.2012, točka 1 (vidite prilog). Ostale 

stavke (zeleno i bijelo) nisam konzultirao jer nisu dio materijala koji ste klasificirali kao angažmane vezane za 

perfektivni rad na temu e-zahtjevnice. 

Za dodatna pitanja stojim na dispoziciji. 

Sa osobitim štovanjem, 

Antonio Čubrić 

Voditelj ureda za upravljanje mrežom 


Jurišićeva 13, 10002 Zagreb 

T. +385 (1) 303 8313 

F. +385 (1) 

M.+385 (98) 476 234 

VPN. 8118 

E-mail: antonio.cubric@posta.hr 

www.posta.hr 

From: Ljubo Nikolic [mailto:ljubo.nikolic@laus.cc] 

Sent: Thursday, February 21, 2013 2:36 PM 

To: Antonio Čubrić; Renata Basrek 

Subject: Dorade na projektu eZahtjevnica nakon isporuke na test okolinu 

Poštovanje gosp. Čubrić, Renata 

Slijedom dogovora sa sastanka u utorak 19.2, u privitku Vam dostavljam specifikaciju angažmana koje smo 

proslijedili i kolegama u HP Sektor Informatike, a koji se odnosi na adaptivno održavanje. 

Crveno označeni retci predstavljaju zahtjev i utrošeni angažman za doradom za koju smatramo da nije bila 

dijelom inicijalnog projektnog opsega. 

Zeleno označene stavke predstavljaju našu korekciju nakon primjedbi kolega iz HP Sektora IT i s kojims se 

slažemo. 



0







Ostale stavke -završen, se odnose Isporučen na angažman - Korisnik potvrdio u zaprimanju, ispravnost analizi i obradi pitanja koja se odnose na primjenu 

isporučenog rješenja na produkcijsku okolinu. 

Za sva Vaša pitanja stojim na raspolaganju. 



-------------------------------------------------------------------------------mail 

Renate Basrek od 19.2. 

Ljubo, 

Kako danas moramo poslati račun na plaćanje moramo završiti priču s rekapitulacijom koja ide uz taj račun. 

Danas je A.Čubrić poslao primjedbu na dodatno potrošenih 3h, a do sada nije bilo odgovora, pa molim da 

nastavno na tu primjedbu umanjiš broj adaptivnih sati i dostaviš konačnu rekapitulaciju. 

Sve dalje zahtjeve vezano uz tu tematiku vodit će se pod zasebnim brojevima. 

Lp, 

Renata Basrek 



Sektor IT 


Umanjenje utrošenih sati za 4,5h po obradama Z: 40745 R:53615/1, Z: 40745 R:53631/1, Z: 40745 R:53747/1, 

jer iz obrada nije razvidno zašto se radila isporuka, pa ne trebaju ući u adaptivno održavanje. 


Poštovani, 

Zahtjev zatvarmo uz vašu suglasnost 


Poštovani, 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Višnja 


13052 

Riješen 


18.01.2013 12:51 

Upisao: 

Božo Mišeta 

Područje: 

LKROP 


18.01.2013 

Potrebno je poslati nove vrijednosti slijedećih parametara plaća: 

PROSP,MINZO iMAXMO prema važećim odredbama zakona u 2013. 



Nakon što prođu svi obračuni plaće za 2012. godinu potrebno izmijeniti parametre MINZO i MAXMO sa novim 

vrijednostima koje važe za 2013. godinu:: 

MINZO 2753.45 

MAXMO 47202.00 

a upisati novi slog parametra PROSP sa ključem 2013 

5464.00 

obavezna je . a ne , 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13051 



18.01.2013 10:04 

Upisao: 

Božo Mišeta 

Područje: 

WINTRAN 


22.01.2013 


U prilogu Vam dostavljam dokument kom_pu šifre 321280 kao i karticu DEPO-a 35358 za navedenu šifru 

koja mi se odnosi na komitenta MOZAIK. 

Naime, kako mi završno stanje za komitenta nije odgovaralo za 3 šifre (321280, 321282 i 321283) 

istraživanjem sam ustanovila da je problem u dokumentu 35358-U12-55467 napravljen u DEPO-u Zagreb 

05.12.2012. s pogrešnim datumom dokumenta tj. 26.11.2012. 

Navedeni dokument nije uvršten u OKR pa samim tim stanje na kartici DEPO-a (157 kom) ne odgovara 

stanju zaliha koje se nama iskazuje u stanju DEPO-a kod OKR (155 kom). 

Napominjem da se u navedenom dokumentu nalaze sve tri navedene šifre kod kojih imam razlike u ZS. 

Molim za intervenciju. 



0









Poštovani, 

ovo je tekst obrade (dolje u nastavku) koji smo vam poslali jučer po vašoj dopuni zahtjeva 40672 HP 13041 u 

kojem se poslali identičan zahtjev ovome a koji se odnosi na isti obračun i na iste artikle. Koje od riješenja želite 

da primjenimo (navedeno pod a i b)? Naglašavam da i dalje nismo dobili tražene podatke po izvornom zahtjevu 

40672 HP 13041! 

RIM 35358-U12-55467 sa artiklima 321280,321282 i 321283 nije prenesen iz skladišnih tablica u HP tablice iz 

kojih se izvlači. 

Nije prenesen jer navedeni dokumenat je proknjižen 05.12.2012 a tog datuma je rađen i prijenos u HP tablice. 

Ovo nije odgovor na upit koji smo postavili, ovo je novi zahtjev a za njega molim dostavite nam odluku: 

a) želite li sami pomaknuti kontrolni datum i izvršiti prenos podataka 

b) želite da mi izvršimo prenos podataka u tablicu HP, nakon čega treba ponoviti obračun za navedene artikle 

Ovaj propust nema veze sa razlikama u knjiženju koje se javljaju zbog netočno odrađenih nivelacija. Molim 

odgovor na upit koji smo postavili u prošloj obradi. 

U očekivanju vašeg odgovora, 

S štovanjem 


Poštovana, 

da ovo smo i zaveli kao novi zahtjev, Što ćemo sa identičnim zahtjevom koji ste poslali kao nadopunu zahtjeva 

40672 HP13041? 

Pozdrav 


poštovani, 




0











Klijent: 





Hitnost: 

Vrlo hitno 


Glorija 


13050 



18.01.2013 09:50 

Upisao: 

Božo Mišeta 

Područje: 

LBASE 


20.01.2013 


Kod čitanja naziva partnera nastaje problem … šifra je ispravna, ali naziv ne ispisuje ispravno. Potrebna 

provjera što je kod ovog partnera problem. 


Ispravljena je greška kod čitanja naziva partnera u poruci za partnere sa istim OIB-om. 

Preuzimanje novog LAUS BASE liba u četvrtak 21.02.2013. 


Poštovani, 





0











Klijent: 





Hitnost: 

Vrlo hitno 


Ivan 


13049 



17.01.2013 15:13 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


18.01.2013 

Na objekzu za ručni unos faktura kod unosa odobrenja javlja se greška sa slike. 



Greška se pojavila zbog prevelikog iznosa u polju količina. 

Polje količina je definirano veličine 10 znamenaka (uključujući i decimalni zarez) pa kada je količina veća od toga 

javi se ova greška. 

Sada sam stavio da je polje količina veličine 14 znamenki. 

Novi WIN FAUS lib. je na internetu. 



0











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13044 



17.01.2013 08:59 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


16.01.2013 


Računi i predračuni neispravno odsjedaju u nadzorne knjige. Odsjedaju u NADZORNA KNJIGA PROMETA 

USLUGA – IZVOZ, a trebaju u NADZORNA KNJIGA PROMETA ROBA – IZVOZ. 

Ovako treba izgledati kada ispravno odsjedne i sve je ok (ovo je sada sev rađeno ručno tj. ono napravljeno 

iz Laus-a izbrisano i ispravljeno upisom ispravnim). 

vidi sliku prilog 

Neispravno odsjedanje iz navedenog objekta. 

Također prikaz godine je neispravan godina je 1/20 ???, umjesto 2013. 


Poštovani, 

Na objektu rucfil.jas ispravljeno je punjenje nadzorne knjige prilikom promjene statusa iz 2 u 3 : 

ispravak 2/20 --> iz protokola, u primjeru iz zahtjeva 2013 

ispravi vnk I--> Z 


Preuzmite WIN FAUS lib će biti dostupan sutra ujutro. 

Molimo povratne informacije nakon testiranja/ suglasnost za zatvaranje zahtjeva - Riješen 

NAPOMENA: za račune filatelije likvidirane od danas do stavljanja na produkciju nove verzije winFaus 

pogrešne slogove ispravlja HP (Glorija) . 

( prepoznatljivi su po vnk.godina= 2/20 



80











Klijent: 





Hitnost: 

Vrlo hitno 


Ivan 


13047 



17.01.2013 07:24 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


20.01.2013 


Na objektu rucfak_fas u polju Faktura/Predračun i Odobrenje treba dodati i RAČUN ZA PRIMLJENI 

PREDUJAM. 

Vrsta dokumenta za Račun za primljeni predujam je RAV, a protokol H. 

Ostali elementi i izgled Računa za primljeni predujam je isti kao i Faktura. 

Račun za primljeni predujam prolazi kroz sve statuse. 

Knjiženje će raditi računovodstvo – ručno kroz konta. Neće biti automatskog knjiženja. 



80









U zahtjevu je traženo da se omogući uno Računa za primljeni predujam s vrstom dokumenta RAV i vrste 

protokola H. 

Na objektu za ručni unos faktura (rucfak_fas) postoji kontrola dali je faktura račun za primljeni predujam (u 

ugovoru vrsta usluge = POS, način plaćanja = AVANS, part_pdv = 'D', iz stavki ugovora usluga = 9121 ). 

Ako su ti uvijeti zadovoljeni tada nastaje račun s vrstom dokumenta RUF i vrste protokola H. 

Treba li ta kontrola ostat ili se ta kontrola uklanja? 


Poštovani, 

Na objektu rucfak_fas je omogućen unos računa za primljeni predujam. 

Vrsta dokumenta za Račun za primljeni predujam je RAV, a protokol H. 


Preuzmite novi WIN FAUS će biti dostupan sutra ujutro. 

Molimo povratne informacije nakon testiranja/suglasnost za zatvaranje zahtjeva- Riješen 


Poštovani, 

Napravljene su izmjene kod evidencije računa za primljeni predujam. 

Datum dospijećaje isti kao i datum DVO-a. 

Nadodano je novo polje "Plaćeno" u koje ručno upisiva datum kad je izvršena uplata. 

Nadodana je i napomenai "Plaćeno i datum" 


Instalacija: sutra ujutro 1.2.2013 će biti dostupan novi WIN FAUS lib. 



Poštovani, 

Na objektima automatskih knjiženja faktura izutete su fakture sa vrstom protokola H (računi za primljeni 

predujam). 


na internetu je od jutros 1.2.2013 dostupan novi WIN FAUS lib. 

Razlog : 

Knjiženje će raditi računovodstvo – ručno kroz konta. Neće biti automatskog knjiženja. 

Molimo povratne informacij/suglasnost za zatvaranje zahtjeva - Riješen 


Poštovani, 

Napravljene su sve tražene izmjene kod generiranja računa za plaćeni predujam. 


Instalacija: već je sve isporučeno. 



Poštovani, 





80











Klijent: 



Pitanje 


Hitnost: 

Vrlo hitno 


Glorija 


13046 



16.01.2013 14:28 

Upisao: 

Božo Mišeta 

Područje: 

LROBD 


16.01.2013 


Skladište kataloške je provelo inventuru za 2012. Došlo je do povrata robe kataloške od kupca koje je 

vezano za otpremnicu 2012. Na koji način napraviti navedeni povrat. Problem se može javiti i kod povrata 

iz PU. 


Poštovani, 

1) provedite dokument sa datumom kada ste stvarno fizički zaprilili robu, a taj datum mora biti mlađi od inventure 

(naša preporuka) 

2) možete tražiti da se ukine ova kontrola (tada smisao i svrha inventure postaje besmislen, ne preporučujem 

vam ovaj zahtjev) 

Pojašnjenje: ova kontrola vrijedi za sve dokumente i primke i povrate dobavljaču, i izdatnice i povratnice, itd ...., 

S štovanjem 



80











Klijent: 





Hitnost: 



Višnja 


13043 

Riješen 


16.01.2013 13:57 

Upisao: 

Božo Mišeta 

Područje: 

LKROP 


31.01.2013 


25.02.2013 

Kroz dis_ban_fk DISKETE ZA BANKE potrebno je za VOLKSBANK D.D. ZAGREB izraditi disketu 

za isplatu neto plaća prema uputi u prilogu. 

Šifra banke je: 

0364 VOLKSBANK D.D.-NETO PLAĆA 


Poštovani, 

Naziv i struktura datoteke za Volks banku su prilagođeni uputama banke iz priloga zahtjeva. 

krop i base libovi od 08.02.2013 

S štovanjem 


Ispravljena je greška u formatu datoteke.Krop lib je na internetu. 



80











Klijent: 





Hitnost: 

Vrlo hitno 


Glorija 


13045 



16.01.2013 13:33 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


16.01.2013 


Kod punjenja datumskim polja nakon izlaska iz Polja otpremnica Datum dokumenta i Datum PDV-a se 

napunjene sa tekućim datumom, a Datum dospijeća se povlači sa otpremnice. Potrebno je da se sva polja 

povlače sa Otpremnice. 


Poštovani, 

Dali da se navedena uzmjena napravi samo kod otpremnice ili treba da se ti datumi povlače i ako se radi o 

narudžbenici? 

S štovanjem 


Napravljena je izmjena na objektu rucfil.jas. 

Nakon izlaska iz polja otpremnica polja Datum dokumenta i Datum PDV-a se sada povlače iz otpremnice. 

Novi WIN FAUS lib će biti dostupan sutra ujutro. 



80











Klijent: 





Hitnost: 

Vrlo hitno 


Višnja 


13042 

Riješen 


16.01.2013 10:58 

Upisao: 

Božo Mišeta 

Područje: 

LKEVP 


17.01.2013 


Kroz odog_jke ODOBRENJA - GENERIRANJE IZ PLANA GO za grupu KAMUUP za 01/2012 nije 

moguće izvršiti generiranje odobrenja jer se javlja poruka: vidi prilog 


Poštovani, 

ispravljena je greška u prijenosu odobrenja iz plana. Naime dodali smo ranije zbog zahtjeva (orig. br. 11735) 

dodatnu kontrolu da se ne može prenijeti 2. dio plana ako se nije ranijim prijenosima za radnika prenio 1. dio 

plana. Međutim imali smo grešku kod ispitivanja godine plana. Radnik 09145 u 2013/01 ima plan iz 2012. 

Verzija će biti na internetu 17/01/2013. 




80











Klijent: 





Hitnost: 

Vrlo hitno 


Glorija 


13041 



16.01.2013 09:34 

Upisao: 

Božo Mišeta 

Područje: 

LROBD 


16.01.2013 


Jednako problem depoa 35348 (riješeni zahtjev 13029) ostao je problem na depoima 35352 i 35358. 

DEPO 35352 ima isti problem sa nivelacijom kao i depo 35348. 

DEPO 35358: problem je nivelacija i izlaz robe iz skladišta. 



80









Glorija, 

molim te neka nam jave brojeve nivelacija i šifre artikala na kojima je poremečeno stanje, kako bismo po hitnom 

postupku riješili zahtjev! 

Poz B 


Poštovani, 

RIM 35358-U12-55467 sa artiklima 321280,321282 i 321283 nije prenesen iz skladišnih tablica u HP tablice iz 

kojih se izvlači. 

Nije prenesen jer navedeni dokumenat je proknjižen 05.12.2012 a tog datuma je rađen i prijenos u HP tablice. 

Ovo nije odgovor na upit koji smo postavili, ovo je novi zahtjev a za njega molim dostavite nam odluku: 

a) želite li sami pomaknuti kontrolni datum i izvršiti prenos podataka 

b) želite da mi izvršimo prenos podataka u tablicu HP, nakon čega treba ponoviti obračun za navedene artikle 

Ovaj propust nema veze sa razlikama u knjiženju koje se javljaju zbog netočno odrađenih nivelacija. Molim 

odgovor na upit koji smo postavili u prošloj obradi. 

S štovanjem 


Poštovani, 

Nivelacija na skladištu 35352 dokument RC3 35352 - R13 -00001 nosi datum 31/12/2012 a protokol sadržava da 

je i 2013 godine te je kao takva neispravno ažuriran obračun obrshp. Sada je ispravljen obračun za nivelacije na 

skladištima 35352 i 35358 te je potrebno proknjižiti RIM dokumente koji nisu proknjiženi u pripremi za knjiženje 

za skladište 35358 u 12 mjesecu 2012 godine. 

Ukoliko se bude i dalje javljala razlika na navedenim listama, provjerite zašto ima dokumenata iz 2012 koji još 

nisu proknjiženi! 

Potrebno je preuzeti laus libove rob0,rob1,rob2,rob3,rob 4 i tran lib koji će biti na internetu 19.01.2013. 

S štovanjem 



80











Klijent: 





Hitnost: 

Vrlo hitno 


Glorija 


13040 



15.01.2013 15:33 

Upisao: 

Božo Mišeta 

Područje: 

LFINK 


15.01.2013 


Prilikom automatskog knjiženja žiro računa za dan 14.01.2013.godine, žiro HR16239000111000186, ostalo 

je neproknjiženo 763 stavke, 90% odnosi se na uplate kupaca. Molimo za provjeru neknjiženih stavaka tj. 

koji je razlog da se stavke nisu automatski proknjižile. Ovdje dio stavaka za koji ne postoji IBAN je jasan, ali 

gdje je upisan račun i postoji IBAN nije jasno. Predpostavka je da je račun izdan na jednu šifru, na nju 

proknjižen. Kasnije otvorena nova šifra I preknjiženo na novu. Izvod dolazi na koju šifru tj. treba se knjižiti 

na onu nositelja, a ne na koju je evidentiran račun. 

select * from izvod_ziro 

where dat_izv='14.01.2013' 

and rnpri='HR1623900011100018674' 

and status='O'; 



80









Poštovani, 

Prilikom knjiženja izvoda žira te traženja već proknjiženih stavaka izmjenjeno je da se za analitiku iz evidencije 

traži NSC te za tu šifru traže već proknjižene stavke. 


Preuzmite novi LAUS BASE i LAUS FINK lib koji su dostupni od sutra ujutru na internetu . 

Molimo povratne informacije nakon testiranja/suglasnost za zatvaranje zahtjeva - riješeno 

Opis problema : 

Prilikom automatskog knjiženja žiro računa za dan 14.01.2013.godine, žiro HR16239000111000186, ostalo je 

neproknjiženo 763 stavke, 90% odnosi se na uplate kupaca. Molimo za provjeru neknjiženih stavaka tj. koji je 

razlog da se stavke nisu automatski proknjižile. Ovdje dio stavaka za koji ne postoji IBAN je jasan, ali gdje je 

upisan račun i postoji IBAN nije jasno. Predpostavka je da je račun izdan na jednu šifru, na nju proknjižen. 

Kasnije otvorena nova šifra I preknjiženo na novu. Izvod dolazi na koju šifru tj. treba se knjižiti na onu nositelja, a 

ne na koju je evidentiran račun. 

----------------------------- 

Povezano sa :KZ - broj 40371/5 - HP 12795 te vrijedi isto : 

IZNIMKE : kod knjiženja izvoda ZR 

// Dodano prema zahtjevu 27476 čitanje analitike iz aktivnog ugovora vezanog za fakturu kad je : 

pozbo(3,4) == '2259' / odnosno 2257 

placanje_tip='A' / odnosno F 

analitika in (select part from part where oib=':xoib' and aktivnost='D' and isaco='D') .... 

HP treba poslat zahtjev s opisom kako treba promijeniti iznimke (ako je potrebno) obzirom da UGK ne smije 

biti na šifri koja je NSC 


Poštovani , 

Nakon promjene 16.2.1013 : 

Prilikom knjiženja izvoda žira te traženja već proknjiženih stavaka izmjenjeno je da se za analitiku iz evidencije 

traži NSC 

te za tu šifru NSC traže već proknjižene stavke. 

rješen je problem : Prilikom automatskog knjiženja žiro računa ostalo je neproknjiženo dosta uplata : 90% se 

odnosi se na uplate kupaca. 

Provjerili smo neproknjižene stavke i nakon promjena. Razlog da se stavke nisu automatski proknjižile : 

- za dio stavaka ne postoji IBAN 

R: popunite nedostajuće podatke 

- za dio stavaka je upisan račun i postoji IBAN ali je račun knjižen i otvoren (jail='' ) na više nivoa (orgj) na 

kontu 120* (preknjižavanje !?) 

R: zatvorite stavke 

- za dio stavki račun je proknjižen i otvoren (jail='') na šifri koja SAD nije NSC a nekad jest ili nije bila . Izvod 

dolazi se knjižiti na šifru nositelja, a ne partnera na kojeg je evidentiran račun ili nekad u prošlosti knjižen . Kod 

automatskog knjiženja izvoda program traži otvorene stavke za račun sa analitikom NSC kako bi se odredilo na 

koji konto i nivo treba knjižiti uplatu . Ako ne postoji otvorena stavka za račun knjiženja na NSC nego na nekoj 

drugoj šifri partnera, neće se automatski proknjižiti uplata . 

R : zatvorite stavke koje nisu na NSC ili preknjižitre po potrebi na NSC 




80











Klijent: 





Hitnost: 

Vrlo hitno 


Glorija 


13037 



15.01.2013 14:26 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


20.01.2013 


21.03.2013 

1.Automatsko knjiženje razduženja trgovačke robe na objektu: 

knjrtr_fas Razduženje trgovačke robe u PU proširiti za uslugu 44131 Prodaja uređaja za evotv 

Kod knjiženja razduženja za prodaju usluge 44131 

1.Gotovina i virman, 

Za vrstu dokumenta GOT, GR1 i VR1 knjiženje provesti na slijedeći način: 

MPV, maloprodajna vrijednost, konto 663800, potražno 

PDV, porez na dodanu vrijednost, konto 664380, dugovno 

RUC, razlika u cijeni, marža, konto 668380, dugovno 

NC, nabavna vrijednost, konto 710800, dugovno 

2.Kredit 

Za vrstu dokumenta FAP, ODO knjiženje provesti na slijedeći način: 





2.Na objektu rekuslN_ fas Rekapitulacija po uslugama, Pregled po artiklima proširiti za uslugu 44131 

Prodaja uređaja za evotv. 

3.Na objektu rekuslN_fas Rekapitulacija po uslugama, Pregled po artiklima treba se vidjeti i promet po 

skupnim fakturama FAS. 

4.Na objektu knjrtr_fas Razduženje trgovačke robe u PU, kod razduženja na Kredit u razduženje uzeti u 

obzir i skupne fakture FAS, po istim pravilima po kojima se razdužuju usluge 44111,44112,44113.(konta 

663000-maloprodajna vrijednost, potražno,664300 – PDV,dugovno,668300 – RUC,dugovno ,710000nabavna 

vrijednost,dugovno). 



80









Poštovani , 

Knjiženja Gotovine i virmana prošireno je za uslugu 44131 Prodaja uređaja za evotv. 

Kod knjiženja na kredit u obzir su uzete i skupne fakture FAS. 

Na objektu rekuslN_fas Rekapitulacija po uslugama . Pregled po artiklima, sada se prikazuje promet (sve 

usluge) sa faktura vrste dokumenta 

FAP,ODO,OBN,FAS. 




Poštovani, 

Napravljene su izmjene na objektu Automatsko knjiženje razduženja trgovačke robe (knjrtr_fas) 

Razduženje trgovačke robe je rošireno za uslugu 44131 Prodaja uređaja za evotv. 

Ta usluga se knjiži: 

1. Gotovina i virman, 





2. Kredit 

Za vrstu dokumenta FAP, ODO 





Instalacija: sutra 07/02/2013 će biti dostupan novi WIN FASU lib. 

S štovanjem 


Ispravljeno je knjiženje razduženja - Kredit. 

Usluga 44131 se knjiži: 

MPV - konto 663800 potražno, 

PDV - konto 664389 dugovno, 

MARZA - konto 668380 dugovno, 

NC - konto 710800 dugovno 

Instalacija: Novi WIN FAUS lib će biti dostupan sutra ujutro (04.04.2013). 



80









Poštovani , 

Riješene su sve točke zahtjeva., uključivo točka 2 i 3 . 

Na objektu rekuslN_fas Rekapitulacija po uslugama kupi: 

a) uslugu 44131 

b) promet po skupnim fakturama FAS . 


Instalacija: ne treba ništa - ranije isporučeno 



Poštovani, 





80











Klijent: 





Hitnost: 

Vrlo hitno 


Višnja 


13039 



15.01.2013 14:22 

Upisao: 

Božo Mišeta 

Područje: 

EPNAB 


16.01.2013 


U privitku dostavljamo popis ugovora za koje, nakon što su iz ePN poslani u Laus, Laus broj nije 'vraćen' u 

ePN. 

Problem je zapažen, kada tehnički nositelj nije mogao za ugovor HP-10/2-5166/12 unijeti račun u 

eObraduRačuna. 

Molim za žurno rješavanje navedenog problema, radi potrebe slanja računa na plaćanje. 



80









Poštovsni, 

Molimo vas na database serveru izvedite na unix prompt-u : 

dbschema -f ime_procedure -d ime_baze > rezultat 

za slijedeće : 

dbschema -f protokol_dokit_ins -d laus@lausprod > proti.sql 

protokol_dokit_del --> protd.sql 

protokol_dokit_upd --> protu.sql 

te nam pošaljite rezultata kako bi usporedili procedure po kojima rade trigger-i na protokol tablici . 

triggeri kod nas i u HP različiti na protokol tablici : 

kod nas : 

create trigger trad_prot_ins insert on protokol referencing new as new for each row 

(execute procedure protokol_dokit_ins(new.protokol, new.vprotokol,new.vdok ,new.analitika, new.boriginal, 

new.status ,new.uradio ,new.datum)); 

U HP : 

create trigger "l1fink".trad_prot_ins insert on "l1base".protokol referencing new as new for each row 

(execute procedure "l1fink".protokol_dokit_ins 

(new.protokol ,new.vprotokol ,new.vdok ,new.analitika ,new.boriginal ,new.status ,new.uradio )); 

--- nema new.datum 

Za prvi ugovor nama ništa ni u laus ni mips bazi u ugovor_eolog : 

ugovor datum sklapanja laus broj 

HP-10/2-5166/12 21.12.2012. 01300-R12-00071 -- u međuvremenu je neko upisao . 

Kao neupisane u ugovor_eolog dobijem i ove ugovore koji nisu u zahtjevu navedni : 

HP-10/1-024434/12 40002-R13-00003 

HP-10/1-024576/13 40002-R12-00064 

HP-10/1-024653/12 40013-R12-00059 

HP-10/1-025253/12 01300-R12-00072 

HP-10/1-025340/12 10016-R13-00002 

HP-10/1-025503/12 41039-R12-00357 

HP-10/1-025579/12 40002-R13-00004 

HP-10/1-025644/12 01100-R12-00161 

HP-10/1-025694/12 01100-R12-00162 

HP-10/1-5243-8/12 01100-R12-00163 

HP-10/2-023777/12 40011-R13-00001 

HP-10/2-024239/12 30001-R13-00003 

HP-10/2-024337/12 20010-R12-00298 

HP-10/2-024573/12 01400-R12-00128 

HP-10/2-025082/12 01500-R12-00060 

HP-10/2-025304/12 01400-R12-00132 

HP-10/2-025715/12 10012-R13-00001 . 

molim provjeru za njih - trebaju ili ne biti upisani u ugovor_eolog ? 

-- nisam ništa upisivala a ako treba odmah izvedite ili javite da mi izvedemo sql za upis nedostajućih ugovora u 

ugovor_eolog : 

Status : čekamo od HP-a procedure dobivene sa dbschema te rezultat provjere za ugovre ovdje navedene 



80









Poštovani, 

Upisano je 42 ugovora u ugovor_eolog (z13039_ubaci.sql ) sa : 

'2013-01-16 11:30:00' =datum_upisa, 

id od 10522 do 10563 

Među njima su i 3 ugovora sa država !=191 : 

protokol status vdok analitika drzava aktivnost 

01100R1200061 2 UGD 649299 250 D 

01100R1200063 2 UGD 649312 203 D 

01200R1200003 2 UGD 632082 208 D 

Ugovor iz ePN koji je sa sataus











Klijent: 





Hitnost: 

Vrlo hitno 


Višnja 


13038 

Riješen 


15.01.2013 14:17 

Upisao: 

Božo Mišeta 

Područje: 

EPNAB 


22.01.2013 


Potrebno je u ePN za spis „HP-10/2-024651/12“ u Registru ugovora bagatelne nabave izvršiti izmjenu: 

- broj ugovora „HP-10/2-0246551/12“, u broj ugovora „HP-10/2-024651/12“ 


Poštovani, 

Potrebno je omogućiti pristup na produkciju Vjeranu Livaiću za izvršenje zahtjeva 13038. 

Molimo pošaljite obavijest kad pristup bude omogućen 


Isporučeno na produkciju 



80











Klijent: 





Hitnost: 

Vrlo hitno 


Višnja 


13036 



15.01.2013 11:32 

Upisao: 

Božo Mišeta 

Područje: 

LZETT 


16.01.2013 


Kroz ugid_ul_jzt ID1 – OBRAZAC potrebno je proširiti broj unosa brojčanih oznaka u dijelu ‘Brojčane 

oznake koje ulaze u listu’ na način da se mogu upisati 20 brojčanih oznaka za koje izađujemo ID1 disketu: 


Kod formiranja ID-1 obrasca i XML datoteke omogućeno je zadavanje do 20 šifri brojčanih oznaka za porez na 

drugi dohodak. 

Preuzmite zett lib. 



80











Klijent: 





Hitnost: 

Vrlo hitno 


Višnja 


13035 



15.01.2013 09:28 

Upisao: 

Božo Mišeta 

Područje: 

LTRAN 


16.01.2013 

Kroz prijenosa slijedećih artikala prenijela se pogrešna tarifna grupa, 

tarifna grupa PDV, a treba P05: 

redmatstamatnaztarfbrdat_vri_dos 

5027312194KAKO CRTATI ŽIVOTINJE-START PLPDV14.1.2013 14:35 

5027312200AUTOMOBILI BOJANKE-START PLUS PDV14.1.2013 14:35 

5027321051Z IDEJE ZA UKRAŠAVANJE I DARIVPDV14.1.2013 14:35 

5027321078Z BOŽIĆNI KOLAČI S OBLIKOM ZA PDV14.1.2013 14:35 

5027321280MOZ BOŽIĆNI SNJEGOVIĆ PDV14.1.2013 14:35 



Poštovani , 

Prebacio sam te sve podatke u nas i napravio prijenos. Sve je prošlo kako treba. 


Instalacija:ne treba ništa. 



Poštovani! 




80











Klijent: 





ruckat.jas- statusi 

Hitnost: 

Vrlo hitno 


glorija 


13034 



14.01.2013 17:45 

Upisao: 

Dajana Lekić 

Područje: 

LWINFAU 


15.01.2013 


15.01.2013 

Zahtjev potrebno što hitnije riješiti, jer se računi neispravno evidentiraju na ruckat.jas 



80









Poštovani, 

Napravila provjeru svih računa u protokolu 5 i 0 nastalih preko ruckat . 

Nisam ništa mijenjala po bazi jer ne smijem dok ne kažete da može ako može obzirom da neke treba stornirati . 

u prilozima (poslano Gloriji) su rezultati analize - čeka se odgovor HP-a na rezultate 

a) ukupno-neoporezivo- porez != osnovica ima 210 računa 

z13034osn.txt : uglavnom zato što je osnovica uvećana za PDV . 

-- provjerite pa napravite : update prot_pdv set osnovica=osnovica-porez where protokol in ( u prilogu navedeni ) 

ili pošaljite suglanost da promjene napravimo mi na računima koje vi označite u prilogu 

b) Nema poreza u zaglavlju za predračun : 

protokol idinp pp 

1100411200291 0.00 55.44 

c) neoporezivo nije jednako u zaglavlju i razradi za : 

protokol vrij_p neo s 

4630001200111 467.88 32.84 3 

d) Nepravilno zapisane stavke sa stopom 0 i tiptar=1 bez tarfbr za uslugu 4412 kod 78 stavki u lm_kat_stav 

(kao crveni) 

tt tb stopdv uk pdv 

1 0.00 6469.50 0.00 

z13034tb.txt 

protokol,usluga,tiptar,matsta,vdok, posprz from lm_kat_stav 

-- ispravak moguć za stavke koje imaju upisan artikal,a za ostale ne . Potrebno pojačati kontrolu kod unosa 

stavki na ruckat. 

NAPOMENA : Nijedan nije nastao prijenosom bss-> LAUS 

Za poslane račune u zahtjevu i nadopuni : u prilogu ove obrade je pojašnjenje 


Poštovani, 




80











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13033 



14.01.2013 13:30 

Upisao: 

Božo Mišeta 

Područje: 

LROBD 


16.01.2013 


Kad se zada pregled F8 (NARpd_pr_fg) narudžbenica (JAM) sa indikatorom Plaćeno:’N’ ne dobije se niti 

jedna narudžbenica koja nije plaćena (Plaćeno:N) iako takva postoji. 

Primjer. 35358-W13-00093 – molimo ispravak. 

Narudžbenica (WIN TRAN) ima upisan indikator Plaćeno: N 


Narudžbenica NAR 35358-W13-00093 je ažurirana sa plaćeno 'N'. Dodana je kontrola prilikom prebacivanje 

dokumenta narudžbenice iz statusa 1 u status 2 da se ažurira polje plaćeno sa 'N' ako podataka nije unesen, a 

on je određen šifarnikom vrste plaćanja. 

Potrebno je preuzeti win tran lib koji je na internetu 



80











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13032 



14.01.2013 11:27 

Upisao: 

Božo Mišeta 

Područje: 

WINTRAN 


16.01.2013 


U privitku Vam dostavljamo usporednu tablicu za klasu 6341-tiskovine za razdoblje 01.01-31.12.2011-2012. 

Analizom prodaje 2012. godine utvrdili smo da se u izvješću nalaze pogrešni podaci (boldano i označeno 

crvenim). 

Primijetili smo da se neki podaci u 2012. prikazuju u dvostrukim količinama. 

Znači imamo sasvim različite podatke za tiskovine iz analize prvih 11 mjeseci koje smo poslali u Upravu 

( službeni podaci) od podataka od prodaji tiskovina za prvih 12 mjeseci koji smo ovaj mjesec vadili iz win 

lausa. 

S obzirom da nismo u mogućnosti prekontrolirati podatke na nivou godine, molimo Vas da HITNO ispravite 

dostavljene greške kao i da prekontrolirate točnost podataka za svu vrstu robe jer se radi o izvješćima koje 

koristimo kao podlogu za planiranje prihoda i zadavanje ciljeva djelatnicima. 


Ispravljeno je ispis uporedbe za dva razdoblja udr_ul.trn u stupcima prodano ,ruc,i mpc za drugo razdoblje. 




80











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13031 



14.01.2013 11:17 

Upisao: 

Božo Mišeta 

Područje: 

WINTRAN 


16.01.2013 


Prilikom generiranje obračuna komisijske robe svim korisnicima u Splitu se javlja greška-243 - zaključanost 

tablice, te im je usporen rad. 

Zadnja tri mjeseca im se ovaj problem učestalo javlja (prilikom generiranja svakog obračuna). 

Molim Vas da provjerite procedure, postavke…kako bi se problem riješio, a korisnici mogli nesmetano 

raditi. 



80









Poštovani , 

Molimo Vaš stav u vezi navedenih prijedloga rješenja . 

Problem : 

U isto vrijeme rade komis. obračun (9:34 ) i to više korisnika odjednom dok se vrti pregled prometa za 2 godine 

udr_ul.trn ( ispisano 11:41) 

pa nije neobično daje zaključana tablica iz koje oboje trebaju podatke a na što ukazuje greška : 

-243 Could not position within a table table-name. 

The database server cannot set the file position to a particular row within the file that represents a table. 

Check the accompanying ISAMerror code for more information. 

-144 ISAM error: key value locked. 

The current operation inserts a row with a certain primary key value or updates a row with a certain primary key 

value, 

but a transaction that has not yet been committed has deleted that key value from the index. 

This error occurs only when the lock mode is set to NOT WAIT. Treat it the same as error -107 (record is 

locked). 

Rješenje : 

R1. Trebali bi raditi nešto od ovog , predlažemo usporednu listu za 2 godine , iza 16:00 ili po dogovru izbjeći 

istovremeno puštanje sa OKR . 

R2 Može se staviti lock mode na WAIT x sekundi kod OKR . Ako se usporedna lista za 2 godine pusti u 

9:00 , pokrene OKR u 9:30 a x < 1800 sekundi rješenje nema smisla tj. ne pomaže . Molimo predložite x 

ukoliko je R2 opcija koju prihvaćate . 

Status : čekamo stav HP-a 



80









Poštovani, 

Obračun koji je 'pušten' 14/01/2013 u 19:20 ne postoji . 

Pod 'pušten' podrazumijevamo generiran tj. pokrenut obračun i upis podataka u bazu . 

Molimo objasnite što podrazumjevate pod 'pušten' obračun : 

- Pušten neki excel izvještaj /pregled ? 

- nešto drugo ? 

NAPOMENA: 

N1. zbog velikog broja podataka koji se trebaju učitati u excel samo učitavanje može potrajati . 

( 30x2000 = 60 000 iz baze direktno + izračun razlika i očekivanog stanja = oko 70 000 ) 

N2. U bazu se podaci upisuju nakon što se sve pročita i sredi u tem tablicama . 

Ako su vremena usklađena i generiranje pušteno u 14:10 a upisalo se sve u bazu u 14:12 dana 14/01/2013 

smatramo da je brzina generiranja obračuna zadovoljavajuća obzirom na veliki broj podataka koji se crpe iz 

tablica 

sa više milijuna slogova . 

-- zaglavlje : 

protokol 40013K1200923 

part 626377 

uradio SVEPALIN 

datum 14/01/2013 

vrijeme 14:12 

terminal RS-3ST-40ORS011 

-- stavke : 

SVEPALIN 14/01/2013 14:12 14:12 -----> stavke obračuna se upisale u bazu 

SVEPALIN 15/01/2013 07:40 07:41-----> ručne korekcije 


Poštovani, 

Na pogrešnom mjestu (na početku) se čita sistemski datum i vrijeme koji se upisuju u obračun . 

Ispravit ćemo tako da se čitaju neposredno prije upisa podataka u bazu. 

Optimikzirat ćemo čitanje/obračun prometa koji ulazi u obračun 


Poštovani, 

Ispravljeno je da se prilikom generiranja obračuna upisuje trenutno datum i vrijeme dokumenta u trenutku upisa 

samog obračuna ,a ne datum i vrijeme početka obračuna. 

Optimikzirano je čitanje/obračun prometa koji ulazi u obračun na nčin da smo postavili dodatne indexe . 


Potrebno je preuzeti winn tran lib koji će biti na internetu 22.01.2013. 

Potrebno je testirati obračun za CESU te potvrditi ispravnost obračuna /poslati suglasnost za zatvranje zahtjeva - 

Riješen 

ili poslati primjedbe . 

U svakom slučaju , molimo pošaljite nasm sistemsko vrijeme kad je pušteno generiranje obračuna te kad je 

završeno 



80









Poštovani, 

Ispravljena greška prilikom generiranja komisijskog obračuna (kom_obr.trn). 


S štovanjem 



80











Klijent: 





Hitnost: 

Vrlo hitno 


Višnja 


13030 

Riješen 


14.01.2013 07:35 

Upisao: 

Božo Mišeta 

Područje: 

LKEVP 


15.01.2013 


Kroz odl40_jke ODLUKA O RASPOREDU I TRAJANJU GO potrebno je kroz ispis odluka (odl40p_rke.txt) 

i dostavnice (odl40d_rke.txt) izvršiti izmjenu na način da se urudžbeni broj po dodatnom podatku 'UBR' , 

UPP, UPT 'čita' iz dodatnih podataka aktivne organizacijske jedinice HRVATSKE POŠTE: 

Organizacijska jedinica Aktivnost 

00000 HP-HRVATSKA POŠTA D.D. D 

11111 HP-HRVATSKA POŠTA D.D. N 

jer se sve izmjene dodatnih podataka provode po aktivnoj organizacijskoj jedinici. 


Poštovani, 

dodano je ispitivanje aktivnosti za orgj iz koje se čitaju navedeni dodatni podaci. 

Na listi odl40p_rke se čitaju UBR, UPP, UPT a na listi odl40d_rke se čita samo UBR. 

kevp.lib će biti na internetu 17/01/2013. 



Poštovani, 

na produkcijskoj bazi orgj 11111 ima tip Firma, tako da su svi daljnji sql-ovi za nju čitali tipove dodatnih 

podataka, kojih nema. 

U čitanje podataka za tip Firma je također dodan uvjet za aktivnost, jer može biti samo jedna, a to je 00000. 

Kevp će biti na internetu 22/01/2013. 




80











Klijent: 





kontrolni pregled financijskih 

izvještaja: konta i upute za 

generiranj 

Hitnost: 

Vrlo hitno 






11.01.2013 14:04 

Upisao: 


Područje: 

AFINK 


14.01.2013 


na uputama za generiranje izvještaja za izvještaj s šifrom "BILANCA", primjerice u retku 24, stupac 6, kada 

se klikne na upute po kontima otvori se prazan dijaloški okvir - nema kontnog plana. To se događa za sve 

ćelije koje se odnose na godine ranije od 2013! nešto se pošemerilo ili u punjenju podataka ili u source 

kodu. Koliko smo vidjeli, kontni plan za ranije godine postoji prenesen u bazi: Kada se ide na kontrolni 

pregled uputa, onda se može na gumb detalja doći do kotnog plana. 

Na tom pregledu kontrolnom događa se također bug: kada se primjerice odabere godina 2009 ili starija, 

onda program puca i javlja grešku kod odabira konta 071000 - pogledati u prilogu zahtjeva grešku i ispis 

detalja greške.. Za godinu 2010javlja da nema tog konta, a za 2011 ok, a za 2012 stoji da nema ga u 

kontnom planu. 

hitno riješiti! 



80









Analiza problema, komunikacija. 


Program je ispravljen i sada se na ekranu uputa za generiranje izvještaja se više ne otvara prazan dijaloški okvir 

(bez kontnog plana). 

Ispravljen je i bug na ekranu Kontrolni pregled financijskih izvještaja: konta. 

Nova verzija je prebačena. 


Poštovani, 

obaviještavamo Vas da smo na serveru SV1-OT-LAUSMIS otvorili danas novu bazu hp4lcs_test za potrebe 

ponavljanja problema i testiranja rješenja za ovaj zahtjev. 

Mi ćemo ju ukloniti nakon što se ovaj zahtijev riješi. 


u dogovoru s gospođom Martinović, dok se ne riješi bug kod kopiranja stupaca, ručno izmijenjene upute u stupcu 

8 BILANCA izvještaja da glase konta na 2013. godinu. 


Poštovani, 

molimo dozvolu za Ivicu Kraljevića da se spoji na sql međubazu za lcsbi kako bi ustanovili postojanje uputa "na 

like" za konsolidirane izvještaje i njihovu ispravnost - u svezi istraživanja nepoželjnog ponašanja u sklopu ovog 


hvala 


Poštovani 

molimo dozvolu za Ivicu Kraljevića za spajanje na sv-1ot-lausmis server i međubazu za lcsbi kako bi mogao 

dalje istraživati ustanovljene probleme oko funkcionalnosti kopiranja uputa za konsolidirane izvještaje iz jednog 

stupca u drugi. 

Hvala 

ps - ovaj zahtjev laus broj 40603 na kojem neko vrijeme radimo, nema evidentiratn HP broj, možete poslati Vaš 

broj ukoliko želite da ga evidentiramo. 


Poštovani, 

što se tiče kopiranja uputa na druge stupce, vjerujemo da s ispravkama koje su se napravile u međuvremenu je 

riješen problem nemogućnosti kopiranja uputa odnosno pogrešnog kopiranja uputa. 

Problematične upute također, koliko vidimo su uklonjene. 

Molimo javite nam povratnu informaciju da li korisnici imaju još neku poteškoću u radu s uputama. 

Hvala 



80











Klijent: 






Vrlo hitno 


Katja 


13029 



11.01.2013 10:20 

Upisao: 

Božo Mišeta 

Područje: 

LROBD 


14.01.2013 

U prilogu se nalaze lista hp_knj1_r Priprema knjiženja robno-materijalnih dokumenata u glavnu knjigu po 

klasi i vdok gdje je prikazana vriednost 1,741.89 kn koja nije ispravna. Trebala bi se slagati sa listom 

obrshp1_rd, vrijednost ulaza 1,909.59. 

Do neslaganja je došlo uslijed napravljene nivelacije cijena na artiklima 01.01.2013 310323, 320955 i 

311965. 


Poštovani, 

Na datum 09.01.2013 nivelacijama broj 35358 - 09300 i 09302 i 09304 na navedenim artiklima napravljena je 

nivelacija kojom je doveddeno vrijednosno stanje u minus. 

Navedene nivelacije trebale su se raditi sa datumom dokumenta 01.01.2013, a ne sa datumom 31.12.2012, jer 

je do izmjene cijene u cijeniku za navedene artikle došlo 01.01.2013, te zbog toga su nivelacije na datum 

dokumenta 31.12.2012 krivo nivelirale cijenu. 

Stoga predlažemo da se intervenira na podacima, na način da se te tri nivelacije obrišu (naknadno je korisnik 

napravio iste te nivelacije ispravno sa datumom 01.01.2013), a potom napravi ispravak u svim vezanim 

tablicama, pa tako i u tablici pripreme za knjiženje! 

U očekivanju vaše dozvole za intervenciju, srdačan pozdrav. 


Nivelacije na skladištu 35358 sa datumom 31/12/2012 ( 35348-R12-09300, 35348-R12-09302 ,35348-R12- 

09304) su izbrisani iz obračuna, pripreme za knjiženje kao i sami dokumenti te je ažurirano stanje i ažurirana je 

nivelacija na 01/01/2013 (RC3 35348-R13-00001) za artikle 310323,320955,311965. 

Potrebno je ponovno usporediti liste obračuna obrshp i pripreme za knjiženje hp_knj te ponovno proknjižiti 

uglavnu knjigu . 




80











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13028 



11.01.2013 09:13 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


14.01.2013 


11.01.2013 

Napravljen je PREDRAČN br. 01400-213-00001 i sub-total i postage dues iznose 0,00 kn kod ispisa – vidi 

prilog 

Također nije ispisan cijeli VAT no – porezni broj – iako je unesen u šifarnik partnera (614214 ERMINIO 

BONALDO CIRCOLO FILATELICO POSTE) 



80









Poštovani, 

Ispis računa filatelije radi dobro. Korisnik je probao ponovo ispisati fakturu i sve je ok. 

Polje VAT je dužine 16 znakova i toliko se znakova ispisuje na listi. 

PITANJE : koliko znakova može biti u VAT polju pa ćemo po tome proširiti u polje u tablici ? 

status : čeka se odgovor HP 

NAPOMENA : 

U parametar tablici je artikal kojeg nema u ovom predračunu pa je PDUES=0 točno . 

sifra PDUES 

podatak 321128 

Provjereno : u bazi- predračun je dobro evidentiran u svim potrebnim tablicama. 

Nema ga u nku jer PID ne ide u nadzorne knjige izvoza 


Poštovani, 

Kod unosa računa filatelije polje VAT broja je prošireno na 26 znakova i tome prilagođen program . 

SQL za proširenje tablice : 

ALTER TABLE lm_fil_part MODIFY (vat char(26) ); 


Preuzmite novi WIN FAUS lib koji će biti dostupan sutra ujutro. 

Molimo povratne informacije nakon testiranja / suglasnost za zatvaranje zahtjeva - Riješen 



80











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13027 



10.01.2013 14:24 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


11.01.2013 


Molim da se kod izrade fakture za katalošku prodaju (na objektu ruckat.jas) makne kontrola da je partner 

626551 nositelj salda konta. 


Poštovani, 

Na objektu za ručni unos račuina kataloške prodaje (ruckat.jas) ukinuta je kontrola da partner mora biti nositelj 

salda konta za sve partnere a ne samo za partnera 626551 . 

RAZLOG : 

Bilo koja faktura se može izraditi/evidentirati na partnera koji nije nositelj salda konta - bitno je samo da je 

partner aktivan . 

NAPOMENA : 

Kod knjiženja bilo kojih računa na analitiku partnera pa tako i računa izrađenih na ruckat.jas ne smije se knjižiti 

na partnera iz fakture ako on nije nositelj salda-konta (NSC) nego se traži njegov aktivni NSC preko part i 

ustroj_part tablica . 

Dakle, faktura može biti izrađena/evidentirana na aktivnog partnera 626551 koji nije NSC ali bi trebala biti 

proknjižena na partnera 638652 koji mu je nadređen , aktivan i koji je nositelj salda-konta (NSC) . 


Preuzmite novi WIN FAUS lib koji je već na internetu 

Molimo povratne informacije nakon testiranja /suglasnost za zatvaranje zahtjeva 



80











Klijent: 





Hitnost: 



Višnja 


13026 



08.01.2013 15:46 

Upisao: 

Božo Mišeta 

Područje: 

LFINK 


15.01.2013 


Potrebno je kroz pna_kot_jf PRIJENOS PUTNIH NALOGA KOTAČ / LAUS preko F3 Veze ekran 

pna_veza_ff Pregled veza putnih naloga KOTAC -> LAUS proširiti filter podatkom 'Datum preuzimanja' i 

omogućiti ispis filtriranih podataka po datumu preuzimanja: 

kako se ne bi uvijek ispisivale sve veze prenesenih putnih naloga 


Poštovani, 

Na objektu pna_kot_jf PRIJENOS PUTNIH NALOGA KOTAČ / LAUS preko F3 Veze ekran pna_veza_ff Pregled 

veza putnih naloga KOTAC -> LAUS dodano je novo filter polje 'Datum preuzimanja' za pregled i ispis podataka 

iz tablice pna_veze. 






80











Klijent: 





Hitnost: 

Vrlo hitno 


Ivan 


13025 



08.01.2013 15:21 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


08.01.2013 


Potrebno je preko objekta 'kzfpu_fas Automatsko knjiženje zbirnih faktura poštanskih usluga' zabraniti 

knjiženja dokumenata u statusu 2. 

Sada se dogodilo da odobrenje: 

Tablica protokol: 

protokol vdokstatus 

3536601202758 ODO2 

Bude proknjiženo premda je u statusu 2: 

Tablica arhivk: 

konto nalogk vdokprotokol red 

120000 12IZ0582 ODO3536601202758 2687 

754051 12IZ0582 ODO3536601202758 2688 


Ispravljeno je Automatsko knjiženje zbirnih faktura poštanskih usluga. 

Sada se više neće knjižiti odobrenja koja su u statusu 2. 

Instalacija: Sutra ujutro novi WIN FAUS će biti na internetu. 



80











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13022 



08.01.2013 09:55 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


10.01.2013 


09.01.2013 

Prilikom prebacivanja računa u viši status ( iz 2 u 3) kroz objekt rucfil.jas, javlja se greška 239. 

Primjer računa 03266-912-00004 


Poštovani, 

Ispravljena je greška koja se javljala na objektu rucfil.jas prilikom prebacivanja računa iz statusa 2 u status 3. 

Greška -239 : Could not insert new row - duplicate value in a UNIQUE INDEXcolumn. 

Ako već postoji račun (protokol) u nadzornim knjigama (nku) kod prijelaza statusa 2 u 3 se ne treba opet 

upisivati a što je program prije ispravka radio. 


Preuzmite novi WIN faus lib je već na internetu. 



Poštovani! 

Više se ne javlja greška 239 prilikom prebacivanja fakture iz statusa 2 u 3 na objektu rucfil.jas. Možete zatvoriti 

ovaj zahtjev. 

Lp, 

----------------------------------------------------- 

Katja Kraljev 



80











Klijent: 





Hitnost: 

Vrlo hitno 


Višnja 


13023 

Riješen 


08.01.2013 09:51 

Upisao: 

Božo Mišeta 

Područje: 

LKROP 


15.01.2013 


Potrebno je prilagoditi strukturu IP XML datoteke izmjenama objavljenim na stranicama Porezne Uprave. 


Napravljena je izmjena u strukturi XML datoteke za IP obrazac prema uputama Porezne Uprave.Nova verzija 

datoteke koristi se za godine od 2009. nadalje.Možete preuzeti krop lib sa interneta. 

Pozdrav 



80











Klijent: 





prepod_jke 

Hitnost: 

Vrlo hitno 


Višnja 


13024 

Riješen 


08.01.2013 09:48 

Upisao: 

Božo Mišeta 

Područje: 

LKEVP 


09.01.2013 


Prijenosom ERV-a u obračun plaće za 12/2012 pogrešan je prijenos za radnike 18002 i 38064. Njima je 

iskazan pogrešan broj sati ( više od fonda) i pogrešan dodatak za prehranu: 

vidi prilog 

VAŽNO: Kako se svaki mjesec pojavljuju radnici sa pogrešnim prijenosom sati u obračun plaća (zahtjevi su 

već poslani), potrebno je ispraviti greške u prijenosu. Napominjem da je Kontrolni pregled ERV za te 

radnike ispravan. 



80









Poštovani, 

navedni radnici su ispravljeni na unosu primanja. Razlog greške je isti kao i na prethodnim zahtjevima, radnici s 

više rješenja i negativnim satima donosa se nisu dobro prebili radi nedozvoljavanja minusa sati na vrećicama. 

Programska ispravka će biti do kraja mjeseca. Podaci na kontrolnom pregledu također nisu dobri jer isti program 

formira podatke. 



Poštovani, 

napravljene su izmjene u prijenosu podataka iz ERV-a u obračun za radnike koji su imali specifičnu kombinaciju 

podataka koja je rezultirala netočnim fondom sati u unosu primanja. 

Kroz ovaj zahtjev riješeni su i: 

12743 

12642 

12552 

12478 

12476 

12441 

kevp možete preuzeti od 13/03/2013. 




80











Klijent: 





Hitnost: 

Vrlo hitno 




13021 

Riješen 


08.01.2013 09:34 

Upisao: 

Boško Tokić 

Područje: 

LZETT 


15.01.2013 


Potrebno je prilagoditi strukturu ID-1 XML datoteke izmjenama objavljenim na stranicama Porezne Uprave: 

http://www.porezna-uprava.hr/e-Porezna/e-id.asp?id=b03d6 


Napravljena je izmjena u strukturi XML datoteke za ID-1 obrazac prema uputama Porezne Uprave.Nova verzija 

datoteke koristi se za godine od 2009. nadalje.Možete preuzeti zett lib sa interneta. 

Pozdrav 



80











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13020 



07.01.2013 13:27 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


09.01.2013 


Napravljen je račun u valuti 21.12.2012 br. 03266-912-00005 i sub-total je -4?? (trebao bi biti 37.31) 



80









Poštovani, 

Molimo provjerite sad iznose na ispisu i evidenciji računa i predračuna za filateliju nakon intervencije na bazi 

te pošaljite suglasnost za zatvaranje zahtjeva - Riješeno ukoliko nema primjedbi 

------iri_iznos.sql ----------------------------------- 

Vezano za devizne račune IRI i predračune PID izrađene na rucfil* ispravljen je način evidencije kune i deviza 

ali i način ispisa . 

Računi koji su pogrešno evidentirani imali su u prošlosti dobar ispis iako je evidencija bila pogrešna. 

devizni iznos greškom je upisan u iznos kuna (protokol.idin) : 

protokol vdok idin status datum uradio 

0326621200001 PID 247.09 2 06/11/2012 NVICEBAY 

0326621200002 PID 23.92 2 18/12/2012 NVICEBAY 

0326621200003 PID 27.18 2 18/12/2012 SVEBAKOV 

0326621200004 PID 41.31 2 20/12/2012 NVICEBAY 

0326691200001 IRI 445.20 3 18/12/2012 SVEBAKOV 

0326691200005 IRI 41.31 3 21/12/2012 NVICEBAY 

a nije u iznos deviza (protdev.idev) : 

protokol valuta idev part tlistab 

0326621200001 840 0.00 2408 12211 

0326621200002 978 0.00 2408 12241 

0326621200003 978 0.00 2408 12241 

0326621200004 978 0.00 2408 12243 

0326691200001 978 0.00 2408 12241 

0326691200005 978 0.00 2408 12244 

Sad kad se ispis prilagodio ispravnoj evidenciji a računi iz prošlosti ostali krivo evidentirani , logično im sad ne 

valja ispis . 

Dakle, tim računima intervencijom na bazu napravljene su izmjene/korekcije u evidenciji i to : 

Devizni iznos je upisan u iznos deviza : 

protokol valuta idev part tlistab 

0326621200001 840 247.09 2408 12211 

0326621200002 978 23.92 2408 12241 

0326621200003 978 27.18 2408 12241 

0326621200004 978 41.31 2408 12243 

0326691200001 978 445.20 2408 12241 

0326691200005 978 41.31 2408 12244 

Kunska protuvrijednost po tlistab (važeći tačaj) upisana je u Iznos kuna i stupac 8 knjige IRA (neoporezivo - 

Izvoz) : 

protokol idev tecajs kune 

0326621200001 247.09 5.874978 1451.65 

0326621200002 23.92 7.527096 180.05 

0326621200003 27.18 7.527096 204.59 

0326691200001 445.20 7.527096 3351.06 

0326621200004 41.31 7.532132 311.15 

0326691200005 41.31 7.535217 311.28 


Poštovani, 

zahtjev uz vašu suglasnost zatvaramo - Riješen 

(Katja: Sve je u redu. Možete zatvoriti ovaj zahtjev. ) 



80











Klijent: 





Hitnost: 

Vrlo hitno 


Ivan 


13019 



07.01.2013 12:38 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


07.01.2013 


Kod Fakturiranja poštanskih usluga preko objekta fakt.jas tip plaćanja ‘F’ nema iznosa PLAĆENO PO 

PREDRAČUNU, već je na svim računima izašlo stanje ZA PLATITI – što je neispravno. PLAĆENO PO 

PREDRAČUNU je stanje svih otvorenih uplata, a ZA PLATITI treba biti 0,00 kn. 

Uplaćeno se gleda sa konta koje je upisano u paremtru 'FRANK'. 

Brojevi računa : 

11004-012-36019 do 11004-012-36035 

11009-012-13913 do 11009-012-13917 

Napomena: 

Salda su prenošena na nositelje salda-kontija. 


Poštovani, 

Napravljena je izmjena kod fakturiranja poštanskih usluga za tip plaćanja F. 

Salda su prenošena na nositelje salda-kontija pa je prema tome izmijenjeno i fakturiranje. 


Instalacija: Već isporučen novi WIN FAUS lib. 

Molimo povratne informacije / suglasnost za zatvaranje zahtjeva - Riješeno 



80











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13018 



07.01.2013 11:11 

Upisao: 

Božo Mišeta 

Područje: 

LROBD 


07.01.2013 


Prilikom ispisa liste (u excel-mail, zaslon, datoteku…) poskl_fd sa dolje navedenim uvjetima, javlja se 

greška 206. 



80









Potrebno je izvesti sql na produkcijskoj bazi create table "l1robd".grupa koji je već ranije izveden i na tesnoj bazi. 

( 

grupa char(6) not null , 

naziv nchar(70) not null, 


datum date, 



); 

create unique index "l1robd".grupa 

on "l1robd".grupa (grupa); 

grant all on grupa to public ; 

create table "l1robd".grupa_art 

( 

grupa char(6) not null , 

artikal char(13) not null, 


datum date, 



); 

create unique index "l1robd".grupa_art 

on "l1robd".grupa_art (grupa,artikal); 

grant all on grupa_art to public ; 

. 



80











Klijent: 



Pitanje 


Hitnost: 

Vrlo hitno 


Katja 


13017 



07.01.2013 09:41 

Upisao: 

Božo Mišeta 

Područje: 

LROBD 


07.01.2013 


Nakon ispravno provedenih inventura na oba skladišta u Rijeci (35347 I 35354) pojavio nam se novi 

problem vezan za provedbu nivelacije cijena iz 2012. godine u skladištu oštećene robe 35354. 

Iz skeniranog ekrana vidi se da za navedena dva artikla nije provedena nivelacija cijene po cjeniku broj 12- 

00675 od 1.11.2012. 

Budući da se radi o oštećenoj robi koja će se vraćati dobavljaču nećemo moći proknjižiti dokument bez 

nivelacije cijena za te artikle, niti nam je program dozvolio nivelacije cjenika iz 2012. godine. 

Da li postoji način da se odradi nivelacija cijena za artikle 316881 I 316882 za koje nije odrađena nivelacija 

u 2012.g. ili bi trebali stornirati inventuru I dokumente prije nje, odraditi nivelaciju I ponovo napraviti 

inventuru? 


Poštovana, 

identičan zahtjev dobili smo pod rednim brojem HP 13016. 

Smijemo li zatvoriti ovaj zahtjev. 

S štovanjem 


Poštovani, 

Napravljena je nivelacija RC3 35354-R12-00391 na skladištu 35354 i datum 01/11/2012 za artikle 316881i 

316882 te je sad potrebno napraviti nivelaciju na 01/01/2013 . 

Pozdrav 



80











Klijent: 



Pitanje 


Hitnost: 

Vrlo hitno 


Katja 


13016 



07.01.2013 09:06 

Upisao: 

Božo Mišeta 

Područje: 

LROBD 


07.01.2013 


Nakon ispravno provedenih inventura na oba skladišta u Rijeci (35347 I 35354) pojavio nam se novi 

problem vezan za provedbu nivelacije cijena iz 2012. godine u skladištu oštećene robe 35354. 

Iz skeniranog ekrana vidi se da za navedena dva artikla nije provedena nivelacija cijene po cjeniku broj 12- 

00675 od 1.11.2012. 

Budući da se radi o oštećenoj robi koja će se vraćati dobavljaču nećemo moći proknjižiti dokument bez 

nivelacije cijena za te artikle, niti nam je program dozvolio nivelacije cjenika iz 2012. godine. 

Da li postoji način da se odradi nivelacija cijena za artikle 316881 I 316882 za koje nije odrađena nivelacija 

u 2012.g. ili bi trebali stornirati inventuru I dokumente prije nje, odraditi nivelaciju I ponovo napraviti 

inventuru? 



80









Poštovana, 

Nivelaciju nije moguće odraditi jer postoje dvije promjene cijene u cijeniku. 

Prva promjena cijene u cijeniku je 01.11.2012 po kojoj nije odrađena nivelacija. 

Druga promjena cijene u cijeniku je 01.01.2013 po kojoj nije dozvoljena promjena jer nije odrađena prva 

nivelacija. 

Prijedlog za riješenje: 

- napraviti nivelaciju (Laus) za prvu izmjenu cijene u cijeniku, a potom prepustiti korisniku da odradi drugu 

nivelaciju. 

(riječ je o dva artikla na skladištu rabljene/oštečene robe) 

Molim dopuštenje za intervenciju. 

S štovanjem 


Dobro, 

Dupli zahtjev, se zatvara,i riješava se pod HP brojem 13017! 

Dobro, 

kako je pod brojevima 13016 i 13017 isti zahtjev kojeg da zatvorimo. 

Poz 

Poštovani! 

Kako je HP broj 13016 već zauzet, mijenjam broj ovog zahtjeva u 13017 

Lp, 

----------- 



80











Klijent: 





Hitnost: 

Vrlo hitno 




13016 

U rješavanju 

Kroz: 

- osb_fk LISTA OSTVARENI SATI BODOVI i 

-aosb_fk OSB LISTA IZ ARHIVA 


04.01.2013 16:17 

Upisao: 

Boško Tokić 

Područje: 

LKROP 


15.01.2013 


31.07.2013 

potrebno je izvršiti slijedeće izmjene na listama osb_rk i osb1_rk prema poslanom prilogu (list osb listaprimjer): 

a)naziv i sadržaj zadnjeg stupca 'Iznos' zamijeniti sa 'Bruto 2' iznosima po svim primanjima 

b)naziv retka 15 'Ukupno 1-14' preimenovati u 'Plaćeni sati/bodovi po RP-u’ 

c)naziv retka 16 zamijeniti sa 'Bodovi po RS-u’ 

d)za ostala primanja (u prilogu, list 'Sve šifre plaća' označeni crveno) na kraju dodati redak po nazivom 

'Ukupno ostala primanja' sa zbirnim iznosima stupaca za ostala primanja 

e)zadnji redak 'Broj radnika' potrebno je preimenovati u ' Broj radnika na bazi sati rada'. 

OSB liste koje se izrađuju na nivou organizacijskih grupa potrebno je uskladiti sa OSB listom na nivou 

cijelog HP-a. 



80









Potrebno je pojašnjenje u vezi točke a zahtjeva tj. što je novi sadržaj stupca : 

potrebno je izvršiti slijedeće izmjene na listama osb_rk i osb1_rk prema poslanom prilogu (list osb lista-primjer): 

a)naziv i sadržaj zadnjeg stupca 'Iznos' zamijeniti sa 'Bruto 2' iznosima po svim primanjima 


Poštovani, 

nove tražene izmjene koje ste poslali produžuju vrijeme realizacije ovog zahtjeva na ukupno 20 sati. 

Pozdrav 


Ispravak prethodne obrade zahtjeva. 

Obzirom na nove izmjene koje uključuju i izradu excel verzija osb lista a koje postoje i u obračunu i u arhivu 

ukupno vrijeme za zahtjev provjenjuje se na 

ukupno 30h. 

Pozdrav 


Moramo pomaknuti rok za isporuku ovog zahtjeva na 29/03/2013 zbog angažmana na drugim zahtjevima. 

Pozdrav 

Ljubo 



80











Klijent: 





Hitnost: 

Vrlo hitno 




13015 


Kroz: 

- osb_fk LISTA OSTVARENI SATI BODOVI i 

-aosb_fk OSB LISTA IZ ARHIVA 


04.01.2013 12:04 

Upisao: 

Boško Tokić 

Područje: 

LKROP 


07.01.2013 


potrebno je uvrstiti primanja: 

a)H22 – REDOVNI RAD-IZNOS i H25 - REDOVNI RAD-NETO IZNOS u grupu 01 kao primanje A00. 

b)B70 - BOL.PODUZEĆA 100% u grupu 04 kao primanje B12. 


Primanja H22 i H25 su upisana u tablicu prim_osb u grupu 01 a primanje B70 u grupu 04 u produkcijskoj bazi. 

Programi za pripremu osb liste iz obračuna i iz arhiva su prilagođeni dodatku novih primanja. 

Preuzmite: krop lib 



80











Klijent: 





Hitnost: 

Vrlo hitno 


Katja Kraljev 


13014 



04.01.2013 10:58 

Upisao: 

Boško Tokić 

Područje: 

WINTRAN 


07.01.2013 


U prilogu šaljemo Kontrolni ispis razlika za NADOSLANJE listano 03.01. I 04.01.2013 gdje nedostaju MPC 

vezana na Zadužene artikle. 

Prilog NADOSLANJE NAŠA DJECA je listano jutros nakon spuštene programske promjene. 


Ispravljena je greška na kontrolnim listama razlika konr1,konr2 i konr3 na objektu konr_ul.trn gdje se iznos cijene 

bio jednak količini. 

Preuzmite win tran lib koji je na internetu. 



80











Klijent: 





Hitnost: 

Vrlo hitno 




13013 

Riješen 


04.01.2013 09:55 

Upisao: 

Boško Tokić 

Područje: 

LTRAN 


05.01.2013 


Potrebno je doraditi prijenos prometa preko objekta ‘pri_ftr PRIJENOS PROMETA - MIPS / LAUS’ tako 

da radi sa PDV-om od 5%. 

Trenutno za slučaj npr.: 

Produkcijska MILA baza 

Tablica racun_zaj: 

racser 11463896801.01.2013.100001201.01.2013.9 

Tablica prom_pos_nov: 

racsersifuslmatstaiznosiznpopfrankikolusltipcijjedcijposprztip_slogtiptartarfbrstopdviznpdv 

1146389684412 321078 0001 39,939,971P0551,9 

Za ovu kombinaciju javila se greška: 93 Nepoznat tarfbr .- 



80









Program prijenosa radi ispravno. Nova porezna grupa nije upisana u šifarnik lm_pdv pa se zbog toga podatak 

evidentira kao pogrešan. 

Potrebno je na laus produkcijskoj bazi i mips bazi izvesti sql: 

insert into lm_pdv ( 

vporez, 

tgrup, 

pdvmips, 

tiptar, 

opis ) 

values ( 

"P", 

"7", 

"P05", 

"1", 

"POREZ PO STOPI 5.00" ) 


Instalacija: korisniku isporučiti sql: 

insert into lm_pdv ( 

vporez, 

tgrup, 

pdvmips, 

tiptar, 

opis ) 

values ( 

"P", 

"7", 

"P05", 

"1", 

"POREZ PO STOPI 5.00" ) 

Korisnik treba izvesti sql na laus produkcijskoj bazi i na mips bazi. 



80











Klijent: 





prot_fm stopa 5 pdv 

Hitnost: 

Vrlo hitno 


glorija 


13012 



04.01.2013 09:29 

Upisao: 

Dajana Lekić 

Područje: 

LBASE 


04.01.2013 


07.01.2013 

U evidenciji dokumenata nije moguće raditi sa stopom 5 bez obzira što je dodana u šifarniku stopa poreza. 



80









Poštovani, 

Dodana je mogućnost unosa stope poreza 5 % kod prot_fm EVIDENCIJA DOKUMENAT na način da se 

izmijenila provjera dozvoljenih stopa . 

Stope koje je moguće unijeti čitaju iz tablice stopa_poreza uz uvjet vporez like PDV% i stopa= zadana stopa, 

Ukinuta je poruka : Neispravna stopa poreza! Dozvoljene stope poreza su 0%, 10 %, 22%, 23% i 25% 

NAPOMENA : 

Provjera radi nevezano za Datum PDV-a ( datumuliz u protokol) i datume važenja stope ( datum_od i datum_do 

u stope_poreza ) jer realno sa stopm koja je prestala važiti prije 01.01.2013 ( stope 0, 22 te 23 ) i sad dolaze 

računi koji ulaze u prijavu pdv-a sa datumuliz>=01/01/2013 . 

Ako je potrebno uvoditi zabrane/upozorenja vezano za nesklad datuma dokumenta i period važenja stope pdv-a 

molimo pošaljite novi zahtjev sa točnom specifikacijom zabrana/upozorenja te navedenim uvjetima za 

provođenje istih . Napr , 

Za sve protokole koji ulaze u knjigu URA/IRA : 

a) zabraniti unos stope kojoj je datum_od > datum dokumenta (napr stopa 5 sa datum_od 01.01.2013 u računu 

sa datum dokumenta 31/12/2012) 

b) zabraniti unos stope kojoj je datum_do < datum dokumenta ( napr stopa 22 sa datum_do 31/07/2009 u 

računu sa datum dokumenta 31/12/2012 ) 


upisati stopu 5% u stope poreza sa vrstom like PDV%, napr PDV5 ili PDV05 

ažurirati datum do na 31/12/2012 za stopu 0. 

preuzeti LAUS BASE lib koji je dostupan na internetu od 7.1.2013 . 

Molimo povratne informacije nakon instalacije/testiranja tj. suglasnost za zatvaranje zahtjeva - Riješeno 



80











Klijent: 






Vrlo hitno 


Katja Kraljev 


13011 

Riješen 


04.01.2013 09:27 

Upisao: 

Boško Tokić 

Područje: 

LROBD 


Molim Vas da pokušate promijeniti datum na dokumentu35347-T13-00001 na 31.12.2012. budući da smo 

greškom proveli inventuru s današnjim datumom, te nam LAUS zbog toga ne dozvoljava nivelaciju cijena 

koja je bila za veliki broj artikala kojima je uveden PDV od 1.1.2013. godine. 

Kada smo uočili grešku koju smo naveli napravili smo storno dokumenta inventure na skladištu oštećene 

robe 35354, ali su nam ostale stavke artikala na stanju u 2013 godini pa nismo sigurni da li smo smjeli tu 

inventuru stornirati. Ako je moguće da nam dokument 35354-T13-00001 vratite u status 7 te da i njemu 

promijenite datum na 31.12.2012. 

Na koncu ako je najjednotavnije pokušajte sve vratiti na početno stanje pa da ponovimo postupak 

zaključenja inventure s ispravnim datumom. 

Ispričavamo se zbog pogreške i molimo da se nastali problem riješi kako bi Depo mogao početi slati robu u 

pošte. 


Inventura vrste dokumenta RI1 35347-T13-00001 (35347-T12-00003) su vraćeni u status 1 tj. inventura 35354- 

T13-00001 ( 35354-T12-00001 ) te je storno dokument 35354-T13-00002 izbrisan. 

Potrebno je radi promjene datuma dokumenta napraviti : 

1. Promjeniti datum dokumenta na željeni u 2012 godini te napraviti F2 (IZMJENA) 

2. Na F3(AŽURIRAJ) ažurirati knjigovodstvemo stanje 

3. F1(ISTO-ST) ažurirati stanje po inventuri da bude jedanko knjigovodstvenom 

4. Isprintiatri liste viškova ili manjkova te utvrditi dali postoje iste 

5. Prebaciti invenuru u status 7. 

Izvedeno kroz bazu korisnika. 



80











Klijent: 





ugovori bagatelna JN 

Hitnost: 



višnja 


13010 

Riješen 


03.01.2013 15:55 

Upisao: 

Dajana Lekić 

Područje: 

EPNAB 


04.01.2013 


04.01.2013 

Potrebno je u ePN za spis „HP-10/1-024867/12“ u Registru ugovora bagatelne nabave izvršiti izmjenu: 

- broj ugovora „HP-1071-024867/12“, u broj ugovora „HP-10/1-024867/12“ 


Isporučeno na produkciju 



80











Klijent: 





Hitnost: 

Vrlo hitno 


Katja Kraljev 


13009 



03.01.2013 15:41 

Upisao: 

Boško Tokić 

Područje: 

LROBD 


07.01.2013 

Molimo da se omoguće ispisi dokumenata po kalkulativnim elementima: 

RUD – Izdatnica u doradu 

RUP – Povratnica robe iz dorade 

RDU – Izdatnica robe u donaciju 

RDP – Povratnica robe iz donacije 



Napravljeni su ispisi po kalkulativnim elemantima na dokumentima RUD,RUP,RDU,RDP. 

Na objektu ISPul_jm PRIDRUŽIVANJE ISPISA DOKUMENTIMA potrebno je po vrstama dokumenta pridružiti 

gore navedene ispise : 

objekt Naziv/Text procedura korisnik 

RUDzg_fd ISPIS PO KALKULATIVNIM ELEMEN. RUDzg_isp_jd KE SVI 

RUPzg_fd ISPIS PO KALKULATIVNIM ELEMEN. RUPzg_isp_jd KE SVI 

RDUzg_fd ISPIS PO KALKULATIVNIM ELEMEN. RDUzg_isp_jd KE SVI 

RDPzg_fd ISPIS PO KALKULATIVNIM ELEMEN. RDPzg_isp_jd KE SVI 

Potrebno je preuzeti rob0,rob1,rob2,rob3,rob4 koji su na internetu. 



80











Klijent: 





prot_fm -stopa 5 

Hitnost: 

Vrlo hitno 


kramer 


13004 



03.01.2013 14:50 

Upisao: 

Dajana Lekić 

Područje: 

LBASE 


07.01.2013 


07.01.2013 

Potrebno omogućiti na prot_fm neometanu evidenciju stope PDV-a od 5% na ulaznim i izzlaznim 

dokumentima koji ulaze u knjige URA/IRA (PDV) . 

Sad to nije moguće jer se javi za upisanu stopa=5 na prot1_fm te prot11_fm na izlazu iz polja za upis 

stope PDV-a poruka : 

Neispravna stopa poreza! Dozvoljene stope poreza su 0%, 10 %, 22%, 23% i 25% ! 



80











Klijent: 





Hitnost: 

Vrlo hitno 


Glorija 


Odmah riješiti 

13008 



03.01.2013 11:03 

Upisao: 

Božo Mišeta 

Područje: 

LWINFAU 


03.01.2013 


Kod kreiranja računa u valuti devizni iznos eura se upiše u kunski, a u devini protdev se upiše 0. Kunski 

treba biti po srednjem tečaju HNB-a na taj datum dokumesta. Račun napravljen na testu. 

Također račun mora ispravno leći u nadzorne knjige i u fiskalizaciji mora ići kunski iznos. 

Vidi prilog 



80









Poštovani, 

Kod kreiranja računa u valuti na rucfil.jas RAČUN U VALUTI ispravljeno je punjenje kunskih i deviznih iznosa. 

Račun prilikom izmjene statusa u 3 prelazi u nadzorne knjige u kunskom iznosu (nku za vnk=Z izvoz roba) 

Prilagođen je ispis nakon izmjena vezanih za popunu deviznih i kunskih iznosa tako da ide : 

iz protdev tablice iznos deviza (ukupan iznos računa u valuti) ili iz lm_fil_stav za iznos deviza za stavke. 

U protokol tablici sad jesu i MORAJU biti kune jer kune idu : 

- u knjigu IRA (pdv) i to pod neoporezivo izvoz (prot_neop.iznos8) 

- u fiskalizaciju (protokol_fis) 

iznos kuna se dobije kao : uk.iznos računa u valuti * srednji tečaj RIZTL za valutu važeći na datum dokumenta u 

računu 

Sve napravljeno po uzoru na ispravno ručno evidentiran dokument IRI broj 4001391000214 


Preuzeti sutra ujutro novi WIN FAUS lib. 

Molimo povratne informacije / suglasnost za zatvaranje zahtjeva - riješeno nakon instalacije i testiranja izmjena 


Poštovani, 



Poštovani, 

Proveden je ispravk pogrešno evidentiranih iznosa kuna i deviza kod računa za filateliju IRI koji su već ušli u 

nadzorne knjige izvoza roba a ne može se stornirati i upisati novi račun jer mora bit isti JCD u NK samo jedanut 

Sve odrađeno kroz bazu i povezano sa zahtjevom 13020 . 

Molimo pošaljite suglasnost za zatvaranje ovog zahtjeva - Riješeno . 

Eventualne nepravilnosti kod deviznih računa i predračuna za filateliju dalje se rješavaju kroz zahtjev 13020 . 


Poštovani, 

Zahtjev zatvaramo uz vašu suglasnost - Riješava se dalje kroz zahtjev HP 13020 . 

(Katja : Možete zatvoriti ovaj zahtjev.) 



80











Klijent: 





Hitnost: 

Vrlo hitno 


Ivan 


13007 



03.01.2013 09:59 

Upisao: 

Božo Mišeta 

Područje: 

EOBRRAC 


03.01.2013 

U eObradi se ne vidi org jedinica 03266 kod ovjere računa sa slike: 




80









Molim pristup na produkciju za Tvrtka Matoševića. 


Organizacijska jedinica 03266 nije aktivna. Molim da se aktivira pa neka provjere da li je onda vidljiva. 

Lp 



80









Poštovani , 

Orgj 03266 kao ni ostale orgj kojima je orgj.istrukt=4 ne mogu biti korištene kod ovjere računa za podgrupu 

troška 2012-8.2.5 zato što se kod ponovne aktivacije razine ovjere 4 poslao slog sa akcija=U (update) a treba 

slati sa akcija=I (insert) - ponovni upis . 

Molimo provjerite može li se sad u ovjeri koristiti orgj razine 4 

Status : čekamo rezultat /suglasnost za zatvaranje zahtjeva - Riješen 

---------izveden 

je SQL : 

insert into mips_laus@mips_laus:tip_razina_eolog 

(podgrupa_tr,razina,akcija,datum_upisa,datum_preuzimanja,status,aktivnost) % 

select podgrupa_tr ,razina,'I','2013-01-04 15:00:23','','','D' 

from mips_laus@mips_laus:tip_razina_eolog 

-- 1 row(s) inserted. 

Zapis je servisom proslijeđen u eObrada : 

id 762 

podgrupa_tr 2012-8.2.5 

razina 4 

akcija I 

datum_upisa 2013-01-04 15:00:23 

datum_preuzimanja 2013-01-04 15:00:35 

status 1 

aktivnost D 

----------------------------mips 

produkcija prije izvođenja sql-a : 

id podgrupa_tr razina akcija datum_upisa aktivnost 

502 2012-8.2.5 4 I 2012-01-19 16:06:40 D ---> aktivno kod akcija I- insert 

674 2012-8.2.5 3 I 2012-03-21 14:24:46 D 

681 2012-8.2.5 4 D 2012-03-22 08:21:14 N----> proglašeno neaktivnim akcijom D-deaktiviranje 

758 2012-8.2.5 4 U 2012-12-28 14:09:23 D----> proglašeno ponovo aktivnim akcijom U-update 

759 2012-8.2.5 2 I 2012-12-28 15:17:30 D 

za orgj 03266 u orgj tablici na laus produkciji je upisno : 

orgj 03266 

naziv ODJEL ZA RAZVOJ 

aktivnost D 

razina 3 - ovdje se upisuje razina u hijerarhiji org. srtukture 

istrukt 4 - ovdje se upisuje razina za ovjeru računa (neka vrijednost iz orgj_tip) 

na laus produkciji u orgj_tip : 

4 ODJEL / PODRUCJE 

Za podrgupu je važeće (oe_vrac tablica uputa /klasifikacija za ovjeru računa) : 

podgrupa_tr 2012-8.2.5 

aktivnost D 

ovjera O 

orgj_tip1 2 

orgj_tip2 3 

orgj_tip3 4 


Poštovani, 

Zahtjev uz vašu suglasnost zatvaramo - Riješen 



80











Klijent: 





Hitnost: 

Vrlo hitno 


Glorija 


13006 



03.01.2013 09:56 

Upisao: 

Božo Mišeta 

Područje: 

LBASE 


08.01.2013 


U Lausu kada se stavi uvjet G i OIB program prikaže sve šifre, ne poštuje zadane uvjete sa ekrana. 

Potrebna provjera svih kombinacija uvjeta. 


Poštovani , 

Omogućeno je da se na svim pregledima kod pretrage partnera na ekranu partt_fm uvažava filter OIB. 


Preuzeti novi LAUS BASE lib ( nakon 5.1.2013. promjene su u lib-u) 




80











Klijent: 





Hitnost: 

Vrlo hitno 


Katja 


13005 



03.01.2013 09:21 

Upisao: 

Božo Mišeta 

Područje: 

EHPUR 


07.01.2013 


U aplikaciji eHPUR kod transakcije T24 Vraćanje u rad molimo omogućiti zbirno vračanje u rad za spise po 

kojima je napravljen izlazni/ulazni podnesak. 

Naime kod odabira spisa po kojima je zadnje napravljen izlazni podnesak dolazi do greške „error on page“ 

za zbirno vraćanje u rad. 



80









Poštovani, 

Molim Vas Print Screen greške, te popis spisa koje ste vraćali u rad, a navedena greška se dogodila. 

Također, što se misli pod ovim: ˝ za spise po kojima je napravljen izlazni/ulazni podnesak˝, da li ste primijetili 

razliku odnosno da se greška događa samo u određenim slučajevima. 

Lp, 


Poštovani, 

Dorade su prebačene na test, molimo povratnu informaciju. 

Lp, 


Molimo pristup produkciji danas 09.01.2013. od 16.00 - 17.00 sati za kolegu Matoševića, a vezano uz 

prebacivanje dorade iz zahtjeva 13005. 

Hvala. 

Lp, 


Poštovani, 

nismo prebacivali doradu bez službenog dopuštenja s Vaše strane. 

Molimo danas 10.01.2013. pristup za Tvrtka Matoševića u periodu od 16.00 - 17.00 sati. 

Također, da li je u redu dorada na zahtjevu 13001, ako je, možemo odmah i tu doradu prebaciti danas? 

Zahvaljujemo na povratnim informacijama. 

Lp, 


Poštovani, 

Dorade su prebačene na produkciju. 

Ukoliko nemate primjedbi, predlažemo zatvaranje zahtjeva. 

Lp, 


Poštovani, 

Zahtjev zatvaramo - Riješen uz vašu suglasnost 

Katja : Možete zatvoriti ovaj zahtjev. 



80











Klijent: 





Hitnost: 

Vrlo hitno 


Ivan 


13004 



02.01.2013 15:07 

Upisao: 

Božo Mišeta 

Područje: 

EOBRRAC 


02.01.2013 


Molim na ekranu Razrada PDV-a u polju stopa dodati novu stopu PDV-a od 5% (uz već postojeće stope 

0,10,22,23 i 25%). Nova stopa primjenjuje se od 01.01.2013. 

P4 Likvidacija 

T9 Likvidiranje računa 


Na ekranu za razradu pdv-a unesena je stopa od 5%. Promjena se nalazi na testnoj verziji. Molim da prije 

korištenja svi obrišu cache. 


Molim HP da ostave Tvrtku Matoševiću dostupnost na produkciju radi prebacivanja zahtjeva 13004 na produkciju 

iza 16h. 

Lp 


Poštovani, 

Promjene su prebačene na produkciju jučer iza 16:00 



80











Klijent: 





Hitnost: 

Vrlo hitno 


Višnja 


13003 



02.01.2013 12:58 

Upisao: 

Božo Mišeta 

Područje: 

EPNAB 


07.01.2013 


Kroz Aministracija sustava-> Korisničke postavke nemoguće je izmijeniti postavke korisnika pod „Radnik“ 

jer je padajući meni disfunkcionalan: 

vidi prilog 

Navedenog korisnika nije moguće 'pronaći' kroz padajući izbornik niti ga 'filtrirati' po nazivu. 



80









Poštovani, 


Potrebno je sa testne baze prebaciti programske promijene vezane za ažuriranje podatka ‘Radnik’ i pripadajući 

šifrarnik radnika 

Pitanje : 

Potrebno je programske izmjene instalirati na produkciju ? 

Potrebno je šifarnik raadnika s test baze prebaciti na produkciju ? 

Molimo odgovre i mogućnost spajanja na produkciju . 

Spajat će se kolega Vjeran Livaić 


Poštovani, 

poslali smo pitanja 15.4.2013. vezano za prebacivanje na produkciju . 

Odgovre nismo dobili - molimo pošaljite traženo 

Status : čekaju se pojašnjenja od HP 





Poštovani, 


Potrebno je sa testne baze prebaciti programske promijene vezane za ažuriranje podatka ‘Radnik’ i pripadajući 

šifrarnik radnika 

Pitanje : 

Potrebno je programske izmjene instalirati na produkciju ? 

Potrebno je šifarnik raadnika s test baze prebaciti na produkciju ? 

Molimo odgovre i mogućnost spajanja na produkciju . 

Spajat će se kolega Vjeran Livaić 


Poštovani, 

Molimo pristup na produkciju za Vjerana Livajića u vezi zahtjeva 13003. 

Status: čekamo 


Poštovani, 



Poštovani, 




80











Klijent: 





Hitnost: 

Vrlo hitno 


Višnja 


13002 



02.01.2013 11:14 

Upisao: 

Božo Mišeta 

Područje: 

LKROP 


07.01.2013 


Kroz rjes_ev_fk Evidencija rješenja na ekranu 'Pregled rješenja' (rjes_ep_fk) potrebno je omogućiti 

filter pretraživanja (kao što je korisnica više puta ekranski dobila), podataka o rješenjima radnika 

(I,VR,OJ,RM): 


Poštovani, 

Ispravljen je pregled rješenja radnika tako da se polja za filtiranje na pregledu uvijek vide. 


Preuzmite novi krop lib od 12.01.2013 

Molimo povratne informacije nakon testiranja/suglasnost za zatvaranje zahtjeva - Riješen 



80











Klijent: 





Hitnost: 

Vrlo hitno 


Višnja 


13001 



02.01.2013 10:02 

Upisao: 

Božo Mišeta 

Područje: 

EHPUR 


02.01.2013 


Kroz eHPUR potrebno je omogućiti evidenciju urudžbenih brojeva u 2013 sa brojem 000001 (jedan), 

a ne s brojem DPO-6/2-000005/13 evidentiranim 02.01.2013. u 07:57:04 u Pisarnici Osijek kako je vidljivo u 

Zbirnom pretraživanju. Nastali problem treba riješit u što kraćem roku, odnosno još danas, da bi urudžbeni 

brojevi koji nedostaju bili evidentirani s današnjim datumom. 



80









Poštovani, 

Molimo omogućite pristup Tvrtku Matoševiću na produkciju eHPUR radi rješavanja ovog zajhteva te pošaljite 

obavjest kad bude moguće spajanje 


Poštovani, 

U telefonskom razgovoru s gosp. Jadrankom Holetićem dogovoreno je slijedeće: 

· HP dostavlja 4 spisa sa svim potrebnim podacima (naziv spisa, nadležnost, prilozi, mjesto pisarnice...) 

· Dokument IT unosi podatke spisa (najvjerovatnije danas, 02.01.2013., poslije 16.00 sati, stoga molimo 

korisnike Pisarnice da ne rade u aplikaciji poslije 16.00 sati 

· Programer istima dodjeljuje brojeve koji nedostaju 000001/13 , 000002/13, 000003/13 i 000004/13 

· Po završetku Dokument IT javlja poruku da je završen unos spisa 

· Provjera Pisarnice da su podaci unešeni s pravilnim ur. brojem te zatvaranje zahtjeva. 


Molimo informatiku da pristup na produkciju bude omogućen do kraja našeg radnog vremena odnosno 17.00 

sati. 

Pristupiti će se rješavanju zahtjeva HP: 13001 u 16.00. 

Hvala, 


Poštovani, 

dostavljeni spisi (4) unešeni su u aplikaciju te su dobili brojevi redoslijedom kako ste ih poslali. 

Molimo provjerite te javite povratnu informaciju/ suglasnost za zatvaranje zahtjeva -riješeno 

Lp, 



80









Poštovani, 

Aplikacija sortira spise prema vremenu unosa spisa (ID). Spisi su naknadno uneseni te se tako i prikazuju. 

Ukoliko se promjeni logika prikaza spisa koji je postavljen od samih početaka potrebno je utrošiti dodatno 

vrijeme, također, definirati po kojem se novome kriteriju trebaju sortirati. 

Smatramo da je to veća intervencija, a sam problem nije toliko značajan. 

Status: čekamo suglasnost za zatvaranje zahtjeva - Riješeno 

ili novi kriterij za sortiranje spisa 


Poštovani, 

Poslali smo Vam jučer, 03.01.2013. odgovor: ˝ Aplikacija sortira spise prema vremenu unosa spisa (ID). Spisi su 

naknadno uneseni te se tako i prikazuju. 

Ukoliko se promjeni logika prikaza spisa koji je postavljen od samih početaka potrebno je utrošiti dodatno 

vrijeme, također, definirati po kojem se novome kriteriju trebaju sortirati. 

Smatramo da je to veća intervencija, a sam problem nije toliko značajan.˝ 

Molimo povratnu informaciju, da li ćete poslati novi zahtjev jer će se isti onda evidentirati kao adaptivno 

održavanje jer se radi o novom načinu sortiranja ili ćete odustati od zahtjeva (prikaz 4 spisa po redoslijedu) i 

zatvoriti ovaj zahtjev. 


Poštovani, 

Molimo Vas pristup za zahtjev 13001 kako bismo probali vidjeti da li je isti moguće riješiti na razini baze ili će se 

pristupiti rješavanju na neki drugi način. 

Molim povratnu informaciju. 

Lp, 


Poštovani, 

Programer Tvrtko Matošević Izvršiti će slijedeće radnje: 

1. backup najnovije baze s produkcije 

2. restore backup- a na testu (HP) 

3. napisati upit koji će Zapis tablicu proširiti s kolonom DatumUnosa 

4. popuniti podatak DatumUnosa koji se može dohvatiti iz Dnevnika rada 

5. u aplikaciji proširiti XPO klasu Zapis 

6. sortirati grid prema novoj koloni 



80









Poštovani, 

Molimo Vas backup baze te da isti stavite na test i javite gdje se točno nalazi. 

Hvala. 


Poštovani, 

Izvršene su radnje opisane u prethodnom mailu. 

Dorade su prebačene na test. Molimo povratnu informaciju. 

Lp, 


Poštovani, 

nismo prebacivali doradu bez službenog dopuštenja s Vaše strane. 

Molimo danas 10.01.2013. pristup za Tvrtka Matoševića u periodu od 16.00 - 17.00 sati. 

Također, da li je u redu dorada na zahtjevu 13001, ako je, možemo odmah i tu doradu prebaciti danas? 

Zahvaljujemo na povratnim informacijama. 

Lp, 


Poštovani, 

Dorade su prebačene na produkciju. 

Ukoliko nemate primjedbi, predlažemo zatvaranje zahtjeva. 

Lp, 


Poštovani, 

Zahtjev zatvaramo - Riješen uz vašu suglasnost 



80











Klijent: 





Hitnost: 



Glorija 


12795 

Riješen 


02.01.2013 09:10 

Upisao: 

Božo Mišeta 

Područje: 

LFINK 


31.01.2013 


Kod knjiženja na nositelja saldakontija (ručno, žirac, ulazni računi iz eObrade, izlazne fakture) potrebna je 

provjera ispravnosti. Knjiženje je mislim definirano da ide iz tablice ustroj_part gdje se traži šifra analitike 

koja je nositelj. Taj sistem nije najbolje rješenja mada sada će biti ispravno jer je u sustavu postavljeno da 

je samo jedna šifra (glavna) nositelj. U slučaju da je npr. glavna šifra nositelj G1 i da su nositelji šifre ispod 

nje G2 i G3, a fakture na šiframa druge razine znači onima ispod G2 i G3 npr. šifre G4 i G5 koje nisu 

nositelji. I pitanje, po vama na koju će šifru proknjižiti fakturu za šifru G4? Treba na G2, a ne na glavnu G1, 

jer je i prva iznad njega definiran kao nositelj. Molimo da sva knjiženja po sustavu postavite ispravno. 



80









Poštovani, 

Sustav je postavljen tako da podržava normalno tj. uredno stanje u šifarniku partnera : Glavna šifra je nositelj 

salda-konta . 

Do neočekivanih rezultata knjiženja može doći zbog neregularnog stanja u šifrsniku za neke šifre tj zbog 

nepravilnosti u šifarniku partnera : 

--- Čekamo vaš odgovor tj. hoćete li i koje aktivnosti poduzeti na sređivanju šifranika partnera te stav u vezi 

uvođenja novog kriterija (pod 4.) 

1. za part=nadpart (glavna šifra partnera ) istrukt treba biti F - Firma) a nije : 

--- takav slučaj je samo 1 : 

part qnadpart aktivnost xis istrukt 

605961 605961 D D P 

Rješenje : Postaviti za ovog partnera istrukt=F 

2. Postoje u part tablici slučajevi kad partner sam sebi nije nadređen a istrukt=F - Firma tj. glavna šifra . 

--- takvih ima 39 aktivnih koji su nositelji salda konta . Napr , 

part nadpart aktivnost xis istrukt 

644105 644104 D D F 

644107 644106 D D F 

644109 644108 D D F 

644113 644111 D D F 

644115 644114 D D F 

644117 644116 D D F 

644118 622782 D D F 

Rješenje : za ove partnere postaviti istrukt=S , isaco=N 

Ako nije moguće postaviti isaco=N onda barem istrukt=S 

3. Postoje partneri kojima nije upisan nadređeni partner . 

--- takvih je 17 . Napr , 

4114 D D F 

4115 D D F 

4122 D D F 

913768 D D F 

Rješenje : upisati za ove partnere nadpart=part u tablici part 

Ako se na njih ne želi knjižiti, onda u nadpart upisati njihovog nositelja sald-konta te postaviti istrukt=S jer nisu 

same sebi nadređeni . 

4. za jednog te istog partnera postoji u ustroju više nadpart koji su aktivni nositelji salda-konta a treba biti samo 1 

--- takvih partnera ima 41 ,a neki imaju i više od 2 nositelja salda-konta . Napr, 

part nadpart istrukt isaco 

0144 627963 F D 

627963 638947 F N 

638947 638947 F D 

Rješenje : postići stanje da je za 1 partnera samo jedna šifra nositelj salda-konta i to glavna šifra sa istrukt=F, 

isaco=D . 

Ako ovo nije moguće , potrebno je barem na šifre za koje part!=nadpart u tablici part postaviti da im je istrukt=S 

a ne F-Firma tako da se postigne da je samo jedna šifra glavna .Onda se kod određivanja nositelja salda-konta 

može uvesti kriterij : 

Ako je šifra partnera aktivna a nije nositelj salda konta - knjiži se na aktivnu nadređenu šifru koja je nositelj salda 

konta po redoslijedu istrukt desc tako da knjiži na istrukt=S (neglavna šifra) koje je nositelj salda konta a na 

glavnu šifru samo ako nema podređenih nositelja salda-konta . 

--- sad ovako radi : 

Ako je šifra partnera aktivna a nije nositelj salda-konta , nositelj se određuje bez redoslijeda : istrukt desc tj. 

određuje se slučajno ako postoji više aktivnih nositelja salda-konta u 'grani' u kojoj je partner 

Ako je šifra partnera aktivna i nositelj salda konta - knjiži se na nju nevezano za istrukt tj. je li glavna ili ne . 

Ako nije aktivna šifra partnera niti šifra nositelja salda-konta - nema knjiženja 



80


Status: 








Poštovani, 

Omogućeno je knjiženje na šifru nositelja salda konta NCS kod knjiženja izvoda žira te knjiženja eObrade. 

Dodano ranije kontrola na NSC samo kod opcije sa upisom grešaka kod knjiženja izvoda. 

Kod knjiženja eObrade na eo_kn_jf i kod knjiženja izvoda bez poruka o greškama kontrola za NSC u proceduri u 

BASE-u dodano sad da se knjiži na NSC pa bi sada trebalo raditi za sve slučaje knjiženja na analitiku partnera 

neovisno o kontu . 


Preuzeti novi LAUS BASE lib koji je na internetu od 5.1.2013 

Molimo pošaljite povratne informacije nakon instalacije i testiranja tj. suglasnost za zatvaranje zahtjeva - Riješen 


Poštovani, 

Ako je šifra partnera aktivna i nositelj salda konta - knjiži se na nju nevezano za istrukt tj. je li glavna ili ne . 

za slučaj koji ste poslali : 

Kada se ide knjižiti na partnera 655477 koji je aktivan i nositelj sad se ne traži glavna šifra nego se na njega 

knjiži . 

( ranije se knjižilo na nadređenu šifru 617339 koja je, također, NSC ) 

Promjene su vidljive kod : 

-- šifarnik partnera 

-- kod knjiženja (ručno, automatski, izvod ZR ,.. ) 


Preuzmite nove LAUS BASE i FINK libove (panter char) koji su dostupni od sutra ujutro na internetu 


------------------ 

IZNIMKE : kod knjiženja izvoda ZR 

// Dodano prema zahtjevu 27476 čitanje analitike iz aktivnog ugovora vezanog za fakturu kad je : 

pozbo(3,4) == '2259' / odnosno 2257 

placanje_tip='A' / odnosno F 

analitika in (select part from part where oib=':xoib' and aktivnost='D' and isaco='D') .... 

HP treba poslat zahtjev s opisom kako treba promijeniti iznimke (ako je potrebno) obzirom da UGK ne smije 

biti na šifri koja je NSC 


Poštovani, 

Kod automatskog knjiženja izvoda žira prilagođena je logika traženja NSC za avans i frankiranje. 

Obavijestiti korisnika o preuzimanju novog LAUS FINK liba u srijedu 30.1. 

S štovanjem 



80

Pregled korisničkih zahtjeva - Laus CC

Create successful ePaper yourself

Delete template?

Save as template?