Histórico da Página

...

Para registrar un producto complementario para enviar al Bridge, basta acceder la rutina de sugerencia de ventas en el módulo de control de tiendas, en Actualizaciones->Escenario de Ventas->Sugerencia de ventas. Es necesario que la base de datos ya posea movimientos de ventas para que la rutina wizard realice la debida vinculación y también el parámetro MV_LJCATPR esté activado conforme procedimientos de implantación.

• Cadastro Archivo de Produtos Similaresproductos similares

Para cadastrar um produto complementar registrar un producto complementario para enviar ao al Bridge basta acessar acceder a rotina la rutina de amarração de categorias x produtos no vinculación de categorías vs. productos en el módulo de controle de lojas em Atualizações->Cadastros->Amarração control de tiendas, en Actualizaciones->Archivos->Vinculación Cat.xprd. Para que a rotina de integração com Bridge entenda la rutina de integración con Bridge entienda que se trata de um un registro de produtos productos similares é necessário que o conteúdo do es necesario que el contenido del campo Sug. VendaVenta (Sugestão Sugerencia de venda) seja preenchido com o conteúdo 1 e campo sequencia não esteja vazio conforme a imagem abaixo. 

venta) se cumplimente con el contenido 1 y campo secuencia no esté vacío, de acuerdo con la siguiente imagen. 

Image Added

Archivo de marcasPara

Disponible el archivo de marcas, se ha puesto a disposición la tabla OG en el archivo SX5.

Impuestos vs. Productos

de Marcas, exclusivo para utilización en la Integración Synthesis. El objetivo de este archivo es almacenar los datos en Protheus®, vincular la marca al producto y enviar estos datos al Bridge para que el POS realice los tratamientos conforme el archivo. Para acceder, en el Control de tiendas, acceda a Actualizaciones/Integración/Marcas. Porque este archivo utiliza nuestro archivo de tablas (SX5) es necesario que el campo Tabla siempre se complete con el contenido OG. 

Image Added

Impuestos vs. Productos

Para el envío de los Impuestos vinculados es necesario que la TES esté registrada en la tabla SFC en el momento del envío de la información al Bridge. A partir de la TES Para el envío de los Impuestos vinculados es necesario que la TES esté registrada en la tabla SFC en el momento del envío de la información al Bridge. A partir de la TES vinculada al producto, se ubicarán los impuestos en la tabla SFC y se enviarán al Bridge Manager.

Importante

El contenido del campo Cpo del L.F.(FB_CPOLVRO) no puede repetirse para los tipos de impuestos mencionados anteriormente. 

Encabezado Promo

Para almacenar el Archivo de promociones (Promo Bridge) se utiliza la tabla MEI - Encabezado regla de descuento. Para alimentar esta tabla existe un servicio WS(Protheus Server) cuya promoción se registra en el Bridge y se envía el código, descripción y vigencia al Protheus®.

En las ventas en las cuales se aplica el descuento referente a una promoción, se informa el código de la promoción, para ello, se creó un campo en los ítems de venta del Protheus(LR\L2_IDPROMO).

Aumento Financiero (Recargos) 

Pago de ventas utilizando NCC

Para que las ventas que utilizan NCC como forma de pago se graben correctamente en las tablas del Protheus®, el parámetro MV_LJCPNCC(Utilización de la NCC si la utilización fuera parcial) se utiliza con el Contenido 2 – Modificación de saldo.

Integración de Ventas previas/Presupuestos

Las ventas previas/presupuestos se realizan en el Sistema Bridge(Synthesis) y se envían al Protheus® para posterior consulta y envío como Pago. Para casos de ventas previas/presupuestos, el campo L1_SITUA se graba con el contenido AG (Esperando pago).

Código de países

En las rutinas de integración Protheus vs. Synthesis el aumento financiero se trata a través de un producto cuyo tipo (B1_TIPO) debe ser igual a CG – Recargo. 
El tipo de producto CG – Recargo se incluye automáticamente en la tabla de tipos de productos en el archivo SX5 después de Los códigos de los países utilizados en la integración será a partir del estándar ISO 3166-1 alfa-3. Los principales países de América del Sur y Central se graban en la tabla SYA a partir de la ejecución de la rutina de carga de datos LJSTSCLIE con la codificación ISO 3166-1 alfa-3.

