[Normaliseren] Implementeren van deelleveringen

Pagina: 1
Acties:

Onderwerpen


Acties:
  • 0 Henk 'm!

  • Speculaasje
  • Registratie: Oktober 2010
  • Laatst online: 09:34
Beste,

Ik ben voor mijn stage bezig met het opzetten van een databaseontwerp voor het verwerken van particuliere bestellingen, tot nu toe werkt de functionaliteit prima alleen een van de eisen is de mogelijkheid deelleveringen toe te passen binnen het systeem. Voor het opzetten van de database (inclusief het schrijven van business logica) moet er gebruik worden gemaakt van het programma FileMaker Pro Advanced 11, dit is kwa functionaliteit te vergelijken met MS Acces (wel de mogelijkheid tot het "schrijven" van scripts d.m.v. drag & drop van verschillende statements).

Op dit moment heb ik het volgende databaseontwerp staan:

Afbeeldingslocatie: http://i52.tinypic.com/dvrr5e.png

Klik voor groot plaatje!

De artikel- en voorraadinformatie wordt op basis van een ODBC connectie uit verschillende databases opgehaald en aan elkaar gekoppeld zodat er een voorraadindicatie kan worden gegeven per orderregel (te herkennen aan de dbo.Artikel.Voorraad etc.).

Nu is mijn vraag aan jullie, hoe kan in het huidige database ontwerp het verwerken van deelleveringen implementeren?

Zelf zat ik er aan te denken om de Order tabel naar zichzelf te laten verwijzen door middel van een reference Order_ID om zo de order, wanneer producten op een order niet op voorraad zijn, in 2en te splitsen zodat er een scheiding wordt gemaakt tussen de producten die wel, en niet op voorraad zijn (het op voorraad zijn van een order is een vereiste om verder te gaan binnen het proces, namelijk het aanmaken van een pakbon).

Alleen heb ik hier nog niet echt succes mee gehad.
Het splitsen van de bestellingen ging in principe prima, alleen lukte het me niet om dan o.a. klantgegevens die op de orginele order staan op de nieuwe (back)order te plaatsen, maar dit kan eventueel aan het ontwerp van mijn presentatielaag liggen.

Graag zou ik willen horen wat jullie ideeen/ervaringen zijn m.b.t. dit onderwerp. :)

Alvast bedankt!

Acties:
  • 0 Henk 'm!

  • zwippie
  • Registratie: Mei 2003
  • Niet online

zwippie

Electrons at work

Het klinkt alsof een Order uit een of meerdere Leveringen bestaat. Ik zou dus eerder een nieuwe entiteit Levering opvoeren dan dat je orders naar orders laat wijzen.

How much can you compute with the "ultimate laptop" with 1 kg of mass and 1 liter of volume? Answer: not more than 10^51 operations per second on not more than 10^32 bits.


Acties:
  • 0 Henk 'm!

  • djluc
  • Registratie: Oktober 2002
  • Laatst online: 27-05 20:17
Dat klinkt inderdaad logisch. Daarna zou ik even naar je facturen logica kijken. In lijkt direct verbonden aan een order. Moet een factuur altijd aan een order zitten, kunnen er meerdere facturen zijn van 1 order, kan 1 factuur meerdere orders bevatten etc. In principe is een factuur een los ding in veel gevallen.

Acties:
  • 0 Henk 'm!

  • xzaz
  • Registratie: Augustus 2005
  • Laatst online: 11:37
Kijken naar iemands classendiagram is altijd lastig omdat je kan (en eigenlijk moet) redeneren vanuit de use case (beschrijvingen) en dus eigenlijk je classendiagram altijd afhankelijk is van de requirements.

Je geeft aan dat 1 van de (nieuwe) eisen is dat er deelleveringen moeten worden geimplementeerd. Ik wil maar zeggen dat het afhankelijk is van de andere eisen dat het de klassendiagram flink kan beinvloeden. Ik zie wel al dat je het netjes in packages hebt neergezet.

Dan zou ik doen:

Order (KlantID, OrderID, aanbetaling, BedragTeVoldoen)
- KlantID is een vreemde sluitel mag niet NULL zijn naar KlantID in Klant
- OrderID is de primaire sleutel

