PPL problem about pplmyapi

[Salamek]

@jfnukal

Cisla baliku/ciselna rada

Cislo ciselne rady ktere dodavate neni zrovna vhodne na pricitani/manipulaci, jeho format pokud vim je:
ABBCEEEEEEE

• A: Typ produktu
• BB: Cislo depa
• C: Je dobirka nebo ne: 9 = CoD/5= Bez dobirky
• EEEEEEE: Cislo baliku

Mnohem jednodusi je rozebrat ono cislo a ziskat EEEEEEE a s nim pracovat v danem rozsahu a pak vse zase slozit nez s tim pracovat v celku, proto jej v celku nepouzivam a proto existuje metoda Tools:generatePackageNumber rusit ji nehodlam, spise pridam do dokumentace vysvetleni jak s temito cisly pracovat a do Tools metodu pro parsovani cisel poskytnutych od PPL + Oprava pro @JamesTheCode

Pripominka

Kdyz o tom jiz diskutujeme:

1. Proc vubec existuje nutnost resit ciselne rady na strane klienta ?
2. Proc to neni optional parametr ? Proc se ciselne rady nespravuji/neresi by default na strane serveru/API ? Zakaznikum je putna jake cislo balik dostane pokud jej mohou zjistit pro tisk na stitek.

Neustale vyzadovat ciselne rady od PPL je neuveritelny opruz... a o co hur z technickeho hlediska naprosto zbytecny! a celkove to ztezuje implementaci (client si musi spravovat ciselne rady, hlidat unikatnost a tuny dalsich veci)

Nejlepsi by bylo kdyby metoda createPackages brala u kazdeho baliku pole clientIdentifier kde by si mohl zakaznik specifikovat UUID baliku v jeho DB a po zavolani createPackages by bylo v navratovych datech znovu ono clientIdentifier zaroven s od PPL vygenerovanym packageNumber
Viz zjednoduseny priklad:

$array = [
    [
        'packageNumber' => null, //Nechci specifikovat vlastni, ale muzu
        'clientIdentifier' => 'MOJE_ID_Z_MOJI_DB',
        ....
    ]
];

$retArray = $api->createPackages($array);
//Obsah $retArray je:
/*[
    [
        'clientIdentifier' => 'MOJE_ID_Z_MOJI_DB',
        'packageNumber' => '40990942614' //Package numer vygenerovany na strane PPL ktery si natisknu na stitek
        ....
    ]
];
*/

Chyby

Vasich specifikaci, bohuzel v minulosti obsahovaly chyby

No me specifikace jsou postavene na prvotni verzi dokumentace a dale na upravach dle pozadavku PPL, problem je ze se zda ze v nektertch pripadech v PPL leva ruka nevi co dela prava... 😃 viz diskuze u #21
Dale jsem v puvodni dokumentaci nasel hromady chyb at uz v samotne dokumentaci nebo v navrhu API viz komentar na zacatku souboru https://github.com/Salamek/PplMyApi/blob/master/src/Api.php#L19 urcite tam neni vse (Po nejake dobe me to prestalo bavit spisovat) a pravdepodobne je hromada veci vyresena opravena...(tise doufam) to ale musim konzultovat s posledni verzi dokumentace.

Nova dokumentace/vypomoc

Uvitam zaslani nove dokumentace, pri nejlepsim jako priloha v odpovedi na toto Issue (ke komentari muzete prilozit prilohu)

Plan do budoucna

1. Rad bych officialni dokumentaci rozkrajel do nejakeho vyvojari vice prijemneho stavu, nejlepe do Markdown a nahral do wiki k projektu viz https://github.com/Salamek/PplMyApi/wiki, pokud by s tim nebyl problem rad vam dam prava na editaci wiki + s radosti napisi script ktery onu wiki pri kazde zmene prevede na PDF a uverejni na strance projektu (kterou bych zalozil) ve finale by to pro vas moho byt primarni uloziste dokumentace misto nejakeho .docx nekde na fileshare v privatni siti PPL... usetrilo by to praci vam i me (ve shaneni aktualni verze)

2. Dale vam rad poslu pripominky k DOC & API, pokud nejake budou (az projdu novou dokumentaci), minimalne jedna je zde uz uvedena a to k ciselnym radam

