Northwind 2.0 Developer Edition: pedidos

Esta Edição do Desenvolvedor do aplicativo de exemplo Northwind Orders é mais avançada do que a da Versão Inicial. Ele se expande no esquema de banco de dados (as tabelas usadas) e agora fornece recursos avançados adicionais. A intenção aqui é apresentá-lo aos recursos do Microsoft Access, não executar nenhum negócio específico.

• A Lista de Pedidos está disponível na Faixa de Opções. Ele tem algumas opções de filtro e hiperlinks para abrir cada pedido.

• Tanto a Lista de Pedidos quanto a Faixa de Opções têm um botão Adicionar Ordem para abrir uma nova ordem em branco.

• Em um formulário new order, selecione um cliente existente na lista suspensa. Nesse ponto, o nome do funcionário e o novo status estão selecionados. A Data do Pedido também já está preenchida. A taxa de imposto é lida na tabela SystemSettings e o Status fiscal é padrão do registro do cliente.

• Novos pedidos e pedidos de compra são adicionados à lista mru (mais recentemente usada) na Faixa de Opções. Saiba mais por meio da seção Lista de MRUneste artigo. 

• Deixe a Data Enviada e a Data Paga em branco por enquanto.

• Para adicionar pedidos para novos clientes, insira o nome da empresa e a guia para fora. O formulário Detalhes da Empresa será aberto para concluir o novo registro de cliente. Em seguida, feche-o e continue com a ordem. A nova empresa agora estará na lista suspensa cliente .

• Para adicionar itens a um pedido, selecione uma Categoria de Produto e Produto para este pedido e insira Quantidade. O preço unitário é preenchido e Price é calculado por uma expressão.

• Status do pedido antecipado e mover o pedido pelo fluxo de trabalho de Nova > Faturado > Enviado > Fechado usando os botões na parte superior do formulário Order.

• O faturamento só pode acontecer se o produto for alocado para esse pedido. Se um item de linha estiver em Nenhum Estoque ou status de Ordem, ocorrerá um erro de validação. O usuário pode criar uma Ordem de Compra para esse produto e recebê-lo, e o item de pedido status será ajustado para Alocado.

• Para enviar um pedido, o Shipper e a Taxa de Envio devem ser inseridos. Se você esquecer de fazer isso, ocorrerá um erro de validação. A Taxa de Envio é adicionada ao Total de Pedidos.

• Pedidos não copiados podem ser excluídos usando o botão Excluir Ordem.

• Os itens de linha de pedido não podem ser modificados depois que a ordem passar do Novo status.

• Na versão Northwind Starter, o processo order é incrivelmente simples (por exemplo, o inventário está sempre disponível, nunca se esgota e nunca precisa ser comprado). Agora, nesta edição de Desenvolvimento, um processo mais realista aborda pelo menos alguns desses problemas. Lembre-se de que estamos mostrando recursos do Access e práticas recomendadas, não implementando um aplicativo do mundo real. 

• As evidências de que não estamos implementando um aplicativo do mundo real aqui incluem o fato de que as datas não estão sendo validadas. Portanto, é possível inserir datas ilógicas, como uma Data Enviada antes da Data do Pedido. 

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

O formulário de pedido obtém seus dados de um qryOrder de consulta simples (consulte Propriedade RecordSource ). Basear um formulário de entrada de dados em uma consulta simples de uma tabela é uma prática recomendada. Observe que não é necessário incluir a tabela OrderDetails nesta consulta. Os detalhes da ordem são tratados pelo subforma.

O formulário OrderList pode abrir várias instâncias do formulário Order. Isso é útil porque os representantes de vendas lidam com muitas interrupções e podem precisar abrir outro pedido enquanto trabalham no primeiro ou compará-lo com uma terceira ordem. A técnica está documentada aqui.

Os vários campos de ID obtêm seus valores de caixas de combinação de duas colunas: uma coluna de ID oculta e uma coluna de descrição visível. Essas caixas de combinação estão associadas a consultas simples de duas colunas: consulte a propriedade RowSource .

Os botões de fluxo de trabalho têm lógica comercial associada a eles forçando o usuário a avançar o pedido de 1 para 4. A equipe de Desenvolvimento do Northwind está ciente de que algumas empresas podem usar regras diferentes. Isso resultaria em uma implementação diferente para os eventos de clique no botão, bem como na consideração de quando uma ordem é definida e quando um pedido ainda pode ser excluído.

O sfrmOrderDetails de subforma está associado a uma consulta mais complexa. Os motivos para isso são discutidos na seção Caixas de combinação em cascata abaixo. Nós marcar para inventário no evento Form_AfterUpdate quando a linha é salva e podemos executar consultas de banco de dados mais poderosas.

ProductCategory e Product são caixas de combinação em cascata: a seleção do primeiro (ProductCategory) limita o próximo a registros de produto filho correspondentes. A técnica usada aqui é descrita em detalhes abaixo.

Ao salvar um registro, os campos necessários devem ser preenchidos. Na edição Inicial, permitimos que o comportamento padrão do Access aconteça; nesta edição de Desenvolvimento, uma técnica mais amigável ao usuário é implementada. A técnica usada aqui é descrita em detalhes abaixo.

Para cada item de linha de pedido, o inventário disponível é verificado e o status é definido de acordo. A ideia básica desse recurso é descrita aqui.
 

COMBOBOXES EM CASCATA

Implementar as listas suspensas categoria do produto e produto como caixas de combinação em cascata é complicado porque o Access não dá suporte a esse recurso fora da caixa. Quatro etapas são necessárias nesta técnica:

O formulário deve estar no modo Formulários Contínuos (não datasheet). As caixas de texto sobrepõem a parte de texto de cada caixa de combinação, deixando apenas as setas suspensas visíveis. 

A consulta de origem de registro do formulário, qryOrderLineItems, usa a tabela OrderDetails por normal, mas também se junta às tabelas Produtos e ProductCategories para pegar ProductName e ProductCategoryName. As duas caixas de texto sobrepostas estão associadas a esses campos.

A caixa de combinação RowSource for the Products analisa o cboProductCategories para retornar apenas produtos para a categoria selecionada nessa caixa de combinação. Observe a 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 faz referência a um formulário por nome.

Depois de selecionar uma categoria de produto na caixa de combinação ProductCategories desvinculada, seu evento AfterUpdate define a caixa de combinação Produtos como o primeiro valor em sua lista. Isso cria uma nova linha no RecordSource do formulário, que preenche o CategoryName para que ele possa ser exibido por sua caixa de texto sobreposta.
 

VALIDAÇÃO

O uso do código de validação implementado na edição northwind dev usa apenas três linhas de código:

• Em Form_BeforeUpdate:
     Cancelar = ValidateForm(Me)

• Em Form_AfterUpdate e Form_Current:
      ValidateForm_RemoveHighlights Me

Tornar o código muito independente é um bom padrão a seguir porque facilita a implementação em todos os lugares. Os desenvolvedores profissionais podem levar isso ainda mais longe, por exemplo, usando a subclasse de formulário. (Isso está além das metas para Northwind Dev.)

O objeto de formulário é passado para o código de validação independente para validar. Em seguida, ele verifica a coleção RecordsetClone Fields subjacente para descobrir quais controles estão vinculados aos campos necessários e verifica se eles têm um valor. Se não o fizerem, eles serão realçados.

• Northwind 2.0 Developer Edition: coisas que você deve saber

• Northwind 2.0 Developer Edition: todos os tópicos