Datacomsys Sistema Integrado:
A partir del dia jueves 01 de Octubre del 2015, las novedades, modificaciones o noticias sobre Datacomsys Sistema Integrado, serán publicadas en los siguientes canales:
Facebook : https://www.facebook.com/Datacomsys
Twitter : https://twitter.com/DatacomsysWeb
YouTube : https://www.youtube.com/user/DatacomsysSI
Agradecemos la colaboración y dedicación recibida.
Carlos Herrero Octubre 2015
lunes, 12 de octubre de 2015
lunes, 26 de agosto de 2013
Datacomsys revision 130726
Modificaciones
importantes en Datacomsys Revisión 130726
Títulos correspondientes a
modificaciones y agregados realizados para esta revisión.
Aplicado a todas las versiones
(7.4 / 8.0 / 10a):
1) Ajustes cuentas
corrientes clientes.
2) Notas de crédito
utilizando precio de venta actual.
3) Cierre de lote
para cupones tarjetas de crédito.
4) Cambios en la
seguridad del sistema.
5) Sobre backups de
datos del sistema.
Detalles :
Todas las versiones
(7.4 / 8.0 / 10a):
Ajustes cuentas
corrientes clientes:
A partir de esta revisión el sistema cuenta con una
nueva actividad para realizar ajustes en cuentas corrientes de clientes.
Si desde el panel “Trabajar con clientes”, se clickea
en (Ajustes cta.cte), se despliega un panel de trabajo con los ajustes
generales que se hayan realizado.
A diferencia de otras actividades del panel que se
realizan habiendo seleccionado primero el cliente, esta nueva actividad tiene
la particularidad de ser aplicada a varios clientes a la vez.
Si dentro del panel “Trabajar ajustes cuenta corriente
clientes”, clickeamos en (Nuevo), procedemos a comenzar la realización de un
ajuste para un cliente o un grupo de ellos.
Se despliega un panel con rotulo “Minuta ajustes
cuenta corriente clientes”, e inmediatamente se despliega una aplicación que
corresponde a la Cabecera del ajuste.
(Este método que es común en la versión 8.0 y
10ª, fue incorporado para esta actividad en todas las versiones).
Los datos de cabecera corresponden a la fecha general
del ajuste, quien lo solicitó
y autorizó, así
como la cuenta contable donde se imputará el total del ajuste.
También cuenta con un campo de observaciones.
Al confirmar la cabecera se vuelve al panel de la
minuta, y clickeando en el botón (Agregar), se podrán incorporar los distintos
clientes y montos a ajustar.
Los clientes son aquellos validos en el sistema, y el
importe de ajuste se puede indicar en positivo o negativo según lo que se
quiera compensar al ajustar.
Una vez concluida la carga de los clientes e importes
a ajustar, se deberá clickear en (Confirmar), produciéndose las siguientes consecuencias:
El ajuste tendrá un número general para todo el
formulario, y a su vez un número correlativo para cada cliente de los
ajustados.
Ya que es imposible que un mismo numero de comprobante
este en dos clientes distintos.
El ajuste particular para cada cliente realizará un
movimiento en su cuenta corriente cronológica y analítica, utilizando los tipos
de comprobantes internos 82-Crédito interno, y 81-Debito interno.
Se generaráa un asiento global por la sumatoria de los importes ajustados, contra la cuenta que haya indicado en la cabecera del ajuste.
El ajuste se desplegará en el panel “Trabajar ajustes
de cuenta corriente”, pudiendo ser consultado mediante el botón (Consultar).
En futuras versiones esta actividad estará disponible
para ajustar proveedores.
Notas de crédito
utilizando precio de venta actual:
A partir de esta revisión es posible parametrizar que
las notas de crédito, asociadas a un comprobante, obtengan los valores
unitarios de los productos en base al precio histórico o el actual.
Por defecto el sistema toma los valores históricos.
Para que utilice los valores actuales, se debe
proceder a generar una alteración desde el acceso de parámetros.
Cierre de lote para
cupones tarjetas de crédito:
A partir de esta revisión se ha comenzado a trabajar en relación al
control y procedimiento de liquidación de cupones de tarjetas de crédito.
Los procedimientos de control se ampliaran en próximas
versiones.
Desde el acceso de tesorería el sistema cuenta con una
nueva actividad para efectuar el cierre de lotes de cupones de tarjetas,
simulando en forma manual lo que se hace en el postnet en forma automática.
Clickeando en (Lotes tarjetas), se accede a un panel
con los distintos lotes que se hayan generado.
El panel ordena del mas reciente al mas antiguo,
pudiendo optar por los lotes que hayan sido saldados o bien que tengan saldo
pendiente de liquidación.
Si se quiere generar un nuevo lote, se deberá clickear
en (Nuevo lote).
Al hacerlo se despliega un panel similar al de trabajo
con valores, pero solamente para aquellos de tipo T-tarjetas de crédito, y que
tengan saldo.
El objetivo es seleccionar uno o mas cupones
pendientes e incorporarlos al lote, de manera similar a como trabaja el
postnet.
Los cupones se pueden filtrar con los cuadros de búsqueda
superiores, y seleccionar de a uno clickeando en la primer columna, o bien en
bloque clickeando sobre el botón superior a la primer columna.
Una vez realizada la selección se debe clickear en
(Conformar lote), desplegándose una actividad con titulo “Minuta lote tarjetas”
En esta minuta solo se pueden incorporar datos de
cabecera, como numero de lote y Terminal, (que los otorga el postnet), fecha,
observaciones y la cartera que se debita en forma global por el crédito a cada
uno de los cupones.
Al confirmarse la minuta se generan las siguientes
consecuencias :
Se genera un registro por el lote conformado, con número
de lote y postnet.
Los cupones seleccionados se cancelan, quedando su
saldo en cero y no afectando mas, por ejemplo, el tope de crédito de los
clientes.
Se genera un movimiento de ingresos y egresos que
debita la cartera global que representa a la entidad y que acredita a cada uno
de los cupones que conforman el lote.
En futuras versiones esta actividad se complementara
con el ingreso de la liquidación de la entidad, que acreditará la cartera global
y debitará la cuenta corriente bancaria, así como marcará al lote como
liquidado.
Siendo importante esto ultimo para efectuar
conciliaciones.
IMPORTANTE : CAMBIOS
EN LA SEGURIDAD DEL
SISTEMA
Aplicado a todas las
versiones : 7.4 / 8.0 y 10ª.
A distribuirse con la
revisión de agosto 2013, aproximadamente el día 15-09-2013
ESTA INFORMACION SERA
REENVIADA ANTES DE PROCEDER A LA INSTALACION
A partir de la revisión 130830 a distribuirse
aproximadamente el día 15-09-2013 y subsiguientes, habrá un importante cambio
en la seguridad del sistema.
Las claves de acceso que utilizan los operadores en
forma habitual, COMENZARAN A TENER UN VENCIMIENTO.
O sea que las claves que se utilizan deberán ser
renovadas por el mismo operador con cierta periodicidad.
El periodo de renovación es automático y aleatorio,
abarcando desde los 3 a
los 120 días.
Esto es inmodificable y aplica a todos y cada uno de
los operadores, sin importar cargo, nivel u otros atributos del mismo.
Si al momento de ingresar al sistema se valida que la
clave esta vencida, se procederá a informar mediante un mensaje:
ATENCION:
Su clave de acceso al sistema esta vencida
Luego se desplegará un panel donde se debe indicar la
nueva clave y repetirla con los siguientes criterios:
Deben coincidir la clave y su repetición.
No debe tener espacios en blanco.
Debe ser de ocho dígitos alfanuméricos
Debe tener por lo menos cuatro letras.
Debe tener por lo menos cuatro números.
No puede ser la clave anterior.
Si se cumplen las pautas anteriores se procede al
cambio de clave informando al usuario que :
IMPORTANTE
: recuerde su nueva clave
Si
la olvida deberá ser dado de alta nuevamente como operador
Su
nueva clave hereda los privilegios y acciones realizadas con la anterior
Su
nueva clave vence el día : DD/MM/AAAA
Deberá
cerrar el acceso actual e ingresar nuevamente con su nueva clave.
ANTES DE PROCEDER A LA INSTALACION DEL NUEVO
METODO DE SEGURIDAD, SE AVISARAA LAS DISTINTOS CLIENTES PARA QUE TOMEN LOS
RECAUDOS CORRESPONDIENTES
Referido al resguardo de datos en forma de backup, recordamos que:
El sistema Datacomsys NO
TIENE en ninguno de sus paneles o actividades la función de hacer un backup de
datos.
El backup de datos se hace
en forma automática o manual desde el administrador de datos SQL que se
encuentra en el servidor.
Habitualmente el
administrador de datos esta instalado de tal manera que los backups se hacen en
forma automática a las 02.00 de cada día.
Los backups que se realizan
se resguardan EN LA
MISMA MAQUINA en la carpeta c:\sqlbck, a no ser que el
administrador de la empresa haya dispuesto algo distinto., manteniendo habitualmente
hasta 3 copias de los últimos 3 días, las anteriores se eliminan en forma automática.
ES OBLIGACION Y
NECESIDAD de cada empresa, resguardar DIARIAMENTE el archivo de backup en
:
OTRA MAQUINA de la red.
FTP EXTERNA accediendo por internet
CD o DVD
Si este resguardo por parte
de la empresa no se hace diariamente, puede ocurrir que, por distintos
inconvenientes, el backup no se haya hecho y la empresa no se entere, por lo
tanto tampoco nos enteraremos nosotros.
Recordamos a tales efectos
que: de producirse un inconveniente grave en el servidor del sistema y
que obligue a ser reinstalado, solicitaremos el último backup de datos, y
que si este backup de datos es antiguo, no tendremos manera de solucionar el
problema.
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-26-07-2013
martes, 13 de agosto de 2013
Datacomsys revision 121221
Modificaciones importantes en
Datacomsys Revisión 121221
IMPORTANTE;
Datacomsys cuenta a este momento con tres versiones, la versión 7.4 para
ambientes Windows Server 2000/2003 y SQL Server 7/ 8, la versión 8.0 para
ambientes Windows 2003 / 2008 64x, SQL Server 2000/2005/2008, Mysql, y la versión
10a, en desarrollo, para ambientes Web.
Esta ultima desarrollada en Java utilizando Apache Tomcat, lo que
permite su instalación en ambientes Windows o Linux y es a la que el proyecto
Datacomsys estima como definitiva.
La versión 7.4 esta disponible desde el año 2004, la versión 8.0 desde
el 2009 y la 10a proyectamos que este
disponible a fines de este año 2013.
Durante todos estos años hemos tratado de mantener consistencia en las
distintas operaciones para todas y cada una de las versiones, siendo la única
diferencia entre ellas el ambiente o base de datos con la que se trabajaba.
A partir de esta revisión, 121221, y a efectos de aprovechar las
herramientas que nos ofrecen ambientes o tecnologías mas modernas, ya no será
posible mantener consistencia en las operaciones de las distintas versiones.
O sea, las operatorias nuevas se diseñaran y fabricarán tomando como
base las versiones 8.0 y 10a, y si es posible se las agregará a la versión 7.4.
Finalmente, proyectamos para diciembre de este año o a mas tardar junio
2014, la versión 7.4 ya no tendrá mas actualizaciones.
La base de datos Datacomsys seguirá siendo compatible entre las
distintas versiones.
O sea, los datos no se perderán ante la migración entre las distintas
versiones.
Es nuestro deseo que, durante este año, aquellas instalaciones que están
utilizando la versión 7.4 migren a la versión 8.0, a tales efectos es
importante tener en cuenta que Datacomsys 8.0 es un sistema nuevo, o sea que
aquellas instalaciones en las que se hayan hecho modificaciones especiales o
agregados al sistema, deberán tener en cuenta que dichos desarrollos en gran
parte podrán ser migrados, pero otra parte deberá ser rediseñada.
En definitiva, esos desarrollos especiales no pueden ser copiados, sino
que necesitan de cierta reingeniería para su adaptación a Datacomsys 8.0.
Por preguntas o dudas sobre este tema, por favor dirigirse por email a
la dirección de correo habitual.
Títulos correspondientes a
modificaciones y agregados realizados para esta revisión.
Aplicado a todas las versiones
(7.4 / 8.0):
1) Preparación de remitos .
Aplicado a la versión 8.0:
1) Compatibilidad con mercado Uruguayo.
2) Moneda y cotización en comprobantes.
3) Moneda de referencia en carteras ingresos y
egresos.
4) Movimientos ingresos y egresos en moneda de
origen.
Detalles :
Todas las versiones
(7.4 / 8.0):
Preparación de
remitos:
A partir de esta revisión el sistema Datacomsys cuenta
con la posibilidad de indicar el estado de una minuta de remito como preparada
o pendiente de preparar.
Parametrizando el punto de venta para que permita la
preparación de remitos, se produce una interrupción en la traza de la minuta de
remito y su archivado definitivo.
Esta interrupción se manifiesta en un panel de Remitos
pendientes de preparación, que cuenta con una actividad donde es posible
ingresar su cantidad preparada, consultarlos o eliminarlos.
La cantidad preparada puede ser menor o igual a la
original.
El remito real se emite por la cantidad preparada.
Esta preparación de remitos se aplica a cualquier tipo
de remito Datacomsys.
Solo disponible en la
versión 8.0:
Compatibilidad con
mercado Uruguayo:
Habiéndose producido la venta e instalación de dos
sistemas Datacomsys en Uruguay, el mismo se ha adaptado para que,
parametricamente, se pueda adecuar a la legislación y disposiciones del mercado
uruguayo.
Moneda y cotización
en comprobantes:
Por medio de una parametrizacion especial, es posible
indicar en pedidos, comprobantes de venta, recibos de caja, órdenes de compra,
comprobantes de proveedor y ordenes de pago, la moneda y cotización que
corresponda.
Moneda de referencia
en carteras ingresos y egresos:
A partir de esta revisión es posible indicar en la
definición de una cartera de ingresos y egresos, a que moneda corresponde
dentro del catalogo de monedas del sistema.
Movimientos de
ingresos y egresos en moneda de origen:
En conjunto con la modificación anterior, los importes
de los pases de los movimientos de ingresos y egresos pueden ser incorporados
en la moneda de origen.
Al ingresar un movimiento de ingresos y egresos, en lo
referente a las carteras de imputación, cada pase tiene la posibilidad de
indicar su moneda y cotización; la conversión a la moneda corriente se realiza
en forma automática.
En las revisiones siguientes se podrá realizar esta
misma operatoria para recibos de caja 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
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-21-12-2012
lunes, 5 de noviembre de 2012
Datacomsys revision 121026
Modificaciones importantes en Datacomsys Revisión 121026
Títulos correspondientes a modificaciones y agregados realizados para esta revisión.
Aplicado a todas las versiones (7.4 / 8.0):
1) Evaluación crediticia.
2) Validación correlatividad numérica y máximo de compra anual en proveedores.
3) Carteras tipo T, manuales o postnet.
4) Resumen de cuenta proveedores por fecha de ingreso.
5) Percepciones provincia de Rió Negro
6) Detalle por concepto de liquidación de sueldos.
Detalles :
Todas las versiones (7.4 / 8.0):
Evaluación crediticia.
El acceso especifico de gestión de cobranzas, udtscobr.exe, cuenta con un nuevo botón que accede a la actividad de evaluación crediticia.
Esta actividad permite recopilar datos de deuda de clientes y desplegarlos en un panel de trabajo, estos datos son similares a los que se obtienen imprimiendo el resumen de deuda del cliente, y se calculan mediante el botón (Obtener datos).
Este botón muestra un panel de selección similar al que se despliega al emitir un resumen de deuda.
Una vez los datos en la grilla, los mismos pueden ordenarse clickeando en las columnas correspondientes, generar un Excel mediante f8 o bien ejecutar distintas acciones .
Validación correlatividad numérica y máximo de compra anual en proveedores.
A efectos de cumplimentar con las resoluciones vigentes de afip, en lo referente a ser solidario ante contribuyentes que vendan o compren mas de lo permitido por su carácter del sujeto, se ha modificado la parametrizacion posible en los métodos de compra, agregando la posibilidad que se valide, al momento de ingresar un comprobante de proveedor, la correlatividad numérica del mismo y la sumatoria anual de comprobantes emitidos.
Al momento de ingresar un comprobante de proveedor, se valida según lo definido en el método, si la numeración del mismo es secuencial al anterior emitido e ingresado, así como si la sumatoria anual de comprobantes emitidos supera el monto máximo permitido por afip.
En caso de no cumplir estas premisas se emite un mensaje de advertencia al respecto.
En caso que el método este parametrizado que no permite estas anomalías, el comprobante no podrá ser ingresado.
Por el contrario, si el método esta definido como que SI permite estas anomalías, solamente se emite el mensaje de advertencia.
Carteras tipo T, manuales o postnet.
Las carteras de imputación de disponibilidades que se definen en ingresos y egresos, cuenta con la posibilidad de ser parametrizadas con distintos tipos.
Entre los tipos posibles el sistema cuenta con el tipo “T”, tarjetas de crédito.
Ahora, al definir una cartera como tipo T, se solicita además si se trata de una tarjeta que se utiliza manualmente o bien con un postnet.
El objetivo de esta parametrizacion es excluir a estos cupones de los resúmenes de deuda y demás informes u operatorias que contemplen el tope de crédito en valores, debido a que si la tarjeta se utiliza mediante un postnet, no tiene sentido incluir los cupones como deuda de cliente, ya que han sido autorizados on-line.
Siendo los reportes y validaciones de topes de crédito procesos privados, se deberá solicitar expresamente la exclusión de estos cupones.
Resumen de cuenta proveedores por fecha de ingreso.
Al momento de ingresar una factura de proveedor se deben indicar dos fechas, la primera es la fecha del sistema, la segunda es la fecha de emisión del comprobante.
La primer fecha se utiliza para la contabilidad, diario de IVA ventas y otros procesos.
La segunda se utiliza para la proyección de la deuda y resúmenes de cuenta.
A partir de esta versión, y para dejar los resúmenes de cuenta de manera homologa a la contabilidad, estos se nutren de la fecha del sistema en vez de la fecha de emisión del comprobante.
Este cambio no es retroactivo a comprobantes ingresados con anterioridad.
Percepciones provincia de Rió Negro
En el acceso de afip, botón (Otras percepciones), se han incluido los procesos de cálculo y emisión de archivos del l modulo SIAP RNGAR correspondiente a la provincia de Rió Negro.
Este módulo SIAP permite importar datos de cuits de clientes y proveedores, así como las percepciones y retenciones realizadas.
Detalle por concepto de liquidación de sueldos.
El acceso de administración de personal, botón (Especiales), cuenta con un nuevo reporte denominado Sueldos/Concepto.
Este reporte recopila información de una o mas liquidaciones seleccionadas, las agrupa por concepto y emite un listado con el detalle de los legajos, liquidaciones y valores .
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-26-10-2012
Títulos correspondientes a modificaciones y agregados realizados para esta revisión.
Aplicado a todas las versiones (7.4 / 8.0):
1) Evaluación crediticia.
2) Validación correlatividad numérica y máximo de compra anual en proveedores.
3) Carteras tipo T, manuales o postnet.
4) Resumen de cuenta proveedores por fecha de ingreso.
5) Percepciones provincia de Rió Negro
6) Detalle por concepto de liquidación de sueldos.
Detalles :
Todas las versiones (7.4 / 8.0):
Evaluación crediticia.
El acceso especifico de gestión de cobranzas, udtscobr.exe, cuenta con un nuevo botón que accede a la actividad de evaluación crediticia.
Esta actividad permite recopilar datos de deuda de clientes y desplegarlos en un panel de trabajo, estos datos son similares a los que se obtienen imprimiendo el resumen de deuda del cliente, y se calculan mediante el botón (Obtener datos).
Este botón muestra un panel de selección similar al que se despliega al emitir un resumen de deuda.
Una vez los datos en la grilla, los mismos pueden ordenarse clickeando en las columnas correspondientes, generar un Excel mediante f8 o bien ejecutar distintas acciones .
Validación correlatividad numérica y máximo de compra anual en proveedores.
A efectos de cumplimentar con las resoluciones vigentes de afip, en lo referente a ser solidario ante contribuyentes que vendan o compren mas de lo permitido por su carácter del sujeto, se ha modificado la parametrizacion posible en los métodos de compra, agregando la posibilidad que se valide, al momento de ingresar un comprobante de proveedor, la correlatividad numérica del mismo y la sumatoria anual de comprobantes emitidos.
Al momento de ingresar un comprobante de proveedor, se valida según lo definido en el método, si la numeración del mismo es secuencial al anterior emitido e ingresado, así como si la sumatoria anual de comprobantes emitidos supera el monto máximo permitido por afip.
En caso de no cumplir estas premisas se emite un mensaje de advertencia al respecto.
En caso que el método este parametrizado que no permite estas anomalías, el comprobante no podrá ser ingresado.
Por el contrario, si el método esta definido como que SI permite estas anomalías, solamente se emite el mensaje de advertencia.
Carteras tipo T, manuales o postnet.
Las carteras de imputación de disponibilidades que se definen en ingresos y egresos, cuenta con la posibilidad de ser parametrizadas con distintos tipos.
Entre los tipos posibles el sistema cuenta con el tipo “T”, tarjetas de crédito.
Ahora, al definir una cartera como tipo T, se solicita además si se trata de una tarjeta que se utiliza manualmente o bien con un postnet.
El objetivo de esta parametrizacion es excluir a estos cupones de los resúmenes de deuda y demás informes u operatorias que contemplen el tope de crédito en valores, debido a que si la tarjeta se utiliza mediante un postnet, no tiene sentido incluir los cupones como deuda de cliente, ya que han sido autorizados on-line.
Siendo los reportes y validaciones de topes de crédito procesos privados, se deberá solicitar expresamente la exclusión de estos cupones.
Resumen de cuenta proveedores por fecha de ingreso.
Al momento de ingresar una factura de proveedor se deben indicar dos fechas, la primera es la fecha del sistema, la segunda es la fecha de emisión del comprobante.
La primer fecha se utiliza para la contabilidad, diario de IVA ventas y otros procesos.
La segunda se utiliza para la proyección de la deuda y resúmenes de cuenta.
A partir de esta versión, y para dejar los resúmenes de cuenta de manera homologa a la contabilidad, estos se nutren de la fecha del sistema en vez de la fecha de emisión del comprobante.
Este cambio no es retroactivo a comprobantes ingresados con anterioridad.
Percepciones provincia de Rió Negro
En el acceso de afip, botón (Otras percepciones), se han incluido los procesos de cálculo y emisión de archivos del l modulo SIAP RNGAR correspondiente a la provincia de Rió Negro.
Este módulo SIAP permite importar datos de cuits de clientes y proveedores, así como las percepciones y retenciones realizadas.
Detalle por concepto de liquidación de sueldos.
El acceso de administración de personal, botón (Especiales), cuenta con un nuevo reporte denominado Sueldos/Concepto.
Este reporte recopila información de una o mas liquidaciones seleccionadas, las agrupa por concepto y emite un listado con el detalle de los legajos, liquidaciones y valores .
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-26-10-2012
domingo, 12 de agosto de 2012
Datacomsys revision 120731
Modificaciones importantes en Datacomsys Revisión 120731
Títulos correspondientes a modificaciones y agregados realizados para esta revisión.
Aplicado a todas las versiones (7.4 / 8.0):
1) Comisiones por cobranzas incorpora montos a cuenta.
2) Partes de producción automáticos en base al plan de producción.
3) Preparación de pedidos de venta.
Detalles :
Todas las versiones (7.4 / 8.0):
Comisiones por cobranzas, incorporación de montos a cuenta:
Uno de los inconvenientes que se presentaban en el cálculo automático de comisiones por cobranzas se producía al ignorar, en el mencionado calculo, a aquellos recibos que solamente cobraban un monto a cuenta.
Como en el monto a cuenta sin aplicar no había una base imponible, era prácticamente imposible calcular el neto de dicho monto a cuenta, ya que podía tratarse de un comprobante final que tuviera varias alícuotas de IVA, impuestos internos, percepciones y otros, o bien se podía calcular pero con errores.
En definitiva, como no podía obtenerse un neto de manera exacta, este monto a cuenta era ignorado por el proceso de cálculo.
A partir de la revisión 120731 Datacomsys cuenta con un procedimiento privado, donde cada una de las instalaciones podrá optar por la incorporación o no de dichos recibos, así como el procedimiento para la obtención del neto.
O sea, los recibos por monto a cuenta podrán ser incorporados a criterio de cada instalación y calculándose el neto de la manera que el responsable de dicha instalación considere adecuado.
Partes de producción automáticos en base al plan de producción:
Cuando se utiliza el procedimiento de producción planificada existe la posibilidad de importar dicho plan desde una planilla Excel.
Una vez importado el plan, el mismo es impactado en el sistema para establecer los tiempos de producción y los insumos y momentos necesarios.
Finalmente se deben generar los distintos partes de trabajo que, al incorporarse los resultados correspondientes, terminan completando el ciclo productivo.
A partir de la revisión 120731 es posible generar los partes de trabajo, pendientes de resultado, en forma automática y basada en el plan de producción.
Este procedimiento implica que, independientemente del plan de producción y su longitud en el tiempo, se genera UN solo parte de trabajo para cada producible, al que luego si, podrá ser incorporado su resultado en una o mas veces.
O sea, bajo este método, el parte de trabajo se convierte en un planificador de la producción más que en un parte de trabajo propiamente dicho.
Preparación de pedidos de venta:
A efectos de mejorar la traza de comprobantes de venta se ha agregado en forma parametrica por sucursal, o sea no obligatoria, la posibilidad de mantener un pedido o presupuesto generado, en un nuevo estado que se denomina pendiente de preparar.
El pedido o presupuesto pendiente de preparar no es visualizado en la traza de remitos o facturación de pedidos hasta que dicho pedido o presupuesto este parcial o totalmente preparado y, la cantidad posible de remitir o de facturar, es precisamente aquella cantidad que ha sido preparada.
Este método de trabajo permite visualizar al pedido o presupuesto en un nuevo acceso al sistema (udtspre.exe Preparación de pedidos), este acceso cuenta con un panel de trabajo (Pedidos pendientes), donde se despliegan precisamente aquellos pedidos o presupuestos que, al haber sido emitidos desde una sucursal parametrizada como que prepara pedidos, están a la espera de la preparación correspondiente.
O sea, así como dichos pedidos o presupuestos NO pueden ser remitidos o facturados, SI pueden ser preparados desde este panel.
La preparación consiste en dos pasos, el primero es la publicación sea en un parte impreso, adaptable para cada instalación, en un archivo de transferencia para una lectora de códigos, o bien en la transmisión de los datos a un software del tipo WMS, y el segundo paso es el recupero de dichos datos de preparación sea en forma manual, a través de la descarga de una pistola lectora de códigos de barra, o bien por la devolución de datos del mencionado software WMS.
El pedido así preparado, parcial o totalmente, puede ser remitido o facturado bajo la traza común de remito sobre pedido o facturación de pedidos.
El pedido se visualizará en el panel Pedidos pendientes, hasta que sea completada su preparación.
Igualmente el panel Pedidos pendientes, cuenta con un combo que permite visualizar no solo los pendientes sino también los preparados, y sobre ellos ejercer acciones de consulta, cancelación, remisión, facturación o incidentarlos.
Es importante tener en cuenta que, el pedido pendiente de preparación reserva stock, condiciones y precios, en cambio el presupuesto pendiente de preparación actualiza condiciones y precios al momento de ser facturado.
Para utilizar esta posibilidad, se debe acceder desde parámetros, parámetros de la sucursal, y activarlo para cada sucursal deseada desde el botón (Parámetros), tilde “El pedido requiere preparación”
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 31-07-2012
Títulos correspondientes a modificaciones y agregados realizados para esta revisión.
Aplicado a todas las versiones (7.4 / 8.0):
1) Comisiones por cobranzas incorpora montos a cuenta.
2) Partes de producción automáticos en base al plan de producción.
3) Preparación de pedidos de venta.
Detalles :
Todas las versiones (7.4 / 8.0):
Comisiones por cobranzas, incorporación de montos a cuenta:
Uno de los inconvenientes que se presentaban en el cálculo automático de comisiones por cobranzas se producía al ignorar, en el mencionado calculo, a aquellos recibos que solamente cobraban un monto a cuenta.
Como en el monto a cuenta sin aplicar no había una base imponible, era prácticamente imposible calcular el neto de dicho monto a cuenta, ya que podía tratarse de un comprobante final que tuviera varias alícuotas de IVA, impuestos internos, percepciones y otros, o bien se podía calcular pero con errores.
En definitiva, como no podía obtenerse un neto de manera exacta, este monto a cuenta era ignorado por el proceso de cálculo.
A partir de la revisión 120731 Datacomsys cuenta con un procedimiento privado, donde cada una de las instalaciones podrá optar por la incorporación o no de dichos recibos, así como el procedimiento para la obtención del neto.
O sea, los recibos por monto a cuenta podrán ser incorporados a criterio de cada instalación y calculándose el neto de la manera que el responsable de dicha instalación considere adecuado.
Partes de producción automáticos en base al plan de producción:
Cuando se utiliza el procedimiento de producción planificada existe la posibilidad de importar dicho plan desde una planilla Excel.
Una vez importado el plan, el mismo es impactado en el sistema para establecer los tiempos de producción y los insumos y momentos necesarios.
Finalmente se deben generar los distintos partes de trabajo que, al incorporarse los resultados correspondientes, terminan completando el ciclo productivo.
A partir de la revisión 120731 es posible generar los partes de trabajo, pendientes de resultado, en forma automática y basada en el plan de producción.
Este procedimiento implica que, independientemente del plan de producción y su longitud en el tiempo, se genera UN solo parte de trabajo para cada producible, al que luego si, podrá ser incorporado su resultado en una o mas veces.
O sea, bajo este método, el parte de trabajo se convierte en un planificador de la producción más que en un parte de trabajo propiamente dicho.
Preparación de pedidos de venta:
A efectos de mejorar la traza de comprobantes de venta se ha agregado en forma parametrica por sucursal, o sea no obligatoria, la posibilidad de mantener un pedido o presupuesto generado, en un nuevo estado que se denomina pendiente de preparar.
El pedido o presupuesto pendiente de preparar no es visualizado en la traza de remitos o facturación de pedidos hasta que dicho pedido o presupuesto este parcial o totalmente preparado y, la cantidad posible de remitir o de facturar, es precisamente aquella cantidad que ha sido preparada.
Este método de trabajo permite visualizar al pedido o presupuesto en un nuevo acceso al sistema (udtspre.exe Preparación de pedidos), este acceso cuenta con un panel de trabajo (Pedidos pendientes), donde se despliegan precisamente aquellos pedidos o presupuestos que, al haber sido emitidos desde una sucursal parametrizada como que prepara pedidos, están a la espera de la preparación correspondiente.
O sea, así como dichos pedidos o presupuestos NO pueden ser remitidos o facturados, SI pueden ser preparados desde este panel.
La preparación consiste en dos pasos, el primero es la publicación sea en un parte impreso, adaptable para cada instalación, en un archivo de transferencia para una lectora de códigos, o bien en la transmisión de los datos a un software del tipo WMS, y el segundo paso es el recupero de dichos datos de preparación sea en forma manual, a través de la descarga de una pistola lectora de códigos de barra, o bien por la devolución de datos del mencionado software WMS.
El pedido así preparado, parcial o totalmente, puede ser remitido o facturado bajo la traza común de remito sobre pedido o facturación de pedidos.
El pedido se visualizará en el panel Pedidos pendientes, hasta que sea completada su preparación.
Igualmente el panel Pedidos pendientes, cuenta con un combo que permite visualizar no solo los pendientes sino también los preparados, y sobre ellos ejercer acciones de consulta, cancelación, remisión, facturación o incidentarlos.
Es importante tener en cuenta que, el pedido pendiente de preparación reserva stock, condiciones y precios, en cambio el presupuesto pendiente de preparación actualiza condiciones y precios al momento de ser facturado.
Para utilizar esta posibilidad, se debe acceder desde parámetros, parámetros de la sucursal, y activarlo para cada sucursal deseada desde el botón (Parámetros), tilde “El pedido requiere preparación”
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 31-07-2012
Datacomsys revision 120526
Modificaciones importantes en Datacomsys Revisión 120526 Títulos correspondientes a modificaciones y agregados realizados para esta revisión.
Aplicado a todas las versiones (7.4 / 8.0):
1) Exportación nomina personal a Galicia Office
2) DGI Citi compras versión 4.0.
3) Informe de evolución de precios.
4) Modificación paneles políticas de ventas.
5) Formación de costos en base a insumos de producción.
6) Codificación QR
Exclusivo de la versión 8.0 :
1) Datos anexos a cheques / valores en recibos y cobranzas contado Detalles correspondientes a modificaciones y agregados realizados para esta revisión:
Todas las versiones (7.4 / 8.0):
Exportación nomina personal a Galicia Office : El panel de exportaciones del módulo de administración de personal, cuenta con una nueva actividad que permite exportar la nomina de personal. Para que la exportación sea correcta, debe existir la planilla : 'Datos_Minimos_GO_template.xls' En la ubicación : c:\datacomsys\planillas\adp de la estación de trabajo que genera la exportación. La planilla se obtiene de la página web del Banco Galicia.
DGI Citi compras versión 4.0 : La actividad de exportación de datos de compras al utilitario SIAP dgi citi compras, se ha adaptado a la versión 4.0.
Informe de evolución de precios : A efectos de cumplimentar con ciertos requisitos de la Secretaria de Comercio, en lo referente a datos sobre la evolución de precios de venta, se ha desarrollado un informe con salida en formato de panel, que permite visualizar la evolución de precios de venta o costos, hasta en seis periodos. El informe permite filtrar por lista de precios, familia, rubro, línea, marca y producto, desplegando los datos a nivel rubro o producto, comparando costo o precio de venta, expresando los valores a consumidor final o sin impuestos, y tomando los datos de los precios históricos de venta y costo, o bien del ultimo comprobante emitido. El informe se emite desde el modulo de precios, (Listas de precios), (Productos), botón superior (Evolución de precios). Al emitirse la salida por panel, el mismo puede ser transferido a Excel mediante F8 Importante : los precios de venta y costo históricos son aquellos que se guardan automáticamente a fin de cada mes mediante el utilitario Data-agent, en caso que dicho utilitario no se utilice, falle, o que por cualquier motivo los precios y costos no sean resguardados, la información emitida será errónea, debiendo optarse por tomarlos del ultimo comprobante del periodo.
Modificación paneles políticas de ventas : Los paneles de trabajo asociados a políticas de precio en general, han sido modificados agregándole la fecha de inicio y finalización de la política desplegada. Formación de costos en base a insumos de producción: El proceso de formación de costos de productos producibles, en base al costo de los insumos utilizados, fue ampliado para la utilización de hasta once niveles de trabajo.
Codificación QR: A partir de la revisión 120526 el sistema esta adaptado para la emisión de códigos QR. A diferencia de los códigos de barras que permiten codificar una serie de números, los códigos QR permiten codificar muchas mas información. De esta manera se pueden crear códigos QR complejos que pueden ser utilizados para distintos usos, como ser publicidad, embalaje, logística, toma de inventario, estibaje en deposito. A diferencia de los códigos de barra, que solo pueden ser leídos o escaneados por pistolas especiales, los códigos QR pueden ser leídos por teléfonos celulares, los que a su vez los pueden transferir por mail, bluetooth u otros medios, por ejemplo a un sistema administrativo. La modificación actual consiste en la disponibilidad de un botón con rotulo (QR) en el legajo del producto, al accionar este botón se genera un código QR con los siguientes datos : pku={código de producto};Descripción={descripción del producto};Rubro={código de rubro};Marca={código de marca} Estos datos codificados pueden ser modificados a solicitud de cada instalación y seguramente serán incluidos o emitidos en diversas actividades actuales y futuras del sistema. El código QR generado será guardado en la carpeta \datacomsys\qr del servidor del sistema, en formato BMP, y con clave {código de producto}QR.bmp El código QR que se adjunta corresponde a mis datos personales. Mas información sobre códigos QR puede obtenerse de : http://es.wikipedia.org/wiki/C%C3%B3digo_QR Para que el código QR sea generado desde Datacomsys/Productos, debe existir conexión internet en la maquina que lo solicita, ya que el procedimiento utiliza una aplicación externa para la conversión de dato en código.
Exclusivo de la Versión 8.0 : Datos anexos a cheques / valores en recibos y cobranzas contado: Por disposición de la Afip, además de los datos actuales que se solicitan para cada valor al hacer un recibo, es necesario mantener también los siguientes datos : Sucursal banco emisor Titular de la cuenta Domicilio del titular Cuit del titular Numero de cuenta Esta disposición es bastante antigua y estaba disponible en el panel “Trabajar con valores”, mediante el botón (Ampliar datos) A efectos de cumplirla, parcialmente, la revisión 120526 incorpora como obligatorio el Cuit del titular en las actividades de recibos de caja, movimientos de ingresos y egresos y cobranzas de contado, para aquellas carteras de tipo V, y que sean incluidas en las mencionadas operaciones.
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 26-05-2012
Aplicado a todas las versiones (7.4 / 8.0):
1) Exportación nomina personal a Galicia Office
2) DGI Citi compras versión 4.0.
3) Informe de evolución de precios.
4) Modificación paneles políticas de ventas.
5) Formación de costos en base a insumos de producción.
6) Codificación QR
Exclusivo de la versión 8.0 :
1) Datos anexos a cheques / valores en recibos y cobranzas contado Detalles correspondientes a modificaciones y agregados realizados para esta revisión:
Todas las versiones (7.4 / 8.0):
Exportación nomina personal a Galicia Office : El panel de exportaciones del módulo de administración de personal, cuenta con una nueva actividad que permite exportar la nomina de personal. Para que la exportación sea correcta, debe existir la planilla : 'Datos_Minimos_GO_template.xls' En la ubicación : c:\datacomsys\planillas\adp de la estación de trabajo que genera la exportación. La planilla se obtiene de la página web del Banco Galicia.
DGI Citi compras versión 4.0 : La actividad de exportación de datos de compras al utilitario SIAP dgi citi compras, se ha adaptado a la versión 4.0.
Informe de evolución de precios : A efectos de cumplimentar con ciertos requisitos de la Secretaria de Comercio, en lo referente a datos sobre la evolución de precios de venta, se ha desarrollado un informe con salida en formato de panel, que permite visualizar la evolución de precios de venta o costos, hasta en seis periodos. El informe permite filtrar por lista de precios, familia, rubro, línea, marca y producto, desplegando los datos a nivel rubro o producto, comparando costo o precio de venta, expresando los valores a consumidor final o sin impuestos, y tomando los datos de los precios históricos de venta y costo, o bien del ultimo comprobante emitido. El informe se emite desde el modulo de precios, (Listas de precios), (Productos), botón superior (Evolución de precios). Al emitirse la salida por panel, el mismo puede ser transferido a Excel mediante F8 Importante : los precios de venta y costo históricos son aquellos que se guardan automáticamente a fin de cada mes mediante el utilitario Data-agent, en caso que dicho utilitario no se utilice, falle, o que por cualquier motivo los precios y costos no sean resguardados, la información emitida será errónea, debiendo optarse por tomarlos del ultimo comprobante del periodo.
Modificación paneles políticas de ventas : Los paneles de trabajo asociados a políticas de precio en general, han sido modificados agregándole la fecha de inicio y finalización de la política desplegada. Formación de costos en base a insumos de producción: El proceso de formación de costos de productos producibles, en base al costo de los insumos utilizados, fue ampliado para la utilización de hasta once niveles de trabajo.
Codificación QR: A partir de la revisión 120526 el sistema esta adaptado para la emisión de códigos QR. A diferencia de los códigos de barras que permiten codificar una serie de números, los códigos QR permiten codificar muchas mas información. De esta manera se pueden crear códigos QR complejos que pueden ser utilizados para distintos usos, como ser publicidad, embalaje, logística, toma de inventario, estibaje en deposito. A diferencia de los códigos de barra, que solo pueden ser leídos o escaneados por pistolas especiales, los códigos QR pueden ser leídos por teléfonos celulares, los que a su vez los pueden transferir por mail, bluetooth u otros medios, por ejemplo a un sistema administrativo. La modificación actual consiste en la disponibilidad de un botón con rotulo (QR) en el legajo del producto, al accionar este botón se genera un código QR con los siguientes datos : pku={código de producto};Descripción={descripción del producto};Rubro={código de rubro};Marca={código de marca} Estos datos codificados pueden ser modificados a solicitud de cada instalación y seguramente serán incluidos o emitidos en diversas actividades actuales y futuras del sistema. El código QR generado será guardado en la carpeta \datacomsys\qr del servidor del sistema, en formato BMP, y con clave {código de producto}QR.bmp El código QR que se adjunta corresponde a mis datos personales. Mas información sobre códigos QR puede obtenerse de : http://es.wikipedia.org/wiki/C%C3%B3digo_QR Para que el código QR sea generado desde Datacomsys/Productos, debe existir conexión internet en la maquina que lo solicita, ya que el procedimiento utiliza una aplicación externa para la conversión de dato en código.
Exclusivo de la Versión 8.0 : Datos anexos a cheques / valores en recibos y cobranzas contado: Por disposición de la Afip, además de los datos actuales que se solicitan para cada valor al hacer un recibo, es necesario mantener también los siguientes datos : Sucursal banco emisor Titular de la cuenta Domicilio del titular Cuit del titular Numero de cuenta Esta disposición es bastante antigua y estaba disponible en el panel “Trabajar con valores”, mediante el botón (Ampliar datos) A efectos de cumplirla, parcialmente, la revisión 120526 incorpora como obligatorio el Cuit del titular en las actividades de recibos de caja, movimientos de ingresos y egresos y cobranzas de contado, para aquellas carteras de tipo V, y que sean incluidas en las mencionadas operaciones.
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 26-05-2012
martes, 7 de febrero de 2012
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
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
miércoles, 21 de diciembre de 2011
Codigo de operaciones de traslado (COT)
Generalidades:
La Disposición normativa Serie B numero 32/06 emitida por ARBA indica que, bajo ciertas condiciones, el traslado de mercadería en el territorio de la Provincia de Buenos Aires, debe estar amparada por un número otorgado por dicha Agencia.
Dicho número es valido para una serie de remitos o bien para un remito en particular, y puede ser obtenido por distintos medios.
A través del aplicativo SIAP, y mediante el modulo OPTTB, a través de la pagina de ARBA, cargando una serie de datos o bien transfiriendo un archivo de textos, o finalmente de manera electrónica, donde en esta ultima se produce una comunicación entre la máquina que esta emitiendo el remito, y los servidores de ARBA encargados de asignarles el numero COT, algo similar, pero mucho mas sencillo que lo que se realiza para facturación electrónica A,B y E.
Igualmente es importante tener en cuenta que, a diferencia de la facturación electrónica Afip, para la obtención del COT se informan una serie bastante mas amplia de datos.
Estos datos surgen del remito u orden de carga, o bien de tablas anexas ya existentes en el sistema como ser la de transportes o parámetros.
El detalle de los datos que se deben enviar electrónicamente, puede ser consultado en el siguiente link :
http://www.arba.gov.ar/bajadas/Fiscalizacion/Operativos/TransporteBienes/Documentacion/20110823-TB-RemitoElectronicoDiseño.pdf
A partir de la revisión 111223, Datacomsys cuenta con la posibilidad de obtención del COT de manera automática, en forma similar a como se obtiene el CAE para una factura electrónica.
A tales efectos, se deben realizar ciertas instalaciones, parametrizaciones y validaciones, y comprender ciertos conceptos que el presente documento intentara explicar.
Diferencias entre la obtención del CAE de facturación y el COT del remito.
La factura electrónica es una factura, a partir que afip otorga el CAE.
El numero COT se obtiene sobre un remito que ya esta realizado.
La factura electrónica sin CAE no es valida, en cambio puede haber, bajo ciertas circunstancias, remitos sin COT, por ejemplo los de otra provincia, o los que valorizados estén por debajo de la cota mínima.
O sea, el COT es a nivel Provincial o de Agencia, el CAE de una factura es a nivel nacional.
(Si bien otras provincias están optando por el mismo método de verificación)
La obtención del CAE requiere de ciertos pasos de habilitación y certificación en AFIP, el COT solo requiere de un usuario y contraseña obtenidos en la Web de ARBA.
La factura con CAE se llama Factura electrónica, al remito con COT lo llaman Remito electrónico, pero en realidad mas que remito electrónico es un remito autorizado electrónicamente.
El numero CAE es único para cada comprobante, el numero COT puede ser el mismo para un lote de remitos.
Que tipos de remitos Datacomsys pueden ser informados:
Los remitos por venta (VTA), los remitos por consignación a clientes (CSG), los remitos por devoluciones a proveedores (DEV), los remitos por envío de Fasón (FSN) y los remitos por transferencias entre depósitos (TRF).
No esta previsto para los tipos de remitos manuales (MAN), las ordenes de entrega asociadas a los contado (OEN) y los remitos por uso interno (USO).
Que tablas Datacomsys hay que tener parametrizadas correctamente.
Catalogo de provincias:
Tener bien parametrizado los datos de código ARBA y código RNPA.
Catalogo unidades de medida:
Tener bien parametrizado los datos de código ARBA
Catalogo de productos:
Tener bien parametrizado los códigos en el campo “Nomenclador”
(Tener en cuenta que no es un código particular para cada producto singular, sino que según la codificación de Arba, es muy posible que todo un rubro lleve el mismo código)
Transportes:
Tener bien parametrizado el cuit del transporte y la patente del mismo.
Sucursales, clientes, proveedores:
Tener correctamente indicados los domicilios, localidades, códigos postales y códigos de provincia.
Los códigos ARBA pueden ser obtenidos del siguiente link :
http://www.arba.gov.ar/bajadas/Fiscalizacion/Operativos/TransporteBienes/Documentacion/20110818-TB-Tablas%20de%20validacion.pdf
Que tramitación se debe hacer en ARBA:
Se debe obtener una clave de acceso y password, según lo que se explica en : www.rentas.gba.gov.ar
Ingresos brutos
Código de operaciones de traslado (COT)
Clave de transporte
Instalación en cada maquina que solicitara el COT:
Se debe instalar la interfase phytom que se obtiene desde el link :
http://www.datacomsys.com.ar/bkps/xpws/electronicas/pythom/201111/instalador-COT-1.01c-full.exe
En la ubicación c:\COT, y siendo esta instalación realizada por nosotros y con un costo adicional.
Debe existir la carpeta c:\datacomsys\cot, donde ser guardarán los distintos archivos de transferencia entre Datacomsys y ARBA.
Parametrizacion de punto de venta:
Se debe acceder a Parámetros, menú superior Parámetros, marcando el punto de venta que se desea habilitar y clickeando en (Parámetros), se debe verificar que este bien parametrizado domicilio, localidad, código postal y provincia.
Habiendo marcado la sucursal que se desea habilitar, se debe clickear en (Impresoras), y luego acceder a la solapa “Remito Electrónico”
En el campo con rotulo “Servidor autentificación”, se debe ingresar:
https://cot.ec.gba.gov.ar/TransporteBienes/SeguridadCliente/presentarRemitos.do
Usuario y contraseña deben ser aquellos tramitados en la Web de ARBA, como se explico anteriormente.
Que se informa y de donde se obtiene:
En función de lo que se menciono en “Generalidades”, los datos que se informan por cada tipo de remito son los siguientes:
VTA Remito de venta:
Obtiene Cuit destino, razón social, domicilio, código postal, localidad y provincia del legajo del cliente.
Si el cliente es consumidor final, asume que es el tenedor final.
Asume que se envían productos terminados.
Asume que el solicitante del COT es el emisor del remito.
CSG Remito por consignación:
Obtiene Cuit destino, razón social, domicilio, código postal, localidad y provincia del legajo del cliente.
Si el cliente es consumidor final, asume que es el tenedor final.
Asume que se envían productos terminados.
Asume que el solicitante es el emisor del remito.
DEV Remito por devolución:
Obtiene Cuit destino, razón social, domicilio, código postal, localidad y provincia del legajo del proveedor asociado, obligatoriamente se debe informar que los productos NO son terminados por mas que lo estén.
Asume que el solicitante del COT es el emisor del remito.
FSN Remito por fason :
Obtiene Cuit destino, razón social, domicilio, código postal, localidad y provincia del legajo del proveedor asociado, obligatoriamente se debe informar que los productos NO son terminados.
Asume que el solicitante del COT es el emisor del remito.
TRS Remito por transferencia entre depósitos:
El cuit de destino es similar al cuit emisor.
Domicilio, código postal, localidad y provincia de destino se obtienen del depósito receptor.
Asume obligatoriamente que se trata de productos NO terminados por mas que lo estén.
Asume que el solicitante del COT es el destinatario de la mercadería.
Otros datos generales que se informan:
Cuit del emisor del remito, fecha y hora de comienzo del traslado de la mercadería, dirección, localidad, código postal y provincia del punto de venta emisor del remito u orden de carga, cuit y chapa patente del transportista asociado a la orden de carga o remito, código ARBA de los productos informados, código propio, descripción, cantidad remitida, e importe total del remito.
Utilización:
Puede utilizarse de dos maneras, obteniendo el numero COT remito por remito, o bien mediante la utilización de una Orden de carga, en este ultimo caso, el numero COT obtenido es el mismo para la orden de carga y los respectivos remitos que la componen.
Sugerimos que la obtención del COT se realice a través de una orden de carga, debiendo estar la misma con el estado “C” cerrada.
En ambos casos, al obtener el cot desde un remito o bien desde una orden de carga, se genera en la dirección c:\datacomsys\cot, un archivo de transferencia con la estructura que se referencia en “Generalidades” y que tiene como nombre la siguiente estructura:
TB_{cuit emisor}_001001_{año mes dia}_{últimos seis dígitos de la OCG o RTO}.TXT
Este archivo es el que se utiliza, automáticamente, para la obtención del cot.
Este archivo no se destruye con la obtención del COT, sino que queda guardado en la dirección referenciada.
Mas detalles sobre este archivo de transferencia, se pueden consultar en el siguiente link: http://www.arba.gov.ar/bajadas/Fiscalizacion/Operativos/TransporteBienes/Documentacion/20110818-TB-RemitoElectronicoAplicacionCliente.pdf
Obtener el número COT desde un remito:
Para obtener el numero COT desde un remito emitido, se debe acceder al acceso AFIP, ingresando con el numero de sucursal acorde a los remitos emitidos y a declarar, y clickear en el botón (COT ARBA).
Una vez accedido, se despliegan los remitos ordenados inversamente, se debe localizar el remito a obtener el COT y clickear en (Obtener COT).
Si no hay errores, se genera el mencionado archivo de transferencia con los datos del remito en particular, se lo envía para su autorización, y se obtiene automáticamente el numero COT que quedará asociado al remito y se podrá visualizar en la consulta del mismo, así como en la grilla de remitos en las columnas COT numero y COT integridad.
Obtener el numero COT desde una orden de carga.
Para obtener el numero COT desde una orden de carga, se debe acceder al acceso DESPACHO, (ordenes de carga), y localizar la orden de carga a autorizar, la que debe estar con estado “C”cerrada.
Una vez localizada la orden de carga, se deberá clickear en (Obtener COT)
Si no hay errores, se genera el archivo de transferencia con los datos de los remitos incorporados en la orden de carga, se lo envía para su autorización, y se obtiene automáticamente el numero COT que quedará asociado a la orden de carga y a todos sus remitos, pudiendo ser consultado tanto en la consulta de ordenes de carga como en cada remito en particular.
Validaciones Datacomsys que se realizan antes de solicitar el COT:
Que este parametrizado el servidor de autentificación en el legajo de la sucursal solicitante.
Que el o los remitos asociados a la orden de carga de origen no tengan número de cot asignado anteriormente.
Que el o los remitos asociados a la orden de carga de origen sean de los tipos de remitos validos para la obtención del COT
Validaciones que realiza ARBA con el archivo de transferencia informado:
Los posibles errores que encuentre ARBA se desplegaran al momento de solicitar el COTS, e igualmente se pueden visualizar desde el acceso Parámetros, menú superior parámetros, opción Motivos de rechazo COT.
Mayores detalles solicitarlos a informes@carlosherrero.com.ar o bien visitando www.datacomsys.com.ar / www.datacomsys.blogspot.com
Ch 16-12-2011
La Disposición normativa Serie B numero 32/06 emitida por ARBA indica que, bajo ciertas condiciones, el traslado de mercadería en el territorio de la Provincia de Buenos Aires, debe estar amparada por un número otorgado por dicha Agencia.
Dicho número es valido para una serie de remitos o bien para un remito en particular, y puede ser obtenido por distintos medios.
A través del aplicativo SIAP, y mediante el modulo OPTTB, a través de la pagina de ARBA, cargando una serie de datos o bien transfiriendo un archivo de textos, o finalmente de manera electrónica, donde en esta ultima se produce una comunicación entre la máquina que esta emitiendo el remito, y los servidores de ARBA encargados de asignarles el numero COT, algo similar, pero mucho mas sencillo que lo que se realiza para facturación electrónica A,B y E.
Igualmente es importante tener en cuenta que, a diferencia de la facturación electrónica Afip, para la obtención del COT se informan una serie bastante mas amplia de datos.
Estos datos surgen del remito u orden de carga, o bien de tablas anexas ya existentes en el sistema como ser la de transportes o parámetros.
El detalle de los datos que se deben enviar electrónicamente, puede ser consultado en el siguiente link :
http://www.arba.gov.ar/bajadas/Fiscalizacion/Operativos/TransporteBienes/Documentacion/20110823-TB-RemitoElectronicoDiseño.pdf
A partir de la revisión 111223, Datacomsys cuenta con la posibilidad de obtención del COT de manera automática, en forma similar a como se obtiene el CAE para una factura electrónica.
A tales efectos, se deben realizar ciertas instalaciones, parametrizaciones y validaciones, y comprender ciertos conceptos que el presente documento intentara explicar.
Diferencias entre la obtención del CAE de facturación y el COT del remito.
La factura electrónica es una factura, a partir que afip otorga el CAE.
El numero COT se obtiene sobre un remito que ya esta realizado.
La factura electrónica sin CAE no es valida, en cambio puede haber, bajo ciertas circunstancias, remitos sin COT, por ejemplo los de otra provincia, o los que valorizados estén por debajo de la cota mínima.
O sea, el COT es a nivel Provincial o de Agencia, el CAE de una factura es a nivel nacional.
(Si bien otras provincias están optando por el mismo método de verificación)
La obtención del CAE requiere de ciertos pasos de habilitación y certificación en AFIP, el COT solo requiere de un usuario y contraseña obtenidos en la Web de ARBA.
La factura con CAE se llama Factura electrónica, al remito con COT lo llaman Remito electrónico, pero en realidad mas que remito electrónico es un remito autorizado electrónicamente.
El numero CAE es único para cada comprobante, el numero COT puede ser el mismo para un lote de remitos.
Que tipos de remitos Datacomsys pueden ser informados:
Los remitos por venta (VTA), los remitos por consignación a clientes (CSG), los remitos por devoluciones a proveedores (DEV), los remitos por envío de Fasón (FSN) y los remitos por transferencias entre depósitos (TRF).
No esta previsto para los tipos de remitos manuales (MAN), las ordenes de entrega asociadas a los contado (OEN) y los remitos por uso interno (USO).
Que tablas Datacomsys hay que tener parametrizadas correctamente.
Catalogo de provincias:
Tener bien parametrizado los datos de código ARBA y código RNPA.
Catalogo unidades de medida:
Tener bien parametrizado los datos de código ARBA
Catalogo de productos:
Tener bien parametrizado los códigos en el campo “Nomenclador”
(Tener en cuenta que no es un código particular para cada producto singular, sino que según la codificación de Arba, es muy posible que todo un rubro lleve el mismo código)
Transportes:
Tener bien parametrizado el cuit del transporte y la patente del mismo.
Sucursales, clientes, proveedores:
Tener correctamente indicados los domicilios, localidades, códigos postales y códigos de provincia.
Los códigos ARBA pueden ser obtenidos del siguiente link :
http://www.arba.gov.ar/bajadas/Fiscalizacion/Operativos/TransporteBienes/Documentacion/20110818-TB-Tablas%20de%20validacion.pdf
Que tramitación se debe hacer en ARBA:
Se debe obtener una clave de acceso y password, según lo que se explica en : www.rentas.gba.gov.ar
Ingresos brutos
Código de operaciones de traslado (COT)
Clave de transporte
Instalación en cada maquina que solicitara el COT:
Se debe instalar la interfase phytom que se obtiene desde el link :
http://www.datacomsys.com.ar/bkps/xpws/electronicas/pythom/201111/instalador-COT-1.01c-full.exe
En la ubicación c:\COT, y siendo esta instalación realizada por nosotros y con un costo adicional.
Debe existir la carpeta c:\datacomsys\cot, donde ser guardarán los distintos archivos de transferencia entre Datacomsys y ARBA.
Parametrizacion de punto de venta:
Se debe acceder a Parámetros, menú superior Parámetros, marcando el punto de venta que se desea habilitar y clickeando en (Parámetros), se debe verificar que este bien parametrizado domicilio, localidad, código postal y provincia.
Habiendo marcado la sucursal que se desea habilitar, se debe clickear en (Impresoras), y luego acceder a la solapa “Remito Electrónico”
En el campo con rotulo “Servidor autentificación”, se debe ingresar:
https://cot.ec.gba.gov.ar/TransporteBienes/SeguridadCliente/presentarRemitos.do
Usuario y contraseña deben ser aquellos tramitados en la Web de ARBA, como se explico anteriormente.
Que se informa y de donde se obtiene:
En función de lo que se menciono en “Generalidades”, los datos que se informan por cada tipo de remito son los siguientes:
VTA Remito de venta:
Obtiene Cuit destino, razón social, domicilio, código postal, localidad y provincia del legajo del cliente.
Si el cliente es consumidor final, asume que es el tenedor final.
Asume que se envían productos terminados.
Asume que el solicitante del COT es el emisor del remito.
CSG Remito por consignación:
Obtiene Cuit destino, razón social, domicilio, código postal, localidad y provincia del legajo del cliente.
Si el cliente es consumidor final, asume que es el tenedor final.
Asume que se envían productos terminados.
Asume que el solicitante es el emisor del remito.
DEV Remito por devolución:
Obtiene Cuit destino, razón social, domicilio, código postal, localidad y provincia del legajo del proveedor asociado, obligatoriamente se debe informar que los productos NO son terminados por mas que lo estén.
Asume que el solicitante del COT es el emisor del remito.
FSN Remito por fason :
Obtiene Cuit destino, razón social, domicilio, código postal, localidad y provincia del legajo del proveedor asociado, obligatoriamente se debe informar que los productos NO son terminados.
Asume que el solicitante del COT es el emisor del remito.
TRS Remito por transferencia entre depósitos:
El cuit de destino es similar al cuit emisor.
Domicilio, código postal, localidad y provincia de destino se obtienen del depósito receptor.
Asume obligatoriamente que se trata de productos NO terminados por mas que lo estén.
Asume que el solicitante del COT es el destinatario de la mercadería.
Otros datos generales que se informan:
Cuit del emisor del remito, fecha y hora de comienzo del traslado de la mercadería, dirección, localidad, código postal y provincia del punto de venta emisor del remito u orden de carga, cuit y chapa patente del transportista asociado a la orden de carga o remito, código ARBA de los productos informados, código propio, descripción, cantidad remitida, e importe total del remito.
Utilización:
Puede utilizarse de dos maneras, obteniendo el numero COT remito por remito, o bien mediante la utilización de una Orden de carga, en este ultimo caso, el numero COT obtenido es el mismo para la orden de carga y los respectivos remitos que la componen.
Sugerimos que la obtención del COT se realice a través de una orden de carga, debiendo estar la misma con el estado “C” cerrada.
En ambos casos, al obtener el cot desde un remito o bien desde una orden de carga, se genera en la dirección c:\datacomsys\cot, un archivo de transferencia con la estructura que se referencia en “Generalidades” y que tiene como nombre la siguiente estructura:
TB_{cuit emisor}_001001_{año mes dia}_{últimos seis dígitos de la OCG o RTO}.TXT
Este archivo es el que se utiliza, automáticamente, para la obtención del cot.
Este archivo no se destruye con la obtención del COT, sino que queda guardado en la dirección referenciada.
Mas detalles sobre este archivo de transferencia, se pueden consultar en el siguiente link: http://www.arba.gov.ar/bajadas/Fiscalizacion/Operativos/TransporteBienes/Documentacion/20110818-TB-RemitoElectronicoAplicacionCliente.pdf
Obtener el número COT desde un remito:
Para obtener el numero COT desde un remito emitido, se debe acceder al acceso AFIP, ingresando con el numero de sucursal acorde a los remitos emitidos y a declarar, y clickear en el botón (COT ARBA).
Una vez accedido, se despliegan los remitos ordenados inversamente, se debe localizar el remito a obtener el COT y clickear en (Obtener COT).
Si no hay errores, se genera el mencionado archivo de transferencia con los datos del remito en particular, se lo envía para su autorización, y se obtiene automáticamente el numero COT que quedará asociado al remito y se podrá visualizar en la consulta del mismo, así como en la grilla de remitos en las columnas COT numero y COT integridad.
Obtener el numero COT desde una orden de carga.
Para obtener el numero COT desde una orden de carga, se debe acceder al acceso DESPACHO, (ordenes de carga), y localizar la orden de carga a autorizar, la que debe estar con estado “C”cerrada.
Una vez localizada la orden de carga, se deberá clickear en (Obtener COT)
Si no hay errores, se genera el archivo de transferencia con los datos de los remitos incorporados en la orden de carga, se lo envía para su autorización, y se obtiene automáticamente el numero COT que quedará asociado a la orden de carga y a todos sus remitos, pudiendo ser consultado tanto en la consulta de ordenes de carga como en cada remito en particular.
Validaciones Datacomsys que se realizan antes de solicitar el COT:
Que este parametrizado el servidor de autentificación en el legajo de la sucursal solicitante.
Que el o los remitos asociados a la orden de carga de origen no tengan número de cot asignado anteriormente.
Que el o los remitos asociados a la orden de carga de origen sean de los tipos de remitos validos para la obtención del COT
Validaciones que realiza ARBA con el archivo de transferencia informado:
Los posibles errores que encuentre ARBA se desplegaran al momento de solicitar el COTS, e igualmente se pueden visualizar desde el acceso Parámetros, menú superior parámetros, opción Motivos de rechazo COT.
Mayores detalles solicitarlos a informes@carlosherrero.com.ar o bien visitando www.datacomsys.com.ar / www.datacomsys.blogspot.com
Ch 16-12-2011
Datacomsys 7.4 / 8.0 Revision 111223
Modificaciones importantes en Datacomsys Revisión 111223
Títulos correspondientes a modificaciones y agregados realizados para esta revisión.
Aplicado a todas las versiones (7.4 / 8.0):
Informe de valores emitidos
Alarma por cambios de precios
Fraccionamientos dinámicos
Ordenes de compra nacionales en moneda extranjera
Clave de Operaciones de transporte (COT)
IMPORTANTE: Facturación electrónica, error de certificados:
En las instalaciones Datacomsys que están utilizando la facilidad de facturación electrónica, A,B y E, se esta presentando un error con cierta periodicidad que imposibilita la obtención del cae.
El mensaje de error dice textualmente:
“El CEE ya posee un TA valido para el acceso al WSN solicitado”
Este mensaje, que envía afip, básicamente quiere decir que el cuit informante, o sea, quien esta intentando emitir la factura (CEE), ya esta habilitado(TA) para la utilización del servicio(WSN) de obtención del CAE.
En definitiva, que no hace falta que se presente de nuevo con su certificado.
Cuando explicamos en su momento el procedimiento de facturación electrónica por Internet, comentamos que constaba de dos pasos, el primero era la presentación del certificado en una especie de ventanilla electrónica, lo que nos habilitaba para presentar, en otra ventanilla electrónica, el comprobante que se quiere autorizar y así obtener el cae.
Para acelerar los tiempos de obtención del cae, afip brinda la posibilidad que la presentación del certificado, en la primer ventanilla, se pueda hacer cada veinticuatro horas, de esa manera se presentaría una sola vez y luego durante esas veinticuatro horas se puede solicitar directamente la obtención del CAE para uno o mas comprobantes, en la segunda ventanilla.
El mensaje de error que mencionamos, nos dice de una manera no muy amigable, que no hace falta que nos presentemos en la primer ventanilla por cada comprobante que emitimos.
Esta posibilidad va a estar disponible en Datacomsys, para la versión del mes de enero 2012.
Detalles correspondientes a modificaciones y agregados realizados para esta versión
Todas las versiones (7.4 / 8.0):
Informe de valores emitidos:
Se ha agregado al menú de informes del modulo de ingresos y egresos, uno nuevo que permite emitir uno desplegando los distintos valores emitidos, el uso es similar al ya existente que informa valores en cartera.
Alarma por cambios de precios:
Se ha agregado una nueva alarma Data-Agent que permite enviar un email, a varios usuarios, informando que hubo cambios de precios o costos de productos de venta.
Fraccionamientos dinámicos:
El modulo de fraccionamiento que se encuentra en el acceso de Producción, cuenta con una nueva posibilidad que denominamos fraccionamientos dinámicos.
Lo dinámico resulta precisamente por no tener que cargar obligatoriamente los resultados de todos los subproductos asociados a un método, sino que bien pueden algunos ignorarse y otros no.
Esta posibilidad se define precisamente en cada método de fraccionamiento.
Otra particularidad es que los productos terminados calculan su óptimo en base a un factor, y que el desperdicio o ganancia se aplica al insumo, siendo que actualmente se aplican al producto terminado.
En caso de ser necesario, y a solicitud, se envía un documento específico para este tema en particular.
Ordenes de compra nacionales en moneda extranjera:
A partir de esta revisión se pueden emitir órdenes de compra en moneda extranjera, anteriormente esta posibilidad estaba restringida a que en el legajo del proveedor se le haya definido un país distinto que 0-Argentina.
Con esta nueva posibilidad, al indicar una moneda distinta que 1-Pesos, la actividad se comporta de manera similar que si se trabajara con un proveedor del exterior.
Clave de Operaciones de transporte (COT) :
Disposición normativa Serie B numero 32/06
http://www.arba.gov.ar/Intranet/Legislacion/Normas/Disposiciones/2006/DispB/B032-06.htm
La normativa de referencia establece, bajo ciertas condiciones, que para el traslado de mercadería, y estando el domicilio emisor del remito dentro de la Provincia de Buenos Aires, se debe tramitar un numero de autorización que se denomina COT.
A partir de esta versión se puede obtener dicho numero de autorización en forma automática, de forma similar a como se tramita el CAE de una factura electrónica.
Esto se logra a través de una interfase desarrollada por terceros, y que deberá ser instalada en cada una de las maquinas que tramiten el COT.
El procedimiento esta disponible para se efectuado remito por remito, o bien a través de una orden de carga.
En caso de solicitarse, se envía un documento especial sobre este tema.
Mas información sobre COT en http://www.rentas.gba.gov.ar/, ingresos brutos, código de operaciones de traslado.
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 23-12-2011
Títulos correspondientes a modificaciones y agregados realizados para esta revisión.
Aplicado a todas las versiones (7.4 / 8.0):
Informe de valores emitidos
Alarma por cambios de precios
Fraccionamientos dinámicos
Ordenes de compra nacionales en moneda extranjera
Clave de Operaciones de transporte (COT)
IMPORTANTE: Facturación electrónica, error de certificados:
En las instalaciones Datacomsys que están utilizando la facilidad de facturación electrónica, A,B y E, se esta presentando un error con cierta periodicidad que imposibilita la obtención del cae.
El mensaje de error dice textualmente:
“El CEE ya posee un TA valido para el acceso al WSN solicitado”
Este mensaje, que envía afip, básicamente quiere decir que el cuit informante, o sea, quien esta intentando emitir la factura (CEE), ya esta habilitado(TA) para la utilización del servicio(WSN) de obtención del CAE.
En definitiva, que no hace falta que se presente de nuevo con su certificado.
Cuando explicamos en su momento el procedimiento de facturación electrónica por Internet, comentamos que constaba de dos pasos, el primero era la presentación del certificado en una especie de ventanilla electrónica, lo que nos habilitaba para presentar, en otra ventanilla electrónica, el comprobante que se quiere autorizar y así obtener el cae.
Para acelerar los tiempos de obtención del cae, afip brinda la posibilidad que la presentación del certificado, en la primer ventanilla, se pueda hacer cada veinticuatro horas, de esa manera se presentaría una sola vez y luego durante esas veinticuatro horas se puede solicitar directamente la obtención del CAE para uno o mas comprobantes, en la segunda ventanilla.
El mensaje de error que mencionamos, nos dice de una manera no muy amigable, que no hace falta que nos presentemos en la primer ventanilla por cada comprobante que emitimos.
Esta posibilidad va a estar disponible en Datacomsys, para la versión del mes de enero 2012.
Detalles correspondientes a modificaciones y agregados realizados para esta versión
Todas las versiones (7.4 / 8.0):
Informe de valores emitidos:
Se ha agregado al menú de informes del modulo de ingresos y egresos, uno nuevo que permite emitir uno desplegando los distintos valores emitidos, el uso es similar al ya existente que informa valores en cartera.
Alarma por cambios de precios:
Se ha agregado una nueva alarma Data-Agent que permite enviar un email, a varios usuarios, informando que hubo cambios de precios o costos de productos de venta.
Fraccionamientos dinámicos:
El modulo de fraccionamiento que se encuentra en el acceso de Producción, cuenta con una nueva posibilidad que denominamos fraccionamientos dinámicos.
Lo dinámico resulta precisamente por no tener que cargar obligatoriamente los resultados de todos los subproductos asociados a un método, sino que bien pueden algunos ignorarse y otros no.
Esta posibilidad se define precisamente en cada método de fraccionamiento.
Otra particularidad es que los productos terminados calculan su óptimo en base a un factor, y que el desperdicio o ganancia se aplica al insumo, siendo que actualmente se aplican al producto terminado.
En caso de ser necesario, y a solicitud, se envía un documento específico para este tema en particular.
Ordenes de compra nacionales en moneda extranjera:
A partir de esta revisión se pueden emitir órdenes de compra en moneda extranjera, anteriormente esta posibilidad estaba restringida a que en el legajo del proveedor se le haya definido un país distinto que 0-Argentina.
Con esta nueva posibilidad, al indicar una moneda distinta que 1-Pesos, la actividad se comporta de manera similar que si se trabajara con un proveedor del exterior.
Clave de Operaciones de transporte (COT) :
Disposición normativa Serie B numero 32/06
http://www.arba.gov.ar/Intranet/Legislacion/Normas/Disposiciones/2006/DispB/B032-06.htm
La normativa de referencia establece, bajo ciertas condiciones, que para el traslado de mercadería, y estando el domicilio emisor del remito dentro de la Provincia de Buenos Aires, se debe tramitar un numero de autorización que se denomina COT.
A partir de esta versión se puede obtener dicho numero de autorización en forma automática, de forma similar a como se tramita el CAE de una factura electrónica.
Esto se logra a través de una interfase desarrollada por terceros, y que deberá ser instalada en cada una de las maquinas que tramiten el COT.
El procedimiento esta disponible para se efectuado remito por remito, o bien a través de una orden de carga.
En caso de solicitarse, se envía un documento especial sobre este tema.
Mas información sobre COT en http://www.rentas.gba.gov.ar/, ingresos brutos, código de operaciones de traslado.
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 23-12-2011
viernes, 27 de mayo de 2011
Costo de ultima compra
Ordenes de compra en distinta moneda que la correspondiente al costo del producto
Detalle:
Se ha detectado un error que se produce al realizar una orden de compra, expresada por ejemplo en pesos; conteniendo productos costeados por ejemplo en dólares.
El error se visualiza en la forma de archivar lo que el sistema denomina como “costo de última compra”.
Datacomsys mantiene, para cada producto y lista de precios, la posibilidad de indicar la moneda en la que se expresa el costo.
En casos en que el producto se compra a un proveedor del exterior, la orden de compra solicita la moneda y la cotización, debiendo dicha moneda ser coincidente con la que se expresa como moneda de costo para cada uno de los productos; pero puede darse que en el legajo del producto y lista de precios, el costo se expresa por ejemplo en dólares, y la orden de compra se realiza a un proveedor de plaza, que por comodidad cotiza en dólares.
En este último caso, el costo de última compra queda archivado en forma errónea.
Explicación:
Al momento de hacer una orden de compra, el costo sugerido es el costo de reposición pesificado según la moneda que se haya indicado, en caso de ser pesos no habrá cálculo, pero en caso de ser otra moneda dicho costo se pesificara utilizando la cotización de la fecha.
Ahora bien, para guardar el costo de ultima compra se realiza el proceso inverso, el costo que se haya sugerido y aceptado, o bien modificado por otro nuevo, se vuelve a la moneda de costo utilizando la cotización indicada en la orden de compra, pero si la orden de compra es en plaza no hay cotización, la cotización será 1.000, o sea, guardará como costo de ultima compra el pesificado, ocasionando el error en los informes de valuación de inventario a costo de ultima compra, ya que dicho informe lo pesificará nuevamente.
Ejemplo:
Producto X, moneda de costo dólares, costo 1.06, cotización dólar en sistema 4.05, cotización dólar en orden de compra 1.0000
Al hacer la orden de compra en plaza, se desplegara como costo (1.06 * 4.05) = 4.293, que es correcto.
Al guardar el costo de ultima compra se calculara (4.293 / 1.000) = 4.293, lo que NO es correcto.
Solución:
A partir de la versión 110624 (24-06-2011), la orden de compra, por mas que sea realizada a un proveedor en plaza, solicitará moneda y cotización, de manera que aquellos proveedores cuyos costos son mantenidos en el sistema en otra moneda que pesos, se les pueda hacer una orden de compra indicando la moneda de origen.
Según el ejemplo anterior, se procedería así:
Producto X, moneda de costo dólares, costo 1.06, cotización dólar en sistema 4.05, cotización dólar en orden de compra 4.05
Al hacer la orden de compra en plaza, se podrá modificar la moneda y la cotización correspondiente, entonces se desplegará como costo (1.06 * 4.05) = 4.293, que es correcto.
Al guardar el costo de ultima compra se calculara (4.293 / 4.05) = 1.06, lo que SI es correcto.
Carlos A.L.Herrero
Análisis de Sistemas
Córdoba 93 (B1640GUA) Martínez - Bs.As.
República Argentina
Tel: 4792-2053 15-4473-6865
www.datacomsys.com.ar
www.datacomsys.blogspot.com
Detalle:
Se ha detectado un error que se produce al realizar una orden de compra, expresada por ejemplo en pesos; conteniendo productos costeados por ejemplo en dólares.
El error se visualiza en la forma de archivar lo que el sistema denomina como “costo de última compra”.
Datacomsys mantiene, para cada producto y lista de precios, la posibilidad de indicar la moneda en la que se expresa el costo.
En casos en que el producto se compra a un proveedor del exterior, la orden de compra solicita la moneda y la cotización, debiendo dicha moneda ser coincidente con la que se expresa como moneda de costo para cada uno de los productos; pero puede darse que en el legajo del producto y lista de precios, el costo se expresa por ejemplo en dólares, y la orden de compra se realiza a un proveedor de plaza, que por comodidad cotiza en dólares.
En este último caso, el costo de última compra queda archivado en forma errónea.
Explicación:
Al momento de hacer una orden de compra, el costo sugerido es el costo de reposición pesificado según la moneda que se haya indicado, en caso de ser pesos no habrá cálculo, pero en caso de ser otra moneda dicho costo se pesificara utilizando la cotización de la fecha.
Ahora bien, para guardar el costo de ultima compra se realiza el proceso inverso, el costo que se haya sugerido y aceptado, o bien modificado por otro nuevo, se vuelve a la moneda de costo utilizando la cotización indicada en la orden de compra, pero si la orden de compra es en plaza no hay cotización, la cotización será 1.000, o sea, guardará como costo de ultima compra el pesificado, ocasionando el error en los informes de valuación de inventario a costo de ultima compra, ya que dicho informe lo pesificará nuevamente.
Ejemplo:
Producto X, moneda de costo dólares, costo 1.06, cotización dólar en sistema 4.05, cotización dólar en orden de compra 1.0000
Al hacer la orden de compra en plaza, se desplegara como costo (1.06 * 4.05) = 4.293, que es correcto.
Al guardar el costo de ultima compra se calculara (4.293 / 1.000) = 4.293, lo que NO es correcto.
Solución:
A partir de la versión 110624 (24-06-2011), la orden de compra, por mas que sea realizada a un proveedor en plaza, solicitará moneda y cotización, de manera que aquellos proveedores cuyos costos son mantenidos en el sistema en otra moneda que pesos, se les pueda hacer una orden de compra indicando la moneda de origen.
Según el ejemplo anterior, se procedería así:
Producto X, moneda de costo dólares, costo 1.06, cotización dólar en sistema 4.05, cotización dólar en orden de compra 4.05
Al hacer la orden de compra en plaza, se podrá modificar la moneda y la cotización correspondiente, entonces se desplegará como costo (1.06 * 4.05) = 4.293, que es correcto.
Al guardar el costo de ultima compra se calculara (4.293 / 4.05) = 1.06, lo que SI es correcto.
Carlos A.L.Herrero
Análisis de Sistemas
Córdoba 93 (B1640GUA) Martínez - Bs.As.
República Argentina
Tel: 4792-2053 15-4473-6865
www.datacomsys.com.ar
www.datacomsys.blogspot.com
miércoles, 25 de mayo de 2011
Datacomsys version 110520
Modificaciones importantes en Datacomsys 7.4 Versión 110520
Títulos correspondientes a modificaciones y agregados realizados para esta versión.
Ventas
Facturación electrónica
Adaptación a webservices facturación electrónica versión 1.
Topes de crédito
Actualización automática evaluando volumen de venta.
Compras
Trabajar órdenes de compra pendientes
Explosión por código de producto.
Ingresos y egresos
Conciliaciones bancarias
Comparación de resumen Excel emitido por el banco, contra el sistema.
Afip
Trabajar cuits vencidos
Actualización automática de fecha de vencimiento.
Arciba
Incorporación en registro exportación, de retenciones hechas a proveedores.
Administracion de personal
Liquidaciones
Posibilidad de incorporar un texto, manualmente, en un recibo.
Detalles correspondientes a modificaciones y agregados realizados para esta versión
Adaptación a webservices facturación electrónica versión 1
Según se informó en un documento especifico, a partir del día 01-07-2011 y a nuestro entender, afip cambia el método de obtención del CAE para comprobantes electrónicos.
A partir de la versión 110520 el sistema esta adaptado para esta nueva modalidad.
La instalación de esta modificación NO es automática, tratándose de un tema impositivo y notificado por afip en una resolución especifica, la instalación de esta modificación debe ser solicitada por cada instalación.
Nuevamente sugerimos que cada responsable contacte a su respectivo estudio contable para conocer mas detalles, y tomar una decisión respecto a la instalación, en el menor tiempo posible.
Actualización automática de topes de crédito, evaluando volumen de venta
Se trata de un proceso automático, que al ejecutarse con cierta periodicidad, tiene le capacidad de evaluar en forma particular para cada instalación, el tope de crédito en cuenta corriente y valores para cada cliente.
Explosión por código de producto en panel trabajar ordenes de compra pendientes
El panel de trabajo de órdenes de compras pendientes, cuanta ahora con un botón inferior que permite explotar dichas ordenes, por código de producto.
Comparación de resumen Excel emitido por el banco contra el sistema
Se trata de un panel de trabajo, que cuenta con diversos controles que permiten incorporar un Excel generado por el banco correspondiente, y que cuente con los datos de movimientos bancarios; para luego compararlo contra el libro de bancos del sistema.
Finalmente se obtiene un panel con aquellos movimientos que no se han encontrado en el libro de bancos comparado.
Actualización automática de fecha de vencimiento de cuits clientes y proveedores
El panel de trabajo de cuits vencidos, al que se accede por el modulo de afip, cuenta con dos botones específicos que permiten cambiar, en forma automática, las fechas de vencimientos de cuits en legajos de clientes y proveedores, postergándolos a 180 días posteriores.
El procedimiento advierte sobre el riesgo jurídico que ocasiona postergar dicho vencimiento, ya que permitiría comerciar con un cliente o proveedor que no este en condiciones de hacerlo, según su condición en afip.
Incorporación en registro arciba de retenciones hechas a proveedores
El panel de trabajo Arciba, al que se accede desde el modulo afip, cuenta ahora con la posibilidad de incorporar en el registro de migración, a las retenciones que se han realizado en pagos a proveedores, correspondientes a la jurisdicción de C.A.B.A.
Posibilidad de incorporar un texto aleatorio en un recibo de sueldos
A efectos de poder agregar un texto manual y único en un recibo de sueldos, el procedimiento de modificación de liquidaciones cuenta con el agregado de un campo especial.
La impresión de dicho campo en el recibo correspondiente, deberá ser solicitada particularmente.
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 20-05-2011
Títulos correspondientes a modificaciones y agregados realizados para esta versión.
Ventas
Facturación electrónica
Adaptación a webservices facturación electrónica versión 1.
Topes de crédito
Actualización automática evaluando volumen de venta.
Compras
Trabajar órdenes de compra pendientes
Explosión por código de producto.
Ingresos y egresos
Conciliaciones bancarias
Comparación de resumen Excel emitido por el banco, contra el sistema.
Afip
Trabajar cuits vencidos
Actualización automática de fecha de vencimiento.
Arciba
Incorporación en registro exportación, de retenciones hechas a proveedores.
Administracion de personal
Liquidaciones
Posibilidad de incorporar un texto, manualmente, en un recibo.
Detalles correspondientes a modificaciones y agregados realizados para esta versión
Adaptación a webservices facturación electrónica versión 1
Según se informó en un documento especifico, a partir del día 01-07-2011 y a nuestro entender, afip cambia el método de obtención del CAE para comprobantes electrónicos.
A partir de la versión 110520 el sistema esta adaptado para esta nueva modalidad.
La instalación de esta modificación NO es automática, tratándose de un tema impositivo y notificado por afip en una resolución especifica, la instalación de esta modificación debe ser solicitada por cada instalación.
Nuevamente sugerimos que cada responsable contacte a su respectivo estudio contable para conocer mas detalles, y tomar una decisión respecto a la instalación, en el menor tiempo posible.
Actualización automática de topes de crédito, evaluando volumen de venta
Se trata de un proceso automático, que al ejecutarse con cierta periodicidad, tiene le capacidad de evaluar en forma particular para cada instalación, el tope de crédito en cuenta corriente y valores para cada cliente.
Explosión por código de producto en panel trabajar ordenes de compra pendientes
El panel de trabajo de órdenes de compras pendientes, cuanta ahora con un botón inferior que permite explotar dichas ordenes, por código de producto.
Comparación de resumen Excel emitido por el banco contra el sistema
Se trata de un panel de trabajo, que cuenta con diversos controles que permiten incorporar un Excel generado por el banco correspondiente, y que cuente con los datos de movimientos bancarios; para luego compararlo contra el libro de bancos del sistema.
Finalmente se obtiene un panel con aquellos movimientos que no se han encontrado en el libro de bancos comparado.
Actualización automática de fecha de vencimiento de cuits clientes y proveedores
El panel de trabajo de cuits vencidos, al que se accede por el modulo de afip, cuenta con dos botones específicos que permiten cambiar, en forma automática, las fechas de vencimientos de cuits en legajos de clientes y proveedores, postergándolos a 180 días posteriores.
El procedimiento advierte sobre el riesgo jurídico que ocasiona postergar dicho vencimiento, ya que permitiría comerciar con un cliente o proveedor que no este en condiciones de hacerlo, según su condición en afip.
Incorporación en registro arciba de retenciones hechas a proveedores
El panel de trabajo Arciba, al que se accede desde el modulo afip, cuenta ahora con la posibilidad de incorporar en el registro de migración, a las retenciones que se han realizado en pagos a proveedores, correspondientes a la jurisdicción de C.A.B.A.
Posibilidad de incorporar un texto aleatorio en un recibo de sueldos
A efectos de poder agregar un texto manual y único en un recibo de sueldos, el procedimiento de modificación de liquidaciones cuenta con el agregado de un campo especial.
La impresión de dicho campo en el recibo correspondiente, deberá ser solicitada particularmente.
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 20-05-2011
jueves, 3 de marzo de 2011
Datacomsys version 110225
Modificaciones importantes en Datacomsys 7.4 Versión 110225
Títulos correspondientes a modificaciones y agregados realizados para esta versión.
Comisiones por venta
Políticas de cálculo
Posibilidad de liquidar comisiones por un monto fijo
Inventario
Marbetes
Inicialización de marbetes
Posibilidad de inicializar marbetes para un solo punto de venta
Stock
Definición de rubros
Habilitaciones
Posibilidad de deshabilitar un rubro solamente para la venta
Ventas
Clientes
Legajo del cliente
Tilde para permitir o impedir el envió de SMS al celular del cliente
Incidentes
Contactos
Legajo del contacto
Tilde para permitir o impedir el envió de SMS al celular del contacto
Tipos de acciones
Legajos de tipos de acciones
Acción a tomar
Se incorpora una nueva acción a tomar, que emite un SMS.
Administracion de personal
Sicoss
Parámetros sicoss
Se incorpora un tilde para informar al aplicativo Sicoss, si se tiene o no seguro obligatorio.
Detalles correspondientes a modificaciones y agregados realizados para esta versión
Posibilidad de liquidar comisiones por un monto fijo
El módulo de comisiones utiliza políticas definidas para realizar los cálculos correspondientes.
Estas políticas finalmente determinan que porcentaje de comisión se aplicaba; ahora existe la posibilidad que lo que se aplique como comisión no sea un porcentaje sobre el neto del comprobante analizado sino un importe fijo.
Posibilidad de inicializar marbetes para un solo punto de venta
La inicialización de marbetes consiste en el borrado de los marbetes anteriores, a efectos de generar nuevos ante un próximo inventario.
La inicialización anterior eliminaba todos los marbetes que se hayan generado, independientemente del estado en que se encuentren y el punto de venta asociado.
Ante la necesidad de realizar inventarios parciales, se habilita la posibilidad de eliminar los marbetes anteriores de manera selectiva.
Si se ingresa como sucursal administrativa 9999, se eliminan todos los marbetes existentes, en cambio si se ingresa con una sucursal distinta, solamente se eliminan los marbetes de dicha sucursal. Todo esto previa confirmación por parte del operador.
Posibilidad de deshabilitar un rubro solamente para la venta
A la actividad de mantenimiento de códigos de rubros, se le agregó la posibilidad de definición si dicho rubro esta habilitado para la venta o no.
Anteriormente existía un tilde que inhabilitaba el rubro tanto para la venta como para la compra.
Ante la necesidad de tener rubros que por ejemplo contengan productos que no se venden, sean insumos o de uso interno, se agregó esta posibilidad.
Al momento de la instalación, el valor que se tomo por defecto es el que tiene la habilitación anterior.
Tilde para permitir o impedir el envió de SMS al celular del cliente
Siendo el envió de SMS un procedimiento que tiene cierto costo para el que lo recibe, se incorporo un tilde en el legajo del cliente que permite indicar si el mismo acepta o no el envió de SMS automáticos.
El contacto asociado, si es que lo hubiere, al cliente, heredara el valor de dicho tilde.
A la instalación, el valor que se determino automáticamente es No.
Tilde para permitir o impedir el envió de SMS al celular del contacto
Al igual que en el legajo del cliente, se incorpora un tilde que permite indicar si el contacto permite o no la recepción de SMS en su teléfono celular.
A la instalación, el valor que se determino automáticamente es No.
Tipo de acción SMS.
A los tipos de acciones a realizar en un incidente, se le agrega la posibilidad que dicha acción sea el envió de un SMS.
Es importante tener en cuenta que, para que se realice dicho envió, la instalación debe contar con un hardware denominado SMS Gateway, el que obviamente no es provisto por nosotros.
La modificación general de envió de SMS solamente consiste en agregar la posibilidad de administracion del envió del mismo en el sistema; siendo útil este procedimiento para confirmación de servicios terminados, alerta temprana de vencimientos, alarmas internas en general y otros.
Seguro obligatorio en SICOSS
A partir de la declaración jurada del mes de Enero 2011, el seguro obligatorio debe ser informado mediante el aplicativo SIAP / SICOSS.
Para tales efectos se debe indicar mediante un tilde en Administracion de personal, Liquidaciones, Parámetros sicoss, si se tiene o no un seguro obligatorio.
Pareciendo un absurdo, pero puede darse el caso que no se declare un seguro obligatorio.
Este valor se traslada al archivo de transferencia que se utiliza para la declaración automática de liquidaciones en el mencionado aplicativo.
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 25-02-2011
Títulos correspondientes a modificaciones y agregados realizados para esta versión.
Comisiones por venta
Políticas de cálculo
Posibilidad de liquidar comisiones por un monto fijo
Inventario
Marbetes
Inicialización de marbetes
Posibilidad de inicializar marbetes para un solo punto de venta
Stock
Definición de rubros
Habilitaciones
Posibilidad de deshabilitar un rubro solamente para la venta
Ventas
Clientes
Legajo del cliente
Tilde para permitir o impedir el envió de SMS al celular del cliente
Incidentes
Contactos
Legajo del contacto
Tilde para permitir o impedir el envió de SMS al celular del contacto
Tipos de acciones
Legajos de tipos de acciones
Acción a tomar
Se incorpora una nueva acción a tomar, que emite un SMS.
Administracion de personal
Sicoss
Parámetros sicoss
Se incorpora un tilde para informar al aplicativo Sicoss, si se tiene o no seguro obligatorio.
Detalles correspondientes a modificaciones y agregados realizados para esta versión
Posibilidad de liquidar comisiones por un monto fijo
El módulo de comisiones utiliza políticas definidas para realizar los cálculos correspondientes.
Estas políticas finalmente determinan que porcentaje de comisión se aplicaba; ahora existe la posibilidad que lo que se aplique como comisión no sea un porcentaje sobre el neto del comprobante analizado sino un importe fijo.
Posibilidad de inicializar marbetes para un solo punto de venta
La inicialización de marbetes consiste en el borrado de los marbetes anteriores, a efectos de generar nuevos ante un próximo inventario.
La inicialización anterior eliminaba todos los marbetes que se hayan generado, independientemente del estado en que se encuentren y el punto de venta asociado.
Ante la necesidad de realizar inventarios parciales, se habilita la posibilidad de eliminar los marbetes anteriores de manera selectiva.
Si se ingresa como sucursal administrativa 9999, se eliminan todos los marbetes existentes, en cambio si se ingresa con una sucursal distinta, solamente se eliminan los marbetes de dicha sucursal. Todo esto previa confirmación por parte del operador.
Posibilidad de deshabilitar un rubro solamente para la venta
A la actividad de mantenimiento de códigos de rubros, se le agregó la posibilidad de definición si dicho rubro esta habilitado para la venta o no.
Anteriormente existía un tilde que inhabilitaba el rubro tanto para la venta como para la compra.
Ante la necesidad de tener rubros que por ejemplo contengan productos que no se venden, sean insumos o de uso interno, se agregó esta posibilidad.
Al momento de la instalación, el valor que se tomo por defecto es el que tiene la habilitación anterior.
Tilde para permitir o impedir el envió de SMS al celular del cliente
Siendo el envió de SMS un procedimiento que tiene cierto costo para el que lo recibe, se incorporo un tilde en el legajo del cliente que permite indicar si el mismo acepta o no el envió de SMS automáticos.
El contacto asociado, si es que lo hubiere, al cliente, heredara el valor de dicho tilde.
A la instalación, el valor que se determino automáticamente es No.
Tilde para permitir o impedir el envió de SMS al celular del contacto
Al igual que en el legajo del cliente, se incorpora un tilde que permite indicar si el contacto permite o no la recepción de SMS en su teléfono celular.
A la instalación, el valor que se determino automáticamente es No.
Tipo de acción SMS.
A los tipos de acciones a realizar en un incidente, se le agrega la posibilidad que dicha acción sea el envió de un SMS.
Es importante tener en cuenta que, para que se realice dicho envió, la instalación debe contar con un hardware denominado SMS Gateway, el que obviamente no es provisto por nosotros.
La modificación general de envió de SMS solamente consiste en agregar la posibilidad de administracion del envió del mismo en el sistema; siendo útil este procedimiento para confirmación de servicios terminados, alerta temprana de vencimientos, alarmas internas en general y otros.
Seguro obligatorio en SICOSS
A partir de la declaración jurada del mes de Enero 2011, el seguro obligatorio debe ser informado mediante el aplicativo SIAP / SICOSS.
Para tales efectos se debe indicar mediante un tilde en Administracion de personal, Liquidaciones, Parámetros sicoss, si se tiene o no un seguro obligatorio.
Pareciendo un absurdo, pero puede darse el caso que no se declare un seguro obligatorio.
Este valor se traslada al archivo de transferencia que se utiliza para la declaración automática de liquidaciones en el mencionado aplicativo.
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 25-02-2011
Suscribirse a:
Entradas (Atom)
