Northwind 2.0 Developer Edition: Beställningar

Exempelprogrammet Developer Edition av Northwind Orders är mer avancerat än i Starter Edition. Den expanderar databasschemat (de tabeller som används) och ger nu ytterligare avancerade funktioner. Avsikten med detta är att introducera dig till funktionerna i Microsoft Access, inte att driva något specifikt företag.

• Orderlistan är tillgänglig i menyfliksområdet. Det finns några filteralternativ och hyperlänkar för att öppna varje order.

• Både orderlistan och menyfliksområdet har knappen Lägg till order för att öppna en ny tom ordning.

• I ett formulär för ny order väljer du en befintlig kund i listrutan. Då markeras namnet på den anställda och den nya statusen. Orderdatumet är redan ifyllt också. Momssats läse från tabellen SystemSettings och standardvärden för skattestatus från kundposten.

• Nya order och inköpsorder läggs till i listan Över senast använda (senast använda) i menyfliksområdet. Läs mer via avsnittet MRU-lista i den här artikeln. 

• Lämna leveransdatumet och betaldatumet tomt för tillfället.

• Om du vill lägga till order för nya kunder anger du företagets namn och går med tabbtangenten. Formuläret Företagsinformation öppnas för att slutföra den nya kundposten. Stäng den sedan och fortsätt med beställningen. Det nya företaget finns nu i listrutan Kund .

• Om du vill lägga till artiklar i en order väljer du en produktkategori och produkt för den här beställningen och anger Antal. Enhetspris fylls i och Pris beräknas med ett uttryck.

• Ange orderstatus och flytta order genom arbetsflödet från Nytt > Faktureras > Skickat > Stängt med hjälp av knapparna högst upp i orderformuläret.

• Fakturering kan endast ske om produkten har allokerats för den beställningen. Om ett radobjekt är i statusen No Stock eller On Order inträffar ett verifieringsfel. Användaren kan skapa en inköpsorder för produkten och ta emot den, och orderartikelstatusen justeras till Allokerad.

• Om du vill skicka en beställning måste speditören och fraktavgiften anges. Om du glömmer att göra det uppstår ett verifieringsfel. Fraktavgiften läggs till i ordersumman.

• Oskapade order kan tas bort med hjälp av knappen Ta bort order.

• Orderradsartiklar kan inte ändras när ordern har passerat statusen Ny .

• I Northwind Starter-versionen är orderprocessen otroligt enkel (t.ex. är inventering alltid tillgänglig, tar aldrig slut och behöver aldrig köpas). I den här Dev-utgåvan tar en mer realistisk process upp åtminstone vissa sådana problem. Kom ihåg att vi visar access-funktioner och metodtips, inte implementerar ett verkligt program. 

• Bevis för att vi inte genomför en verklig tillämpning här innefattar det faktum att datumen inte valideras. Därför är det möjligt att ange ologiskt datum, till exempel ett leveransdatum som infaller före orderdatumet. 

I det här avsnittet beskrivs anmärkningsvärd implementeringsinformation för orderformuläret frmOrderDetails:

Orderformuläret hämtar data från en enkel fråge-qryOrder (se egenskapen RecordSource ). Det är bäst att basera ett datainmatningsformulär på en enkel entabellfråga. Observera att det inte är nödvändigt att ta med tabellen Orderdetaljer i den här frågan. Orderinformation hanteras av underformuläret.

Formuläret OrderList kan öppna flera instanser av orderformuläret. Detta är praktiskt eftersom säljare hanterar många avbrott och kan behöva öppna en annan order medan de arbetar med den första, eller jämföra den med en tredje order. Tekniken är dokumenterad här.

De olika ID-fälten får sina värden från kombinationsrutor med två kolumner: en dold ID-kolumn och en synlig beskrivningskolumn. Dessa kombinationsrutor är bundna till enkla frågor med två kolumner: se egenskapen RowSource .

Arbetsflödesknapparna har affärslogik som är kopplad till dem och tvingar användaren att gå vidare från 1 till 4. Northwinds utvecklingsteam är medvetna om att vissa företag kan använda olika regler. Detta skulle då resultera i olika implementeringar för knappklickshändelser, samt en ny bedömning av när en order är bestämd, och när en order fortfarande kan tas bort.

Underformuläret sfrmOrderDetails är bundet till en mer komplex fråga. Orsakerna till detta diskuteras i avsnittet Överlappande kombinationsrutor nedan. Vi söker efter lager i händelsen Form_AfterUpdate när raden sparas och vi kan köra mer kraftfulla databasfrågor.

ProductCategory and Product are Cascading comboboxes: selecting from the first (ProductCategory) narrows the next one to matching child Product records. Tekniken som används här beskrivs i detalj nedan.

När du sparar en post måste de obligatoriska fälten fyllas i. I Starter-versionen låter vi Access-standardbeteendet ske. i denna Dev-utgåva implementeras en mer användarvänlig teknik. Tekniken som används här beskrivs i detalj nedan.

För varje orderradsartikel kontrolleras det tillgängliga lagret och statusen anges därefter. Den grundläggande idén med den här funktionen beskrivs här.
 

SAMMANHÄNGANDE KOMBINATIONSRUTOR

Det är svårt att implementera listrutorna Produktkategori och Produkt som sammanhängande kombinationsrutor eftersom Access inte har stöd för den här funktionen. Fyra steg är nödvändiga i denna teknik:

Formuläret måste vara i läget Löpande formulär (inte datablad). Textrutor överlappar textdelen i varje kombinationsruta och lämnar bara listrutepilarna synliga. 

Formulärets fråga för datakälla, qryOrderLineItems, använder tabellen Orderdetaljer som vanligt, men kopplas också till tabellerna Produkter och ProductCategories för att hämta ProductName och ProductCategoryName. De två överlappande textrutorna är bundna till dessa fält.

Kombinationsrutan Radkälla för produkter ser tillbaka på cboProductCategories för att bara returnera produkter för kategorin som valts i kombinationsrutan. Observera syntaxen "[Formulär]! [cboProductCategories]" i villkorsuttrycket, som är mer flexibelt än de explicita formulären! FormName! ControlName-syntax , som refererar till ett formulär efter namn.

När du har valt en produktkategori i kombinationsrutan För obundna Produktkategorier ställer händelsen AfterUpdate in kombinationsrutan Produkter till det första värdet i listan. Då skapas en ny rad i formulärets RecordSource, som fyller i Kategorinamn så att den kan visas med den överlappande textrutan.
 

VALIDERING

Med verifieringskoden som implementerats i Northwind Dev-utgåvan används endast tre rader med kod:

• I Form_BeforeUpdate:
     Cancel = ValidateForm(Me)

• I Form_AfterUpdate och Form_Current:
      ValidateForm_RemoveHighlights mig

Att göra kod väldigt fristående är ett bra mönster att följa eftersom det gör det enkelt att implementera överallt. Professionella utvecklare kan ta detta ännu längre, till exempel genom att använda formulärunderklassning. (Detta är utöver målen för Northwind Dev.)

Formulärobjektet skickas till den fristående verifieringskoden för validering. Därefter kontrolleras den underliggande samlingen RecordsetClone-fält för att ta reda på vilka kontroller som är bundna till obligatoriska fält och kontrollerar om de har ett värde. Om de inte gör det markeras de.

• Northwind 2.0 Developer Edition: Saker du bör känna till

• Northwind 2.0 Developer Edition: Alla ämnen