12 ZÁŘ 2005 %CSPUT Hlavní společnost - 1 - 13:17 PB-101 Tisk požadavků Datumy od 13072005-12092005 Požadavek Zapsáno Vyřešeno Zapsal Řeší Skupina P Termín Předmět Přílohy (Z/Ř) ──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── 2040215 14072005 14072005 PB PB MZD 5 14072005 Posunutý tisk druhu propuštění na ZL (0/0) Zadání : Po nové úpravě s variantním tiskem druhu a důvodu propuštění se tyto řádky netisknou dobře. Řešení : Opraveno řádkování v programu, které ve verzi s rámečky způsobovalo problémy. 2040216 14072005 14072005 PB PB MZD 5 14072005 Program padá při zadávání PSČ/Místa ve formuláři (0/0) Zadání : Po instalaci nové verze padá program při zadávání PSČ nebo místa v rámci formuláře FN-nástupní list. Řešení : Opraveny definice vstupů na PSČ a místo v matriční obrazovce %MZM12-adresy. Protože jsou vstupy Stát, PSČ a Místo na sobě vzájemně závislé, upravil jsem definice vstupů tak, že výběrová okna nejsou k dispozici pod běžným Find (resp. Home), ale je třeba si vybírat z doplňkových výběrových oken dostupných pod F17 (resp. F5) Zároveň tato doplňová výběrová okna jsou dostupná pouze v rámci programu %MZM12-adresy a nikoli při zadávání pomocí formulá - vzhledem k variabilitě formulářů totiž nevím, zda vůbec a na jakých vstupech jsou k dispozici hodnoty Stát, PSČ. 2040217 14072005 14072005 PB PB MZD 5 14072005 Změna v účtování do SAP pro ConocoPhillips (0/0) Zadání : Ráda bych Vás touto cestou informovala, ze počátkem července přechází naše společnost na novou verzi účetního systému Sap. Přechod na nový systém s sebou bohužel přináší nová čísla účtů používaných v účetnictví, nová cost centra a jiný způsob natahování mzdových dat do našeho účetnictví. Pro úspěšný převod dat by nyní soubor měl být v excelovém formátu, ukázku přikládám jako přílohu (sheet č. 1). V případě "C" cost center se formát mění z 1726Cxxxxx na SKN01xxxxx, bohužel ještě nem k dispozici informaci jak budou vypadat cost centra typu "Q" (tj. někteří zaměstnaci v kanceláři). Jakmile budu vědět více, informaci Vám předám. Řešení : 1) Rozšířil jsem %MZC101-číselník středisek o položku "14. Kód pro účetnictví :" - pro všechna střediska Cxxxxx jsem již naplnil podle zadaného podkladu jako SKN01xxxxx (tohle všechno jsem již udělal na serveru SOCO01, abyste na tom mohla dělat napřed) - počítám, že nadále budeme ve mzdách používat dosavadní (nebo jakékoli si zvolíte) značení středisek a podle obsahu nové kolonky budeme jiné (zde SAP značení) předávat do účetnictví - ověřte si prosím, jak vypadá aktuálně situace kolem Q středisek "ještě nemám k dispozici informaci jak budou vypadat cost centra typu "Q" (tj. někteří zaměstnaci v kanceláři)" a případně si dopňte tento číselník 2) Je třeba si ručně naťukat nová čísla účtů a změnit si všechny předpisy ukazující na původní čísla účtů na nová čísla účt - tato převodní tabulka je v přiloženém XLS souboru ve druhé záložce 3) Rozšířil jsem program %MZCON01-účetní osnova o parametry Tax code a Order Kód účtu : 1. Popis : 2. Po střediscích ? 3. Tax code (MWSKZ) : 4. Order (AUFNR) : a je třeba vyplnit tyto položky u těch účtů, které vyžadují vyplnění těchto kolonek. Aktuálně je třeba vyplnit pro účet 111500 parametr Tax code na "YY" a pro účet 822000 parametr Order na "SKN0100051" 4) Upraven program %MZCON03-Export účetních dat od 07/2005 - ze zadávání parametrů tisku odstraněny již zbytečné vstupy "Referenční číslo/text :", "Předčíslí střediska :" - upravena předvolená hodnota na prvním vstupu - standardně se bude nabízet CO200507.CSV, kde 200507 je aktuální měsíc - upraven formát exportovaných dat podle poslaného vzoru - upraven tiskový výstup - odstraněn zbytečný sloupce Journal code, sestava rozšířena na 132 sloupců, přidány nové sloupce Tax code a Order 5) Původní program na účtování ve starším formátu je dostupný jako %MZCON05-Export účetních dat do 06/2005 2040218 14072005 14072005 PB PB MZD 5 14072005 Nástroj na převod všech mzdových dat (0/0) Zadání : Přebíráme do zpracování mezd společnost XY. Dle jejich informace se výplaty se vyhotovují na programu IDEA-mzdy. Ráda bych se s Vámi dohodla zda by bylo možné veškerá data z této společnosti přenést k nám do počítače. Řešení : Vytvořen nový program %MZDT226-Export všech dat aktuální firmy 12 ZÁŘ 2005 %CSPUT Hlavní společnost - 2 - 13:17 PB-101 Tisk požadavků Datumy od 13072005-12092005 Požadavek Zapsáno Vyřešeno Zapsal Řeší Skupina P Termín Předmět Přílohy (Z/Ř) ──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── - po spuštění tohoto programu a zadání prefixu vytvářených souborů se vytvoří čtyři DAT soubory, které je možné přenést na cílový počítač a tam je s naší asistencí rozbalíme - tyto DAT soubory obsahují postupně A) matrice B) historii matričních změn C) výplaty D) všechna ostatní data projektu IDEA-mzdy. 2040219 18072005 18072005 PB PB MZD 5 18072005 Účtování v projektu IDEA-mzdy (0/0) Zadání : Při zaúčtovávání mezd se nám objevují v některých případech záporné částky i v případě, že u nikoho není na daném mzdovém řádku vyplacena záporná částka. Zřejmě to souvisí s agendami na dělení středisek a zakázek. Řešení : Objevil jsem příčinu potíží se zápornými částkami při účtování například přesčasů nebo SO/NE. Problém je způsoben kumulací nesprávného zaokrouhlování několika malých čísel na celé částky. Chyba se projevovala například pro 280-LANÍK Ladislav a jeho řádek 20-Příplatek za SO/NE, na kterém bylo 148Kč. Primárně se celá částka napočítala na jeho režijní zakázku 18 a pak se postupně "odstěhovávala" procenta na jiné zakázky. Každá takto stěhovaná částka se ale zaokrouhlovala na celé Kč nahoru (tedy například pro středisko 2-Voice se 6,12% z 148 = 9,05 zaokrouhlilo na 10 Kč). A takto se postupně z původní zakázky 18 odstěhovalo více Kč, než které tam původně byly. V součtu to přesto dalo dohromady správných 148 Kč, ale výsledek na zakázce 18 z tohoto jediného rozúčtovávání byl minus. Upravil jsem celý algoritmus (a to i přímo na stroji v SOCO) rozdělování tak, že se každá jednotlivá částka ořezává na celé Kč dolů. Tím dosáhneme toho, že nikdy nedostaneme na režijní zakázce záporné hodnoty. Naopak může nastat situace, kdy na režijní zakázce zůstanou nakumulované zaokrouhlovací rozdíly. Tato chyba je podle mě menším zlem a ve velkých částkách nija nemůže ovlivnit korektnost výpočtu. Na vysvětlenou - při zkoumání detailů účetnictví jsem použil možnost tisku detailních podkladů o zaúčtování. Konkrétně jsem zadal povel na zobrazení detailu o účtování u všech zaměstnanců zadáním Detail u lidí vyhovujících podmínce : PRAVDA Vždy splněná podmínka 2040220 18072005 18072005 PB PB MZD 5 18072005 Rekonstrukce ztraceného archivu zaměstnanců (0/0) Zadání : U jedné firmy zmizela data z archivu (pravděpodobně chybným použitím programu na hromadné rušení v archivu matric). Je možn nějak archiv zachránit? Řešení : Připreven nový program %MZDT227-na rekonstrukci dat v archivu. Program pracuje následovně : 1) prochází všechny měsíce, které jsou ve stavu 99-ukončeno 2) v nich prochází všechna osobní čísla 3) jestliže dané osobní číslo neexistuje v dalším měsíci -> pak se tato matrice přesune do archivu 2040221 19072005 19072005 PB PB MZD 5 19072005 Nová sestava na daně ze základních tisků (0/0) Zadání : Ráda bych Vás poprosila o úpravu těchto nových sestav - a to tak, aby se mi za sebou tiskli zaměstnanci abecedně za sebou - tak jak to bylo u té staré sestavy, kdy jsme si nastavili tisk ne podle středisek, ale podle výplatního místa - pal to byly obvykle 2 - 3 stranky tisku. Dneska se sestava tiskne sice abecedně, ale v rámci středisek. Já mám např. v DuPontu asi 35 středisek a v Conoco ještě mnohem více, a pak mi vyleze sestava daní v případě DuPontu na 25 stránkách, protože se každé středisko tiskne ještě na zvláštní stránku. Je to moc papírů. Řešení : Obě sestavy %MZDT224 - podklady o výpočtu daní %MZDT225 - podklady o daních zvláštní sazbou jsem rozšířil o možnost spouštění a třídění podle výplatních míst - toto chování se nastavuje parametrem v konfiguraci "Programy spouštět přes ?" A-výplatní místa/B-střediska. 2040222 08082005 08082005 PB PB MZD 5 08082005 Přidat možnost třídění do tisku smluv v RTF (0/0) 12 ZÁŘ 2005 %CSPUT Hlavní společnost - 3 - 13:17 PB-101 Tisk požadavků Datumy od 13072005-12092005 Požadavek Zapsáno Vyřešeno Zapsal Řeší Skupina P Termín Předmět Přílohy (Z/Ř) ──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── Řešení : Do sestavy %MZI003-Tisk smluv se zaměstnanci do RTF přidána klasická možnost třídění až podle tří kritérií. 2040223 09082005 09082005 PB PB MZD 5 09082005 Neplacené volno při práci v zahraniční a VZ pro ZP (0/0) Zadání : Zaměstnanec je od 12.7. odhlášen ze ZP ( práce a pojištění v zahraničí, u nás neplacené volno ). Do mzdového řádku 315-Neplacené volno bez ZP jsem zadal do kolonky "Seznam dnů" hodnotu "12-31". Program správně vykáže hodiny a dny neplacen volna, v důsledku toho je správně i dopočítaná základní mzda za začátek měsíce, ale mám problém s vyměřovacím základem pro zdravotní pojištění. Vyměřovací základ pro zdravotní pojištění (ř.398) by měl být stejný jako ř. 395 a 320, a nikoliv ve výši minimální mzdy. Řešení : Zde byla chyba v chybném nastavení vlastností řádku 315-Neplacené volno bez ZP s ohledem na stanovení minimálního vyměřovacího základu pro ZP. Nově jsme nastavili u tohoto řádku zápočet HZP-do KD pro stanovení vyměřovacího základu ZP takový parametr, který způsobí, za kalendářní uvedené na tomto řádku se program nesnaží dopočítávat minimální vyměřovací základ. Takže například pro náš případ s měsícem dlouhým 31 dnů a neplaceným volnem 20 dnů se : a) dosud chybně program snažil porovnávat mzdu s číslem 7185*31/31=7185 (tedy chybně s plnou minimální mzdou) b) nově program snaží porovnávat mzdu s číslem 7185*(31-20)/31=2549.5 (tedy s minimální mzdou odpovídající 11ti dnům) 2040224 09082005 09082005 PB PB MZD 5 09082005 Předvolená hodnota stavu matrice přebíjí zadanou (0/0) Zadání : Pokud v matričním formuláři FZ-základní zadávání zadávám nového člověka a zadám mu do kolonky "Dopočet do FPD ?" hodnotu Ne tak program přesto uloží hodnotu Ano. V čem je problém. Řešení : Opravil jsem postup při plnění dat v rámci zadávání matric přes formuláře. Program byl od počátku zamýšlen a nyní již opět funguje takto : 1) V případě zadávání nového pracovníka program nejprve naplní všechny matriční údaje, které mají předvolenou hodnotu. - typicky se to týká údajů z matriční obrazovky %MZM4-stavy matrice - existuje ale i uživatelsky definovatelný mechanismus %MZDIIMU-individuální inicializace matric 2) Až poté se plní data zadaná na formuláři Chyba byla v tom, že v rámci kroku 1 jsem pro všechny údaje s předvolenou hodnotou "zapomněl" data zadaná na formuláři, tak ačkoli uživatel zadával hodnotu N, tak se místo ní použila předvolená hodnota A. 2040225 10082005 10082005 PB PB MZD 5 10082005 Komunikace s ČSSZ - upřesňování (0/0) Zadání : 1) Při generování přihlášek program neplní povinné kolonky "úvazek - hodiny týdně" a "úvazek - dny týdně" 2) Při generování přihlášek program neplní kolonky "místo výkonu činnosti (stát)" a "předpokládaný měsíční hrubý příjem" 3) Při odesílání záznamu typu 5-oprava chybně uvedených údajů zaměstnance se neodesílá v souboru datum uvedené v kolonce "Oprava ČSSZ ze dne" Řešení : 1) Při generování záznamu typu 1-přihláška se vždy plní kolonky "úvazek - hodiny týdně" a "úvazek - dny týdně" - plní se na základě dat z kalendáře, případně na základě údajů o zkráceném úvazku - M130 Individuální pracovní doba v tý - M130N Úvazek na počet dnů v týdnu 2) Při generování záznamu typu 1-přihláška se vždy plní kolonky "místo výkonu činnosti (stát)" - a to na základě matričního údaje M128-Sídlo trvalého pracoviště - číselník trvalých pracovišť byl rozšířen o pole "Stát", kde je možné zejména u pracovišť v zahraničí zadat, v jakém státě se nachází - pro tuzemská pracoviště není nutné pole "Stát" vyplňovat - vytvořen odvozený matriční údaj M128S-Místo výkonu činnosti (stát), který je odvozen z M128 právě z pole "Stát" - tento údaj je v dokumentaci popisován jako nepovinný, takže je možné jej nevyplňovat a nechat prázdný tím, že nebudete u pracovišť vyplňovat jejich státy 3) Možnosti při plnění kolonky "předpokládaný měsíční hrubý příjem" - tento údaj je v dokumentaci popisován jako nepovinný, takže je možné jej nevyplňovat a nechat prázdný 12 ZÁŘ 2005 %CSPUT Hlavní společnost - 4 - 13:17 PB-101 Tisk požadavků Datumy od 13072005-12092005 Požadavek Zapsáno Vyřešeno Zapsal Řeší Skupina P Termín Předmět Přílohy (Z/Ř) ──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── - navíc se v dokumentaci píše "uvádí se přibližný předpokládaný příjem zaměstnance, který se zahrnuje do vyměřovacího základu pro pojistné na sociální zabezpečení. Případně stačí uvést - více jak 400,- Kč. Není-li příjem pravidelný, uvede se předpokládaný průměrný měsíční příjem." - celé řešení jsem založil na odvozeném matričním údaji M194M-Průměrný měsíční hrubý výdělek - tento údaj je vypočten jako {průměr pro PP účely}*{průměrná délka směny}*{průměrný počet směn v měsíci} - jedná se o údaj, který se tiskne na zápočtové listy v kolonce "Průměrný měsíční hrubý výdělek" - v konfiguračním programu %MZDCF16-konfigurace ELDP a ČSSZ můžete nastavit parametr Jak plnit 'předpokládaný měsíční hrubý příjem' ? , který má tyto možnosti 0-neplnit 1-podle M194M-Průměrný měsíční hrubý výdělek 2-podle M194M, ale ořezávat ji na 401 - v případě varianty 2 se budou jakékoli částky vyšší než 400 nahrazovat konstantou 401 (protože do numerické kolonky nejse schopen jinak zapsat požadované "více jak 400,- Kč") 4) Do konfigurace přidána možnost zadat si předvolené jméno souboru, kam se budou exportovat XML soubory - jedná se o parametr "4. Standardně export do souboru :" - připomínám a doporučuji následující možnosti, které by mohlo být výhodné použít -- Parametry pro práci s ELDP --------------------------------- 3. Standardně export do souboru : D:/DATA/IDEA-ELDP-@%ZDT8@.XML -> D:/DATA/IDEA-ELDP-20050816.XML -- Parametry pro práci s ČSSZ --------------------------------- 4. Standardně export do souboru : D:/DATA/IDEA-CSSZ-@%ZDT8@.XML -> D:/DATA/IDEA-CSSZ-20050816.XML - kde povel @%ZDT8@ znamená dosazuj aktuální datum ve formátu RRRRMMDD - případně můžete používat i povel @%DT8@, který znamená dosazuj aktuální datum ve formátu DDMMRRRR 5) Do programu %MZCSSZ2-tisk a export dat ČSSZ byl přidán export údaje "Oprava údajů ze dne" do XML souboru 2040226 10082005 10082005 PB PB MZD 5 10082005 Jak generovat změny pro ČSSZ (0/0) Zadání : Také nevím, kde mám generovat změny- např. když jsem z Pečínkové Gabriely udělala Pečínků Gabriel. Řešení : Změny pro ČSSZ se schematicky provádějí takto : - spusťte %MZCSSZ-zadávání a opravy dat ČSSZ - vyberte si osobní číslo - na vstupu Pořadové číslo máte k dispozici povely N-odskok do generování nové přihlášky/odhlášky, P-vytvoření nového záznamu pouze s identifikací pojištěnce - zvolte si povel P-vytvoření nového záznamu pouze s identifikací pojištěnce - v nově vygenerovaném záznamu si případně upravte Typ akce : 5-oprava chybně uvedených údajů zaměstnance na Typ akce : 3-změna údajů zaměstnance - případně si podle potřeby upravte jakékoli další údaje 2040227 10082005 10082005 PB PB MZD 5 10082005 Připomínky k novým sestavám s podklady o daních (0/0) Zadání : Zjistila jsem následující a prosím zmenit: Nová sestava o výpoctu daní - máte chybu v celkovém souctu na konci sestavy - není soucet za celou organizaci, ale opisujete poslední stredisko/ a také i ve zvlášní sazbou/ Ve staré sestave jsem mela možnost upravit konfiguraci sestava za dane, mi vyšla celá organizace podle príjmení/tudíž každý clovek jen na jednom rádku/, ted mi to nejde. Dríve byly dane prehlednejší na na 11 stránkách, nyní na 43 listech, což nám nevyhovuje. 12 ZÁŘ 2005 %CSPUT Hlavní společnost - 5 - 13:17 PB-101 Tisk požadavků Datumy od 13072005-12092005 Požadavek Zapsáno Vyřešeno Zapsal Řeší Skupina P Termín Předmět Přílohy (Z/Ř) ──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── Ve zvláštní sazbe máte napsáno základ dane a dan 15%, není zohlednené pojistné a není ani hrubý príjem, tudíž bych musela kontrole dávat k dispozici ješte výplatní pásky a poskakovat kolem nich, což nechci. Takže by byla lepší sestava jako v zálohové dani. Také Vám vyjíždí na konci stránky jen jméno a dalším listu jen cástky, což se už nelíbilo ani sociálce pri poslední kontrol Řešení : 1) Na závěrečné stránce s rekapitulací po střediscích opraven tisk řádku se součtem 2040228 10082005 10082005 PB PB MZD 5 10082005 Úpravy v exportu dat do účetnictví NORIS (0/0) Zadání : Do exportovaného řádku je třeba mezi první údaj (textový popis) a druhý údaj (konstanta M nebo D) přidat měsíc ve formátu MM/RRRR. Řešení : Upraven export dat z účetnictví ve formátech 5-export do NORIS (středník) a 6-export do NORIS (tabelátor). Formát věty je nyní následující : 1. popis/poznámka/text záznamu 2. měsíc ve formátu MM/RRRR 3. strana "M" nebo "D" 4. konstanta 1 5. částka 6. konstanta 100 7. účet 8. konstanta ""-prázdno 9. konstanta 106 nebo ""-prázdno 10. středisko 11. konstanta ""-prázdno 12. je-li vyplněná zakázka, pak konstanta 314, jinak ""-prázdno 13. zakázka O tom, jestli součástí prvního údaje "popis/poznámka/text záznamu" bude měsíc rozhoduje zadání obsluhy při spouštění programu na zaúčtování na vstupu "Přidat do popisu období ve formátu ?". Předvolenou hodnotou je zde 1-MM/RRRR, což by měla být hodnota, která prý bude podle paní Šímové vyhovovat. V exportovaném souboru pak budou začátky vět vypadat tedy nějak takto : DZP 07/2005 {tabelátor} 07/2005 {tabelátor} M {tabelátor} 1 {tabelátor} 16555,00 ...... SP zamestnanec 07/2005 {tabelátor} 07/2005 {tabelátor} M {tabelátor} 1 {tabelátor} 6103,00 ...... ZP zamestnanec 07/2005 {tabelátor} 07/2005 {tabelátor} M {tabelátor} 1 {tabelátor} 3433,00 ...... 2040229 11082005 11082005 PB PB MZD 5 11082005 Nejde vytvořit prázdný záznam ELDP (0/0) Zadání : V programu zadávání a opravy ELDP, když si vyberu zaměstnance mi při /pořadové číslo / nejde vygenerovat nový záznam, skoč mi to na hlášku volejte správce systému. Řešení : Opravena chyba, která se projevovala v po zadání povelu P-vytvoření nového záznamu pouze s identifikací pojištěnce. Nový záznam se nevytvořil a program padal. 2040230 12082005 12082005 PB PB MZD 5 12082005 Zamítnutí ELDP kvůli variabilnímu symbolu (0/0) Zadání : Posílám dnes evidenční listy za 05-06/2005 a nic mi neprošlo. Na Vytisknutých EL variabolní symbol je, takže nevím co s tím PVS vrací chybu : Neuveden povinný údaj variabilní symbol organizace v hlavičkových údajích (RELDP@vs). Řešení : Příčinou této chyby je skutečnost, že formát zprávy ELDP vyžaduje mít variabilní symbol jak u každého zaměstnance, tak zároveň společně na začátku v hlavičce. Program odvozuje variabilní symbol na základě dat z číselníku sociálních pojišťoven. Protože můžeme mít v programu nejen bežnou okresní správu sociální zabezpečení (typicky zadanou pod kódem 1), ale také maji uživatelé běžně zadanou fiktivní správu s kódem 0-neuplatňuje se nebo nedávno zavedené "zahraniční sociální pojišťovny", tak není v principu obecně možné zapsat do hlavičky jedinou hodnotu variabilního symbolu. Tato chyba bylo způsobena víceméně náhodně tím, že dosud program dával do hlavičky VSYM od posledního zpracovávaného zaměstnance (klidně i takového, který neměl ve vybraném období záznam ELDP) a tento poslední měl zřejmě nevyplněný údaj M175-sociální pojišťovna nebo tento údaj ukazoval na sociální pojišťovnu 12 ZÁŘ 2005 %CSPUT Hlavní společnost - 6 - 13:17 PB-101 Tisk požadavků Datumy od 13072005-12092005 Požadavek Zapsáno Vyřešeno Zapsal Řeší Skupina P Termín Předmět Přílohy (Z/Ř) ──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── nevyplněným variabilním symbolem. Vyřešil jsem to celé tak, že jsem do programu přidal vstup Jen sociální pojišťovny > a doporučuji v něm zadávat filtr pouze na hlavní správu sociální zabezpečení (typicky zadanou pod kódem 1). 2040231 31082005 31082005 PB PB MZD 5 01092005 Volno z důvodu překážek na straně zaměstnavatele (0/0) Zadání : Který mohu použít mzdový řádek, když u nás nastala situace, že se některým pracovníkům bude dávat volno z důvodu překážek v práci na straně zaměstnavatele a v kolektivní smlouvě máme, že zaměstnanci náleží 80% průměr. výdělku. Řešení : Použijte řádek 92-Náhrada 60% mzdy. Budete ale muset provést následující úpravy : 1) změnit parametr "14. Procento krácené náhrady mzdy :" na hodnotu 80 v programu %MZDCFG5-další parametry 2) přes individuální změnu názvu řádku si provést změnu názvu řádku tak, aby obsahovala místo 60 text 80 2040232 01092005 01092005 PB PB MZD 5 01092005 Přepočet DNP průměrů (0/0) Zadání : Při zadávání průměrů po výpočet nemocenských dávek jsem zjistila následující: Nová nemoc / kdy si musím ručně zadat data pro výpočet/ 1. v programu /správce mezd, data z minulých aplikací/ data pro DNP průměry nastavím - Kč pro průměr a počet neodprac. dnů 2. použiju program pro přepočet průměrů /mzdt208 - skutečné nastavení/. A teď jsem zjistila, že když se potom podívám zpětně do matrice na obrazovku průměry pro DNP, tak počet neodpracovaných dnů je tam načten dvakrát!!!! Proč? Řešení : Nemůže být tento dojem způsoben tím, že jste zároveň dodávala zpětně mzdy za 01/2005-03/2005 a zároveň jste za toto období zadala i data do "data z minulých aplikací"? Program %MZDT208-přepočet průměrů prochází zpětně rozhodné období a v každém měsíci sčítá jak data z IDEA-mzdy, tak i "data minulých aplikací". Jinou možnou příčinu nevidím - při přepočtu vždy inicializuji hodnoty, takže tím se vylučuje i neustálé načítání při každé spuštění přepočtu .. --------------------- Odpověď : Ano je to přesně tak. Já jsem se domnívala, že i když do programu data z minulých aplikací zadám všechny předchoz měsíce /Kč a dny/ a dám přepočet že si to počítač přebere, ale měsíce které mám už spočítané mi tam načte dvakrát. Nesprávn jsem pochopila princip. Teď už vše chápu, ale nevím co s tím přesně provedu. Prosím nesetkal jste s někým, kdo měl někdy podobný problém. --------------------- Právě jsem promazal v agendě "data z minulých aplikací" všechna data týkající se měsíců 01/2005 až 09/2005. Předtím jsem po jistotu udělal zálohu. Takže všechny nově přepočítávané DNP průměry by již měly brát korektně - do 12/2004 data z "data z minulých aplikací" a od 01/2005 z IDEA-mzdy. 2040233 05092005 05092005 PB PB MZD 5 06092005 Příspěvek na penzijní připojištění ve výši 5% VZSZ (0/0) Zadání : Vybraným zaměstnancům platíme penzijní pojištění ve výši 5 % vyměřovacího základu (jedná se o různé penzijní fondy, proto je třeba zadat individuálně č. účtu, VS, KS-to není problém). Nyní částku zadávám jako automatickou hodnotu k přičtení, ale problém je v tom, že při změně vyměřovacího základu musím udělat korekci. Líbilo by se mi řešení v obrazovce "daně a základy" kde na řádku 13 je možnost "M-maximální příspěvek 3% z VZ SZ, doplnit volbu MM-maximální příspěvek 5% z VZ SZ s dělením částky na řádku 512 a 513-přísp.zaměstnavatele do 3% a nad 3% Řešení : Byla rozšířena škála možností zadání údaje M544-Ručně zadaný trvalý příspěvek na penzijní připojištění. Zadáním čísla následovaného písmenem P zadáte povel - příspěvek bude ve výši zadaných procent z vyměřovacího základu SZ. Například je možné zadat povel "5P" ve smyslu "poskytuj příspěvek ve výši 5% VZ SZ". 12 ZÁŘ 2005 %CSPUT Hlavní společnost - 7 - 13:17 PB-101 Tisk požadavků Datumy od 13072005-12092005 Požadavek Zapsáno Vyřešeno Zapsal Řeší Skupina P Termín Předmět Přílohy (Z/Ř) ──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── Po zavedení této syntaxe je jedno, jestli zadáte povel "3P" nebo "M". Oba tyto povely představují poskytnutí příspěvku ve v 3% VZ SZ. 2040234 05092005 05092005 PB PB MZD 5 06092005 Chyby a varování při přepočtu mezd (0/0) Zadání : Chtěla bych Vám sdělit některé připomínky k Vašemu mzdovému programu, který využíváme již řadu let: 1) U úkolových dělníků zadávám na výčetku mezd do řádku 3 jejich mzdu a odpracované hod. jednou položkou. Přesto, že hrubá mzda je vyšší jak minimální mzda, po přepočítání jeho mzdy se na konci napíše: Základní hod. mzda 0 je menší, než 45,33 (minimální mzda). Nevím, co pro to udělat, aby se toto upozornění nepsalo u každého úkolového a režijního pracovníka - mimo THP. 2) U pracovníků, kteří pobírají ČID už není plátcem zdravotního pojištění stát. Přesto to vždy po přepočtu mzdy upozorňuje, že by měl být plátcem stát. Řešení : varování typu 1) v projektu musí zůstat. Jeho variabilní potlačení "vy píšete nezobrazovat u úkolového a režijního pracovní bych sice mohl udělat, ale musel bych to udělat variabilně pro každého zákazníka jinak. A po zkušenostech s uživateli byste tom měli jen zmatek a očekávám problémy při tomto nastavování. Jednoduše toto varování ignorujte. Jen tak ho obecně odstran nemohu. ad 2) Varování typu 30-U důchodce by měl být plátcem pojistného stát se nyní negeneruje pro ty zaměstanance, kteří mají dru důchodu 11-častečný invalidní nebo 21-souběh vdovského a častečně invalidního. 2040235.1 12092005 12092005 PB PB MZD 5 13092005 Změna v účetnictví Conoco - položka Order (0/0) Zadání : V Conoco potřebují ještě nějaké úpravy v účetnictví - myslím, že nemohu ručně udělat to, že k jednomu účtu nemohu přiřadit dvě různá tzv."order" . U účtu 701201 mají být dva - SKN0100020 a SKN0100021. ------------ Dosud máme export do účetnictví CONOCO udělán tak, že v seznamu účtů máme u každého účtu uveden parametr "Order (AUFNR) :". A pro všechny účetní záznamy na daný účet uvádíme tuto jednu hodnotu do kolonky AUFNR při exportu. Je pravda, že byste potřebovali tento princip změnit a u některých složek mzdy nebo u některých lidí účtovat na nějaký účet (701201) tak, aby měl v jednom případě Order/AUFNR SKN0100020 a ve druhém SKN0100021? Co vlastně znamená sloupec Order/AUFNR? ------------- přechodem na novou verzi našeho účetního systému došlo k tomu, že některé účty byly namapovány na 1 nový společný, pro naše interní účely používáme u některých nákladových účtů jako rozlišovací znak tzv. statistical internal orders..princip j e právě v tom, že u jednoho účtu se používá několik orders. V případě mezd jsou to následující účty a tyto orders Account Order 701201 SKN0100020 Conoco contribution to pension fund-D 701201 SKN0100021 Conoco contribution to pension fund-N 701201 SKN0100021 Conoco contribution to trust 822000 SKN0100050 Social insurance company 822000 SKN0100051 Health insurance company Je možné že v budoucnu dojde k úpravě těchto orders u účtu 701201 tak by bylo fajn, kdyby si mohla paní Pohlová tyto orders nějakým způsobem sama nastavit... -------------- Dotaz : Položka "Order" závisí A) na složce mzdy nebo B) na konkrétním člověku ? Zdálky to vypadá spíše tak, že to bude v závislosti na složce mzdy, následovně : sociální pojištění se bude účtovat na dvojici 822000 SKN0100050 Social insurance company zdravotní pojištění se bude účtovat na dvojici 12 ZÁŘ 2005 %CSPUT Hlavní společnost - 8 - 13:17 PB-101 Tisk požadavků Datumy od 13072005-12092005 Požadavek Zapsáno Vyřešeno Zapsal Řeší Skupina P Termín Předmět Přílohy (Z/Ř) ──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── 822000 SKN0100051 Health insurance company Tedy všechno co se vyskytne na určité složce mzdy se bude účtovat na jasně danou dvojici "účet/order" a nebude existovat situace, kdy pro nějakého konkrétního člověka/skupinu lidí se bude tatáž složka mzdy účtovat na jinou dvojici "účet/order" ? ---------------------- Je to přesně tak jak píšete, závisí to na konkrétní složce mzdy a neměla by se vyskytnout situace, kdy pro nějakého člověka by se složka mzdy účtovala na jinou dvojici. Řešení : Upraven princip celé práce s údajem "Order" při účtování pro Conoco. Údaj Order je možné uvádět v konkrétních předpisech pro jednotlivé mzdové řádky a jen není-li údaj Order na tomto místě vyplněn, pak se hledá jako dosud v číselníku účtů. 1) Upraven program %MZCON02-účetní předpisy - kvůli přehlednosti dat a výběrových oken předělán program na 132 znaků na řádek - do každé n-tice při určování strany přidán vstup "Order" a odstraněn již nepoužívaný údaj "Journal type" - reorganizováno výběrové okno se seznamem definovaných účetních předpisů 2) Upraven program %MZCON03-export účetních dat od 07/2005 - program odvozuje údaj Order podle výše uvedeného principu - nejprve podle zadané hodnoty u účetního předpisu u mzdového řádku, není-li tam uveden, pak z číselníku účtů 3) Upraven program %MZCON04-otisk účetních předpisů - upraveno rozložení tisku analogicky ke změnám popisovaným v bodě 1) - tedy přidán sloupec "Order" a odstraněn již nepoužívaný sloupec "Journal type" 2040236.1 12092005 12092005 PB PB MZD 5 13092005 Na ELDP uvádět českou adresu (0/0) Zadání : Dobrý den , ješte jsem zapomnela, že Slováci musí mít na EL ceskou adresu, což je prechodné bydlište a skáce mi trvalé, mám zadanou státní príslušnost S, takže všichni musí mít ceskou adresu. ---------------- Jeste jsem se dival na ty chyby a je to vesmes chyba (RELDP - Neuveden povinný údaj "cit(Obec)" v části "adr (Adresní údaje pojištěnce)".) Coz je zpusobeno tim ze tady u nas ma skoro kazdy zamestnanec vedlejsi cinnost(8 vedlejší pracovní činnost ) a u tech se nevyplnuji tyto udaje jelikoz se tam zadava vazba na osobni cislo hlavni cinnosti. Mel bych prosbu aby se tyto udaje braly pri generaci eldp z cisla hlavni cinnosti. Řešení : 1) Upraveno odvozování údaje Stát jak pro trvalé, tak i přechodné bydliště - je-li kolonka stát vyplněna, pak se použije - jinak se zkoumá, jestli PSČ začíná na jeden ze znaků 0,8,9 -> pokud ano, pak se jako stát bere natvrdo "SK"-Slovenská republika - jinak se jako stát bere "CZ" (nebo přesněji to, co je uvedeno v konfiguraci jako kód České republiky) - toto odvozování se používá jak při generování záznamů typu ELDP, tak i pro generování záznmů do ČSSZ (přihlášky/odhlášky) 2) Upraveno odvozování adresy generované pro potřeby ELDP - jestliže je adresa trvalého bydliště mimo ČR, pak se vezme adresa ze sady údajů o přechodném bydlišti - jesliže ani po tomto odvození není k dispozici vyplněná adresa, tak se v případě poměrů typu VČ/NP (8-vedlejší pracovní činnost, 9-náhradní práce) pokusíme odvodit adresu z hlavního poměru přes údaj M108-Osobní číslo hlavní činnosti. ──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── Celkem požadavků : 22 ─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── IDEA