Kaip išsirinkti naują apskaitos ir verslo programą????

Ot čia tai aukštasis pilotažas !
Nieko nesupratau, tik įdomu, kodėl visame tame pilotaže nenaudojate tokių dalykų kaip Atsakomybės centrai, Tikslinės paskirtys, Projektai, Balanso ir PN(PL) skirtingų formulių komplektai ir t.t. Gal bent tų įspūdingų subsaskaitų galima būtų išvengti?
IT-ui gal taip pat galima būtų turėti dvi duomenų bazes, su skirtinga skaičiavimo baze, ir atskirai koresponduoti į Dkn.
SP-e taip pat peršasi mintis, kad prie kiekvienos sąskaitos Nr. galima būtų su programuotojų pagalba padaryti TAS analogus su apjungimo forulėmis.
Ar aš čia "ne apie tai"?

Na, dvieju IT knygu i viena DK nesuintegruosi. Arba, jei integruosi, gausis per daug palaikymo reikalaujanti sistema.

Pvz: Pirkai laptopa uz 3 000 Lt. Kaip daryt irasus i DK, jei, tarkim, vietoje pasitvirtines 500 Lt. IT kapitalizavimo norma, o grupe - 1.500 svaru?

Vietinese ataskaitose turtas turi buti itrauktas i turto saskaita ir veliau nudevimas, o grupes ataskaitose turtas is karto turi buti nurasytas - ir cia tik pradzia.

Paskui 3 metus vietinese ataskaitose tas kompas generuos nusidevejima, kuris tures visada buti reversuojamas grupes ataskaitose, nes turtas grupes ataskaitose buvo nurasytas jo isigijimo metu.

Skirtumai del turto pripazinimo salygos skirtumus akcininku nuosavybes / pelno dydziuose.

Nezinau, ar yra sukurta apskaitos programa, kuri palaikytu tokius bajerius.

O kaip suprast "reconciliatinima darau uzbalansinese saskaitose" ?

Nu joooooooooo...

[quote:886a5a4053="Svečias"="Svečias"]Jau kelintas mėnuo bandome išsirinkti apskaitos ir verslo valdymo programą, bet.......... nesutariam kuri yra pati pati pati...geriausia ir nuostabiausia, o be to ir už priimtiną kainą... Įmonė užsiiima didmenine prekyba. Reikia 6 darbo vietų : direktoriui, vyr. buhalterei, apskaitininkei ir vadybininkams. Patarkite [/quote]

Siūlyčiau pabandyti Centą (www.centas.lt). Dabar jau pritaikytas darbui su SQL serveriu. Taigi darbo vietų skaičius neribojamas.

Na, visgi smagu, kad yra ir daugiau susduriančių su šia problema.
Tikrai labai naudingi patarimai. Vertėjo klausti Tur būt, badnysiu kurti kažkokį tarpinį savo variantą.
O darbdaviui, manau, galiu tvirtinti, kad gatavos programos, susietos su GAAP (tiksliau, programos karkaso) Lietuvos rinkoje kol kas nėra

Kreipkites į UAB "Intertrust" - pademonstrosime. Į 2, 3, ar 1000 skirtingų sąskaitų planų, skirtingai ir automatiškai, su galimybę vėliau koreguoti lengvai ir automatiškai per visus SP.

Atsiprašau, už reklamą, nesusilaikiau. Jei ką, tegul Admin ištrina mano postą.

Taip vienas gali būti naudojamas mokestinei, kitas finansinei (tuo tarpu ir pagal GAAP), trečias valdymo ir t.t. apskaitai tvarkyti.

Kas liečia MAPPINGO variantą, aprašytą aukščiau, tai jis atneša daugiau problemų, nei duoda naudos. Tas pats galioja ir įvairių rušių apskaitos vedimui skirtingose bazėse. Visu pirma pirmynę informaciją reikia vęsti kelis kartus, antra problema - kai rezultatai nesueina, surasti ir pakorėgoti klaidas praktiškai neįmanoma. Ir kas idomiausia: VISADA NESUEINA.

O kaip vadinasi toji programa ?