Integración Usuarios

Los usuarios se registran en el Protheus® y se envían de forma encriptada al Bridge, que realiza la validación del hash en el momento del login en el Bridge POS. Para la integración con la Synthesis es obligatoria la cumplimentación de la fecha de validez del login del usuario. Después de la inclusión de un usuario por medio del Control de tiendas se muestra una pantalla para que se informe el perfil del usuario al Bridge, esta información es obligatoria para el Bridge. Existen tres tipos de perfil 1, 2 o 3. Siendo 1 = Admin, 2 = Advanc, 3 = Basic. Las configuraciones referentes a cada perfil quedan almacenadas en el sistema Bridge. Después de informar el perfil del usuario se activa la pantalla de archivo de vendedores para facilitar el registro del vendedor. El código del vendedor debe ser el mismo del login del usuario. Para el Bridge un usuario (login) puede ser vendedor y caja.

Archivo de clientes

• La integración no acepta caracteres especiales en los campos del Archivo de clientes.
• El campo fecha de nacimiento es obligatorio para la integración.
• Para clientes persona física, es necesario completar los campos Nombre reducido(A1_NREDUZ) y el campo Nombre(A1_NOME).
• Para clientes persona Jurídica es necesario completar el campo Nombre(A1_NOME).
• Si el cliente tuviera ingresos brutos, complete el campo N.Ing.Brutos(A1_NROIB).
• Si se hubiera completado el campo Teléfono, los campos DDN y DDI, también deben completarse.
• Si el cliente tuviera impuestos para registrar (SFH) es obligatorio completar los siguientes campos: FH_PERCENT - % Exención, FH_ALIQ – Alícuota, FH_DECRETO – Decreto, FH_INIVIGE – Ini. Vigencia, FH_FIMVIGE – Fin Vigencia, FH_CATCLI – Cód Categoría.
• Es obligatorio informar el CUILT para persona física, el DI (Documento de identidad) para persona física o el número de pasaporte para los extranjeros. Esta información es necesarias para la generación automática del código del cliente.

Regla para generación del código del cliente

Con el objetivo de evitar duplicidades de códigos de clientes, el campo Código del cliente (A1_COD), tendrá 13 caracteres y se compondrá de:  tipo de documento del cliente (01 – Documento nacional de identidad; 02 – Pasaporte; 03 – CUIT) + Número del documento y se completará con ceros a la izquierda del número del documento.

Ejemplo: Un cliente persona física que presenta su DNI(Documento nacional de identidad) que tiene el número 12345, el Código del cliente (A1_COD) debe ser de la siguiente manera: 010000012345. El código del cliente se revalidará y ajustará de forma automática de acuerdo con la regla Synthesis en el momento de la confirmación del archivo del cliente. El código informado manualmente se ignorará.

Bloqueo de registros

El bloqueo de registros se trata por medio del campo (ALIAS)_MSBLQL para las siguientes entradas. Después del bloqueo del registro, se envía al Bridge el registro como bloqueado

• Proveedores.
• Clientes.
• Niveles de jerarquía.
• Grupos de jerarquía.
• Unidad de medidas.
• Impuestos IVA de los productos.
• Tipo de impuestos internos. Productos.
• Medios de pago.
• Prefijos.

Monitor de LOGS

Para facilitar la identificación y corrección de las inconsistencias ocurridas en la integración, se puso a disposición un Monitor de Logs (LOJA743). Por este monitor, es posible verificar qué error ocurrió en la integración y permite modificar el estatus del registro para reprocesamiento. Para registrar las inconsistencias ocurridas en el transcurso de las integraciones, se utilizan tablas específicas dependiendo de la modalidad de la integración (MF4 – Exportación y MEZ – Importación). Interfaz para modificación de la tabla intermediaria de exportación – MEZ

