Northwind 2.0 Developer Edition: Поръчки за покупка

Това dev издание на примерното приложение "Поръчки за покупка на Northwind" има единствен модул "Поръчки за покупка". В Starter Edition продуктите никога не са изчерпани и никога не е необходимо да се купуват. Това издание на Dev се разширява по схемата на базата данни (използвани таблици) в Northwind 2.0 Starter Edition и използва по-разширени функции. Все още е предназначена да ви запознава с основните функции на Microsoft Access, а не да управлява конкретна фирма.

• Списъкът с поръчки за покупка е наличен от лентата. Тя има хипервръзки за отваряне на всяка поръчка за покупка.

• И списъкът с поръчки за покупка, и лентата имат бутон Нова поръчка за покупка, за да отворите нова празна поръчка за покупка. Можете също да създадете поръчки за покупка от формуляра Продукти >пренареждане на бутона Продукт .

• Бутоните в горния колонтитул предхождат поръчките за покупка чрез работния поток чрез Подаване, одобрение, получаване и затваряне. Съответните полета за проследяване във формуляра са заключени, защото те трябва да се задават програмно само чрез щракване върху бутоните за действия.

• Одобряването на ПОРЪЧКА за покупка изисква привилегия за одобрение на покупката. Можете да влезете като Андрю Сенцини, който има привилегията, или да си го дадете в System Администрация > Privileges. Имайте предвид, че способността ви да направите това е една от многото причини Northwind да не е приложение за качество на производството. В реалния свят потребителите няма да могат да издигнат собствените си разрешения.

• Редовете с артикули в поръчка за покупка се проверяват по отношение на тяхното количество. Това трябва да бъде поне минималното количество за пренареждане и в идеалния случай трябва да възстанови наличностите до най-малко целевото ниво, както е зададено за всеки продукт.

• Когато е получена поръчка за покупка, се извиква специална обработка, за да се разпространяват тези продукти, за да се поръчат елементи, които са в състояние "Без наличност" и да се зададат на "Заделени". Оставащото количество се изпраща до наличностите. Към таблицата StockTake се добавя запис.

Този раздел разглежда подробните данни за внедряването на формуляра за поръчка за покупка frmPurchaseOrderDetails:

1. Формулярът "Поръчка за покупка" получава своите данни от проста заявка qryPurchaseOrder (вж. свойството RecordSource ). Базирането на формуляр за въвеждане на данни върху проста заявка е най-добра практика. Обърнете внимание, че не е необходимо да включвате таблицата PurchaseOrderDetails в тази заявка. Подробностите се обработват от подформуляра. Но заявката се съединява с други таблици, за да се изберат полетата StatusName, SubmittedBy и ApprovedBy само за четене.

2. Формулярът PurchaseOrderList може да отвори няколко екземпляра на формуляра за поръчка за покупка. Това е полезно, тъй като отделът за PO се занимава с много прекъсвания и може да се наложи да отвори друга поръчка за покупка, докато работи върху първата – или да я сравни с трета поръчка за покупка. Техниката е документирана тук.

3. VendorID получава стойността си от разгъващ се списък от две колони: колона със скрит ИД и видима колона Описание. Тези разгъващи се списъки са обвързани с прости заявки с две колони: вижте свойството RowSource .

4. При записване на запис трябва да бъдат попълнени поне задължителните полета. В изданието Starter позволяваме поведението по подразбиране на Access да се случва; в това издание на Dev е внедрена по-удобна техника – както е описано подробно по-долу.

5. Когато състоянието на PO отиде на Получени, се извиква специална обработка (процедура AllocateToInventory), за да разпространите новите наличности над поръчки, които чакат за тези продукти.

РАТИФИЦИРАМ

Кодът за проверка, въведен в изданието Northwind Dev, изисква само три реда код:

• В Form_BeforeUpdate: Cancel = ValidateForm(Me)

• В Form_AfterUpdate:  ValidateForm_RemoveHighlights мен

• В Form_Current: ValidateForm_RemoveHighlights мен

Това е добър модел за следване: превръщането на кода в много самостоятелен улеснява внедрявания навсякъде. Професионалните разработчици могат да отстъпят още повече, например използването на подкласирането на формуляри. (Това е извън целите на Northwind Dev.)

Самостоятелният код за проверка приема обект на формуляр за проверка.  След това проверява колекцията от формуляри на RecordsetClone, за да разбере кои контроли са обвързани с задължителните полета, и проверява дали имат стойност. Ако не го направят, те се осветяват. 

• Northwind 2.0 Developer Edition: Неща, които трябва да знаете.

• Northwind 2.0 Developer Edition: Всички теми