Northwind 2.0 Developer Edition: Orders

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

• Списъкът с поръчки е наличен от лентата. Той има няколко опции за филтриране и хипервръзки, за да отворите всеки ред.

• И списъкът с поръчки, и лентата имат бутон Добавяне на поръчка, за да отворите нов празен ред.

• Във формуляр Нова поръчка изберете съществуващ клиент от падащия списък. В този момент се избират името на служителя и новото състояние. Датата на поръчката вече е попълнена. Данъчната ставка се чете от таблицата SystemSettings , а състоянието на данъците по подразбиране е от записа за клиента.

• Нови поръчки и поръчки за покупка се добавят към списъка на последно използваните поръчки в лентата. Научете повече чрез секцията списък на последно използваните в тази статия. 

• Оставете засега дата на експедиране и дата на плащане празно.

• За да добавите поръчки за нови клиенти, въведете името на фирмата и табулатора. Формулярът "Подробни данни за фирмата" ще се отвори, за да завърши новия запис за клиент. След това го затворете и продължете с поръчката. Новата фирма сега ще бъде в падащия списък "Клиент" .

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

• Advance Order Status и move the order through the workflow from New > Invoiced > Shipped > Closed using the buttons at the top of the Order form.

• Фактурирането може да се случи само ако продуктът е заделен за тази поръчка. Ако даден ред е в състояние "Няма акции" или "На поръчка", ще възникне грешка при проверка. Потребителят може да създаде поръчка за покупка за този продукт и да я получи, а състоянието на елемента на поръчката ще бъде коригирано на "Разпределено".

• За да изпратите поръчка, трябва да се въведе таксата за спедиция и доставка. Ако забравите да го направите, ще възникне грешка при проверка. Таксата за доставка се добавя към общата сума на поръчката.

• Неизпълнените поръчки могат да бъдат изтрити с помощта на бутона "Изтриване на поръчка".

• Елементите от ред за поръчка не могат да бъдат модифицирани, след като поръчката е минала състоянието "Създай" .

• В версията Northwind Starter процесът на поръчка е невероятно прост (например наличностите винаги са налични, никога не изтичат и никога не е необходимо да се купуват). Сега, в това издание на Dev, по-реалистичен процес обръща внимание поне на някои такива проблеми. Не забравяйте, че показваме функциите и най-добрите практики на Access, а не внедряваме приложение в реалния свят. 

• Доказателството, че не прилагаме приложение в реалния свят тук, включва факта, че датите не се проверяват. Следователно е възможно да въведете нелогични дати, например дата на експедиране, която е преди датата на поръчката. 

В този раздел са разгледани подробните данни за внедряването на формуляра за поръчка frmOrderDetails:

Формулярът за поръчка получава данните си от qryOrder на проста заявка (вж . свойството RecordSource ). Най-добра практика е да базирате формуляр за въвеждане на данни върху проста заявка от една таблица. Обърнете внимание, че не е необходимо да включвате таблица OrderDetails в тази заявка. Подробните данни за поръчката се обработват от подформуляра.

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

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

Бутоните на работния поток имат бизнес логика, свързана с тях, налагаща на потребителя да продължи поръчката от 1 до 4. Екипът по разработка на Northwind е наясно, че някои фирми може да използват различни правила. Това ще доведе до различна реализация за събитията при щракване на бутон, както и преосмисляне кога дадена поръчка е дефинирана и кога дадена поръчка все още може да бъде изтрита.

Подформулярът sfrmOrderDetails е обвързан с по-сложна заявка. Причините за това са обсъдени в раздела Каскадни разгъващи се групи по-долу. Проверяваме за наличности в събитието на Form_AfterUpdate, когато редът се записва, и можем да изпълняваме по-мощни заявки към базата данни.

ProductCategory и Product са каскадни разгъващи се списъци: избирането от първия (ProductCategory) стеснява следващия до съответстващите дъщерни записи за продукти. Техниката, използвана тук, е описана подробно по-долу.

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

За всеки ред от поръчка се проверява наличностите и състоянието се задава по съответния начин. Основната идея на тази функция е описана тук.
 

КАСКАДНИ РАЗГЪВАЩИ СЕ СПИСЪКИ

Прилагането на продуктовите категории и падащи менюта за продукти като каскадни разгъващи се списъци е трудно, тъй като Access не поддържа тази функция от кутията. Четири стъпки са необходими в тази техника:

Формулярът трябва да бъде в режим на непрекъснати формуляри (а не в лист с данни). Текстовите полета припокриват текстовата част на всеки разгъващ се списък, оставяйки видими само стрелките на падащото меню. 

Заявката на формуляра за източник на записи qryOrderLineItems използва таблицата OrderDetails по обичайния начин, но също така се съединява с таблиците Products и ProductCategories, за да вземе ProductName и ProductCategoryName. Двете припокриващи се текстови полета са обвързани с тези полета.

RowSource за разгъващия се списък Products търси обратно cboProductCategories, за да върне само продукти за категорията, избрана в този разгъващ се списък. Обърнете внимание на синтаксиса "[Формуляр]! [cboProductCategories]" в израза за критерий, който е по-гъвкав от явните Формуляри! Име на формуляр! Синтаксисът на ControlName , който препраща към един формуляр по име.

След като изберете категория продукти в разгъващия се списък unbound ProductCategories , неговото събитие AfterUpdate задава разгъващия се списък Продукти на първата стойност в своя списък. Това създава нов ред в RecordSource на формуляра, който попълва CategoryName , така че да може да бъде показан чрез неговото припокриващо се текстово поле.
 

РАТИФИЦИРАМ

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

• В Form_BeforeUpdate:
     Отказ = ValidateForm(Me)

• В Form_AfterUpdate и Form_Current:
      ValidateForm_RemoveHighlights мен

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

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

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

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