Northwind 2.0 Developer Edition: Encomendas

Esta Edição de Programador da aplicação de exemplo Encomendas da Northwind é mais avançada do que a da Edição Starter. Expande-se no esquema da base de dados (as tabelas que são utilizadas) e agora fornece funcionalidades avançadas adicionais. A intenção aqui é apresentar-lhe as funcionalidades do Microsoft Access e não gerir qualquer negócio específico.

• A Lista de Encomendas está disponível no Friso. Tem algumas opções de filtro e hiperligações para abrir cada encomenda.

• Tanto a Lista de Encomendas como o Friso têm um botão Adicionar Encomenda para abrir uma nova ordem em branco.

• Num formulário Nova Encomenda, selecione um cliente existente na lista pendente. Nessa altura, o nome do funcionário e o novo estado estão selecionados. A Data da Encomenda também já está preenchida. A Taxa de Imposto é lida a partir da tabela SystemSettings e o Estado fiscal é predefinido a partir do registo do Cliente.

• As novas encomendas e encomendas de compra são adicionadas à lista de MRU (Utilizados Mais Recentemente) no Friso. Saiba mais através da secção Lista de MRUneste artigo. 

• Deixe a Data de Envio e a Data Paga em branco por enquanto.

• Para adicionar encomendas a novos clientes, introduza o nome da empresa e prima a Tecla de Tabulação. O formulário Detalhes da Empresa será aberto para concluir o novo registo do cliente. Em seguida, feche-a e continue com a encomenda. A nova empresa estará agora na lista pendente Cliente .

• Para adicionar itens a uma encomenda, selecione uma Categoria de Produto e Produto para esta encomenda e introduza Quantidade. O Preço Unitário é preenchido e o Preço é calculado por uma expressão.

• Avance o Estado da Encomenda e mova a encomenda através do fluxo de trabalho de Novo > Faturado > Enviado > Fechado utilizando os botões na parte superior do formulário Encomenda.

• A faturação só pode ocorrer se o produto for alocado para essa encomenda. Se um item de linha estiver no estado Sem Stock ou Em Encomenda, ocorrerá um erro de validação. O utilizador pode criar uma Nota de Encomenda para esse produto e recebê-lo e o estado do item de encomenda será ajustado para Alocado.

• Para enviar uma encomenda, o Transitário e a Taxa de Envio têm de ser introduzidos. Se se esquecer de o fazer, ocorrerá um erro de validação. A Taxa de Envio é adicionada ao Total da Encomenda.

• As encomendas não pára-brisas podem ser eliminadas com o botão Eliminar Encomenda.

• Os itens de linha de encomenda não podem ser modificados depois de a encomenda ter ultrapassado o estado Novo .

• Na versão Northwind Starter, o processo Order é incrivelmente simples (por exemplo, o inventário está sempre disponível, nunca se esgota e nunca tem de ser comprado). Agora, nesta edição Dev, um processo mais realista resolve, pelo menos, alguns desses problemas. Lembre-se de que estamos a mostrar as funcionalidades e as melhores práticas do Access e não a implementar uma aplicação do mundo real. 

• A prova de que não estamos a implementar uma aplicação do mundo real inclui o facto de as datas não estarem a ser validadas. Por conseguinte, é possível introduzir datas ilógicas, como uma Data de Envio antes da Data da Encomenda. 

Esta secção aborda detalhes de implementação notáveis do formulário Order, frmOrderDetails:

O formulário de encomenda obtém os respetivos dados a partir de uma consulta simples qryOrder (veja Propriedade OrigemDosRegistos ). Basear um formulário de entrada de dados numa consulta simples de uma tabela é uma melhor prática. Tenha em atenção que não é necessário incluir a tabela OrderDetails nesta consulta. Os Detalhes da Encomenda são processados pelo subformulário.

O formulário OrderList pode abrir várias instâncias do formulário Encomenda. Isto é útil porque os representantes de vendas lidam com muitas interrupções e podem ter de abrir outra encomenda enquanto trabalham na primeira ou compará-la com uma terceira encomenda. A técnica está documentada aqui.