Gal galetum trumpai papasakoti apie algoritma, kuris butu naudojamas ?Sakykim, kai imone yra nusistaciusi kad ilgalaikis turtas kurio savikaina maziau 1 000 Lt. yra nurasomas i sanaudas, o grupe, kuriai priklauso imone, tokia riba laiko 5 000 lt.

Pvz. nori daryti imones ataskaitas ir nori daryti grupes ataskaitas.

Kokiu principu atskiriama, kur ka ideti ?

Atsiprašau, bet nenorėčiau plėstis, nes tai gali būti suprantama kaip reklama.

Jiegu trumpai, tai vartotojas aprašo tipinius pravedymus. Viename iš tokių pravedymų, budingų Sąskaitai-faktūrai turi būti nurodyta, kad jeigu lauko savikaina reikšmė yra mažesnė už 1 000, sistema turi atlikti tokias kontuotes į buhalterinį SP, jei didesnė - kitas kontuotes. Ten pat turi būti aprašytos ir kontotės į finansinį SP, kur savikaina yra liginama su 5 000.

Vėliau, formuojant dokumentą, patvirtinantį turto įsigijimą, kurio savikaina yra tarkime 2500Lt, vartotojas pasirenką sukurtą tipinį pravedymą ir sistema automatiškai pagal aprašytas taisykles formuoja skirtingas kontotes į finansinį SP ir buhalterinį SP.

Tai yra kiekvieno dokumento kiekviena specifikacijos eilutė gali skirtingai įtakoti skirtingus SP.


SP 1 <--D1,K1,sum1--- dokumento spec. eilutė ----D2,K2,sum2--> SP 2

Na, jei detum panegirika programai, tai tada butu reklama, jei pasidalintum algoritmu, tai sitai nebutu laikoma reklama, greiciau konkurencinio privalumo paskelbimas.

O kaip atsizvelgete i fakta, kad vartotojas paims ir padarys klaidinga kontuotes aprasyma, veliau pastebes ir pakeis i teisinga - bet kas bus su duomenimis, kurie buvo ivesti naudojantis klaidingu kontuotes aprasu ?

Kitas klausimas - o kas bus, jei vartotojas tik metu gale pastebejo, kad visus metus naudojo neteisinga kontuote ir nusprende visu metu irasus perdaryti naudodamas teisinga kontuote ?

Siam tikslui reiks kurti atskira kontruotes tipa ir aprasa ?

Ant kokios duombazes pastatyta programa ?

Realizavimo algoritmo ash pasakiti negaliu, nes jo nezinau, ne programeris

Darytu tai, ka ir dirbdamas su vienu SP. Yra speciali kontociu koregavimo procedura, kuri atshaukia visus pravedimus pagal neteisinga kontuote ir praveda ish naujo su nauja. Be to, kontote reikia ivesti viena karta ir ju teisingumas gan grieztai kontroliojamas (administracines priemones).

Dirbame su SQL DB. Kaip ir dauguma kitu panashaus softo kureju.

[quote:49e1ab3fbc]
Darytu tai, ka ir dirbdamas su vienu SP. Yra speciali kontociu koregavimo procedura, kuri atshaukia visus pravedimus pagal neteisinga kontuote ir praveda ish naujo su nauja. Be to, kontote reikia ivesti viena karta ir ju teisingumas gan grieztai kontroliojamas (administracines priemones).
[/quote]

Ar tik tai nebus tipine lietuvisku softu klaida, leidzianti isvengiant nauju - koreguojamu irasu darymo pakeisti praeities duomenis.

Kitaip sakant, kazkada sudarytos finansines atskaitomybes nebesudarysi antra karta vienas prie vieno, jei busi per ta laika pakeites bent vienos kontruotes aprasyma ?

Dar toks klausimelis - ar kontuociu istorija yra issaugoma, ar nauja to paties tipo kontuote uzdengia sena ?

Ar tik tai nebus tipine lietuvisku softu klaida, leidzianti isvengiant nauju - koreguojamu irasu darymo pakeisti praeities duomenis.

Kitaip sakant, kazkada sudarytos finansines atskaitomybes nebesudarysi antra karta vienas prie vieno, jei busi per ta laika pakeites bent vienos kontruotes aprasyma?

Dar toks klausimelis - ar kontuociu istorija yra issaugoma, ar nauja to paties tipo kontuote uzdengia sena ?[/quote]

