Если бы только определение. Хуже, когда на самом деле аналитика не стыкуются с сальдо по счету. Порой вина в том, что в нужном месте "галочку" не поставили или еще чего-нибудь.

Ирен, у меня и не стыковалась. Пришлось каждой морде свой 2310, свой 5310, и т.д. приписать. План счетов на много листов, зато теперь хоть ошибку найти можно.

Офигеть.

Tatjanai. ERP sitēmās gan Hansā, gan Navision informācijas uzskaite diezgan radikāli atšķiras no vietējiem produktiem. Ja vietējos produktos visbiežāk debitoru uzskaite tiek veidota ar 2310 subkontu palīdzību, tad rietumu sistēmās ir viens 2310 konts, bet analītika pa debitoriem ir debitoru blokā. Ja, Jums kaut kādu iemeslu pēc 2310 virsgrāmatas summas atšķiras no debitoru kopsummām, tad Jums vienkārši nav paveicies ar programmas piegādātāju un viņš savas pieredzes trūkuma vai kādu citu iemeslu pēc nav spējis korekti ieviest sistēmu.

Tagad nedaudz par tēmu. Navision ir Microsoft produkts un tieši tāpēc viņš ir vislabāk integrēts ar pārējiem Microsoft produktiem. Visas MS servispakas utt. tiek testētas ar Navision, tāpēc ir mazāk problēmu. Bez tam Hanzai joprojām nav normāla algu moduļa. Ir algas, bet pats piegādātājs klientiem iesaka pagaidām nepirkt:) Kā arī dažādas problēmas ar apaļošanu. Turklāt cik man ir zināms, tad Hanzai ir obligāta ikgada atjaunošanas maksa 20% apjomā no licences cenas, Navision gadījumā tas nav obligāti.

Navision nav orientēts tikai uz lieliem uzņēmumie. Jau vairāk par gadu tiek piedāvāta versija maziem uzņēmumiem, kura maksā aptuveni 2000 EUR uz vienu vienlaicīgu lietotāju. Versijā ir iekļauta pilnīgi visa funkcionalitāte, kura ir nepieciešama grāmatvedības uzskaites veikšnai atbilstoši Latvijas likumdošanai.

Es uzreiz atvainojos par drukāšanu latviešu valodā, bet man nav krievu valodas burtu uz klaviatūras un translits izskatās atbaidoši.

Latviešu valoda atšķirībā no transliterācijas ir normalā valoda.

Bet mani joprojām interesē - kādu objektīvo iemeslu dēļ datubāzē jābūt diviem ierakstiem ar vienādiem cipariem par vienu dokumentu? Tas tā, tīras zīņkarības pēc... Manuprāt, loģiski ir kad vienam dokumentam pienākās viens ieraksts datubāzē, informācija no kura arī aiziet visās atskatēs.

Mūsu gudriem programētājiem šodien laikam brīvā diena

Tāpēc, ka katrā blokā ir svarīga sava informācija. Piemēram, virsgrāmatas ierakstos ir svarīgs VG konts, grāmatošanas datums un summa, bet Klienta grāmatā savukārt apmaksas termiņš un atlikusī apmaksas summa.

Rietumu tipa sistēmās Virsgrāmats ierakstos neglabājas informācija par Klientiem, piegādātājiem, precēm un pamatlīdzekļiem. Tas viss ir loģiski sadalīts pa blokiem un ir pieejams katrā blokā atsevišķi.

Kāpēc tā? Tāpēc lai ar sistēmu varētu strādāt ne tikai grāmatveži, bet arī tirdzniecības menedžeri un citi mirstīgie. Izrakstot rēķinu menedžerim nav jādomā par grāmatojumiem. Menedžeris izvēlas klientu un preci, bet sistēma pēc grāmatveža iestatījumiem izveido grāmatojumus. Rēķinus var izrakstīt menedžeris un grāmatvedim atliek tikai iegrāmatot, nevis nodarboties ar datu ievadi. Kā arī analizējot darījumu vēsturi menedžerim ir svarīgi apmaksas termiņi, nevis virsgrāmatas konti.

