Northwind 2.0 Developer Edition: Замовлення

Цей випуск розробника зразка програми Northwind Orders більш розширений, ніж у Starter Edition. Вона розширюється на схему бази даних (таблиці, які використовуються) і надає додаткові додаткові функції. У цьому документі ви познайомите вас з функціями Microsoft Access, а не будь-яким конкретним бізнесом.

• Список замовлень доступний на стрічці. У ній є кілька параметрів фільтра та гіперпосилання, за допомогою яких можна відкривати кожне замовлення.

• У списку замовлень і на стрічці є кнопка Додати замовлення, щоб відкрити нове пусте замовлення.

• У формі "Нове замовлення" виберіть наявного клієнта з розкривного списку. На цьому етапі буде вибрано ім'я працівника та новий стан. Дата замовлення також уже заповнена. Податкова ставка читається з таблиці SystemSettings і за замовчуванням податкового стану із запису клієнта.

• Нові замовлення та замовлення на придбання додаються до списку нещодавно використаних документів на стрічці. Докладні відомості див. в розділі Список MRU в цій статті. 

• Залиште дату доставки та платну дату пустими.

• Щоб додати замовлення для нових клієнтів, введіть назву компанії та перейдіть на вкладку. Відкриється форма "Відомості про компанію", щоб завершити створення нового запису клієнта. Потім закрийте його та продовжуйте виконувати замовлення. Нова компанія тепер буде в розкривному списку "Клієнт ".

• Щоб додати елементи до замовлення, виберіть категорію товару та товар для цього замовлення та введіть Кількість. Ціна за одиницю заповнюється, а ціна обчислюється виразом.

• Зміна стану замовлення та переміщення замовлення з нового > виставленого рахунка-фактури > Доставлено > Закрито за допомогою кнопок у верхній частині форми замовлення.

• Виставлення рахунків-фактур може статися, лише якщо продукт виділено для цього замовлення. Якщо елемент рядка перебуває в стані "Немає запасу" або "У замовленні", станеться помилка перевірки. Користувач може створити замовлення на придбання для цього продукту та отримати його, а стан елемента замовлення буде змінено на Виділено.

• Щоб надіслати замовлення, потрібно ввести плату задоставку та доставку. Якщо ви забудете про це, станеться помилка перевірки. Вартість доставки додається до підсумка замовлення.

• Непоставлені замовлення можна видалити за допомогою кнопки Видалити замовлення.

• Елементи рядка замовлення не можна змінити після того, як порядок минув після нового стану.

• У версії Northwind Starter процес замовлення неймовірно простий (наприклад, інвентаризація завжди доступна, ніколи не закінчиться і ніколи не потрібно купувати). Тепер у цьому випуску Dev більш реалістичний процес вирішує хоча б деякі такі проблеми. Пам'ятайте, що ми демонструємо функції та практичні поради Access, а не впроваджуємо реальну програму. 

• Докази того, що ми не впроваджуємо реальну заявку тут, включають той факт, що дати не перевірені. Таким чином, можна ввести нелогічні дати, як-от дата відвантаження, яка передуватиме даті замовлення. 

У цьому розділі примітні деталі реалізації форми замовлення frmOrderDetails:

Форма замовлення отримує дані з простого запиту qryOrder (див. властивість RecordSource ). Радимо створити форму введення даних у простому запиті на одну таблицю. Зверніть увагу, що необов'язково включати таблицю OrderDetails до цього запиту. Відомості про замовлення обробляються підформою.

Форма OrderList може відкривати кілька екземплярів форми "Замовлення". Це зручно, оскільки торгові представники мають справу з великою кількістю перерв і, можливо, доведеться відкрити інше замовлення під час роботи над першим або порівняти його з третім замовленням. Техніка описана тут.

Різні поля ідентифікаторів отримують свої значення з двох стовпців зі списком: прихований стовпець ідентифікатора та видимий стовпець Опис. Ці поля зі списком прив'язані до простих запитів із двома стовпцями: див. властивість RowSource .

