Dirba su mano programa, bet reikėtų rašyti į atitinkamą temą.
Šiaip DB struktūros klaida, po kažkelinto atnaujinimo pasikeitė. Reikia išsitaisyti per Bendras\DB struktūra.

Ir niekada nebuvo?

Višta toks jau padaras - nenuspėjamas ir kvailas. Kiek pažįstu jos priverstinių naudotojų, visi teigia, kad dėl jai vienai žinomų priežasčių višta turi savybę neleisti veikti atsitiktinėms programoms, t.y. tai, kad viena višta vykdo, visai nebūtinai reiškia, kad kita irgi tą darys.

Neinstaliuotas, nepaleistas arba blokuotas MySql serveris. Gali būti višta, gali ir nebūti.

Žiopla klaida SQL script'e, pridedamą failą išarchyvuokite į programos folderį (overwrite - yes), pasitikrinkite DB struktūrą.

Asmenines žinutes tikrinkitės.

Nepasikeitė, nes aš dar neturėjau laiko prie GPM deklaracijų prisėsti. Kai turėsiu mažiausiai du laisvus pusdienius, prisėsiu.
Kol kas pilnai funkcionuoja tik SODROS 13-SD ir abi versijos SAM deklaracijos.

Su atostogų kompensacijomis yra taip:
- nepanaudotų likučio apskaičiavimas tiek anksčiau, tiek dabar veikia gerai, tik yra vienas niuansas: atostogos yra skaičiuojamos sveikais skaičiais, t.y. pagal proporciją apskaičiavus nepanaudotų atostogų kiekį pvz 10,01 dienos, programa skaičiuos 11 dienų. Tokiame skaičiavime logikos yra teisinės - atostogos yra skaičiuojamos kalendorinėmis dienomis, o pgl DK visi neaiškumai yra darbuotojo naudai. Nors tikriausiai būtų galima skaičiuoti ir didesniu tikslumu, t.y. dienų dalimis;
- leidimas rankiniu būdu keisti atostogų kompensacijos dydį reikštų leidimą klaidingai skaičiuoti kompensaciją; man toks leidimas visai ne prie širdies.

Update'e ištaisyta:
1. Atrodo, galutinai sutvarkyta SAM deklaravimas, išskirtos dvi SAM versijos - darbuotojams ir autoriniams;
2. Nebekvailioja su atostogų kompensacija (nemėto lentelių, kada nereikia).

Update'as čia:
http://cid-061b6c20c4d4f14d.skydrive.live.com/self.aspx/Vie%c5%a1asis/Apskaita%7C_1.1%7C_beta%7C_update.exe

1. Įsidėkite naujausią update'ą;
2. Įvykdykite sąkinį (be kabučių su kabliataškiu):
"UPDATE prekes_op p SET p.BZ_ID=(SELECT s.BZ_ID FROM sfg s
WHERE s.P_ID=p.ID LIMIT 1)
WHERE p.ID=ANY(SELECT z.P_ID FROM sfg z WHERE z.Rus=1 AND z.P_ID=p.ID);"
3. Pasitikrinkite vėl dėl tos pačios klaidos, turėtų dingti. Jei nedings, rašykite.

Yra, bet per forumą nieko čia labai nepriaiškinsi, reikia žiūrėti visus dokus ir tada spręsti. Kreipkitės į teisininkus.

Būkime kultūringi ir nevartokime jau penkmetį nebesančios sąvokos "ieškininis pareiškimas"

1. Kokį dokumentą vykdo antstolis - nutartį dėl laikinų apsaugos priemonių ar vykdomąjį raštą/teismo įsakymą?
2. Jei vykdomąjį raštą/teismo įsakymą, nusirašyti turi antstolis, nors iš principo galima pervesti ir kreditoriui informuojant apie tai antstolį. Šiuo atveju padeda paaiškinimas antstoliui ar jo sekretorei, kad rytoj rašysite skundą teisingumo monisterijai dėl antstolio vilkinimo atlikti vykdymo veiksmus.
3. Jei nutartį dėl laikinų apsaugos priemonių, tai antstolis viso labo laikys areštavęs tol, kol uždėjusi institucija priims priešingą sprendimą. Praktikoje susidūriau su atvejais, kada areštas kaba > 5 metus.Tokiu atveju reikia pervesti skolą kreditoriui ir rašyti prašymą teismui, uždėjusiam areštą, jį nuimti (pavedimas pridedamas).

Pretenzijos iš viso nebūtinos, išskyrus atvejį, kada sutartyje/faktūroje nenurodyta apmokėjimo data/terminas. Bet mandagu.

Taip pat dėl netikėtai padidėjusio darbų, sudarančių pajamų šaltinį, krūvio padidėjimo, negaliu pažadėti mėnesinės GPM deklaracijos šią savaitę.

Update ištaisyta/pridėta:
1. Vėl veikia duomenų gavimas iš JAR ir VMI;
2. Kartais kai kam priklausomai nuo mėnulio fazės mesdavo klaidą formuojant darbuotojo kortelę - daugiau nebemes;
3. Pridėtas 13-SD deklaracijos eksportas ir perdaryta SAM deklaracija.

Update'as čia:
http://cid-061b6c20c4d4f14d.skydrive.live.com/self.aspx/Vie%c5%a1asis/Apskaita%7C_1.1%7C_beta%7C_update.exe