Tāpēc informācija ir segmentēta vairākās daļās. Gribam bilanci vai P/Z skatamies virsgrāmatā, gribam informāciju par debitoru skatamies debitora kartiņā.

Hansa un Navision ir ERP (Enterprise resource planning system). Līdz ar to sistēmai ir jāatbild ne tikai uz grāmatvedibas jautājumiem, bet arī uz resursu plānošanas jautājumiem. Grāmatvedība, faktiski, atbild par to, kas jau ir noticis, tas ir atspoguļo faktu. Bet ERP sistēma palīdz plānot nākotni.

To visu var panākt vienkārši atticīgi uzvbuvējot atskaites un ievadīšanas formas. Bet tam visam manuprāt pilnībā pietiek ar vienu datubāzes ierakstu. Menedžerim izveidojot dokumentu nav jāredz gramatojumi vai ko tur vēl - tad vienkārši nevajag viņam tās rādīt pavadzīmes ivadīšanas formā. Grāmatvedim nevajag redzēt klientus - var vienkārši nelikt grāmatvdeības atskatē kolonu "klients"...

Dokumentam tik un tā ir vairāki apstrādāšanas/grāmatošanas posmi. Kapēc tā vietā, lai pie grāmatošanas ierakstīt grāmatojumu jau esošā datu bāzes ierakstā, kuru izveidoja menedžeris, vajag veidot pilnīgi atsevišķu jaunu ierakstu?

Es nestrīdos un nemēģinu neko pierādīt. Es vinkārši gribu saprast. Nevar taču būt tā, ka datubāzes struktūru uztaisa tik sarežģītu tā pat.

Kāpēc Jums liekas, ka sabāzt visu informāciju 1. tabulā VG ieraksts ir vienkāršāk?

Ja glabāt informāciju vienā tabulā, tad šim ierakstam būs bezgalīgi daudz lauku: informācija par klientu, piegādātāju, preci, pamatlīdzekli un tā tālāk un tā joprojām. Katrā atsevišķā gadījumā lielākā daļa informācijas būs lieka. Lai iegūtu kaut kādu kopēju informāciju vajadzēs veidot arvien jaunus pārskatus.

Vienkāršāk ir glabāt virsgrāmatas informāciju virsgrāmatā un klienta informāciju klienta grāmatā.

Turklāt problēma, kad VG konta summa nesakrīt ar kopsummu no analītikas bloka ierakstiem ir netipiska. Ja šāds gadījums ir radies, tad kāda no iesaistītajām pusēm nekorekti lieto sistēmu.

Loģiski ka es nekorekti lietoju sistēmu. Jo kredītrēķinu jūra nekādā gadījumā nepadara manu darbu vieglāku.... Ktrs kredītrēķins veido divu ierakstus, tad vienam dokumentam jau ir četri ieraksti. Un ja vēl neizdevas izlabot ar pirmo piegajēnu... Īpaši žēl ražot kredītrēķinus, ja kļūda ir datumā

Skaidrs par tiem vairākiem ierakstiem:) Liels paldies par atbildi!

"Вопрос к программерам. Зачем в той же ханзе (и не только в ней) проводка живет отдельно, а счет к ней отдельно? Получается один документ = две записи в базе = две цифери. " - а это быть может нерациональное построение базы данных, только и всего. Напрограммировать можно как угодно, результат соответственный. Если Вам нравится, Вы покупаете - свободный рынок.

Par neracionālo datubāzes struktūru nevarētu piekrist.

Varbūt, ja paskatās vienu no dzīves atrautu gadījumu ar 2310 kontu, tad racionālāk liktos veidot 1 ierakstu datubāzē.

Bet dzivē ir simtiem dažādu situāciju. Turklāt Navision lieto vairāk nekā 1000 klientu dažādās pasaules valstīs. Microsoft iegulda vairāk par Miljards!!! Eiro jaunu versiju izstrādē. Protams var teikt ka Microsoft neracionāli tērē naudu un 5 programmētāji no Latvijas var izstrādāt labāku sistēmu nekā 500 no Redmondas, bet, diemžēl, tas parasti neatbilst patiesībai.