OderType (OrderID, omschrijving, OrderID, OrderTypeID)
OderType (OrderTypeID, omschrijving)
- OrderTypeID is een de primaire sleutel
- OrderID is een vreemde sluitel mag niet NULL zijn naar OrderID in Order
(Dit is eigenlijk alleen leuk als een Order meerdere omschrijvingen kan hebben, blijkbaar is dat een requirement?

Factuur (FactuurID, LeveringID, CreationDate, FactuurID, FactuurregelID)

Levering ( LeveringID, KlantID, OrderID, bedrag)
- OrderID is een vreemde sleutel naar OrderID in OrderRegel
(waarom ex btw bijhouden?)

LeveringOrderRegel ( LeveringID, OrderRegelID)
- LeveringID is een vreemde sleutel naar LeveringID in Levering
- OrderRegelID is een vreemde slutel naar OrderRegelID in OrderRegel

En dan nog een koppeltabel voor Order en Levering en factuur gaat eigenlijk naar levering...

Kan nog iets niet aan kloppen maar heb ff geen progje tot me beschikking.

[ Voor 10% gewijzigd door xzaz op 22-03-2011 23:11 ]

Schiet tussen de palen en je scoort!


Acties:
  • 0 Henk 'm!

  • Speculaasje
  • Registratie: Oktober 2010
  • Laatst online: 09:34
Goeiemorgen, bedankt voor het advies!
OderType (OrderTypeID, omschrijving)
- OrderTypeID is een de primaire sleutel
- OrderID is een vreemde sluitel mag niet NULL zijn naar OrderID in Order
(Dit is eigenlijk alleen leuk als een Order meerdere omschrijvingen kan hebben, blijkbaar is dat een requirement?
Er worden via webshops van verschillende klanten bestellingen geplaatst welke worden opgeslagen in het CMS, het is de bedoeling dat er per "soort" webshop huisstijlelementen (bijv. in de vorm van een logo) wordt geplaatst op de bestelling/factuur/pakbon etc. Vandaar het entiteit OrderType, hier wou ik ook bijvoorbeeld velden als verzend- of rembourskosten in kwijt aangezien dit kan verschillen per webshop. De huisstijlelementen zou ik eventueel af kunnen vangen door middel van een KlantType entiteit, misschien dat dat wat netter is dan het te willen definieren op OrderType niveau.
Levering ( LeveringID, KlantID, OrderID, bedrag)
- OrderID is een vreemde sleutel naar OrderID in OrderRegel
(waarom ex btw bijhouden?)
Binnen FileMaker kan je Calculation velden definieren die wanneer een record wordt geladen de opgegeven berekening uitvoert, (de prijsgegevens die ik ophaal uit een externe bron zijn incl. BTW en de accountant wou graag ook ex. BTW regels op bestellingen/facturen terug zien) deze berekeningen worden dus realtime gedaan, het is naar mijn weten niet mogelijk om op de presentatie laag deze vorm van calculaties uit te voeren vandaar dat ik dit op databaseniveau doe.

Op basis van de externe voorraadgegevens wordt er per orderregel de voorraad berekend en getoond.

Van de producten die op voorraad zijn moet er een pakbon worden aangemaakt (wanneer er een factuur is aangemaakt en deze is betaald, het genereren van dit overzicht gaat allemaal prima).

Volgens mij wordt dit ook afgevangen door de n..m relatie tussen Levering en Orderregels.

Ik ga een poging wagen met een vernieuwd ontwerp en ik zal later vandaag laten weten hoe het is gegaan!

Soms blijf je iets te lang hangen in een bepaald onderwerp en dan laat me boeren verstand me wel eens in de steek :)

Acties:
  • 0 Henk 'm!

  • Boss
  • Registratie: September 1999
  • Laatst online: 16:40

Boss

+1 Overgewaardeerd

Vergeet ook niet de artikelprijs en omschrijving over te nemen naar je orderregel. Anders veranderen al je oude orders bij het wijzigen van een artikel.

The process of preparing programs for a digital computer is especially attractive, not only because it can be economically and scientifically rewarding, but also because it is an aesthetic experience much like composing poetry or music.


Acties:
  • 0 Henk 'm!

  • RuudvandeBeeten
  • Registratie: Oktober 2007
  • Laatst online: 16-10-2024
Mag ik vragen waarom je bijvoorbeeld Klant en Klanthistorie lost van elkaar hebt gemodelleerd?
Pagina: 1