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

         - 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. 

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/Ř)
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
         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)
Ř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.

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/Ř)
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
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ý
         - 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/

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/Ř)
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

         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.

         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 
         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. 

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/Ř)
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
Ř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".

         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.

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/Ř)
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
         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 
         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)

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/Ř)
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

         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