Northwind 2.0 Developer Edition: Pedidos de compra

Esta edición Dev de la aplicación de ejemplo Pedidos de compra de Northwind tiene el único módulo Dev Orders. En starter edition, los productos nunca se agotan y nunca es necesario comprarlos. Esta edición Dev se amplía en el esquema de base de datos (tablas usadas) en Northwind 2.0 Starter Edition y usa características más avanzadas. Todavía está pensado para presentarle las principales características de Microsoft Access, no para dirigir ninguna empresa específica.

• La lista de pedidos de compra está disponible en la cinta de opciones. Tiene hipervínculos para abrir cada pedido de compra.

• Tanto la lista de pedidos de compra como la cinta de opciones tienen un botón Nuevo pedido de compra para abrir un nuevo pedido en blanco. También puede crear pedidos de compra desde el formulario Productos >botón Reordenar producto .

• Los botones del encabezado avanzan por los pedidos de compra a través del flujo de trabajo a través de Enviar, Aprobar, Recibir y Cerrar. Los campos de seguimiento correspondientes del formulario están bloqueados porque solo se deben establecer mediante programación haciendo clic en los botones de acción.

• La aprobación de un pedido de compra requiere privilegios de aprobación de compra. Puede iniciar sesión como Andrew Cencini, que tiene el privilegio, o dárselo a sí mismo en Privilegios de Administración > del sistema. Tenga en cuenta que su capacidad para hacerlo es una de las muchas razones por las que Northwind no es una aplicación de calidad de producción. En el mundo real, los usuarios no podrán elevar sus propios permisos.

• Los artículos de línea de un pedido de compra se validan con respecto a su Cantidad. Debe ser al menos la Cantidad mínima de reordenación e idealmente debería recuperar el inventario al menos hasta el nivel de destino, tal y como se estableció para cada Producto.

• Cuando se recibe un pedido de compra, se invoca un procesamiento especial para distribuir esos productos a los artículos de línea de pedido que están en estado Sin existencias y establecerlos en Asignados. Cualquier cantidad restante se envía al inventario. Se agrega un registro a la tabla StockTake .

En esta sección se descuelga información destacada sobre la implementación del formulario pedido de compra, frmPurchaseOrderDetails:

1. El formulario Pedido de compra obtiene sus datos de una consulta sencilla, qryPurchaseOrder (vea la propiedad RecordSource ). Basar un formulario de entrada de datos en una consulta sencilla es un procedimiento recomendado. Tenga en cuenta que no es necesario incluir la tabla PurchaseOrderDetails en esta consulta. El subformulario controla los detalles. Pero la consulta se une con otras tablas para seleccionar los campos StatusName, SubmittedBy y ApprovedBy de solo lectura.

2. El formulario PurchaseOrderList puede abrir varias instancias del formulario Pedido de compra. Esto es útil porque el departamento de pedido de compra se ocupa de muchas interrupciones y es posible que tenga que abrir otro pedido de compra mientras trabaja en el primero, o compararlo con un tercer pedido de compra. La técnica está documentada aquí.

3. VendorID obtiene su valor de un cuadro combinado de dos columnas: una columna id. oculta y una columna descripción visible. Estos cuadros combinados están enlazados a consultas simples de dos columnas: vea la propiedad RowSource .

4. Al guardar un registro, es necesario rellenar al menos los campos obligatorios . En la edición Starter, permitimos que se produzca el comportamiento predeterminado de Access; en esta edición Dev, se implementa una técnica más fácil de usar, como se describe detalladamente a continuación.

5. Cuando el estado del pedido de compra pasa a Recibido, se invoca el procesamiento especial (procedimiento AllocateToInventory) para distribuir el nuevo inventario en los pedidos que están esperando estos productos.

VALIDACIÓN

El código de validación implementado en la edición Northwind Dev solo requiere tres líneas de código:

• En Form_BeforeUpdate: Cancel = ValidateForm(Me)

• In Form_AfterUpdate:  ValidateForm_RemoveHighlights Me

• En Form_Current: ValidateForm_RemoveHighlights Yo

Este es un buen patrón para seguir: hacer que el código sea muy autocontenido facilita la implementación en todas partes. Los desarrolladores profesionales pueden llevar esto aún más lejos, por ejemplo, usando subclases de formulario. (Esto va más allá de los objetivos de Northwind Dev.)

El código de validación autocontenido acepta un objeto de formulario para validar.  Después, comprueba la colección de formularios de RecordsetClone subyacente para averiguar qué controles están enlazados a los campos obligatorios y comprueba si tienen un valor. Si no es así, se resaltarán. 

• Northwind 2.0 Developer Edition: lo que debes saber.

• Northwind 2.0 Developer Edition: Todos los temas