Řešení příchozích objednávek

[roman-dvorak]

Cíle modulu a jeho úkoly:

Cílem modulu je vytvořit rozhraní pro zakládání, tvorbu a správu příchozích objednávek (prodej). Modul by měl obhospodařit celý životní cyklus objednávku. Tj. od jejího založení (ruční založení i z externího API), přídávání položek, jejich úpravu atd..

Objednávka

Měla by obsahovat základní informace o "zákazníkovi". Zatím si jeho parametry bude držet sama u sebe. Po vzniku adresáře zákazníků (#97) to bude reference. To se pak převede nějakým hromadným skriptem.

Parametry o zákazníkovi jsou:

Životní cyklus objednávky:

Zadávání položek objednávky

Položky objednávky musí být možné zapsat ručně. Každou položku musí být možné zároveň spárovat se skladovou položkou. Následně by mělo být možné ze skladové položky vyčíst cenu a vložit jí do objednávky (nějakým tlačítkem u každého řádku, a globálně pro celou objednávku). Je potřeba, aby se cena držela přímo v databázi u objednávky a nebylo to sdílené s cenou položky, která se může změnit. Tahle hodnota musí být neměnná.

Řešení ceny a peněz

Systém musí umět řešit příjem peněz po "částech" tedy že uživatel zaplatí část z celkové objednávky (například podle nějaké zálohové faktury) a pak následně vznikne konečná faktura, kde bude celková částka.

Jedna objednávka může vytvořit více (například dílčích) faktur. Více dodacích listů, a více příjmů peněz.

Parametry položky

1. Název, Stručný popis
2. Je to skladová položka? Pokud ano, tak přiřadit skladové označení
3. Cena za ks (bez DPH)
4. Sleva (ideálně možnost zadat v procentech nebo hodontu)
5. Množství
6. DPH
7. Cena bez DPH/Cena s DPH

Generování PDF dokumentů

Důležitým výstupem jsou PDF dokumenty, kterými jsou například:

• Nabídka
• Objednávka
• Zálohová faktura/proforma faktura
• Faktura
• Dodací list

[cisar2218]

Ahoj, mám pár technických otázek...

Položka

1. Cena za kus je bez DPH?
2. Má být dph konstantní 21%? Tzn. není to parametr, který uživatel zadává..

Objednávka:

1. Má mít objednávka parametry typu název a popis v přehledu objednávek a databázi? Případně jiné parametry, které nebyly zmíněny a pomohou objednávku identifikovat?
2. Měly by být položky objednávky být vidět již v přehledu? Nebo stačí až po rozkliknutí podrobností?
3. Mám dovolit vytvořit prázdnou objednávku (například bez položek, nebo jiného důležitého údaje)? Může sloužit například jako template.
4. Dole je databázová struktura: uvažoval jsem o přidání segmentu dole, komentář "// optional". Je pro Vás důležité tímto způsobem trackovat změny na objednávce, nebo je to zbytečné a nemám to přidávat? Poté vyvstává:
   4.1. generovat změnu dynamicky jako string "popis" při úpravě objednávky v databázi
   4.2. nebo mít údaje jako paid, changed items, atd. aby byl snažší data quering pro nějaké statistiky. Věřím, že až tolik změn v jedné objednávce nebude, přesto to může být například i přehlednější.

Zákazník:

1. Nebyl jsem si jistý jaké parametry ukládát do databáze. Zatím jsem udělal jen "jméno a info". Což je 100% málo a bude to chtít upravit. Z Adresář #97 mi nepřipadalo zřejmé, které údaje zatím ukládat než bude modul se zákazníky bojeschopný. Budu rád za upřesnění: zda mám například načítat prozatím "jen" firmu atd.
2. Po upřesnění "1" mám pravděpodobně tvořit zároveň zákazníky jako jednotlivé dokumenty v customer collection v databázi, kdyby se změnili jejich údaje ať jsou v objednávce ty staré (embedded, ne linked) údaje, ale nemusí se customers vypisovat? Viz. struktura níže.
3. Zakazník je vždy u objednávky právě 1, že?

Databázová struktura:

• budu rád za komentáře (nejen týkající se otázek)

{
    "_id" : ObjectId(),
    "name" : "název objednávky",
    "description" : "popis objednávkyr",
    "customer" : { 
        "name" : "jméno zákazníka",
        "other_info" : "libovolné další info"
    },
    "date_of_creation" : ISODate(""),
    "price_total" : 80,
    "price_to_pay" : 80,
    "items" : [ 
        {
            "name" : "jméno položky",
            "description" : "popis položky",
            "price_per_piece" : (cena za kus v Kč),
            "discount" : (sleva v Kč, ve frontendu zobrazovaná/zadávána i v %),
            "amount" : (počet kusů),
            "dph" : 0.21, // zbytečné?
            "price_no_dph" : (cena bez dph v Kč),
            "price_total" : (cena v dph v Kč)
        }
    ],
// OPTIONAL
    "changes" : [
           {
                  "date_of_change" :  ISODate(""),
                  "user" :  "uživatel který provedl změnu",
                  "track" :  "dynamicky generovaný popis změny",
            }
    ]
}

[roman-dvorak]

Ahoj, tohle je rozsáhlý komentář :)

