Jak řešit změny v cenách produktů?

Skript ukládá do databáze název produktu, pořizovací cenu, prodejní cenu, množství Příjem - zvyšuje se množství ve skladu Výdej - dělám podobně jako příjem, ale zde mám vlastní skutečnou prodejní cenu a množství se odečte ze skladu. tabulky: products, import, import_products, export, export_products Zisk počítám podle rozdílu prodejní a pořízovací ceny * množství Problém nastává ve chvíli, kdy se změní pořizovací cena. Kdybych pořizovací cenu změnil, změnil bych tím i dosavadní zisk předešlých období, což nechci.  Jak se tento problém v praxi řeší? Každý měsíc ukládat do nové tabulky zisk daného měsíce?

aneb skladová evidence. K importu si přidej tabulku s nákupní cenou produktu (klidně tam ještě rozpočítej náklady na dopravu), přidej si do té tabulky i množství a pak aloupec s prodaným množstvím, to snižuj od nejstarší aneb skladová metoda FIFO.Nejjednodušší varianta je asi takhle:import_products_prices (import_product_price_id, import_id, import_product_id, unit_price, quantity, remain_quantity)Při importu si vyplníš do import_products_prices vždy jeden řádek pro každou různou nákupní cenu, rovnou si tam ukládej rozpočítanou cenu na jeden ks, ulož si tam množství, které takhle máš, kolik jsi jich ještě neprodal (na začátku tam bude stejné množství jako v quantity) a vazbu na produkt. Pro jeden produkt tady pak máš více řádků.Při počítání marží na konci měsíci si vezmeš prodané množství pro každý produkt, vezmeš si všechny řádky z téhle tabulky pro produkt, vyfiltruješ jen ty, které mají nenulové zbývající množství (remain_quantity), seřadíš od nejstaršího a postupně budeš množství snižovat k nule dokud takhle nerozpadneš počet prodaných produktů v měsíci. Zároveň si u toho vypočítáš marži podle unit_price podle toho o kolik jsi snížil remain_quantity.Většinou to zvládne naprogramovat i začátečník. Je to asi nejjednodušší metoda, není nejsprávnější, nedodržují se tam normálové formy na tvorby databázových tabulek, ale pro malý eshop dostatečné. Mimochodem, přesně takhle to bylo třeba na slevomatu v prvních měsících než se to přepsalo do klasické skladové evidence.

import_products_prices (import_product_price_id, import_id, import_product_id, unit_price, quantity, remain_quantity)

Remain quantity se mi zdá suprové, takhle můžu sledovat, kolik jsem v té době toho měl. Tohle mi zatím chybělo. Zisk Co takhle při exportu automaticky vzít si pořizovací cenu z tabulky products a vložit do export_products. Měl bych pak v té tabulce prodejní, pořízovací cenu a množství. Tam by mi to zůstalo, nehledě na to, jak by se v budoucnu měnila cena produktů. Navíc se nemusím hrabat v tabulce import

nevím, co přesně obsahuje tabulka export_products a k čemu je. Čekal bych, že tam každý řádek ukazuje na nějaký produkt, pokud bys to chtěl dělat jak píšeš, muselo by tam být pro jeden produkt více řádků podle toho, jak se měnila nákupní cena.

Napsal TomášX;1649156

nevím, co přesně obsahuje tabulka export_products a k čemu je. Čekal bych, že tam každý řádek ukazuje na nějaký produkt, pokud bys to chtěl dělat jak píšeš, muselo by tam být pro jeden produkt více řádků podle toho, jak se měnila nákupní cena.

mám strukturu takto: products: id, name, quantity, unit_cost, selling_price, quantity... import: id, total_price... import_products: product_id, import_id, quantity, current_quantity export (faktura): id, total_price... export_products (seznam zboží): product_id, export_id, quantity, unit_cost, selling_price... měnit se bude jenom nákupní cena v tabulce products. prodejní cena v products je jenom orientační. V export_products je skutečná prodejní cena. Tam vložím současnou nákupní cenu, která se měnit nebude. Co ještě vylepšit? 

ok, export je tedy prodej. Vyhnul bych se uvádět nákupní cenu v tabulce export z několika důvodů:- co když zákazník koupí dva produkty a ty máš každý za jinou nákupní cenu?- když uděláš něco špatně, blbě se to opravuje, měsíční nápočet můžeš lépe testovat a případně opravovatJe dobré účetní operace (nákupní cena je účetní údaj) držet mimo provozní, tj. aspoň v samostatných tabulkách a je také dobré při samotném nákupu v eshopu dělat jen ty nejnutnější změny v db, snížit možnost, že díky chybě v aplikaci přijdešo objednávku, co nejvíce operací přesuň na procesy na pozadí, což je třeba nápočet marží.