Aktivnost
Od 19.03.2012 do 17.04.2012
17.04.2012
-
22:15 Podrška #27336: POS priprema, switch na semaphores_v1.1
- "commit":https://github.com/knowhow/F18_knowhow/commit/cceca0ae9ca68bb687c8361914f39aeaa423e3d3
još borbe sa izvještajima... -
- tu je i POS blizu iskoristivom stanju
-
- "commit":https://github.com/knowhow/F18_knowhow/commit/6e1391b2fe8b3bf1291beab1b3c8ebdf8485c5bb
-
- ažuriranja sam očistio
-
- "realizacija kase":https://github.com/knowhow/F18_knowhow/commit/926e7016077ea421d1404566942a18f518920822
osposobio sam ovaj izvještaj, problem kreiranje POM tabele itd... sada je napravljeno kako treba
treba pročistiti i ostale iz... -
- ispravio "commit":https://github.com/knowhow/F18_knowhow/commit/cceca0ae9ca68bb687c8361914f39aeaa423e3d3
-
- u kojem režimu, šta se pokreće ? koja opcija
-
15:03 Greške #27665 (Zatvoreno): F18 1.0.6, KALK, TD 16, stavka protustavka !OK
- duplicate key value violates unique constraint "kalk_kalk_pkey
obje stavke imaju rbr 1 -
- sada poziva ~/knowhowERP/util/delphirb.exe
treba da poziva /opt/knowhowERP/util/delphirb -
14:33 Podrška #27661: F18 release 1.0.6
-
-
-
- bringout@knowhow:~$ cd src/F18_knowhow/
bringout@knowhow:~/src/F18_knowhow$ git fetch -
- *ISPRAVAK*
Nisam dobro uradio build za x64 -
- I publikovao na Google Code
i686 -
- 64 bit:
-
- Packaging:
-
- bringout@build32:~/dev/F18_knowhow$ ./build_release.sh
-
zatim uradio pull s gita-
- bringout@euroholz-1:/opt/knowhowERP/util$ ssh bringout@192.168.45.48
-
-
- tagirao sam 1.0.6
može se preuzeti i bildati ubuntu verzija -
-
- znači ne treba stavljati ?
-
13:17 Podrška #27663: F18, log_write, uvijek upisati datum + vrijeme
- u fmk.log imaš vrijeme svih operacija posebna kolona u tabeli. zato to nisam stavio u F18.log
-
- u funkciji log_write() implementirati da se uvijek upiše datum + vrijeme
primjer: -
-
- implementirati funkciju
*f18_odt_convert_to_pdf()*
koja će obavljati ovaj posao nakon generisanja odt dokumenta (funkcija *f18_odt_generate()* ) -
- dakle, na veznom tiketu sam ispitao
može se bez problema koristiti "jodconverter paket":http://www.artofsolving.com/opensource/jodconverter
komandna linija je: -
-
- koriste se samo ova dva parametra
-
- Ernad Husremović je napisao/la:
> i ubuntu ima pandam open-u
> ...
izbaci nepotrebne parametre, iskoristi ovo -
- h1. Podešenje štampe pod Windows-om
Praktično je identično
h2. 1) Globalni parametri
Također defaultne postavke se uzimaju
*Java start cmd*: -
- i ubuntu ima pandam open-u
#26266
-
- nakon toga pozivamo generisanje fakture ili bilo kojeg drugog reporta i dešava se
* provjera lokacije template (izbaci info u slučaju da template fajl ne postoji)
* provjera jodreports-cli paketa (izbaci info ako ne postoji)
* gene... -
- Ernad Husremović je napisao/la:
> > /home/bin/jodreports-cli.jar
> ...
nemoj po feature ticketu -
- > /home/bin/jodreports-cli.jar
ovo ne valja
podesiti kao pod windows-ima
gje je ovaj jar na F18 windows instalaciji ?
pretpostavljam /opt/knowhowERP/lib ili /util -
- h2. 2) lokacija template fajlova
Template fajlove smjestiti na lokciju: -
- h1. Podešenje štampe pod Linux-om
h2. 1) Globalni parametri jodreports, java
Globalni parametri se podašavaju na glavnom meniju aplikacije pod
*P. Parametri aplikacije*
Podešava se:
*java start cmd:* -
- povezati se sa instalacijom template-a
-
- napisati postavke pod linuxom, windows-ima
-
- dobro
-
- *xdg-open* ima svaka distribucija
-
-
- "commit":https://github.com/knowhow/F18_knowhow/commit/b3189786bfc1d2b643ba44ab0e79cfcdb2de1c35
-
- uveo logiranja
"commit":https://github.com/knowhow/F18_knowhow/commit/39af1d2cf66fdeb83eda047f9d5b8f578712ff28
također promjenio funkciju *g_afile()* -> *get_file_list_array()*
ta funkcija je sporna, ona je zapravo informisala o... -
- E sada druga stvar, nije mi jasno kako nisu uspjeli ovo podesiti jer postoje nivoi provjere koje sam baš sa ovim zadnjim doradama na odt generisanju napravio
Prvi dio je provjera template fajla
"template provjera":https://github.co... -
- dobro, meni je ostala nepoznanica gdje će biti ova lokacija, poslije je to ustanovljeno, uglavnom
*F18_TEMPLATE_LOCATION* sam stavio da bude -
- četiri dana da se nešto ovakvo podesi.
poražavajuće.
-
- testiraj pripremi
-
- ovo je iz meni nepoznatog razloga pretvoreno u rocket science
napravi da radi kako treba da radi
lokacija treba biti analogna podešenjima na windowsu:
/opt/knowhowERP/template -
-
- E sada jedini problem koji ovdje postoji je naziv fajla velikim slovima itd... na windows-u to neće predstavljati problem ali na ubuntu hoće, treba smisliti nešto.
-
- "commit":https://github.com/knowhow/F18_knowhow/commit/9aa3f4468ac7908b1809dccf283c6ad081f9ad82
napravio još par korekcija
import uspješno odrađen -
16.04.2012
-
- prebacio na mašinu
-
-
- Hernad mi je naglasio da git checkout određenog taga me ne izbaci sa određenog branch-a, tako da ako
zelimo ponovo -
- bringout@build32:~/dev/F18_knowhow$ git checkout 1.0.5
-
- bringout@build32:~/dev/F18_knowhow$ git pull
-
-
- Emir mi je rekao da radim po ovom wikiju:
http://redmine.bring.out.ba/projects/f18/wiki/F18_Ubuntu_build
-
- uraditi linux build, instalirati kod euroholz
tamam pmirza neka uradi ovo -
- puširao windows verziju
-
-
-
- puširao
http://code.google.com/p/knowhow-erp-f18/downloads/detail?name=f18_db_migrate_package_4.4.3.gz&can=2&q= -
- ok
-
- postoji publish.sh skripta koja gleda posljednji tag i kreira .gz za publikovanje
-
- http://knowhow-erp-f18.googlecode.com/files/f18_db_migrate_package_4.4.1.gz
-
- ne mogu naći gdje se ovo puširan na gcode
-
-
-
- U *dijelu 3* u *koloni 21* se nalazi ispisan ovaj doprinos
-
- Primjer specifikacije:
attachment:specifikacija_primjer.pdf -
- h1. Specifikacija uz isplatu plaća
Prilikom poziva specifikacije treba da postavimo sljedeći parametar: -
- h1. Napravimo jedan obračun
*Radnik 1*, podesio mu BF u polju K4, u polju K3 = 1 (koristit će 3%) a u formuli imam: (_I02 + _I03)
Evo radnikove kartice: -
- h2. 4) Šifrarnik radnika
U polje *K4* u šifrarniku radnika je potrebno unjeti
*BF*
a u polje *K3* šifru koeficijenta beneficiranog staža na osnovu šifrarnika koeficijenata, za radnike koji imaju pravo na ovaj dodatak.
_primjer:_ -
- Ono što je jako bitno, to je ovo *BENEF* u opisu doprinosa. To se ne smije ispustiti, jer program na osnovu toga zna koju će šifru doprinosa uzeti.
-
- h2. 2) Šifrarnik koeficijenata beneficiranog staža
U ovaj šifrarnik definišemo sljedeće stavke: -
- h1. Kako podesiti opciju ?
h2. 1) Parametri obračuna - formule
Bruto osnova za izračun doprinosa kod beneficiranih radnika može da odstupa od regularnog obračuna, tako recimo može biti da noćni rad, državni praznik ne ulaze u iznos za... -
- Opcija namjenjena evidentiranju i obračunu doprinosa za radnike za beneficiranim radnim stažom.
-
-
- vidjeti šta se na liniji 112 dešava ovo je izgleda error na error
-
-
-
- "ispravio":https://github.com/knowhow/F18_knowhow/commit/5121a6080fcf6ec30909562f29166a97d1df9f41
-
-
10:59 Podrška #27611: F18 1.0.4
- Odradio sam ubuntu32 build
git pull
git checkout 1.0.4
./build_relase.sh -
-
- sada brisanje radi kako treba
-
- "ovako":https://github.com/knowhow/F18_knowhow/blob/e0172c85c993fb65c5e3602a9e7a13e6a0bf949e/common/codes_browse.prg#L1996
-
- ?
-
- možemo jednostavno ispitivati sa hb_hhaskey() da li postoji "id" unutar hash matrice
-
- http://redmine.bring.out.ba/issues/27597#note-13
-
-
-
- ispravljeno par dana ranije u jednom od čišćenja
14.04.2012
-
- kada se pošalje fiskalni .txt zahtjev, kreće dugačko odbrojavanje od cca 200 sec
omogućiti da se kombinacijom tipki ova operacija prekine.
recimo <ESC> + "X"
namjerno stavljam kombinacija jer bi obični <esc> mogao izazvati nehotične ... -
-
- vidjeti šta bi ovdje moglo biti uzrok. očigledno se u nekoj situaciji desi beskonačna petlja
-
-
- #26262
-
-
- bug report #27607
-
- ovo je posebna tema pa ću otvoriti poseban bug report
-
- manifestacija je da nema partnera, a da račun sa popustom ako je partner = empty ignoriše popust ?!
-
- h2. fakt - ne valja fiskalni račun
međutim glavni problem je taj što fiskalni računi ne valjaju - popust se ne uračunava.
razlog je taj što se polje idpartner fakt_doks ne setuje (slično kao što se nije setovalo fakt_doks -> dindem) -
- "fin azuiraranje lOK bug, bug report sada šalje podatke na fmk.log":https://github.com/knowhow/F18_knowhow/commit/09d10494636586eaed18af54254259c5da8bde8c
-
-
-
-
- ovako u tabeli pripreme je vidljivo polje IDPARTNER, dok pravimo fakturu
znači formira se storno dokument i kada se pomjerimo malo udesno, prije polja broja računa itd... vidimo polje "partn" koje sadrži IDPARTNER zapis.
Praktično ... -
- pošto je fiskalni račun izdan zato što je polje partnera bilo prazno, da li je bolje onda napraviti ispravku pa onda staviti prazno za polje partnera ?
da li će se i u tom slučaju ignorisati popust ? -
- vjerovatno treba sa bugovitom verzijom
-
- treba uraditi istu stvar kao "ovdje":https://github.com/knowhow/F18_knowhow/commit/73bd8c11720155ca0060b3156205217993942ded#L1R409
samo je pitanje kako stornirati -
- postoji bug sa fiskalnim računima, ne izdaje se sa dobrim iznosom itd...
otkrili smo da se radi o polju fmk.fakt_doks -> idpartner
to polje je prazno -
- neznam kada dolazi ova radnica, pokušat ću je dobiti između 8-9 ja sam na putu p ću telefonski odrađivati
-
- ako ne može naći tabelu setuj a_dbf_rec["table"] = NIL. evo "koda":https://github.com/knowhow/F18_knowhow/blob/1.0.4/common/a_dbfs.prg#L176
-
- i ja i saša smo ovo uočili i ispravljali paralelno
riješeno u nver 1.0.4 -
- "rules" alias ne postoji nego "FMRULES"
na kraju isključio otvaranje te tabele -
- fakt pokušam ući iz menija u šifarnike robno poslovanje
-
-
- pošto smo otvorili mali milin ticketa povodom bugova u ver 1.0.2 - 1.0.4 otvoriću poseban za ovaj konačni release
-
-
13.04.2012
-
- "legacy izbacio, lagerlista fakt_pripr alias DNE debug":https://github.com/knowhow/F18_knowhow/commit/4c0160f6267be08d226955b6f840693f53314bad
-
- ovo bi ujutro trebalo u cago instalirati barem na radnoj stanici gdje će se vršiti fakturisanje
-
- http://knowhow-erp-f18.googlecode.com/files/F18_Windows_1.0.2.gz
-
-
-
-
- tagirano jeste, puširao na google windows verziju
-
- Ernad Husremović je napisao/la:
> h2. status synchro ids
> ...
ovo je ostalo neriješeno. vidjećemo da li treba -
- h2. kod ulaska proći kroz sve tabele !
najbolje je je da se kod ulaska napravi prolaz kroz sve tabele koje korisnik upotrebljava ...
e sada ako je to skupa operacije raditi je recimo prvi put o toku dana ... ali to su sada finese i... -
- h2. status synchro ids
synchro_ids operacije ne prijavljuju ništa. kada se duže radi te operacije mogu trajati.
recimo kod klijenta sam uočio 3500 promjena za sinhronizirati FAKT ... istina sa semaphores v1.0 ih treba biti puno ma... -
- h2. my_use exclusive ?
svojevremeno sam radi gather scatter i open errora na linuxu uveo da je default otvaranje share
Kasnije smo skontali da eksterni editor izaziva zauzeće dbf-ova ... što se rješava sa close all prije end print... -
- najviše me brine pack kod velikih baza od milion i kusur zapisa ... ali o tom po tom.
Sada ćemo se fokusirati na 200-300 hiljada tabele gdje lokalni pack ne znači puno -
- h2. pack dbf-ova
na radnim bazama klijenta uočio da postoji veliki broj brisanih zapisa.
napraviti da se kod ulaska uradi pakovanje ako broj deleted() slogova pređe recimo 10% ukupne veličine zapisa.
Ovo sve vjerovatno treba par... -
-
-
- "debug":https://github.com/knowhow/F18_knowhow/commit/73bd8c11720155ca0060b3156205217993942ded#L1R409
-
- u bring.out primjetili na štapi liste dokumenata da se za nove fakture nije setovala valuta = KM
bio je bug.
-
-
-
- h2. zašto pakovanje dbf-a ?
ako ima previše deleted zapisa u dbf-u onda su određene operacije značajno usporene (set filter npr) -
- h2. algoritam 2
radi prema postocima - broj zapisa deleted > 10% default
h2. algoritam 9
ako postoji ijedan zapis deleted() vrši se pakovanje -
- h2. algoritam 0
u .f18_config.ini trebamo staviti: -
- vagrant@f18-dev-1:~/github/F18_knowhow$ cat ~/.f18/.f18_config.ini
ako želimo podesiti da se briše za > 10 zapisa podešavamo -
- "default vrijednosti":https://github.com/knowhow/F18_knowhow/commit/cd2eb920d6793260d65c5d56b6da5b2fb235eb7b#L1R16
h2. algoritam 1
samo sam njega testirao - ok
vrši pakovanje tabele ako je > 700 zapisa deleted()
-
- "hocu_li_pack":https://github.com/knowhow/F18_knowhow/commit/cd2eb920d6793260d65c5d56b6da5b2fb235eb7b#L1R166
-
-
- ovo je urađeno
-
-
-
- "tag 1 umjesto ID":https://github.com/knowhow/F18_knowhow/commit/91f7280a55b3d409b218456cb8dc4965402b660c#L1R30
-
- vagrant@f18-dev-1:~/github/F18_knowhow$ git push origin --tags
-
- a ha
-
- ali uzrok nije identičan
-
- riješio
-
- pa to je identična greška kao i jučer
dbseek -
-
-
- Ernad Husremović je napisao/la:
> mirza nisi ovdje ništa sam mogao riješiti, testirati ?
> ...
Misliš na ovaj "odt_report.prg":https://github.com/knowhow/F18_knowhow/blob/master/common/f18_odt.prg
Koliko mogu vidjeti ovdje je sve OK... -
- mirza nisi ovdje ništa sam mogao riješiti, testirati ?
pokazao sam onaj source code, možeš li ga iščitati i iz njega skontati kako bi se ovo podesilo ?
odt_report.prg tako nekako ... nađi na github. stavi link na linije koje su re... -
- testirano je na mac-u
hoćemo da testiramo na linux-u
šta nam je bitno ovdje, parametri... -
-
-
- "commit":https://github.com/knowhow/F18_knowhow/commit/d40ccb72b2f249b998ef23de012398d89d2654bf
ld korekcija
fakt ugovori korekcija semafora -
-
-
- hernad
-
- Odradio build, opet error :(
-
- tagirao 0.9.98
-
- "sql_in za numerička polja":https://github.com/knowhow/F18_knowhow/commit/ab12afb2f54cc5210c841cdeaf0541ec9de00680
-
- dobro
-
- radi hernad na ovom
-
- bringout@ubuntu:~$ tail F18.log
-
-
-
-
- postavio ovaj exe kod željke, ulazak prošao bez problema
-
- verzija piše 0.9.97 u ovom exe što si stavio, da je zapakujem kao 0.9.98 ?
-
- vsasa neka zapakuje kao verziju posljednju to je 0.9.98
-
-
- u build.sh je podešen working dir .h
to je razlog ... saću staviti execut pa neka ga željka instalira drito sa ticketa
-
- da
-
- radi li ti build.sh obični ?
-
- ne, ne dobijem, gcc izbaci identičnu grešku
hm, ja na sesiji nisam instalirao zadnju verziju f18_serviser sa mingw itd... možda je to uzrok ? -
- jesi li dobio F18.exe
taj dio pakovanja radi samo na mac-u ali ono najbitnije build bi trebao biti ok -
- gore vidim errore kod build-a to je već problem
-
- taj zadnji dio skripte je nebitan.
bitno je da se napravi F18 exe -
- kada pokrenem build_release.sh skriptu dobijam ovo:
-
-
- dupli
-
-
-
- Saša Vranić je napisao/la:
> znači, ostanu još set_a_dbfs podešenja za
> ...
ok to nam sada nije bitno -
- znači, ostanu još set_a_dbfs podešenja za
* virm
* rnal
* mat
-
- izbacio p_kif, p_kuf i kreiranje tabela itd...
također sredio kreiranje tabela kalk, fin
"commit":https://github.com/knowhow/F18_knowhow/commit/a275de7d4f161e372a4972e016781911651b4a8d
-
- na veznom tiketu sam gledao tabele FIN (kuf, kif), praktično se uopšte ne koriste, postoji samo kao šifarnik definisano
*P_KIF(), P_KUF()* i to je to
-
- otvorio aktivnost za ubacivanje tabela koje fale #27581
-
- konkretno kod fin-a imamo zbrku
neke su tabele ostale da se kreiraju i u "t_fin_db.prg":https://github.com/knowhow/F18_knowhow/blob/fd4a56596165ab034bdd5f7d79ec765dfb15602d/fin/t_fin_db.prg#L219
a vidim da se unutar šifranika već k... -
- ima nekih tabela koje su ostale temporary a trebaju na semafore, kao što su fond, funk u fin-u
-
- "os, cre_all_os, set_a_dbf_os":https://github.com/knowhow/F18_knowhow/commit/1b446cd17f8f0c32b3ee9a93ab33725995ddcfa6
-
- "epdv, cre_all_epdv":https://github.com/knowhow/F18_knowhow/commit/787435eee5d9afc44974a0c2f18cc41104f9ce0a
-
- "commit":https://github.com/knowhow/F18_knowhow/commit/8569511f37e258346ffafa6b538badc2f7cf095b
u epdv-u dodao još šta je njegovo, također u fin-u ukinuo FIN_PRIPRRP (to nije potrebno)
-
- da
-
- POS je urađen ?
-
- Prvo sam napravio odvojen prg za temporary tabele koje se dijele između modula, to su ove neke temp itd...
"commit":https://github.com/knowhow/F18_knowhow/commit/9b0d45b625453857dc2abaaac48c6ea969b0fe66 -
- Ostalo još
* OS/SII
* ePDV
* VIRM
* RNAL -
-
- u 4.4.1
-
- verzija cago_test izgleda nije bila ok
-
- Saša Vranić je napisao/la:
> e to mi nije jasno, jer to postoji
u kojoj ver db-a je to pos_dokspf definisano ? -
- meni to ne pravi problem
-
- e to mi nije jasno, jer to postoji
-
- sljedeće mi prijavljuje: semapohres_pos_dokspf
-
- takođe i u cre_sifrarnici_1
-
- Saša Vranić je napisao/la:
> kad smo kod tokval.dbf tabele, nigdje ne vidjeh da se koristi
misliš u aplikaciji se nigdje ne koristi ? znači set_a_dbf treba izbaciti -
- isto mi traži i semapohres_pos_dokspf
-
- kad smo kod tokval.dbf tabele, nigdje ne vidjeh da se koristi
-
- ukinuo tu provjeru polja...
"commit":https://github.com/knowhow/F18_knowhow/commit/fd4a56596165ab034bdd5f7d79ec765dfb15602d
-
- ovo poljexists() ispitivanje je viška
https://github.com/knowhow/F18_knowhow/blob/master/common/cre_sifrarnici_1.prg#L147 -
- definisana kao non-temp tabela ali nema je u semaforima
-
-
-
- dodao u semafore tabele
* objekti
* parek
* buiz
* fond
* funk
* ulimit -
- a ha, VPRIH koristi tabela KUF, KIF u fin-u
-
- VPRIH također fin koristi
u VIRM-u imamo VRPRIH, ali ovo je drugo -
- FIN ima ove tabele KUF, KIF da li se to koristi ?
Šta se uopšte koristi od ovoga ? -
- recimo, misterija je šta su sljedeće tabele u FIN-u ?
* PAREK
* BUIZ
* BBKLAS
* VKSG
* KIF
* KUF
* ULIMIT -
- funk, fond finansije fale
-
-
-
- poispravljao sam i loše pozive alijasa
-
-
12.04.2012
-
- izgleda da nisi tagirao
-
-
- nemoj ovu verziju praviti, svakako nije dobra
-
-
- puširao na gcode windows verziju
-
-
-
- ispravio i testirao kod sebe na sesiji, sada je ok
-
- "commit":https://github.com/knowhow/F18_knowhow/commit/a4ee2c79e2a0d8fe7c63ca21fed6f09ead8adf59
-
- kako je ovdje urađeno https://github.com/knowhow/F18_knowhow/blob/master/common/semaphores.prg#L273
-
- https://github.com/knowhow/F18_knowhow/blob/semaphores_v1.0/common/semaphores.prg#L372
if (_version > -1) .and. ...) treba dodati -
- i gledam, stvarno nema partn.cdx fajla
-
- pa to ponavlja za svaku tabelu prilikom kreiranja
-
- recimo:
-
-
-
- "commit":https://github.com/knowhow/F18_knowhow/commit/9c96d7980e06b117e36e2eb259c3680bd911478c
ovdje bili stari pozivi funkcija, ispravio, sada radi -
-
- "fmk paket 4.4.2":https://github.com/knowhow/fmk/commit/a2a047fec40b27b26402a654e43435bfc2dd0939
dodao promjenu dužine polja -
- otkud 40, znači treba promjeniti na 250 također ili gledam polje opis-a je tipa *text*, možda i naziv staviti na ovaj tip
-
- polje u dbf tabeli je dužine 250
"referenca":https://github.com/knowhow/F18_knowhow/blob/6b3774c958fca7c128f7ee6fe42c794636ebb17f/common/cre_roba.prg#L24
dužina naziva u sql tabeli je 40 ?!??
"referenca":https://github.com/know... -
-
- ne bih ovo portirao, tamo ću drugačije riješiti
-
- svakako ostaviti otvoren dok se problem u master branchu ne riješi
-
- hm ne možeš zatvoriti treba ovo odmah backportirati u master branch
-
-
- "commit":https://github.com/knowhow/F18_knowhow/commit/83416dadd2e6e4e3c4b4b284c095eeb81c0c0f9b
napravio korekciju, sada izvještaj radi -
- da, kreira se neka temp tabela mtemp.dbf pa je ne može naći...
-
-
- Treba testirati jedan import sada iz FMK TOPS-a, pa eventualno poispravljati još greške
-
- Jutros nastavio na ubuntu sesiji da radim development, pa sam prvo podešavao git (user i email) itd... pa ssh key
Doradio i opciju importa tops prenosa u kalk
"commit":https://github.com/knowhow/F18_knowhow/commit/1c9217707d0137d... -
- riješio u F18_3rd ubuntu 1.2.0
-
- rješavati na veznom ticketu
-
- "commit":https://github.com/knowhow/F18_knowhow/commit/fb28087c0e8e6aa9d446a40fdea3b83ea5782498
uklonio -
- zar nisam ?
-
-
- ovo bi za euroholz moglo zatrebati
-
-
-
- Puširao Ubuntu i686 verziju na gcode
-
- "CHANGELOG":https://github.com/knowhow/F18_knowhow/blob/49167e243e46bbec2f4e1a3385e3c31cabf44de3/CHANGELOG.md
-
-
- bjasko je želio provjeriti samo KALK i dobio je grešku. ali je šifarnike sigurno ostavio aktivnim za provjeru
-
- ne, nego je unutar provjere šifrarnika i provjera tabele RADN (ld-a) a pošto LD nije portiran ne zna da ga otvori
Ako isključim šifrarnik i ostavim samo fin, kalk, fakt, pos, to onda radi -
- ništa nije u redu, problem sa gADBFs
treba uraditi my_use_temp ili nešto slično
-
- a šta nije ok
11.04.2012
-
-
- Izmjeniti F18_update skriptu, F18 ide na lokaciju /opt/knowhowERP/bin
i wget dbf2pg u /opt/knowhowERP/util -
-
- ovo se sada testira tako da funkcioniše samo sa TOPS FMK ili .... ?
-
- E, sada treba testirati prenos podataka u POS iz ovog direktorija...
-
- Sada su fajlovi koji idu od KALK-a prema TOPS-u
kt140201, kt140202 -
- "commit":https://github.com/knowhow/F18_knowhow/commit/39569d99a7b46dbe8f29a523bbd04fe44425693a
još ispravki, testirao sam prenos KALK->TOPS, sada se generiše datoteka prenosa na zadanoj lokaciji po prodajnim mjestima.
Također sam ... -
- import fajlova u tops sređen, promjenjeni i nazivi baznih funkcija
*gentops -> kalk_generisi_tops_dokumente()*
*kalk2pos -> pos_preuzmi_iz_kalk()*
"commit":https://github.com/knowhow/F18_knowhow/commit/6633e04ce05cd6cd68f26865f3... -
- inače ove tabele se kreiraju u runtime-u, tj. prilikom pokretanja opcije, ali sada treba pogledati ovu opciju import-a kod TOPS-a pa iskoristiti istu funkciju za kreiranje kontra tabele ako je ista
-
- to i uradio
-
- kao što smo i kod F18 LD-a primjenili - sva polja koja se koriste su otvorena i predviđena
-
- Saša Vranić je napisao/la:
> nisam je testirao, samo ispisao... treba testirati
> ...
u F18 imamo jednu jedinstvenu strukturu tabela. To treba primjeniti i ovdje.
Zato ako je potrebno u FMK/TOPS napraviti neki modstru da bi se proši... -
- nisam je testirao, samo ispisao... treba testirati
također, ovdje su bitni pojedini parametri i tabela koncij (koja se u jednoj varijanti koristi)
čak razmišljam da ne bi bilo loše da se napravi samo jedna varijanta, a to je ona sa... -
- Opcija KALK->TOPS (prenos podataka za TOPS)
"velika borba":https://github.com/knowhow/F18_knowhow/commit/77bbbf61e25940d18d0e4c8137d413385bfe75ec
ali konačno funkcija na nešto liči...
Također su bile dvije identične funkcije
... -
-
-
- kod formiranja početnog stanja u pripremi bio problem
"commit":https://github.com/knowhow/F18_knowhow/commit/641c2786ca5a6ead2d2af9a2a52d237e341b6f51 -
- E sada je ok, inače sam non-stop dobijao full sinhro nakon ažuriranja
-
- funkcija o_kalk_za_azuriranje ukinuo semafore sa off/on funkcijama
"commit":https://github.com/knowhow/F18_knowhow/commit/f636695a3e649ccd84408ebef1c0b4993793417e -
- testiram ažuriranje, povrat - ok
-
- uklonio kalk_Semaphores.prg
"commit":https://github.com/knowhow/F18_knowhow/commit/86f8c4cd86f3805cc3da36b12254a79df6661835 -
- Kalk ažuriranje u verziji semafora 1.1
"commit":https://github.com/knowhow/F18_knowhow/commit/27bbb8dcc3e1c8b575dcc7dcfda98c6ce404d744
također ispravio i povrate dokumenta
"commit":https://github.com/knowhow/F18_knowhow/commit/9... -
10.04.2012
-
- završeno
-
- prebacio sve na my_use_temp funkcije
"commit":https://github.com/knowhow/F18_knowhow/commit/75a4e3dcca5e78cb96c8f69d4d051b9bf665d7b5 -
- fin, također male korekcije napravio i radi import/export podataka
-
- ostalo još KALK prebaciti otvaranje tabela na my_use_temp, kao i FIN, ostalo još FIN testirati prenose
-
- bila se potrkala jedna transakcija viška, pa sam to ispravio
"commit":https://github.com/knowhow/F18_knowhow/commit/30453b8a497145a7aa4a7b03edb00f0cd06313ce -
- import konačno proradio kako treba
"commit":https://github.com/knowhow/F18_knowhow/commit/f7eb7903bb7135a84b6658a79a12ef6ea133d50b -
- "commit":https://github.com/knowhow/F18_knowhow/commit/7fdb334e196df082166fa445745de4ab6bd3f846
-
- da, da, to upravo stavljam, vidim da sam zaboravio
-
- Saša Vranić je napisao/la:
> sada import također radi ali mi se dešava jedna čudna stvar, non stop mi radi fakt_fakt full sinhro algoritam
nije čudna :)
trebaš da staviš -
- sada import također radi ali mi se dešava jedna čudna stvar, non stop mi radi fakt_fakt full sinhro algoritam
-
- kako se nakon kreiranja zip fajla uvijek brišu fajlovi, nikada ga nisam vidio
-
- Da čovjek ne povjeruje !
"commit":https://github.com/knowhow/F18_knowhow/commit/c29ec837006309e942ba6248c3c22bba692486ed
fpt fajl treba uključiti u zip, eto razloga -
- "COPY STRUCTURE EXTENDED":http://www.harbour-project.org/doc/copystructureextended.htm
-
- hm, da, sad kada sam otvorio tabelu e_fakt, stoji *opis C(120)*
tabele se kreiraju sa opcijom kreiranja po strukturi na osnovu ključne tabele
"ovako":https://github.com/knowhow/F18_knowhow/blob/1c237842cf3221f7422ad0984734045f3e06b... -
- E pa stvarno...
-
- aaaaa, sad znam šta je !!!
Ne može da otvori fakt tabelu!
Ostale otvara, premjestio sam da se fakt otvori poslije...
da nisu ona FPT polja itd... -
- F18.log
-
- I što je najžalosnije evo kalk radi !???
-
- Znači, nakon raspakivanja sam sa eksternim editorom otvorio e_fakt.dbf i on radi, napunjen je podacima, normalno otvaram sve tabele
Čudno mi je to, što mi je opcija zapravo radila odmah sa početka i to export podataka, dok su još staj... -
- importdbf je direktorij. zašto je problem što je on otvoren ?
čim se neko nalazi u direktoriju recimo uđeš sa terminalom u taj direktorij dobijaš zauzeće. to ne bi trebalo predstavljati nikakav problem -
- to je neko vraćanje statusa (naziva) direktorija, ili tako nešto
-
- ma nije, i kada nema komande ista stvar stoji
šta je cwd ? -
- stavio brakepoint prije otvaranja tebela
bringouts-MacBook:cago_2011 bringout$ lsof | grep dbf -
- to je ovaj tiket #27234
-
- sa lsof sam ja debugirao start print / end print bug. postoje moje bilješke
-
- > Da nisu sporne ove funkcije zip, unzip
moguće da ih ne koristiš kako treba, tako da fajlovi ostaju otvoreni i nakon što je to potrebno -
- Saša Vranić je napisao/la:
> ma čuj, gore sam napisao, opcija exporta ih fino otvori i upiše podatke u tmp tabele, što znači da my_use_tmp() radi kako treba.
> ...
to ćeš jednostavno utvrditi sa lsof funkcijom
stavi bug point nakon ... -
- ma čuj, gore sam napisao, opcija exporta ih fino otvori i upiše podatke u tmp tabele, što znači da my_use_tmp() radi kako treba.
Sada sam na windows-u ovo isto pozvao.
Prvo kod exporta sam primjetio da mi je izbacio grešku kod pako... -
- ili ovo:
-
- a šta ako pokušaš otvoriti
ako staviš alias = NIL šta dobiješ ?
ako staviš alias = _dbf_name ? šta dobiješ
-
- greška je:
-
- > Import i dalje prijavljuje OPEN ERROR !!!
stavi detaljnije info, možda ti mogu pomoći -
- "korekcije":https://github.com/knowhow/F18_knowhow/commit/1c237842cf3221f7422ad0984734045f3e06bf47
hm, interesantno je sljedeće...
export podataka, iako koristi istu funkciju za otvaranje export tabela - radi !
Import i dalje pr... -
- Ispravio kod
"otvaranje tabela":https://github.com/knowhow/F18_knowhow/blob/bd27fc49eae152497dcadb48e725929724adfa9b/fakt/fakt_udaljena_razmjena.prg#L852
međutim dobijam OPEN ERROR opet
dobra je putanja do fajla
-
- ova tabela se u slučaju koirštenja my_use_temp *NE MORA* onda dodavati u set_a_fakt_temp( ... )
-
- _dbf_name := "e_fakt"
-
- praktično radi open dbf tabele apsolutno bez korištenja semafora.
Međutim, vrlo je bitno da se kod korištenja ne koriste radna područja WORKAREA koje koriste tabele pod semaforima.
Zato nemoj stavljati brojeve u aplikativni kod
... -
- Saša Vranić je napisao/la:
> ma ja, samo stavi i parametar za table_path
uveo my_use_temp:
"my_use_temp ( alias, full path + ime_tabele, new_area, excl ) ":https://github.com/knowhow/F18_knowhow/commit/9335b3eb3a028aae36485db681ef7f47... -
- ma ja, samo stavi i parametar za table_path
-
- ma da my_use to ne radi
treba napraviti my_use_temp koja se neće uopšte baviti semaforima, napraviću sada -
- mislim na "ovu sekvencu":https://github.com/knowhow/F18_knowhow/blob/0217a0fa2b73aa5bf462b817be331768dceab555/common/my_use.prg#L120
-
- ma ja, zato što u my_use funkciji u sekvenci na kraju stoji
-
- hm... probao sam ovo na razne načine ali jednostavno ne može se otvoriti fajl koji nije unutar my_home()
nemam pojma kako definisati to ?
Dobijam grešku -
- eto vidiš... kažem ti ja da pišem
-
- moram praktično setovati sa
set_a_dbf_temp() ove tabele
i onda koristiti my_use
-
- ovo treba ispraviti
-
- Ja ja, o tome upravo krenuo da pišem
-
- ovako trebaš imati na umu da je sada worakrea (F_KALK, F_VAKO, F_NAKO) bitno da bude jedinstveno
ako trebaš u nestandardnom području otvarati dbf onda je najbolje da to navedeš u my_use
ovako nekako sigurno radi -
- Inače ovo je radilo, tj. radi kod modula KALK u staroj verziji F18...
-
- hm, interesantno je da kod importa dobijam grešku
-
- "commit":https://github.com/knowhow/F18_knowhow/commit/eca76e7371738d6226994c00ce95b347bb8bd629
-
- h2. FAKT -> FAKT (export dokumenata)
Testirao sada export dokumenta, ok, za neki period mi je prebacio 7 dokumenata kako i jeste u pomoćne tabele pa napravio zip fajl. -
- sada ok
-
- E sad sam pustio, sada ide, izgleda da je sad ok, vidjet ćemo do kraja sinhronizacije
-
-
- "na početku ovaj update semafora treba preskočiti":https://github.com/knowhow/F18_knowhow/commit/8cdcb7b215e3a7730e396db9495d6ef60ed0a499
-
-
- isječak iz log-a na kraju
-
- i dalje isti problem
09.04.2012
-
-
- kada pokušam da pokrenem master verziju F18 dobijam poruke:
-
- Eh, sada sam razdvojio sve ove funkcije, sada treba samo osposobiti opcije prenosa
-
- "fin, udaljena razmjena":https://github.com/knowhow/F18_knowhow/commit/79fec94806186c9ce649c7b4865d244281af941f
-
- "commit":https://github.com/knowhow/F18_knowhow/commit/9fa1de2d5b507f1df05758e9e9770efe42e5abf4
razdvojio funkcije razmjene, otvorio funkcije za fakt -
- Util funkcije se mogu sigurno prebaciti u common dio, pošto će sada i ovi moduli djeliti iste... recimo ono decompres_files ili compress_files itd...
-
- Ovdje u principu imamo skroz malo modifikacija, pošto samo džonimo funkciju KALK-a
"kalk udaljena razmjena":https://github.com/knowhow/F18_knowhow/blob/1e8f52f0415ba3a80abb37ac6129dafc58228ecd/kalk/kalk_udaljena_razmjena.prg -
- Dakle, to će biti to što se tiče razmjene podataka između identičnih modula FAKT->FAKT, FIN->FIN itd...
-
- Za KALK već napravljena super opcija #26695
Treba identično napraviti i za FIN i FAKT. -
-
- "otvori dbf ako je potreban synchro":https://github.com/knowhow/F18_knowhow/commit/9476c596262801b2205a0034b16a9785c48ea34c#L1R262
-
-
- Sada kod starta imam grešku:
-
-
- Ovdje je bitna još jedna stvar, imamo sljedeće tipove razmjene sada:
* eksterna instalacija (razmjena između udaljenog TOPS i KALK)
* interna instalacija (razmjena između internog TOPS<->KALK) -
- testirao
-
- da, testiraj još jednom kod sebe windows build - ažuriranje na testnoj bazi FIN, KALK, FAKT i nosi.
-
- jel ovo sada spremno za isporuku ?
07.04.2012
-
- Ernad Husremović je napisao/la:
> 3) izbrisati debug sekvence
urađeno -
- Ernad Husremović je napisao/la:
> 1) ovo isto close/open uraditi u azur_kalk, azur_fin, azur_ld, azur_epdv ...
uradio fin, kalk, fakt
> ...
uradio
-
- https://github.com/knowhow/F18_knowhow/blob/0.9.81/CHANGELOG.md
-
- uradio backport set_all_gvars #27467 iz master brancha
-
- 3) izbrisati debug sekvence
-
- h2. šta je ostalo za isporuku korisniku
1) ovo isto close/open uraditi u azur_kalk, azur_fin, azur_ld, azur_epdv ...
2) u update_rec_server_and_dbf, delete_rec_server_and_dbf dodati lock/free semaphores -
- naravno ako su podfunkcije neke utility funkcije koje samo obavljaju dio posla za glavnu funkciju, ovo nema smisla, ali ako su podfunkcije samostalne cjeline koje se pri tome (potencijalno) koriste više puta, treba ogranizovati otvaranje...
-
- h2. dobra praksa, gledajući funkcije i podfunkcije
u kod imamo ovo -
- h2. pozitivna praksa - pojedinačne funkcije trebaju biti zatvorene cijeline u smislu otvaranja dbf-ova
inače treba prakticirati da se u pojedinčanim funkcijama kako je to urađeno ovdje u fakt_azur_dbf vrši otvaranje/zatvaranje dbf tabel... -
- h2. ostale potrebne promjene
s obzirom da se nakon sinhronizacije uvijek radi zatvaranje dbf tabela, treba u svim sekvencama ažuriranja dodati close all pa open all tabele, kako je to urađeno ovdje u "fakt_azur_dbf":https://github.com... -
- treba imati na umu da radim na legacy semaphores version ... to je u semaphores v1.1 (master branch) drugačije - jednostanije rješen (gaDBFs je skroz izbačeno).
kako god bilo ovo treba isto uraditi i na master branchu ovaj bug i tamo ... -
- što se tiče bloka koda "EVAL ( ... gaDBFs 4 ... ) to je praktično kod tabele fakt izvršenje update-a tabele sa servera po ids algoritmu":https://github.com/knowhow/F18_knowhow/blob/0e3cca6b35b1c46316d8d509725920d4bfbb26f1/fakt/fakt_sema...
-
- h2. debug
ovo je "ključni kod":https://github.com/knowhow/F18_knowhow/commit/0e3cca6b35b1c46316d8d509725920d4bfbb26f1#L1R367
šta se dešava ovdje ?
*PRIJE* nego se izvrši update semafora dešava se provjera stanja semafora. ako je... -
- h2. uzrok
uočavam da je uzrok sljedeći
ovo je proces ažuriranja (fokusiraću se na fakt tabelu, ostale su nebitne za demonstraciju problema)
# table fakt lock
# push fakt dokument na server
# push id-ove na semaphore fakt
# update sema... -
- h2. priprema
"uvodim pametniju funkciju u kojoj u jednom selectu "uzimam i version i last_version semafora određene tabele":https://github.com/knowhow/F18_knowhow/commit/0e3cca6b35b1c46316d8d509725920d4bfbb26f1#L1R276
-
- test1 prvi dokument se ažurira usporeno npr 0200
test2 ulazi u lock - pojavljuje se fakt_fakt lock ...
test2 user ažurira 0201
i to je to !
test1 ima oba dokumenta, ali test2 je "progutao" 0200 dokument u cijelini !
zašt... -
- kako ovo reproducirati
dodajem sleep statement "da vještački usporim ažuriranje":https://github.com/knowhow/F18_knowhow/commit/0e3cca6b35b1c46316d8d509725920d4bfbb26f1#L2R729
onda ovu debug verziju pokrećem na testnoj linux sesij... -
- h2. reprodukcija buga
user1 je unio dokument "00100"
bug se manifestuje tako što se u logu usera (user2) stavke pojavljuje lock_table ... unlock ...
nakon toga u logu se vide stavke vezane za ažuriranje dokumenta koji je unosio ... -
-
- ispravka se odnosi na prije azur_dbf - close all
-
- mislim da je najbolje ovo sve uraditi samo u master branch-u ... ovo nisu multi-user kritični moduli
-
06.04.2012
-
- znači prije poziva reporta je potrebno sve dbf-ove zatvoriti ako to već nije slučaj. To je normalno ponašanje aplikacije a ne ono što sada imamo na mnogim mjestima.
-
- h2. close all end print - zatvori pa otvori prije end print
vidim da je vsasa pogešno počeo stavljati ove ispravke vezane za zatvaranje svih tabela prije end print
1) ovo se treba implementairati bez ikakvih ifdef UNIX - to treba biti... -
- pošto ovo ne znam razjasniti ostavio sam u source kodu ove komentare privpremeno.
-
- h2. zbrka fisk_rn, fisk_st
ovo mi je do kraja nejasno i nelogično. znam da je vsasa fisc_st polje dodavao da je prije toga nešto žonglirao unutar fisc_rn polja ... ali je ovo u neke table dodao u neke nije ... skroz nejasno.
Sada j... -
- ovo treba uraditi i za druge module
-
- uh KALK je u skroz lošem stanju ...
ne razumijem ni kako to uopšte radi u semaphores v1.0
recimo morao sam u f18_init dodati
setovanje globalnih varijabli po modulima da bih recimo imao varijablu "ZAOKRUZENJE" koje mi opcija "k... -
-
-
- Nakon štampanja obrasca potrebno je u koloni 4 zaokružiti nešto od predviđenog, tj. ono za šta se obrazac odnosi.
Recimo, radnik treba da se penzioniše, ili se za nekog radnika uplaćuju doprinosi samo itd... -
- Evo kako obrazac izgleda
attachment:pmip_gen.odt (odt varijanta obrasca)
attachment:pmip_gen.pdf (pdf varijanta obrasca) -
- Obrazac se pokreće sa standarnog menija generisanja MIP obrasca:
*4. izvještaji -> M. mjesečni obrazac MIP-1023*
Ako na uslovima izvještaja MIP zadamo radnika u polju radnika tada ćemo dobiti štampanu verziju PMIP obrasca. U slučaj... -
- Obrazac namjenjen za prikaz podataka pojedinog radnika na mjesečnom nivou.
Obrazac sadrži sve podatke obrasca MIP, samo što je fokusiran na jednog radnika, zato mu je i naziv PMIP (pojedinačni MIP obrazac)
-
-
-
- h2. Kontrolisanje izvještaja
Da bi kontrolisali ispravnost izvještaja jednostavno pozivamo
*4. izvještaji -> 3. pregledi -> 2a. pregled plata za više mjeseci*
gdje zadajemo ove uslove:
!js_chk_01.png!
datumski period i red... -
- Primjer obrazaca:
attachment:js-3400_gen.odt (odt varijanta)
attachment:js-3400_gen.pdf (pdf varijanta) -
- Gdje je obavezno setovati sljedeće:
* period od - do, uvijek ide za godinu dana (sem ako nije specifično drugačije predviđeno)
* obračun = 1, sem ako postoji više obračuna (onda se ostavlja prazno)
* definicija doprinosa (ostaje po ... -
- Obrazac se povlači sa sljedećeg menija:
*4. izvještaji -> J. prijave doprinosa (JS-3400)*
nakon pokretanja dobijamo sljedeće uslove:
!js_opt_01.png! -
- jedno 10-ti put ispravljam ovo f.
-
- Obrazac urađen po konceptu obrazaca MIP, OLP, GIP, dakle trenutno se može samo štampati putem Libre Office-a.
-
- "Kod" se nalazi "ovdje":https://github.com/knowhow/F18_knowhow/blob/a6db22ba75a7e29abdecd0e957c77365dbc847db/ld/ld_js3400_obrazac.prg
-
- Rok za predaju je 30.04 naredne godine za prethodnu.
-
- Dakle, riječ je o obrascu koji daje informacije o godišnjim obračunatim doprinosima po radnicima:
* doprinos PIO
* doprinos zdravstvo
* doprinos nezaposlenost
Obrazac se radi na godišnjem nivou -
-
- semaphores v1.1
-
-
- 1) unos KALK ostao iz FMK
2) slučajno nisam unio FCJ kod 10-ke dokumenta pa je program poludio
prvo je izbacio zero divisor a onda nastavio do besvjesti sa errorima, zadnji je: -
-
- odradio ubuntu 32 build
-
05.04.2012
-
-
- puširao sam windows verziju na gcode
-
- neću još raditi novi build, bit će još korekcija
-
-
- Testirano i u fmk radi kao i u F18
-
- obrazac pmip postavljen na klijentske fajlove kao i obrazac js
-
- "commit":https://github.com/bringout-fmk/ld/commit/f02c7c9b9c7583c803b3567ef35f1a4bef6b15c2
-
- portirao u FMK
-
- http://redmine.bring.out.ba/projects/klijenti/files
-
- postavio obrasce na klijentski dio fajlova za download
-
-
- ispravio pojedine stvari na obrascu, iznose koji ne mogu stati, redne brojeve itd...
-
- Testirao i u FMK, ok
-
- Sada obrazac radi i u FMK također.
-
- Dobro, test je dao dobar rezultat
-
- testiranje obrasca #27433
-
- portiranje obrasca u fmk
"commit":https://github.com/bringout-fmk/ld/commit/37d287b0a824f40cfaa603322666f8060f2c89ad
ovdje moram parametre vratiti u PARAMS tabelu....
"commit":https://github.com/bringout-fmk/ld/commit/6e163206f... -
- napomena:
Mora se imati na umu da lock tabela mora minimalno trajati !
Ovo nije dobar kod -
- pogledati ove funkcije. sumnjam na to da se u multikorisničkom režimu dešavaju problemi
vjerovatno treba zaključati tabele koje se kod prenosa koriste.
ja sam juče kod rada na semaphore v1.1 uočio da update_server_and_dbf and delet... -
-
04.04.2012
-
- ostalo srediti šifarnike robe
-
- ObjDbEdit - tabela liste dokumenata sredio da napokon liči na nešto
"koriste se PADR i BROWSE_COL_SEP ":https://github.com/knowhow/F18_knowhow/blob/cac696e3cbef2261845db37cbe2e824f487c385c/fakt/fakt_tabela_lista_dokumenata.prg#L67
-
- "fakt_povrat sređen":https://github.com/knowhow/F18_knowhow/blob/4b685c9902d4c4acf2fb780d2dadb892666c8f94/fakt/fakt_povrat.prg#L412
nisam stavio lock/free semapores jer sada lock/free postoji unutar delede_rec_server_and_dbf funkcije -
- u tabeli pregledu dokumenata koja se najčešće koristi dodao kod svake komande
"refres_fakt_tbls":https://github.com/knowhow/F18_knowhow/blob/4b685c9902d4c4acf2fb780d2dadb892666c8f94/fakt/fakt_pregled_dokumenata.prg#L786
ovim se ob... -
- delete and update_rec_server_and_dbf dodao "lock_semaphore lock/free sekvencu":https://github.com/knowhow/F18_knowhow/blob/4b685c9902d4c4acf2fb780d2dadb892666c8f94/common/f18_db.prg#L51
-
- "fakt_azur_sql":https://github.com/knowhow/F18_knowhow/blob/cac696e3cbef2261845db37cbe2e824f487c385c/fakt/fakt_azuriranje.prg#L256
po uzoru na fin_azur_sql
-
- "fakt_azur_dbf totalni refactoring:":https://github.com/knowhow/F18_knowhow/blob/cac696e3cbef2261845db37cbe2e824f487c385c/fakt/fakt_azuriranje.prg#L256
predhodna verzija je bila loše napisana
vidi se kako je samo mijenjan fmk kod što j... -
- omogućio "my_use (fakt_pripr, fakt_fakt, .f. ) ":https://github.com/knowhow/F18_knowhow/commit/cac696e3cbef2261845db37cbe2e824f487c385c#L1R39
gdje se otvara fakt_fakt tabela sa aliasom fakt_pripr -
- funkciju update_from_server ... izbacio jer je bila skoro identična sa "sql_table_update":https://github.com/knowhow/F18_knowhow/commit/cac696e3cbef2261845db37cbe2e824f487c385c#L1R39
-
-
-
-
- napravio upgrade openvpn-a, podesio autokonekciju faruk.ovpn
-
-
-
- a ostali problemi zbog diskprostora koji sam podigao
-
- problem sa pristupom je bio zbog loklane fbde zone pa sam napravio
root@ns-lan-1:/etc/bind# grep webdisk * -
-
- ostalo portirati u FMK
-
- Znači da ne bude zabune ovaj obrazac je također *mjesečni* kako i stoji u nazivu i postoji fiksno jedna kolona tj. za mjesec za koji se poziva.
Čisto da ne bi neko pričao kako treba da izlista sve obračune jednog radnika po mjesecima ... -
- znači logika je ova:
ako na uslovima MIP obrasca zadamo radnika onda se uvijek štampa PMIP obrazac i ne postoji export podataka nego ide obavezno ODT štampa
i to je to
Korigovao postojeći MIP obrazac i napravio PMIP odt obrazac -
- "commit":https://github.com/knowhow/F18_knowhow/commit/70812d840c57a7e48760bdf442a8a5a6cb611274
obrazac PMIP stavljen u funkciju -
- ostalo provjeriti podatke izvještaja i portirati ga u FMK
-
- ali hajde de, sad za sada nek to stoji...
-
- Računanje početka i prestanka osiguranja
"commit":https://github.com/knowhow/F18_knowhow/commit/58c019434b48534ff48b6b4fd44f4f71504cb555
to je jedan jako blentav algoritam :)
Znači, podaci iz pomoćne tabele su poredani po mjesec... -
- hm...
-
- trebalo bi biti to
-
- mada mi iskreno nije jasno šta je ovo na obrascu vezano za osiguranje
kaže
* datum početka osiguranja ( mjesec / dan )
* datum kraja osiguranja ( mjesec / dan )
odnosi se na godinu za koju se povlači izvještaj.
E sad pretpos... -
- Iskoristio sam polja
* radn->hiredfrom
* radn->hiredto
kao podatak osiguranja
Ta polja su se koristila kod DP obrasca i praktično više ničem ne služe.
-
- ld_js_1.odt treba postaviti u /knowhowERP/template lokaciju
-
- Eh, to bi bilo otprilike to...
-
- a ha, datum osiguranja, dtos umjesto dtoc kod provjere
"commit":https://github.com/knowhow/F18_knowhow/commit/e4320c7af4d5a2d5dd9d9f8f30ebd1c56bdd5206 -
- "commit":https://github.com/knowhow/F18_knowhow/commit/b0865dd26eaee9e86d9e0c659f050f9bbf12c254
finaliziranje izvještaja -
- naravno, treba vidjeti još za ova nepostojeća polja šta da uradim i šta da iskoristim itd...
-
- xml fajl se generiše ok izgleda, sada samo fali odt fajl obrasca pa da vidimo...
-
- "commit":https://github.com/knowhow/F18_knowhow/commit/0059928f894757bfd4a4e6093a07820659639676
dodao novi prg i iskoristio izvještaj GIP koji mi daje identične podatke, samo je filter drugačiji...
-
- na pufbih nema nikakvih informacija o elektronskom podnošenju
-
- Također imamo i polje
* Uplaćeni doprinosi (ukupni)
kod nas to uvijek može biti total doprinosa jer u LD-u nemamo mogućnost setovanja koliko je uplaćeno a koliko ne. -
- Na obrascu postoje ova polja
* datum početka osigruanja
* datum prestanka osiguranja
za radnika, to generalno nemamo...
Imamo polje HIRED_FROM, HIRED_TO ali se to odnosi na zaposlenje. -
- interesuje me da li će se i ovaj obrazac predavati elektronski, to nisam nigdje vidio jer u gornjem desnom uglu stoji barkod
-
- Obrazac izvlači podatke o doprinosima
-
- kako i samo ime obrascu glasi ovo je godišnji obrazac, znači radimo ga za godinu dana, ali treba napraviti kao kod MIP obrasca datumski period od
*mjesec/godina* do *mjesec/godina*
ko zna kakvih će biti zahtjeva itd... i perioda -
-
-
-
- odradio ubuntu 32 build
-
-
- Puširao windows verziju
-
-
- ja sam u toku da osposobim fakt na master branchu
nakon toga treba one bugove koji su u fmk uočeni i ispravljeni backportirati
3 decimale, grupno ažuriranje i šta već sve -
-
-
-
- odradio
-
- odnosno konačni cilj
-
- u stvari možeš pošto ima masa onih transakcija pogrešnih ... ali ne diraj. kako god to je do sada slalo podatke na server.
svrha je da se sa postojećim stanjem riješi veliki problem koji kod korisnika postoji *odmah*.
A svakako je... -
- ova logika unutar se ne može mijenjati u ver 1.0 i to ostaje
samo provjeri da li u ovim udarnim funkcijama imaš lock/free lock kako treba a ono između ne diraj jer ni ne možeš mijenjati
-
- dobro si shvatio.
u ver 1.0 imamo ovo -
- Koliko sam shvatio ovo je jedino što treba uraditi, vidim da na veznom tiketu postoji promjena na lock funkcijama kod ažuriranja finanasija, ali to je tako u verziji 1.1, u verziji 1.0 je skroz drugačije.
Da li treba i to dirati ili o... -
- "commit":https://github.com/knowhow/F18_knowhow/commit/13dbbc78314141e24068a097bd2c6fcd33c0ccea
ubacio promjene u semaphores.prg koje su rađene na verziji 1.1
03.04.2012
-
- http://redmine.bring.out.ba/issues/27393#note-9
kada drugi korisnici ažuriraju podatke ostali imaju lockove ... trebali bi biti kratkotrajni, da ih korisnici i ne osjete ... ali to ipak treba vidjeti na terenu.
svakako semaphores_v... -
-
- h2. transakcija je zakon
pokrenuo ažuriranje (sa idle-ovima da dugo traje) - ubio klijenta
pokrenuo sve ok - dbf je tu gdje je bio, server nije ažuriran ... ponovio operaciju - sve ok.
vidi se kraj najmržim servisnim sesijama ka... -
- h2. rezime
i postojeći sistem ažuriranja ima sistem
lock tables
... ažuriranje
unlock tables
ista stvar je i kod my_use
lock tables
... ažuriraj semafore
unlock tables
bez obzira što ažuriranje u semaforima... -
- u slučaju da neko ostavi lock stavio sam da se lock prekida nasilno
(recimo neko je u zaključao tabele pa nasilno ugasio aplikaciju)
zato sam povećao "vrijeme lock-a i broj pokušaja":https://github.com/knowhow/F18_knowhow/commit/d0... -
- h2. lock bug
lock sistem uopšte ne radi
ne radi zbog ovoga !
"falio je alltrim :(":https://github.com/knowhow/F18_knowhow/commit/d070c14be81bfab9b0c4942d7874a87b00b5a2a2#L2R32
vrlo je vjerovatno da bi i semaphores v1.0 proradio ako o... -
- h2. provjera broja instanci
dobro bi bilo ipak napraviti provjeru da je F18 pokrenu i recimo sa lsof na linuxu otvorene tabele bi se mogle ispitati -
- "delete_rec_server_and_dbf":https://github.com/knowhow/F18_knowhow/commit/9ffd1bbba6598a4dfcf4dd2e7d2e20d9adbc225d#L4R148 traži da se pozicioniraš na tu dbf tabelu
-
- force_erase - ako je dbf oštećen onda je "Read error":https://github.com/knowhow/F18_knowhow/commit/9ffd1bbba6598a4dfcf4dd2e7d2e20d9adbc225d#L0R84
-
- h2. oštećena tabela
napravimo oštećenu fin_suban
vagrant@f18-dev-1:~/github/F18_knowhow$ echo fljas > ~/.f18/f18_test/fin_suban.dbf
prijavi crvenom bojom alert:
ERR-CI ... ne mogu otvoriti SUBAN
nakon toga bez pitanja obri... -
- h2. sifv brisanje
dodao brisanje sif kada se briše šifra
https://github.com/knowhow/F18_knowhow/commit/6aaf073d3b163fef56657c78b8d36444fa7ca98d
dodao agloritam 3
algoritmi se jednostavno dodaju to je dobra stvar
h2. kre... -
- decimal_to_string() nije dobro radila u update_ ... from server funkciji
zamjenio to sa "dbf_fields_len atributima":https://github.com/knowhow/F18_knowhow/commit/6f60fbf02954218446e0ba50fe07a9b65a311977#L1R85
testirao radi iznos 200 00... -
- ptxt linux
LANG=sl_si.UTF-8 ... wine ...
sudo apt-get install language-pack-sl
-
- ferase_dbf je brisao ćutke dbf-ove koje ne može otvoriti
sada sam uveo pitanje
tako ako se dva puta otvori aplikacija ferase_dbf je brisao fajlove -
-
- puširao windows verziju
-
-
- zar ima veze ? mislim da nema veze.
izgenerisani txt je identičan bez obzira na OS. -
- hm, jel to sa win stanice ili lx stanice ?
-
- prilikom unosa datuma isplate treba postaviti
* godina: 2012
* radna jedinica: 01 (npr, ako se je to glavna)
* obračun: 1 (obavezno) uvijek je 1, sem ako ih ima više (ako ima više obračuna uvijek defaultna isplata se unosi na obraču... -
-
- ovdje se uopšte ne radi o dupliranju
radi se o tome da su u f18_test demo bazi šifarnici uduplani i to kod brisanja izaziva neusaglašenost dbf - sql.
u dbf-u izbrišemo id="14" koga ima 2x. Na serveru se ozbrišu oba zapisa tako da s... -
-
- 6. postavka parametara izgleda dokumenata
Varijanta kartice plate za kredite (1/2) = "2" -
- Kontaktirao Esada, objasnio mi...
Da postoji varijanta ispisa kredita na kartici plate "1" ili "2"
U parametrima izgleda se to podešava, i treba da stoji "2"
onda to izgleda ovako: -
- > Na listi radnika ne prikazuje ukupno zadužene po kreditu , ostatak duga već samoiznos jedne rate .
Na chatu se pominje lista radnika. Prema tome mislim da je ovdje konfuzija oko toga koji izvještaj.
Privjeri da li na listi radnik... -
- Saša Vranić je napisao/la:
> Ernad Husremović je napisao/la:
> ...
taj je izvještaj ok - provjerio si ?
-
- Saša Vranić je napisao/la:
> ne razumijem ni ja, zato ovo sve pišem, loše prikupljene informacije
nemoj biti prestrog. Po većini pitanja imaš podatke i informacije. -
- ali fakat nedostaje šta konkretno ...
-
- iako emir na veznom ticketu attachment "esad_krediti_kartica" jasno rekao da klijent žele podatke na kartici
-
- Ernad Husremović je napisao/la:
> Saša Vranić je napisao/la:
> ...
na listi se uvijek prikazuje stanje kredita aktuelno -
- Jednostavno, treba pitati čovjeka konkretno o čemu se radi i šta mu treba, mi to u ovom momentu ne znamo.
-
- Saša Vranić je napisao/la:
> Postoji lista kredita za kreditora izvještaj
da li tu postoje svi podaci i da li su ispravno prikazani ? -
- stavi naziv kolone "ostatak duga"
i stavi ovo što si naveo. to su definitivno informacije koje se traže
> Ta hendliranja sigurno ne postoje, zato i prikazuje samo trenutnu ratu kredita i kreditora.
ovo je podatak koji je aktuela... -
- Postoji lista kredita za kreditora izvještaj
-
- Pitanje je i da li se uopšte radi o kartici ? Esad spominje listu.
Zato sam i izrazio sve ove sumnje. -
- Ako je pokrećem sa parametrima obračuna 1/2012 a šta ako je pokrenem sa parametrima obračuna 5/2012
mislim na globalne parametre obračuna prilikom ulaska u obračun plata
* mjesec
* godina
na osnovu kojih se dalje barata
prak... -
- Recimo, u ovoj varijanti prikaza, nek prikazuje ostatak sa uključenom ovom odbijenom ratom, ali šta će se desiti kada pokrećem karticu za 5 mjeseci unazad ?
Ta hendliranja sigurno ne postoje, zato i prikazuje samo trenutnu ratu kredit... -
- ostatak duga - ono što je ostalo za plaćanje nakon isplate tekuće rate.
ov nismo ni imali ? čim me pitaš nismo ... praktično ovo je novi zahtjev ? -
- ne razumijem ni ja, zato ovo sve pišem, loše prikupljene informacije
-
- ovu tvoju kolonu ostatak ne razumijem ... u stvari ne razumijem do kraja
ostatak od ukupnog iznosa kredita po pojedinim kreditorima - prije ili nakon uplate tekuće rate -
- ja stvarno ne znam šta tačno želi mislio sam da je to bug a ne nešto čega ranije nije ni bilo.
-
- trenutno prikazuje ovako:
-
- Esad je to lijepo napisao na chatu:
> Na listi radnika ne prikazuje ukupno zadužene po kreditu , ostatak duga već samoiznos jedne rate .
-
- Esad reče da iznosi nisu uredu.
-
- a šta je problem ?
-
-
-
- "commit":https://github.com/knowhow/F18_knowhow/commit/b5df6f4a80e52ec0f579884ff02808ea46335a66
-
- korigovao i ručne prepravke rata, nije ni to radilo...
testirao tako što sam unjeo novi kredit za jednog radnika na 10 mjeseci, pa setovao ručno da su 3 prve rate otplaćene...
na kraju pobrisao kredit, ostale ove 3 rate u bazi, ost... -
- "commit":https://github.com/knowhow/F18_knowhow/commit/6dfc848a418abbca11db1289cfc48170b778367c
brisanje i redefinisanje kredita ispravljeno -
- http://redmine.bring.out.ba/boards/9/topics/6004
-
-
02.04.2012
-
- ovo stanje je totalno neupotrebljivo.
koliko sam primjetio prilikom inicijalnog importa se dupliraju zapisi.
-
- sada sam doveo do toga da se non stop dupliraju zapisi ...
radi promjena u my_use () ?? -
-
- čitava logika se promijenila ?!:
-
- vidim ponovo segfault-e ...
pa ispad ovdje: -
- prolazi - mjesto O_RADN koje poziva semafor pozivam reopen_exclusive(dbf_table)
-
-
-
- nastavljam sutra
-
- korekcije u kod-u, izbačeno korištenje starih funkcija
"commit":https://github.com/knowhow/F18_knowhow/commit/c0ab195c4a0ce5d637253a31658d7c5d51a22a62 -
- prebacio definicije tabela
"commit":https://github.com/knowhow/F18_knowhow/commit/d977bea8612e748149ceb10e54aa9ee738b75e7a -
-
- problem je bio kod sa mojom testnom bazom
-
- nastavljam sutra
-
- ne znam, kod mene postoje te tabele, evo sam odradio upgrade i na drugu bazu i tu su kreirane
-
- tabele: semaphores_pos_dokspf nema
-
-
- odvojio ovo u poseban tiket #27366
-
- da li ovo ima veze
-
- "f_init_db -> pos_init_dbfs":https://github.com/knowhow/F18_knowhow/commit/b76f78af39c23cbfd629f352a4d63e071f791bc2
-
- ma da, to ću promjeniti, međutim čitava stvar mi je čudna ?
zašto ima u psql a nema u dbf ? -
- hm ... pogledao sam u kod, ovo se i dešava kod ulaska u pos modul
poziva se iz ove funkcije f_init_db()
ovu funkciju definitivno treba zamijeniti sa pos_init_dbfs() ... ime treba asocirati na pos -
- Saša Vranić je napisao/la:
> Kod starta se dakle koristi ova funkcija
gdje kod starta ?
Ovo treba pomjeriti kod ulaska u POS modul a ne tamo kod inicijalizacije tabela u f18_init -
- Kod starta se dakle koristi ova funkcija
"pogledaj":https://github.com/knowhow/F18_knowhow/blob/f0d4d3b36f99a0ad522d42df7eaa441576d8c4ec/pos/pos_database_admin.prg#L67
koja automatski napuni prazne tabele STRAD i OSOB sa defaultnim... -
- Automatsko kreiranje stavki u OSOB i STRAD pri startu korigovano
"commit":https://github.com/knowhow/F18_knowhow/commit/68f196b6992ccda68dadc6b321ab950115d55a38 -
- Borba sa *STRAD* i *OSOB*, "commit":https://github.com/knowhow/F18_knowhow/commit/6654994719c78d883b585b740545cc2306914ab1
-
- ihhh, stare funkcije scatter() gather() postoje, to je to
-
- Međutim u POS-u postoji problem sa OSOB / STRAD tabelama
nešto se čudno događa
dodam u tabele vrijednosti, nakon novog ulaska te tabele opet budu prazne itd... ako više puta uđem u njih dobijam *segmentation failed* grešku -
- sada su tarife ok, dodaju se na server itd...
-
- Šifranike prebacio tamo gdje im je mjesto
"commit":https://github.com/knowhow/F18_knowhow/commit/14e77f0bfae022d60f72c567a1af2659dd6af59f
u a_dbfs_legacy.prg ih izbrisao -
- Saša Vranić je napisao/la:
> jah, pa nije uopšte ovaj set šifranika ubačen u set_a_dbf_sif()
> ...
za to je predviđen set_a_dbf_sifarnici.prg -
- jah, pa nije uopšte ovaj set šifranika ubačen u set_a_dbf_sif()
ROBA, TARIFA, SAST itd... -
- nije nego u šifraniku osoblja i statusa nema ništa (prazni su)
hm... recimo dodavanje nove tarife -
- prilikom ulaska u pripremu dobijam
-
- dobro
-
- log_write sada sve operacije stavlja i na fmk.log tabelu što je za dijagnostiku multiuser problema veoma bitno
-
- Saša Vranić je napisao/la:
> Šta je dalje ?
> ...
fmk.log je koliko se sjećam u 4.2.6 db-u instalirana. ima u changelog-u -
- Šta je dalje ?
Kaže relacija fmk.log ne postoji! I to par puta... u log-u nema ništa.
Vjerovatno treba da postoji na sql/db neka tabela fmk.log, koje vidim nema na serveru.
-
- alias tabele treba da bude *_pos_pripr* umjesto *_pripr*
-
- Ispravio grešku
"commit":https://github.com/knowhow/F18_knowhow/commit/6d82b912c1c792510dcd3747fb7b820e62cdf004 -
- ima li ta tabela u set_a_dbf_pos definisana sa:
set_a_dbf_temp( ... )
-
- Prilikom ulaska ovu grešku dobijem
-
- ažuriranje računa, povrat računa korekcije
"commit":https://github.com/knowhow/F18_knowhow/commit/99ad1b813c3a3457f7a66235ae2c079609d7f0eb
da, tabela kao parametar, ime tabele pravo -
- ali treba koristiti dbf_table kao parametar uobičajeno
-
- ispravio tako da bi sada i alias trebao biti prihvatljiv parametar
-
- Saša Vranić je napisao/la:
> pronašao grešku:
> ...
hm pa nije ovo baš greška aplikacije ovo je bug u update funkciji -
- pronašao grešku:
"commit":https://github.com/knowhow/F18_knowhow/commit/1f04745a139067aced3cb15814362c59b5121a28 -
- a ovakve stvari su takođe, pretpostavljam, potencijalne bombe
-
- update-ovo sam server db na 4.4.1 dbijam da ne postoji tabela fmk.strad
zar ne treba biti fmk.pos_strad ? -
- evo šta fmk paket sadrži !
bringouts-MacBook:fmk bringout$ grep -i -R "osob" * -
- sad vidim neku zbrku, na sql/db imam i
* pos_osob
* osob
* pos_strad
* strad -
- napravio sam punjenje ovih tabela na dužinu polja
"commit":https://github.com/knowhow/F18_knowhow/commit/3f8889c89d83233dd85a13b62632b2a1675d6062
ovo se desi u log-u -
- ovo bi vrlo lahko i moglo biti ono što je uzročnik problema u semaforima ver 1.0
-
-
- odradi update fmk paketa svakako
-
- Nema šta, svaki put kada ulazim u šifranik praktično ova dva šifrarnika budu prebrisana, znači kada god se desi
*O_STRAD*
*O_OSOB* -
- ranije mi je prijavlijvao da strad nema na serveru trebam nover baze ?
-
- ja sam dobio ovu grešku:
-
- Znači pobrisao lokalne tabele i ušao u app i kada pokušam u jednu od ove dvije tabele izbaci me odmah...
Sve ostale tabele rade kako treba. -
- interesantno *segmentation* se opet dešava ?!???
-
- #27370 sredio radna područja
-
- Ernad Husremović je napisao/la:
> po ovom principu:
> ...
ma jasno -
- ali mislim da ih ima više od 250
ja sad ne znam da li harbour dozvoljava više od 250, ja sam negdje već koristio i 300 ali negdje mi nije uspjevalo sa 350 recimo -
- po ovom principu:
-
- ok
-
- Saša Vranić je napisao/la:
> Svojevremeno si pominjao da se u harbour-u mogu zadavati i oznake, recimo
> ...
da ali logika je da se WA tretira na najvećem broju mjesta kao numerička varijabla.
ma samo prođi kroz kompletan f_fmk ... ... -
- Svojevremeno si pominjao da se u harbour-u mogu zadavati i oznake, recimo
-
- jeste jeste, to je to
-
- *segmentation fault* je bila greška ranije kada smo imali dvije tabele pod istim brojem...
"F_STRAD":https://github.com/knowhow/F18_knowhow/blob/b76f78af39c23cbfd629f352a4d63e071f791bc2/common/f_fmk.ch#L152
pa onda opet imamo tabel... -
- svakako treba sve ove WA napraviti jedinstvenim
uradi to odmah za kompletan f_fmk.ch -
- da li se desi da nakon
pos inicijalizacije uđe u rnal inicijalizaciju i onda se napravi full sycnhro (zap) koji sve pobriše u pos dbf-ovima -
- ove wa se preklapaju sa RNAL
-
- Pobrisao sam lokalne dbf-ove
* pos_osob.dbf
* pos_strad.dbf
i ušao u aplikaciju / ušao u POS
nakon što sam izašao provjerio stanje dbf-ova, dbf-ovi su napunjeni sa stanjem iz sql-a to je dobro, međutim problem je kada uđem pono... -
- ovo je najbolje da izdvojim na poseban tiket
-
-
-
- datum unesen, RJ 01, varijanta obračuna prazno, kod generisanja MIP-a datum isplate ostaje "0-00-00"
-
- radna područja sredio
"commit":https://github.com/knowhow/F18_knowhow/commit/dbdc5935eca691c28acfcf19cc4996a4ae16d7bb -
30.03.2012
-
- dodao tabelu #27341
-
- hm, dobro, to ću pogledati kako u pos ubaciti, idem dodati tabele prvo u sql/db
-
- ovdje se koristilo update_server_from_rec("fin_suban", "END")
isto bi bilo da je napisano funkcija sql_table_update(nil, "END")
iz jednostavnog razloga što je efekat komnde "COMMIT" transakcije tako da se ime tabele uopšte ne uzi... -
- a "završava ovdje":https://github.com/knowhow/F18_knowhow/blob/34b3a3b09a31ae6b6717d024e91ba96db863ac8b/fin/azuriranje_naloga.prg#L258
-
- h2. primjer fin ažuiranje
trasakcija "počinje ovdje":https://github.com/knowhow/F18_knowhow/blob/34b3a3b09a31ae6b6717d024e91ba96db863ac8b/fin/azuriranje_naloga.prg#L133
-
- treba uočiti da je transakcija vezana za ažuriranje više tabela (ne treba zbutniti što se poziva funkcija sql_table_update).
-
- "pogledajmo sekvencu":https://github.com/knowhow/F18_knowhow/blob/a0e365a3fd/common/codes_browse.prg#L844
-
- h2. Greške tipa "already in transaction", "outside an transaction" ne smiju se više dešavati
Kod ažuriranja i povrata je bilo u sem v1.0 masovna pojava ovih grešaka. -
- tabela pos_pos također uveo da ima dva nivoa algoritma
2 je za dokument (brisanje)
"commit":https://github.com/knowhow/F18_knowhow/commit/08fd5fa27f0476fc4b59a78189427a51accd1f09 -
- Uveo sam set_a_dbf_pos.prg
"commit":https://github.com/knowhow/F18_knowhow/commit/f0efeecac13ac7c9e43e0eeaaa3650e673c7f3a6
po uzoru na set_a_dbf_fakt.prg -
- pričam o ranijem stanju naravno
-
- ePDV tabele su u priličnom haosu .. bojim se da niz stvari u kuf, kif ne odlaze na server
-
- analogno napraviti pos.sql
-
- tabele dbf - sql moraju biti identične
to sam ovdje započeo:
https://github.com/knowhow/fmk/blob/master/database/misc/epdv.sql#L214
-
- h2. server database tabele
postojeći ugrade je skroz nepregledan.
uočio sam da su neke tabele u ePDV skroz različite dbf <-> sql
da bih sve to upratio na kraju sam sredio server_db sql
https://github.com/knowhow/fmk/blob/mast... -
- algoritam 2 jednostavno manipuliše tabelom na "nivou dokumenta a ne zapisa":https://github.com/knowhow/F18_knowhow/blob/master/fin/set_a_dbf_fin.prg#L101
-
- evo kako primjenjujemo algoritam 2 kod povrata dokumenta:
https://github.com/knowhow/F18_knowhow/blob/master/fin/fin_povrat_dokumenta_priprema.prg#L147 -
- h2. algoritam 1
svaka tabela koja ide na sinhro ima barem 1 algoritam za sinhronizaciju
tabele kao što je fin_suban imaju dva.
-
- h2. kreiranje set_a_dbf.prg
ovdje se definišu parametri koji se već dijelom nalaze u common/a_dbf_legacy.prg (gADBFs)
ja to radim tako što te stavke kopiram pa ih onda uređujem.
pored toga sql_in npr nalazi se u pos/pos_semapho... -
- h2. switch sa semaphores_v1.0 na master
-
- uradio git merge
master <- semaphores_v1.0
tako da su sve promjene koje su rađene na ovom branchu sada u masteru.
-
- ja sam uradio najvećim dijelom za fin, fakt, epdv
-
- ovo je sada mjesto gdje se definišu svi parametri dbf-a i parametri sinhronizacije
https://github.com/knowhow/F18_knowhow/blob/master/fakt/set_a_dbf_fakt.prg#L17 -
- zadatak je da pripremimo pos u novom okruženju.
logika semafora je skroz promjenjena posebno sa stanovišta definicije sinhronizacije. sada se sve nalazi na jednom mjestu
pos/pos_semaphores.prg su nepotrebne - ne koriste se -
- pushiraj sve sa semaphores_v1.0 i prebaci se na master branch
git checkout master
git pull
dobićeš stanje na kome radim -
-
-
- dodao tabelu pos_dokspf
-
- odvojio u fmk paketu pos.sql
"commit":https://github.com/knowhow/fmk/commit/b6edc96b056fb5251c72c69a844697fd289cabaa
-
- treba još napraviti da se tabela kreira i na serveru... ostavljam ovo kod sređivanja fmk paketa i izdvajanja pos.sql skripte
-
- Prebacio kreiranje dbf-a u cre_all_pos.prg
"commit":https://github.com/knowhow/F18_knowhow/commit/b173e2f1483fa30fc67ccb18a58d3c47ff478f8f
-
- Ova tabela sadrži podatke o partneru kada se izdaje porezna faktura iz pos-a
-
-
-
- uradili cmd 301, zatvorili rn ali printer ublokao ne prima polog niti bilo koju drugu komandu, izbacuje grešku
-
-
- Kod mene je bila verzija 0.9.71, odradio sam update na novu verziju 0.9.77 i greška se opet ponavlja.
Pustio jedan fiskalni račun, i opet je problem sa našim slovima -
- na dnu fiskalnih računa gdje su podaci o partneru prikaz naših slova ne valja
umjesto svih slova prikazuju se simboli -
-
- "commit":https://github.com/knowhow/F18_knowhow/commit/b173e2f1483fa30fc67ccb18a58d3c47ff478f8f
izbacio -
- izbaci ne treba
-
- postoje DINTEG1, DINTEG2, INTEG1, INTEG2 tabele koje su svojevremeno korištene za integritet podataka kod prenosa
treba li nama uopšte to ? -
-
- Treba dodati da imamo 4-5 verzija specifikacije
* standardnu
* samostalni radnici
* autorski honorari
* ugovori o djelu
* rep.srpska
* itd...
-
- Najbolje i jeste prebaciti na ODT report, samo treba vremena. Specifikacija, kao i rekapitulacija jesu generalno nezgodni izvještaji sada.
-
- Ovo je varijanta delphirb reporta bez tabele, korisi se INI fajl sa džokerima. U samom RTM fajlu se nalaze također ti džokeri koji budu zamjenjeni prilikom print-a.
Međutim ova delphirb linija bude sa -
- ali dobro treba pogledati u čemu je kvaka da li se ovo uvijek ponaša (za svaki sadržaj dokumenta) ili ima veze za print drajverom, os-om itd ...
-
- na ovakvim budaleštinama se mogu izgubiti dani umjesto da se odmah presječe i napravi "čisto" rješenje
-
- ovdje treba razmisliti da se ovi "udarni" - često korišteni izvještaji, kakav je ovaj, prebace na odt
-
- Trenutno rješenje je da se na print dijalogu kaže
* CURRNENT PAGE ili
* PAGES: 1
i onda je ok -
- Problem je taj što ne dobijamo samo jedan list u delphirb-u nego kako vintamo stranice možemo u nedogled ići i kada se pusti na štampu izvlačit će ih sve dok ne isključimo printer.
-
-
- stvarno u epdv_pdv tabeli nema polja i_opor
-
- full_synchro iz ovog ispada
-
- semaphores_v1.1 algoritam automatski formira fields listu na osnovu strukture dbf-a.
full_synchro funkcioniše tako što select formira na osnovu liste polja u fmk.
ovo se može promijeniti u iznimnim situacijama u set_a_dbf_ ... funk... -
-
- dobro zakrpljeno je tako da se može ovo isporučiti korisnicima kojima je hitno
ovo ćemo onda uzeti u master branchu koji se priprema -
- sinoć je saša to radio "ovako":https://github.com/knowhow/F18_knowhow/commit/208961c5bb541751e7186f6383392269f5823c8b#L1R258
imamo znači "milion" bezpotrebnih konverzija u aplikativnom dijelu -
- hah evo upravo sada vidim da je to zakrpljeno ako ne treba - u aplikativnom dijelu koda :(
-
- h2. postojeći kod
ukloniti konverzije u aplikativnom dijelu kje su predhodnih dana rađene -
- gledam fetch metric funkciju:
-
- h2. šta uraditi
u aplikativnom kodu - kodu koji koristi fetch_metric set_metric treba izbaciti konverzije
u get_metric treba staviti konverziju -
- aplikativni developer ne treba misliti o konverziji parametara.
h2. principi
1) na sql serveru podaci *MORAJU* biti pohranjeni u utf formatu. utf je 2-bajt format za naša slova.
2) memorijske varijable u harbour-u (ono što se ... -
- uočavam 5-6 bugova i niz problema koje izaziva promjena parametara - prebacivanje na server db.
to se jedno po jedno fiksira ali to tako ne treba. To treba fiksirati u F18 core funkcijama)
u set_metric / fetch_metric treba te stv... -
29.03.2012
-
- ispravio u verziji 0.9.77
-
- ista stvar je kod gip, mip itd
-
- dopušta unos ali nakon ponovnog pokretanja da smeće
-
-
- puširao windows verziju na google
-
- preduslov fmk paket verzija 4.3.3
-
-
-
- osposobio adresar
"commit":https://github.com/knowhow/F18_knowhow/commit/602ef19dad7b7e919110123fd49bddd860625020
novi fmk paket
"commit":https://github.com/knowhow/fmk/commit/681d17d8fe3c33243f2c29a9e8b952b0a9669bec
"commit"... -
28.03.2012
-
- "ovdje":https://github.com/knowhow/F18_knowhow/blob/86ffe88e09bd798c67b0ca155470fcd62bc948d6/common/sifk_sifv.prg#L427
i "ovdje":https://github.com/knowhow/F18_knowhow/blob/86ffe88e09bd798c67b0ca155470fcd62bc948d6/common/sifk_sifv.prg... -
- zašto je u dbf-u naz c (50)
a na serveru naz c (200) ?
de mi pomozi pa mi lociraj kod na kome si ti setovao PADR (200) za sifk/sifv semafore
-
- sifv dbf:
-
-
-
- puširao windows verziju
-
-
-
- stavio sam jedan msgbox
"commit":https://github.com/knowhow/F18_knowhow/commit/43dd132a1e6e14caf0bc9aaf8f8a1d550761108a
čisto informativno -
- > blokada povrata ako dokument postoji u pripremi
ili bar upozorenje
-
- tu prije svega treba analizirati nekakve "normalne" opcije korištenja povrata.
Te masovne ispravke su loša ... vrlo loša praksa.
Ali ako to korisnicima predstavlja dobru stvar ne treba se svesti na "zabrani", ali treba riješiti ta... -
- Jedini problem je što možemo imati potrebu da vraćamo više dokumenata radi brisanja
-
-
- "commit":https://github.com/knowhow/F18_knowhow/commit/39dd13e7e795087548bc500b3a7feff68bc0918d
ispravljeno -
- "commit":https://github.com/knowhow/F18_knowhow/commit/5a7249a55925e8b5ea93184c6638640d8b690389
korigovano -
-
- bringouts-MacBook:kalk bringout$ git tag 0.9.75
bringouts-MacBook:kalk bringout$ git push origin semaphores_v1.0 --tags -
- "commit":https://github.com/knowhow/F18_knowhow/commit/333abd6da35c303685c70cd847067de40c5c3b0e
osposobio opciju ažuriranja fakt dokumenta
Iskorištena klasična funkcija ažuriranja fakt dokumenta modula FAKT -
- http://redmine.bring.out.ba/issues/27236#note-13
-
- Odrađen build 32
-
- h2. pushiranje na server:
kada se pušira:
git push origin semaphores_v1.1
tagiranje se radi kao i do sada -
- odradio
git checkout semaphores_v1.0
i swičao se na ovaj branč, evo vidim da imam fajl fin_semaphores.prg sada -
- provjera i napomena za developera
paziti da si na pravom branchu kada radiš
npr. fin/fin_semaphores.prg u semaphores_v1.1 ne postoji
-
- hernad@macan:~/github/F18_knowhow$ git checkout semaphores_v1.0
-
- sinoć sam napravio merge semaphires_v1.1 u glavni branch.
međutim, postoje neodložne stvari za danas tako da se mora uraditi par hitnih debug-a.
Vraćam se zato na verziju 0.9.74 koja je posljednja objavljena tako da debug develope... -
-
- http://redmine.bring.out.ba/issues/27236#note-13
27.03.2012
-
- zadnjim promjenama - uvođenjem f18 parametara (RAČUN, PREDRAČUN) si poremetio naša slova.
Očigledno radiš neke viška ili manjka konverzije. -
-
-
-
-
- puširao windows verziju na google
-
-
- "commit":https://github.com/knowhow/F18_knowhow/commit/62b787d48a96be42d1a8ed79d28507b2606a1b4c
26.03.2012
-
- danas je vsasa na parametrima radio ?
-
-
-
- iz pripreme automatika
-
- Ubuntu 32 build odrađen
-
-
- puširao windows verziju
-
-
- Ubuntu 64 build odrađen
-
- Odradio ubuntu 32 build
-
- Ma to su prazni zapisi u tabeli LD, a server ne dozvoljava da je godina, mjesec = NULL i to je to.
To je ok -
-
- kao što su default rok.plaćanja itd...
-
- još bitnih parametara prebačeno na sql/db
"commit":https://github.com/knowhow/F18_knowhow/commit/fd6fa178239fcebdd631134931de12e6978ec870 -
- fakt, bitni parametri u sql/db
"commit":https://github.com/knowhow/F18_knowhow/commit/27c49d954ef6dc747883fd92c36661d4dbab1b0e -
-
-
- sada imamo server_side log
https://github.com/knowhow/F18_knowhow/commit/6167c14d1e26bedcccce2851eaeaff543d0a25e2
-
- ver 4.3.2 - fmk.log_id_seq - grant to xtrole
-
- https://github.com/knowhow/fmk/blob/4.3.1/database/misc/log.sql
-
- https://github.com/knowhow/fmk/blob/4.3.1/CHANGELOG.md
-
- 4.3.1
-
25.03.2012
-
- znači ovako treba biti
-
- štampa šifarnika mi je pokazala da ovo nije bila naša praksa. ostavljali smo otvorene tabele i pozivali print.
treba to sada počistiti kod glavnih funkcija.
U svakom slučaju windows klijent radi, dok unix-i ne rade dok se ovo ne iš... -
23.03.2012
-
-
- publikovana windows verzija na google
-
-
- u paketu sa kompenzacijom
-
- treba i ostala FAKT podešenja staviti na server i potpis ... pri tome
paziti da je potpis user, a parametri kao što su unos datuma plaćanja, broj dana za odgodu plaćanja globalni parametri -
- brisanjem loko dbf-ova gube se i ova podešenja
-
- Puširao windows verziju
-
-
- "commit":https://github.com/knowhow/F18_knowhow/commit/4af90c7dc25c7af19a7025a7a5e99dfb47ac2a4b
-
- ispravio sam grešku kod izvještaja, malo sam ga i doradio da piše broj obračuna i ime i prezime radnika
-
- http://redmine.bring.out.ba/boards/2/topics/5977?r=5993
-
-
- Napravljeno u FMK, samo prepisao u F18.
-
-
-
-
- Puširao windows verziju
-
- bringouts-MacBook:F18_knowhow bringout$ git tag 0.9.69
bringouts-MacBook:F18_knowhow bringout$ git push origin master --tags -
-
- znači kad se na to naiđe ostaviti samo true dio
-
- jeste, ima u kod-u na hiljade mjesta gdje se ispituje varijabla, negdje sam brisao taj uslov a ostalo je još na puno puno mjesta
-
-
- jeste
22.03.2012
-
- ovo je stavljeno u funkciju ?
-
- to je sada uvijek .t. je li tako ?
-
-
-
- "CHANGELOG":https://github.com/knowhow/F18_knowhow/blob/84f70212d723e2aa4b58bf17c2224be67e1a6e09/CHANGELOG.md
-
- Puširao na google windows verziju
-
- bringouts-MacBook:common bringout$ git tag 0.9.68
bringouts-MacBook:common bringout$ git push origin master --tags -
-
- "commit":https://github.com/knowhow/F18_knowhow/commit/ae98700bf223db51c902ee929f99b239ff72306a
iščistio dosta toga -
- ubacio _filter_quote, izbacio eval i ovaj izvještaj radi
https://github.com/knowhow/F18_knowhow/commit/9fa52b208a99e3516a1fe6d8
treba ove evale svugdje izbaciti a isto tako i filter izraze iščistiti
-
- koriste se ld-u ali vjerovatno i drugdje.
-
-
- nije, jer nije ni bilo tabela u F18 za njega, tek sam ja sada sa zadnjim doradama uveo sql tabele
-
- je li ovo do sada rađeno ?
-
21.03.2012
-
- na osnovu onoga što je Saša govorio najviše posla će biti oko prenosa knjigovodstvo <-> POS
-
-
- ovo nam je aktuelno
-
- treba napraviti u odt formatu
-
-
- puširao windows verziju
-
- aha samo njega znači. pa nije strašno ...
otvoriću ticket na F18.
ove stvar trebamo napraviti tako da serviser ovo brisanje odnosno ovaj full sinhro ne radi ručno -
- Kod postavljanja ove verzije bitno iz home direktorija pobrisati sifv.* da bi se odradio full sinhro
-
- bringouts-MacBook:F18_knowhow bringout$ git tag 0.9.67
bringouts-MacBook:F18_knowhow bringout$ git push origin master --tags -
-
-
-
-
- Sada se regularno upisuju stavke u IDS-ove na dužinu 200 a tako se i traže kod osvježavanja tabele.
-
- ispravljeno
"commit":https://github.com/knowhow/F18_knowhow/commit/a249d43c102f81ff10ce0a4704373b41935f8aeb
sada radi regularno -
- pardon
rpad(idsif, 15) ... rpad(naz, 200) ...
onoliko koliko su ta polja maksimalno velika tako semafore treba puniti -
- međutim nema potrebe za komplikacijom.
idisif=c200 širine.
ne treba uopšte ići na varijabilnost
treba uvijek biti -
- nije idsif, nego dužina i tip polja "naziv" iz tabele SIFV
-
- da
-
- gdje se nalazi informacija o ispravnoj šifri ?
u sifk -
- problem je ovaj
npr za idsif dužine 15 ovo treba: -
-
- konkretni problem će biti rješen da se na serveru poveća veličina polja nazv u šifarniku partnera
ali generalno kada ažuriranje ne uspije mora se uraditi rollback a ne de-facto brisanje šifre -
-
- da, tako je i bilo, nije bilo podataka FAKT tabele.
Ovo je naknadnim ispravkama u semaforima riješeno. -
- ovo sam napravio, problem je bio do komande *close all* na već otovrene tabele (zauzete izvještajem)
-
- Ovo sam riješio na terenu...
"commit":https://github.com/knowhow/F18_knowhow/commit/c6c543247b4d89ab6c303158b7621bdf1c59a60d
20.03.2012
-
- server prijavi grešku tako da stara šifra nestane ... ne napravi rollback nego izbriše postojeću šifru
-
-
- Odradio ubuntu 64
19.03.2012
-
- nije stavljeno u funkciju
-