Příspěvky uživatele


< návrat zpět

Strana:  1 ... « předchozí  24 25 26 27 28 29 30 31 32   další » ... 302

Nejako som ten popis nepobral.
Na jednom hlasovacom lístku máte X kandidátov. A pri každom kandidátovi môžete zaškrtnúť Áno/Nie/Zdržal. Doslovne pri každom - naraz. Naraz ? A ako potom vyhodnocujete kto je zvolený? Ak môže vzniknúť mrte možností kombinácií. Niekto zvoli ANO pre k1, k2 a NIE pre k3. Iný zvolí NIE pre k1 a ANO pre k3 no pri k2 sa zdrží. Ďalší dá 3x NIE, ...
Ak toto preklenieme, tak potom po vyplnení formulára (odpísaní papierového lístku ???) sa potom prevedie zápis tlačítkom?

Pozor oprava, mrk vyššie.

Stačí teda v 1. riadku urobiť takúto zmenu
Set rZmena = Application.Intersect(Range(Range("W4"), Cells(Rows.Count, "N").End(xlUp)), Target) 'kontrola změny v dané oblasti
a vyplnenosť dát/riadkov by som určo robil pomocou kontroly posledného údaju v "N", lebo práve "N" hodnota sa bude potom vyhľadávať.

Ak myslíte niečo iné pod výrazom "pokud je řádek na Listu2 prázdný", viac to špecifikujte.

EDIT:
Oprava, musí to byť napr. takto

Set rZmena = Application.Intersect(Range(Range("W4"), Cells(Cells(Rows.Count, "N").End(xlUp).Row, "W")), Target) 'kontrola změny v dané oblasti
Inak by to reagovalo od stĺpca N po stĺpec W. Som sa "upsal" 5

Neviem, či ste to domyslel. Tam môže nastať množstvo situácií na ktoré treba myslieť. Viacnásobná zmena, iná hodnota ako 1, nekonzistentná oblasť zmeny, nenájde sa hodnota, prázdne N, žiadne dáta, opakovaná zmena pri W pri Nie, ...
Akurát počítam že nebudete filtrovať, lebo potom treba zisťovať rozsah inak.

Príklad

1. Koľko tých čísel P bude? Odhadom koľko max bude počet čísel P v tom súčte? Pamätám si na jednu účtovníčku, ktorá chcela niečo podobné, a nedokázala pochopiť, že taký výpočet bude (v jej daných počtoch) trvať celé roky. Musel som ukázať reálne počet prejdených čísel, kombinácií za hodinu a previesť na roky - to boli strašné miliardy kombinácií.

2. Robil som to vtedy makrom. Môže byť makro?

Tlačítka na filter sú zbytočné. To si makro ošéfuje podľa stĺpca J.

Problém je, že je to asi nerealizovateľné. Kvôli tomu, že vy požadujete pravdepodobne na každú tlačenú/exportovanú stránku toho istého listu, inú lupu ! Aby sa Vami definovaný počet riadkov vliezol na stránku.

Takže môžu byť ešte iné dáta pod oblasťou tlače a vpravo od nej? Nad oblasťou tlače a vľavo od nej nie.

Budú mať stránky nejaké orámovanie? Pýtam sa preto, lebo ak áno, môže pri odstraňovaní vedľajších dát prísť k odstráneniu rámov krajných buniek. A potom to treba napraviť.

Prvé 2 strany majú 50 riadkov, tretia 47 - je to v poriadku?

Bude teda potrebné vkladať manuálne zlomy strán, lebo by sa prvé 3 riadky z ďalšej strany dali k tým 47.

Uvidím, čo ma ešte napadne spýtať...

Vytvoril som si pokusný zdroj 13000 riadkov, a aktualizuje sa 9000, a vzorcom to robí asi 5 sek. Cez ADO asi 0,5 sek. Rýchlejšie to asi nepôjde. Má to spolu 1,4 MB takže odkaz na GoogleDrive.

Otestujte

Ak je príloha XLSM musíte ju zabaliť do ZIP. A veľkosť max do cca 300 KB. Ak to je väčšie a nedá sa zmenšiť, tak do nahrajte niekam na úložisko (uloz.to, GoogleDrive, ...) a dajte link.

A viete aké to makro spôsobí problémy? Bude nutné uchovávať prípadnú pôvodnú farbu bunky, odstrániť jej podmienené formátovanie (PF) (samozrejme si ho zapamätať), pri zmene bunky, to všetko vrátiť naspäť (pre celý riadok a stĺpec defakto po jednej bunke), a celú operáciu zapamätania farieb a PF urobiť znovu pre inú bunku. To preto, lebo má PF prednosť pred manuálnym vyfarbením. To bude nereálne.

Nastavte tomu PF "krížu" zastavenie PF (to zaškrtávacie políčko), a by bolo pre celú oblasť ako prvé.

Tak ma ešte trklo, že na to idem zložito. Stačilo by iba UnpivotOtherColumns

EDIT:
Tak teraz pozerám tú Vašu novú prílohu. Používate Unpivot, tam treba práve názvy stĺpcov, ktoré budú variabilné. Použite ako píšem UnpivotOtherColumns. Takže sa treba len rozhodnúť, či bude zdroj Tabuľka alebo tabuľka. Pre KT nepotrebujete upravený zdroj zobrazovať na ďalšej Tabuľke. PQ dotaz môže byť rovno ako zdroj KT - viď moja príloha.

Tu som urobil príklad ešte na predošlú prílohu (tú Vašu najnovšiu pozriem neskôr). Princíp je taký, že sa so zdrojovou tabuľkou urobí to, že sa zoberú všetky názvy stĺpcov, ktoré by ste mal mať v jednom stĺpci aby fungoval riadkový súčet v KT, urobí sa pre každý stĺpec vlastná tabuľka, a tieto tabuľky sa rozbalia. Takže vznikne presne to, čo potrebujete do KT. Čiže všetky stĺpce okrem "měna" a "info" budú v jednom hodnotovom stĺpci. Kľudne ich môže byť viac, lebo to je robené aktuálnym zoznamom stĺpcov, a nie vzorcom v počítanom poli s pevnými stĺpcami. No mňa to napadlo jedine takto ...

Musela by byť tá zdrojová tabuľka inak orientovaná. Prípadne by ostala rovnaká ale ako zdroj pre KT by bol PQ dotaz, ktorý by zdroj upravil do takejto podoby. Potom súčet riadku funguje.


Strana:  1 ... « předchozí  24 25 26 27 28 29 30 31 32   další » ... 302

Uživatelské menu

Nejste přihlášen(a)
avatar\n

Menu

Formulář Faktura

Formulář Faktura IV

Oblíbený formulář Faktura byl vylepšen a rozšířen.
Více se dočtete zde.

Helios iNuvio

Používáte podnikový systém Helios iNuvio? Potřebujete pomoci se správou nebo vyvinout SQL proceduru? Více informací naleznete na stránce Helios iNuvio.

On-line nástroje