Taip, tai bus "tipine lietuvisku softu klaida, leidzianti isvengiant nauju - koreguojamu irasu darymo pakeisti praeities duomenis"

Irashu stornas, priimtas Skandinavijos shalyse, nepatinka Lietuviams (ishvada ish bendravimo su vartotojais patirties). Klaidos yra taisomos be storno. Savaime suprantama yra Uzdarymo periodai, yra teisiu sistema (nevisi gali koregoti dokumentus, priklausomai nuo ju bukles) ir pan. Bet grieztos storno politikos mes nesilaikom. Kodel? Mentalitetai Danijoje ir Lietuvoje skirtingi. Ir ash nematau priezasciu kodel mes turime ish ju perimti tai, ka jie turi "blogo", o priskirti storna prie "gero" ash negaliu, nes nematau tam priezasciu.

Po to, kai jus pakeitet kontote ir paleidot procedura (tam tikram neuzdarytam periodui), seno balanso jus negausit. O kam? Jis gi buvo su klaidomis. O jeigu nebuvo, tai kam buvo keisti operacija ir leisti procedura? Suklidot? Na tada pakeiskit i sena ir vel paleiskit procedura. Yra kvailu zmoniu imoneje? Apribokit ju teises.
Atsekti ka kas kada ir i ka pakete galima. Taip pat kaip galima ir palikti sena operacija. Faktishkai ji visada yra ishsaugoma ir atstatyti viska visada yra imanoma

Aisku. As linkes prie to, kad visi irasai butu issaugomi originalaus, o ne pakeisto pavidalo, o esant klaidoms klaidingi irasai butu reversuojami ten pat, kur jie ir buvo itraukti, ir tik paskui uzklojami naujais irasais.

O norint keisti uzdaryta perioda reikia ji atidaryti, perleisti procedura ir vel uzdaryti ?

O kaip tuomet atsiminti, kuriam periodui buvo taikomos kokios kontuotes, jei, tarkim, keiti apskaitos politika nuo periodo X ?

Paprastai reikia perspausdinti visus registrus, kuriuose itraukti pasikeite irasai. Ar vartotojui reikia atsekti, kurie konkreciai irasai pasikeite, ar sitai padaro programa automatiskai ?

Programa atseka -> atshaukia senus pravedimus -> formuoja naujus. Plius perskaicioja nurashymus pagal FIFO (esant poreikiui) ir atlieka kitas operacijas (jeigu reikia).

Atsiminti nereikia, yra specialus interfeisas.

Taip, reikia atidariti, pakeisti ir uzdariti. Nevisi darbuotojai turi tokia teise.

1oo

Pasirodo yra programu, kuriose galima tureti skirtingus apskaitos standartus, nes kaupiami pirminiai duomenys ir nereplikuojami DK, o ataskaitas rengia galingas varikliukas, kaskart is pirminiu duomenu. Pakeiciam apskaitos schema ir jau turim nauja atskaitomybe su tais paciais pirminiais duomenimis.

Cia siaip, geros mintys apskaitos programu kurejams, zemiau citata is vienos opensource programos aprasymo:

Most applications replicate transaction data to be able to support the different accounting dimensions.

Compiere was designed to support multiple accounting. The concept of Set of Books was improved with the concept of Accounting Schema. An Accounting Schema is any combination of the following:

* Chart of Accounts
* Accrual or Cash-based accounting
* Accounting standard
* Costing method
* Accounting currency

Note, that in contrast to Set of Books, Calendar is not directly part of an Accounting Scheme, as you may have multiple calendars per accounting schema. The calendar is reduced to transaction support functions (open/close periods, summary postings, allocation definition ease of entry).

In contrast to most applications, Compiere differentiates Transaction and the resulting accounting consequences with the following benefits:

* Transaction data is not replicated
* You can add or discontinue an accounting scheme anytime
* You can generate accounting information for historical transactions
* You can modify or replace any attribute (and optionally regenerate the accounting)
* Easy to extend and to maintain
* Error tolerant (you correct it and regenerate)

Būtų poreikis ir pinigai tam poreikiui patenkinti...
Suburiate programerių komandą ir pirmyn