Cena za kus je bez DPH?

Ano, je to cena bez DPH.

Má být dph konstantní 21%? Tzn. není to parametr, který uživatel zadává..

V česku máme 3, resp. 4 různé DPH sazby. My ve skladu ale aktuálně máme asi produkty jen s 21 % sazbou. Bylo by určitě užitečné to moct změnit. Nejspíše způsobem, že tam budou ty 4 přednastavené (nějaký selectbox).

Má mít objednávka parametry typu název a popis v přehledu objednávek a databázi? Případně jiné parametry, které nebyly
zmíněny a pomohou objednávku identifikovat?

Možná by nějaký název/popis mohla mít. Může být buď uživatelsky zadaný. Nebo ho nějak generovat z obsahu.

Měly by být položky objednávky být vidět již v přehledu? Nebo stačí až po rozkliknutí podrobností?

Podrobnosti stačí po rozkliknutí. V přehledu bych zobrazil věci jako:

• Název (volitelně)
• Stav objednávky (může být řešno podbarvením řádku)
• Datum vytvoření/uzavření
• Adresát
• Počet položek, celková cena

Mám dovolit vytvořit prázdnou objednávku (například bez položek, nebo jiného důležitého údaje)? Může sloužit například jako template.

Jo

Dole je databázová struktura: uvažoval jsem o přidání segmentu dole, komentář "// optional". Je pro Vás důležité tímto způsobem trackovat změny na objednávce, nebo je to zbytečné a nemám to přidávat? Poté vyvstává:
4.1. generovat změnu dynamicky jako string "popis" při úpravě objednávky v databázi
4.2. nebo mít údaje jako paid, changed items, atd. aby byl snažší data quering pro nějaké statistiky. Věřím, že až tolik změn v jedné objednávce nebude, přesto to může být například i přehlednější.

Trackování úprav v rámci jedné objednávky asi není nutné.

Zákazník:

Nebyl jsem si jistý jaké parametry ukládát do databáze. Zatím jsem udělal jen "jméno a info". Což je 100% málo a bude to chtít upravit. Z #97 mi nepřipadalo zřejmé, které údaje zatím ukládat než bude modul se zákazníky bojeschopný. Budu rád za upřesnění: zda mám například načítat prozatím "jen" firmu atd.
Po upřesnění "1" mám pravděpodobně tvořit zároveň zákazníky jako jednotlivé dokumenty v customer collection v databázi, kdyby se změnili jejich údaje ať jsou v objednávce ty staré (embedded, ne linked) údaje, ale nemusí se customers vypisovat? Viz. struktura níže.

