Sprzedawanie i kupowanie tego samego towaru po różnych cenach. Historia kosztów i przychodów.

0

Ciekawy problem (sklep/hurtownia).
Powiedzmy, że jest tabela towary (ean, nazwa, cena).
Towary możemy kupować i sprzedawać po różnych cenach.
Mamy więc tabelę składowane_towary (ean, data_dodania, liczba_sztuk, cena_zakupu) //cena, po której towar został kupiony.
Przykład: kupujemy towary
Dnia 18/03/18 1839,049 dodajemy towar 0001 w liczbie sztuk 30, cena zakupu 490 zł/szt.
Dnia 22/03/18 1510,082 dodajemy towar 0001 w liczbie sztuk 50, cena zakupu 370 zł/szt.

Teraz sprzedaż. Raz wprowadzona do bazy cena zakupu jest stała. A cena sprzedaży w skrajnym przypadku może być inna dla każdego egzemplarza, jeżeli będzie się często zmieniać.
Jak zachować historię sprzedaży, np do późniejszego obliczenia jaki zysk wygenerował towar 0001? Muszę pamiętać liczbę sprzedanych sztuk, cenę zakupu i sprzedaży.

  1. Myślałem nad stworzeniem nowej tabeli i wrzucaniem do niej historii sprzedaży. A w tabeli składowane_towary zmniejszać liczba_sztuk po sprzedaniu towaru. Taka tabela szybko może się rozrosnąć, ale można zrobić miesięczne statystyki i inne bajery.
  2. Lub zamiast trzymania w tabeli składowane_towary dla różnych dat różnych cen produktów - przy dodawaniu jakiejś partii produktu który już jest w tabeli, obliczać nową średnią cenę zakupu dla wszystkich i trzymać ją w kolumnie. Trzeba by wtedy dodać kolumnę do sumowania zysku ze sprzedaży. Tu nie mam pełnej historii, ale tyle mi prawdopodobnie wystarczy + rekordów jest nie więcej niż produktów.
    Wyglądałoby to tak: (ean, liczba_niesprzedanych, liczba_sprzedanych, śr_cena_zakupu, całkowity_zysk).
  3. A może jeszcze inaczej?

Czy któryś sposób polecacie/odradzacie? Jak się to robi w profesjonalnych aplikacjach?

1

Na początku poradzę Ci, żebyś ceny średnie olał ponieważ mało kto z tego korzysta (chyba, że masz do czynienia ze skupem złomu gdzie cena zakupu dla każdej transakcji może być inna, ale to inna bajka....)

Nie wiem po co chcesz trzymać ceny sprzedaży w oddzielnej tabeli. Możesz sobie zysk liczyć z tabeli w której trzymasz pozycje dokumentów sprzedaży. Tak samo musisz przecież tam mieć cenę zakupu (żeby było wiadomo z której dostawy był rozchód). Więc mając te dane łatwo policzyć sobie zysk jaki masz dla danego towaru. Możesz to nawet trzymać jako dodatkowe pole np wartosc_marzy i potem tylko sobie ładnie sumujesz po towarze w rozbiciu na ceny zakupu.

Inną kwestią jest trzymanie domyślnych cen sprzedaży dla danego towaru w danej cenie zakupu. Nie wiem czy u Ciebie można tak zrobić, że towary sprzedajemy niezależnie od ceny zakupu w tej samej cenie. Jeśli tak, to sprawa jest prosta, bo wystarczy w kartotece towarów trzymać domyślną cenę sprzedaży i koniec. Jeśli nie, to musiałbyś mieć dodatkową tabelę np:
towary_ceny_sprzedazy:

  • towar_id
  • cena_zakupu
  • cena_netto
  • cena_brutto

Na początku takie coś powinno starczyć. Nad zmianą można pomyśleć jak Ci wydajność spadnie.

3