Tatjanai. Precīzi nezinu kā Hanzā, bet Navision jebkuru grāmatojumu /dokumentu var stornēt (atcelt) ar pāris klikšķiem, līdz ar to ir vienkāršāk atcelt visu iegrāmatoto rēķinu nekā censties atcelt kaut kādu daļu. Un problēmas rodas tikai tad, kad grāmatvedis cenšas stornēt pēc kaut kāda sava algoritma.

Jāāāā, bet mani tracina tas, ka tie pāris klikšķi ražo ierakstu lērumu, kas velkās visu mūžu šim nabaga dokumentam līdzi... Un rezultātā debitoru atskaite ir papīra paka, kur ir sarakstīti visi plusi un mīnusi un vēl visa kā daudz... To gan nevienam dzīvē nevajag

Jāāāā, bet mani tracina tas, ka tie pāris klikšķi ražo ierakstu lērumu, kas velkās visu mūžu šim nabaga dokumentam līdzi... Un rezultātā debitoru atskaite ir papīra paka, kur ir sarakstīti visi plusi un mīnusi un vēl visa kā daudz... To gan nevienam dzīvē nevajag

Atvajnojiet, netīšām internets aizķerās pelē...

"Если кому не лень, объясните пожалуйста, почему не хватает одной записи в базе на один документ?" - а она и должна быть одна, а все её интерпретации должны быть виртуальными, не должны храниться, тогда независимо от корректировок и от способа получения отчётов (аналитически или в целом по счёту) цифири всегда будут актуальными.

Parasti stornēšanas problēmas rodas sistēmas ieviešanas pirmajos posmos un turpinās pāris pirmos mēnešu. Turklāt šī daudzkārtējā sornēšana panesās tikai tad, kad uzreiz nestornēja pareizi, bet kāut kā pa savam. Tad ir stornējums, kuram ir savukārt savs stornējums utt.

Turklāt šo problēmu var visai vienkārši atrisināt. Grāmatas ierakstos izveidojot jaunu lauku - ķēķsīti kļūda un turpmāk atskaitēs iekļaujot tikai ierakstus, kās nav Kļūdas.

Bet kā jau teicu, stornēšanas problēmas ir aktuālas sistēmas ieviešanas sākumā, kad sistēma ir nostabilizējusies tādām problēmām nevajadzētu rasties.

Почему вообще проблема подобного рода имеет место быть, на любом этапе: на начальном или нет? При правильном построении базы данных её просто не бывает.

Šāda problēma norodas vispār, ja grāmatvedis negrāmato nekorektus grāmatojumus. Ir jāgrāmato izmantojot klienta analītiku, nevis pa tiešo Vg kontā. Turklāt pa tiešo grāmatot parasti arī nav iespējams, bet grāmatvedis APZINĀTI atceļ šo aizliegumu! Tas ir tāpat kā ar satiksmes noteikumiem - ja braucēji nepārkāptu noteikumus nerastos avārijas.

eh, cienītais Andresm, visam piekrītu - ļoti labi izskaidrots, bet nepārbaudītu info par Hansu gan nevajadzēja rakstīt.Tikai viens no jūsu "apgalvojumiem" nedaudz atbild patiesībai.

Ja kāds vēl nesaprata par to, kāpēc vajadzīgi divi ieraksti, mēģināšu pateikt to pašu ko Andres, tikai citiem vārdiem:

pārdevējam nav nekāds sajēgas pa kādiem kontiem jāgrāmato prece, kuru viņš pārdod, noliktavas uzskaitvedim arī nav šīs sajēgas - grāmatojumi vajadzīgi tikai priekš grāmatvedības un punkts!Rēķini, noliktavas un citi dokumeti vajadzīgi attiecīgi priekš pārdevējiem, noliktavas darbiniekiem, vadībai. Priekš kam viņiem grāmatojumi???

Par valodu - nu labi, negribat tā, varu arī šādi, es jau tikai labu gribēju, neba jau nu priekš sevis.

Par tēmu - visu, ko var izdarīt Navision var paveikt arī Hansā. Ļoti bieži tas ir vienkāršāk. Daudzos tehnoloģiskos risinājumos tā ir pārāka par Navison un citiem Microsoft produkiem.