Está a disposición la interfaz para modificación de los registros almacenados en la tabla intermedia de exportación de los dados al Sistema Bridge. El objetivo de esta interfaz es modificar el estatus de los registros de la tabla intermedia MEZ por medio del campo Estatus POS (MEZ_STFLAG). Para entrar al Control de tiendas, acceda a Actualizaciones/Integración/Interfaz intermedia exportación.

Interfaz para modificación de la tabla intermedia de importación – MF3

Está a disposición la interfaz para modificación de los registros almacenados en la tabla intermedia de importación de los dados al sistema Bridge. El objetivo de esta interfaz es modificar el estatus de los registros de la tabla intermedia MF3 por medio del campo Estatus POS (MF3_STFLAG). Para entrar al Control de tiendas, acceda a Actualizaciones/Integración/Interfaz intermedia importación.

Restricciones:

en las tablas intermediarias LJSTSCLIE conforme informado en procedimientos de implementación. 
El producto del tipo CG – Recargo se identifica al Bridge a través de la TAG genericItemFlag en el webservice de envío de productos.
Este producto debe estar relacionado a una TES que no calcule stock (F4_ESTOQUE = N), caso el producto del tipo CG - Recargo no posea una TES vinculada a través del campo B1_TS o la TES vinculada esté parametrizada para calcular stock la venta no se procesará y estará pendiente en la tabla intermediaria de exportación hasta el debido ajuste. 
Por el hecho de que la integración funciona solo con el escenario de ventas activo este producto del tipo CG debe estar vinculado a una lista de precios activa (DA1).
En las ventas con aumento financiero el Bridge va a enviar el valor del aumento financiero (recargo) da venta en el producto parametrizado como aumento financiero (recargo) y el Protheus va a considerar el valor enviado por el Bridge y no considerar los valores parametrizados para este producto en especial. Para los productos del tipo CG(Recargo) la tabla de/para de TES no se considera automáticamente y se considera la TES del producto. 

Venta de Servicios 
En las rutinas de integración Protheus vs. Synthesis la venta de servicios es tratada a través de un producto cuyo tipo (B1_TIPO) debe ser igual a SV – Servicios. 
 

El tipo de producto SV – Servicios se incluye automáticamente en la tabla de tipos de productos en el archivo SX5 después de la ejecución de la rutina de carga en las tablas intermediarias LJSTSCLIE conforme informado en procedimientos de implementación. 
 

El producto del tipo SV – Servicios se identifica al Bridge a través de la TAG genericItemFlag en el webservice de envio de productos.

 
Este producto debe estar relacionado a una TES que no calcule stock (F4_ESTOQUE = N), caso el producto del tipo SV - Servicio no posea una TES vinculada a través del campo B1_TS o la TES vinculada esté parametrizada para calcular stock para venta no se procesará yestará pendiente en la tabla intermediaria de exportación hasta el debido ajuste. 

Por el hecho de que la integración funcione solo con el escenario de ventas activo este producto de tipo SV debe estar vinculado a una lista de precios activa (DA1).

En las ventas de productos del tipo servicio el Bridge va a enviar el valor del servicio en el producto parametrizado como servicio y el Protheus va a considerar el valor enviado por el Bridge y no considerar los valores parametrizados para este producto en especial. Para los productos del tipo SV (Servicio) la tabla de/para de TES no se considera automáticamente y es considerada la TES del producto.

Pago de ventas utilizando NCC

Para que las ventas que utilizan NCC como forma de pago se graben correctamente en las tablas del Protheus®, el parámetro MV_LJCPNCC(Utilización de la NCC si la utilización fuera parcial) se utiliza con el Contenido 2 – Modificación de saldo.

Integración de Ventas previas/Presupuestos

Las ventas previas/presupuestos se realizan en el Sistema Bridge(Synthesis) y se envían al Protheus® para posterior consulta y envío como Pago. Para casos de ventas previas/presupuestos, el campo L1_SITUA se graba con el contenido AG (Esperando pago).

Código de países