Takhle, jak máš navrženou strukturu db, tak se mi to líbí, že ten "zákazník" je tam vložený jako jeden objekt. Což znamená, že pak vytvoření adresáře bude jednoduché a pak se zákazník pouze nalinkuje do této json struktury.

Zakazník je vždy u objednávky právě 1, že?

Tohle je složitý problém. Protože je úplně reálné, aby jeden zákazník vytvořil objednávku, která se skládá ze dvou faktur pro dva jiné zákazníky :). Nevím, jak k tomuto problému teď přistoupit. To by bylo se o tom pobavit s @ChroustJan

Databázová struktura:

Bylo by užitečné k položkám přidat link na položku ze skladu. To je ObjectId. Musí ale existovat možnost vložit řádek bez této reference.

Pak tam chybí boolean, jestli všechny hodnoty jsou načtené ze skladu (od položky) nebo jsou ručně upravené.

Jinak mi ta struktura přijde fajn.

[cisar2218]

Ahoj, je někde prosím dokumentace k api /store/api/products/, nebo celkově k API, které přistupuje k položkám ve skladě? Kontext je nahrávání položek do objednávky: Filtrování položek podle parametrů a výrazu ze searchbaru při výběru položky uživatelem (podobné jako je v modulu sklad). @roman-dvorak

[cisar2218]

Generování PDF:

1. Budou k dispozici nějaké detailnější informace o tom jak mají jednotlivé dokumenty vypadat?
2. Zároveň budu rád za doplňení kontextu k interfacu:

• Aktuálně uživatel označí objednávku a klikne na generovat pdf (kde vybere typ pdf). Stačí to zatím takto?
• Pravděpodobně je vhodné nabídnout generování určitých pdf při událostech (zaplacení, vytvoření objednávky, etc). Prosím o specifikaci pokud chcete abych podobné funkce implementoval.

[roman-dvorak]

Ahoj, já jsem teď dostal upozornění až na poslední komentář. O předposledním nevím i přes to, že v něm jsem označený..

Jakou formu dokumentace by sis představoval? Aktuálně přímo "dokumetace" k tomu není. Zatím neznám způsob, jak takovou věc generovat přímo ze zdrojových kódů (a bylo to použitelné). Asi to prozatím musíme psát ručně. Které dotazy bys tedy přesně potřeboval? Sepíšu je.

Budou k dispozici nějaké detailnější informace o tom jak mají jednotlivé dokumenty vypadat?

Tohle asi zálží, jakou cestu generování PDF zvolíš. Jestli půjdeš cestou nějakého latexu a .tex šablony, která se bude editovat samostatně? Nebo se "grafika" dokumentů bude generovat přímo z python kódu?

Myslím, že @ChroustJan by nám mohl poskytnout vzory faktur, se kterými se mu dobře pracuje. tj. jsou přehledné a snadno se v nich orientuje. To je z hlediska podoby dokumentů asi hlavní požadavek.

Zároveň budu rád za doplňení kontextu k interfacu:

Já jsem tvé aktuální rozhraní ještě neviděl. Nestihl jsem si ho stáhnout.

Vygenerovaní určitého dokumentu na tlačítko je určitě potřebná funkce. Potřeba takové možnosti má mnoho důvodů.
Generování za určitých podmínek (tj např. zaplacení, vytvoření objednávky) jsou určitě zajímavé a do budoucna potřebné funkce. Aktuálně ale nemám vymyšleno, jak si takové eventy uvnitř intranetu předávat. Možná by to chtělo zavést nějaké queue. A zároveň nějaký proces, který by pracoval i mimo požadavků z prohlížečů.

Což by chtělo asi rozsáhlejší debatu nad architekturou předávání takových zpráv a akcí.

[cisar2218]

Jelikož modul objednávek je relativně velký, budu jednotlivé dokumenty zpracovávat jednotlivě:

• zálohová faktury
• faktury
• doklady o přijetí zálhovové faktury
• dodací listy
• opravné daňové doklady