Negaliu sutikti. Punktai yra pagal gyventojo veiklos teisinį kvalifikavimą, o ne pajamų rūšį. Juk pirmame punkte kalbama apie darbuotojus, o ne darbo užmokestį. Mano nuomone, tos kitos pajamos gali reikšti kitas gyventojo gaunamas pajamas, apmokestinamas GPM, bet ne išmokas, susijusias su darbo santykiais.

[quote=Petronele]
Esmė tokia: visos pajamos, kurios apmokestinamos GPM, apmokestinamos ir

"

Man atrodo, kad tas reiškia, kad nuo ligos pašalpos (darbdavio lėšomis) neskaičiuojamas

[quote=Loreta]Ir dar, Samajana, nepamiršk, kad

Gal galėtumėte pagrįsti

Mano galva GPM dalimi iki reformos. Dabar gi turime du savarankiškus įstatymus be nuorodų į vienas kitą...

Gal kas netyčia žino, kaip po šitų mokesčių reformų reikia koresponduoti DU žiniaraštį ir kaip pats žiniaraštis turėtų atrodyti?

Pažeidimas, bet jei toks grafikas nuolatinis, galima susišluoti padorią sumą už viršvalandžius (už trejus metus vidutiniškai 16 val. viršvalandžių per savaitę, t.y. maždaug 20 proc. darbo užmokesčio, "i togo" apie 6 mėn. atlyginimą).

Tingėdamas dirbti per pusvalandį pritaikiau programą naujam npd skaičiavimui, bet iškilo klausimas kaip turi atrodyti DU žiniaraščio korespondencijos naujojo mokesčio šviesoje?

Grybavimas su centais atsiranda dėl dviejų priežasčių:
- DU žiniaraštyje mokesčiai skaičiuojami kiekvienam darbuotojui atskirai, o DU žiniaraščiuose visam žiniaraščiui sumuojant priskaičiavimus;
- Nenuspėjamas serverio elgesys, kada susiduriama su apvalinimu ir 5 (žr. aukščiau).

Bandysiu savaitgalį spręsti. Įtariu, dideliam mano nenorui teks pasitelkti savos kūrybos apvalinimo procedūrą serveryje.

Atitinkamai klausimas buhalteriams: ties kuria apvalinimo taisykle apsistoti:
- visada į mažesnę pusę;
- visada į didesnę pusę;
- visada link apvalaus skaičiaus (bankinė arba statistinė apvalinimo taisyklė, labiausiai paplitusi kompiuterių technologijose).

www.vilniauskompiuteriai.lt/kompiuteriu-taisymas-ir-remont...

Nežinau, ar jums pavyks įvykdyti surašytas instrukcijas, bet jos teisingos.

Kas neleidžia?



Kad lig ir helpe aiškiai viskas parašyta. Įvedate atitinkamus naujus parametrus tai pačiai DS ir tiek. Pvz., jei 2008-01-01 sudarėte DS, kurios nr 5, tai nuo 2009-01-06 įvedate 5 numerio ds naują krūvį. Programa pasirinkus žiniaraščio datą atsirenka aktualų tai datai parametro dydį.



Programa skaičiuoja (bando skaičiuoti) kiek kalendoriškai tą mėnesį buvo darbo dienų ir valandų, tada gautą dydį daugina iš krūvio. Ši sistema į tobulumą nepretenduoja (bent kol kas), taigi formuojant DU žiniaraščius reikia atkreipti dėmesį į tai, ar teisingai nurodytas grafikinių ir faktinių dienų, valandų skaičius.

Dėl GPM programą atnaujinsiu savaitgalį.



Gruodžio mėn algą mokėdami už sausį taikytinus tokiam mokėjimui tarifus įvesite Darbuotojai->nustatymai, vėliau pakeisite į "stabilius" tarifus. Žiniaraščiai atsimins jų formavimo metu taikytus tarifus.