Los códigos de los países utilizados en la integración será a partir del estándar ISO 3166-1 alfa-3. Los principales países de América del Sur y Central se graban en la tabla SYA a partir de la ejecución de la rutina de carga de datos LJSTSCLIE con la codificación ISO 3166-1 alfa-3.

Integración Usuarios

Los usuarios se registran en el Protheus® y se envían de forma encriptada al Bridge, que realiza la validación del hash en el momento del login en el Bridge POS. Para la integración con la Synthesis es obligatoria la cumplimentación de la fecha de validez del login del usuario. Después de la inclusión de un usuario por medio del Control de tiendas se muestra una pantalla para que se informe el perfil del usuario al Bridge, esta información es obligatoria para el Bridge. Existen tres tipos de perfil 1, 2 o 3. Siendo 1 = Admin, 2 = Advanc, 3 = Basic. Las configuraciones referentes a cada perfil quedan almacenadas en el sistema Bridge. Después de informar el perfil del usuario se activa la pantalla de archivo de vendedores para facilitar el registro del vendedor. El código del vendedor debe ser el mismo del login del usuario. Para el Bridge un usuario (login) puede ser vendedor y caja. 

Archivo de clientes

• La integración no acepta caracteres especiales en los campos del Archivo de clientes.
• El campo fecha de nacimiento es obligatorio para la integración.
• Para clientes persona física, es necesario completar los campos Nombre reducido(A1_NREDUZ) y el campo Nombre(A1_NOME).
• Para clientes persona Jurídica es necesario completar el campo Nombre(A1_NOME).
• Si el cliente tuviera ingresos brutos, complete el campo N.Ing.Brutos(A1_NROIB).
• Si se hubiera completado el campo Teléfono, los campos DDN y DDI, también deben completarse.
• Si el cliente tuviera impuestos para registrar (SFH) es obligatorio completar los siguientes campos: FH_PERCENT - % Exención, FH_ALIQ – Alícuota, FH_DECRETO – Decreto, FH_INIVIGE – Ini. Vigencia, FH_FIMVIGE – Fin Vigencia, FH_CATCLI – Cód Categoría.
• Por el hecho que Bridge no trata el concepto de vigencia para sus registros de impuestos del cliente la integración siempre envía todos los registros de la tabla SFH sn considerar los campos de vigencia.
• Si el cliente posee un registro en la tabla SFH con el campo de exento (FH_ISENTO) igual a S se envía un registro con la alícuota 0(cero).
• Si el cliente posee un registro en la tabla SFH con el campo de alicuota igual a 0(cero) se envía un registro con la alícuota vacía para que el Bridge entienda que será tratado de la forma de cálculo de impuesto general.
• Es obligatorio informar el CUILT para persona física, el DI (Documento de identidad) para persona física o el número de pasaporte para los extranjeros. Esta información es necesarias para la generación automática del código del cliente.
• Es obligatorio el rellenado del campo Cod.Municipio (A1_COD_MUN) debido a las validaciones internas del sistema Bridge. El campo Municipio (A1_MUN) se completa de forma automática tras el rellenado del código del municipio. Para la importación del cliente a partir del sistema Bridge el processo es el mismo. Las informaciones referentes al código, descripción y estado/prov. del municipio están almacenadas en la tabla CC2 (Municipios). Para facilitar la implantación esta tabla se publica de forma automática por las rutinas de setup de la integración. Caso necesario el mantenimiento en esta tabla está disponible la rutina de registro de municipios (FISA010) localizada en Actualizaciones->Integración->Municipios.

Regla para generación del código del cliente

Con el objetivo de evitar duplicidades de códigos de clientes, el campo Código del cliente (A1_COD), tendrá 13 caracteres y se compondrá de:  tipo de documento del cliente (01 – Documento nacional de identidad; 02 – Pasaporte; 03 – CUIT) + Número del documento y se completará con ceros a la izquierda del número del documento.

