Datacomsys 7.4 / 8.0 Revision 120127

Modificaciones importantes en Datacomsys Revisión 120127

Títulos correspondientes a modificaciones y agregados realizados para esta revisión.

Aplicado a todas las versiones (7.4 / 8.0):

1) Ampliación de datos para rendición de órdenes de carga.


2) Validación de remitos para entregar, o que retira el cliente en ordenes de carga.


3) Facturación electrónica, separación de obtención de token and sign.


4) Envió de pedidos, recibos, órdenes de compra y de pago por email.


Detalles correspondientes a modificaciones y agregados realizados para esta versión:

Todas las versiones (7.4 / 8.0):

Ordenes de carga:
Rendición de órdenes de carga:

Hemos ampliado los datos asociados a la rendición de una orden de carga, en lo referente a solicitar las horas de inicio y finalización del viaje, y el kilometraje inicial y final.
Estos datos se visualizan en la consulta de la orden de carga, y pueden ser incorporados en el formulario impreso de la misma.

Validación de incorporación de remitos en órdenes de carga:

A efectos de poder validar, que un remito de venta, pueda o no ser incorporado en una orden de carga, se han realizado una serie de controles al momento de ser incorporado.
Siendo el remito un documento complejo, ya que puede ser el comienzo de una operación, el intermedio o el final, se ha establecido la siguiente precedencia en los controles.

Si el remito tiene incorporado datos de entrega, botón: (Datos de despacho, con el logo del camión), se lo considera válido para incorporarlo en una orden de carga.

Si el remito NO tiene datos de entrega, pero esta asociado a una factura, se verifica que esta factura tenga datos de entrega, y de ser así, se lo considera válido para incorporarlo en una orden de carga.

Si el remito NO tiene datos de entrega, esta asociado a una factura, y esta factura NO tiene incorporados datos de entrega, se verifica que dicha factura este asociada a un pedido, en este caso, se verifica que el pedido tenga definido en el campo con rotulo “Tipo entrega” : el valor Entrega la empresa, y de ser así, se lo considera válido para incorporarlo en una orden de carga.

Si el remito NO tiene datos de entrega, la factura tampoco, y esta ultima o bien NO esta asociada a un pedido, o el pedido tiene definido en el campo con rotulo “Tipo de entrega”, el valor Retira el cliente, el remito es considerado como NO válido para incorporarse en una orden de carga.

Si el remito NO tiene datos de entrega, pero esta asociado a un pedido, y este pedido tiene definido en el campo con rotulo “Tipo de entrega”, el valor Entrega la empresa, es considerado válido, si por el contrario tiene asociado el valor Retira el cliente, el remito no es considerado valido.

Si el remito NO tiene datos de entrega, y no esta asociado a ningún documento anterior, el remito no es considerado válido para incorporarse en una orden de carga.

Estas validaciones solo se realizan sobre remitos de tipo VTA, por el contrario, los remitos de tipo CSG, DEV, FSN, MAN, OEN, TRS y USO, no tienen validación alguna.

Facturación electrónica
Separación de obtención de token and sign :

En el documento anterior mencionamos cierto error que se estaba produciendo, referido a la obtención del token and sign, al momento de obtención del cae sobre una factura electrónica.

Dicho error se manifestaba como :

“El CEE ya posee un TA valido para el acceso al WSN solicitado”

Si el operador lo aceptaba y aprobaba de nuevo, ocasionalmente el error seguía, pero comúnmente se obtenía el cae sin mayor inconveniente.

La facturación electrónica consiste en dos momentos, el primer momento es aquel donde se presenta el certificado otorgado por Afip, y se obtienen dos registros denominados Token and Sign, luego con la obtención de estos dos registros se presentan los datos del comprobante y se obtiene el cae.

Estos dos registros, Token and Sign, pueden ser obtenidos una vez cada veinticuatro horas, agilizando bastante el procedimiento de obtención del cae.

A partir de esta versión, la primera vez que se genera un comprobante electrónico, el token y sign obtenido se mantiene dentro del sistema y se lo reutiliza para cada comprobante.


Estos registros son eliminados automáticamente con los procesos de comienzo del día, o sea, no deberían durar en el sistema más de veinticuatro horas.

Independientemente de este proceso de borrado automático, el panel “Trabajar minutas electrónicas”, ahora cuenta con un botón inferior con rotulo (Renovar firma), que básicamente realiza la operación de borrado manual de los registros de Token and Sign y su nueva obtención.

En definitiva, esta modificación debería ser transparente para el usuario en lo referente a su operatoria, y debería favorecer a la obtención del Cae de manera mas rápida.

Envió de pedidos, recibos, órdenes de compra y de pago por email.

Si bien el sistema ya disponía de varias formas de envío de estos documentos por email, ahora hemos agregado una nueva posibilidad; que se utiliza de manera similar a como se envían por email los comprobantes electrónicos de venta.

El procedimiento consiste en generar por medio de una impresora virtual, el archivo pdf correspondiente; y directamente, desde el sistema, enviarlo por email según las direcciones de correo que se encuentren definidas en el legajo del cliente o proveedor.
Este envío de email, de estar parametrizada esta acción, genera un incidente en el documento que se haya enviado.

Básicamente los paneles de “Pedidos por cliente”, “Recibos por cliente”, “Ordenes por proveedor”, y “^Pagos por proveedor”, cuenta con un botón (Reimprimir).
Al haber seleccionado un comprobante y clickear en (Reimprimir), posterior a la confirmación, se despliega un pequeño panel central que permite seleccionar el tipo de impresión.
A este panel se le ha agregado la opción “Envió email”.

Al tildar “Envió email” y confirmar, se despliega un mensaje que solicita que se genere el archivo .pdf a partir de la impresión que se desplegará en pantalla.

Al dar (Ok), se desplegará la impresión común del comprobante seleccionado y se deberá imprimir al mismo con la impresora PDF que se haya instalado (Adobe, pdfcamp, dopdf, o lo que el técnico sugiera).


Una vez generado el archivo .pdf, se desplegará un panel con los datos de la dirección de correo a enviar, si hay copias, como asunto se incorporar el nombre de la empresa emisora y el tipo y numero de comprobante a enviar, y se deberá adjuntar al .pdf creado.

Al clickear en (Enviar), se enviara el email con el archivo adjunto y se procederá a la generación del indicente correspondiente.

Importante :

El punto de venta desde DONDE se envía el email, deberá estar parametrizado acorde a lo que se solicita en “Parámetros”, “Parámetros de la sucursal”, botón (Impresoras), solapa “Correo”.
De no ser así, no habrá acción alguna.

Se sugiere que haya un path específico para guardar los .pdf generados.

Recomendamos dopdf v7 como impresora virtual.

Recomendamos revisar en el legajo del cliente, solapa “Otros”, las direcciones de email para envío de pedidos, y envío de recibos, así como en el legajo del proveedor, solapa “Otros”, las direcciones de correo para el envío de ordenes de compra y ordenes de pago.








Las consultas que surjan sobre estos u otros temas relacionados al sistema, por favor enviarlas a informes@carlosherrero.com.ar o consultar www.datacomsys.blogspot.com

Verifique si su instalación ha podido ser actualizada ingresando en Parámetros y clickeando en “Acerca de Datacomsys”, en caso que el numero de versión no coincida con la de este informe solicitamos que lo reporte por correo electrónico.
Recordamos la necesidad de respaldar en CD, DVD o en otro equipo, el archivo .bck generado automáticamente por el proceso de backup diario.

Ch 27-01-2012