UNIVERSIDAD NACIONAL DE TRUJILLO

FACULTAD DE INGENIERÍA
Escuela Académico Profesional De Ingeniería De
Sistemas

SISTEMA DE GESTIÓN DE BASE DE DATOS PARA EL SISTEMA

DE VENTAS DEL FERTIAGRO “MARIN AGRO EIRL”

CURSO:
BASE DE DATOS AVANZADA

DOCENTE:
Ing. BOY CHAVIL, LUIS ENRIQUE

INTEGRANTES:
 MUÑOZ SÁNCHEZ, PABLO LORENZO
 ORTIZ CIENFUEGOS, RONAL ENRIQUE
 PINEGRO DÍAZ, ALESSANDRO JESÚS
 PINGLO NUÑEZ, YANIRA YASMIN

CICLO:
VII

GUADALUPE – PERÚ
2019
 DEDICATORIA

Dedicado el presente trabajo a nuestros padres por sus enseñanzas y sus

buenas costumbres han creado en nosotros sabiduría haciendo que hoy tenga
el conocimiento de lo que soy; a Dios que nos dio fortaleza para terminar este
proyecto de investigación.

LOS ALUMNOS
INTRODUCCIÓN
INDICE
 CAPITULO I:

GENERALIDADES
1. CAPÍTULO I: GENERALIDADES
1.1. Generalidades de la Empresa
1.1.1. Reseña Histórica

Fig. 1: Fotografía del frontis del fertiagro MARIN AGRO EIRL

La empresa inicia sus actividades el año 2003 en el domicilio pasaje

GUILLERMO LEYVA sin número cafetal I, con la razón comercial
“Marín agro” de MARIN SANCHEZ WILMER, quien era el único
propietario y trabajador.
Luego de un arduo trabajo y con muchas ganas de progresar en la
vida en el año 2007 se traslada a la AV. industrial 203 GUADALUPE,
constituyéndose de esta manera una empresa jurídica “MARIN AGRO
EIRL”, responsable y dedicada a la venta de fertilizantes y
agroquímicos, para las necesidades del público del valle
Jequetepeque.
Dicha empresa cuenta con unas instalaciones amplias, cómodas y
confortables y a la vez con un stop surtido y muy solvente para atender
a los diversos agricultores. Lo cual contribuye con mi
desenvolvimiento positivo en mis prácticas pre profesional.
En la actualidad cuenta con cuatro trabajadores comprometidos a
desempeñarse correctamente para el buen funcionamiento,
crecimiento y mejoramiento de dicha empresa.
RAZÓN SOCIAL : “MARIN AGRO I.E.R.L”
RUC : 20481716056
DIRECCIÓN : AVENIDA NILA CERRUTI
TELÉFONO/FAX : 44949948850
1.1.2. Estructura Organizacional de MARIN AGRO EIRL

JUNTA GENERAL DE ACCIONISTAS

GERENCIA GENERAL

ÁREA DE ÁREA ADMINISTRACIÓN ÁREA DE ÁREA DE ÁREA DE

VENTAS Y FINANZAS PRODUCCION PERSONAL CONTABILIDAD

Fig. 2: Estructura Organizacional de la empresa

 GERENCIA GENERAL: WILMER MARIN SANCHEZ

 ÁREA DE VENTAS: OSCAR ARRELUCEA
 ÁREA DE ADMINISTRACIÓN/FINANZAS: WILMER MARIN
SANCHEZ
 ÁREA DE PRODUCCIÓN: JAIME MARIN SANCHEZ
 ÁREA DE PERSONAL: JOSE PEREZ PADILLA (TRANSPORTE)
 ÁREA DE CONTABILIDAD: JOSE PADILLA OLANO

1.1.3. Visión, Misión y Valores

VISIÓN
MARIN AGRO EIRL desde sus inicios se identificó con la agricultura de
nuestro valle y hoy en día se está consolidando, no solo con los productos
que comercializa si no también el servicio que presta como valor agregado
para la satisfacción de los agricultores.

MISIÓN
Servir con el abastecimiento de fertilizantes agroquímicos y todo lo
relacionado a nuestros agricultores de valle Jequetepeque.

