Jaka struktura tabel do programu magazynowego
Tdobe - 29-12-2006 00:25
Jaka struktura tabel do programu magazynowego
Witaj,
Chce napisac juz kolejny program magazynowy, stosowałem różne
techniki w bazie danych, przewaznie to takie tablice:
Kontraheci (kontrahent_id, nazwa, adres...)
Magazyny (Magazyn_id, Nazwa, ....)
Czesci (czesc_id, index, nazwa, ....)
Bilanse_otwarcia (bilans_otwarcia_id, rok, miesiac, kontrahent_id,
czesc_id, sztuk....)
Typy_ruchow (typ_ruchu_id, oznaczenie, znak)
Historia_ruchow_magazynowych(magazyn_id, kontrahent_id, czesc_id,
typ_ruchu_magazynowego, sztuk, ...)
Na takiej to prostej strukturze można sobie zorganizowac prosty
magazyn z dowolna ilością ruchów magazynowcyh (PZ, PW, RW...) oraz
można dostać obroty na dowolnym ruchu i stan magazynowy NA DOWOLNY
DZIEN.
To jest taki przykład jednak ma on wady, jedna z nich skoplikowane
zapytania (uwzgledniajace BO i historię rychów magazynowych), druga
to taka ze tabela przetrzymujaca BO oraz historie rychów cały czas
rośnie, więc z upływem czasu szybkość spada...
Robiełem też rozwiązania, Bilanse_otwarcia dwie tabele magazyn_stan,
magazyn_wydane, w magazynie stan zawsze było tylko to co jest na
stanie a magazyn_wydane juz tylko wydane artykuły.
Jak tak naprawdę najlepiej zorganizować strukturę w bazie danych
zeby mieć wszystko oraz jak najbardziej zoptymalizowane pod względem
wydajności?
pwola - 29-12-2006 00:25
>Jak tak naprawdę najlepiej zorganizować strukturę w bazie danych
>zeby mieć wszystko oraz jak najbardziej zoptymalizowane pod względem
>wydajności?
Nie ma chyba uniwersalnych rozwiązań - dużo zależy od skali
magazynu/obrotów oraz sposobu rozliczania magazynów.
Ale spróbujmy przemyśleć różne warianty:
1. Księgowy
Bilans otwarcia miesiąca + przychody - rozchody = bilans zamknięcia
miesiąca +- przeceny magazynowe
Zalety:
prosto się księguje i weryfikuje,
preferowane stosowanie cen ewidencyjnych,
stosowanie cen średnich, ważonych, zakupu również możliwe
Wszystkie dokumenty można (a nawet trzeba łącznie z BO) wrzucić do
jednej tabeli (tzn. 2 nagłówek i pozycje)
i pilnować żeby rozchód nie był wpisany wcześniej niż przychód ;-)
Stany liczą się szybko można stosować nawet dla dużych hurtowni
i tak liczy się tylko miesiąc. Stan na koniec miesiąca oczywisty.
Wady:
Zamknięcie miesiąca :( no chyba, że tabele roczne to roku
Średnio duża ilość tabel miesięcznych
Przy raportach rocznych trzeba liczyć każdy miesiąc osobno i sumować
2. Magazynowy
tak jak poprzednio ale nie robimy tabel miesięcznych tylko jedną dużą
Zalety:
Prosto się robi i łatwo raportuje z kilku lat
Wady:
System z miesiąca na miesiąc chodzi coraz wolniej i coraz dłużej robią
się backupy aż w końcu nocy nie starcza na zrobienie kopii :-(
Policzenie stanu bieżącego i stanu na dzień też trwa coraz dłużej
3."Hurtowniany"
tak jak poprzednio ale tabelę dzielimy na stany "bieżące" i
"archiwalne"
Zalety:
Stany bieżące możemy sprawdzić w miarę szybko i system nie zwalnia z
roku na rok (tylko przy raportowaniu)
Wady:
Raportujemy z dwóch tabel małej (bieżącej) i ogromnej (archiwalnej)
a to oznacza, bardziej skomplikowane raporty (i z roku na rok coraz
dłuższe).
Przenoszenie rekordów pomiędzy tabelami musi być w transakcji (bo w
razie awarii ....)
Robienie raportów w trakcie przenoszenia danych pomiędzy tabelami nie
jest dobrym pomysłem :-(
4. Wersje jak 1-3 ale dokumenty przychodowe i rozchodowe w różnych
tabelach
Zalety:
Można lepiej dostosować przechowywane dane
Wady:
Nie można precyzyjnie określić kolejności przychodów i rozchodów (cena
średnia ważona)
5. Jak 4 ale dokumenty korygujące w osobnych tabelach
Zalety i wady: Tak jak poprzednio
6. Jak 4 i 5 ale stany bieżące trzymamy w osobnej tabeli (niezależnie
od dokumentów przychodowych i rozchodowych)
Zalety:
Chyba najlepsze rozwiązanie przy kilkudziesięciu tysiącach
asortymentów towaru do sprzedaży
Wady:
No tutaj to już naprawdę można nieźle namieszać ;-)
Jeżeli opuściłem jakieś rozwiązanie to proszę o uzupełnienie.
Na co należy jeszcze zwrócić uwagę przy budowie takiego programu:
- obsługa wielu magazynów
- obsługa wielu obszarów w magazynach
- półki (miejsca składowania)
- przesunięcia międzymagazynowe (ceny rozliczeniowe ! )
- przesunięcia pomiędzy lokalizacjami
- czas pomiędzy dostarczeniem towaru a jego przyjęciem (może być kilka
dni bo np. czekamy na fakturę)
- to samo przy wydaniu ("ujemne" sztuki na magazynie bo towar już
wyjechał do klienta a formalnie nie został jeszcze "zdany" z
produkcji)
- obsługa rezerwacji towaru
- system weryfikacji dostaw z zamówieniami
- rozliczenia PZ z fakturami zakupu
- inwentaryzacje magazynowe
- postępowanie ze stratami (i nadwyżkami ) magazynowymi
- kody kreskowe
- identyfikacja towaru na poziomie serii i pozycji dostawy
- wagi i wymiary
Uff, koniec pomysłów - może ktoś dorzuci coś jeszcze :-)
Piotr
Paweł Matejski - 29-12-2006 00:25
Tdobe wrote:
> Witaj,
>
> Chce napisac juz kolejny program magazynowy, stosowałem różne
> techniki w bazie danych, przewaznie to takie tablice:
>
> Kontraheci (kontrahent_id, nazwa, adres...)
> Magazyny (Magazyn_id, Nazwa, ....)
> Czesci (czesc_id, index, nazwa, ....)
> Bilanse_otwarcia (bilans_otwarcia_id, rok, miesiac, kontrahent_id,
> czesc_id, sztuk....)
> Typy_ruchow (typ_ruchu_id, oznaczenie, znak)
> Historia_ruchow_magazynowych(magazyn_id, kontrahent_id, czesc_id,
> typ_ruchu_magazynowego, sztuk, ...)
>
> Na takiej to prostej strukturze można sobie zorganizowac prosty
> magazyn z dowolna ilością ruchów magazynowcyh (PZ, PW, RW...) oraz
> można dostać obroty na dowolnym ruchu i stan magazynowy NA DOWOLNY
> DZIEN.
>
> To jest taki przykład jednak ma on wady, jedna z nich skoplikowane
> zapytania (uwzgledniajace BO i historię rychów magazynowych),
Wywal tabele bilans_otwarcia i załatw to odpowiednim 'ruchem' (ja wole taką
tabele nazywać operacje) na otwarcie - zdefiniuj sobie w tym celu specjalny typ
ruchu.
> druga
> to taka ze tabela przetrzymujaca BO oraz historie rychów cały czas
> rośnie, więc z upływem czasu szybkość spada...
Na to nie ma rady. Możesz co pewien czas archiwizować dane, jeśli już nie będą
potrzebne.
> Robiełem też rozwiązania, Bilanse_otwarcia dwie tabele magazyn_stan,
> magazyn_wydane, w magazynie stan zawsze było tylko to co jest na
> stanie a magazyn_wydane juz tylko wydane artykuły.
Tabele aktualnego stanu warto mieć, ale jedynie ze względów wydajnościowych. Jej
aktualizacją powinny zajmować sie trigger.
--
P.M.
Tdobe - 29-12-2006 00:25
No w sumie największą prawdą chyba jest ze nie ma złotego środka,
połowe tych metod stosowałem, i podejście podobne...
dzieki za info,
acha to co robię to już 4 system magazynowy na produkcji, takze pola
składowania i wiele magazynów też uwzględniam, pozdrawiam
ktos - 29-12-2006 00:25
pwola napisał(a):
> Nie ma chyba uniwersalnych rozwiązań - dużo zależy od skali
> magazynu/obrotów oraz sposobu rozliczania magazynów.
> Ale spróbujmy przemyśleć różne warianty:
>
Moglibyscie powiedziec jak rozwiazac sprawe korekt wartosciowych:
- zakupiono 100 sztuk po 10 zl
- na RW/WZ... wydano 10 sztuk po 10 zl na jakis tam cel, 30 sztuk na
inny cel. zostalo 60 sztuk = 600 zl
i teraz, zalozmy ze przychodzi korekta, ze cena zakupu to nie 10 zl a
np. 8.
Zakladamy, ze dokumenty obrotu to struktura master/detail (naglowek +
pozycje), zapas trzymam w odzielnej tabeli.
W pozycjach i tabeli zapasow trzymam m.in. cene.
Razem z korekta zmieniam cene w tabeli z zapasem aktualnym. Wiec
nastepne rozchody mam po nowej cenie.
Ale jak zapisac te korekty, zeby raporty za okres po korekcie pokazywaly
wartosc rozchodu na te dwa cele juz z uwzglednieniem korekty?
Tworzyc sztucznie korekty do tych RW/WZ-tow?
Herakles - 29-12-2006 01:38
Tdobe wrote:
> Witaj,
>
> Chce napisac juz kolejny program magazynowy, stosowałem różne
> techniki w bazie danych, przewaznie to takie tablice:
>
> Kontraheci (kontrahent_id, nazwa, adres...)
> Magazyny (Magazyn_id, Nazwa, ....)
> Czesci (czesc_id, index, nazwa, ....)
> Bilanse_otwarcia (bilans_otwarcia_id, rok, miesiac, kontrahent_id,
> czesc_id, sztuk....)
> Typy_ruchow (typ_ruchu_id, oznaczenie, znak)
> Historia_ruchow_magazynowych(magazyn_id, kontrahent_id, czesc_id,
> typ_ruchu_magazynowego, sztuk, ...)
>
> Na takiej to prostej strukturze można sobie zorganizowac prosty
> magazyn z dowolna ilością ruchów magazynowcyh (PZ, PW, RW...) oraz
> można dostać obroty na dowolnym ruchu i stan magazynowy NA DOWOLNY
> DZIEN.
>
> To jest taki przykład jednak ma on wady, jedna z nich skoplikowane
> zapytania (uwzgledniajace BO i historię rychów magazynowych), druga
> to taka ze tabela przetrzymujaca BO oraz historie rychów cały czas
> rośnie, więc z upływem czasu szybkość spada...
>
> Robiełem też rozwiązania, Bilanse_otwarcia dwie tabele magazyn_stan,
> magazyn_wydane, w magazynie stan zawsze było tylko to co jest na
> stanie a magazyn_wydane juz tylko wydane artykuły.
>
> Jak tak naprawdę najlepiej zorganizować strukturę w bazie danych
> zeby mieć wszystko oraz jak najbardziej zoptymalizowane pod względem
> wydajności?
Zabawa w magazyn to nie rurki z kremem.
Sławomir Szyszło - 30-12-2006 01:03
Dnia Fri, 29 Dec 2006 00:09:52 +0100, ktos <bo@kr.onet.pl> wklepał(-a):
>pwola napisał(a):
>> Nie ma chyba uniwersalnych rozwiązań - dużo zależy od skali
>> magazynu/obrotów oraz sposobu rozliczania magazynów.
>> Ale spróbujmy przemyśleć różne warianty:
>>
>
>Moglibyscie powiedziec jak rozwiazac sprawe korekt wartosciowych:
>- zakupiono 100 sztuk po 10 zl
>- na RW/WZ... wydano 10 sztuk po 10 zl na jakis tam cel, 30 sztuk na
>inny cel. zostalo 60 sztuk = 600 zl
>
>i teraz, zalozmy ze przychodzi korekta, ze cena zakupu to nie 10 zl a
>np. 8.
To może tak:
- zwrot tych wydanych przez RW/WZ
- zwrot przyjętego towaru
- ponowne przyjęcie z nową ceną
- ponowne wydanie.
Problem się komplikuje, jeśli towar faktycznie został wydany i poszła faktura.
:)
>Zakladamy, ze dokumenty obrotu to struktura master/detail (naglowek +
>pozycje), zapas trzymam w odzielnej tabeli.
>W pozycjach i tabeli zapasow trzymam m.in. cene.
>Razem z korekta zmieniam cene w tabeli z zapasem aktualnym. Wiec
>nastepne rozchody mam po nowej cenie.
A te zapasy masz rozbite na poszczególne partie towaru? Bo inaczej taka cena to
OKDR. Chyba, że to cena uśredniona, ale wtedy i tak jest bezużyteczna, bo do
rozliczeń nie użyjesz jej.
--
Sławomir Szyszło mailto:slaszysz@poczta.onet.pl
Primus inter FAQires & Grand Inquisitor no.0 of pl.comp.bazy-danych
FAQ pl.comp.bazy-danych http://www.dbf.pl/faq/
Archiwum http://groups.google.com/groups?grou...mp.bazy-danych
Paweł Matejski - 30-12-2006 01:03
Sławomir Szyszło wrote:
> Dnia Fri, 29 Dec 2006 00:09:52 +0100, ktos <bo@kr.onet.pl> wklepał(-a):
>
>> pwola napisał(a):
>>> Nie ma chyba uniwersalnych rozwiązań - dużo zależy od skali
>>> magazynu/obrotów oraz sposobu rozliczania magazynów.
>>> Ale spróbujmy przemyśleć różne warianty:
>>>
>> Moglibyscie powiedziec jak rozwiazac sprawe korekt wartosciowych:
>> - zakupiono 100 sztuk po 10 zl
>> - na RW/WZ... wydano 10 sztuk po 10 zl na jakis tam cel, 30 sztuk na
>> inny cel. zostalo 60 sztuk = 600 zl
>>
>> i teraz, zalozmy ze przychodzi korekta, ze cena zakupu to nie 10 zl a
>> np. 8.
>
> To może tak:
> - zwrot tych wydanych przez RW/WZ
> - zwrot przyjętego towaru
> - ponowne przyjęcie z nową ceną
> - ponowne wydanie.
>
> Problem się komplikuje, jeśli towar faktycznie został wydany i poszła faktura.
> :)
Ale po co tak komplikować? Przecież cena wydania nie powinna mieć związku z ceną
przyjęcia (z punktu widzenia struktury), co najwyżej zysk będzie większy lub
strat się dorobi.
Ja bym tylko zmienił cenę przy przyjęciu (w osobnej tabeli rejestrując korektę)
ewentualnie zrobił zwrot i przyjęcie z typem operacji korekta.
--
P.M.
Piotr Kulinski - 30-12-2006 01:03
Fri, 29 Dec 2006 00:09:52 +0100, na pl.comp.bazy-danych, ktos napisał(a):
> pwola napisał(a):
>> Nie ma chyba uniwersalnych rozwiązań - dużo zależy od skali
>> magazynu/obrotów oraz sposobu rozliczania magazynów.
>> Ale spróbujmy przemyśleć różne warianty:
>>
>
> Moglibyscie powiedziec jak rozwiazac sprawe korekt wartosciowych:
> - zakupiono 100 sztuk po 10 zl
> - na RW/WZ... wydano 10 sztuk po 10 zl na jakis tam cel, 30 sztuk na
> inny cel. zostalo 60 sztuk = 600 zl
>
> i teraz, zalozmy ze przychodzi korekta, ze cena zakupu to nie 10 zl a
> np. 8.
>
> Zakladamy, ze dokumenty obrotu to struktura master/detail (naglowek +
> pozycje), zapas trzymam w odzielnej tabeli.
> W pozycjach i tabeli zapasow trzymam m.in. cene.
> Razem z korekta zmieniam cene w tabeli z zapasem aktualnym. Wiec
> nastepne rozchody mam po nowej cenie.
>
> Ale jak zapisac te korekty, zeby raporty za okres po korekcie pokazywaly
> wartosc rozchodu na te dwa cele juz z uwzglednieniem korekty?
>
> Tworzyc sztucznie korekty do tych RW/WZ-tow?
korekty powowinny być trzymane tak jak inne dokumenty magazynowe. Moze być
problem przy wystawianiu korekty - np. korekty zbiorcze, jedna korekta
kordyguje powiedzmy 20 faktur. Jeśli korekta koryguje pojedyńczy dokument
(idealne rozwiązanie) to nie ma problemu z wiązaniem dokument korekta.
Zresztą nawet jeśli koryguje wiele dokumentów to musi istnieć IMO tabela
linkująca koretka + dokument - i oczywiście który artykuł tyczy którego
dokumentu.
Chyba że mówisz o innych korektach, np. korygujacych stan, cenę itp. Dla
mnie sąto "noty korygujące", de facto to i tak dokumenty.
--
pozdrawiam, GG i SkyPe w X-nagłówku posta, e-mail: zmień wpw na wp
piotr
Kto powiedział że życie to bajka
biuro@msv-soft.pl - 30-12-2006 01:03
ktos napisał(a):
> pwola napisał(a):
> > Nie ma chyba uniwersalnych rozwiązań - dużo zależy od skali
> > magazynu/obrotów oraz sposobu rozliczania magazynów.
> > Ale spróbujmy przemyśleć różne warianty:
> >
>
> Moglibyscie powiedziec jak rozwiazac sprawe korekt wartosciowych:
> - zakupiono 100 sztuk po 10 zl
> - na RW/WZ... wydano 10 sztuk po 10 zl na jakis tam cel, 30 sztuk na
> inny cel. zostalo 60 sztuk = 600 zl
>
> i teraz, zalozmy ze przychodzi korekta, ze cena zakupu to nie 10 zl a
> np. 8.
>
> Zakladamy, ze dokumenty obrotu to struktura master/detail (naglowek +
> pozycje), zapas trzymam w odzielnej tabeli.
> W pozycjach i tabeli zapasow trzymam m.in. cene.
> Razem z korekta zmieniam cene w tabeli z zapasem aktualnym. Wiec
> nastepne rozchody mam po nowej cenie.
>
> Ale jak zapisac te korekty, zeby raporty za okres po korekcie pokazywaly
> wartosc rozchodu na te dwa cele juz z uwzglednieniem korekty?
>
> Tworzyc sztucznie korekty do tych RW/WZ-tow?
Odpowiedz jest prosta, potrzebny jest jeden dokument
" Korekta wartosci magazynu (dokument wewnetrzny)" zakładając ze
towar został sprzedanyWZ, wydanyRW
Dokument RW jak i WZ jest dokumentem kosztowym
zakładajac ze przyjelismy
15 sz po 10zł = 150zł
caly towar wydano RW/WZ
wiec w koszty zaksiegowano 150zł
korekta
15szt po 9zł = 135zł
po otrzymaniu korekty cenowej nalezy w programie magazynowym wykonac
tylko korekte wartosci magazynu
= -15zł
i to wszystko
pozdrawiam
Piotr Kulinski - 30-12-2006 01:03
29 Dec 2006 09:42:55 -0800, na pl.comp.bazy-danych, biuro@msv-soft.pl
napisał(a):
[ciach]
>> Tworzyc sztucznie korekty do tych RW/WZ-tow?
>
> Odpowiedz jest prosta, potrzebny jest jeden dokument
> " Korekta wartosci magazynu (dokument wewnetrzny)" zakładając ze
> towar został sprzedanyWZ, wydanyRW
>
> Dokument RW jak i WZ jest dokumentem kosztowym
> zakładajac ze przyjelismy
> 15 sz po 10zł = 150zł
> caly towar wydano RW/WZ
> wiec w koszty zaksiegowano 150zł
>
> korekta
> 15szt po 9zł = 135zł
> po otrzymaniu korekty cenowej nalezy w programie magazynowym wykonac
> tylko korekte wartosci magazynu
> = -15zł
>
i do ładu nie dojdziesz :)
Zależy jak jest księgowany magazyn... jesli każda sztuka jest księgowana z
osobna (np. tzw. specyfikacje artykułów) to warto wiedzieć do której sztuki
odnosi się korekta. Zależy też jak jest księgowany magazyn w systemie FK i
jak jest prowadzona - o ile jest - kalkulacja kosztów i cen.
Nigdy bym nie dopuścił żeby lakonicznie wprowadzić dokument który np. coś
skoryguje ale nie wiadomo co. Korekta jest do konkretnego dokumentu/ów.
--
pozdrawiam, GG i SkyPe w X-nagłówku posta, e-mail: zmień wpw na wp
piotr
Nic nie stoi na przeszkodzie, co by przeszkody sobie nie stworzyć :)
ktos - 30-12-2006 01:03
biuro@msv-soft.pl napisał(a):
>
> Dokument RW jak i WZ jest dokumentem kosztowym
> zakładajac ze przyjelismy
> 15 sz po 10zł = 150zł
> caly towar wydano RW/WZ
> wiec w koszty zaksiegowano 150zł
>
> korekta
> 15szt po 9zł = 135zł
> po otrzymaniu korekty cenowej nalezy w programie magazynowym wykonac
> tylko korekte wartosci magazynu
> = -15zł
>
> i to wszystko
Niezupelnie.
Jesli rozchodowano całą dostawę do nie ma co korygować wartości
magazynu, bo już na nim nic nie ma. Korekta dotyczy cen faktury
zakupowej czyli PZ-tu. Korektę wiążemy z PZ-tem,to oczywiste, ale jak
skorygować wartośc rozchodów?
Kazdy program musi miec raporty typu:
BO + przychody - rozchody w cenach ewidencyjnych = stan koncowy
czyli PZ 15 szt x 10 zł = 150 zł
RW 10 szt x 10 zł = 100 zł
zostaje 5 szt x 10 zł = 50 zł
Teraz korekta (różnica)
PZ-S 15 szt x -2 zł = 30 żł
W chwili jej wprowadzania na stanie jest 5 szt, warte teraz 8 zł, wiec
zapas koncowy to 40 zł
A my po korekcie PZ-tu mamy:
- zakupy 15 szt x 10 zł = 150 zł
- korekta 15 szt x -2 zł = -30 zł
- rozchody 10 szt x 10 zł = 100 zł
Czyli zapas to 5 szt i 20 zł, a ma byc 5 szt po 8 zł.
Zakladam oczywiscie, ze korekta to oddzielny zapis powiazany i
pierwotnym PZ-tem ale nie zmieniajacy jego ceny na zasadzie aktualizacji
w miejscu.
Jesli z 15 szt. rozchodowano 10 zostało 5, korygujemy wartośc tych 5
szt. to pewnie powinnismy tez utworzyc korekte do rozchodow o wartosci
10 x -2 zł. To by sie dało zrobic. Ale przeciez zamiast jednego RW/WZ
moze byc ich cała masa:
- w firmie produkcyjnej RW na rozne zlecenia produkcyjne/ budowy/
- W firmie handlowej WZ przypisane roznym przedstawicielom. ich premia
zalezy od marzy.
I program ma oczywiscie raporty pokazujace pobrania materiałów ogólem
ale i w rozbicu na te miejsca powstawania kosztow/akwizytorow...
Jak uwzgledniacie na nich te korekty?
Jezeli korekta dotyczyla dostawy z ktorej byly n rozchodow to program
tworzy do kazdego z nich korekte? Wtedy wprowadzanie korekty jest
popier-..ne ale raporty sa proste czy tez nie tworzycie korekt ale wtedy
raporty sa b. złożone?
Może wypowie sie ktos znajacy jakąś Symfonie Forte/CDN XL czy innego
SAP-a, jak oni to robią?
pwola - 30-12-2006 01:03
>Moglibyscie powiedziec jak rozwiazac sprawe korekt wartosciowych:
>- zakupiono 100 sztuk po 10 zl
>- na RW/WZ... wydano 10 sztuk po 10 zl na jakis tam cel, 30 sztuk na
>inny cel. zostalo 60 sztuk = 600 zl
>
>i teraz, zalozmy ze przychodzi korekta, ze cena zakupu to nie 10 zl a
>np. 8.
>
To już wiąże się ze sposobem ksiegowań
(i jak dokładne mają być raporty )
Normalnie to proponowałbym tak
PZ 100 szt x 10 zł
RW 10 szt x 10 zł
RW 30 szt x 10 zł
Korekta PZ 100 szt x ( 10 - 8 ) zł
Korekta RW (może być zbiorcza) 40 szt x (10 - 8) zł
Następne RW schodzą po 8 zł
Wersja 2:
Ceną ewidencyjną jest 10 zł
Korekty ksiegujemy w odchylenia cen zakupu od cen ewidencyjnych
Wersja 3. Księgujemy jak leci - różnice wrzucamy w koszty :)
Jacek Czapla - 31-12-2006 00:04
WOW. Odpowiedź godna Twojego nicka.
--
*Jacek Czapla* //usuń ".pułapka" z adresu email
www.ASIT.pl
http://www.busyonline.pl - Rezerwacja miejsc w busach
Herakles - 01-01-2007 00:25
Jacek Czapla wrote:
> WOW. Odpowiedź godna Twojego nicka.
>
ok. prosty magazyn kilka tabel,
ale wszystkie wejścia sprzedaże faktury rezerwacje przesunięcia ....
fakt ładujesz dokumanty do jednej tabeli, linijki dokumentów do drugiej,
dodajesz jeszcze tabelkę z produktami i masz magazyn na 3 tabelach, ale już
chcesz rozbudować to o pola dodatkowe, klientów, do tego zrobić to
dodatkowo z tabelami historycznymi, waluty to już robi się więcej tabel.
Jadę dalej, dorzucę grupy klientów i różne ceny dla nich otrigerować to,
żeby ceny się uśredniały, no i userów samego magazynu, ich grupy i
uprawnienia dla tych grup, do tego jeszcze będziesz chciał w przyszłości
definiować własne typy dokumentów, więc parę tabel w których to pomieścisz,
a jak będzie trzeb stiker podłączyć......
To na pewno się zgodzisz, że porządny magazyn będzie tych tabelek miał
multum.
Piotr Kulinski - 01-01-2007 00:25
Sun, 31 Dec 2006 05:07:32 +0100, na pl.comp.bazy-danych, Herakles
napisaů(a):
[ciach]
> To na pewno sić zgodzisz, ýe porzŕdny magazyn bćdzie tych tabelek miaů
> multum.
a to cytat z wŕtku startowego.
Na takiej to prostej strukturze moýna sobie zorganizowac prosty
magazyn z dowolna iloúciŕ ruchów magazynowcyh (PZ, PW, RW...) oraz
moýna dostaă obroty na dowolnym ruchu i stan magazynowy NA DOWOLNY
DZIEN.
"prosty magazyn", wićc nie komplikuj sprawy. W ten sposób moýna rozbudowaă
program do systemu ERP, a i tak zawsze bćdzie czegoú brakowac.
--
pozdrawiam, GG i SkyPe w X-nagůówku posta, e-mail: zmień wpw na wp
piotr
Uśmiechnij sić, śmiech to zdrowie
Jacek Czapla - 01-01-2007 00:25
Ja z Twoim stwierdzeniem nie polemizuję. Chodziło mi o to, że Twoja
odpowiedź była zupełnie zbędna, bez żadnej interesującej treści.
--
*Jacek Czapla* //usuń ".pułapka" z adresu email
www.ASIT.pl
http://www.busyonline.pl - Rezerwacja miejsc w busach
Herakles - 02-01-2007 01:26
Jacek Czapla wrote:
> Ja z Twoim stwierdzeniem nie polemizuję. Chodziło mi o to, że Twoja
> odpowiedź była zupełnie zbędna, bez żadnej interesującej treści.
>
>
faktycznie, muszę przyznać ci rację.
Jacek Czapla - 03-01-2007 00:24
Szacunek 4u.
--
*Jacek Czapla* //usuń ".pułapka" z adresu email
www.ASIT.pl
http://www.busyonline.pl - Rezerwacja miejsc w busach
pe3no@N05PAM.o2.pl - 03-01-2007 00:24
Tdobe napisał(a):
[...]
> To jest taki przykład jednak ma on wady, jedna z nich skoplikowane
> zapytania (uwzgledniajace BO i historię rychów magazynowych), druga
Być może coś w rodzaju hurtowni danych byłoby jakimś wsparciem?
Prekalkulacja złożonych zapytań w czasie, gdy system nie jest obciążony,
choć nie do końca jestem pewien, czy dobrze zrozumiałem intencję :)
> to taka ze tabela przetrzymujaca BO oraz historie rychów cały czas
> rośnie, więc z upływem czasu szybkość spada...
Może pomogłyby pola wyliczeniowe obsługiwane przez wyzwalacze?
Wstawiam do tabeli operac_mag (INSERT) WZ -2 sztuki produktu ID=1.
Wówczas wyzwalacz na tabeli operac_mag z tabeli produkty zdejmuje
ze stanu 2 sztuki produktu o ID=1. Niesie to za sobą oczywiście
ryzyko utraty spójności, jeżeli coś źle oprogramujemy lub czegoś nie
przewidzimy (konieczny wyzwalacz na UPDATE/DELETE, który też modyfikuje
stan).
Pozdrawiam~~Piotrek~~pe3no.
zanotowane.pldoc.pisz.plpdf.pisz.pleffulla.pev.pl
|
oracle -> oracle lub oracle -> mysql replikacja - programy
[spam] sprzedam używane programy Adobe/Macromedia [spam sprzedam]
Prezentacja =?ISO-8859-2?Q?zdj=EA=E6_z_w=B3=B1czeniem/wy=B3a?==?ISO-8859-2?Q?czeniem_-_jaki_program_polecacie_do_tego_?=
Program do konwersji =?ISO-8859-2?Q?zdj=EA=E6_B=26W_-=3E_?==?ISO-8859-2?Q?kolor?=
[mysql] =?ISO-8859-2?Q?wielko=B6=E6_bazy_a_stabilno=B6=E6=2C?==?ISO-8859-2?Q?_podzia=B3_du=BFej_bazy_a_powi=B1zania_tabel?=
SQL Server 2005: początkujący programista T-SQL ma problem
[MSSQL2000] Problem z =?ISO-8859-2?Q?tabel=B1/indeksem/zapytanie?==?ISO-8859-2?Q?m_czy_b=B3=B1d_w_bazie_danych=2E=2E=2E?=
Import faktur do Insert Subiekt GT oraz Wapro Wf-Mag z innego programu
=?iso-8859-2?Q?program_foxpro_i_win_vista_=3F_w_xp_dzia=B3a=B 3o.?=
[Oracle] Czy znacie jakiś programik który wykonuje sie z lini poleceń do porównywania Schemy?
zanotowane.pldoc.pisz.plpdf.pisz.pltejsza.htw.pl
Cytat
Decede mihi sole - nie zasłaniaj mi słonca.
Gdy kogoś kochasz, jesteś jak stworzyciel świata - na cokolwiek spojrzysz, nabiera to kształtu, wypełnia się barwą, światłem. Powietrze przytula się do ciebie, choćby był mróz, a ty masz w sobie tyle radości, że musisz ją rozdawać wokoło, bo się w tobie nie mieści
Hoc fac - tak czyń.
A tergo - od tyłu; z tyłu.
I czarne włosy posiwieją. Safona |
|