3. Rad s vami projednam pripominky na tuto knihovnu

[vaclavvanik]

Problém s trackovacím číslem je poněkud složitější kvůli PPL Sprint.
Vícekusová Sprint zásilka má stejné track číslo a liší se pouze kusovým číslem.

Nicméně přiřazování čísel pořád vidím jako záležitost API. Já jako programátor to vůbec nechci řešit. Hlavně vysvětlujte zákazníkům, že v případě PPL musí spravovat třeba 10 číselných řad a kromě toho i kusovou řadu. 👎

Další velké zlepšení bych viděl v přidání metody getLabel.

vstupní parametry:

• package_id
• type (zpl / pdf / data - všechny texty, které se tisknou na štítek)

Václav Vaník, TouchStore.cz leader developer

/cc @jfnukal

[jfnukal]

Dobry den,

diky. cislo neni tvoreno. cislo je vzdy prirazeno a negeneruje se na strane zakaznika. To je nutne specifikovat. Nektere firmy se toho chytaji a pak tu mame problem. Dost firem se odkazuje na Vas, ze delaji podle Vasich specifikaci, bohuzel v minulosti obsahovaly chyby. Pokud budete chtit s necim pomoci, rad to tak udelam, aby vse bylo jak ma. Kontaktujte nas prosim na [email protected] Dostanete aktualni dokumentaci, domluvime se co a jak. Diky

kazdopadne za Vasi praci diky
Jarek Fnukal

[Salamek]

@JamesTheCode Ahoj, pokud z nejakeho duvodu Tools:generatePackageNumber vraci nevalidni data tak je mozne prepsat generovane package number zavolanim metody setPackageNumber:

$myPackageIdFromNumberSeries = 942614; //Cislo ze serie od PPL osekate o prefix ktery ve skutecnosti nepotrebujeme proze jej generuje Tools:generatePackageNumber tzn cely format je  40990942614 coz ale neni vhodne pro pricitani...
$weight = 3.15;
$package = new Salamek\PplMyApi\Model\Package($myPackageIdFromNumberSeries, Product::PPL_PARCEL_CZ_PRIVATE, $weight, 'Testovaci balik', Depo::CODE_09, $sender, $recipient);
$package->getPackageNumber(); //By melo vratit 40990942614
$package->setPackageNumber('XYZABC123');
$package->getPackageNumber(); //By melo vratit XYZABC123

...

pry neni aktualni.

Nejake podrobnejsi info ?

Kontaktovat me muzete zde pod timto issue, verte tomu ze na nej budu reagovat pruzneji nez na email 😄

[Salamek]

@JamesTheCode @jfnukal ted jsem si vsiml ze email na me je v kazde hlavicce kazdeho souboru viz
https://github.com/Salamek/PplMyApi/blob/master/src/Tools.php

[Salamek]

@vaclavvanik Pro stitky pouzivame https://github.com/Salamek/PplMyApi/blob/master/src/Label.php ale urcite by bylo dobre mit neco primo na strane API pro lidi co chteji dostat jen jeden stitek...
a getLabel($id, 'data') by bylo super i pro mou custom implementaci tisku stitku...

[JamesTheCode]

Diky moc za info. Kdyz uz jsme u toho stitku, ja jsem bohuzel byl nucen ho prestylovat aby se vesel na ppl stitky do termotiskarny. PPL zdarma dava prazdne stitky v nejakem formatu a tak jak je to ted, tak se to tam nevleze... To by tam bylo super dodat jako metodu do tridy Label.

[vaclavvanik]

@Salamek my máme v TouchStore vlastní implementaci MyApi. Já jakožto programátor bych chtěl, aby tisk štítků řešilo api. Když to umí geis, dpd, uloženka, ups, gls, intime a zásilkovna, tak nevidím důvod, proč by to nemělo umět MyApi :)))

Generovat/renderovat štítky vlastní cestou je akorát koledování o průšvih.

[Salamek]

@JamesTheCode Label A4 by se mel vejit na jakykoliv stitek (pri tisku si to ovladace tiskarny zmenci aby se veslo) co dodava PPL za stitky netusim... PR uvitam.