Man asmeniskai, tai labai panasu i marketinga.

Graziai parasyta, o realiai nieko gero.

1. Galingas varikliukas, kuris gali pernesti duomenys i saskaitu plana uz metus reikalauja galingo serverio. Isivaizduokite duombaze su kokiais 400 000 dokumentu per metus (tai nera labai daug). Tam kad juos pernesti reikia prabegti per VISU SIU DOKUMNTU VISAS SPECIFIKACIJOS EILUTES, atlikti matematinius veiksnius ir padaryti atitinkamus irasus i duombaze. Reali serverio verte apie XX 000Lt. Uztruks apie valanda. Geriausiu atveju.

2. Kiekvienas pirminio dokumento tipas turi kruva skirtingu kontavimo schemu. Plius isimtys. Aprasant norima "pernesimo i DK metodika" faktiskai reikia nurodyti schema KIEKVIENO DOKUMENTO KIEKVIENAI POZICIJAI. Kiek veiksmu turi atlikti buhgalteris - ziurekite 1 punkta.

3. Neimanoma tureti noryma atskaitomybe tada, kai ji yra reikalinga. Jeigu as siandien noriu gauti atskaitomybe pagal vienus standartus man reikia PAKEISTI KIEKVIENO PIRMINIO DOKUMENTO KIEKVIENOS SPECIFIKACIJOS POZICIJOS KONTAVIMO CCHEMA. Paleisti varikliuka, gauti duomenys. Rytoj man skambina sefas, sako nori gauti atskaitomybe pagal antra standarta ir MAN VEL REIKIA PAKEISTI KIEKVIENO PIRMINIO DOKUMENTO KIEKVIENOS SPECIFIKACIJOS POZICIJOS KONTAVIMO CCHEMA. Paleisti varikliuka. Gauti atskaitomybe. Poryt as noriu grizti prie pirmo varianto, noriu tvarkyti apskaita, man VEL..... Nors, protinga programos realizacija gali sumazinti darba.

4. Klaidu taisymas. Isivaizduokite kaip tai atrodo. Paleidi varikliuka, lauki. Nesueina galai, ieskai, kazka randi, pataisai, paleidi varikliuka, lauki, nepasitaise klaidos, pakeiti, paleidi varikliuka, pasitaise. Viskas gerai. Pakeiti visas schemas pagal antra apskaitos schema, paleidi varikliuka, lauki, yra klaidu, pakeiti kazka, paleidi varikliuka, lauki, pasitaise, ivedi kontavimus pagal pirma cshema, paleidi varikliuka, lauki, dabar jau pirmoje shemoje galai nesueina...

5. Musu programoje yra daug patogesnis ir daug pranasesnis mechanizmas, palaikantys apskaita pagal skirtingas metodikas. Taigi, tegul jie mokasi is lietuviu kaip reikia tai realizuoti programose, o ne mes is ju.

O atsakymas ar ne marketingas?


Compiere is for business with the level of functionality usually only found in expensive first tier ERP systems with revenue between $5M and $500M.
Taip, serveris gali kainuoti 8-10 tukst, nelygu kiek vartotoju, mano atveju tilpau i 2000 Lt.

Paprasciausiai kiekvienai operacijai galima priskirti kelias schemas, skirtingoms apskaitoms/saskaitu planams. Privalumas - operacija viena, duomenys vienakart irasyti, atskaitomybes kelios. Tik nestandartinem operacijom tektu kazka rankiniu budu priskyrineti

Sukuriam nauja schema ir pirmyn! sena tegul lieka!
Schema pirminiu dokumentu tipams, nebent netipinius reiktu pakoreguoti.
Dar karta apie principa: KIEKVIENA OPERACIJA TURI PO VIENA IRASA DUOMBAZEJE, BET PRIE JOS GALI BUTI PRIKABINTOS KELIOS SCHEMOS, KAIP TIE DUOMENYS ATSISPINDI ATSKAITOMYBEJE.

Matau dideli privaluma klaidu taisyme, juk operacijos duomenys tik vienoje vietoje, taisyti tik pirmine operacija... Klaidos ir atsiranda del duomenu nesinchronizacijos ivairiuose zurnaluose, knygose... ten pataisiau, o cia pamirsau