Eikite į įsigyto IT operacijas ir pašalinkite įrašą apie amoertizacijos laikotarpio nustatymą. Tada leis keisti SF.

Update ištaisyta:
1. Keičiant sąskaitų numerius (jau egzistuojančios sąskaitos numerį), automatiškai nepakeisdavo avanso apyskaitoje nurodytų numerių. Todėl po tokio pakeitimo galėjo nebesueiti balansas dėl nerandamų korespondencijų. Jei kam tokia problema kilo, reikia patikrinti avanso apyskaitas, ar kur nenusimušė sąskaita.
2. Sąlygiškai ištaisyta aukščiau minėta problema su apvalinimu. Visiškai išspręsti bent kol kas negaliu. Bėda tame, kad programavime yra naudojami trys apvalinimo algoritmai. Programa turėtų taikytis prie serverio, bet pats serveris neturi stabilaus algoritmo (priklauso nuo C bibliotekos konkrečioje versijoje ir operacijos kintamųjų tipo). Dar didesnė bėda ir būdinga ji visoms programoms, naudojančioms kintamųjų tipus double/single/float (o tokių tikriausiai absoliuti dauguma, jei ne visos), yra paties tokio tipo skaičiaus neapibrėžtumas. Šių bėdų kombinacija reiškia bėdas, kai prireikia apvalinti skaičius su penketais, pavyzdžiui, "2,225" gali su vienoda tikimybe virsti "2,22" arba "2,23". Dabar įdėjau rankinį apvalinimą į mažesnę pusę, nes toks algoritmas naudojamas mano MySQL serverio versijoje. Bet nesu tikras, ar tas veiks visose serverių versijose.
3. Perdariau pranešimo formą (kur iššoka ir kažko paklausia ar leidžia pasirinkti). Ji turėtų stengtis įgyti auksinę proporciją (pgl. fi). Bet nežinau, ar tas ypatingo grožio pridėjo.

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. Norintiems pasigilinti į skaičių sampratą ir apvalinimo problemas kompiuteriuose, galite žiūrėti čia:
http://blog.troyd.net/Bankers+Rounding+Vs+Common+Rounding+In+NET.aspx
arba moksliškiau:
docs.sun.com/source/806-3568/ncg_goldberg.html

Atsiųskite to žiniaraščio visus parametrus (su darbuotojais) asmenine žinute arba e-mailu.

Negalėtų, nes tada sulauksiu pasipiktinimo laiškų iš dešimčių buhalterių, kurioms patinka kasą vesti jų mėgiama tvarka, pavyzdžiui, iš pradžių visus KIO, o tada .



Techniškai neįmanoma neperkraunant serverio.



Jei kasa yra tikra, tai pinigų joje stebuklingai neatsiras, nebus, ką išduoti, nebus KIO, nebus minuso ir raudonuoti nereikės ir šiaip kio atsiradimas pernykšte data keistokai atrodo.

Ltd. verčiasi kaip "limited", tai angliškos AB arba UAB žymuo, reiškiantis, kad bendrovė yra ribotos atsakomybės. Santrumpa bus suprantama daugiau mažiau visam pasaulyje.
JSC šifruojasi kaip "joint stock company", čia jau išimtinai lietuviškas išradimas pažodžiui atkartojantis UAB, bet visiškai neprasmingas užsieniečiams (ar bent daugeliui jų).

Jei dėl grožio - teisingiaus JSC, jei dėl užsieniečių - Ltd.

Update ištaisyta:
1. Klaida banko formoje (mesdavo klaidą bandant trinti apskaitoje registruotą operaciją);
2. Klaida likučių perkėlimo formoje (taisant likučių perkėlimo operaciją likučio įrašo ID buvo "perstumiamas", dėl to "dingdavo" turto ir prekių įrašai, susieti su likučių perkėlimo operacija, t.y. patys įrašai niekur nedingo, bet rodo į klaidingą BŽ operaciją);
3. Kontrahentų (asmenų) formoje įvestas mygtukas su gaublio paveiksliuku. Įvedus asmens (įmonės) kodą ir paspaudus šį mygtuką, programa mėgins gauti visus duomenis apie tą asmenį iš JAR ir VMI duombazių.

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. Tie, pas ką "dingo" turto ar prekių įrašai, rašykite asmeninę žinutę, paaiškinsiu kaip padaryti, kad atsirastų. Update'as pats savaime dingusių įrašų nesutvarkys.

