Delspinigiai ir baudos yra pajamos, bet nėra PM objektas ir nėra pardavimo pajamos, todėl jiems turėtų būti išrašoma laisvos formos sąskaita.

Ne paskutinius, o paskutinį

Tai kad priklauso...
Jei pelningumas yra suprantamas kaip: (pajamos - sąnaudos)/pajamos
nusidėvėjimo apskaita leidžia keisti sąnaudas niekaip neįtakojant pajamų.

Failai žaidžia slėpynes, reikia gi ir jiems kažkaip atsipalaiduoti. Žaiskite ir Jūs, kai surasite, galėsite pamatyti

Kibiro ir dobsono sistemos teleskopo sandara yra labai artima. Šie teleskopai yra vienu metu labai galingi ir labai primityvūs. Todėl astronomų gretose jie vadinami (šviesos) kibirais.

Jei bus giedra naktis, keleta gražių vaizdų galėsiu parodyti. Nors liepos pabaigoje dar naktys per šviesios pačių gražiausių objektų stebėjimui.

Kibiras: www.teleskopai.lt/index.php?page=shop.product_de...

Update ištaisyta:
1. Balanso formoje dėl pernelyg tiksliai suprantamos vartotojo nurodytos datos pirmos laikotarpio dienos operacijos pakliūdavo į likučius prieš tą laikotarpį.
2. Keleta estetinio pobūdžio nedadirbimų (tab šokinėjimo tvarka estetiškas kai kurių elementų atvaizdavimas ir pan.).

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

Yra, pilnas, pats naudoju, nors vartotojams nepatariu
<5.0 nesupranta dėl SP nebuvimo, >5.1 nesupranta dėl sintaksės naujovių (ypač lentelių kūrimo/keitimo sintaksės)



Patikėk, vartotojai prikiš nepriklausomai nuo varnelės ne/buvimo.
Man šiandien viena buhalterė sugebėjo faktūrinio įsigijimo IT įrašą ištrinti, neištrindama faktūros. Kaip jai tas pavyko, nepaaiškino. Programoje dėl savaime suprantamų priežasčių to daryti griežtai neleidžiama. Pats patikrinau, logika tokius bandymus blokuoja nepriekaištingai. Susidaro įspūdis, kad buhalterės yra piktieji SQL genijai - komandomis rašo/trina tiesiai duombazėn.

O "b" nereiškia betos? 5.0 versija yra pirma mysql versija, kurioje atsirado stored procedures/functions. Šiuo metu aktuali yra 5.0.83, tikėtina, kad problema su funkcija būtent tame.



Kiek reikia tikslams pasiekti, tiek ir keičiu. Nepamenu, ar esu trynęs stulpelius, paprastai stulpelius ir lenteles pridedu, nors reikalui esant yra galimybė ir trinti. Perskaičiavimai mano DB struktūrai neaktualūs.



Veikti netrukdys, bet tikrinant DB struktūrą mes klaidą. Kad tokios klaidos "neištaisytų", reikia tiesiog nuimti nuo jos varnelę. Alternatyva, jei naudosi tik vienos struktūros DB gali persirašyti DB sukūrimo scriptą pagal poreikius. (tiesa atnaujinimo metu scriptas siekant atspindėti eilinių vartotojų poreikius yra overwrite'inamas, taigi po update'o riekės vėl persikopijuoti, taip pat galima nesunkiai padaryti alternatyvaus scripto galimybę, scriptas randasi programos folderyje program files kaip atskiras .sql failas)

Na, galima ir taip išsireikšti



Pas mane nieko panašaus, nebent aš kažką ne taip supratau.
Šita funkcija nėra atkuriama, kada iš backupo atkurinėjama duombazė. Čia jau serverio ypatumas, nelabai ką galiu padaryti. Kitais atvejais viskas veikia korektiškai.
O kurią serverio versiją naudoji?