Кнопки робочого циклу мають пов'язану з ними бізнес-логіку, яка змушує користувача переходити від 1 до 4. Команда Northwind Development усвідомлює, що деякі компанії можуть використовувати різні правила. Після цього це призведе до різних упроваджень для подій натискання кнопки, а також повторного розгляду того, коли замовлення визначене, і коли замовлення все ще можна видалити.

Підформа sfrmOrderDetails прив'язана до складніших запитів. Причини цього обговорюються в розділі Каскадні поля зі списком нижче. Ми перевіряємо наявність запасів у події Form_AfterUpdate, коли рядок зберігається, і ми можемо запускати потужніші запити до бази даних.

ProductCategory та Product – це каскадні поля зі списком: вибір із першого елемента (ProductCategory) звужує наступне до відповідності дочірніх записів продукту. Методика, яка використовується тут, детально описана нижче.

Під час збереження запису необхідно заповнити обов'язкові поля. У випуску Starter ми дозволили програмі Access відбуватися за замовчуванням; у цьому випуску Dev реалізовано більш зручний метод. Методика, яка використовується тут, детально описана нижче.

Для кожного елемента рядка замовлення доступний інвентаризація перевіряється, а стан установлюється відповідним чином. Основну ідею цієї функції описано тут.
 

КАСКАДНІ ПОЛЯ ЗІ СПИСКОМ

Упровадження розкривних списків "Категорія продуктів" і "Продукт" як каскадне поле зі списком є складним, оскільки Access не підтримує цю функцію з поля. У цьому методі потрібно виконати чотири кроки:

Форма має бути в режимі неперервних форм (не у табличному поданні). Текстові поля перекривають текстову частину кожного поля зі списком, залишаючи видимими лише стрілки розкривного списку. 

У запиті джерела записів форми qryOrderLineItems використовується таблиця OrderDetails для звичайного використання, але також об'єднує таблиці "Продукти" та "Категорії продуктів", щоб отримати дані "ProductName" і "ProductCategoryName". Два текстові поля, що перекриваються, прив'язані до цих полів.

Функція RowSource для поля зі списком Products повертає cboProductCategories, щоб повернути лише продукти для категорії, вибраної в цьому полі зі списком. Зверніть увагу на синтаксис "[Форма]! [cboProductCategories]" у виразі умови, який є більш гнучким, ніж явні Forms! Ім'я форми! Синтаксис ControlName , який посилається на одну форму за іменем.

Після вибору категорії продукту в полі зі списком "Неприєднані категорії продуктів " подія AfterUpdate установлює для поля зі списком Продукти перше значення в списку. У формі RecordSource створюється новий рядок, який заповнює ім'я категорії , щоб його можна було відобразити за допомогою текстового поля, що перекривається.
 

ПЕРЕВІРКИ

Використання коду перевірки, реалізованого у випуску Northwind Dev, займає лише 3 рядки коду:

• У Form_BeforeUpdate:
     Cancel = ValidateForm(Me)

• У Form_AfterUpdate та Form_Current:
      ValidateForm_RemoveHighlights мене

Створення коду дуже самостійно міститься є хорошим шаблоном, щоб слідувати, тому що він робить його легко реалізувати скрізь. Професійні розробники можуть взяти це ще більше, наприклад, за допомогою підкласизування форм. (Це виходить за рамки цілей для Northwind Dev.)

Об'єкт форми передається до самостійного коду перевірки для перевірки. Потім він перевіряє базову колекцію RecordsetClone Fields, щоб з'ясувати, які елементи керування прив'язані до обов'язкових полів, і перевіряє, чи є у них значення. Якщо ні, вони виділяються.

• Northwind 2.0 Developer Edition: що ви повинні знати

• Northwind 2.0 Developer Edition: Усі теми