[quote=Juskevic] Dėl

Mane konsultuojanti buhalterė laikosi nuomonės, kad tokios teisės Jūs neturite. Pagrįskite, kas Jums suteikė teisę kilnoti per mėnesius.



O helpo skaityti nebandėte (Pagalba/Pagalba)? Žmonės stengėsi, rašė, o dabar niekas neskaito.

Nuo procesinių palūkanų (6 proc.) žyminis nemokamas ir jų (palūkanų) dydis konkrečia suma neskaičiuojamas taip pat. Apskaičiuoja antstolis vykdymo metu.

Skolų išieškojimo kompanijos gerai dirba prevenciškai (patikrina klientus prieš sutartį). Išieškoti jokių stebuklingų galimybių jie neturi.

Jų paslaugos teikiant info apie potencialius klientus yra panašios į draudimą. Turėjau tokį atvejį: klientas buvo sudaręs sutartį su Žvilgsniu iš arčiau ir pasitikrindavo prieš sutartis sudarydamas (~1000 Lt. per metus), dvejus metus nepasitaikė jokių abejotino mokumo asmenų, todėl klientas nutarė atsisakyti tokios praktikos. Tik po poros mėnesių užtaikė ant nemokaus asmens ir teko nurašyti į beviltiškas skolas ~2500 Lt.