VALORES
Honestidad, puntualidad, precio justo, productos garantizados, servicio de
Asesoría.
1.2. Generalidades del Proyecto
1.2.1. Título del proyecto
Sistema de gestión de base de datos para el sistema de ventas del
fertiagro “MARIN AGRO EIRL”
1.2.2. Objetivo general del proyecto
Mejorar la atención de los clientes de la empresa "MARIN AGRO
EIRL"
1.2.2.1. Objetivos específicos
 Reducir el tiempo de atención de un pedido.
 Reducir el tiempo de despacho en un 20%.
 Incrementar el nivel de satisfacción de un cliente.
 Facilitar el medio de pago del cliente.
1.2.3. Limitaciones
En el desarrollo de la investigación se presentaron las siguientes
limitaciones:
 Falta de instrumentos de control acceso a la información en
algunos días, lo que imposibilito conocer con exactitud la
investigación llevada.
 Disposición por parte de los empleados en brindar información o
disposición de tiempo por parte de ellos por sus ocupaciones
laborales.
 Las respuestas obtenidas en una entrevista o encuesta realizada
dependerán del grado de conocimiento que tenga cada persona y
del cargo que ocupe.
 Por políticas de la empresa, la revelación de los nombres reales,
algunas cifras y cierta información que consideran importantes de
resguardar, no serán mencionados en este proyecto.
1.2.4. Cronograma de actividades, encuadrado en el periodo 2019-I

PERIODO 2019-I

MARZO
ACTIVIDADES

JUNIO
MAYO
ABRIL

JULIO
Lluvia de Ideas.

Recopilación de información para el

desarrollo del Proyecto de Investigación.

Construcción y Planteamiento del

Problema.

Implementación y Desarrollo del Proyecto

de Investigación
Sustentación del Proyecto de Investigación
por los estudiantes de la facultad de
Ingeniería de Sistemas.

Trabajo en equipo.

Tabla 1: Cronograma de Actividades del periodo 2019-I

1.2.5. Análisis de requerimientos funcionales y no funcionales del

proyecto
REQUERIMIENTOS FUNCIONALES
1. Solicitar pedido
 Registrar cliente
- Cliente natural
- Cliente jurídico
 Generar pedido
- Buscar cliente
- Seleccionar producto
 Emitir documento de venta
- Buscar pedido
2. Despachar pedido
- Despachar pedido en domicilio
- Emitir guía de remisión
3. Efectuar pago
 Emitir documento de venta
- Emitir boleta de venta
- Emitir factura
 Registrar pago
4. Comprar suministros

REQUERIMIENTOS NO FUNCIONALES
1. Apariencia o Interfaz externa:
 Debe ser clara, legible y fácil de usar.
 Poseer los colores específicos que representan a la
Empresa “MARIN AGO EIRL”.
 Debe mostrar seguridad a los trabajadores para que estos
se sientan confiados.
2. Usabilidad:
 El sistema debe estar concebido para cualquier tipo de
persona, o sea debe lograr una aceptación general tanto
para un experto como para una persona menos diestra.
 El servicio que brinda la aplicación debe ayudar a que los
usuarios logren su objetivo específico con efectividad,
eficiencia y satisfacción.
3. Rendimiento:
 El sistema debe tener una alta velocidad de procesamiento
y respuesta ante cualquier solicitud del trabajador de la
empresa, para que este no se sienta incomodo en su
objetivo.
 Alto grado de eficiencia.
 Disponible en cualquier instante.
4. Soporte:
 El sistema será instalado y configurado por los Especialista
de la dirección de Sistema, quienes se encargarán de darle
mantenimiento.
 Fácil adaptabilidad para asumir nuevas funciones.
5. Seguridad:
La información manejada por el sistema debe estar protegida de
acceso no autorizado y divulgación.
6. Requerimientos Políticos y Culturales:
 El producto debe manejar facturas de la empresa.
 El producto no debe contener expresiones que difundan los
resultados de sus procesos a entes extraños, ya que limaría
la profesionalidad de la institución.
7. Requerimientos Legales:
El sistema cumple con las normas de la SUNAT promulgadas por
el Ministerio de Economía y Finanzas de la República del Perú.
En su trabajo de automatización de los procesos.
8. Confiabilidad:
 Tolerancia a fallo correspondiente al SQL Server.
9. Ayudas y Documentación en línea:
El sistema requiere de una ayuda y de manual de usuario, para
una mejor comprensión del mismo, elevando el trabajo y la
productividad.
10. Software:
 Sistema Windows Server 2008 o superior
 SQL Server 2012 o superior
 IBM Rational Software Architect 8.1
 ERwin Data Modeler
 Visual Basic NET
 QlikView 12
 Reporting services