Ejemplo: Un cliente persona física que presenta su DNI(Documento nacional de identidad) que tiene el número 12345, el Código del cliente (A1_COD) debe ser de la siguiente manera: 010000012345. El código del cliente se revalidará y ajustará de forma automática de acuerdo con la regla Synthesis en el momento de la confirmación del archivo del cliente. El código informado manualmente se ignorará.

Bloqueo de registros

El bloqueo de registros se trata por medio del campo (ALIAS)_MSBLQL para las siguientes entradas. Después del bloqueo del registro, se envía al Bridge el registro como bloqueado

• Proveedores.
• Clientes.
• Niveles de jerarquía.
• Grupos de jerarquía.
• Unidad de medidas.
• Impuestos IVA de los productos.
• Tipo de impuestos internos. Productos.
• Medios de pago.
• Prefijos.

Monitor de LOGS

Para facilitar la identificación y corrección de las inconsistencias ocurridas en la integración, se puso a disposición un Monitor de Logs (LOJA743). Por este monitor, es posible verificar qué error ocurrió en la integración y permite modificar el estatus del registro para reprocesamiento. Para registrar las inconsistencias ocurridas en el transcurso de las integraciones, se utilizan tablas específicas dependiendo de la modalidad de la integración (MF4 – Exportación y MEZ – Importación). Interfaz para modificación de la tabla intermediaria de exportación – MEZ 

Está a disposición la interfaz para modificación de los registros almacenados en la tabla intermedia de exportación de los dados al Sistema Bridge. El objetivo de esta interfaz es modificar el estatus de los registros de la tabla intermedia MEZ por medio del campo Estatus POS (MEZ_STFLAG). Para entrar al Control de tiendas, acceda a Actualizaciones/Integración/Interfaz intermedia exportación.

Interfaz para modificación de la tabla intermedia de importación – MF3

Está a disposición la interfaz para modificación de los registros almacenados en la tabla intermedia de importación de los dados al sistema Bridge. El objetivo de esta interfaz es modificar el estatus de los registros de la tabla intermedia MF3 por medio del campo Estatus POS (MF3_STFLAG). Para entrar al Control de tiendas, acceda a Actualizaciones/Integración/Interfaz intermedia importación.

Monitor de errores Integración ERP 
Para facilitar la identificación y corrección de las inconsistencias ocurridas en la integración de las ventas con el ERP Protheus después de la grabación de las tablas del módulo de control de tiendas, está disponible un Monitor de errosr Integración ERP (LOJA781). 
Image Added

Es posible verificar el error ocorrido en la integración con las tablas del ERP y permite modificar el estatus del registro para reprocesamiento; 
Image Added