Papildoma info:
- Po update'o reikės atsinaujinti DB struktūrą, nes 13-SD deklaracijos privaloma tvarka reikalauja asmens SODROS kodo, o autoriniai yra išmokami ne tik darbuotojams;
- Jei 2009 m. vedėte autorinius ne darbuotojams, kitų išmokų formoje pridėkite tų asmenų SD kodus;
- Nors verk eksportuotos SAM formos nesupranta formfilleris. Nesuprantu kodėl, bet jei tik yra autorinių, iš karto meta klaidą, kad neteisingos išmokų ir įmokų sumos F4 formoj. Skaičiai visi surenkami teisingai. Gal kas dirba su autorinėmis galėtų pažiūrėti, kame kampas.

Tikriausiai Registrų centras pakeitė savo puslapio struktūrą. Savaitgalį pažiūrėsiu.

Neinstaliuotas arba nepaleistas serveris.

Na šiaip jau duombazės struktūrą reikia pasitikrinti. Po paskutinio atnaujinimo, pasikeitė programos naudojama struktūra.

O jei vartojamas išimtinai tik alus?



Patikėkite, Jūs to nenorėtumėte



Problemiška su atvežimu ir kepimu vietoje



Na aš tai laaabai ramus žmogus, linkęs išvengti nebūtinų administracinių procedūrų.

Taigi tą dienų skaičių galima rankomis pataisyti. Iki gero d.d. skaičiuotuvo dar rankos nedaėjo. Iš kitos pusės, jokia programa nepajėgi nuspėti vyriausybės ketinimų stumdyti dienas (pavyzdžiui, tarp š.m. sausio ir vasario), todėl net patobulinus veikimą vis tiek idealaus tikslumo pasiekti neįmanoma.

Problemos turėtų išsispręsti po paskutinio update'o ir įvykdžius šį sakinį (be kabučių su kabliataškiu):
"UPDATE prekes_op p SET p.BZ_ID=(SELECT s.BZ_ID FROM sfg s
WHERE s.P_ID=p.ID LIMIT 1)
WHERE p.ID=ANY(SELECT z.P_ID FROM sfg z WHERE z.Rus=1 AND z.P_ID=p.ID);"

Update ištaisyta/papildyta:
- Klaida avanso apyskaitos formoje neleidavusi taisyti apyskaitos;
- Klaida gautų sf formoje: kada į jau registruotą sf buvo pridedama prekių, nusimušdavo prekių ir sf tarpusavio ryšiai. (vėliau pabandysiu sugalvoti kaip greitai padėti tiems, kurių duombazėse ši klaida jau iškilo);
- Avanso apyskaitose pridėta galimybė atskirai įvesti PVM.

Update'as čia:
http://cid-061b6c20c4d4f14d.skydrive.live.com/self.aspx/Vie%c5%a1asis/Apskaita%7C_1.1%7C_beta%7C_update.exe

Po šio update'o reikės atsinaujinti DB struktūrą.

Tai kad neaišku, ar čia juoktis, ar verkti reikia. Tie studentai kažkur po to dirbs...

Seniai atnaujinimų nesidėjote. Pasitikrinkite duombazės struktūrą.

Jei turite omenyje DU išmokėjimą per kelis kartus, tai programa to nepalaiko.

Galima ir paprasčiau:
- atskaitingas asmuo rašo jums laisvos formos ataskaitą/pažymą (kiek, už ką, iš ko, galima excelyje tokią formą pasidaryti) apie surinktus pinigus ir prisega x vienetų PPK.
- šios ataskaitos ir pridedamų PPK pagrindu darote paprasčiausią BŽ įrašą, kuriame kiekvienai kreditinei korespondencijai (tiek korespondencijų, kiek skirtingų asmenų) priskiriate atitinkamą asmenį (iš kurio gauti pinigai), o bendrą analitiką priskiriate tam atskaitingam darbuotojui. Korepondencija: x kiekis K2____ Pirkėjų skolos, D2____ Atskaitingi asmenys.
- per parodote pinigų paėmimą iš to darbuotojo ir viskas.

Šito rezultate visas judėjimas puikiai matosi per atitinkamų sąskaitų apyvartos žiniaraščius ir pakanka dviejų operacijų.

Šis metodas netinka, jei jūs norite fiksuoti kiekvieno atskiro PPK datą. Tada belieka kiekvienam PPK išrašinėti po .

Nieko nesupratau... Kaip gali būti vienoje SF tos pačios rūšies prekės už skirtingą kainą?

Pabandykite atsidaryti Bendras\Query browser ir įvykdyti sąkinį:

"SELECT b.Op_data, b.Op_Dok, s.BZ_ID, s.Preke, s.V_KK, p.BZ_ID, p.ID
FROM sfg s, prekes_op p, bz b
WHERE p.ID=s.P_ID AND s.Rus=1 AND p.BZ_ID<>s.BZ_ID AND s.BZ_ID=b.Op_ID;"

(be kabučių su kabliataškiu) ir parašykite asmeninę žinutę, ką išmes. Jei viskas gerai, turėtų nieko nemesti.

Update ištaisyta:
1. Per faktūrą parduodant IT teisingai apskaičiuoja savikainą (atsižvelgiant į amortizaciją ir pekainojimus);
2. Perdaryta kitų išmokų gyventojams forma pgl. naujus mokesčius;
3. Kažkokių smulkių klaidų taisymas prieš sudegant mano kompui (nepamenu tiksliai kas).

Update'as čia:
http://cid-061b6c20c4d4f14d.skydrive.live.com/self.aspx/Vie%c5%a1asis/Apskaita%7C_1.1%7C_beta%7C_update.exe

Mano senasis kompas, kuriuo programavau, sudegė praeitą savaitę. Dar neatsikūriau duomenų. Toliau kažką daryti galėsiu tik po kokios savaitės, kai duomenis atgausiu ir naują kompą susitvarkysiu.