11. Hardware:
Servidor Web:
 Microprocesador: Core i3, superior o compatible
 Memoria RAM: 8 GB
Servidor SQL:
 Microprocesador: Core i3, superior o compatible.
 Memoria RAM: 8 GB
 Disco Duro: 500 GB o superior
Clientes:
 Microprocesador: Core i3, superior o compatible.
 Memoria RAM: 4 GB
12. Restricciones en el diseño y la implementación:
El software como debe respetar la política de estandarización de
la Empresa, al emitir los reportes debe seguir un patrón de diseño
previamente acordado. Se exige la construcción de una
herramienta tradicional de escritorio, para ganar en riqueza, con
el uso de la tecnología .NET en cualquiera de sus lenguajes, con
servidor SQL Server 2012.
 CAPITULO II:

CARACTERISTICAS DEL
SISTEMA ACTUAL
2. CAPITULO II: CARACTERISTICAS DEL SISTEMA ACTUAL
2.1.1. Organización sincrónica del problema
(ANEXO 1)
2.1.2. Organización diacrónica del problema
(ANEXO 2)
2.1.3. Árbol de Causa-Efecto
El sistema actual de la empresa cuenta con el problema de una cierta
lentitud al momento de registrar una venta, lo cual el proyecto
elaborado pretende solucionar, expresado en necesidades
insatisfechas y/o oportunidades no aprovechadas.
Analizaremos dicho problema mostrando cual es el factor causante y
las consecuencias que trae. (ANEXO 3)

2.1.4. Descripción de la Realidad Problemática

Hoy en día, la venta de productos agrícolas se ha hecho muy popular,

debido a la gran cantidad de personas que se dedican a la agricultura,
tanto para su propio necesidad consumo, como para la venta de
diversos cultivos. Sin embargo, existe inconformidad en el cliente por
fallas que se presentan al momento de realizar sus pedidos. La falta
de capacitación en los vendedores antes de llegar al cliente genera
que las personas, no estén al tanto de las características y calidad de
la prenda que solicita o en muchos de los casos, el vendedor hace
alusiones falsas sobre el producto, con el único objetivo de vender y
sin pensar en la satisfacción del cliente cuando obtenga su producto.

De la misma manera se pudo encontrar que existen demoras en los

pedidos al ser procesados, por lo que el cliente prefiere comprar en
otras tiendas y mercados. Así mismo la falta de actualización en las
actuales tecnologías y la baja capacidad y velocidad de los
ordenadores generan un cierto retraso al momento de atender dichos
pedidos, generando cierta molestia.

Teniendo la problemática descrita se plantea la implementación de un

sistema de gestión de base de datos con la metodología RUP para las
ventas del fetiagro “MARIN AGRO EIRL”.
2.2. Plan y diseño de entrevistas:
Para recolectar la información requerida para elaborar el siguiente
sistema, elaboramos un cuestionario, con las diversas preguntas que
nos ayuden a entender el proceso del sistema de ventas de la empresa
a estudiar (ANEXO 4).

2.3. Modelo de Objetos del Negocio

2.3.1. Modelo de casos de uso del negocio (AN, CUN, CUN vs ON, y
ON), DCUN

Fig. 3: Actores del Negocio (AN)

Fig. 4: Casos de Uso del Negocio (CUN)

Fig. 5: Objetivos del Negocio (ON)

 Fig. 6: CUN vs ON

DIAGRAMA GENERAL DE CASOS DE USO DEL NEGOCIO (DCUN)

Fig. 7: DCUN

2.3.2. Modelo de Análisis (TN, RN, EN)

Fig. 8: Trabajadores del Negocio (TN)

 Fig. 9: Realizaciones del Negocio (RN)

Fig. 10: Entidades del Negocio (EN)

2.3.3. Diagramas de actividades de casos de uso del negocio

ESPECIFICACIONES DEL CUS-SOLICITAR PEDIDO
1. Actores
 Cliente
 Vendedor
2. Breve descripción
El CU inicia cuando el cliente solicita un pedido. El CU finaliza
cuando se registra todos los pedidos solicitados por el cliente.
3. Flujo de eventos
El proceso de Solicitar pedido se lleva a cabo de acuerdo al
siguiente procedimiento:
a. El cliente solicita le un pedido al vendedor.
b. El vendedor verifica si el cliente está registrado (E-1).
 c. El vendedor verifica la existencia del producto (E-2).