Os vários campos de ID obtêm os respetivos valores a partir de caixas de combinação de duas colunas: uma coluna de ID oculta e uma coluna Descrição visível. Estas caixas de combinação estão vinculadas a consultas simples de duas colunas: veja a propriedade RowSource .

Os botões de fluxo de trabalho têm lógica de negócio associada, forçando o utilizador a avançar a encomenda de 1 para 4. A equipa de Desenvolvimento da Northwind está ciente de que algumas empresas podem utilizar regras diferentes. Isto resultaria numa implementação diferente para os eventos de clique do botão, bem como uma nova consideração de quando uma encomenda é definitiva e quando uma encomenda ainda pode ser eliminada.

O subformulário sfrmOrderDetails está vinculado a uma consulta mais complexa. As razões são abordadas na secção Cascading Comboboxes abaixo. Verificamos o inventário no evento Form_AfterUpdate quando a linha é guardada e podemos executar consultas de base de dados mais poderosas.

ProductCategory e Product são caixas de combinação em cascata: selecionar a partir da primeira (ProductCategory) restringe a seguinte aos registos de Produto subordinados correspondentes. A técnica utilizada aqui é descrita em detalhe abaixo.

Ao guardar um registo, os campos necessários têm de ser preenchidos. Na edição Starter, permitimos que o comportamento predefinido do Access acontecesse; nesta edição Dev, é implementada uma técnica mais fácil de utilizar. A técnica utilizada aqui é descrita em detalhe abaixo.

Para cada item de linha de encomenda, o inventário disponível é verificado e o estado é definido em conformidade. A ideia básica desta funcionalidade é descrita aqui.
 

CAIXAS DE COMBINAÇÃO EM CASCATA

Implementar os menus pendentes Categoria do Produto e Produto como Caixas de Combinação em Cascata é complicado, porque o Access não suporta esta funcionalidade despropositável. São necessários quatro passos nesta técnica:

O formulário tem de estar no modo Formulários Contínuos (não em Folha de Dados). As caixas de texto sobrepõem-se à parte de texto de cada caixa de combinação, deixando apenas as setas pendentes visíveis. 

A consulta de origem de registos do formulário, qryOrderLineItems, utiliza a tabela OrderDetails por habitual, mas também se associa às tabelas Products e ProductCategories para recolher ProductName e ProductCategoryName. As duas caixas de texto sobrepostas estão vinculadas a estes campos.

A caixa de combinação RowSource for the Products analisa a cboProductCategories para devolver apenas os produtos para a categoria selecionada nessa caixa de combinação. Repare na sintaxe "[Formulário]! [cboProductCategories]" na expressão de critérios, que é mais flexível do que os Formulários explícitos! FormName! Sintaxe ControlName , que referencia um formulário por nome.

Depois de selecionar uma categoria de produto na caixa de combinação ProductCategories desvinculada, o evento AfterUpdate define a caixa de combinação Produtos para o primeiro valor na lista. Esta ação cria uma nova linha na OrigemDosRegistos do formulário, que preenche o CategoryName para que possa ser apresentada pela respetiva caixa de texto sobreposta.
 

VALIDAÇÃO

A utilização do código de validação implementado na edição Northwind Dev utiliza apenas 3 linhas de código:

• Em Form_BeforeUpdate:
     Cancelar = ValidateForm(Me)

• In Form_AfterUpdate and Form_Current:
      ValidateForm_RemoveHighlights Me

Tornar o código muito autónomo é um bom padrão a seguir porque facilita a implementação em todo o lado. Os programadores profissionais podem levar isto ainda mais longe, por exemplo, através da subclasse de formulários. (Isto está para além dos objetivos da Northwind Dev.)

O objeto de formulário é transmitido para o código de validação autónomo para validar. Em seguida, verifica a coleção de Campos RecordsetClone subjacente para saber quais os controlos que estão vinculados aos campos necessários e verifica se têm um valor. Se não o fizerem, serão realçados.

• Northwind 2.0 Developer Edition: Coisas que deve saber

• Northwind 2.0 Developer Edition: Todos os tópicos