[quote=Rolanda]to Niemand: praturtėjus be pagrindo pagal LR XX sk. 6.237 str. ?
Nepagrįstas praturtėjimas - dėl jo atsiranda civilinė pareiga grąžinti nepagrįstai gautas pajamas (

Sakyčiau žiopla klaida gali būti traktuojama kaip sąskaitybos klaida.

2002 m. lapkričio 13 d BĮ UAB “Motorida” v. Donatas Kulvičius Civilinė byla Nr. 3K-3-1355/2002 m.
"Darbo įstatymų kodekso 139 straipsnio 3 dalis leidžia išieškoti iš darbuotojo jam permokėtas sumas, jeigu tai įvyksta dėl skaičiavimo klaidos. Lietuvos Aukščiausiojo Teismo praktikoje sąvoka “skaičiavimo klaida” yra aiškinama kaip sąskaitybos klaida (Lietuvos Aukščiausiojo Teismo Civilinių bylų skyriaus teisėjų kolegijos 2001 m. balandžio 4 d. nutartis civilinėje byloje AB “Lietuvos radijo ir televizijos centras” v. J. Basalykas, Nr. 3K-3-417/2001, kat. 5.5.). Sąskaityba nagrinėjamos bylos prasme reiškia ne tik aritmetinį darbo užmokesčio skaičiavimą, bet ir kitus veiksmus, susijusius su darbo užmokesčio apskaita ir išmokėjimu (žodis “sąskaityba” lietuvių kalboje apibrėžiamas kaip sąskaitų tvarkymas: Dabartinės lietuvių kalbos žodynas. Vilnius, Mokslo ir enciklopedijų leidykla, 1993, p. 677). Pirmosios instancijos teismas, remdamasis ieškovo pateiktais įrodymais, pagrįstai pripažino, jog atsakovui buvo be pagrindo du kartus išmokėtas darbo užmokestis ir tai įvyko būtent dėl buhalterinės sąskaitybos klaidos. Toks Darbo įstatymų kodekso 139 straipsnio 3 dalies aiškinimas ir taikymas atitinka tiek Lietuvos Aukščiausiojo Teismo praktiką, tiek ir teisingumo, sąžiningumo ir protingumo principų reikalavimus ( 1.5 str.)."

Nors tokiais atvejais žinoma yra problematikos.

[quote=Juskevic]Ar yra galimybė pritaikyti kitą

O taip galima elgtis?



Jūs gal ir negalėsite, o programa įtrauks automatiškai. Motinystės atostogos nėra specialiai apskaitomos programoje, tiesiog tiems darbuotojams neformuojami DU žiniaraščiai, SAM formoje jie atsiduria kaip ir priklauso su nuliais.



O kas trukdo?



Tik jei atsiras vilnietis buhalteris, išmanantis prekių apskaitą, kuris sutiktų sudaryti jų algoritmus (ar bent jau išsamiai akivaizdžiai paaiškintų jų veikimo principus).

Akivaizdžiai darėte, bet čia mano kaltė, programos klaida, pasistengsiu ištaisyti šiandien. Pažiūrėkite bendrojo žurnalo formoje, koks ID suteiktas likučių perkėlimo operacijai.

Grąžinti be abejonės reikės, tik čia abejoju ar DK iš viso būtų taikomas. Elementarus nepagrįstas praturtėjimas PO darbo santykių pabaigos. Tiesa, tai visiškai nieko nekeičia iš esmės. Darbdavys pirmiausia kreipsis į teismą, tik tada galės į antstolius.

Neturėtų, bet geriau paklauskite cento autorių, ar centas nenaudoja 3306 porto arba duombazės, kuri būtų nesuderinama su MySQL.

Na tai, jei kada savaitėlei paskolinsite ir užvešite į Vilnių, prijungsiu prie programos.

Nežinau, gal kas ir prijungė, teoriškai tas yra paprasta. Aš pats tokių galimybių neturiu, nes negaliu gauti kasos aparato eksperimentams.

Update'as čia ne prie ko, jame nebuvo niekas keičiama turto modulyje.
Įtariu čia ta pati mistinė problema su IT, kurios priežasčių niekaip negaliu suvokti.
Prisijunkite prie reikiamos įmonės, nueikite į Bendras/Query browser ir surinkite tokią komandą (be kabučių su kabliataškiu gale):
"SELECT * FROM turtas t LEFT JOIN bz b ON b.Op_ID=t.Isigijimo_dok;"
Stulpelyje "Isigijimo_dok" skaičiai turi atitikti bendrajame žurnale rodomus susietų įsigijimo operacijų ID. Jei neatitiks, parašykite kokie neatitikimai.

1. Jei neatitiks, parašykite kokie neatitikimai.
2. Kokias operacijas darėte prieš IT "dingimą"?
3. Ar nekeitėte likučių perkėlimo įrašo (nespaudėte mygtuko "Įvesti" likučių perkėlimo formoje nepriklausomai nuo pakeitimų buvimo)?

Update ištaisyta:
1. Banko duomenų importo formoje "nebekvailioja" spalvinimas ir jau esančių DB operacijų rodymas/slėpimas pakeitus atitinkamą checkbox'ą.
2. Pakoreguotas skaičiaus formato atpažinimas. Kai kuriais atvejais gali užkirsti kelią klaidoms. Nors pasitaiko retų atvejų, kada programa nesusikalba su kompo regioniniais nustatymais. Jei po šio update'o vis tiek mes klaidą, lieka tik grąžinti normalius lietuviškus regioninius nustatymus.

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

Būtų džiugu, jei klaidos pranešime paspaustumėte mygtuką Details.
Nors greičiausia čia jūsų kompo regioninių nustatymų problema. Žr. Start\Settings\Control panel\Regional and language options.

Dėl statybos darbų ir juos atliekančių specialistų licencijavimo, sertifikavimo geriausia konsultuotis su Statybos produktų sertifikavimo centru www.spsc.lt/. Tiesiog paskambinti į atitinkamą skyrių, išvardinti planuojamus darbus ir paklausti ar kuriems nors iš jų yra kokie nors reikalavimai.