d. El vendedor solicita el producto en el sistema.
e. El cliente especifica los detalles del producto.
f. El vendedor agrega el producto al pedido.
g. El vendedor solicita la cantidad del producto.
h. El cliente especifica la cantidad.
i. Finalmente, el vendedor procede a agregar la cantidad
solicitada de producto en el pedido (E-3).
4. Flujo Alternativo

E-1: Se obtiene el listado de clientes:

 Si el cliente esta registrado se da paso a verificar la existencia

del producto.
 Si NO se encuentra registrado, se procede a registrar el cliente,
de acuerdo a su tipo.

E-2: Se verifica si existe el producto.

 Si cumple con los requisitos se procede al registro del pedido.

 Si NO cumple los requisitos el CU termina.

E-3: Se pregunta si requiere de otro producto.

 Si requiere uno nuevo, se procede a registrarlo.

 Si NO requiere de más productos el CU termina.
5. Información adicional
Se efectuará el Diagrama de Actividades del proceso Solicitar
pedido.
Fig. 11: Diagrama de Actividades Caso de Uso Solicitar pedido
ESPECIFICACIONES DEL CUS-DESPACHAR PEDIDO
1. Actores
 Cliente
 Vendedor
 Despachador
2. Breve descripción
El CU inicia cuando el cliente solicita un pedido. El CU finaliza
cuando se empaca y entrega el pedido solicitado por el cliente.
3. Flujo de eventos
El proceso de Despachar pedido se lleva a cabo de acuerdo al
siguiente procedimiento:
a. El cliente solicita le un pedido al vendedor.
b. El vendedor verifica la existencia del pedido (E-1).
c. El vendedor emite el documento de venta para el
despachador.
d. El vendedor actualiza el stock de productos.
e. El despachador prepara el pedido.
f. El despachador verifica el pedido.
g. El despachador empaca y entrega el pedido.
4. Flujo Alternativo

E-1: Se obtiene el listado de pedidos registrados:

 Si el pedido esta registrado se da paso a emitir documento de

venta.
 Si NO cumple los requisitos el CU termina.
5. Información adicional
Se efectuará el Diagrama de Actividades del proceso Despachar
pedido.
Fig. 12: Diagrama de Actividades Caso de Uso Despachar pedido
 ESPECIFICACIONES DEL CUS-EFECTUAR PAGO
1. Actores
 Cliente
 Vendedor
2. Breve descripción
El CU inicia cuando el cliente solicita un pedido. El CU finaliza
cuando se empaca y entrega el pedido.
3. Flujo de eventos
El proceso de Despachar pedido se lleva a cabo de acuerdo al
siguiente procedimiento:
a. El cliente solicita le un pedido al vendedor.
b. El vendedor verifica la existencia del pedido (E-1).
c. El vendedor registra el pago.
d. El vendedor emite el documento de venta (E-2).
e. El vendedor sella y entrega el comprobante.
f. El vendedor entrega pedido.
4. Flujo Alternativo

E-1: Se obtiene el listado de pedidos registrados:

 Si el pedido esta registrado se da paso a registrar pago.

 Si NO cumple los requisitos el CU termina.

E-2: Se solicita el tipo de cliente:

 Si cliente natural, se emite boleta de venta.

 Si es jurídico se emite una factura.
5. Información adicional
Se efectuará el Diagrama de Actividades del proceso Efectuar
pago.
Fig. 13: Diagrama de Actividades Caso de Uso Efectuar pago
ESPECIFICACIONES DEL CUS-COMPRAR SUMINISTROS
1. Actores
 Vendedor
 Administrador
 Gerente General
 Proveedor
2. Breve descripción
El CU inicia cuando el vendedor revisa el stock de los productos.
El CU finaliza cuando el proveedor entrega el pedido de
productos solicitado.
3. Flujo de eventos
El proceso de Despachar pedido se lleva a cabo de acuerdo al
siguiente procedimiento:
a. El vendedor revisa es stock de productos y la entrega al
Administrador.
b. El Administrador revisa las prioridades de los productos a
solicitar y consulta al Gerente General.
c. El Gerente General decide si comprar o no (E-1).
d. El Administrador negocia la compra de productos al
proveedor.
e. El proveedor confirma el stock.
f. El proveedor define el despacho.
g. Finalmente, el proveedor procede a entregar el pedido
solicitado por el Administrador.
4. Flujo Alternativo

E-1: Se realiza la compra:

 Si acepta se procede a negociar.

 Si NO cumple los requisitos el CU termina.