Jei ir po paskutinio update'o nerodys lietuvybės, reiškiasi swedai nusprendė atsisakyti bendro LITAS-ESIS v1.2 standarto. Standartą galite rasti čia:
www.lba.lt/index.php/lt/28751/

pretenzijos dėl jo nesilaikymo bankams. SEB, ačiū dievams, laikosi šio standarto preciziškai.

Update ištaisyta netinkamas prekių operacijų rodymas prekių operacijų formoje (kartais vietoj vienos rodydavo dvi ar daugiau identiškų operacijų, nors DB viskas gerai). Update taip pat pakeista e-banko duomenų importui naudojamos koduotės versija (iš "ISO-8859-13" į "windows-1257"; teoriškai šios koduotės yra identiškos, bet LITAS-ESIS formate naudojamas "windows-1257" pavadinimas; nežinau, ar turės kokią nors įtaką).

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

Pakaktų ir pirmą puslapį perskaityti... Serverį instaliavote?

Nu atsiliepiau, i ką?
Greičiausiai galėsiu, jei ČP neįvyks.
Tikiuosi mašinos plotis ne mažesnis nei golfo, nes gali kilti problemų su mano kibiro įtalpinimu. Nors jei nebus giedra, kibiro ir vienos vietos neprireiks.

Beje, gal yra kas iš Molėtų arba pro Molėtus pravažiuojantys. Beatostogaudamas dalį įrangos palikau ir nežinau, ar iki liepos galo tuose kraštuose būsiu atsiimti

Update vieno vartotojo prašymu avanso apyskaitoje numatyta galimybė naudoti dok nr ne tik SF atveju, bet ir su bet kokiais kitais dokumentais, taip pat spausdinamoje apyskaitos formoje lentelės grafoje "Kam, už ką" bus rodomas priskirto asmens pavadinimas (kerpamas ties 60 simbolių), kabliataškis ir sf/apraše nurodytas pagrindas, nevišijant bendro 100 simbolių ilgio.

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

P.S. Po šio update'o ir vėl teks atsinaujinti duombazių struktūrą.

Artimiausioje ateityje ne. Čia yra tam tikrų gilesnių problemų. Nepakankamai apgalvota BO atvaizdavimo gride metodika.

Priklausomai nuo bankų naudojamų formatų stabilumo, importą galima nesunkiai padaryti iš skirtingų šaltinių. Bet: reikia žinoti pateikiamų duomenų tikslų formatą ir būti įsitikinusiam, kad bankui nešaus į galvą kokio laukelio pastumti.

Žodžiu, jei apsiimtumėte pasirašinėti su bankais email'ais, gautumėte jų naudojamus standartus ir išsiaiškintumėte jų stabilumą laike, galėčiau padaryti.

Šiaip LT yra tik vienas oficialus tarpbankinis e-duomenų standartas LITAS-ESIS, bet kažkodėl ir jo kai kurie bankai nesilaiko.

Jei mokate tvarkyti apskaitą dvigubu įrašu, tada taip. Nors programos prekių gamybos funkcijos yra nepritaikytos auginimui, t.y. gamybai iš nieko. Tektų derlių pajamuotis per paprastą BŽ įrašą.

Update ištaisyta klaida kai kurių formų spausdinime. Bevalydamas kodą mažumėlę persistengiau

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

Šitų klaidų man pakartoti nepavyko. Šiaip jau to negali būti, nes žiniaraštyje ir jų sąraše yra taikoma absoliučiai identiška formulė GPM skaičiavimui. Gal kažkokia skaičių kombinacija įdomi. Atsiųskite asmenine žinute visus skaičiavimui naudotus duomenis.

Programa skaičiuojant DU už <2009 m. paprasčiausiai nekreipia dėmesio į tarifus, pakanka nustatyti teisingus GPM ir SODROS tarifus.

Update ištaisytas klaidingas IT vertės rodymas, kada IT yra perkeliamas su apskaitos likučiais ir sukaupta amortizacija.

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

