Balík kancelářských programů MS Office je produkt, který uživatelům spoustu věcí ulehčí, když funguje podle představ, dokáže ale přidělat i hromadu starostí, pakliže se zrovna rozhodne žít a přemýšlet po svém. Druhá ze zmíněných situací může nastat, pokud potřebujeme propojit excelová data s wordovým dokumentem a v těch datech máme i data kalendářní. O tom, jak se s nimi poprat a jak obecně používat textová a slučovací pole, byla na internetu napsána už řada poučných článků, já se tak podělím o něco trochu jiného, a sice o případ, kdy ono kouzelné {MERGEFIELD NazevPole \@ "DD. MM. YYYY"} odmítlo fungovat.
Den, či měsíc? Toť pro Word otázka
Už před půl druhým rokem jsme v práci vytvořili excelovou tabulku, která obsahuje tuny kalendářních dat. Ta se tam píšou zcela obyčejně v krátkém formátu (D.M.YYYY). Tabulku máme přes hromadnou korespondenci připojenou k wordovému dokumentu, data zobrazujeme pomocí slučovacích polí a formátujeme do výše zmíněného DD. MM. YYYY. Vše funguje. Nebo tedy fungovalo. Teď jsme tabulku rozšířili o další tři sloupečky pro datum, formálně totožné s původními, a vytvořili odvozený dokument. V něm už si datum najednou dělá, co chce.
Datum z Excelu se v novém dokumentu chová následovně: Pokud jsou čísla dne i měsíce ≤ 12, formát data je MM. DD. YYYY, pokud je jedno > 12, přepne se na DD. MM. YYYY, jak má. Když tedy do dané buňky v Excelu napíšeme datum 3.5.2018, slučovací pole ve Wordu nesmyslně vyplivne 05. 03. 2018, pokud použijeme datum 30.5.2018, Word ukáže již správně 30. 05. 2018. Jako by nevěděl, co je den a co měsíc, a používal z vlastního rozmaru formát měsíc, den, rok, dokud není jasné, co je co.
Otevřeme-li si ve Wordu okno Upravit seznam příjemců, objevíme další nesmysl a pravděpodobný důvod všeho: Data z původních sloupců Word vidí ve formátu M/D/YYYY, data z nových jako D.M.YYYY. Jak je to možné a jak to lze ovlivnit, když jsou ze strany Excelu všechny sloupečky jeden jako druhý, nemám sebemenší tušení. Chyba se děje někde ve vzájemné komunikaci obou programů. A internety o ní mlčí (alespoň pro mě).
Řešení (?)
Že je chyba v komunikaci a nejspíš na straně Wordu, pro změnu nikoli jen mezi klávesnicí a židlí, tomu napovídá i mé řešení celého problému. Když v Excelu pouze přepneme formátování inkriminovaných sloupců z krátkého formátu data na dlouhý (tedy z 3.5.2018 na 3. květen 2018), aniž bychom cokoli dalšího kdekoli jinde měnili, Word těmto datům už bez problému porozumí a ve slučovacím poli konečně poslušně vypíše 03. 05. 2018. Tak. A teď se v tom vyznejte.
Budu moc rád, když vám tento text dovede poradit, pokud se s podobnou stupiditou setkáte, a budu ještě radši, pokud zjistíte, kde je zakopaný pes, a o svoje vědomosti se podělíte. Třeba tady, v komentářích. Díky.
Přečteno 5215krát.
Také jsem bojoval s formátem datumu při hromadné korespondenci a zjistil jsem, že pokud je ve slouci s datumem uvedena místo datumu nějaká textová hodnota (třeba AAA), pak se do Wordu naimportují všechny datumy v tom formátu, jaký je nastavený už v Excelu – není pak nutné provádět formátování slučovacího pole ve Wordu přidáním \@ “DD. MM. YYYY”, ale stačí ponechat slučovací pole v původním tvaru {MERGEFIELD NazevPole}.
Ahoj, nevím, jestli to úplně souvisí, ale v hromadné korespondenci, kterou jsem v poslední době řešil, jsem se potýkal s obdobným problémem. Zdroj dat excel, pole s hodnotami datum.
Měl jsem 2 sloupce s hodnotou datum (v českém klasickém formátu, tj. 3. května 2020 zobrazeno v excelu jako 3.5.2020). Ve slučovacím poli ve wordu se mi data z jednoho sloupce zobrazovaly normálně, tj. 3.5.2020, ale data z druhého sloupce se zobrazovaly v anglickém formátu: 05/03/2020, tj. měsíc jako první. Nevěděl jsem, čím to je, snažil jsem se změnit v excelu všechno možné (různé formáty datumu, atd.), ale bezvýsledně. Pak jsem se ve wordu spustil Upravit seznam příjemců a objevil jsem, kde byl zakopaný pes: v jednom ze sloupců v excelu, kde jsem měl zadány data, byl v jedné buňce místo datumu zadán text „bez data – n/a“ – úmyslně, neboť pro tento záznam jsem chtěl zdůraznit, že datum zde nebude. A právě datumy z toho sloupce, ve kterém byl v jedné buňce tento text, se pak ve slučovacím poli ve wordu zobrazovaly ve správném, tj. českém, formátu. Ale ve sloupci, kdy byly čistě jenom datumy (nebo prázdná buňka) se ve wordu objevoval anglický formát data.
Při převodu údajů pro hromadnou korespondenci si tedy zjevně word / excel analyzuje, jaké data ve sloupci jsou, a když usoudí, že jsou to data v datovém typu „datum“, převezme ho jako datum, s anglickým formátem (tedy tím nejpůvodnějším počítačovým formátem, který byl samozřejmě anglický). Ale když ve sloupci objeví hodnotu, která je „text“, bere pak celý sloupec jako text, a nikoliv datum, a proto se to pak i správně zobrazuje ve wordu.
Inu, vrtal jsem se v tom hodně dlouho, a nemám zatím rozuzlení. Formátování uvedené v kódu pole je nezbytné, to každopádně. Jenže jádro pudla bude jinde. Mám sešit, který už v prvopočátku, tedy už při jeho uvedení coby zdroje dat pro hromadnou korespondenci, vrací strašlivá hausnumera. Jeho verze pochází někdy řekl bych z Excelu 2010 a Word 2019 s ním má problém. Problém byl odstraněn už při pouhém přeuložení v novějším Excelu (2019). Proto se nedomnívám, že by řešení tkvělo v použití dlouhého formátu pro datum (ani žádného jiného, třeba vlastního formátu s uvedením užitého jazyka). Spíš to vidím na nějakou drobnou změnu ve specifikaci Office Open XML. Ale to by chtělo vyvrátit i pokusem zdroje dat coby binárního staršího formátu XLS. Zkrátka až bude čas…