Jei nežinote DU skaičiavimo ir apmokestinimo dalykų, klauskite atitinkamose temose. Tai nieko bendro neturi su šios programos naudojimu.

Programa viską tvarko pagal buhalterinių dokumentų logiką. Pervedei pinigus per banką - banko operacija. Gavai grynus pinigus - . Užskaitos tarp atskaitingo asmens ir tiekėjų (apmokėjimai per atskaitingą) - avanso apyskaita.

Nelabai suvokiu, kodėl avanso apyskaitos dokumentui turėtų būti įdomios banko ir kasos operacijos.

Elementari banko operacija, registruojama importuojant banko duomenis arba rankiniu būdu. Analitika - atitinkamas darbuotojas.



Avanso apyskaitos eilutė, formuojama be sąskaitos, nurodant atitinkamą sumą ir tiekėją, kuriam sumokėjo. Koreponduojant sąskaita gali būti tiek 2 klasės avansiniai apmokėjimai, tiek ir tiesiogiai 4 klasės mokėtina tiekėjams. Man labiau patinka antrasis variantas, nes visas judėjimas su tuo tiekėju matosi vienoje sąskaitoje, o ne per dvi. Be to, nebereikia uždarančių įrašų.



Paparastas kasos pajamų orderis.

I togo trys skirtingų tipų per skirtingas formas vedamų operacijų. Plius dar viena, kai tiekėjas SF išrašys.

Koreguoti IT įsigijimo duomenis leidžiama, TIK jei nėra operacijų su tuo IT. Ištrinkite visas IT operacijas (įskaitant amortizacijos laikotarpio nustatymo) ir leis koreguoti.

Ir dar įkėliau paskutinę visos programos instaliacinio paketo versiją ir einamąjį programos kodo archyvą.

Update ištaisyta:
1. Keletas smulkių klaidų, kildavusių koreguojant avanso apyskaitas;
2. Įdėtas FR0671(2) ir FR0672(2) generavimas. Naujos versijos deklaracijos yra generuojamos, jei datos intervalo viršutinė riba >2008 m. rugsėjį (tada šios deklaracijos versijos įsigaliojo). Priešingu atveju generuojamos senos formos deklaracijos.
3. Uždrausta per IT modulio formas trinti IT įsigijimo įrašus, sukurtus per SF modulį;
4. Prekėms pridėti pirkimo ir pardavimo kainų laukeliai (naudojami TIK SF pildymui pagreitinti);
5. Gautų SF registravimo formoje sumų paklaidos padidintos iki +-9 centų;
6. Laikinai (o gal ir nuolat) atjungtas automatinis programos atnaujinimas. Microsoftas savo serveryje, kuriame saugomi mano programos failai, įsidėjo apsaugą, kuri neleidžia parsisiųsti failo, prieš tai vartotojui nepasigrožėjus puslapio vaizdu. Jei sugalvosiu kaip tą apsaugą apeiti, padarysiu, kad vėl veiktų;
7. Jei sukurta/prieinama tik viena įmonė, bus automatiškai prie jos prisijungiama.

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 reikės atsinaujinti duomenų bazės struktūrą.

Man tokios klaidos sukelti nepavyko. Ką tiksliai suvedėte?

Pavadinimas JAR'e jau rezervuotas. Pirmadienį bus surinkti visi galutiniai dokumentai. Teigtina, kad vėliausiai iki kovo 20 d. bus baigti visi steigimo formalumai ir atidaryta banko sąskaitą, o gal ir greičiau.

Galimas ir toks metodas, kokį aprašote jūs. Tiesiog programuodamas pasirinkau man labiau patinkantį ir paprastesnį metodą - nenaudoju atskiros sąskaitos sukauptam nusidėvėjimui, o tiesiogiai nukreipiu į įsigijimo savikainą. Pasiekiamas rezultatas identiškas.

Nėra tokio reikalavimo, pakanka paramos sutartėlėje nurodyti "visuomeniškus ir kilnius" tikslus. Jei abi įmonės taip sutaria, jokių tarpusavio sąmatų/ataskaitų teikti nereikia, tik VMI deklaracijos.

Nesuprantu, kodėl visi tingi skaityti forumą...
1. Įsidėti paskutinį update'ą (jei neįdėtas);
2. Atnaujinti DB struktūrą.

Šiaip jau su šiuolaikinėmis komunukacijų galimybėmis ir trupučiu organizacijos viską galima išspręsti konstruktyviai:
1. Visi, kas gali ir nori atvežti kokių nors maisto produktų, informuoja Elvusia apie asortimentą ir kiekybę (iki kažkokios datos);
2. Elvusia apibendrina, kas gaunasi, palygina su poreikiais ir sukuria centralizuotai perkamo maisto sąrašą;
3. Visi vykdo savo pažadus.

Planuoju, kada pasirodys bent jau SODROS deklaracijų formos, nes duomenys apie atorines ir pan. yra svarbūs būtent deklaravimo tikslais ir atitinkamai būtina žinoti deklaracijų formas.

Savaitgalį planuoju padirbėti ties programa, kol kas numatomų korekcijų sąrašas toks:
1. Ištaisyti klaidas redaguojant avansines apyskaitas;
2. Prekėms pridėti laukelius pirkimo ir pardavimo kaina;
3. Uždrausti trinti IT įsigijimo įrašus, kada įsigijimas registruotas per SF.

Jei dar ko reikia, rašykite.