5. Información adicional
Se efectuará el Diagrama de Actividades del proceso Comprar
suministros.
 Fig. 14: Diagrama de Actividades Caso de Uso Comprar suministros

2.3.4. Diagrama de estado de los objetos identificados.

Fig. 15: Diagrama de Estado DOC_VENTA

Fig. 16: Diagrama de Estado D_DOC_VENTA

Fig. 17: Diagrama de Estado FACTURA

Fig. 18: Diagrama de Estado BOLETA_VENTA

Fig. 19: Diagrama de Estado PERSONAL

Fig. 20: Diagrama de Estado PUESTO

Fig. 21: Diagrama de Estado CLIENTE

Fig. 22: Diagrama de Estado NATURAL

 Fig. 23: Diagrama de Estado JURIDICO

Fig. 24: Diagrama de Estado PEDIDO

Fig. 25: Diagrama de Estado PEDIDO_DETALLE

Fig. 26: Diagrama de Estado PRODUCTO

 Fig. 27: Diagrama de Estado PROVEEDOR

Fig. 28: Diagrama de Estado PAGO

Fig. 29: Diagrama de Estado DETALLE_PAGO

 CAPITULO III

SISTEMA PROPUESTO
3. CAPITULO III: SISTEMA PROPUESTO
3.1. Modelo de Objetos del Sistema

Fig. 30: Modelo de Objetos del Sistema

3.1.1. Modelo de casos de uso del sistema (Requisitos).

Fig. 31: Paquete Seguridad

Fig. 32: Paquete Reutilizable

 Fig. 33: Paquete Solicitar pedido

Fig. 34: Paquete Despachar pedido

 Fig. 35: Paquete Efectuar pago

Fig. 36: Paquete Comprar suministros

Fig. 37: Diagrama General de Casos de Uso

3.1.2. Diagramas de secuencia de casos de uso del sistema; con
documentos de especificación de caso de uso
 CAPITULO IV

DISEÑO DEL SISTEMA

PROPUESTO
4. CAPITULO IV: DISEÑO DEL SISTEMA PROPUESTO
4.1. Descripción de Datos
4.1.1. Modelo Normalizado de la base de datos; en Erwin
4.1.2. Diseño de la base de datos en SQL Server
4.1.3. Integridad de datos
4.1.3.1. Script de toda la base de datos en T-SQL
4.1.3.2. Script de Dominio de atributos y valores por defecto
4.1.3.3. Script de disparadores para la integridad de datos (incluya en su
informe; por lo menos 03 trigger’s)
4.1.3.4. Script de Procedimientos Almacenados y vistas de la base de
datos (incluya por lo menos 03 procedimientos almacenados y
02 vistas)
4.1.3.5. Script de Funciones escalares y de tablas de múltiples
sentencias (incluya por lo menos 03 funciones)
4.1.3.6. Script de Cursores (incluya por lo menos 02 cursores)
4.1.4. Procesamiento de transacciones (incluya por lo menos 02
transacciones)
4.1.5. Procesamiento de reportes (incluya por lo menos 02 reportes de c/u;
con Reporting Service)
4.1.5.1. Reportes Operacionales, para decisiones de corto plazo
4.1.5.2. Reportes Tácticos, para decisiones de mediano plazo
4.1.5.3. Reportes Estratégicos, para decisiones de largo plazo
4.1.6. Procesamiento de reportes con KPI
4.1.6.1. Procesamiento de tableros de control con Qlik View (02 tableros)
4.2. Administración de la Base de datos
4.2.1. Instalación del Servidor de la Base de datos
4.2.2. Seguridad de datos
4.2.2.1. Descripción del plan de Seguridad de datos
4.2.2.2. Operaciones de Backup y Restore de la base de datos
4.2.3. Gestión de usuarios de la base de datos
4.2.3.1. Creación de Usuarios; asignación de permisos; roles y derechos.
4.2.4. Implementación del Plan de Mantenimiento
4.2.5. Implementación de Índices para el acceso a datos
4.3. Diseño de la Interface
4.3.1. Diseño del Menú de las Opciones del Sistema
4.3.2. Diseño de la Interfaz del Administrador
4.3.3. Diseño de la Interfaz del usuario
5. CAPITULO V: IMPLEMENTACION DEL SISTEMA PROPUESTO

5.1 Codificación del Sistema Integrado en Visual Basic NET

5.1.1 Programación de la Clase Frontera

5.1.2 Programación de la Clase de Datos y Conectividad