Po pastarojo atnaujinimo reikia atsinaujinti DB struktūrą

Ir dar du klausimai:
- kokioje spausdinamoje DU žiniaraščio formoje ir kaip reikia rodyti žiniaraščio komentarus? (šiuo metu jų niekur nespausdina)
- ar reikalingas/prasmingas GPM perskaičiavimo kalkuliatorius?

Realiai GPM perskaičiavimas paaiškėjus pajamoms (pvz, SODROS pašalpai) reiškia laukelį (atliktus apskaičiavimus fiksuojant žiniaraščio komentaruose).

Update ištaisyta pridėta:
1. Pilnai sutvarkytas GPM ir SODROS deklaracijų generavimas;
2. Pridėta galimybė priskirti prekes vartotojo susikurtoms grupėms ir formuoti apyvartos ataskaitas pgl grupes;
3. Ištaisyta klaida DU žiniaraščio formoje - į duombazę nenukeliaudavo formulė ir dėl to kildavo problemų atliekant žiniaraščio pakeitimus;
4. Ištaisyta klaida avanso apyskaitų formoje - mesdavo klaidą, kada vartotojas mėgindavo įvesti sąnaudas ne pagal faktūrą ir be PVM;
5. Pridėta galimybė komentuoti DU žiniaraštį (aktualu su dabartinėmis GPM perskaičiavimų peripetijomis);
6. Padarytas šioks toks DB klaidų atpažinimo mechanizmas vykdymo eigoje. Jei neatitiks DB struktūra ir dėl to kils klaida, bus automatiškai atidaroma DB struktūros tikrinimo forma. Tiesa, jei vartotojas primygtinai ignoruos šios formos atsiradimą ir kelis kartus ją uždarys, programa užlūš. Galima būtų dar tobulinti, bet jei vartotojas kvailas, tai jam niekas nepadės.

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

1. Paskutinis atnaujinimas (jei dar neinstaliuotas);
2. DB struktūros atnaujinimas.

kaip ir bet kokią kitą operaciją per BŽ formą.

Jei čia apie suminę eilutę lentelės apačioje, tai jos pridėjimas formoje yra nepatogus - tas paprastai nesuderinama su rūšiavimu pagal stulpelius, o rankiniu būdu perrašyti visą rūšiavimo logiką sudėtinga. Nesunku gi atsidaryti spausdinamą formos versiją, jei labai reikia.

5/6 uždarymas yra šventa operacija - po jos ankstesnius metus yra ir bus draudžiama. Jei norite taisyti ankstesnį laikotarpį - ištrinkite uždarymą, darykite reikalingas korekcijas ir perdarykite uždarymą.

FR0572 nėra visiškai išbaigta. Kol kas neskaičiuoja (neišskiria) sumų už perleistą turtą ir nesuderinama su ankstesniais (<2009) metais. Liko darbo porai valandų, kurią dieną kitą savaitę pabaigsiu.



O konkrečiau? Kuri grafa ko nesumuoja?

Update ištaisyta/pridėta:
1. FR0572 trečios versijos generavimas;
2. Klaida darbuotojo kortelėje rodant išmokų už šventine/poilsio dienas dydį;
3. Klaida buvo neteisingai nustatomas asmens SODROS kodo stulpelio tipas.

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

Atliekant GPM perskaičiavimą santykyje su SODROS ligos pašalpa, kaip koresponduoti papildomai priskaičiuotą GPM?

Kreditas tai kaip ir 4462 Mokėtinas gyventojų pajamų mokestis, o debetas?

DK 224 str. nenumato tokio išskaitos iš DU pagrindo kaip mokesčio perskaičiavimas, o skaičiavimo klaidos sąvoka čia vargu ar pritaikoma (nebent seimo klaida)

O gal paprasčiausiai sumažinti perskaičiavimo mėnesio taikytiną ?