Olegai, jei vietoje sio susirasinejimo savo energija SKIRTUME zmoniu isprusimo kelimui, tai brangus vartotojai zinotu, kad didziausia VERTE yra ne gelezis ir ne programa, o paslauga: sprendimas, kuris palengvina versla, aptarnarnavimo kokybe ir pan. Vartotojai nepasirenge tinkamai sumoketi uz paslauga, gal paslaugos kokybe to neverta? Uzdaras ratas gaunasi.
Vakaruose VVS diegimo kastai 1 darbuotojui (radau internete):
duombazes licencija - $300
verslo valdymo sistema - $8000-10000
diegimas x1-x2 dar tiek.

Manau, kad Olegas visiskai teisus del lietuvisku programu. Man kartais atrodo, kad Navision, Scala ir kitos užsienietiškos programos - tai senos programos perprogramuotos su naujomis technologijomis. Lietuviškose programose yra realizuota žymiai daugiau originalių ir naujų idėju.
Kokia čia ptrograma, jei as, buhaltere, padariau klaida, as ja matau, noriu pataisyti ją taip, kad niekas nematytu, kad ten buvau kazka ne taip padariusi, o programa neleidzia. Atseik stornuok. O jei as galiu be to apsieiti, man tik skaiciukus pakeisti reikia. O visa kita yra mano problemos. Tai mano kaip buhalterės teisių suvaržymas. Kodėl aš būtinai turiu visiems demonstruoti savo klaidas ir neturiu teisės jų pataisyti net tokiu atveju, kai tai niekam nepakenks, nei VMI, nei savininkams.
Teko girdėti tokia istorija. Buhaltere stornavo įplaukos į kasą operaciją. Storno operacijoje aišku buvo C Kasa. Šefas pamatė atspausdintą diddžiąją knygą ir klausia "Kur padėjai pinigus? Kam juos išmokėjai iš kasos?" O išaiškinti, kad tai stornas jam juk beviltiška. Arba dar variantas. Dirbant su NAVISION buhalterė kreditavo ne tą pajamų sąskaitą. Pamatė, kad padarė blogai po kiek laiko. Tada ji tą sąskaitą debetavo ir kreditavo kitą pajamų sąskaitą, t.y. padarė koreguojantį įrašą. Tai va, kai ją tikrino VMI, reikėjo rašyti pasiaškinimą, kam ji sumažino pajamas. Kad kitur atitinkamai padidino, tai niekam neįdomu, tokia mat buvo tikrintojų kvalifikacija. Aišku savaime, viskas baigėsi gerai, bet tokių nesusipratimų nebūtų, jei programa leistų pakoreguoti perkeltą įrašą. O ar galima tai daryti, tai jau ne programos kūrėjų, o mano, buhalterės reikalas. Jei aš kažką ne taip padarysiu, tai ir atsakysiu. O jei kai kas mano, kad tai apsaugos nuo apgavysčių, tai labai klysta. Vėl turiu gerą pavyzdį, su HANSA programa. Įmonę tikrino auditorė. Buhalterė buvo padariusi kažkokią kliauzą, kurios nenorėjo parodyti. Tada ji padarė taip: iš HANSA programos ataskaitą eksportavo į EXCEL'į, ten išmetė keletą eilučių, kurių ji nenorėjo parodyti auditorei, o sumas galutines paliko tokias, kokias reikia, t.y. taip, kaip programoje. Va jums ir perkėlimai, geležiniai uždarymai.
Man atrodo, kad ir suprogramuoti tokią programą, kurioje leidžiamą viską laisvai koreguoti ir perskaičiuoti, žymiai sunkiau, negu tokią, kurioje padarei įrašą, ir jis užrakintas, baigėsi mėnuo, jis uždaromas ir baigta.
Taigi, mielieji užsienietiškų programų propaguotojai, baikit pūsti arabus žmonėms į akis. Jokio stebuklo ten nėra, tik pasenusios idėjos. Ir jūsų šūkis, kad tos programos leidžia "laisvai organizuoti apskaitos procesą įmonėje" labiau tinka lietuviškoms programoms, kurios kuriamos ŽMOGUI,
kuris klysta, bet turi teisę pataisyti savo klaidas.