Facilitadores de implantación y diagnóstico de posibles inconsistencias durante la integración: 
• Rutina de carga para publicar las tablas del motor de integración client y server con todos los datos necesarios para ejecutar la integración; 
• Rutina para publicar la tabla de-para con los principales deparas (tipos de productos, formas de pago, categorías de terminal, monedas y países ya definidos entre TOTVS y Synthesis; 
• Rutina para publicar nuevas tablas y datos necesarios para los archivos Synthesis con los datos ya definidos entre TOTVS y Synthesis (Categorías del cliente ante los impuestos, Tipos de Impuesto por Jurisdicción, Categorías de ítems para los impuestos, Uso del ítem, Clase de Impuesto, Reglas de Impuestos, Impuestos IVA Productos, formas de pago (NCC, Euro, Dólar), países para seguir el estándar ISO 3166-1 alfa-3, tipo de productos 02-SX5) y Municipios Argentina (Ciudades); 

• Rutina para publicar la tabla SB0 con base en los datos de la tabla SB1 ya rellenando todos los campos obligatorios para integración existente en la tabla SB0. Para ejecutar esta rutina acceda la sucursal que desea crear la tabla SB0 Actualizaciones/Integración/Crea SB0. 

• Rutina para publicar una nuva tienda en la tabla intermediaria de exportación del Protheus y envío al Bridge con todos los datos base ya cargados para las demás tiendas. Para ejecutar esta rutina acceda Actualizaciones/Integración/Genera Nueva tienda. 

• Monitores de LOGS de integración para importación (SERVER) y exportación (CLIENT) donde consta el estatus del registro, el motivo de la inconsistencia y los datos inconsistentes, todo en una sola pantalla y con la opción de que el propio usuario solicite el reprocesamiento tras el ajuste de las inconsistencias de datos. 
• Envío automático de alerta vía e-mail al responsable por la operacion cuando detecta alguna inconsistencia en el proceso de integración dentro del Protheus para importación y exportación de datos y movimientos; 
• Rutina para modificación de datos en las tablas intermediarias de integración tanto Server como Client, evitando la necesidad de accesos directos a base de datos; 
• Monitor integracion ERP (GRAVABATCH) donde consta el estatus del registro, el motivo de la inconsistencia y los datos inconsistentes, todo en una sola pantalla y con la opción de que el propio usuário solicite el reprocesamiento tras el ajuste de las inconsistencias de datos;

Restricciones: 

No se consideran en esta Integración los siguientes procesos:

...

1.       Estilos, envases, imágenes, enlazados y servicios (productos)

...

5.       Aumento financiero por condición de pago. 

• La generación de los valores fiscales son de responsabilidad de Synthesis.

...

• Los datos relacionados a movimiento ej. ventas, informe Z, movimiento caja, retiros parciales de caja, entrada de vuelto son de responsabilidad de Synthesis.

...

• La integración soporta movimientos de devolución en dinero o en factura de crédito (NCC).

Procedimiento de implementación:

Importante

Antes de ejecutar el compatibilizador UPDLO114 y UPDLO143, es imprescindible:

a)        Realizar la copia de seguridad de la base de datos y de los diccionarios de datos SXs del producto donde se ejecutará el compatibilizador.

...

d)        Si los diccionarios de datos tienen índices personalizables (creados por el usuario), antes de ejecutar el compatibilizador, asegúrese de que estén identificados por el nickname. Si el compatibilizador necesita crear índices, los agregará a partir del orden original instalado por el Protheus, lo que podrá superponer índices personalizables, si no están identificados con por el nickname.

e)        El compatibilizador debe ejecutarse con la Integridad referencial desactivada*. 

1. En TOTVS Smart Client, digite U_UPDLO114 en el campo Programa inicial.

Importante

Para la correcta actualización del diccionario de datos, asegúrese de que la fecha del compatibilizador es igual o superior al 22/06/2013.

1. Haga clic en OK para continuar.
2. Después de la confirmación, se muestra una pantalla para seleccionar la empresa en la cual se modificará el diccionario de datos.
3. Al confirmar se muestra un mensaje de advertencia sobre la copia de seguridad y la necesidad de su ejecución de modo exclusivo.
4. Haga clic en Procesar para iniciar el procesamiento. El primer paso de la ejecución es preparar los archivos.
   Se  Se muestra un mensaje explicativo en la pantalla.
5. A continuación, se muestra la ventana Actualización finalizada con el historial (log) de todas las actualizaciones procesadas. En este log de actualización sólo se muestran los campos actualizados por el programa. El compatibilizador crea los campos que aún no existen en el diccionario de datos.
6. Haga clic en Grabar para guardar el historial (log) mostrado.
7. Haga clic en OK para finalizar el procesamiento.

Importante

Realice el mismo procedimiento de implementación utilizado para aplicación del UPDLO114, al UPDLO143.

Actualización del compatibilizador UPDLO114

1. Modificación de tabla en el archivo SX2– Tablas:

2. Creación de tabla en el archivo SX2– Tablas:

3. Creación de disparadores en el archivo SX7 – Disparadores:

• Tabla MFB - Vínculo Categoría vs. Filtro:

1. Creación de tablas genéricas en el archivo SX5 – Tablas genéricas:

2. Modificación de Campos en el archivo SX3 – Campos:

• Tabla ACU - Categoría de productos:

• Tabla ACV – Categoría vs. Grupo o Producto:

• Tabla SA5 – Vínculo Producto vs. Proveedor:

• Tabla SB5 - Datos adicionales del producto:

...