@vaclavvanik Tak jasne ze by to melo umet, o tom zadna...

Generovat/renderovat štítky vlastní cestou je akorát koledování o průšvih.

No stitky ze strany prepravce se zase nedaji kombinovat na 1x A4 s 4 nalepkami, coz mi vlastni implementace vsech stitku dopravcu umoznuje, takze muzu hromadne tisknout CP, PPL, Zasilkovnu etc... treba 30 objednavek najednou...

[vaclavvanik]

@Salamek jo jasně. To záleží na expedičním workflow. Jestli se balí/polepuje dávkově nebo fifo.
My jedeme fifo, generujeme zplka a posíláme do zebry. tisk je pak fofr :)

[jfnukal]

Zdravim.
ad kontat - github a prostredi neznam, nepracuju s tim, neumim. ale diky za info.
ad ciselna rada -
@Salamek nemam dobrou zkusenost, pokud se rady kouskuji. zakaznici to pletou. dulezite je hlidat kdy dojdou, nepresvihnuti a hlavne duplicity. rady mozna nejsou stastne, ale tak to je a nic s tim nasledujici rok/dve neudelame (vic vam aktualne nereknu).

ad label - metoda CreatePackageLabel - bohuzel aktualne se potykame s tim, jak to funguje. metoda jako takova je hotova, ale ten zbytek neni ok. pustit tam 1000 zakazniku a to bychom nedali.

vase dotazy:
1.Proc vubec existuje nutnost resit ciselne rady na strane klienta ? // protoze to tak je od pocatku veku proste. PPL s tim nikdy jinak neumela pracovat

2.Proc to neni optional parametr ? Proc se ciselne rady nespravuji/neresi by default na strane serveru/API ? Zakaznikum je putna jake cislo balik dostane pokud jej mohou zjistit pro tisk na stitek. // protoze nepracujeme na urovni sluzeb, ale v cisle baliku vidime od pohledu, co si zakaznik plati. Az se sluzby rozrostou, nebude to mozne, ale uz to toto je v reseni, viz vyse.

---

aktualne je tu metoda GetNumberRange - automaticke prirazovani ciselnych rad pro klienta. Ovsem v realu je to jen zatim na zacatku. A aktualne spise overujeme, nez abychom globalne nasadili.

---

ad chyby - chyby byly v kodu, kdy mi je zakaznici upravovali (myslim na Vasi strane v php).
"pripadech v PPL leva ruka nevi co dela prava... " - kdyz mate nejaky dotaz, na koho se obracite? na nas team tezko :) ale klidne me vyvedte z omylu a polepsim se. Ad dokumentace.. staci si napsat, dostanete aktualni. Dokumentace je tak dokonala, jako jeji autor a ten (ja) rozhodne se k tomu ani neblizi a jelikoz to neni ma primarni napln, vzdy bude obsahovat "hlouposti" nicmene si projdu casem vase poznamky a pokusim se napravit. dekuji

Dokumentace se delit nebude a nemuze byt ani dana zde, resp do wiki (bohuzel to nejde, sam jsem se poptaval. Korporat je korporat). byt se mi Vas navrh moc libi.

---

Jedna vec na konci - prosim, nepouzivejte a nikdo at nepouzivat "sender" je to zbytecne a dela to jen problemy (provozni vec, zakaznika se nedotyka)

Diky a omlouvam se za styl

jfnukal

[Salamek]

@JamesTheCode omrkni https://github.com/Salamek/PplMyApi/releases/tag/v1.2.0 je tam zmena ktera resi tvuj problem bez potreby toho hacku co jsem uvedl vyse, proste passni cele cislo baliku (40990942614) jako prvni parameter do Package::__constructor a melo by to byt ok

[JamesTheCode]

Jj super, diky, ale asi si to forknu a pre jenom trochu upravim, hlavne ten label mi proste nesedne do tiskarny, rucne jsem si ho predelal na a6 a prestyloval trochu. Ted se budu vrhat na postu, tam jsem si taky vsiml, ze si celkem nedavno vydal modul a pote ppl, taky asi zkusim tvuj modul :D diky.