składowane_towary normalnie to się nazywa magazyn i kluczem głównym w niej jest para towar, partia. W 99% przypadków partią jest data zakupu jednak jeśli w danym dniu kupiliśmy ten sam towar z różną ceną to np. dodaje się do daty kolejne numery. Partia jako taka nie musi mieć formatu yyyy-mm-dd/kolejny_numer - może to być np yymmdd/kolejny_numer (dla wygody). Jednak format z datą, która ma postać rok miesiąc dzień ma jeden ważny aspekt - sortuje się wg daty zakupu (jeśli mamy wydania FIFO/LIFO to taki format nam załatwia sprawę). Następnie na dokumencie sprzedaży/wydania/cokolwiek nie wydajemy tylko towaru, ilości i ceny ale towar, partia, ilość i cena. To nam załatwia w 100% kwestię ile towaru po jakiej cenie zakupu mamy na stanie, ile i z jakiej partii zakupowej sprzedaliśmy, czy na danej dostawie zarobiliśmy i ile.

Jest jeszcze jeden aspekt przemawiający za partiowaniem towaru - jeśli mamy różnych dostawców i chcemy wiedzieć jak sprzedaje się towar od poszczególnych dostawców. Wtedy osobna partia to nie tylko inna cena ale także inny dostawca.

0

No widzicie, a planowałem całkowicie olać pochodzenie towaru przy jego sprzedaży ;)
Czyli tak to powinno wyglądać?
towary (ean, bieżąca_cena_sprzedaży)
magazyn(ean, partia, cena_zakupu, liczba_sztuk)
sprzedane_towary(id_transakcji, ean, partia, cena_sprzedaży, liczba_sztuk)
transakcje(id_transakcji, id_klienta, data, id_zamówienia, nr_faktury)

1

Generalnie tak :).
Jeszcze kilka uwag ogólnych:

  1. jednostkę powinieneś mieć w towarze
  2. na magazynie powinna być ilość a nie liczba_sztuk bo towar nie zawsze jest w sztukach, może być w kg, m, l, ... (pomijam całkowicie kwestię występowania tego samego towaru w różnych jednostkach)
  3. transakcje zazwyczaj nazywa się dokumenty a sprzedane_towary nazywa się dokument_pozycje (lub podobnie)
  4. towar powinien mieć id, generalnie im wcześniej nauczysz się dodawać id typu autoinc do tabel tym szybciej ci to na dobre wyjdzie :). Są tabele, gdzie id jest rzeczywiście zbędne (np. dodatkowe tabele przy złączeniu m-n, czy w tym wypadku tabela magazyn, bo tam naturalnym PK będzie towar_id, partia) ale w większości przypadków jednak osobne, sztuczne pole typu numerycznego jako PK ma swoje zalety.

Dodam tylko, że w prostych systemach sprzedażowych "zwykły" operator nawet nie musi wiedzieć, że coś takiego jak partia istnieje - przyjmowanie towaru automatycznie nadaje partie a rozchód następuje wg FIFO/LIFO. Partią tak naprawdę zajmują się tylko ludzie od analizy.

0

Ok, to jeszcze kilka pytań ;)
Jaką jednostkę? Chodzi o określenie, czy towar jest sztukach, litrach, kilogramach?

Powinien mieć id nawet, jeżeli ean zapewnia mi unikatowość (z tego co się orientuję)?

Czy dorzucenie do sprzedane_towary kolumny cena_zakupu to dobry pomysł? Nie będzie trzeba robić dodatkowego selecta, ale to powielanie informacji.

0

tak, chodzi o jednostkę miary. EAN zapewnia unikalność ale co w przypadku, kiedy towar z firmy x chcesz nazwać np. Super duper towar a od firmy y Super hiper świetny towar? Sytuacja z życia - jest hurtownia lodów, która ma dwóch dostawców tego samego towaru. W zależności od tego jakie sobie wynegocjują warunki (a warunki obowiązują kwartał) taką mają cenę zakupu niezależnie od warunków pogodowych (jak wiadomo sprzedaż lodów jest mocno zależna od pogody) oraz ich własnej sprzedaży. Żeby się nie pogubić w dostawach i łatwo analizować jednego i drugiego dostawce towary są dwa - ta sama nazwa, ean, ale inny kod wewnętrzny towaru.

