Manual Operacion GDDS V8
DDS GM
GDDS
Operación
: (55) 5524 2915 | www.w32.com.mx
Tel: (55) 5524 2915 | www.w32.com.mx
Índice
- Funcionalidad de GDDS ................................................................................................. 3
- GDDS Vehicle Inventory ................................................................................................. 4
- GDDS Vehicle Sale ........................................................................................................ 8
- GDDS Parts Inventory ....................................................................................................20
- GDDS Parts Sales ..........................................................................................................21
- GDDS Repair Order ........................................................................................................25
- Herramienta para leer XML............................................................................................. 42
1.- FUNCIONALIDAD
¿QUE ES GDDS?
La interfaz GDDS es una actualización de la interfaz DataSharing Agreement que hoy en día está funcionando, pero ahora se incluye información de:
VI (Inventario Vehículos) ---------- Ya certificado---------Envío diario
VS (Venta Vehículos) -------------- Aun no certificado----Envío diario
RO (Ordenes de Reparación) --- Ya certificado-----------Envío diario
PI (Inventario Refacciones) ------ Ya certificado----------Envío diario PS (Venta Refacciones) ---------- Ya certificado-----------Envío diario
La información que se envía a la interfaz GDDS es extraída de la base de datos y enviada al servidor de DataPower en archivos XML, y este último se encargará de transmitir dicha información a la comunidad segura de GM Exchange.
La información enviada servirá para el análisis, modelado y estrategias de mercadotecnia e iniciativas corporativas de la marca General Motors.
¿COMO FUNCIONA?
Hoy en día el usuario dentro del DMS realiza el proceso de:
- Mantenimiento de Inventario VN, por interfaz SOFIA o manualmente
- Pedido/Facturación de VN/ Usados
- Creación/Cierre/Facturación de Ordenes
- Mantenimiento de Inventario de Refacciones, por actualizaciones de Precios o manualmente
- Facturación de Refacciones
- Mantenimiento de Citas de Servicio, por interfaz OSS o ContactCenter
En cualquiera de los procesos mencionados, el usuario opera de forma normal, es decir, debe ingresar los datos conocidos y es probable que sea necesario agregar otros campos. El armado de los archivos XML y sus envíos operan de forma transparente. Sin embargo, para garantizar que la información recibida por la interfaz GDDS sea correcta, es necesario conocer que campos de cada proceso son requeridos, lo cual se explican en los capítulos siguientes.
2.- Vehicle Inventory (VI)
¿QUE ENVIA?
El archivo XML VI contiene datos del inventario de Vehículos nuevos con modelos del año corriente y solo modelos de año anterior siempre y cuando el kilometraje de entrega sea cero. Considerar que, en el caso de un vehículo nuevo, el año modelo se hereda de la versión del vehículo, donde el año modelo del vehículo nuevo debe ser el año modelo de la versión.
- Campo Condición, este campo indica si el vehículo es Nuevo.
- Campos Marca y Modelo
- Campos Color Exterior, Color Interior, Transmisión, Tipo de combustible, N° de Cilindros, N° de Puertas, N° de Pasajeros, Motor, Año Modelo, VIN y N° de Inventario,
- Campo Paquete, se extrae de la versión del Vehículo
- Campo Clave Comercial, se extrae de la versión del Vehículo
- Campo Status, se envían 4 status:
- InTransit = En transito
- AvailableForSale = Disponible
- OnHold = Demo, aplica solo para vehículos nuevos
- Allocated = Operación
Estos estatus los podemos ver en la pestaña “Estados”, en el campo Salida.
- Campo Descripción de Accesorios, se extrae de la pestaña Accesorios y de la pestaña Extras de Fábrica,
- Campo Localización, se utiliza del campo Descripción de la localización,
- Campo Km Entrega, del vehículo, cuando un modelo de un año anterior contenga un valor mayor a cero, el inventario no será enviado a DDS.
- Campo Fecha de Adquisición, se obtiene el campo Fecha y hora del estado de Recibido
- Campo Número de factura, se envía el campo “Num. Fact Compra”
- Método de Adquisición, se utilizan 2 valores: OEM y Dealer Exchange
El valor OEM se obtiene validando si el vehículo ingresó con la interfaz Sofía, caso contrario se envía el valor ingresado en el campo Método adquisición. Cuando el vehículo ingresa como compra en concesionario entonces se utiliza el valor Dealer Exchange.
- Campo Costo Total de Compra Vehiculo, se envía el campo Total Factura Compra
- Campo Precio Retail, se utiliza el campo Precio V.N. 2
- Campo Precio List, se utiliza el campo Precio dentro del Vehiculo
3.- Vehicle Sales (VS)
¿QUE ENVIA?
El archivo XML VS contiene datos de la venta de vehículos nuevos y usados, datos del:
- Cliente, contacto del cliente
- Vehículo
- Vendedor
- Financiamiento
- Entrega del vehículo
- Garantía extendida
- Venta adicional
- Accesorios
- Toma a cuenta
- Arrendamiento
- Tipo de venta
- Otros datos
a) Cliente: se debe enviar los datos del cliente ya sea persona física o moral.
1.- Persona Física: el aplicativo toma los datos del cliente, tal y como se muestra la imagen de abajo, el cliente asociado al vehículo del taller. En caso de que no exista el cliente asociado a un vehículo del taller, entonces el aplicativo tomará los datos del cliente del Pedido.
Los datos de la persona física que se toman son los que se muestran abajo en color rojo:
Para que sea considerado una persona física, el aplicativo valida que el valor del campo Genero sea diferente a “N”.
2.- Persona Moral: el aplicativo toma los datos del cliente, tal y como se muestra la imagen de abajo, el cliente asociado al vehículo del taller en color rojo, y también se envían los datos del contacto por ejemplo en la imagen de abajo el contacto se llama “Eduardo Diaz Trujillo“, en color negro. En caso de que no exista el cliente asociado a un vehículo del taller, entonces el aplicativo tomará los datos del cliente del Pedido.
Los datos de la persona Moral que se toman son los que se muestran abajo en color rojo:
Los datos del contacto de la persona Moral que se toman son los que se muestran abajo en color rojo:
Nota: es importante que el usuario que factura las ventas de vehículos agregue el contacto de la persona MORAL, tal y como se muestra abajo:
Al terminar de facturar el pedido, el sistema abre la ventana de “Vehículos del taller” en la pestaña de Campos variables por default, y en ese momento se puede cambiar a la pestaña de Datos particulares y agregar los datos del contacto, en el recuadro que dice Conductor. En caso de que al terminar de facturar el pedido no se abra la ventana de “Vehículos del Taller”, usted puede abrirlo de forma manual, abriendo la ficha del vehículo y luego en el menú Acciones.
- Vehículo: los datos del vehículo que se toman son los que se muestran abajo en color rojo:
- Vendedor: los datos del vendedor que se toman son los que se muestran abajo en color rojo:
- Financiamiento: los datos del financiamiento que se toman son los que se muestran abajo en color rojo:
- Entrega del vehículo: se envía la fecha y hora de la entrega del vehículo, recordar que esto se hace en el proceso de entrega en la interfaz de Sofía, en la operación VN y operación VO:
También se envía el kilometraje con el que se entrega el vehículo
- Garantía extendida: los datos de la garantía extendida que se toman son los que se muestran abajo en color rojo:
- Venta adicional: los datos de la venta adicional que se toman son los que se muestran abajo en color rojo:
- Accesorios: se envía el código, descripción y el precio de los accesorios que se agregan al pedido:
- Toma a cuenta: se envían los datos marcados en rojo:
- Arrendamiento: cuando el tipo de venta es arrendamiento se valida por la sección del pedido.
- Tipos de venta: se envían el tipo de venta menudeo y flotillero para lo cual se valida la sección del pedido:
- Otros datos: en caso de que se proporcione el servicio de emplacamiento, el aplicativo busca las placas.
Además, el aplicativo busca la fecha de la orden interna previa entrega por medio del VIN
4.- Parts Inventory (PI)
¿QUE ENVIA?
El archivo XML PI contiene datos del inventario de refacciones:
1.- Código de la refacción
2.- Descripción de la refacción
3.- Cantidad en stock
4.- Cantidad reservada, las piezas reservadas
5.- Cantidad en tránsito, lo que está en pedidos sin surtir
6.- Costo de refacción
7.- Marca de la refacción
8.- Proveedor de la refacción
5.- Parts Sales (PS)
¿QUE ENVIA?
El archivo XML PS contiene datos de la venta de refacciones solo de Mostrador:
- Cliente, contacto del cliente
- Vendedor
- Factura
- Tipos de venta
- Descuentos
- Refacción
- Cliente: se debe enviar los datos del cliente ya sea persona física o moral.
1.- Persona Física: el aplicativo toma los datos del cliente, tal y como se muestra la imagen de abajo:
Para que sea considerado una persona física, el aplicativo valida que el valor del campo Genero sea diferente a “N”. Adicional se tiene una validación en el RFC del Cliente, donde la longitud de 13 es considerado como persona física y 12 como persona moral.
2.- Persona Moral: el aplicativo toma los datos del cliente al que se le facturó, tal y como se muestra la imagen de abajo en color rojo.
Nota 1: En el caso del campo Estado se envía de acuerdo con el catálogo de la norma ISO 3166 Nota 2: es importante que el correo electrónico se capture de forma correcta.
- Vendedor: se debe enviar los datos del vendedor.
- Datos de factura: se envían datos como fecha, número e importes.
- Tipos de Venta: el tipo de venta se obtiene del campo Sección. Este campo indica el CustomerType en el reporte que recibe GM.
- Descuentos: el aplicativo toma los descuentos de cada refacción facturada y a nivel global en la factura.
- Refacción: el aplicativo toma ciertos datos de cada refacción facturada.
6.- Repair Order (RO)
¿QUE ENVIA?
El archivo XML RO contiene datos de todas las ordenes de servicio:
- Cliente, contacto relacionado con el vehículo
- Datos de la Orden de servicio
- Asesor de servicio
- Tipos de ordenes
- Mano de Obra
- Refacciones
- Técnico
- Vehículo
- TOT´s
- Materiales diversos
- Garantía GWM
a) Cliente: se debe enviar los datos del cliente ya sea persona física o moral.
1.- Persona Física: el aplicativo toma los datos del cliente, tal y como se muestra la imagen de abajo, el cliente asociado a la matricula. Para que sea considerado una persona física, el aplicativo valida que el valor del campo Genero sea diferente a “N”.
Hay que recordar que el cliente que aparece en la orden de servicio es el cliente asociado en la matricula.
En la siguiente tabla se muestra los campos que se envían a DDS con los valores de ejemplo de las imágenes anteriores.
2.- Persona Moral: el aplicativo toma los datos del cliente, tal y como se muestra la imagen de abajo, el cliente asociado al vehículo del taller en color rojo, y también se envían los datos del contacto por ejemplo en la imagen de abajo el dueño del vehículo es “ENVIOS MEXICANOS SA DE CV “, y el Contacto es “MA DEL CARMEN HERRERA MAGAÑA”.
El cliente Moral dueño del vehículo, debe tener en el campo GENERO = N, los datos de la persona Moral que se toman son los que se muestran abajo en color rojo:
Los datos del contacto de la persona Moral que se toman son los que se muestran abajo en color azul, siguiendo el ejemplo de 2 imágenes anteriores:
Nota 1: es importante que el usuario que crea las ordenes de servicio agregue el contacto de la persona MORAL.
Nota 2: En el caso del campo Estado se envía de acuerdo con el catálogo de la norma ISO 166.
Nota 3: es importante que el correo electrónico se capture de forma correcta.
También si el dueño del vehículo, en la ficha del vehículo no tiene un contacto creado como Cliente, como la imagen de abajo, donde el dueño del vehículo es “LIVERPOOL SA DE CV”
Entonces, los datos del cliente Moral son los que se muestran abajo en color rojo, donde el contacto se toma del campo Contacto en la ficha del Cliente el valor registrado, en la imagen de abajo es “ALBERTO PERES MATIAS”:
Importante es que una persona MORAL debe tener en el campo GENERO el valor N.
- Datos de la Orden: se debe enviar datos como: kilometraje, fecha promesa de entrega, fecha de recepción, fecha de término, si la orden proviene de una cita.
Se debe enviar los comentarios del técnico y los que se imprimen en la factura.
Se debe enviar el precio de venta total y el impuesto.
Se debe enviar el motivo del trabajo:
Considerar que en este campo se tienen mas opciones que la marca GM agregó.
- Asesor de servicio: se debe enviar los datos del asesor de servicio.
- Técnico del servicio: se debe enviar los datos de los técnicos que trabajaron cada operación.
- Tipos de Ordenes: los tipos de órdenes que se envían son:
Garantías: se valida que sea el documento Garantía
Internas: se valida que la orden este activo el check Nota Interna
y Públicas, y dentro de las públicas hay una subclasificación de:
HYP: se valida la sección
Express: se valida la sección
y Público en general: se valida la sección
- Mano de Obra: se envían datos de cada operación trabajada en la orden, si la operación es código de LTG también se indican en el XML, en color rojo abajo se muestran los campos a enviar:
- Refacciones: se envían datos de cada refacción surtida en la orden, en color rojo abajo se muestran los campos a enviar:
- Materiales adicionales: se envían datos de los materiales diversos:
- Trabajos en otros talleres: se envían datos de los TOT´s:
Para ello se valida que la operación este activo el check de Trabajo externo.
- Datos de la garantía: estos datos son los que se registran en la interfaz GWM (aunque de momento esta inactiva la interfaz), código de falla, descripción de la falla, código de queja descripción de queja y descripción de la corrección:
- Estatus de la orden: se envían los estatus de:
Orden en Proceso: un estado distinto a TERMINADA,CANCELADO
Orden facturada: las ordenes que ya tienen una factura asignada
Orden cancelada: las ordenes que tienen el estado CANCELADO.
Cabe mencionar que para el envío diario de la información de ordenes de Servicio, se envían 3 eventos distintos:
*Open
*Cancelled
*Invoiced
Si en el día la Orden de Servicio se abrió y no se Facturó/Canceló entonces se envía el evento Open y todos los datos de la OR.
Si en el día la Orden de Servicio se abrió y se facturó entonces se envía el evento Open y evento Invoiced, y todos los datos de la OR. En el XML enviado se puede ver que hay 2 órdenes con sus datos, pero en realidad solo es una Orden.
Si en el día la Orden de Servicio se abrió y se canceló entonces se envía el evento Open y evento Cancelled. En el XML enviado se puede ver que hay 2 órdenes con sus datos, pero en realidad solo es una Orden.
- Vehículo: se envían los datos del vehículo en color rojo:
- Paquete de mantenimiento: se envía el código del kit de mantenimiento:
- Datos de la garantía extendida: dentro del mantenimiento del vehículo se tienen datos de la garantía extendida.
7.- Herramienta para leer XML
La aplicación cuenta con una funcionalidad para leer el archivo XML de Ordenes de Reparación y Venta Mostrador, el cual mostrará la información en una ventana tipo excel, y en el mismo se podrá exportar a un excel.
El objetivo de esta funcionalidad es que el usuario pueda consultar que información contiene el XML de algún día en particular y con la ayuda del excel hacer su análisis correspondiente.
Para leer los XML de Venta Mostrador debemos dar clic en la opción “Leer XML generados Parts
Sales”
Se mostrará una ventana donde el usuario deberá de indicar:
- El número de Bac, lo elige del campo BAC
- Debe indicar la fecha de inicio y la Fecha Final de los XML enviados a DDS,
- La ruta de la carpeta compartida del DataPower
La fecha inicial y final lo buscará en el nombre de los archivos de la carpeta compartida del DataPower, por lo que se recomienda sea un rango de fecha corto.
Por ejemplo, el archivo PartsInvoice_Show_191966_20231109005001409.xml es un archivo que contiene la venta de mostrador del BAC 191966 y que su fecha de creación es el 09/Noviembre/2023 a las 00:50:01 am, por lo tanto, el usuario debe indicar en la herramienta que quiere leer el archivo con fecha inicial 09/11/2023 al 09/11/2023
En las implementaciones se dejó configurado que la ruta de los XML creados se graben en la ruta siguiente: \\IP_del _delaer\SharedData\Temporal
Ejemplo: \\201.100.61.50\SharedData\Temporal
Por lo tanto, un ejemplo de cómo haría la búsqueda el usuario sería como la siguiente imagen:
En realidad, el usuario debe usar la herramienta para consultar la información, pero en las imágenes anteriores se ejemplificó como busca la información de acuerdo a la nomenclatura de los archivos XML.
Si el usuario agrega una fecha distinta en la fecha final y mayor a la fecha inicial, la herramienta si puede buscarlo, solo que se mostrará información de distintos días. Recordando que la aplicación crea de forma diaria los archivos XML.
Después que el usuario agregó los datos de búsqueda, puede dar clic en el boton “Cargar” y con esto la herramienta buscará el archivo, y mostrará la información contenida en la ventana en la parte inferior.
En esta ventana se mostrarán los nodos que actualmente se comparten con DDS, y aquí es donde el usuario puede identificar el contenido enviado, donde cada columna corresponde al nombre del nodo dentro del XML.
El usuario puede usar el boton de “Opciones” y ahí “Exportar datos” a un archivo excel.
Se abrirá la ventana de Windows y el usuario puede indicar la ruta donde quiera guardar el archivo excel.
Después de indicar que guarde el archivo, debe esperar a que la aplicación realice la creación del archivo excel y al finalizar verá un mensaje como el siguiente:
El usuario podrá ir a la carpeta donde grabó el archivo excel
Y al abrirlo verá la información, y aquí es donde podrá hacer uso de excel para el análisis de información.
Importante es mencionar que:
1.- La carga de la información del XML en la ventana de la aplicación puede tardar dependiendo del volumen de información que encuentre en el XML, por ejemplo el ejemplo de la imagen se hizo en 5 segundos, pero hay XML donde vienen cientos de registros y esto puede ser no tan rápido.
2.- Tambien el layout de la Venta de Refacciones es mas pequeño que el de Ordenes de Servicio, por lo tanto, este último puede tardar hasta 1 minuto en cargar información. En las ordenes de Servicio el layout tiene mas de 100 campos, aunque no se ocupan todos, pero para efectos de leer la información y ver que nodos son, se compara con el layout y luego se construye y luego se muestra la información.
Tambien existe la opción de que se pueda ver cierto detalle de cada registro, por ejemplo, en el caso de la venta de refacciones puedo ver el detalle solicitado de cada item vendido, para ello debemos activar el check de “Cargar detalles” y luego dar clic en el boton “Cargar”.
Se seguirá mostrando la información sobre la ventana principal, solo que al dar un doble clic sobre algún registro se abrirá una segunda ventana donde podemos ver el detalle, por ejemplo en la imagen, en color rojo el registro donde di doble clic y se abre la siguiente ventana.
En caso de que el usuario no indique el BAC o la Ruta, el sistema mandará un mensaje indicando el error.
Para el caso de las Ordenes de Servicio, básicamente es el mismo procedimiento, donde de manera inicial debe elegir la opción “Leer XML generados Repair Order”
Solo que en la ventana principal aparece una opción para “Quitar duplicados” por fecha de facturación en la ventana principal. Esto es porque hay ocasiones donde una orden se factura una fecha anterior, y se refactura al siguiente día, por lo que el envío a DDS se hace en los 2 días. Y si la búsqueda del XML en esta herramienta considera los 2 días entonces mostrará ambos registros de distintos archivos que corresponden a distintos días.
Por ello es importante recalcar que lo recomendable es buscar solo de un día. La finalidad de esta herramienta es que el usuario vea que información se esta enviando en que archivo de que día.
Related Articles
MANUAL OPERACION SOFIA 2 4
SOFIA GM SOFIA 2.0 Historial Versión Comentario / Descripción Responsable Fecha Estatus 1.0 Creación y elaboración del documento. Moisés Ramírez Jun. 2014 Creado 2.0 Actualización – Sofia 2.0 Humberto Cuahutle Dic. 2017 Actualizado 2.1 Actualización ...Manual de Operación DDC ScoreCard-
ScoreCard Operación Tabla de contenido Indicadores ScoreCard 2 Definición 2 Captura de Información 2 Captura de Indicadores. 2 Indicadores ScoreCard. Definición ScoreCard son indicadores que la marca solicita para poder reportar información de ...3 Cuenta Predial Operacion
Cuenta Predial Manejo de Arrendamiento, Cuenta Predial Operación Cuenta Predial Introducción Reglas de Negocio Configuración Operación Notas de Débito Notas de Crédito Cuenta Predial Introducción Cuenta Predial, en este ...Manual - DDC Inventario-VTA Seminuevos Cambios NISSAN Operacion 2024
DDC Valuaciones, Inventarios & Venta de Seminuevos Operación Tabla de contenido Cambios en la interface de DDC Valuaciones, Inventario & Venta de Seminuevos. Definición Mapeo de información Mapeo de Marca, Modelo, Versión y Año. Operación Mapeo de ...3 - Service 360 CRM Operacion 22 0 4
SERVICE 360 CRM Service 360 CRM Versión 22.0.4 Operación Contenido CRM POSTVENTA Visualizar en las citas la información de la relación de trabajos que la integran. Citas. Funcionamiento. Agendar citas de servicio en fechas lejanas Calendario de ...