Atsinaujinkite programos versiją (įsidėkite paskutinį update'ą) ir pasitaisykite duombazių struktūrą (Bendras\DB struktūra).

Po tokių paaiškinimų kyla abejonių ne tik dėl "pradedančiosios", bet ir dėl "buhalterės".

Nežinote įstatinio kapitalo korespondencijų - labai keista, tai tikriausiai pirmas pavyzdys visuose apskaitos kursuose, nes tobulai atspindi fundamentalią lygybę TURTAS=NUOSAVYBĖ. Kaip pradedančiai gal ir būtų galima atleisti, tarkime pamiršote ir forumo temą klaidingai pasirinkote. Nu bet rimtai patikėti, kad tas daroma per likučių perkėlimą, tai jau virš visko. Tam atsakyme žmogus paprasčiausiai nesuprato klausimo, galvojo, kad jau veikiančią įmonę norite pradėti vesti.

Gal jūs geriau nebandykite kol kas pulti gadinti gyvenimo realioms įmonėms ir dar pasimokykite.

Nelabai noriu to realizuoti dėl labai objektyvios priežasties - atsiranda dar didesnės skaičiavimo paklaidos, pavyzdžiui:
ROUND(kiekis*vntkaina*nuolaida)<>ROUND(ROUND(kiekis*vntkaina)*nuolaida)

Tas ženkliai paaštrintų ir dabar visose programose randamą vieno cento problemą.

Programa apskaito išimtinai finansinę prasmę turinčius duomenis. Pareigos neturi finansinės išraiškos ir nėra naudojamos jokiuose apskaitos dokumentuose, todėl jos niekur nėra registruojamos programoje.

Konkretaus sąrašo nėra, yra daugiau mažiau bendro pobūdžio teisė gauti informaciją.
Mano nuomone, teikti reikia viską, išskyrus dokumentus, kuriuose yra asmens duomenys, pvz., konkretaus darbuotojo DU matosi DU žiniaraštyje, todėl jo teikti nereikėtų. Jei prašoma didelio kiekio informacijos ar dokumentų, darbdavys turi teisę prašyti sąnaudomis pagrįsto atlygio už informacijos parengimą, pavyzdžiui, 50 ct. už lapą ar pan.

Perinstaliuojant kažkas buvo rimtai pridirbta. Galbūt padėtų švarus serverio ištrynimas ir nauja instaliacija, bet nesu tikras.

Techninė šios problemos pusės buvo aptarinėjama mysql forume:
forums.mysql.com/read.php?22,33999,248738#msg-248738

reziumė - nieks tiksliai nežino, kokia jos priežastis, bet kažkas ryškiai blogai serverio ir (ar) OS lygmenyje.

Problema supratau. Del pasikeitusios duombazes strukturos pasikeite teisiu 'formuluotes'. Senu 'formuluociu' palaikymas butu problemiskas, be to, nemanau, kad tai bus masiska problema. Atsiusiu po poros valandu sakini, kuris jusu konkrecia problema isspres. Jei dar kam kils tokia pat problema, rasykit man asmenine zinute

Arba dar galit bendras/Query browser ivykdyti sakini 'SHOW GRANTS;' (be kabuciu su kabliataskiu) ir gauta atsakyma atsiusti man

Tikriausiai kaltas as su paskutiniu atnaujinimu, bet kol negrisiu, nieko negaliu padaryti. man bet kuriuo atveju reikia zinoti, kokias teises turit, paklauskit to, kas suteike

Grisiu vakarop namo, paziuresiu. O kokios teises vartotojui suteiktos?

Update ištaisyta:
1. Daug klaidų, susijusių su vartotojų administravimu (dirbant per tinklą), atsiradusių per ilgą laiką kintant duombazės struktūrai;
2. Spausdina darbuotojo kortelę, nors man asmeniškai forma neestetiška.

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

Asmenines žinutes reikėtų paskaityti

Kokia klaida, nepastebėjau jokio pranešimo.

Geriausia kada vertėjas yra lietuvių-kiniečių, o ne lietuvių-kiniečių, anglų, vokiečių ir svahili



Abu atvejai turi savų privalumų ir trūkumų. Man asmeniškai patinka kiekvienai konkrečiai užklausai ar transakcijai atidarinėti/uždarinėti connection'ą, bet čia daugiau skonio reikalas. Šiaip šiuolaikiniai SQL serveriai gana neprastai naudoja connection pooling'ą, kuris abu atvejus stipriai suvienodina.



Nesupratau, kas turima omenyje. Bet tobulos programos architektūros pačios savaime neegzistuoja. Dabar populiaraisios 3 sluoksnių architektūros programos, nors pilna pavyzdžių ir 2 arba >3 sluoksnių. Kuo daugiau kodo tarp UI ir data persistence, tuo lėčiau viskas veikia. Iš kitos pusės, galima ir priešinga situacija. 2-tier architektūra dirbant su duombaze, kurioje milijonai eilučių ir didelis krūvis, jau traukia link mazochizmo. Tada jau reikia tarpinio sluoksnio, kuris naudotų kelis replikuojamus SQL serverius paskirstydamas krūvį. Ir iš viso galimos įvairios situacijos ir dar įvairesni sprendimai.
Vidutinei įmonei su norais turėti galimybę dirbti per inetą, šiai dienai aš rekomenduočiau naudoti remoting'o arba web service'o technologiją. Tik kiek žinau, jokia lietuviška programa to nepalaiko, priešingai toliau žaidžia su pasenusiomis technologijomis iš serijos FoxPro "data base container", COM+, ODBC ir t.t. Kas keisčiausia niekas nenaudoja senos, bet tikrai geros enterprise service technologijos.



Viliuosi, kad čia iš jumoro kampelio. Eiliniam useriui siūlyti dirbti per VPN'ą yra vienok originalu

Rasti galima čia: www.lat.lt/default.aspx?item=tn_liteko&lang=1

Bet jūsų nurodytas numeris nėra LAT bylos numeris, struktūra neteisinga.