Co do dodatkowego pola to jest to złamanie zasad normalizacji (konkretnie jest to nadmiarowa informacja) ale w rzeczywistych systemach często takie pola się dodaje aby zaoszczędzić czas kosztem większej ilości danych. Jednak miejsce jest znacznie tańsze w stosunku do mocy przetwarzania czy czasu oczekiwania na wynik

0

Jeżeli to nie jest projekt dla zabawy, to warto zapoznać się jakie dokumenty na tym magazynie się generuje (PZ,WZ,MM,PR itd...) w kontekście JPK_MAG.

Dodatkowo sprzedaż do klienta ma się nijak do wyceny magazynu, rozchód z magazynu nie jest tym samym co sprzedaż towaru, dla przykładu masz towarX i kupiłeś go od jednego dostawcy za 100 PLN w ilości 1 i za 90 PLN w ilości 2, wszystkie sprzedałeś za 150 PLN, na WZ "wartość" będzie równa 280 PLN, a na sprzedaży 450 PLN...

0

JPK to grubsza sprawa, ale generowanie zwykłych dokumentów do dobry pomysł. Programu pewnie nikt używał nie będzie :P

Dodatkowo sprzedaż do klienta ma się nijak do wyceny magazynu, rozchód z magazynu nie jest tym samym co sprzedaż towaru, dla przykładu masz towarX i kupiłeś go od jednego dostawcy za 100 PLN w ilości 1 i za 90 PLN w ilości 2, wszystkie sprzedałeś za 150 PLN, na WZ "wartość" będzie równa 280 PLN, a na sprzedaży 450 PLN...

A co w tym nie tak? Wszystko się zgadza.
https://poradnikprzedsiebiorcy.pl/-wz-wydanie-na-zewnatrz-wzor-z-omowieniem
Ta cena która jest w tym artykule nie odnosi się do ceny sprzedaży towaru klientowi?

Ogólnie od spraw podatkowo dokumentowo biurokratycznych mnie odrzuca na kilometr :D

Wysokość podatku trzymać w bazie, w pliku? Problem, że wysokość podatku może się zmienić. Myślałem, żeby go zapisywać w tabeli sprzedane_towary lub zamiast niego kwotę po obliczeniu podatku.
sprzedane_towary(id_transakcji, ean, partia, cena_sprzedaży_brutto, cena_sprzedaży_netto, liczba_sztuk)
lub
sprzedane_towary(id_transakcji, ean, partia, cena_sprzedaży_brutto, wysokość_podatku, liczba_sztuk)

Ogólnie wcześniej zapomniałem o uwzględnieniu marży
magazyn(ean, partia, cena_zakupu, liczba_sztuk, marża, typ_marży)//typ: procentowa/kwotowa

0

jeśli sięgamy aż tak głęboko :) to do VATów powinna być osobna tabela - na dokumencie mogą występować towary z różnymi stawkami i nie da się ich zapisać w jednym rekordzie (znaczy można zapisywać w prawo ale co w przypadku, kiedy dojdzie nowa stawka co wcale nie jest takie rzadkie). Oczywiście są to znowu nadmiarowe dane bo przecież można to wyliczyć z pozycji za każdym razem.

BTW co rozumiesz pod że wysokość podatku może się zmienić? Jeśli rozpatrujemy dokument to nawet jak się pomylisz, a kopia poszła do klienta to nie wolno ci zmieniać np. stawki podatku tylko trzeba korektę wystawić. Natomiast może się zdarzyć tak, że jakiś towar dotychczas miał 5% a teraz ma 23% VATu i to jest coś normalnego (normalnego w sensie, że tak się może zdarzyć). Dlatego też stawka podatku powinna być w pozycji dokumentu obok ceny sprzedaży.

0

