Presta 1.4 souhrn úprav

[Cakewalk]

Vzhledem k narůstající popularitě verze 1.4 a zmatkům v optimalizaci a převodu zavedených modulů ze starších verzí, vzniká tento topic, který by měl souhrnně nabídnout řešení nejběžnějších problémů.

1. čeština: 100% včetně adminu (překlad SQL)

2. IČ DIČ vlastníka obchodu: stejné jako v 1.3

do souboru AdminContact.php přidáte řádky

'PS_IC' => array('title' => $this->l('IČ:'), 'validation' => 'isGenericName', 'size' => 30, 'type' => 'text'),
'PS_DIC' => array('title' => $this->l('DIČ:'), 'validation' => 'isGenericName', 'size' => 30, 'type' => 'text'),

3. IČ DIČ zákazníka: 1.4 už tuto vlastnost má, ale jsou tam menší zmatky
úprava je akorát v přehození polí, tak aby IČ a DIČ byly u sebe, zobrazení IČ a DIČ rovnou v záložce zákazníka (po rozkliknutí detailu). Chybí dodělat zobrazení rovnou v tabulce zákazníků.

4. Doprava: upravené moduly ship2pay, dobírka, i úhrada hotově (včetně opravy chyby při nezobrazování v jednostránkové objednávce)

5. úprava objednávky: předělaná z 1.3 - je tam pár chyb, na kterých se pracuje (nelze přidávat zboží, vzhled)

6. čeština do PDF: stačí nakopírovat fonty a v nastavení PDF je nastavit

7. správné zobrazení Kč ve fakturách:
stačí upravit soubor classes/PDF.php

static protected function convertSign($s)
{        
$arr['before'] = array('€', '£', '¥');       
$arr['after'] = array(chr(128), chr(163), chr(165)); 
return str_replace($arr['before'], $arr['after'], $s);    
}

na

static protected function convertSign($s)
{       
$arr['before'] = array('€', '£', '¥');       
$arr['after'] = array(chr(128), chr(163), chr(165));       
$s = Tools::iconv('utf-8', self::encoding(), $s);        
return str_replace($arr['before'], $arr['after'], $s);    
}

Někteří to řeší přes novinku override, ale tahle možnost mi nefungovala.
Faktury z Presty jsem ovšem přestal používat. Finančák s tím má problém.

Veliké díky vše, kteří se na těchto úpravách podíleli.

[Tenvelkej]

proč s tim ma financak problem ?

[Cakewalk]

Má problém hled s několika prvky:
1. presta není akreditovaný účetní program, byť jen vystavuje faktury, tak pak vznikají zmatky s číselnýma řadama faktur u účetnictví
2. zákazník se zaregistruje, udělá objednávku a automaticky se mu vygeneruje faktura, nad kterou nemá vlastník obchodu vůbec kontrolu
Problém je pak hlavně s DPHčkem.

Už jsem měl s finančákem pár rozmluv na toto téma

[josejumbo]

Má problém hled s několika prvky:
1. presta není akreditovaný účetní program, byť jen vystavuje faktury, tak pak vznikají zmatky s číselnýma řadama faktur u účetnictví
2. zákazník se zaregistruje, udělá objednávku a automaticky se mu vygeneruje faktura, nad kterou nemá vlastník obchodu vůbec kontrolu
Problém je pak hlavně s DPHčkem.

Už jsem měl s finančákem pár rozmluv na toto téma

A co se odporučuje jako optimální řešení, aby byly uspokojeny obě dvě strany?

[Cakewalk]

Těžko říct. Asi to zálěží na úřednících. Mi osobně bylo doporučeno, aby automatické generování faktur bylo zakázáno. Zákazník může uhradit částku např. převodem na základě objednávky, která v tomto případě nahrazuje proformo fakturu. V případě dobírky nebo osobního odběru prostě fakturu vystavíme v účetnictví a předáme ji zákazníkovi. Vzhledem k nové legislativně si nemůže zákazník nechat vrátit DPH, když fakturu neuhradil. DPH se vrací pouze z uhrazených faktur. Nastává zde jen menší problém přelomových dnů.
I když fakturu vystavíte 30.x a zákazník ji se zbožím dostane až např.2.x následujícího měsíce, tak vrácení DPH musí žádat až za měsíc, ve které fakturu obdržel. Tedy i za kvartál, ve kterém fakturu obdržel. Tím odpadají zákazníci, kteří chtějí fakturami na konci měsíce zkrátit DPH.

Tyhle věci raději proberte se svou účetní případně s úředníkem, který Vás má nastarosti na finančáku.