Je to zřejmě důležité téma pro reálné využívání Base. Proto uvedu možnosti řešení.
To nejméně efektivní, ale spolehlivé řešení je vytvořit pohled - například když byste dělal relační databázi (ale může být i vícesloupcová - nerelační).
Pohled dělá "variace bez opakování". Je to jako "tachometr". Například sloupec první tabulky (=A) - bude mít 50 záznamů. Sloupec druhé tabulky (=B) bude mít 20 záznamů. Pohled vygeneruje 1000 položek. Každé položce A přiřadí každou položku B.
Nad tímto pohledem vytvoříte formulář s dotazem, nebo jen dotaz. Pak jde o to co budete chtít dělat dál. Pokud budete chtít jenom sečíst příslušné položky z jednoho typu sloupce bude postup jiný, nežli v případě že chcete dělat rozdíly (to co uvádíte v dotazu). Když se to řeší tak pomocí aliasu v dotazu. Tam se načtou podle vzorce hodnoty jako + a -. Součet ze sloupce aliasu je to co hledáte.
Řešení může být i pomocí filtru, ale filtr funguje ve formuláři špatně. Lze zadat jen jedno filtrované pole. Takže ne všechny potřeby se dají dělat jen filtrem (bez aliasu). Zase když by se zaváděly originálně například výdaje mínusem a příjmy plusem tak filtr stačí - odfiltruje položky bez potřebného příznaku a sloupec se sečte..
Tenhle postup ve spojení s "pohledem" umožňuje například komplexní vyhodnocení všech položek (má dáti - dal). Jinak je to ale poměrně zbytečně složité. Vždy musíte vytvořit pohled znovu a ten aktuální by se měl vždy jmenovat stejně. To znamená buď původní pohled smazat, nebo přejmenovat. nevýhodou je také ta "variace". Když byste vytvořil v prosinci pohled za celý rok může to být tak velké, že to stroj neuveze.
Problém je prakticky jen v jediné věci. Najít společný jmenovatel pro obě tabulky a pak se dají dělat všechny možné opičárny. Například u výpisů z banky je to snadné - bude tam nějaký variabilní, nebo jinak podobný symbol. Pak stačí udělat vazby. Z nich následně dotazy a formulář být ani nemusí. Stačí sestava pro tisk. Toto řešení ať už s formulářem, nebo bez něj je nejlepší, ale musíte dostat dva součty - někam a udělat vyhodnocení - nejspíš součet dvou součtů sloupců ve formuláři. To bych viděl nejlépe jako dva SubFormy v MainFormu, ale jde to také sečíst například makrem.
Jde také přímo postavit jen dotaz - zejména SQL a vracet položky po součtu. Tohle by mělo jít i bez "vazeb" mezi tabulkami. Vyjde to ale "nastejno". Spíš půjde o erudici při psaní SQL dotazů.
Bohu žel asi ne vždy najdeme ten "společný jmenovatel", respektive mohou existovat naprosto různé potřeby. Například dohledat chybně vypsaný variabilní symbol, nebo otestovat platby v určitém období a zkoušet komparace na určitou výši.
Takže pak by asi řešením bylo manuální procházení databází a přepis položek do nové databáze. Tohle se může stávat zejména při vzájemných zápočtech a "bez rozumné" systematiky, nebo při vysloveně špatném vyrovnávání závazků "protislužbami", respektive nefinančním plnění (zřejmě podstata Vašeho problému v nekoncepčnosti pokladna - banka). To by měly být správně podle účetní osnovy zakázané operace - jenže účetní může skákat 3 metry vysoko. Když je možnost směnného obchodu - kdo by chtěl počítat a odevzdat daň? Tak se zavede do účetnictví nějaká kravina - vždyť nula od nuly pojde. Ne dělám si legraci - od výdajového dokladu k zúčtovatelné položce je daleko a cesta je nevyzpytatelně různorodá. Lituju účetního který dostane krabici papírů a má dělat daně :-(
Takže řešením je vlastně vytvořit nějaký sekundární klíč pokud se nenabízí podobný VS ap. To může být případ pokladny odkud se dávají "zálohy" a podobné věci. Naklíčovat výdejní a příjmové doklady pokladny + normální fakturaci je jistě obecný problém. Profi programy to mívají ošetřeno, ale ani tak se průšvihu nezabrání.
Vycházím z toho, že ten kdo staví účetní systém v Base nepoužívá standardní komerční program, nebo potřebuje výstupy z více různých programů sjednotit. Takže jde o to správně nastavit vstupy a výstupy, tabulky a jejich struktury. Z toho pak musí vycházet vazby a standardní dotazy bez zbytečných operací a průzkumů. Teprve následně mohou být vytvořeny formuláře které budou dělat co je potřeba a vystačí si s omezenými možnostmi Base.
Base je sice omezená, ale tím že spolupracuje s Calcem tak se vyrovná i těm nejlepším databázovým systémům ať jsou pojmenované jakkoliv. Takže já osobně upřednostňuji práci přímo a jen v Calcu. Když potřebují něco udělat aby to vypadalo lépe nežli rozhraní tabulkového procesoru, tak to vytvořím v Calcu jako CSV a na to udělám formulář. Pak jde jen o to aby se CSV dalo Calcem předělávat. To souvisí s registrací databáze, ale i Calc může být jako databáze registrován.
Takže to je moje rada : - Problematické operace dělejte v Calcu. Jde to Basí "překrýt" že to nikdo nevidí. Base se musí sice aktualizovat (opětovně načítat), ale tak velký problém to není. Calc může být spuštěn jako "hidden" a nahrazovat nedostatky SQL (největší omezení Base) více nežli dobře.
Zřejmě zajímavé (zejména nyní - když jsou žně účetních) je zpracovávat Calcem vstupy, vyplivnout je v požadovaném rozvržení klientského účetního programu a vytvořit daňové přiznání - respektive podklady pro odsouhlasení.
Nejzajímavější je možnost naskenovat doklady pomocí OCR, následně načíst Calcem a dokonce to i automaticky spočítat - vytvořit deník ap. všechny agendy.
Největší problém je s kontrolou OCR, ale vyplatí se to. Novější OCR umí pracovat se šablonami, takže po prvních ukoptěných pracích a opravách lze získat vzory nejčastějších, nebo všech příjmových a výdajových dokladů. Krabice se seřadí podle data a naskenuje se (může i naprostý laik). Provede se OCR a někdo fundovaný to zkontroluje ve smyslu správnosti rozpoznání obsahu a ve smyslu seřazení podle data (vše v OCR). Následně se udělá výstup do formátu csv, nebo Excelu. O zbytek už se mohou postarat makra. Výstupy mohou být například jako dBase, nebo CSV (podle toho jaký účetní program finální klient užívá - musí to být program uznávaný - problémy jsou s legislativou). Takové podklady se načtou jako záloha. Po pře chroupání profesionálním programem který by měl vyplivnout případné chyby a nedostatky) je hotovo. Účetní na tom nemusí ani moc dlouho pracovat - hlavně jen ze začátku. Profesionální účetní program ani vlastnit nemusí, ale měl by mít k němu přístup kvůli kontrole. OCR bývá ve výbavě tiskáren i když někdy dost omezený, ale profi program (Recognita, Finereader ap.) jsou v řádech několika tisíc.
Editoval neutr (4. 2. 2016 18:10:18)
Moje e-mailová adresa
Pokud je Váš problém vyřešen, označte prosím svůj příspěvek za "VYŘEŠENÝ"
Zlepšíte orientaci při vyhledávání řešení JAK OZNAČIT TÉMA ZA VYŘEŠENÉ