Ciężko doradzić, skoro programu nikt nie będzie używał, a od spraw księgowych chcesz być daleko.

Ale od początku: Jeżeli wydajesz coś z magazynu (WZ) to tam nie ma podatku, WZ nie jest dokumentem księgowym (poza wyjątkami), na podstawie WZ generujesz fakturę w której dopiero obliczasz VAT.
I teraz najlepsze VAT można policzyć na 3 sposoby (http://ksiegowosc.infor.pl/podatki/vat/faktura/697566,Metody-obliczania-kwoty-VAT-podawanej-na-fakturze.html)...

0

Ja bym dorzucił unikalne '''ID''' dla dostaw na magazynie i te '''ID''' przenosił dalej do sprzedaży. Byłoby powiązanie bez przenoszenia jakichkolwiek informacji.
Kolejne co bym dodał to '''ilosc_przyjeta''' i '''ilosc_wydana''' na magazynie. Przy sprzedaży bym uaktualniał pole ilości wydanej, żeby dwa razy tego samego nie sprzedawać, plus to co niżej jeszcze.
Do tego można dodać statusy dostaw na magazynie, żeby było łatwiej odfiltrować to, które jeszcze nie zostały rozchodowane. Pomocne przy wyliczaniu ilości/wartości magazynu.

Do sprzedaży przenosimy tylko '''ID'' z magazynu i ilość przy okazji uaktualniając ilość wydaną w magazynie dla dostawy. Jeśli jedna dostawa to za mało to wstawiana jest kolejna pozycja tak aby wydać tyle ile chcemy po różnych cenach zakupu, gdzie cena sprzedaży jest taka sama dla różnych przyjęć tego samego towaru.

Ogólnie to temat bardzo rozległy. Taki zalążek systemu ERP :)

0

Mówiąc o zmianie wysokości podatku miałem na myśli zmiany ustawowe.

Na razie zostanę przy tym co mam. Zgłębiając się w temat jest coraz więcej komplikacji papierkowych i niedługo wyjdzie na to, że muszę stworzyć klona Subiekta :P a chcę się skupić na innych bajerach do tej aplikacji. Bardziej chcę pójść w samą obsługę magazynu, niż szczegóły handlowe, dorzucić jakiś wewnętrzny komunikator i inne :)

Najostatniejsze pytania.

  1. Klientami mogą być firmy lub osoby fizyczne (w tym anonimowe).
    W takim przypadku trzymać wszystkich w jednej tabeli
    klienci(id, nazwa, telefon, email, adres, nip, typ_klienta)
    i wtedy
    w przypadku firmy w polu nazwa będzie jej nazwa, pole NIP będzie wypełnione.
    w przypadku osoby fizycznej w polu nazwa będzie jej imię i nazwisko (lub puste). NIP pusty.
    ?
    Czy stworzyć taką tabelę klienci
    klienci(id, typ) - gdzie typ będzie odsyłał do tabeli firmy/osoby_fizyczne?

  2. Jest jeszcze kwestia osób fizycznych. Co jest kluczem w sklepach internetowych, jeżeli nie wymagają peselu? Patrzę sobie teraz na jednym sklepie konto i obowiązkowe jest tylko imię, nazwisko i email. Jeżeli przyjmę tylko email za klucz, czy jest tu jakaś pułapka?

0

1). Dorzuć ewentualnie pole pesel dla indywidualnych. Dla anonimowych możesz mieć klienta własnego jako np. Anonim, a adresy dla niego trzymać w oddzielnej tabeli z adresami
2). Przerabiałem ze sklepem internetowym i importem do systemu. Jeśli nie zakłada konta i dane wprowadza zawsze z ręki to może zrobić literówkę i będzie potraktowane jako nowy klient.

0
  1. Czyli wszystko co jest klientem w jednej tabeli?
  2. Ok, mimo to u siebie też zrobię klucz-email. Nazwisko może się zmienić więc może być problem.
1

Robisz tabelę w której masz id adresu dostawy, id klienta i adres dostawy, email. Dla firm zapisujesz w nowej tabeli i na poziomie sprzedaży wskazujesz gdzie ma być dostarczone. Jeśli adres dostawy jest taki sam jak firmy to można to pominąć.

Jeśli chodzi o indywidualnych to możesz mieć jednego klienta wprowadzonego jako ANONIM, INDYWIDUALNY i rejestrować tylko adresy dostaw w nowej tabeli i na tym się opierać do paragonu.Jeśli nie ma faktury to nie ma problemu. Jeśli klient zażyczy sobie fakturę to i tak musisz założyć klienta i jak chcesz to pesel możesz pominąć. Załóżmy, że klienta podaje do faktury adres Warszawa, ale chce dostarczyć towar do Krakowa. W tym wypadku masz w tabeli klientów wpis o kliencie Warszawa, a w tabeli adresów dostaw zapisujesz Kraków.

Na firmach to weź taką Castoramę. Faktura jest na centralę, ale dostawa na drugi koniec kraju. To jako przykład tylko

0

Poza pierwszym akapitem rozumiem.

id adresu dostawy, id klienta i adres dostawy, email


Jeżeli chodzi o adres dostawy to nie ma problemu, mogę go dorzucić do tabeli zamówienia. Ogólnie jak teraz czytam wątek, to nie wiem dlaczego zeszliśmy na ten temat :P
Problem mam w tym: chcę jednoznacznie zidentyfikować osobę fizyczną nieanonimową bez znajomości PESEL, czy mogę to bezpiecznie robić za pomocą emaila.

I nowy problem.
Chcę rozdzielić składowanie towarów na wiele magazynów (budynków). Aktualnie tabela magazynowanych towarów tak wygląda:
magazyn(ean, partia, cena_zakupu, liczba_sztuk).//podkreślone klucze
Zamierzam dorzucić nr_magazynu (do klucza). Będzie ok?

0

Ok, wysmażyłem taki schemat. Wcześniej nie robiłem takich rozbudowanych. Ma to sens (klucze i relacje)?
titleasd

1

Na początek to tak:
Tabela Kontrahenci (Dostawcy + Klienci)
Tabela Towary + tabela Towary_kontrahenci żeby zapisywać nazwy, ean itp towaru dla różnych dostawców i odbiorców
Dodałbym dodatkowo tabelę kartotek towarowych przypisanych do magazynów tj. Magazyn_kartoteki - nr_magazynu, id_towaru. Żeby określić ma którym magazynie konkretne id_towaru mogą być. To opcjonalnie tylko.
Tabela zamówienia: Zamówienia pobiera tylko kontrahenta z tabli Kontrahenci. Jest powiązana z Zamówione_towary. Zamówione_towary pobierają dane z tabeli Towary. Ilość i cenę z ręki.
Tabele Transakcje nazwałbym Dokumenty_spd. Pobiera dane z Kontrahenci. Nie wiem czy na nagłówku jest sens pobierania zamówienia. Jeśli to zawsze będzie jedno zamówieni, jeden dokument sprzedaży to może być. Ja bym przerzucił zamówienie do pozycji tj. Sprzedane_towary
Sprzedane_towary łączyłbym z Transakcje (Dokumenty_spd) i tutaj bym pobierał któej pozycji zamówienia to dotyczy ze względu na to, że jeden klient może mieć kilka zamówień.

W załączniku coś co na szybko zrobiłem

1

@endrius i tak nazewnictwo tabel jest z czapy :] Naprawdę uważasz, że SprzedaneTowary to dobra nazwa tabeli? Według tego nazewnictwa nie wiem gdzie miałbym umieścić zakupy, bo chyba nie w tej właśnie tabeli.... Należałoby zrobić tabele Dokumenty zawierające faktury zakupu, sprzedaży oraz DokumentyPozycje Analogicznie Zamowienia oraz ZamowieniaPozycje Ewentualnie DokumentyTowary oraz ZamowieniaTowary coby trzymać się konwencji.

Co ciekawe można na tabeli pozycji dokumentów warto trzymać sobie znacznik typu transakcji np:
1 - przychód
2 - rozchód
albo jeszcze lepiej po prostu znak w polu int:
1 - przychod
-1 - rozchód
Dzięki czemu bardzo prosto policzymy sobie stany na magazynie coś w ten deseń:

select towar_id, sum(znak*ilosc) as stan from DokumentyPozycje group by towar_id
0

Podszedłem do tego jeszcze raz i jest schemat jest prostszy niż poprzedni.
Tak jak poradził @Mr.YaHooo jedna tabela ze znacznikiem transakcji. +założenie jest takie, że użytkownik wystawia PZ i WZ.
Co sądzicie? Wydaje mi się, że niezbyt dobrze jest to zrobione.

0

@Potat0x jak dla mnie na początek starczy :)

0

Ostateczna wersja w załączniku, tym razem chyba jest ok. (jeszcze będę dorabiał komunikację między pracownikami, ale to już prosta sprawa).

I pytanie z innej beczki. Wnioskuję z tego co pisaliście, że w pracy macie np tabele "dokumenty" - czyli polskie nazwy. A kod jest po angielsku? Jeżeli tak, to czy są tam rzeczy typu getMiejscowosc, setJednostka? Wygląda to niefajnie. Widzę 2 sposoby na uniknięcie tego: pisać kod po polsku/przetłumaczyć nazwy w bazie na angielski. Najchętniej zostawiłbym bazę po polsku (specyficzne nazwy), a kod pisał normalnie po angielsku. Tylko to setPodatek, ble :/

0

Generalnie jest ok. Dopatrzyłem się tylko jednej rzeczy. Stawki VAT. Niech klucz główny będzie też sztucznym ID. Wtedy na pozycji dokumentów, kartotece towarowej, czy gdzieś indziej będziesz używać ID stawki VAT. Jestem zwolennikiem podejścia gdzie każdy PK powinien być sztuczny i kolumna typu int.

Co do nazewnictwa w bazie. To ja akurat mam w bazie nazwy PL. Tylko, że ja pracuję z kodem legacy, tak więc kod tez jest PL. Osobiście jakbym miał zaczynać nowy projekt wybrałbym całość w języku EN. Chyba, żeby to była wąska domena gdzie trudno się tłumaczy nazwy. Wtedy bym zostawił nazwy domenowe PL, reszta kodu EN.

0

Rola tabeli "Stawki VAT" miała być tylko taka, że będzie ładowana do comboboxa - ma tylko podawać użytkownikowi stawki do wyboru, a te będą zapisane jako wartość przy towarze.
To przetłumaczę wszystko. Przy okazji zmienię z VATem tak jak mówisz :)

1

Bardzo dobre rozwiązanie ze słownikiem. Ale sama stawka nic Ci nie da. W Polsce mamy 3 stawki zerowe:

  • 0%
  • ZW
  • NP

I w realnym świecie interesuje księgową ile było sprzedaży/zakupów NP, a ile ZW. Zatem musiałbyś trzymać oprócz stawki w procentach jej symbol. Łatwiej trzymać po prostu ID stawki ze słownika.

0

Do rejestru przedmiotów dodałem id stawki.
Do rejestru przedmiotów na dokumentach (pozycje) dodałem id stawki oraz jej wysokość na wypadek, gdyby się zmieniła w przyszłości.
Poprawiłem też relację towary/dokumenty_pozycje

0

Cześć wszystkim!

Chciałbym się podpiąć pod temat, bo mam dość podobny system ale nieco specyficzny i coś czuję, że się zamotałem.
Czuję, że gdzieś popełniam błąd. System działa ale...
Już mówię o co chodzi.
Część systemu który piszę, to magazyn blach.
Blachy przyjmowane są dokumentem pz (tylko i wyłącznie) którego nagłówek jest standardowy za to pozycje wyglądają następująco:

id_dok
nazwa_materialu //ze słownika
grubosc_arkusza //ze słownika
szerokosc_arkusza
dlugosc_arkusza
ilosc_arkuszy
cena_za_kg
nr_regalu //ze słownika
nr_polki //ze słownika

(myślę, że nazwy pól są na tyle opisowe, że nie wymagają komentarza)

te pozycje modyfikują bazę magazyn która ma strukturę

id
nazwa_materialu
grubosc_arkusza
szerokosc_arkusza
dlugosc_arkusza
nr_dostawy //zawarte w nagłówku pz-ta
cena_za_kg
nr_regalu
nr_polki
ilosc_arkuszy

Blachy wydawane są na podstawie rw (bardzo rzadko wz, ale jako że idea taka sama skupie się na rw)

Klient wystawiając dokument rozchodowy widzi stany magazynowe według powyższej specyfikacji, wybiera sobie blachę np alu, grubość np 7,5 mm, rozmiary arkusza np 1800x1200 mm - i to nie budzi wątpliwości. Następnie musi wybrać nr_dostawy (cena_za_kg jest z tym powiązana, to trochę pole nadmiarowe ale upraszcza zapytania), nr_regalu, nr_polki i jest wiersz rw-tki :)

Klient wolałby coby podał te dane oczywiste, a następnie ilość potrzebnych arkuszy (nie przekraczającą stanu mag arkuszy o danych parametrach, materiał, grubość, szerokość, długość) a system sam zaciągałby najstarsze numery dostawy i podawał mu z którego regału i półki ma zdjąć.
Nie widzę innej możliwości zrobienia tego niż chyba niezbyt eleganckie przejechanie pętlami bazy magazynowej i pozciąganie tego według jakiegoś narzucanego kryterium. Na przykład najstarsze dostawy, najdalsze regały, najwyższe półki.

Dobrze myślę? Czy można to jakoś uprościć.

Torin - zupełnie bez długiego weekendu :) :/

1

@Torin: Potrzebujesz funkcji, która by robiła rozchód według zadanych parametrów i powielała pozycje na dokumencie RW dla wybranych parametrów. Na pewno też przydałby się komunikat o tym, że jest mniejsza ilość niż ta którą chce rozchodować.
Np:
Chcemy rozchodować 15 kg o grubości 7,5 mm blachy. Mamy w tym momencie na magazynie 34 kg w 5 dostawach: 5,5,3,14,7. W kolejności od najstarszych. Czyli rozchodowując będziemy mieli pozycje z ilościami
5 - cała dostawa
5 - cała dostawa
3 - cała dostawa
2 - część z dostawy 14 kg.
Pracownik powinien wybrać tylko towar, grubość, rozmiary arkusza oraz ilość którą chce rozchodować (i co tam jeszcze przyjdzie do głowy, żeby zawęzić ilość dostaw). Dalej funkcja z automatu wyszukuje najstarsze dostawy i generuje tyle pozycji na dokumencie ile jest dostaw. Komunikat o braku ilości dla parametrów można dodać w momencie potwierdzania pozycji do dokumentu

Jeśli coś nie zrozumiałe to pytaj. Czasami potrafię się zakręcić z tłumaczeniem :)

0

@endrius Właśnie powoli siedzę i rzeźbie podobna funkcję.
W momencie wystawiania rw pacjent wybiera typ blachy, grubość i rozmiary (to ich interesuje) a system zlicza ile jest łącznie arkuszy o tych parametrach i nie pozwala wybrać większej ilości.
Potem iteruje po magazynie od najstarszej dostawy i regałów i półek.
Na razie schemat jest ino nie chce działać tak jak bym chciał. (funkcja tworzy się w php)
Idę się przewietrzyć i wrócę do tematu za chwile.
Dzięki za sugestie - zawsze to spojrzenie z boku otwiera klapki na oczach :)

Torin - idący się przewietrzyć ;)

0 użytkowników online, w tym zalogowanych: 0, gości: 0