5.1.3 Programación de la Clase Entidad

5.1.4 Programación de la Clase Negocios

5.1.5 Codificación integral con programación por capas en VB NET

5.2 Implementación de Reportes para decisiones en QlikView y RS

5.3 Manual de Instalación del sistema

OPCIONAL:

5.4 Para el caso de Soluciones de Inteligencia de Negocios:

5.4.1 Fase I: Planificación del Proyecto

5.4.1.1 Definición del proyecto

5.4.1.2 Selección de la estrategia de implementación

5.4.1.3 Desarrollo del escenario del uso empresarial

5.4.2 Fase II: Definición de los requerimientos del proyecto

5.4.2.1 Identificación de las fuentes de información

5.4.2.2 Programación de entrevistas

5.4.2.3 Revisión de la base de datos transaccional del sistema actual

5.4.2.4 Análisis de reportes de gestión

5.4.2.5 Hojas de gestión

5.4.2.6 Hoja de análisis

5.4.2.7 Dimensiones y jerarquías

5.4.2.8 Medidas vs. Dimensiones

5.4.2.9 Datawarehouse bus architecture matrix

5.4.2.10 Priorización de procesos

5.4.2.11 Análisis dimensional final.

5.4.3 Fase III: Modelo dimensional

5.4.3.1 Declaración del grano

5.4.3.2 Definiciendo dimensiones

5.4.3.3 Definiciendo tablas de hecho

5.4.3.4 Diseño dimensional a implementar

5.4.4 Fase IV: Diseño físico

5.4.4.1 Modelo físico

5.4.4.2 Implementación con Análisis Service de Microsoft Data Tool

ANEXOS
ANEXO 1: ORGANIZACIÓN SINCRÓNICA DEL PROBLEMA

PEDIDO
PEDIDO GESTIÓN PROCESADO
GESTIÓN DE GESTIÓN
DE PRODUCTOS DE VENTA
CLIENTES

SOLICITAR PEDIDO
ANEXO 2: ORGANIZACIÓN DIACRÓNICA DEL PROBLEMA

VARIABLES ENDÓGENAS VARIABLES EXÓGENAS

 CLIENTE
 VENDEDOR
 ADMINISTRADOR
 GERENTE GENERAL
 DESPACHADOR
 PROVEEDOR  SUNAT
ANEXO 3: ÁRBOL DE CAUSA-EFECTO

LENTITUD EN EL REGISTRO
DE VENTAS

Demora en la toma de Sistemas aislados

Poco uso de tecnología
pedidos

Pérdida del cliente Poca capacitación. Cada área dentro de la

administración trabaja
con diferente software.

Fallo en la toma de pedido

Devolución de los pedidos

CAUSA

EFECTO
ANEXO 4: CUESTIONARIO DE PREGUNTAS PARA ENCUESTAS

CUESTIONARIO N.º 01
1. TÍTULO DEL PROYECTO
Sistema de gestión de base de datos para el sistema de ventas del
fertiagro “MARIN AGRO EIRL”

2. INVOCACIÓN-OBJETIVO
La presente investigación persigue el principal objetivo de
“Implementar un Sistema de gestión de bases de datos para el
sistema de ventas del fertiagro “MARIN AGRO EIRL”
Le agradeceremos leer bien el enunciado y responder.

3. INFORMANTES

3.1. Cargo
3.2. Años de experiencia
3.3. Edad: [20 – 25] ( ) <25 – 30] ( ) <30 – 35] ( )
<35 – 40] ( ) <40 – Más] ( )
3.4. Sexo: Masculino ( ) Femenino ( )

4. INTRODUCCION
Estimados Gerente del fertiagro MARIAN AGRO EIRL, el presente
cuestionario es parte de un proyecto de investigación que tiene por
finalidad la obtención de información, acerca del proceso actual que
se lleva acabo sobre las ventas en dicha empresa.

5. DETALLE DE LOS ITEMS

 ¿Cómo es el proceso por el cual se acepta y ejecuta una venta?
 ¿Se necesita presentar algún documento especial para realizar
dicha venta?
 ¿Cuántas personas trabajan en la empresa y cual es función
dentro de la misma?
 ¿El Gerente General a que se dedica?
 ¿Es solo para personas naturales o también jurídicas?
 ¿Se financian los mismos responsables?
 ¿Los trabajadores que requisitos necesitan tener?
 ¿Cuál es la modalidad de despacho de un pedido?
 ¿Qué es lo que incluye un documento de venta?