Administracion de personal
Procedimiento para Liquidación de vacaciones
Generalidades:
El sistema mantiene los días de vacaciones que correspondan en forma de cuenta corriente.
Dicha cuenta corriente se genera en base a la cantidad de días que el empleado tiene asignados según su antigüedad y convenio, a los que se le aplica los días que se va tomando en base a las liquidaciones de vacaciones realizadas.
A tales efectos existe un procedimiento de mantenimiento de datos parametrizados, referentes a los convenios y la cantidad de días por año trabajado, así como la información al sistema de los días que efectivamente el empleado se toma.
Luego, la liquidación de vacaciones, mediante un concepto con una formula especial, se encarga de incorporar estos días en la liquidación, para que finalmente al confirmarla, se descuenten efectivamente estos días de la cuenta corriente por vacaciones del empleado.
Este documento se complementa con el que corresponde a Incidentes en general, ya que el sistema toma a las vacaciones como un incidente mas.
Parametrizacion inicial:
Definir la cantidad de días por año trabajado según convenio
Para poder establecer la cantidad de días que un empleado tiene asignados según su antigüedad, es necesario establecer los parámetros correspondientes a la relación de convenio y días trabajados.
A tales efectos, se deben incorporar estos datos accediendo por (Personal), botón lateral (Convenios), seleccionar el convenio que se quiere definir y clickear en (días / Vacaciones).
En esta actividad se debe definir: Año desde, Año hasta, y cantidad de días.
Ejemplo para Empleados de comercio:
1 a 4 años, corresponde 14 días
5 a 9 años, corresponden 21 días
10 a 19 años, corresponden 28 días
20 a 99 años, corresponden 35 días
Atención: para cualquier convenio el sistema adopta como año completo al legajo con fecha de apertura entre el primero de enero y el treinta de junio, para ingresos posteriores se asume un día por cada veinte trabajados.
Cálculo automático de días según convenio y años trabajados
Este proceso permite calcular en base a la fecha de ingreso en el legajo, y una fecha base o de cálculo, la cantidad de días que corresponden por vacaciones.
El cálculo obtenido se incorpora como movimiento en la cuenta corriente de vacaciones asociada al legajo.
Para utilizar este proceso, se accede por (Personal), botón superior (Vacaciones) y luego botón central (Calculo por convenio).
Una vez ingresado se debe indicar la fecha de calculo, ejemplo 31-12-2010, y si calcula para todos los legajos activos o no.
Al confirmar se procederá a evaluar en función de la fecha de ingreso en el legajo, y el convenio asociado, la cantidad de días que le corresponden al empleado.
El cálculo obtenido se incorporará como movimiento en la cuenta corriente por vacaciones de cada legajo.
Se lo visualizara como un Debito, por la cantidad de días que corresponda, y con leyenda “Calculo automático vacaciones base: DD/MM/AAAA.
En casos especiales donde esta relación entre convenio y años de trabajo no se respeta, por ejemplo por reconocimiento de antigüedad en empleos anteriores, se deberá proceder a realizar un ajuste manual en la cuenta corriente de vacaciones relacionada.
Tipo de incidente para vacaciones:
Para que el procedimiento de cálculo obtenga los días de vacaciones que un empleado se toma, es necesario indicar estos días en forma de incidente.
Cada incidente tiene asociado un tipo, por lo que se debe definir un tipo de incidente especial para esta operatoria.
Los tipos de incidentes se definen desde (Personal), botón superior (Incidentes), botón lateral (Tipos incidentes).
Una vez accedidos a la aplicación se le deberá dar un código y diversos datos según este ejemplo:
Código : LVAC
Descripción: Licencia por vacaciones
Tildar en “Queda pendiente de liquidar y se liquida como”
Tipo de liquidación asociada: 5-Liquidación de vacaciones
Tildar en “Modifica situación de revista como”
Situación de revista 12-Licencia vacaciones
Tildar en “Implica ausencia”
Tildar en “Requiere cerrar el incidente”
Tildar en “Evalúa cantidad de días contra cuenta corriente vacaciones”
Rango máximo en días: 35
Una vez confirmado el tipo de incidente, el mismo esta disponible para ser utilizado y liquidado.
Concepto de liquidación especial:
Para que la cantidad de días incidentados sean evaluada en una liquidación, se debe dar de alta un concepto especial.
Dicho concepto se da de alta desde (Conceptos) y luego (Nuevo concepto)
Una vez en la actividad se debe dar de alta un concepto especial según el siguiente ejemplo:
Código 000089
Tildar en “Habilitado”
Descripción: VACACIONES
Tipo: H-haber
Se utiliza como: A-Concepto fijo o novedad
Tildar en “Se le aplican descuentos”
Formula:
La formula utiliza la palabra clave INCIDE, que se utiliza para realizar la evaluación de un incidente dado, en este caso vacaciones; así como otros argumentos para obtener el sueldo del empleado.
Básicamente para una empresa que utiliza escalafones la formula podría ser:
( ( ( ESCALA;”JF”;CATEGO ) / 25 ) * INCIDE;LICVAC;ULT )
O expresado en forma textual:
( ( ( Escalafón JF evaluado por categoría en legajo) / 25 ) * Cantidad de días ultima Licencia por vacaciones )
De esta manera el proceso de liquidación obtendría la cantidad de días localizando en los incidentes del legajo, el último con tipo de incidente LICVAC, dentro del rango de fechas definidas como Periodo de la liquidación .
Procedimiento de liquidación :
Generar el incidente de vacaciones
Antes de proceder a la liquidación de vacaciones se debe generar el incidente que, en definitiva, indicará al sistema la cantidad de días que el empleado se toma.
Los días indicados en el incidente se validarán contra el saldo de la cuenta corriente de vacaciones asociada al legajo, y contra la cantidad máxima de días corridos que la empresa otorga, esto ultimo definido en el tipo de incidente asociado.
Para proceder a cargar el incidente, se debe acceder desde (Personal), localizando el legajo que se quiere incidentar, y luego clickear en (Incidentes), para finalmente clickear en (Nuevo).
Como tipo de incidente se debe indicar el que corresponda a licencia por vacaciones, LVAC según el ejemplo anteriormente descrito.
Como fecha se debe aceptar la que se sugiere, ya que no tiene relevancia para las vacaciones, siendo solamente la fecha de generación del incidente.
Como fecha de inicio se debe indicar la que corresponda al primer día de vacaciones otorgadas.
Como fecha final se debe indicar la última que corresponda al periodo de vacaciones otorgadas.
La cantidad de días que media entre ambas fechas es validada contra el saldo de la cuenta corriente de vacaciones, así como contra la cantidad máxima de días corridos que la empresa permita.
Luego se pueden indicar datos de referencia o detalle, pero básicamente no son obligatorios para este tipo de incidente, según lo que se parametrizó en el tipo de incidente LVAC.
Al confirmar el incidente, el mismo se numerará y se desplegará en la grilla de incidentes por legajo.
El incidente quedará con estado “Abierto”, y puede ser modificado o anulado hasta que sea incorporado en una liquidación y la misma este en estado “Cerrada”.
Si un incidente es modificado habiendo sido incorporado en una liquidación, esta última deberá ser reprocesada.
Si la liquidación se encuentra en estado 4 o 5 , el incidente ya no podrá ser modificado.
Liquidar el incidente de vacaciones:
Una vez generado el incidente, y teniendo el concepto de liquidación definido como se explico en el ejemplo anterior, bastará incorporarlo como novedad, y proceder a calcular la liquidación para que la cantidad de días que median en el incidente sea tomada como la cantidad de días de vacaciones.
Los incidentes a liquidar se incorporan evaluándolos de manera que sus fechas de inicio y final estén dentro de las fechas definidas como “Periodo inicial” y “Periodo final”, de la definición de la liquidación.
Luego de procesar la liquidación se podrá ver en (Ver liquidación), que el concepto asociado evaluó la formula.
Según el ejemplo anterior, este concepto habrá obtenido el sueldo por el escalafón y luego de dividirlo por 25, lo multiplico por la cantidad de días que median entre la fecha de inicio y final del ultimo incidente LVAC.
Confirmar liquidación de vacaciones:
El procedimiento de confirmación de la liquidación de vacaciones es similar a cualquier otra, lo que si se produce es una actualización en los incidentes de vacaciones asociados, así como en la cuenta corriente de vacaciones por legajo.
En el caso de los incidentes, se verá que el incidente de vacaciones, LVAC en el ejemplo que estamos trabajando, quedará con estado “Cerrado”, y con un número de liquidación asociada.
Una vez en este estado el incidente solo podrá ser consultado.
Para la cuenta corriente de vacaciones, se habrá generado un crédito con la fecha de la liquidación, por la cantidad de días que se hayan liquidado, y con leyenda “Confirmación liquidación nnnnn”, donde nnnnn es el numero de liquidación asociada.
Dicho crédito modificará el saldo de días asociado al legajo.
Ajustes y Nuevo periodo de vacaciones:
Para incrementar el saldo de vacaciones, por ejemplo al cambiar el año, o bien se puede realizar un ajuste manual en la cuenta corriente, o bien correr nuevamente el proceso “Calcular por convenio”, indicando como fecha base la que corresponda al final del nuevo año.
Este proceso calculará nuevamente en función del convenio y fecha de ingreso, e incrementará el saldo de vacaciones en función de los días calculados.
Si se desea hacer el ajuste manual, se procede desde (Personal), localizando el legajo asociado y clickeando en (Vacaciones), para finalmente en (Nuevo registro).
Se solicita la fecha de registro y la cantidad de días que se ajustan, pudiendo ser con signo negativo para el caso de restar días.
Ch 20-09-2010
domingo, 3 de octubre de 2010
Incidentes en legajos empleados
Administracion de personal
Incidentes sobre legajos
Generalidades:
A efectos de poder realizar un control y seguimiento de las distintas situaciones que hacen a un legajo, el sistema permite definir y mantener ciertos datos en forma de incidentes.
Estos incidentes se relacionan al legajo de un empleado y son visualizados en forma de grilla.
Los incidentes se tipifican mediante un código de tipo de incidente, y son numerados en forma automática y secuencial.
Los incidentes sobre legajos no tienen relación alguna con el modulo de incidentes del sistema administrativo.
Parametrizacion inicial:
Tipos de incidentes:
La parametrizacion de los tipos de incidentes permite definir distintos códigos que actúan de una manera u otra, a efectos que, al ingresar el incidente asociado a un legajo, se solicitan ciertos datos y acciones de manera obligatoria.
Para definir los tipos de incidentes se accede desde (Personal), botón superior (Incidentes), y finalmente botón lateral (Tipos incidentes).
Se desplegará un panel de trabajo con todos los tipos de incidentes definidos.
Una vez clickeado en (Nuevo), y ya en la actividad se solicitan diversos datos :
Código : Se refiere al código que identificará al tipo de incidente.
Descripción: Es la descripción del tipo de incidente.
Queda pendiente de liquidar y se liquida como: Es un tilde que internamente actúa por si o por no.
Si el incidente queda pendiente de liquidar, podrá ser utilizado en una liquidación del tipo asociado.
Modifica situación de revista como : Es un tilde que internamente actúa por si o por no.
Si el incidente modifica la situación de revista, podrá ser utilizado desde el panel de trabajo de incidentes para proceder a modificar la situación de revista de un legajo.
Implica ausencia : Es un tilde que internamente actúa por si o por no.
Requiere certificado / Justificación : Es un tilde que internamente actúa por si o por no, y en función de este tilde se solicitará o no cierta información al ingresar o cerrar el incidente.
Requiere visita a domicilio : Es un tilde que internamente actúa por si o por no, y en función de este tilde se solicitara o no cierta información al ingresar o cerrar el incidente.
Requiere cerrar el incidente : Es un tilde por si o por no, y que permitirá dejar al incidente como pendiente de cierre, para un posterior cierre manual o a través de una liquidación, o bien dejará al incidente como cerrado en el mismo ingreso.
Referencia obligatoria : Es un tilde por si o por no, y que permitirá definir si al momento de ingresar un incidente, es obligatorio o no que se ingrese un texto de referencia.
Detalle Obligatorio : Es un tilde por si o por no, y que permitirá definir si al momento de ingresar un incidente, es obligatorio o no que se ingrese un texto detallando el mismo.
Dar aviso a ART: Es un tilde por si o por no, y que permitirá definir si al momento de ingresar un incidente, es obligatorio o no que se ingresen los datos asociados a la ART.
Solución obligatoria : Es un tilde por si o por no, y que permitirá definir si al momento de ingresar un incidente, es obligatorio o no que se ingrese un texto en el campo de solución.
Evalúa cantidad de días contra cuenta corriente de vacaciones : Es un tilde por si o por no, y que permite que, al momento de ingresar un incidente, las fechas de inicio y final del mismo sean evaluadas en su cantidad contra el saldo de la cuenta corriente de vacaciones asociada al legajo.
Para una mejor explicación se provee un documento especial para liquidación de vacaciones.
Rango máximo de días : Es la cantidad de días máxima que puede mediar entre la fecha inicial y final de un incidente, y solo a efectos que, al momento de ingresar un incidente, la cantidad de días que media entre la fecha inicial y final, no supere dicho numero.
Como ejemplos de tipos de incidentes, podemos aplicar que :
Un accidente laboral, implica ausencia, no queda pendiente de liquidar, modifica la situación de revista, requiere una visita al domicilio por parte del medico, requiere cerrar el incidente, tiene referencia y detalle obligatorio, se debe dar aviso a la ART y no tiene un rango máximo de días.
Una ausencia con aviso, no queda pendiente de liquidar, no modifica la situación de revista, implica una ausencia, requiere un certificado o justificación, no requiere visita a domicilio, requiere cerrar el incidente, requiere una referencia y detalle, no da aviso a la ART, no requiere de una solución, no evalúa la cantidad de días de vacaciones, y tiene un rango máximo de 1 día.
Una licencia por vacaciones queda pendiente de liquidar, modifica la situación de revista, implica una ausencia, no requiere certificado, no requiere visita a domicilio, requiere cerrar el incidente, no tiene referencia, detalle ni solución, evalúa la cantidad de días contra la cuenta corriente de vacaciones, y tiene un máximo de 35 días.
Y así las distintas combinaciones posibles o necesarias.
Dar de alta un incidente :
Para dar de alta un incidente, se debe acceder desde (Personal), seleccionar en la grilla el legajo que se asociara al incidente y clickear en (Incidentes), se desplegará una grilla con los incidentes asociados al legajo en forma inversa, el mas cercano primero, la grilla podrá ser filtrada para obtener solamente los vigentes, los anulados o todos, también se podrá filtrar por tipo de incidente.
Para dar de alta un nuevo incidente, se deberá clickear en (Nuevo).
Lo primero que se debe indicar es el tipo de incidente a ingresar, debido a que precisamente el tipo de incidente determinará que datos son obligatorios y cuales no.
Luego se sugiere la fecha del día, que indica básicamente la fecha del incidente.
Fecha de inicio y fecha final se refieren al comienzo y finalización del incidente, en el caso de una licencia por maternidad será la fecha de comienzo y finalización de dicha licencia, lo mismo para el caso de vacaciones; en el caso de una ausencia será la misma fecha en ambos datos.
La cantidad de días que media entre una fecha y otra será validada contra la cantidad máxima de días que tiene definido el tipo de incidente.
La solapa “Incidente” permite dejar constancia del incidente en si.
Referencia es un titulo o descripción corta del incidente, y será obligatorio su ingreso si se ha definido así en el tipo de incidente asociado.
Detalle es un texto donde se debería explicar el incidente, y será obligatorio su ingreso si se ha definido así en el tipo de incidente asociado.
Resolución es un texto donde se debería explicar la solución del incidente, y será obligatorio su ingreso si así se ha definido en el tipo de incidente asociado.
Adjunto permite ingresar o buscar un documento externo al sistema, ejemplo una amonestación o suspensión hecha en un procesador de texto, y dejarla asociada al incidente para su consulta o seguimiento.
La solapa “Médico” permite dejar constancia de ciertos datos que pueden estar asociados al incidente.
Fecha y hora de visita se refiere al momento en que el médico efectuó la visita en el domicilio del
Paciente.
Nombre del profesional se refiere al nombre del médico que ha visitado al paciente.
Resultado / Observaciones es un texto que sirve de aclaración al incidente.
Los datos médicos son obligatorios si se ha definido así en el tipo de incidente y el mismo quiere cerrarse.
La solapa “Certificados” permite dejar constancia de ciertos datos que pueden estar asociados al incidente.
Fecha de certificado se refiere precisamente a la fecha que consta en el certificado presentado
Observaciones es un texto que puede servir de aclaración al incidente
Los datos sobre certificados son obligatorios si se ha definido así en el tipo de incidente y el mismo quiere cerrarse.
La solapa “ART” permite dejar constancia del aviso del siniestro a la ART que corresponda.
Fecha y hora de aviso se refiere precisamente al momento en que el incidente es declarado a la ART
Atendió / Contacto / Nombre se refiere a la persona de la ART que nos ha relevado el incidente .
Número de siniestro es el número que otorga la ART al incidente y servirá para referencias posteriores.
Observaciones es un texto que sirve de aclaración a la denuncia del incidente a la ART
Los datos de fecha, contacto y número de siniestro son obligatorios si así se ha definido en el tipo de incidente y se pretende cerrar el mismo.
La solapa “Abogados” permite dejar constancia sobre datos asociados a situaciones que requieran la intervención de un abogado.
Nombre profesional se refiere precisamente al nombre del abogado asociado.
Observaciones es un texto que sirve de aclaración.
La solapa “Situación de revista” permite establecer que tipo de situación de revista esta asociada al incidente.
Situación de revista se refiere a la situación en que el empleado ingresa a partir de la incorporación del incidente, la misma es sugerida en base a lo definido en tipos de incidente, pudiendo también ser modificada por el operador que esta ingresando el incidente.
Si el tipo de incidente no tiene indicado que modifica la situación de revista, este dato no será tenido en cuenta.
La aplicación de estas situaciones de revista a cada legajo, para su migración al aplicativo Sicoss, se explica en documento aparte.
La solapa “Liquidación” permite establecer en que tipo de liquidación se ha de procesar el incidente.
Tipo de liquidación asociada se refiere precisamente al tipo de liquidación en que el incidente será evaluado e incorporado.
El tipo de liquidación sugerido se obtiene de lo que se haya parametrizado en la definición del tipo de incidente.
Si el tipo de incidente no tiene indicado que es liquidable, este dato no será tenido en cuenta.
La solapa “Cierre” mantiene datos asociados al cierre del incidente.
Marca el incidente como cerrado se refiere precisamente al hecho de cerrar el incidente y que el mismo no pueda ser modificado.
Al pretender cerrar el incidente se evaluarán los contenidos de ciertos datos según lo parametrizado en el tipo de incidente asociado.
Los incidentes que son liquidables se cerrarán automáticamente al confirmar la liquidación asociada sin necesidad de cerrarlos en forma manual.
Al confirmar el incidente el mismo quedará archivado asociado al legajo, y podrá ser visualizado en la grilla asociada al legajo o bien en la general de incidentes.
Modificar un incidente :
Para modificar un incidente bastará con seleccionarlo en la grilla correspondiente y clickear en (Modificar)
No se podrá modificar un incidente cerrado o anulado.
Anular un incidente:
Para anular un incidente bastará con seleccionarlo en la grilla correspondiente y clickear en (Anular).
No se podrá anular un incidente cerrado o ya anulado con anterioridad.
Los incidentes anulados no serán tenidos en cuenta en una liquidación
Consultar un incidente
Para consultar un incidente bastará con seleccionarlo en la grilla correspondiente y clickear en (Consultar)
Liquidar un incidente :
Los incidentes que en su tipo hayan sido definidos como Liquidables, podrán ser utilizados en una liquidación mediante la utilización de un tipo de formula especial.
Dicho tipo de formula tiene la particularidad de localizar el incidente y obtener la cantidad de días que median entre la fecha de inicio del mismo y la fecha final.
Estas fechas deben estar dentro del rango de aquellas definidas en la liquidación que los va a utilizar.
O sea, al momento de definir una liquidación se solicita el periodo inicial y el periodo final, dichas fechas sirven, entre otras cosas, para obtener incidentes pendientes de liquidación , con fecha de inicio y final dentro de dicho rango.
Formulas utilizando incidentes:
Para poder utilizar días de un incidente en una formula, se utiliza la palabra clave INCIDE
INCIDE es la palabra clave que permite ser incorporada como argumento dentro de una formula de un concepto de liquidación.
INCIDE va seguido del código del tipo de incidente a evaluar y un modificador respecto a que es lo que debe hacer en lo referente a : localizar el último incidente y tipo, localizar el primer incidente y tipo, o bien realizar la sumatoria de días de dicho incidente dentro del periodo de la liquidación.
Sintaxis :
INCIDE;{TIPO DE INCIDENTE};{modificador}
INCIDE es la palabra clave
TIPO DE INCIDENTE se refiere a un código de tipo de incidente definido.
Modificador se refiere a la forma de evaluar el incidente, pudiendo ser :
ULT : cantidad de días del ultimo incidente del tipo indicado.
PRI : cantidad de días del primer incidente del tipo indicado
SUM: sumatoria de días de todos los incidentes del tipo indicado.
Ejemplos:
Vacaciones
Suponiendo que el tipo de incidente para licencia por vacaciones sea LICVAC
INCIDE;LICVAC;ULT
Devolverá la cantidad de días del último incidente LICVAC
Entonces podría ser utilizado de esta manera
( ( ( ESCALA;”JF”;CATEGO ) / 25 ) * INCIDE;LVAC;ULT )
Calculando el valor de las vacaciones obteniendo el sueldo según escalafón “JF”, evaluado por categoría en legajo y dividido 25 multiplicado por la cantidad de días del ultimo incidente LVAC asociado al legajo
Ausencias sin aviso
Suponiendo que el tipo de incidente para ausencias sin aviso sea AUSEN1
INCIDE:AUSEN1;SUM
Devolverá la sumatoria de los días de todos los incidentes del tipo AUSEN1 en el periodo que abarque la liquidación.
Entonces podría ser utilizado de esta manera
( ( ( ( ESCALA;”JF”;CATEGO ) / 30 * INCIDE;AUSEN1;SUM ) * - 1 )
Calculando el valor a restar obteniendo el sueldo del escalafón JF evaluado por categoría, dividiéndolo por 30 y multiplicándolo por la cantidad de ausencias dentro del periodo.
Ch 20-09-2010
Incidentes sobre legajos
Generalidades:
A efectos de poder realizar un control y seguimiento de las distintas situaciones que hacen a un legajo, el sistema permite definir y mantener ciertos datos en forma de incidentes.
Estos incidentes se relacionan al legajo de un empleado y son visualizados en forma de grilla.
Los incidentes se tipifican mediante un código de tipo de incidente, y son numerados en forma automática y secuencial.
Los incidentes sobre legajos no tienen relación alguna con el modulo de incidentes del sistema administrativo.
Parametrizacion inicial:
Tipos de incidentes:
La parametrizacion de los tipos de incidentes permite definir distintos códigos que actúan de una manera u otra, a efectos que, al ingresar el incidente asociado a un legajo, se solicitan ciertos datos y acciones de manera obligatoria.
Para definir los tipos de incidentes se accede desde (Personal), botón superior (Incidentes), y finalmente botón lateral (Tipos incidentes).
Se desplegará un panel de trabajo con todos los tipos de incidentes definidos.
Una vez clickeado en (Nuevo), y ya en la actividad se solicitan diversos datos :
Código : Se refiere al código que identificará al tipo de incidente.
Descripción: Es la descripción del tipo de incidente.
Queda pendiente de liquidar y se liquida como: Es un tilde que internamente actúa por si o por no.
Si el incidente queda pendiente de liquidar, podrá ser utilizado en una liquidación del tipo asociado.
Modifica situación de revista como : Es un tilde que internamente actúa por si o por no.
Si el incidente modifica la situación de revista, podrá ser utilizado desde el panel de trabajo de incidentes para proceder a modificar la situación de revista de un legajo.
Implica ausencia : Es un tilde que internamente actúa por si o por no.
Requiere certificado / Justificación : Es un tilde que internamente actúa por si o por no, y en función de este tilde se solicitará o no cierta información al ingresar o cerrar el incidente.
Requiere visita a domicilio : Es un tilde que internamente actúa por si o por no, y en función de este tilde se solicitara o no cierta información al ingresar o cerrar el incidente.
Requiere cerrar el incidente : Es un tilde por si o por no, y que permitirá dejar al incidente como pendiente de cierre, para un posterior cierre manual o a través de una liquidación, o bien dejará al incidente como cerrado en el mismo ingreso.
Referencia obligatoria : Es un tilde por si o por no, y que permitirá definir si al momento de ingresar un incidente, es obligatorio o no que se ingrese un texto de referencia.
Detalle Obligatorio : Es un tilde por si o por no, y que permitirá definir si al momento de ingresar un incidente, es obligatorio o no que se ingrese un texto detallando el mismo.
Dar aviso a ART: Es un tilde por si o por no, y que permitirá definir si al momento de ingresar un incidente, es obligatorio o no que se ingresen los datos asociados a la ART.
Solución obligatoria : Es un tilde por si o por no, y que permitirá definir si al momento de ingresar un incidente, es obligatorio o no que se ingrese un texto en el campo de solución.
Evalúa cantidad de días contra cuenta corriente de vacaciones : Es un tilde por si o por no, y que permite que, al momento de ingresar un incidente, las fechas de inicio y final del mismo sean evaluadas en su cantidad contra el saldo de la cuenta corriente de vacaciones asociada al legajo.
Para una mejor explicación se provee un documento especial para liquidación de vacaciones.
Rango máximo de días : Es la cantidad de días máxima que puede mediar entre la fecha inicial y final de un incidente, y solo a efectos que, al momento de ingresar un incidente, la cantidad de días que media entre la fecha inicial y final, no supere dicho numero.
Como ejemplos de tipos de incidentes, podemos aplicar que :
Un accidente laboral, implica ausencia, no queda pendiente de liquidar, modifica la situación de revista, requiere una visita al domicilio por parte del medico, requiere cerrar el incidente, tiene referencia y detalle obligatorio, se debe dar aviso a la ART y no tiene un rango máximo de días.
Una ausencia con aviso, no queda pendiente de liquidar, no modifica la situación de revista, implica una ausencia, requiere un certificado o justificación, no requiere visita a domicilio, requiere cerrar el incidente, requiere una referencia y detalle, no da aviso a la ART, no requiere de una solución, no evalúa la cantidad de días de vacaciones, y tiene un rango máximo de 1 día.
Una licencia por vacaciones queda pendiente de liquidar, modifica la situación de revista, implica una ausencia, no requiere certificado, no requiere visita a domicilio, requiere cerrar el incidente, no tiene referencia, detalle ni solución, evalúa la cantidad de días contra la cuenta corriente de vacaciones, y tiene un máximo de 35 días.
Y así las distintas combinaciones posibles o necesarias.
Dar de alta un incidente :
Para dar de alta un incidente, se debe acceder desde (Personal), seleccionar en la grilla el legajo que se asociara al incidente y clickear en (Incidentes), se desplegará una grilla con los incidentes asociados al legajo en forma inversa, el mas cercano primero, la grilla podrá ser filtrada para obtener solamente los vigentes, los anulados o todos, también se podrá filtrar por tipo de incidente.
Para dar de alta un nuevo incidente, se deberá clickear en (Nuevo).
Lo primero que se debe indicar es el tipo de incidente a ingresar, debido a que precisamente el tipo de incidente determinará que datos son obligatorios y cuales no.
Luego se sugiere la fecha del día, que indica básicamente la fecha del incidente.
Fecha de inicio y fecha final se refieren al comienzo y finalización del incidente, en el caso de una licencia por maternidad será la fecha de comienzo y finalización de dicha licencia, lo mismo para el caso de vacaciones; en el caso de una ausencia será la misma fecha en ambos datos.
La cantidad de días que media entre una fecha y otra será validada contra la cantidad máxima de días que tiene definido el tipo de incidente.
La solapa “Incidente” permite dejar constancia del incidente en si.
Referencia es un titulo o descripción corta del incidente, y será obligatorio su ingreso si se ha definido así en el tipo de incidente asociado.
Detalle es un texto donde se debería explicar el incidente, y será obligatorio su ingreso si se ha definido así en el tipo de incidente asociado.
Resolución es un texto donde se debería explicar la solución del incidente, y será obligatorio su ingreso si así se ha definido en el tipo de incidente asociado.
Adjunto permite ingresar o buscar un documento externo al sistema, ejemplo una amonestación o suspensión hecha en un procesador de texto, y dejarla asociada al incidente para su consulta o seguimiento.
La solapa “Médico” permite dejar constancia de ciertos datos que pueden estar asociados al incidente.
Fecha y hora de visita se refiere al momento en que el médico efectuó la visita en el domicilio del
Paciente.
Nombre del profesional se refiere al nombre del médico que ha visitado al paciente.
Resultado / Observaciones es un texto que sirve de aclaración al incidente.
Los datos médicos son obligatorios si se ha definido así en el tipo de incidente y el mismo quiere cerrarse.
La solapa “Certificados” permite dejar constancia de ciertos datos que pueden estar asociados al incidente.
Fecha de certificado se refiere precisamente a la fecha que consta en el certificado presentado
Observaciones es un texto que puede servir de aclaración al incidente
Los datos sobre certificados son obligatorios si se ha definido así en el tipo de incidente y el mismo quiere cerrarse.
La solapa “ART” permite dejar constancia del aviso del siniestro a la ART que corresponda.
Fecha y hora de aviso se refiere precisamente al momento en que el incidente es declarado a la ART
Atendió / Contacto / Nombre se refiere a la persona de la ART que nos ha relevado el incidente .
Número de siniestro es el número que otorga la ART al incidente y servirá para referencias posteriores.
Observaciones es un texto que sirve de aclaración a la denuncia del incidente a la ART
Los datos de fecha, contacto y número de siniestro son obligatorios si así se ha definido en el tipo de incidente y se pretende cerrar el mismo.
La solapa “Abogados” permite dejar constancia sobre datos asociados a situaciones que requieran la intervención de un abogado.
Nombre profesional se refiere precisamente al nombre del abogado asociado.
Observaciones es un texto que sirve de aclaración.
La solapa “Situación de revista” permite establecer que tipo de situación de revista esta asociada al incidente.
Situación de revista se refiere a la situación en que el empleado ingresa a partir de la incorporación del incidente, la misma es sugerida en base a lo definido en tipos de incidente, pudiendo también ser modificada por el operador que esta ingresando el incidente.
Si el tipo de incidente no tiene indicado que modifica la situación de revista, este dato no será tenido en cuenta.
La aplicación de estas situaciones de revista a cada legajo, para su migración al aplicativo Sicoss, se explica en documento aparte.
La solapa “Liquidación” permite establecer en que tipo de liquidación se ha de procesar el incidente.
Tipo de liquidación asociada se refiere precisamente al tipo de liquidación en que el incidente será evaluado e incorporado.
El tipo de liquidación sugerido se obtiene de lo que se haya parametrizado en la definición del tipo de incidente.
Si el tipo de incidente no tiene indicado que es liquidable, este dato no será tenido en cuenta.
La solapa “Cierre” mantiene datos asociados al cierre del incidente.
Marca el incidente como cerrado se refiere precisamente al hecho de cerrar el incidente y que el mismo no pueda ser modificado.
Al pretender cerrar el incidente se evaluarán los contenidos de ciertos datos según lo parametrizado en el tipo de incidente asociado.
Los incidentes que son liquidables se cerrarán automáticamente al confirmar la liquidación asociada sin necesidad de cerrarlos en forma manual.
Al confirmar el incidente el mismo quedará archivado asociado al legajo, y podrá ser visualizado en la grilla asociada al legajo o bien en la general de incidentes.
Modificar un incidente :
Para modificar un incidente bastará con seleccionarlo en la grilla correspondiente y clickear en (Modificar)
No se podrá modificar un incidente cerrado o anulado.
Anular un incidente:
Para anular un incidente bastará con seleccionarlo en la grilla correspondiente y clickear en (Anular).
No se podrá anular un incidente cerrado o ya anulado con anterioridad.
Los incidentes anulados no serán tenidos en cuenta en una liquidación
Consultar un incidente
Para consultar un incidente bastará con seleccionarlo en la grilla correspondiente y clickear en (Consultar)
Liquidar un incidente :
Los incidentes que en su tipo hayan sido definidos como Liquidables, podrán ser utilizados en una liquidación mediante la utilización de un tipo de formula especial.
Dicho tipo de formula tiene la particularidad de localizar el incidente y obtener la cantidad de días que median entre la fecha de inicio del mismo y la fecha final.
Estas fechas deben estar dentro del rango de aquellas definidas en la liquidación que los va a utilizar.
O sea, al momento de definir una liquidación se solicita el periodo inicial y el periodo final, dichas fechas sirven, entre otras cosas, para obtener incidentes pendientes de liquidación , con fecha de inicio y final dentro de dicho rango.
Formulas utilizando incidentes:
Para poder utilizar días de un incidente en una formula, se utiliza la palabra clave INCIDE
INCIDE es la palabra clave que permite ser incorporada como argumento dentro de una formula de un concepto de liquidación.
INCIDE va seguido del código del tipo de incidente a evaluar y un modificador respecto a que es lo que debe hacer en lo referente a : localizar el último incidente y tipo, localizar el primer incidente y tipo, o bien realizar la sumatoria de días de dicho incidente dentro del periodo de la liquidación.
Sintaxis :
INCIDE;{TIPO DE INCIDENTE};{modificador}
INCIDE es la palabra clave
TIPO DE INCIDENTE se refiere a un código de tipo de incidente definido.
Modificador se refiere a la forma de evaluar el incidente, pudiendo ser :
ULT : cantidad de días del ultimo incidente del tipo indicado.
PRI : cantidad de días del primer incidente del tipo indicado
SUM: sumatoria de días de todos los incidentes del tipo indicado.
Ejemplos:
Vacaciones
Suponiendo que el tipo de incidente para licencia por vacaciones sea LICVAC
INCIDE;LICVAC;ULT
Devolverá la cantidad de días del último incidente LICVAC
Entonces podría ser utilizado de esta manera
( ( ( ESCALA;”JF”;CATEGO ) / 25 ) * INCIDE;LVAC;ULT )
Calculando el valor de las vacaciones obteniendo el sueldo según escalafón “JF”, evaluado por categoría en legajo y dividido 25 multiplicado por la cantidad de días del ultimo incidente LVAC asociado al legajo
Ausencias sin aviso
Suponiendo que el tipo de incidente para ausencias sin aviso sea AUSEN1
INCIDE:AUSEN1;SUM
Devolverá la sumatoria de los días de todos los incidentes del tipo AUSEN1 en el periodo que abarque la liquidación.
Entonces podría ser utilizado de esta manera
( ( ( ( ESCALA;”JF”;CATEGO ) / 30 * INCIDE;AUSEN1;SUM ) * - 1 )
Calculando el valor a restar obteniendo el sueldo del escalafón JF evaluado por categoría, dividiéndolo por 30 y multiplicándolo por la cantidad de ausencias dentro del periodo.
Ch 20-09-2010
Datacomsys version 100924
Modificaciones importantes en Datacomsys 7.4 Versión 100924
Títulos correspondientes a modificaciones y agregados realizados para esta versión.
Parámetros
Caracteres del sujeto
Monto máximo operaciones anuales
Compras
Aranceles de importación
Reaplicación por lote
Paneles “Trabajar con”, en tablas asociadas
Proveedores
Pagar comprobantes
Marca para “Pendiente de nota de crédito”
Administración de personal
Conceptos
Orden de calculo
Incidentes
Incidentes por ausencias
Dataagent
Emisión automática de reportes
Monto máximo operaciones anuales
Existiendo una normativa por la que se debería proceder de una manera especial, tanto para ventas o compras a monotributistas, y que excedan un monto máximo anual; existe la posibilidad de indicar un valor máximo de compra y venta para cada carácter del sujeto.
Ese importe es verificado al realizar una venta o comprobante de compra, informando al operador de dicha situación, el comprobante igualmente puede ser realizado, solamente se avisa a efectos informativos.
Importante :Todos los caracteres del sujeto han sido inicializados en estos campos con el valor máximo 9999999.99, para la correcta utilización de esta posibilidad, no solo se deben modificar estos valores por parte de los responsable de cada instalación, sino que también debe estar corriendo el utilitario Data-agent en el servidor, solicitar mas detalles por correo electrónico.
Reaplicación por lote de aranceles de importación
El panel “Productos por aranceles de importación” ha sido modificado, agregándole un botón que ejecuta un proceso, este proceso recorre todos los productos asociados al arancel seleccionado, y los actualiza con los valores propios de dicho arancel.
Paneles “Trabajar con”, en tablas asociadas a compras/proveedores
Los botones (Categorías), (Condiciones), (Métodos), (Rubros), (Impositiva) y (Sectores), que originalmente permitían acceder directamente a la actividad de alta, baja y modificación correspondiente, ahora acceden a un panel de trabajo donde se despliega una grilla con los datos ingresados.
Para realizar una modificación o eliminación se deberá pinchar el dato y clickear en los botones correspondientes, así como para dar de alta un nuevo registro se debera clickear en (Nuevo).
Estos paneles se complementan con un botón superior (Proveedores), donde se desplegarán aquellos que contengan en su legajo el dato seleccionado en la grilla.
Marca para “Pendiente de nota de crédito”A efectos de poder realizar un cálculo correcto por retenciones de ganancias, en comprobantes que se pagan parcialmente, a la espera de una nota de crédito; el panel de trabajo correspondiente a (Pagar facturas) ha sido complementado con un tilde que permite dejar constancia en el sistema que, el pago parcial que se esta realizando, corresponde porque se esta esperando un crédito del proveedor, y no porque es un pago a cuenta.
Este tilde permite que el sistema aplique correctamente, en su calculo, el importe que corresponda a percepciones de ingresos brutos hechas en el comprobante que se esta pagando, ya que las percepciones proporcionales no están permitidas, y no serán incluidas en la nota de crédito a la espera.
Este tilde también sirve para que, en un segundo acceso al mencionado panel, se pueda visualizar que dicho comprobante pendiente esta a la espera de una nota de crédito.
Si el saldo del comprobante es incluido en una orden de pago, y dicho tilde esta precisamente tildado, se emite un mensaje de advertencia, pero puede igualmente incluirselo.
Es importante resaltar que el tilde se activa, solamente si el importe a pagar es menor que el saldo del comprobante.
Orden de calculo en conceptos de liquidación
A efectos de preparar el sistema de sueldos para el calculo de ganancias, es necesario establecer que los conceptos de liquidación puedan ser de primera o segunda pasada, esto quiere decir que es posible, independientemente del ordenamiento numérico por concepto que realiza el sistema al momento de calculo, indicar que un concepto sea calculado en una pasada posterior a otro grupo de conceptos.
Todos los conceptos existentes han sido inicializados como de primer pasada.
Incidentes por ausencias por legajos
Profundizando el mantenimiento de incidentes por legajos de empleados, se ha ampliado profundamente el concepto de lo que es un incidente.
Esta modificación se explica en documento aparte, enviado a aquellas instalaciones que utilizan el sistema de administración de personal.
Calculo de vacaciones
Complementando incidentes por ausencias, se ha realizado un desarrollo que permite mantener legajo por legajo la cuenta corriente en días de vacacaciones, en base a su antigüedad por convenio y las liquidaciones que se han ido realizando.
Esta modificación se explica en un documento aparte, enviado a aquellas instalaciones que utilizan el sistema de administración de personal.
Emisión automática de reportes
El utilitario Data-agent ha sido modificado para poder realizar la emisión de reportes automáticamente y en una fecha dada.
Los distintos informes necesarios de emitir para cada instalación, deben ser solicitados por correo electrónico.
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 24-09-2010
Títulos correspondientes a modificaciones y agregados realizados para esta versión.
Parámetros
Caracteres del sujeto
Monto máximo operaciones anuales
Compras
Aranceles de importación
Reaplicación por lote
Paneles “Trabajar con”, en tablas asociadas
Proveedores
Pagar comprobantes
Marca para “Pendiente de nota de crédito”
Administración de personal
Conceptos
Orden de calculo
Incidentes
Incidentes por ausencias
Dataagent
Emisión automática de reportes
Monto máximo operaciones anuales
Existiendo una normativa por la que se debería proceder de una manera especial, tanto para ventas o compras a monotributistas, y que excedan un monto máximo anual; existe la posibilidad de indicar un valor máximo de compra y venta para cada carácter del sujeto.
Ese importe es verificado al realizar una venta o comprobante de compra, informando al operador de dicha situación, el comprobante igualmente puede ser realizado, solamente se avisa a efectos informativos.
Importante :Todos los caracteres del sujeto han sido inicializados en estos campos con el valor máximo 9999999.99, para la correcta utilización de esta posibilidad, no solo se deben modificar estos valores por parte de los responsable de cada instalación, sino que también debe estar corriendo el utilitario Data-agent en el servidor, solicitar mas detalles por correo electrónico.
Reaplicación por lote de aranceles de importación
El panel “Productos por aranceles de importación” ha sido modificado, agregándole un botón que ejecuta un proceso, este proceso recorre todos los productos asociados al arancel seleccionado, y los actualiza con los valores propios de dicho arancel.
Paneles “Trabajar con”, en tablas asociadas a compras/proveedores
Los botones (Categorías), (Condiciones), (Métodos), (Rubros), (Impositiva) y (Sectores), que originalmente permitían acceder directamente a la actividad de alta, baja y modificación correspondiente, ahora acceden a un panel de trabajo donde se despliega una grilla con los datos ingresados.
Para realizar una modificación o eliminación se deberá pinchar el dato y clickear en los botones correspondientes, así como para dar de alta un nuevo registro se debera clickear en (Nuevo).
Estos paneles se complementan con un botón superior (Proveedores), donde se desplegarán aquellos que contengan en su legajo el dato seleccionado en la grilla.
Marca para “Pendiente de nota de crédito”A efectos de poder realizar un cálculo correcto por retenciones de ganancias, en comprobantes que se pagan parcialmente, a la espera de una nota de crédito; el panel de trabajo correspondiente a (Pagar facturas) ha sido complementado con un tilde que permite dejar constancia en el sistema que, el pago parcial que se esta realizando, corresponde porque se esta esperando un crédito del proveedor, y no porque es un pago a cuenta.
Este tilde permite que el sistema aplique correctamente, en su calculo, el importe que corresponda a percepciones de ingresos brutos hechas en el comprobante que se esta pagando, ya que las percepciones proporcionales no están permitidas, y no serán incluidas en la nota de crédito a la espera.
Este tilde también sirve para que, en un segundo acceso al mencionado panel, se pueda visualizar que dicho comprobante pendiente esta a la espera de una nota de crédito.
Si el saldo del comprobante es incluido en una orden de pago, y dicho tilde esta precisamente tildado, se emite un mensaje de advertencia, pero puede igualmente incluirselo.
Es importante resaltar que el tilde se activa, solamente si el importe a pagar es menor que el saldo del comprobante.
Orden de calculo en conceptos de liquidación
A efectos de preparar el sistema de sueldos para el calculo de ganancias, es necesario establecer que los conceptos de liquidación puedan ser de primera o segunda pasada, esto quiere decir que es posible, independientemente del ordenamiento numérico por concepto que realiza el sistema al momento de calculo, indicar que un concepto sea calculado en una pasada posterior a otro grupo de conceptos.
Todos los conceptos existentes han sido inicializados como de primer pasada.
Incidentes por ausencias por legajos
Profundizando el mantenimiento de incidentes por legajos de empleados, se ha ampliado profundamente el concepto de lo que es un incidente.
Esta modificación se explica en documento aparte, enviado a aquellas instalaciones que utilizan el sistema de administración de personal.
Calculo de vacaciones
Complementando incidentes por ausencias, se ha realizado un desarrollo que permite mantener legajo por legajo la cuenta corriente en días de vacacaciones, en base a su antigüedad por convenio y las liquidaciones que se han ido realizando.
Esta modificación se explica en un documento aparte, enviado a aquellas instalaciones que utilizan el sistema de administración de personal.
Emisión automática de reportes
El utilitario Data-agent ha sido modificado para poder realizar la emisión de reportes automáticamente y en una fecha dada.
Los distintos informes necesarios de emitir para cada instalación, deben ser solicitados por correo electrónico.
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 24-09-2010
jueves, 2 de septiembre de 2010
Datacomsys version 100827
Modificaciones importantes en Datacomsys 7.4 Versión 100827
Títulos correspondientes a modificaciones y agregados realizados para esta versión.
Ventas
Precios
Políticas de precios
Precios por cliente / marca
Importación de precios
Márgenes mínimos de ganancia
Proveedores
Pagos
Retención impuesto a las ganancias
Producción
Plan de producción
Ingreso de resultados
Numero de lote y vencimiento
Administración de personal
Liquidaciones
Liquidación en estado 5
Informes especiales
Emisión desglosando o acumulando liquidaciones
Aplicación de remuneraciones imponibles a totales de cálculo
Parámetros sicoss
Condiciones
Libro de sueldos provincia de Buenos Aires
Antigüedad convenio gráficos
Detalles correspondientes a modificaciones y agregados realizados para esta versión
Precios por cliente y marca
En el acceso a precios y referido a las políticas de precio posibles por cliente, se agregó la posibilidad de generar descuentos especiales por la relación de cliente y marca.
La forma de utilización es similar al resto de las políticas por cliente, y cuenta con la posibilidad de importación de datos desde una planilla externa.
La precedencia se ha modificado, evaluando inicialmente la relación entre cliente y producto, luego cliente y marca, luego cliente, rubro y línea, y finalmente cliente rubro.
Para que las políticas sean aplicadas, se deberá tildar en la definición de la lista de precios correspondiente, el casillero “Permite precios especiales por cliente”.
El acceso a la definición de las políticas se realiza mediante el botón (Precios por cliente), solapa Cliente / Marca.
Márgenes mínimos de ganancia
Se ha modificado el procedimiento de importación de precios externos, a efectos de incorporar márgenes mínimos de ganancia, en importe o porcentajes, indicándole como valor cero (0).
También es posible la incorporación en cero de precios de venta y costos.
Esta posibilidad se obtiene indicando en el combo superior a cada columna, la opción “0 – en cero”.
En definitiva, a partir de esta versión, el procedimiento de importación cuenta con la posibilidad de: O bien indicar una letra de columna asociada a la planilla externa, para que desde dicha columna se extraigan los datos; o bien indicar “# - ignorar”, para que no se modifiquen los valores internos de los datos en el sistema; o bien indicar “0 – en cero”, para incorporar dicho valor, cero, en los datos existentes.
Retenciones de impuestos a las ganancias
Ampliando la capacidad del sistema para realizar el cálculo de retenciones sencillas en órdenes de pago, como ser las de ingresos brutos, hemos agregado la posibilidad de realizar retenciones mas complejas, como ser las de ganancias, tanto por bienes de cambio o por servicios u honorarios.
A tales efectos, la definición de impuestos que se puede realizar desde el acceso a parámetros, ha sido ampliada en lo referente a poder evaluar y formar la base imponible en función de la sumatoria de pagos que se han realizado en un mes, y el agregado de una tabla independiente que contiene los rangos a evaluar, y los importes y porcentajes a retener.
De esta manera, al emitir una orden de pago, se evalúan aquellos realizados durante el mes en curso, los que son sumados a lo que corresponda retener por la orden de pago que se esta realizando, resultado al que se le restan las retenciones anteriores del mismo periodo, obteniendo la nueva retención.
Esta nueva retención se incorpora como cartera en la minuta de la orden de pago, de manera similar a como se realiza actualmente con ingresos brutos.
Al momento de la instalación de la versión se han incorporado en forma automática las definiciones de los nuevos impuestos, los que deberán ser a su vez incorporados, a voluntad del administrador del sistema, en las subcategorías impositivas definidas en el modulo de proveedores.
En caso que no existiera, no se ha creado la cartera correspondiente ni la cuenta contable que la soporta.
O sea, por más que el sistema esta preparado para hacer las retenciones anteriormente detalladas, las mismas no se harán en forma automática hasta que el administrador del sistema lo considere oportuno.
Número de lote y fecha de vencimiento en producción
Al momento de ingresar un resultado, correspondiente a un parte de trabajo, asociado a un plan de producción, es posible detallar el número de lote y su vencimiento.
Este numero de lote se incorpora en forma automática al movimiento de stock asociado a la producción, o sea que puede ser visualizado en cualquier consulta que tenga asociado uno o mas movimientos de stock.
El formato en que se visualiza es en forma de observación, indicando CODIGO DE PLAN / NUMERO DE PARTE DE TRABAJO / NUMERO DE RESULTADO / NUMERO DE LOTE.
Liquidaciones de sueldos en estado 5
A efectos de poder inhibir, definitivamente, la modificación de una liquidación realizada, impresa y asentada; se puede pasar opcionalmente a la misma a un nuevo estado que hemos denominado estado 5.
Una liquidación en estado 5, no puede ser recalculada ni modificada por proceso u operador alguno.
Tampoco es posible la reimpresión del libro de sueldos, o el re-asentamiento contable de la misma.
O sea que el estado 5 solamente permite la consulta, o la utilización en los informes correspondientes sobre liquidaciones que se encuentran bajo el botón (especiales).
El pasaje de una liquidación a estado 5 es opcional, y se realiza mediante el botón (cerrar liquidación)
Solamente puede pasarse a estado 5 una liquidación que se encuentre en estado 4.
Informes especiales desglosando las liquidaciones que intervienen
Los informes sobre liquidaciones que se pueden emitir accediendo a (Especiales), tienen ahora la posibilidad de ser impresos agrupando o bien desglosando las liquidaciones que se hayan tildado.
A tales efectos se ha agregado, debajo de la botonera del sector derecho, un check box que indica si se desea emitir los informes en forma Consolidada o Abierta.
La forma consolidada es la que ya estaba implementada, en la forma Abierta se detalla cada una de las liquidaciones que se hayan tildado, y realiza un subtotal por número de legajo.
Remuneraciones imponibles asociadas a totales de cálculo
A las palabras reservadas o argumentos TOTHCD, TOTHSD, TOTASI, TOTHAB, TONETO, y TBRUTO, se les ha agregado la posibilidad de indicar un modificador que permite que esa palabra reservada sea evaluada solamente, si no supera una remuneración imponible dada, caso contrario el valor tomado es el de la remuneración imponible.
Si por dar un ejemplo, una formula calcula el 3 % del total de haberes con descuento, siempre y cuando dicho total no supere la remuneración imponible 4, se la define indicando: ( TOTHCD;RI4 * ( 3 / 100 ) ).
Los modificadores posibles son RI2, RI3, RI4 hasta RI8, correspondiendo desde remuneración imponible 2 a remuneración imponible 8.
Parámetros Sicoss
Ciertos parámetros que estaban definidos en la actividad de parametrizacion Sicoss han sido derivados a otras tablas del sistema.
La Zona del empleador, y si Corresponde o no realizar aportes reducidos, han sido derivados a la definición de sectores.
El importe que corresponde a Aporte adicional obra social, ha sido derivado al legajo de cada empleado.
Condiciones
El catálogo de condiciones ha sido modificado, agregándole la posibilidad de indicar si la condición definida permite que en el legajo del empleado la obra social este en cero ( “000000”), o no.
Libro de sueldos Provincia de Buenos Aires
A efectos de cumplir con el formato de impresión del libro de sueldos del ministerio de trabajo de la provincia de Buenos Aires, el mismo se imprime en una sola pasada encabezado y detalle; no siendo necesaria la preimpresion del mismo mediante el proceso (Hojas rubricadas)
En caso que se haya parametrizado tipo de libro 2 – Formato numero 2 (Pcia.Bs.As), el botón correspondiente a (Hojas rubricadas), no podrá ser utilizado.
Antigüedad según convenio gráfico
Para que la antigüedad de un empleado sea evaluada según el convenio correspondiente a Gráficos, se deberá reemplazar la palabra clave ANTIGU por ANTIE1.
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-08-2010
Títulos correspondientes a modificaciones y agregados realizados para esta versión.
Ventas
Precios
Políticas de precios
Precios por cliente / marca
Importación de precios
Márgenes mínimos de ganancia
Proveedores
Pagos
Retención impuesto a las ganancias
Producción
Plan de producción
Ingreso de resultados
Numero de lote y vencimiento
Administración de personal
Liquidaciones
Liquidación en estado 5
Informes especiales
Emisión desglosando o acumulando liquidaciones
Aplicación de remuneraciones imponibles a totales de cálculo
Parámetros sicoss
Condiciones
Libro de sueldos provincia de Buenos Aires
Antigüedad convenio gráficos
Detalles correspondientes a modificaciones y agregados realizados para esta versión
Precios por cliente y marca
En el acceso a precios y referido a las políticas de precio posibles por cliente, se agregó la posibilidad de generar descuentos especiales por la relación de cliente y marca.
La forma de utilización es similar al resto de las políticas por cliente, y cuenta con la posibilidad de importación de datos desde una planilla externa.
La precedencia se ha modificado, evaluando inicialmente la relación entre cliente y producto, luego cliente y marca, luego cliente, rubro y línea, y finalmente cliente rubro.
Para que las políticas sean aplicadas, se deberá tildar en la definición de la lista de precios correspondiente, el casillero “Permite precios especiales por cliente”.
El acceso a la definición de las políticas se realiza mediante el botón (Precios por cliente), solapa Cliente / Marca.
Márgenes mínimos de ganancia
Se ha modificado el procedimiento de importación de precios externos, a efectos de incorporar márgenes mínimos de ganancia, en importe o porcentajes, indicándole como valor cero (0).
También es posible la incorporación en cero de precios de venta y costos.
Esta posibilidad se obtiene indicando en el combo superior a cada columna, la opción “0 – en cero”.
En definitiva, a partir de esta versión, el procedimiento de importación cuenta con la posibilidad de: O bien indicar una letra de columna asociada a la planilla externa, para que desde dicha columna se extraigan los datos; o bien indicar “# - ignorar”, para que no se modifiquen los valores internos de los datos en el sistema; o bien indicar “0 – en cero”, para incorporar dicho valor, cero, en los datos existentes.
Retenciones de impuestos a las ganancias
Ampliando la capacidad del sistema para realizar el cálculo de retenciones sencillas en órdenes de pago, como ser las de ingresos brutos, hemos agregado la posibilidad de realizar retenciones mas complejas, como ser las de ganancias, tanto por bienes de cambio o por servicios u honorarios.
A tales efectos, la definición de impuestos que se puede realizar desde el acceso a parámetros, ha sido ampliada en lo referente a poder evaluar y formar la base imponible en función de la sumatoria de pagos que se han realizado en un mes, y el agregado de una tabla independiente que contiene los rangos a evaluar, y los importes y porcentajes a retener.
De esta manera, al emitir una orden de pago, se evalúan aquellos realizados durante el mes en curso, los que son sumados a lo que corresponda retener por la orden de pago que se esta realizando, resultado al que se le restan las retenciones anteriores del mismo periodo, obteniendo la nueva retención.
Esta nueva retención se incorpora como cartera en la minuta de la orden de pago, de manera similar a como se realiza actualmente con ingresos brutos.
Al momento de la instalación de la versión se han incorporado en forma automática las definiciones de los nuevos impuestos, los que deberán ser a su vez incorporados, a voluntad del administrador del sistema, en las subcategorías impositivas definidas en el modulo de proveedores.
En caso que no existiera, no se ha creado la cartera correspondiente ni la cuenta contable que la soporta.
O sea, por más que el sistema esta preparado para hacer las retenciones anteriormente detalladas, las mismas no se harán en forma automática hasta que el administrador del sistema lo considere oportuno.
Número de lote y fecha de vencimiento en producción
Al momento de ingresar un resultado, correspondiente a un parte de trabajo, asociado a un plan de producción, es posible detallar el número de lote y su vencimiento.
Este numero de lote se incorpora en forma automática al movimiento de stock asociado a la producción, o sea que puede ser visualizado en cualquier consulta que tenga asociado uno o mas movimientos de stock.
El formato en que se visualiza es en forma de observación, indicando CODIGO DE PLAN / NUMERO DE PARTE DE TRABAJO / NUMERO DE RESULTADO / NUMERO DE LOTE.
Liquidaciones de sueldos en estado 5
A efectos de poder inhibir, definitivamente, la modificación de una liquidación realizada, impresa y asentada; se puede pasar opcionalmente a la misma a un nuevo estado que hemos denominado estado 5.
Una liquidación en estado 5, no puede ser recalculada ni modificada por proceso u operador alguno.
Tampoco es posible la reimpresión del libro de sueldos, o el re-asentamiento contable de la misma.
O sea que el estado 5 solamente permite la consulta, o la utilización en los informes correspondientes sobre liquidaciones que se encuentran bajo el botón (especiales).
El pasaje de una liquidación a estado 5 es opcional, y se realiza mediante el botón (cerrar liquidación)
Solamente puede pasarse a estado 5 una liquidación que se encuentre en estado 4.
Informes especiales desglosando las liquidaciones que intervienen
Los informes sobre liquidaciones que se pueden emitir accediendo a (Especiales), tienen ahora la posibilidad de ser impresos agrupando o bien desglosando las liquidaciones que se hayan tildado.
A tales efectos se ha agregado, debajo de la botonera del sector derecho, un check box que indica si se desea emitir los informes en forma Consolidada o Abierta.
La forma consolidada es la que ya estaba implementada, en la forma Abierta se detalla cada una de las liquidaciones que se hayan tildado, y realiza un subtotal por número de legajo.
Remuneraciones imponibles asociadas a totales de cálculo
A las palabras reservadas o argumentos TOTHCD, TOTHSD, TOTASI, TOTHAB, TONETO, y TBRUTO, se les ha agregado la posibilidad de indicar un modificador que permite que esa palabra reservada sea evaluada solamente, si no supera una remuneración imponible dada, caso contrario el valor tomado es el de la remuneración imponible.
Si por dar un ejemplo, una formula calcula el 3 % del total de haberes con descuento, siempre y cuando dicho total no supere la remuneración imponible 4, se la define indicando: ( TOTHCD;RI4 * ( 3 / 100 ) ).
Los modificadores posibles son RI2, RI3, RI4 hasta RI8, correspondiendo desde remuneración imponible 2 a remuneración imponible 8.
Parámetros Sicoss
Ciertos parámetros que estaban definidos en la actividad de parametrizacion Sicoss han sido derivados a otras tablas del sistema.
La Zona del empleador, y si Corresponde o no realizar aportes reducidos, han sido derivados a la definición de sectores.
El importe que corresponde a Aporte adicional obra social, ha sido derivado al legajo de cada empleado.
Condiciones
El catálogo de condiciones ha sido modificado, agregándole la posibilidad de indicar si la condición definida permite que en el legajo del empleado la obra social este en cero ( “000000”), o no.
Libro de sueldos Provincia de Buenos Aires
A efectos de cumplir con el formato de impresión del libro de sueldos del ministerio de trabajo de la provincia de Buenos Aires, el mismo se imprime en una sola pasada encabezado y detalle; no siendo necesaria la preimpresion del mismo mediante el proceso (Hojas rubricadas)
En caso que se haya parametrizado tipo de libro 2 – Formato numero 2 (Pcia.Bs.As), el botón correspondiente a (Hojas rubricadas), no podrá ser utilizado.
Antigüedad según convenio gráfico
Para que la antigüedad de un empleado sea evaluada según el convenio correspondiente a Gráficos, se deberá reemplazar la palabra clave ANTIGU por ANTIE1.
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-08-2010
Datacomsys version 100723
Modificaciones importantes en Datacomsys 7.4 Versión 100625/100723
Ventas
Facturación
Facturación electrónica exportación
A partir de la versión 100723, el sistema Datacomsys esta adaptado para la emisión de comprobantes electrónicos letras E.
IMPORTANTE:
Todo lo referido a la utilización de facturación electrónica, se enviará en documento aparte a aquellas instalaciones que, por normativa o por decisión, se vean obligadas o hayan decidido utilizar este procedimiento.
Letras validas por sucursal.
Se ha agregado al modulo de ventas un nuevo parámetro, que permite limitar la emisión de comprobantes por letra a cada punto de venta en particular; de manera de inhibir que una sucursal real o fiscal emita comprobantes E por error, y viceversa.
La paremetrizacion se realiza desde el acceso a parámetros, parámetros de la sucursal, letras validas.
Generales
Parámetros
Contadores por sucursal
Se ha agregado en el panel de trabajo con sucursales, un botón que permite acceder al manejo de los contadores de dicha sucursal.
Los contadores antiguos se han eliminado.
Despacho
Ordenes de carga
Rendición de órdenes de carga
Al procedimiento habitual de emisión de órdenes de carga, se ha agregado una nueva actividad que permite rendir la misma, en lo referente a la entrega o rechazo de los remitos que la componen, así como el total real del flete realizado.
El remito que es rechazado puede ser incorporado en una nueva orden de carga.
El motivo del rechazo se incorpora, provisoriamente, en forma textual.
Administracion de personal
Parámetros
Se ha agregado a los parámetros de sueldos, la posibilidad de indicar que formato de libro se desea utilizar.
Libro de sueldos
Ministerio de trabajo Provincia de Buenos Aires
Se ha agregado la posibilidad de emisión del libro de sueldos, acorde a las nuevas hojas rubricadas provistas por el Ministerio de trabajo de la provincia de Buenos Aires.
Conceptos
Formulas de conceptos
Traer valor de otro concepto
Se ha modificado la sintaxis del mismo para poder obtener no solo el valor calculado de otro conceptos, sino también parámetro 1, parámetro 2, y los parámetros fijos.
Sumatoria de conceptos
Se ha agregado la posibilidad que un concepto sea la resultante de la suma de otros conceptos enunciados en forma de rango.
Informes especiales
Comparativa legajo
Es un informe que permite comparar seis periodos comprendidos entre dos fechas, acumulando las liquidaciones por empleado que estén comprendidas en dicho rango.
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-07-2010
Ventas
Facturación
Facturación electrónica exportación
A partir de la versión 100723, el sistema Datacomsys esta adaptado para la emisión de comprobantes electrónicos letras E.
IMPORTANTE:
Todo lo referido a la utilización de facturación electrónica, se enviará en documento aparte a aquellas instalaciones que, por normativa o por decisión, se vean obligadas o hayan decidido utilizar este procedimiento.
Letras validas por sucursal.
Se ha agregado al modulo de ventas un nuevo parámetro, que permite limitar la emisión de comprobantes por letra a cada punto de venta en particular; de manera de inhibir que una sucursal real o fiscal emita comprobantes E por error, y viceversa.
La paremetrizacion se realiza desde el acceso a parámetros, parámetros de la sucursal, letras validas.
Generales
Parámetros
Contadores por sucursal
Se ha agregado en el panel de trabajo con sucursales, un botón que permite acceder al manejo de los contadores de dicha sucursal.
Los contadores antiguos se han eliminado.
Despacho
Ordenes de carga
Rendición de órdenes de carga
Al procedimiento habitual de emisión de órdenes de carga, se ha agregado una nueva actividad que permite rendir la misma, en lo referente a la entrega o rechazo de los remitos que la componen, así como el total real del flete realizado.
El remito que es rechazado puede ser incorporado en una nueva orden de carga.
El motivo del rechazo se incorpora, provisoriamente, en forma textual.
Administracion de personal
Parámetros
Se ha agregado a los parámetros de sueldos, la posibilidad de indicar que formato de libro se desea utilizar.
Libro de sueldos
Ministerio de trabajo Provincia de Buenos Aires
Se ha agregado la posibilidad de emisión del libro de sueldos, acorde a las nuevas hojas rubricadas provistas por el Ministerio de trabajo de la provincia de Buenos Aires.
Conceptos
Formulas de conceptos
Traer valor de otro concepto
Se ha modificado la sintaxis del mismo para poder obtener no solo el valor calculado de otro conceptos, sino también parámetro 1, parámetro 2, y los parámetros fijos.
Sumatoria de conceptos
Se ha agregado la posibilidad que un concepto sea la resultante de la suma de otros conceptos enunciados en forma de rango.
Informes especiales
Comparativa legajo
Es un informe que permite comparar seis periodos comprendidos entre dos fechas, acumulando las liquidaciones por empleado que estén comprendidas en dicho rango.
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-07-2010
martes, 22 de junio de 2010
Facturacion electronica exportacion
Resumen de los puntos de este informe:
1) El 01-07 comienza a regir la facturación electrónica de exportación letra E.
2) Los puntos de venta Datacomsys actuales, para operaciones del exterior, tienen que ser deshabilitados.
3) Las empresas que hayan optado por el método RECEL, deben informar número de boca para ser dada de alta como manual.
4) La facturación electrónica, por cualquier método, otorga un CAE con vencimiento a los 10 días de emisión.
5) Se debería comenzar a utilizar el pedido Datacomsys como factura pro forma.
6) Se debe dejar de usar el formulario actual de impresión de facturas E
La explicación de los puntos anteriores, a continuación:
1) Según lo explicado en diversos informes enviados, el día 01-07-2010 comienza a regir la facturación electrónica obligatoria, para operaciones comerciales de exportación de bienes o servicios.
Una venta a Tierra del fuego también esta incluida en esta normativa.
Esto obliga a ciertos cambios en la forma de facturar, sea que se haya contratado la modificación del sistema o no.
2) Los cambios a efectuar redundan en que, a partir de esa fecha, las sucursales o puntos de venta asociados en Datacomsys para tal operatoria, deben ser parametrizados como deshabilitados, ya que la normativa indica que, tanto habiendo optado por el método de facturación en línea de la afip (RECEL), o bien por el método de Web services (RECE), la misma se debe realizar con números de bocas de expendio nuevos.
3) Las instalaciones que han contratado la modificación del sistema, ya han abierto las nuevas bocas de expendio y se han hecho las pruebas correspondientes.
Las instalaciones que han optado por el método de facturación en línea, deberán informar el número de boca asociada al método RECEL, para que la misma sea dada de alta en Datacomsys como sucursal Manual, similar a las que se utilizan para el ingreso de comprobantes manuales.
Luego, la incorporación de un comprobante RECEL, a Datacomsys, se realizará de la misma manera que el ingreso normal de comprobantes manuales, debiendo indicar importe, fecha y seleccionado el numero de un talonario prefijado, o bien ingresando el numero directamente, sin validación alguna.
No esta prevista diferencia alguna en el ingreso de una factura manual A o B, respecto a una E.
4) Es también importante tener en cuenta que tanto el método RECEL, (en línea), como el método RECE (Web services), otorgan comprobantes con un numero CAE, y un vencimiento del mismo.
El vencimiento del mismo es 10 días de emitido el comprobante.
Luego del vencimiento el comprobante no tiene valor alguno.
5) Varios responsables de instalaciones me han comentado que el vencimiento del CAE en 10 dias es un impedimento, ya que por ejemplo la factura se emite varias semanas antes de la efectiva venta, para presentar a bancos, enviar al mismo cliente u otras operaciones administrativas.
A tales efectos la única solución posible es no hacer la factura hasta el mismo momento de la efectiva venta, y utilizar lo más parecido que tiene el sistema a una factura, esto es el pedido.
El pedido Datacomsys tiene los mismos datos que una factura, y puede ser utilizado como pro forma.
Al momento de facturar efectivamente, se puede utilizar el pedido como modelo, y utilizar la opción de (Facturar Pedido).
Para utilizar el pedido como pro forma, se deberá modificar la salida impresa del mismo, adaptándola de manera que todos los pedidos a clientes del exterior o Tierra del fuego, en vez de ser impresos como Pedido, sean impresos como Factura pro forma.
Luego internamente el tratamiento es el mismo, es solamente un cambio en la impresión.
6) Los que hayan optado por la facturación en línea (RECEL), enviaran a su cliente la salida .PDF que se obtiene en la misma Web de Afip, pero aquellos que hayan optado por el método RECE (Web services), donde el que factura es Datacomsys, deberán dejar de usar los formularios preimpresos que tienen a este momento, ya que el CAI actual no va a servir mas a partir del 01-07, y deberían rediseñar o bien por lo menos imprimir formularios nuevos dejando el lugar del CAE y vencimiento en blanco.
Recuerdo que el comprobante electrónico puede ser impreso en una hoja en blanco, mientras cuente con el numero de comprobante, cuits, tipo afip, letra, importes, CAE y vencimiento.
No es obligatoria la impresión del código de barras, el que igualmente esta previsto en Datacomsys.
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
1) El 01-07 comienza a regir la facturación electrónica de exportación letra E.
2) Los puntos de venta Datacomsys actuales, para operaciones del exterior, tienen que ser deshabilitados.
3) Las empresas que hayan optado por el método RECEL, deben informar número de boca para ser dada de alta como manual.
4) La facturación electrónica, por cualquier método, otorga un CAE con vencimiento a los 10 días de emisión.
5) Se debería comenzar a utilizar el pedido Datacomsys como factura pro forma.
6) Se debe dejar de usar el formulario actual de impresión de facturas E
La explicación de los puntos anteriores, a continuación:
1) Según lo explicado en diversos informes enviados, el día 01-07-2010 comienza a regir la facturación electrónica obligatoria, para operaciones comerciales de exportación de bienes o servicios.
Una venta a Tierra del fuego también esta incluida en esta normativa.
Esto obliga a ciertos cambios en la forma de facturar, sea que se haya contratado la modificación del sistema o no.
2) Los cambios a efectuar redundan en que, a partir de esa fecha, las sucursales o puntos de venta asociados en Datacomsys para tal operatoria, deben ser parametrizados como deshabilitados, ya que la normativa indica que, tanto habiendo optado por el método de facturación en línea de la afip (RECEL), o bien por el método de Web services (RECE), la misma se debe realizar con números de bocas de expendio nuevos.
3) Las instalaciones que han contratado la modificación del sistema, ya han abierto las nuevas bocas de expendio y se han hecho las pruebas correspondientes.
Las instalaciones que han optado por el método de facturación en línea, deberán informar el número de boca asociada al método RECEL, para que la misma sea dada de alta en Datacomsys como sucursal Manual, similar a las que se utilizan para el ingreso de comprobantes manuales.
Luego, la incorporación de un comprobante RECEL, a Datacomsys, se realizará de la misma manera que el ingreso normal de comprobantes manuales, debiendo indicar importe, fecha y seleccionado el numero de un talonario prefijado, o bien ingresando el numero directamente, sin validación alguna.
No esta prevista diferencia alguna en el ingreso de una factura manual A o B, respecto a una E.
4) Es también importante tener en cuenta que tanto el método RECEL, (en línea), como el método RECE (Web services), otorgan comprobantes con un numero CAE, y un vencimiento del mismo.
El vencimiento del mismo es 10 días de emitido el comprobante.
Luego del vencimiento el comprobante no tiene valor alguno.
5) Varios responsables de instalaciones me han comentado que el vencimiento del CAE en 10 dias es un impedimento, ya que por ejemplo la factura se emite varias semanas antes de la efectiva venta, para presentar a bancos, enviar al mismo cliente u otras operaciones administrativas.
A tales efectos la única solución posible es no hacer la factura hasta el mismo momento de la efectiva venta, y utilizar lo más parecido que tiene el sistema a una factura, esto es el pedido.
El pedido Datacomsys tiene los mismos datos que una factura, y puede ser utilizado como pro forma.
Al momento de facturar efectivamente, se puede utilizar el pedido como modelo, y utilizar la opción de (Facturar Pedido).
Para utilizar el pedido como pro forma, se deberá modificar la salida impresa del mismo, adaptándola de manera que todos los pedidos a clientes del exterior o Tierra del fuego, en vez de ser impresos como Pedido, sean impresos como Factura pro forma.
Luego internamente el tratamiento es el mismo, es solamente un cambio en la impresión.
6) Los que hayan optado por la facturación en línea (RECEL), enviaran a su cliente la salida .PDF que se obtiene en la misma Web de Afip, pero aquellos que hayan optado por el método RECE (Web services), donde el que factura es Datacomsys, deberán dejar de usar los formularios preimpresos que tienen a este momento, ya que el CAI actual no va a servir mas a partir del 01-07, y deberían rediseñar o bien por lo menos imprimir formularios nuevos dejando el lugar del CAE y vencimiento en blanco.
Recuerdo que el comprobante electrónico puede ser impreso en una hoja en blanco, mientras cuente con el numero de comprobante, cuits, tipo afip, letra, importes, CAE y vencimiento.
No es obligatoria la impresión del código de barras, el que igualmente esta previsto en Datacomsys.
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
lunes, 7 de junio de 2010
Version 100528
Modificaciones importantes en Datacomsys 7.4 Versión 100423/0528
Ventas
Facturación
Facturación electrónica
A partir de la versión 100423, el sistema Datacomsys esta adaptado para la emisión de comprobantes electrónicos letras A y B, bajo el método RECE, según resolución Afip Nro.:2485.
La versión correspondiente a Junio 2010, a liberarse aproximadamente el día 25-06-2010, contemplara la emisión de comprobantes letra E.
Estadísticas
Comparativa por vendedor
Al menú de estadísticas comparativas, se ha agregado la posibilidad de emitir estadísticas comparativas por vendedor.
Padrón sobreexcedidos CABA
Se ha modificado el módulo de ventas, para que cumpla con la resolución 177/AGIP/2009, en lo referente a percepción de ingresos brutos para contribuyentes inscriptos como régimen simplificado y sobreexcedidos en sus compras.
Clientes
Legajo de clientes
Se ha modificado el legajo del cliente, en lo referente a la carga del tipo de inscripción en ingresos brutos que el contribuyente declare.
A tales efectos se debe optar por los tipos de inscripción posibles, que se despliegan en formato de combo.
Precios
Modificación de precios y costos por lote.
Calculo de costos en base a insumos.
Se han modificado estos procesos a efectos que el resultado pueda ser aplicado a precios o costos pendientes de activación.
Stock
Depósitos
Sectores por depósitos.
A partir de esta versión se puede mantener un catalogo de los distintos sectores que tiene un deposito.
El objetivo es poder visualizar, en las consultas de stock, en que lugar del deposito se encuentra el producto.
Un producto puede estar en varios sectores a la vez.
No se mantiene stock por cada sector
Afip
Percepciones ingresos brutos CABA
Padrón de sobrexcedidos
La actividad de incorporación del padrón de riesgo CABA, se ha modificado para complementarla con la incorporación del padrón de sobrexcedidos.
Parámetros ingresos brutos CABA
La actividad de parámetros de ingresos brutos CABA, se ha modificado para contemplar los datos correspondientes a la percepción por defecto que se debe realizar a contribuyentes sobreexcedidos y que no figuran en el respectivo padrón.
A tales efectos, se complementa la parametrizacion con los siguientes datos:
Base imponible: Calculada sobre la compra anual del contribuyente.
Alícuota de percepción: Es la alícuota que se le debe aplicar al contribuyente excedido.
Tipo de inscripción: Es el tipo de inscripción al que se debe evaluar.
Dataagent
Proceso de obtención de total de venta anual a clientes
Se ha ampliado el utilitario dataagent, para que calcule mensualmente el importe vendido a un cliente, a efectos de ser utilizado en el análisis de percepción a realizar en un comprobante de venta, según la resolución 177/AGIP2009.
Generales
Parámetros
Contadores por sucursal
A partir de esta versión se ha cambiado la lógica de obtención de números de contadores internos por sucursal.
A los mismos se accede mediante parámetros, parámetros de la sucursal, botón (Numeradores), botón (Método nuevo).
Los contadores antiguos se mantendrán visibles por cierto tiempo, sin tener función alguna en el sistema actual.
El proceso de instalación de la versión, ha copiado los valores de dichos contadores a lo que se denomina como método nuevo.
Padrón de sobreexcedidos CABA
Debido a la implementación del padrón de sobreexcedidos CABA, se ha generado una tabla de codificación de los distintos tipos de inscripción en ingresos brutos.
Tipos de inscripción en ingresos brutos
Se refiere a los tipos de inscripción por convenio multiláteral, contribuyente directo, exento y régimen simplificado CABA.
Facturación electrónica resolución 2485 y 2758
Parámetros especiales
Se han complementado y agregado ciertos tipos de parámetros que son necesarios para la confección de facturas electrónicas (A,B y E) bajo las resoluciones mencionadas.
Sucursales
Se ha habilitado un nuevo tipo de sucursal: E – Electrónica
La definición de impresoras se ha ampliado manteniendo los siguientes datos:
Solapa electrónicos:
Mantiene los datos correspondientes a la ubicación física de los certificados necesarios para la comunicación con afip, el nombre de los mismos, y las direcciones http: de los servidores de autentificación y procesamiento.
Solapa correo:
Mantiene los datos necesarios para el envío de los comprobantes electrónicos por email
Solapa pauta:
Mantiene el texto que se enviara como cuerpo del email automático con el comprobante electrónico adjunto.
Países
Se ha complementado el catalogo de países con los siguientes datos:
Cuit por persona jurídica
Cuit por persona física
Código otorgado por afip al país
Idioma asociado al país
Idiomas
Se ha complementado el catalogo de idiomas con los siguientes datos:
Código afip asociado al idioma
Unidades de medida
Se ha complementado la tabla de unidades de medida con los siguientes datos:
Código afip asociado a la unidad de medida.
Monedas
Se ha complementado la tabla de monedas con los siguientes datos:
Código afip asociado a la moneda.
Tipos de exportaciones
Mantiene los distintos tipos de exportaciones según afip, básicamente servicios o bienes.
Cláusulas de exportación
Mantiene las distintas cláusulas de exportaciones, ejemplo FOB, CIF, FCA y otras.
Tipos de comprobantes afip:
Mantiene la relación entre los distintos tipos de comprobantes del sistema y los tipos otorgados por afip.
Administración de personal
Catalogo de obras sociales
Se ha ampliado la clave de las obras sociales a seis dígitos alfanuméricos.
Formulas
Se ha ampliado el espectro de formulas de calculo de conceptos.
IMPORTANTE:
Todo lo referido a la utilización de facturación electrónica, se enviará en documento aparte a aquellas instalaciones que, por normativa o por decisión, se vean obligadas o hayan decidido utilizar este procedimiento.
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 28-05-2010
Ventas
Facturación
Facturación electrónica
A partir de la versión 100423, el sistema Datacomsys esta adaptado para la emisión de comprobantes electrónicos letras A y B, bajo el método RECE, según resolución Afip Nro.:2485.
La versión correspondiente a Junio 2010, a liberarse aproximadamente el día 25-06-2010, contemplara la emisión de comprobantes letra E.
Estadísticas
Comparativa por vendedor
Al menú de estadísticas comparativas, se ha agregado la posibilidad de emitir estadísticas comparativas por vendedor.
Padrón sobreexcedidos CABA
Se ha modificado el módulo de ventas, para que cumpla con la resolución 177/AGIP/2009, en lo referente a percepción de ingresos brutos para contribuyentes inscriptos como régimen simplificado y sobreexcedidos en sus compras.
Clientes
Legajo de clientes
Se ha modificado el legajo del cliente, en lo referente a la carga del tipo de inscripción en ingresos brutos que el contribuyente declare.
A tales efectos se debe optar por los tipos de inscripción posibles, que se despliegan en formato de combo.
Precios
Modificación de precios y costos por lote.
Calculo de costos en base a insumos.
Se han modificado estos procesos a efectos que el resultado pueda ser aplicado a precios o costos pendientes de activación.
Stock
Depósitos
Sectores por depósitos.
A partir de esta versión se puede mantener un catalogo de los distintos sectores que tiene un deposito.
El objetivo es poder visualizar, en las consultas de stock, en que lugar del deposito se encuentra el producto.
Un producto puede estar en varios sectores a la vez.
No se mantiene stock por cada sector
Afip
Percepciones ingresos brutos CABA
Padrón de sobrexcedidos
La actividad de incorporación del padrón de riesgo CABA, se ha modificado para complementarla con la incorporación del padrón de sobrexcedidos.
Parámetros ingresos brutos CABA
La actividad de parámetros de ingresos brutos CABA, se ha modificado para contemplar los datos correspondientes a la percepción por defecto que se debe realizar a contribuyentes sobreexcedidos y que no figuran en el respectivo padrón.
A tales efectos, se complementa la parametrizacion con los siguientes datos:
Base imponible: Calculada sobre la compra anual del contribuyente.
Alícuota de percepción: Es la alícuota que se le debe aplicar al contribuyente excedido.
Tipo de inscripción: Es el tipo de inscripción al que se debe evaluar.
Dataagent
Proceso de obtención de total de venta anual a clientes
Se ha ampliado el utilitario dataagent, para que calcule mensualmente el importe vendido a un cliente, a efectos de ser utilizado en el análisis de percepción a realizar en un comprobante de venta, según la resolución 177/AGIP2009.
Generales
Parámetros
Contadores por sucursal
A partir de esta versión se ha cambiado la lógica de obtención de números de contadores internos por sucursal.
A los mismos se accede mediante parámetros, parámetros de la sucursal, botón (Numeradores), botón (Método nuevo).
Los contadores antiguos se mantendrán visibles por cierto tiempo, sin tener función alguna en el sistema actual.
El proceso de instalación de la versión, ha copiado los valores de dichos contadores a lo que se denomina como método nuevo.
Padrón de sobreexcedidos CABA
Debido a la implementación del padrón de sobreexcedidos CABA, se ha generado una tabla de codificación de los distintos tipos de inscripción en ingresos brutos.
Tipos de inscripción en ingresos brutos
Se refiere a los tipos de inscripción por convenio multiláteral, contribuyente directo, exento y régimen simplificado CABA.
Facturación electrónica resolución 2485 y 2758
Parámetros especiales
Se han complementado y agregado ciertos tipos de parámetros que son necesarios para la confección de facturas electrónicas (A,B y E) bajo las resoluciones mencionadas.
Sucursales
Se ha habilitado un nuevo tipo de sucursal: E – Electrónica
La definición de impresoras se ha ampliado manteniendo los siguientes datos:
Solapa electrónicos:
Mantiene los datos correspondientes a la ubicación física de los certificados necesarios para la comunicación con afip, el nombre de los mismos, y las direcciones http: de los servidores de autentificación y procesamiento.
Solapa correo:
Mantiene los datos necesarios para el envío de los comprobantes electrónicos por email
Solapa pauta:
Mantiene el texto que se enviara como cuerpo del email automático con el comprobante electrónico adjunto.
Países
Se ha complementado el catalogo de países con los siguientes datos:
Cuit por persona jurídica
Cuit por persona física
Código otorgado por afip al país
Idioma asociado al país
Idiomas
Se ha complementado el catalogo de idiomas con los siguientes datos:
Código afip asociado al idioma
Unidades de medida
Se ha complementado la tabla de unidades de medida con los siguientes datos:
Código afip asociado a la unidad de medida.
Monedas
Se ha complementado la tabla de monedas con los siguientes datos:
Código afip asociado a la moneda.
Tipos de exportaciones
Mantiene los distintos tipos de exportaciones según afip, básicamente servicios o bienes.
Cláusulas de exportación
Mantiene las distintas cláusulas de exportaciones, ejemplo FOB, CIF, FCA y otras.
Tipos de comprobantes afip:
Mantiene la relación entre los distintos tipos de comprobantes del sistema y los tipos otorgados por afip.
Administración de personal
Catalogo de obras sociales
Se ha ampliado la clave de las obras sociales a seis dígitos alfanuméricos.
Formulas
Se ha ampliado el espectro de formulas de calculo de conceptos.
IMPORTANTE:
Todo lo referido a la utilización de facturación electrónica, se enviará en documento aparte a aquellas instalaciones que, por normativa o por decisión, se vean obligadas o hayan decidido utilizar este procedimiento.
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 28-05-2010
domingo, 6 de junio de 2010
Percepciones ingresos brutos CABA Sobreexcedidos
Percepciones y retenciones Ingresos brutos Capital Federal
Referencia: Padrón sobreexcedidos
El sistema Datacomsys se ha modificado para que, aquellas empresas agentes de percepción C.A.B.A., puedan utilizar el padrón de sobreexcedidos que dicha administracion distribuye desde su página Web.
Es importante aclarar que, dicho padrón de sobreexcedidos, no invalida al padrón de riesgo, sino que lo complementa, así como también es necesario que, el sistema administrativo del contribuyente, analice bajo ciertos criterios al sujeto percibido, y le aplique la percepción por sobreexcedidos por mas que no lo localice en el mencionado padrón.
Se considera como sobreexcedido, al cliente que no esta inscripto como régimen simplificado y cuya compra neta en el año inmediato anterior, ha superado los $144.000,00.- (Pesos ciento cuarenta y cuatro mil)
A tales efectos, este padrón determina por número de cuit la alícuota que corresponde percibir o retener para la operación a realizar siempre y cuando el sujeto sea considerado como sobreexcedido.
El padrón debe descargarse desde la página Web de Rentas e incorporarse al sistema trimestralmente.
En caso que el sujeto a percibir se encuentre en ambos padrones, prevalecerá el de riesgo.
En el caso que el sujeto a percibir no figure en ningún padrón, este dado de alta como régimen simplificado, y las operaciones que median entre el último día del mes anterior y un año hacia atrás, superen los $144.000,00.-, el sistema lo percibirá por un dos por ciento.
Estos valores por defecto pueden cambiar, y el sistema esta preparado para indicarlos en forma parametrica.
Se comprenderá, que básicamente el objetivo es penalizar a los contribuyentes inscriptos como regimen simplificado, y cuyas compras suponen que deberian haberse inscripto como contribuyentes directos o en convenio multilateral.
Por otro lado, si el contribuyente declara que la compra se realiza para bien de uso, no se deberia aplicar la alícuota de penalizacion.
Modificación del sistema:
Para poder cumplimentar con la resolución, en lo referente a la aplicación de alícuotas de percepción para contribuyentes sobreexcedidos, el sistema Datacomsys se ha modificado de la siguiente manera:
A) Obtención del padrón de contribuyentes sobreexcedidos
En esta operatoria el sistema NO estará presente, se deberá obtener por los medios que corresponda a cada agente de percepción el archivo que Rentas publicará trimestralmente en su página Web.
B) Descompresión del archivo .zip que contiene el padrón de contribuyentes.
En esta operatoria tampoco estará presente el sistema, el operador o encargado deberá descomprimir el archivo obtenido de la Web mediante Winzip, Winrar, u otro software que realice dicha operatoria.
El archivo descomprimido deberá guardarse en el Server del sistema, en la dirección c:\datacomsys\rentascf, y renombrado a excedidos.txt (respetar mayúsculas y minúsculas)
C) Incorporación del padrón de contribuyentes a la base de datos.
Una vez obtenido el padrón de contribuyentes y descomprimido, el mismo deberá ser incorporado a la base de datos.
A tales efectos se ha modificado el procedimiento actual de incorporación del padrón de riesgo, para que primero incorpore el padrón de sobreexcedidos.
O sea, primero se incorpora el padrón de sobreexcedidos, y a continuación se incorpora el padrón de riesgo.
En caso que el contribuyente se encuentre en ambos padrones, prevalecerá la alícuota determinada en al padrón de riesgo.
En este sentido es importante considerar que es un archivo de ciertas dimensiones, con 100.000 registros, lo que implica un tiempo también considerable de incorporación así como un aumento en el volumen de datos en unos 14 megas.
Téngase en cuenta que, durante la importación NO, se debe realizar operatoria alguna que implique la obtención de alícuotas, por lo que se recomienda que la misma se realice fuera del horario normal de trabajo.
El tiempo total de importación dependerá de la calidad de la maquina que este importando.
El proceso de importación DEBE ser realizado indefectiblemente desde el Server.
D) Aplicación
Percepciones
Al momento de realizar un pedido, presupuesto o factura, el sistema verificará el número de cuit del cliente en cuestión contra el consolidado de padrones incorporados al sistema, si el cuit es localizado se tomara la alícuota indicada en el padrón; sino, se aplicará la modalidad mencionada anteriormente, referida al total de operaciones netas y tipo de inscripción, y finalmente sino cumple con ninguna de estas reglas se lo percibirá por la alícuota asociada al carácter del sujeto.
E) Exportación a utilitarios.
La modificación debería ser transparente para la exportación de datos mediante el modulo Afip, para los distintos aplicativos vigentes.
F) Legajos de clientes
El legajo del cliente se ha modificado en lo referente a la incorporación del tipo de inscripción en ingresos brutos.
A tales efectos se ha creado una tabla con los tipos de inscripción que es accedida desde Parámetros.
Al instalar esta versión se han dado de alta los siguientes tipos de inscripción:
CM - Convenio multilateral
NCM- Contribuyente directo
EXE – Contribuyente exento
RSC - Régimen simplificado CABA
RSU- Régimen simplificado CABA bien de uso.
Asimismo se han modificado en forma automática los legajos de todos los clientes adaptándolos a esta nueva modalidad según el dato originalmente ingresado.
G) Calculo del total de operaciones anuales
Se ha agregado al utilitario DATAAGENT la obtención de dicho importe en forma mensual, todos los primeros días del mes, y de manera que el mismo este disponible para cada operación, en vez de calcularlo en el momento.
Consultas al padrón:
El consolidado de los padrones podrá ser consultado desde el panel “Trabajar padrón rentas CF”, mediante los métodos de búsqueda habituales.
También se han agregado botones de consultas al padrón en las actividades de: Alta de clientes, Consulta legajo cliente, Alta de proveedores y Consulta legajo proveedores.
En la consulta de los datos del padrón se ha agregado el motivo de inclusión, pudiendo ser “Riesgo” u “Origen”, depende cual ha prevalecido.
Modificaciones al padrón:
Se aplica la misma lógica que se utilizaba con el padrón de riesgo.
Métodos de cálculo:
Los métodos de cálculo no han cambiado respecto a la modalidad anterior.
Otros Parámetros:
En el panel “Trabajar padrón rentas CF”, se encuentra un botón pequeño con rotulo (Parámetros).
A la parametrizacion original se han agregado los siguientes datos:
Padrón sobreexcedidos habilitado: Permite utilizar o no el padrón de sobreexcedidos, en caso de estar destildado, el padrón no se incorpora al sistema.
Base imponible: corresponde al total de operaciones a evaluar para determinar de oficio si el contribuyente esta sobreexcedido o no.
Alícuota de percepción: es la alícuota a aplicar en caso de no estar registrado en los padrones y haber superado las operaciones según la base imponible.
Aplicado solamente a: Se refiere al tipo de inscripción que se incluye, en este momento se excluye la correspondiente a RSC – régimen simplificado.
Puesta en marcha:
La versión será instalada entre los días Viernes 28-05 y Viernes 04-06.
Los tipos de inscripción en ingresos brutos se generaran automáticamente.
Los legajos de los clientes se adaptaran a esta codificación en forma automática.
No tendrá efecto inmediato debido a que:
El sistema se parametrizara para que NO utilice el padrón de sobreexcedidos.
Luego quedara por parte de cada una de las instalaciones, la incorporación del padrón de sobreexcedidos, su habilitación y su utilización según se ha explicado anteriormente.
Ch 26-05-2010
Referencia: Padrón sobreexcedidos
El sistema Datacomsys se ha modificado para que, aquellas empresas agentes de percepción C.A.B.A., puedan utilizar el padrón de sobreexcedidos que dicha administracion distribuye desde su página Web.
Es importante aclarar que, dicho padrón de sobreexcedidos, no invalida al padrón de riesgo, sino que lo complementa, así como también es necesario que, el sistema administrativo del contribuyente, analice bajo ciertos criterios al sujeto percibido, y le aplique la percepción por sobreexcedidos por mas que no lo localice en el mencionado padrón.
Se considera como sobreexcedido, al cliente que no esta inscripto como régimen simplificado y cuya compra neta en el año inmediato anterior, ha superado los $144.000,00.- (Pesos ciento cuarenta y cuatro mil)
A tales efectos, este padrón determina por número de cuit la alícuota que corresponde percibir o retener para la operación a realizar siempre y cuando el sujeto sea considerado como sobreexcedido.
El padrón debe descargarse desde la página Web de Rentas e incorporarse al sistema trimestralmente.
En caso que el sujeto a percibir se encuentre en ambos padrones, prevalecerá el de riesgo.
En el caso que el sujeto a percibir no figure en ningún padrón, este dado de alta como régimen simplificado, y las operaciones que median entre el último día del mes anterior y un año hacia atrás, superen los $144.000,00.-, el sistema lo percibirá por un dos por ciento.
Estos valores por defecto pueden cambiar, y el sistema esta preparado para indicarlos en forma parametrica.
Se comprenderá, que básicamente el objetivo es penalizar a los contribuyentes inscriptos como regimen simplificado, y cuyas compras suponen que deberian haberse inscripto como contribuyentes directos o en convenio multilateral.
Por otro lado, si el contribuyente declara que la compra se realiza para bien de uso, no se deberia aplicar la alícuota de penalizacion.
Modificación del sistema:
Para poder cumplimentar con la resolución, en lo referente a la aplicación de alícuotas de percepción para contribuyentes sobreexcedidos, el sistema Datacomsys se ha modificado de la siguiente manera:
A) Obtención del padrón de contribuyentes sobreexcedidos
En esta operatoria el sistema NO estará presente, se deberá obtener por los medios que corresponda a cada agente de percepción el archivo que Rentas publicará trimestralmente en su página Web.
B) Descompresión del archivo .zip que contiene el padrón de contribuyentes.
En esta operatoria tampoco estará presente el sistema, el operador o encargado deberá descomprimir el archivo obtenido de la Web mediante Winzip, Winrar, u otro software que realice dicha operatoria.
El archivo descomprimido deberá guardarse en el Server del sistema, en la dirección c:\datacomsys\rentascf, y renombrado a excedidos.txt (respetar mayúsculas y minúsculas)
C) Incorporación del padrón de contribuyentes a la base de datos.
Una vez obtenido el padrón de contribuyentes y descomprimido, el mismo deberá ser incorporado a la base de datos.
A tales efectos se ha modificado el procedimiento actual de incorporación del padrón de riesgo, para que primero incorpore el padrón de sobreexcedidos.
O sea, primero se incorpora el padrón de sobreexcedidos, y a continuación se incorpora el padrón de riesgo.
En caso que el contribuyente se encuentre en ambos padrones, prevalecerá la alícuota determinada en al padrón de riesgo.
En este sentido es importante considerar que es un archivo de ciertas dimensiones, con 100.000 registros, lo que implica un tiempo también considerable de incorporación así como un aumento en el volumen de datos en unos 14 megas.
Téngase en cuenta que, durante la importación NO, se debe realizar operatoria alguna que implique la obtención de alícuotas, por lo que se recomienda que la misma se realice fuera del horario normal de trabajo.
El tiempo total de importación dependerá de la calidad de la maquina que este importando.
El proceso de importación DEBE ser realizado indefectiblemente desde el Server.
D) Aplicación
Percepciones
Al momento de realizar un pedido, presupuesto o factura, el sistema verificará el número de cuit del cliente en cuestión contra el consolidado de padrones incorporados al sistema, si el cuit es localizado se tomara la alícuota indicada en el padrón; sino, se aplicará la modalidad mencionada anteriormente, referida al total de operaciones netas y tipo de inscripción, y finalmente sino cumple con ninguna de estas reglas se lo percibirá por la alícuota asociada al carácter del sujeto.
E) Exportación a utilitarios.
La modificación debería ser transparente para la exportación de datos mediante el modulo Afip, para los distintos aplicativos vigentes.
F) Legajos de clientes
El legajo del cliente se ha modificado en lo referente a la incorporación del tipo de inscripción en ingresos brutos.
A tales efectos se ha creado una tabla con los tipos de inscripción que es accedida desde Parámetros.
Al instalar esta versión se han dado de alta los siguientes tipos de inscripción:
CM - Convenio multilateral
NCM- Contribuyente directo
EXE – Contribuyente exento
RSC - Régimen simplificado CABA
RSU- Régimen simplificado CABA bien de uso.
Asimismo se han modificado en forma automática los legajos de todos los clientes adaptándolos a esta nueva modalidad según el dato originalmente ingresado.
G) Calculo del total de operaciones anuales
Se ha agregado al utilitario DATAAGENT la obtención de dicho importe en forma mensual, todos los primeros días del mes, y de manera que el mismo este disponible para cada operación, en vez de calcularlo en el momento.
Consultas al padrón:
El consolidado de los padrones podrá ser consultado desde el panel “Trabajar padrón rentas CF”, mediante los métodos de búsqueda habituales.
También se han agregado botones de consultas al padrón en las actividades de: Alta de clientes, Consulta legajo cliente, Alta de proveedores y Consulta legajo proveedores.
En la consulta de los datos del padrón se ha agregado el motivo de inclusión, pudiendo ser “Riesgo” u “Origen”, depende cual ha prevalecido.
Modificaciones al padrón:
Se aplica la misma lógica que se utilizaba con el padrón de riesgo.
Métodos de cálculo:
Los métodos de cálculo no han cambiado respecto a la modalidad anterior.
Otros Parámetros:
En el panel “Trabajar padrón rentas CF”, se encuentra un botón pequeño con rotulo (Parámetros).
A la parametrizacion original se han agregado los siguientes datos:
Padrón sobreexcedidos habilitado: Permite utilizar o no el padrón de sobreexcedidos, en caso de estar destildado, el padrón no se incorpora al sistema.
Base imponible: corresponde al total de operaciones a evaluar para determinar de oficio si el contribuyente esta sobreexcedido o no.
Alícuota de percepción: es la alícuota a aplicar en caso de no estar registrado en los padrones y haber superado las operaciones según la base imponible.
Aplicado solamente a: Se refiere al tipo de inscripción que se incluye, en este momento se excluye la correspondiente a RSC – régimen simplificado.
Puesta en marcha:
La versión será instalada entre los días Viernes 28-05 y Viernes 04-06.
Los tipos de inscripción en ingresos brutos se generaran automáticamente.
Los legajos de los clientes se adaptaran a esta codificación en forma automática.
No tendrá efecto inmediato debido a que:
El sistema se parametrizara para que NO utilice el padrón de sobreexcedidos.
Luego quedara por parte de cada una de las instalaciones, la incorporación del padrón de sobreexcedidos, su habilitación y su utilización según se ha explicado anteriormente.
Ch 26-05-2010
lunes, 22 de febrero de 2010
Facturacion electronica
Resolución general Afip Nro. 2758/2010
Referente a operaciones de exportación
Régimen especial de emisión y almacenamiento electrónico de comprobantes originales
Facturación electrónica Resolución 2485
Generalidades: A efectos de cumplimentar con la resolución de referencia, en los meses de diciembre 2009 y enero 2010, hice circular entre las distintas instalaciones, información referente y consultas sobre el alcance de esta resolución para cada empresa en particular.
El objetivo era tener presente cuales instalaciones Datacomsys se encontraban alcanzadas por esta modalidad de facturación.
La resolución consiste, básicamente, en la implementación por parte de la Afip, de una modalidad de facturación en la que, comprobante por comprobante, el mismo es autorizado en tiempo real por dicha agencia.
También durante el año 2009 comenté, personalmente, que la Afip estaba implementando esta modalidad de facturación para ciertas actividades en particular, ejemplo la mía, donde a partir de octubre 2009 ustedes reciben mes a mes un comprobante electrónico por mis honorarios.
Esta modalidad va a ir incrementándose en su aplicación, a distintas actividades, hasta que en algún momento, cualquier empresa de las denominadas auto impresores, o bien con talonario preimpreso, deberán cumplir con ella.
Solamente quedarían excluidas las emisiones con controlador fiscal, aunque las versiones mas modernas de estos, ya necesitan una conexión a Internet para validar con la afip la emisión de comprobantes.
A finales de diciembre 2009, circuló que en este año se aplicaría esta modalidad a las facturas de exportación, las que se emiten con letra E.
Finalmente se publico la norma, la que puede ser consultada en la dirección:
http://biblioteca.afip.gov.ar/gateway.dll/Normas/ResolucionesGenerales/reag01002758_2010_01_20.xml
Es importante tener en cuenta que, una venta a Tierra del Fuego, esta considerada como una exportación.
En la resolución se explica que 30 empresas comienzan con esta modalidad el día 01-03-2010 y el resto a partir del 01-05-2010.
En definitiva, una factura electrónica es un comprobante que se valida en tiempo real contra los servidores de la Afip, siendo esta ultima la que autoriza, o no, la emisión del mismo; una vez autorizada se puede enviar por mail, y puede ser impresa en cualquier papel, que igualmente tendrá valor legal, debido a que tiene un CAE (Código de autorización electrónico), a diferencia de los comprobantes preimpresos que tienen CAI (Código de autorización Impreso).
Este procedimiento que, a primera vista presupone un control contra la venta informal, y parecería estar diseñado para entorpecer la venta formal, le permite a la Afip, como decía, autorizar o no el comprobante a emitir; en caso que la empresa emisora tenga algún inconveniente, presentación no realizada, impuesto mal pago o circunstancia similares, el comprobante podría no ser autorizado y por lo tanto no emitirse.
Lo mismo para con fallas técnicas, propias de la empresa emisora, propias de la empresa que presta el servicio de Internet, o propias de los servidores de la Afip; o sea, ante fallas técnicas, no se podrá emitir el comprobante.
Demás esta decir que en la agencia quedan los datos referentes a la venta.
También es importante aclarar, como pretendo en los párrafos que siguen, que esta modalidad no solo implica una modificación al sistema de gestión de ventas, sino que tiene repercusiones impositivas, administrativas y de representación en la Afip, por lo que considero que la forma de aplicación de la misma debe ser realizada en conjunto con el responsable administrativo de la empresa, el contador o estudio contable que asesora, y por supuesto el proveedor del sistema.
O sea, y con riesgo de ser reiterativo, no es un tema entre “El contador y el de sistemas”.
Lo que sigue a continuación, es aplicable a la emisión de comprobantes electrónicos, facturas, debitos o créditos, independientemente que sean de exportación o dentro del país, recordando que la resolución de referencia que entra en vigencia esta solamente para la emisión de comprobantes letra E.
Modalidades:
La afip propone distintas modalidades de uso para la facturación electrónica, dependiendo de la actividad y de la cantidad de comprobantes a emitir.
Básicamente existen dos métodos RECE (Régimen de emisión de comprobantes electrónicos) y RECEL (Régimen de emisión de comprobantes electrónicos en línea).
Método RECE:
El método RECE es aquel por el que una maquina remota a la Afip, y mediante ciertos procedimientos, se comunica con la agencia y en tiempo real le envía datos de facturación para obtener el mencionado CAE (Código de autorización electrónico).
O sea que existe una forma en la cual un sistema informático se comunica en tiempo real con otra maquina en la Afip, le envía ciertos datos y obtiene la autorización correspondiente.
Esto es posible mediante lo que se denominan Web Services, o sea que la afip publica de cierta forma, un servicio que puede ser consumido mediante Internet por un sistema externo a la propia Afip.
Este procedimiento utiliza una forma de comunicación específica, o protocolo, que se llama SOAP, y un lenguaje, también específico, para transferir datos, que se denomina XML.
Mas allá de las siglas y denominaciones, esto permite que un sistema cualquiera, hecho en cualquier lenguaje y que mantenga sus datos en cualquier base de datos, y mientras tenga la posibilidad de “conversar” en este protocolo y transferir datos en ese lenguaje, podrá comunicarse con la afip y transferir y recibir datos.
Ahora bien, esto también requiere de cierta seguridad, o sea, no solamente la capacidad de dialogar entre las maquinas, sino también la seguridad que quien dialoga sea quien realmente pretende ser.
Esto se realiza mediante la obtención de lo que se denominan “Certificados”, y “Firmas Digitales”, estos certificados y firmas son específicas para cada contribuyente y se obtienen mediante una serie de procedimientos, complejos, de emisión y autorización por parte de la Agencia, donde interviene el contribuyente y el proveedor del sistema mediante su clave fiscal y la modalidad de “Aceptación de designación”, específicamente “Administración de certificados digitales”, algo similar a lo que se realiza para con las impresoras fiscales.
En resumen, el método RECE es aquel por el cual un sistema informático se comunica con los servidores de Afip, enviándole un certificado y firma digital, y ante la autorización de la Afip, envía una serie de datos con un formato especial para la obtención de un numero CAE que será utilizado en la emisión de un comprobante de ventas.
Este método RECE, tiene a su vez la particularidad que puede ser utilizado desde un sistema informatico de terceros (Datacomsys por ejemplo), o bien puede ser utilizado desde el aplicativo RECE que ofrece la Afip, y que se incorpora al utilitario SIAP, pudiendo descargarse de la dirección:
http://www.afip.gov.ar/Aplicativos/frmAplicativoDetalle.aspx?UTWBOi0%2fjrCt9WwLwm5WjyI8StGVAi0imaXx0oabgS0%3d
O sea, la Afip provee de un modulo Siap que permite realizar la comunicación con la Afip bajo la modalidad anteriormente descripta.
Los datos en el modulo RECE pueden ser incorporados manualmente, o bien desde un archivo de exportación, similar a los que se utilizan para los otros utilitarios (SIFERE, IB mensual, SICOSS, etc.), luego el utilitario genera un archivo que debe ser presentado por ventanilla fiscal, y la Afip asegura que la respuesta se realiza en unos 10 minutos.
La respuesta consiste en la autorización o no de los datos enviados y el numero CAE correspondiente.
Esta forma del método RECE, obliga a generar los datos en forma manual en el modulo RECE/SIAP, y ante la autorización incorporarlos en el sistema, o bien generar los comprobantes en el sistema, realizar la migración, presentar el comprobante en la ventanilla fiscal, y luego incorporar los resultados.
Hasta aquí entonces vemos que el método RECE permite obtener en forma automática el numero CAE, teniendo la posibilidad de incorporar el método a un sistema administrativo en uso (Datacomsys) a la manera de web services o bien exportación al RECE/SIAP, o sino con la utilización directa del modulo RECE incorporado al SIAP, generando ahí los datos y luego incorporarlos manualmente en el sistema administrativo.
Método RECEL:
El método RECEL es aquel por el cual el contribuyente tiene la posibilidad de generar un comprobante electrónico, directamente en la web de la afip.
El procedimiento se realiza ingresando con clave fiscal, y una demo del mismo puede ser visualizada en la dirección:
http://www.afip.gob.ar/fe/documentos/DemofacturaEnLinea/fa.htm
Utilizando este método, no hay ningún tipo de comunicación entre el sistema administrativo de ventas, (Datacomsys), y la agencia; debiendo replicar manualmente en el sistema, al comprobante realizado en la web.
El formato de la impresión es obligatorio al que genera la Afip, y la factura puede ser mantenida en las maquinas del contribuyente en formato PDF.
Una copia queda siempre en la Afip para ser consultada o vuelta a imprimir.
Hasta aquí intenté dar un panorama sobre la resolución, y una breve explicación sobre los métodos de utilización posibles, a continuación intentaré explicar el diseño Datacomsys que se adecua a cada una de estas modalidades.
Por mas información, la Afip provee una página de consultas y respuestas frecuentes referidas a facturación electrónica, en la dirección:
http://www.afip.gov.ar/genericos/guiavirtual/directorio_subcategoria.aspx?id_nivel1=562&id_nivel2=603
Facturación electrónica Datacomsys:
La facturación electrónica, por resolución, obliga a tener una nueva boca de venta habilitada como tal, en la afip.
En este sentido, al momento de habilitar dicha sucursal dentro de los parámetros Datacomsys, la misma será definida con un nuevo tipo de sucursal denominado:
E – Sucursal electrónica.
A partir de esta parametrizacion el sistema trabajará específicamente para facturación electrónica.
Como mencioné anteriormente, están previstos dos métodos, el método RECE y el método RECEL.
Método RECEL:
Bajo el método RECEL, donde los comprobantes se realizan en línea en la web de la afip, y bajo clave fiscal, no hay muchas posibilidades de cambio, si bien esa boca de ventas será definida como electrónica y tendrá un numero especifico, los comprobantes realizados en la web de afip, deberán ser retipeados como comprobantes manuales, como aquellos comprobantes que se utilizan cuando hay cortes de energía o problemas de comunicaciones.
Este procedimiento es el mas sencillo, y como es de esperar el menos controlado, ya que no hay manera de corroborar que aquello que se generó como comprobante en la web afip, sea idéntico a lo que se incorporó como comprobante manual, tanto en su calidad de información, totales y numero CAE y vencimiento del mismo.
Desde el lado de la Afip, el aplicativo que se utiliza no tiene ningún tipo de relación con la base de datos, como se puede visualizar en la demostración que se sugirió ver anteriormente, tanto el número de cuit del cliente, los datos de los productos de venta, unidades de medida, precios unitarios, etc., deben ser incorporados manualmente, no habiendo posibilidad, siquiera, de copiar un comprobante anterior a uno nuevo, similar a hacer una factura con un procesador de texto.
Pero insisto en que es el procedimiento mas sencillo, menos costoso, y quedará en cada instalación evaluar si, por la cantidad de comprobantes y necesidades de control, este procedimiento se ajusta las necesidades.
Método RECE:
Por el método RECE las modificaciones al sistema son bastante mas complejas que en el RECEL.
Se prevé un panel de trabajo similar al que es utilizado en la actualidad por aquellas instalaciones que cuentan con impresoras fiscales, o bien con varias maquinas facturadoras y un solo lugar de impresión.
En estos casos, lo que el operador de facturación realiza, es lo que se denomina una minuta de venta, la minuta de venta contiene los mismos datos que la factura final, pero es en definitiva una pro forma, a la espera de la confirmación.
En el caso de las facturas fiscales, la confirmación radica precisamente en la impresión fiscal, y en el caso de las facturas electrónicas, la confirmación es aquella que denominamos anteriormente como CAE, para que luego si, puedan ser impresas.
O sea, así como la impresión fiscal consta de un dispositivo externo a Datacomsys, denominado impresora fiscal; la impresión electrónica consta de un dispositivo externo que es el servidor de la Afip.
Entonces, la emisión de comprobantes electrónicos Datacomsys, consistirá de dos pasos, uno donde el operador genera la minuta de venta, sea factura, debito o crédito y otro paso donde se obtiene la autorización de dicho comprobante.
Este ultimo paso se realizará desde un panel especial: “Minutas electrónicas pendientes”, desde donde se podrán realizar distintas operaciones: Autorizar la minuta mediante web services, autorizar la minuta mediante la generación de un archivo de exportación para el utilitario RECE/SIAP, o bien eliminar la minuta.
Si la empresa ha decidido la utilización del utilitario RECE/SIAP, se comprenderá que, ante la emisión del archivo de exportación de datos, Datacomsys pierde la traza y queda a la espera que dicho archivo sea nuevamente incorporado.
Al incorporar el archivo de transferencia los comprobantes que han sido rechazados se eliminarán, y a los que han sido aceptados se les incorporará el CAE, y se convertirán en comprobante reales del sistema.
Si por el contrario, la empresa ha decidido la utilización del método basado en web services, el panel de minutas pendientes de aprobación, quedara suspendido a la espera de la respuesta desde el servidor de la afip.
Siendo el procedimiento interno a realizar, resumidamente, el siguiente:
Ante una minuta electrónica pendiente, el sistema administrativo tiene que enviar un requerimiento denominado: Ticket de acceso, que contiene las firmas digitales y certificados realizados con anterioridad, este y cualquier otro envío se realiza con los mencionados web services, protocolos, etc., y teniendo sincronizada la fecha y hora entre ambas maquinas, y con internet funcionando correctamente.
Una vez verificado en la Afip el ticket de acceso, el mismo se remite nuevamente al sistema y es valido por 5 horas, pudiendo este tiempo cambiar según disposición de la afip, este archivo devuelto contiene lo que se llama Token y Sign, que en definitiva son datos que permitirán que el contribuyente envié sus comprobantes para verificar.
Una vez obtenido este ticket de acceso, que por un lado valida que el contribuyente sea el contribuyente, y que el mismo este autorizado a utilizar este servicio, el sistema puede enviar los datos correspondientes al comprobante electrónico a verificar.
Finalmente, si todo esta bien, se obtiene el CAE y se archiva definitivamente el comprobante.
También el diseño contempla la posibilidad de acumular minutas pendientes y enviarlas en un momento dado, por ejemplo a la noche.
Como se puede ver, estos procesos donde habrá o puede haber cierta espera entre el momento que se realiza el comprobante y su aprobación, obligará a tener en cuenta que la facturación deja de ser una operatoria instantánea, donde la misma se realiza al momento de ser necesaria, sino que seria prudente poder organizarla de manera que no se generen cuellos de botella en los que por dar un ejemplo la factura esta siendo esperada por un cliente, un transporte, o alguien; y que lamentablemente se verá obligado a esperar la autorización que entrega un tercero, en este caso la Afip.
Y esta autorización, como se prevé, puede lentificarse por motivos propios del contribuyente: maquinas fuera de red, problemas de fechas y horas erróneas, certificados, problemas de red, problemas de Internet, etc.; o bien lisa y llanamente por problemas en el servidor de la Afip, sea saturación de autorizaciones a realizar, o problemas técnicos de ellos.
Para la facturación por decirlo de alguna manera, instantánea, se debería utilizar el método de las impresoras fiscales, aunque como se sabe, estas no prevén la emisión de comprobantes letra E.
Resumen de lo expuesto:
La resolución 2485 de Afip prevé la incorporación de contribuyentes al régimen de facturación electrónica de manera progresiva.
La resolución 2758 obliga a aquellos contribuyentes que emiten facturas letra E, a comenzar a realizar dicha operación con comprobantes electrónicos.
La misma resolución se aplica a partir del 01-03-2010 para 30 empresas específicas, comenzando todas las restantes el día 01-05-2010.
En todos los casos, la facturación electrónica requiere de una nueva boca habilitada en Afip.
Existen dos modalidades de trabajo para la generación de facturas electrónicas, un método denominado RECE y otro denominado RECEL.
El método RECEL es aquel por el cual el contribuyente genera el comprobante electrónico en la web de Afip, ese comprobante puede ser convertido a un archivo PDF y enviado al cliente o bien resguardado en la maquina del contribuyente.
El método RECEL, no contempla códigos de clientes, productos, precios y otros que se mantienen en el sistema administrativo.
El comprobante así emitido, deberá ser incorporado al sistema Datacomsys en forma manual, como si fuera un comprobante hecho a mano.
El método RECE es aquel por el cual el contribuyente genera el comprobante electrónico mediante software instalado en su maquina.
Este software utiliza una forma de comunicación para registrarse en los servidores de la Afip, enviarle datos y obtener el código CAE que autoriza al comprobante a emitir.
Este método obliga a ciertos cambios, tanto en el sistema de gestión de ventas, así como en la forma administrativa de usarlos.
El software utilizado para el método RECE, puede ser en la forma de un módulo que se incorpora en el SIAP, o bien un desarrollo especial en el sistema administrativo del contribuyente.
Si se usa el módulo RECE en el aplicativo SIAP, el sistema administrativo genera un archivo de transferencia que se incoporpora al modulo RECE y luego desde ese modulo se genera un nuevo archivo a ser presentado por ventanilla electrónica de Afip y, una vez validado, ese mismo aplicativo genera un nuevo archivo de transferencia que es incorporado al sistema administrativo.
Si no se usa el modulo RECE del SIAP, y se utiliza un desarrollo especial en el sistema administrativo, este desarrollo se encarga de comunicarse con la Afip, registrase, validarse y obtener el CAE.
Esto requiere de ciertos trámites a realizar con clave fiscal, por parte del contribuyente y del desarrollador del software.
En todos los casos, la instrucción de los operadores, el estado técnico de los equipos, la red interna, e Internet se vislumbran como herramientas fundamentales para el correcto uso en tiempo y forma de estos métodos.
Finales:
Desde fines del año pasado que intente circular entre las distintas instalaciones la información que obtenía sobre facturación electrónica.
A fines de Enero 2010 solicite confirmación sobre aquellas empresas que se encontraban alcanzadas por esta resolución.
Entiendo que, a primera vista, puede considerarse un “inconveniente”, que deberá ser resuelto por el Contador y el de Sistemas, pero debido a la profundidad del cambio, así como las distintas operatorias a realizar con clave fiscal, certificados, firmas digitales y otros, y la modificación en las conductas de facturación de los operadores, insisto en extender esta resolución por lo menos a los encargados de las distintas administraciones que utilizan Datacomsys.
Nuevamente reitero la necesidad de tener conocimiento sobre si su empresa es alcanzada por esta resolución, y en caso afirmativo, que tipo de método va a utilizar, ya que independientemente de los tramites a realizar por uno o por otro, el método mas complejo, denominado RECE donde los comprobantes se autorizan por el propio sistema, requiere de un desarrollo y adquisición de productos de terceros, que deriva en la necesidad de trasladar dicho costo, en forma proporcional y por única vez, a aquellos interesados en utilizarlo.
Esta información es necesario tenerla para la primera semana de Marzo 2010.
Si su empresa recibió este documento es porque, a mi entender, esta incluida en la resolución de referencia, y por lo menos ha hecho un comprobante de exportación en el año que media entre el 01-02-09 y 31-01-10.
Este documento se encuentra publicado en www.datacomsys.blogspot.com
Carlos A.L.Herrero 22-02-2010
Referente a operaciones de exportación
Régimen especial de emisión y almacenamiento electrónico de comprobantes originales
Facturación electrónica Resolución 2485
Generalidades: A efectos de cumplimentar con la resolución de referencia, en los meses de diciembre 2009 y enero 2010, hice circular entre las distintas instalaciones, información referente y consultas sobre el alcance de esta resolución para cada empresa en particular.
El objetivo era tener presente cuales instalaciones Datacomsys se encontraban alcanzadas por esta modalidad de facturación.
La resolución consiste, básicamente, en la implementación por parte de la Afip, de una modalidad de facturación en la que, comprobante por comprobante, el mismo es autorizado en tiempo real por dicha agencia.
También durante el año 2009 comenté, personalmente, que la Afip estaba implementando esta modalidad de facturación para ciertas actividades en particular, ejemplo la mía, donde a partir de octubre 2009 ustedes reciben mes a mes un comprobante electrónico por mis honorarios.
Esta modalidad va a ir incrementándose en su aplicación, a distintas actividades, hasta que en algún momento, cualquier empresa de las denominadas auto impresores, o bien con talonario preimpreso, deberán cumplir con ella.
Solamente quedarían excluidas las emisiones con controlador fiscal, aunque las versiones mas modernas de estos, ya necesitan una conexión a Internet para validar con la afip la emisión de comprobantes.
A finales de diciembre 2009, circuló que en este año se aplicaría esta modalidad a las facturas de exportación, las que se emiten con letra E.
Finalmente se publico la norma, la que puede ser consultada en la dirección:
http://biblioteca.afip.gov.ar/gateway.dll/Normas/ResolucionesGenerales/reag01002758_2010_01_20.xml
Es importante tener en cuenta que, una venta a Tierra del Fuego, esta considerada como una exportación.
En la resolución se explica que 30 empresas comienzan con esta modalidad el día 01-03-2010 y el resto a partir del 01-05-2010.
En definitiva, una factura electrónica es un comprobante que se valida en tiempo real contra los servidores de la Afip, siendo esta ultima la que autoriza, o no, la emisión del mismo; una vez autorizada se puede enviar por mail, y puede ser impresa en cualquier papel, que igualmente tendrá valor legal, debido a que tiene un CAE (Código de autorización electrónico), a diferencia de los comprobantes preimpresos que tienen CAI (Código de autorización Impreso).
Este procedimiento que, a primera vista presupone un control contra la venta informal, y parecería estar diseñado para entorpecer la venta formal, le permite a la Afip, como decía, autorizar o no el comprobante a emitir; en caso que la empresa emisora tenga algún inconveniente, presentación no realizada, impuesto mal pago o circunstancia similares, el comprobante podría no ser autorizado y por lo tanto no emitirse.
Lo mismo para con fallas técnicas, propias de la empresa emisora, propias de la empresa que presta el servicio de Internet, o propias de los servidores de la Afip; o sea, ante fallas técnicas, no se podrá emitir el comprobante.
Demás esta decir que en la agencia quedan los datos referentes a la venta.
También es importante aclarar, como pretendo en los párrafos que siguen, que esta modalidad no solo implica una modificación al sistema de gestión de ventas, sino que tiene repercusiones impositivas, administrativas y de representación en la Afip, por lo que considero que la forma de aplicación de la misma debe ser realizada en conjunto con el responsable administrativo de la empresa, el contador o estudio contable que asesora, y por supuesto el proveedor del sistema.
O sea, y con riesgo de ser reiterativo, no es un tema entre “El contador y el de sistemas”.
Lo que sigue a continuación, es aplicable a la emisión de comprobantes electrónicos, facturas, debitos o créditos, independientemente que sean de exportación o dentro del país, recordando que la resolución de referencia que entra en vigencia esta solamente para la emisión de comprobantes letra E.
Modalidades:
La afip propone distintas modalidades de uso para la facturación electrónica, dependiendo de la actividad y de la cantidad de comprobantes a emitir.
Básicamente existen dos métodos RECE (Régimen de emisión de comprobantes electrónicos) y RECEL (Régimen de emisión de comprobantes electrónicos en línea).
Método RECE:
El método RECE es aquel por el que una maquina remota a la Afip, y mediante ciertos procedimientos, se comunica con la agencia y en tiempo real le envía datos de facturación para obtener el mencionado CAE (Código de autorización electrónico).
O sea que existe una forma en la cual un sistema informático se comunica en tiempo real con otra maquina en la Afip, le envía ciertos datos y obtiene la autorización correspondiente.
Esto es posible mediante lo que se denominan Web Services, o sea que la afip publica de cierta forma, un servicio que puede ser consumido mediante Internet por un sistema externo a la propia Afip.
Este procedimiento utiliza una forma de comunicación específica, o protocolo, que se llama SOAP, y un lenguaje, también específico, para transferir datos, que se denomina XML.
Mas allá de las siglas y denominaciones, esto permite que un sistema cualquiera, hecho en cualquier lenguaje y que mantenga sus datos en cualquier base de datos, y mientras tenga la posibilidad de “conversar” en este protocolo y transferir datos en ese lenguaje, podrá comunicarse con la afip y transferir y recibir datos.
Ahora bien, esto también requiere de cierta seguridad, o sea, no solamente la capacidad de dialogar entre las maquinas, sino también la seguridad que quien dialoga sea quien realmente pretende ser.
Esto se realiza mediante la obtención de lo que se denominan “Certificados”, y “Firmas Digitales”, estos certificados y firmas son específicas para cada contribuyente y se obtienen mediante una serie de procedimientos, complejos, de emisión y autorización por parte de la Agencia, donde interviene el contribuyente y el proveedor del sistema mediante su clave fiscal y la modalidad de “Aceptación de designación”, específicamente “Administración de certificados digitales”, algo similar a lo que se realiza para con las impresoras fiscales.
En resumen, el método RECE es aquel por el cual un sistema informático se comunica con los servidores de Afip, enviándole un certificado y firma digital, y ante la autorización de la Afip, envía una serie de datos con un formato especial para la obtención de un numero CAE que será utilizado en la emisión de un comprobante de ventas.
Este método RECE, tiene a su vez la particularidad que puede ser utilizado desde un sistema informatico de terceros (Datacomsys por ejemplo), o bien puede ser utilizado desde el aplicativo RECE que ofrece la Afip, y que se incorpora al utilitario SIAP, pudiendo descargarse de la dirección:
http://www.afip.gov.ar/Aplicativos/frmAplicativoDetalle.aspx?UTWBOi0%2fjrCt9WwLwm5WjyI8StGVAi0imaXx0oabgS0%3d
O sea, la Afip provee de un modulo Siap que permite realizar la comunicación con la Afip bajo la modalidad anteriormente descripta.
Los datos en el modulo RECE pueden ser incorporados manualmente, o bien desde un archivo de exportación, similar a los que se utilizan para los otros utilitarios (SIFERE, IB mensual, SICOSS, etc.), luego el utilitario genera un archivo que debe ser presentado por ventanilla fiscal, y la Afip asegura que la respuesta se realiza en unos 10 minutos.
La respuesta consiste en la autorización o no de los datos enviados y el numero CAE correspondiente.
Esta forma del método RECE, obliga a generar los datos en forma manual en el modulo RECE/SIAP, y ante la autorización incorporarlos en el sistema, o bien generar los comprobantes en el sistema, realizar la migración, presentar el comprobante en la ventanilla fiscal, y luego incorporar los resultados.
Hasta aquí entonces vemos que el método RECE permite obtener en forma automática el numero CAE, teniendo la posibilidad de incorporar el método a un sistema administrativo en uso (Datacomsys) a la manera de web services o bien exportación al RECE/SIAP, o sino con la utilización directa del modulo RECE incorporado al SIAP, generando ahí los datos y luego incorporarlos manualmente en el sistema administrativo.
Método RECEL:
El método RECEL es aquel por el cual el contribuyente tiene la posibilidad de generar un comprobante electrónico, directamente en la web de la afip.
El procedimiento se realiza ingresando con clave fiscal, y una demo del mismo puede ser visualizada en la dirección:
http://www.afip.gob.ar/fe/documentos/DemofacturaEnLinea/fa.htm
Utilizando este método, no hay ningún tipo de comunicación entre el sistema administrativo de ventas, (Datacomsys), y la agencia; debiendo replicar manualmente en el sistema, al comprobante realizado en la web.
El formato de la impresión es obligatorio al que genera la Afip, y la factura puede ser mantenida en las maquinas del contribuyente en formato PDF.
Una copia queda siempre en la Afip para ser consultada o vuelta a imprimir.
Hasta aquí intenté dar un panorama sobre la resolución, y una breve explicación sobre los métodos de utilización posibles, a continuación intentaré explicar el diseño Datacomsys que se adecua a cada una de estas modalidades.
Por mas información, la Afip provee una página de consultas y respuestas frecuentes referidas a facturación electrónica, en la dirección:
http://www.afip.gov.ar/genericos/guiavirtual/directorio_subcategoria.aspx?id_nivel1=562&id_nivel2=603
Facturación electrónica Datacomsys:
La facturación electrónica, por resolución, obliga a tener una nueva boca de venta habilitada como tal, en la afip.
En este sentido, al momento de habilitar dicha sucursal dentro de los parámetros Datacomsys, la misma será definida con un nuevo tipo de sucursal denominado:
E – Sucursal electrónica.
A partir de esta parametrizacion el sistema trabajará específicamente para facturación electrónica.
Como mencioné anteriormente, están previstos dos métodos, el método RECE y el método RECEL.
Método RECEL:
Bajo el método RECEL, donde los comprobantes se realizan en línea en la web de la afip, y bajo clave fiscal, no hay muchas posibilidades de cambio, si bien esa boca de ventas será definida como electrónica y tendrá un numero especifico, los comprobantes realizados en la web de afip, deberán ser retipeados como comprobantes manuales, como aquellos comprobantes que se utilizan cuando hay cortes de energía o problemas de comunicaciones.
Este procedimiento es el mas sencillo, y como es de esperar el menos controlado, ya que no hay manera de corroborar que aquello que se generó como comprobante en la web afip, sea idéntico a lo que se incorporó como comprobante manual, tanto en su calidad de información, totales y numero CAE y vencimiento del mismo.
Desde el lado de la Afip, el aplicativo que se utiliza no tiene ningún tipo de relación con la base de datos, como se puede visualizar en la demostración que se sugirió ver anteriormente, tanto el número de cuit del cliente, los datos de los productos de venta, unidades de medida, precios unitarios, etc., deben ser incorporados manualmente, no habiendo posibilidad, siquiera, de copiar un comprobante anterior a uno nuevo, similar a hacer una factura con un procesador de texto.
Pero insisto en que es el procedimiento mas sencillo, menos costoso, y quedará en cada instalación evaluar si, por la cantidad de comprobantes y necesidades de control, este procedimiento se ajusta las necesidades.
Método RECE:
Por el método RECE las modificaciones al sistema son bastante mas complejas que en el RECEL.
Se prevé un panel de trabajo similar al que es utilizado en la actualidad por aquellas instalaciones que cuentan con impresoras fiscales, o bien con varias maquinas facturadoras y un solo lugar de impresión.
En estos casos, lo que el operador de facturación realiza, es lo que se denomina una minuta de venta, la minuta de venta contiene los mismos datos que la factura final, pero es en definitiva una pro forma, a la espera de la confirmación.
En el caso de las facturas fiscales, la confirmación radica precisamente en la impresión fiscal, y en el caso de las facturas electrónicas, la confirmación es aquella que denominamos anteriormente como CAE, para que luego si, puedan ser impresas.
O sea, así como la impresión fiscal consta de un dispositivo externo a Datacomsys, denominado impresora fiscal; la impresión electrónica consta de un dispositivo externo que es el servidor de la Afip.
Entonces, la emisión de comprobantes electrónicos Datacomsys, consistirá de dos pasos, uno donde el operador genera la minuta de venta, sea factura, debito o crédito y otro paso donde se obtiene la autorización de dicho comprobante.
Este ultimo paso se realizará desde un panel especial: “Minutas electrónicas pendientes”, desde donde se podrán realizar distintas operaciones: Autorizar la minuta mediante web services, autorizar la minuta mediante la generación de un archivo de exportación para el utilitario RECE/SIAP, o bien eliminar la minuta.
Si la empresa ha decidido la utilización del utilitario RECE/SIAP, se comprenderá que, ante la emisión del archivo de exportación de datos, Datacomsys pierde la traza y queda a la espera que dicho archivo sea nuevamente incorporado.
Al incorporar el archivo de transferencia los comprobantes que han sido rechazados se eliminarán, y a los que han sido aceptados se les incorporará el CAE, y se convertirán en comprobante reales del sistema.
Si por el contrario, la empresa ha decidido la utilización del método basado en web services, el panel de minutas pendientes de aprobación, quedara suspendido a la espera de la respuesta desde el servidor de la afip.
Siendo el procedimiento interno a realizar, resumidamente, el siguiente:
Ante una minuta electrónica pendiente, el sistema administrativo tiene que enviar un requerimiento denominado: Ticket de acceso, que contiene las firmas digitales y certificados realizados con anterioridad, este y cualquier otro envío se realiza con los mencionados web services, protocolos, etc., y teniendo sincronizada la fecha y hora entre ambas maquinas, y con internet funcionando correctamente.
Una vez verificado en la Afip el ticket de acceso, el mismo se remite nuevamente al sistema y es valido por 5 horas, pudiendo este tiempo cambiar según disposición de la afip, este archivo devuelto contiene lo que se llama Token y Sign, que en definitiva son datos que permitirán que el contribuyente envié sus comprobantes para verificar.
Una vez obtenido este ticket de acceso, que por un lado valida que el contribuyente sea el contribuyente, y que el mismo este autorizado a utilizar este servicio, el sistema puede enviar los datos correspondientes al comprobante electrónico a verificar.
Finalmente, si todo esta bien, se obtiene el CAE y se archiva definitivamente el comprobante.
También el diseño contempla la posibilidad de acumular minutas pendientes y enviarlas en un momento dado, por ejemplo a la noche.
Como se puede ver, estos procesos donde habrá o puede haber cierta espera entre el momento que se realiza el comprobante y su aprobación, obligará a tener en cuenta que la facturación deja de ser una operatoria instantánea, donde la misma se realiza al momento de ser necesaria, sino que seria prudente poder organizarla de manera que no se generen cuellos de botella en los que por dar un ejemplo la factura esta siendo esperada por un cliente, un transporte, o alguien; y que lamentablemente se verá obligado a esperar la autorización que entrega un tercero, en este caso la Afip.
Y esta autorización, como se prevé, puede lentificarse por motivos propios del contribuyente: maquinas fuera de red, problemas de fechas y horas erróneas, certificados, problemas de red, problemas de Internet, etc.; o bien lisa y llanamente por problemas en el servidor de la Afip, sea saturación de autorizaciones a realizar, o problemas técnicos de ellos.
Para la facturación por decirlo de alguna manera, instantánea, se debería utilizar el método de las impresoras fiscales, aunque como se sabe, estas no prevén la emisión de comprobantes letra E.
Resumen de lo expuesto:
La resolución 2485 de Afip prevé la incorporación de contribuyentes al régimen de facturación electrónica de manera progresiva.
La resolución 2758 obliga a aquellos contribuyentes que emiten facturas letra E, a comenzar a realizar dicha operación con comprobantes electrónicos.
La misma resolución se aplica a partir del 01-03-2010 para 30 empresas específicas, comenzando todas las restantes el día 01-05-2010.
En todos los casos, la facturación electrónica requiere de una nueva boca habilitada en Afip.
Existen dos modalidades de trabajo para la generación de facturas electrónicas, un método denominado RECE y otro denominado RECEL.
El método RECEL es aquel por el cual el contribuyente genera el comprobante electrónico en la web de Afip, ese comprobante puede ser convertido a un archivo PDF y enviado al cliente o bien resguardado en la maquina del contribuyente.
El método RECEL, no contempla códigos de clientes, productos, precios y otros que se mantienen en el sistema administrativo.
El comprobante así emitido, deberá ser incorporado al sistema Datacomsys en forma manual, como si fuera un comprobante hecho a mano.
El método RECE es aquel por el cual el contribuyente genera el comprobante electrónico mediante software instalado en su maquina.
Este software utiliza una forma de comunicación para registrarse en los servidores de la Afip, enviarle datos y obtener el código CAE que autoriza al comprobante a emitir.
Este método obliga a ciertos cambios, tanto en el sistema de gestión de ventas, así como en la forma administrativa de usarlos.
El software utilizado para el método RECE, puede ser en la forma de un módulo que se incorpora en el SIAP, o bien un desarrollo especial en el sistema administrativo del contribuyente.
Si se usa el módulo RECE en el aplicativo SIAP, el sistema administrativo genera un archivo de transferencia que se incoporpora al modulo RECE y luego desde ese modulo se genera un nuevo archivo a ser presentado por ventanilla electrónica de Afip y, una vez validado, ese mismo aplicativo genera un nuevo archivo de transferencia que es incorporado al sistema administrativo.
Si no se usa el modulo RECE del SIAP, y se utiliza un desarrollo especial en el sistema administrativo, este desarrollo se encarga de comunicarse con la Afip, registrase, validarse y obtener el CAE.
Esto requiere de ciertos trámites a realizar con clave fiscal, por parte del contribuyente y del desarrollador del software.
En todos los casos, la instrucción de los operadores, el estado técnico de los equipos, la red interna, e Internet se vislumbran como herramientas fundamentales para el correcto uso en tiempo y forma de estos métodos.
Finales:
Desde fines del año pasado que intente circular entre las distintas instalaciones la información que obtenía sobre facturación electrónica.
A fines de Enero 2010 solicite confirmación sobre aquellas empresas que se encontraban alcanzadas por esta resolución.
Entiendo que, a primera vista, puede considerarse un “inconveniente”, que deberá ser resuelto por el Contador y el de Sistemas, pero debido a la profundidad del cambio, así como las distintas operatorias a realizar con clave fiscal, certificados, firmas digitales y otros, y la modificación en las conductas de facturación de los operadores, insisto en extender esta resolución por lo menos a los encargados de las distintas administraciones que utilizan Datacomsys.
Nuevamente reitero la necesidad de tener conocimiento sobre si su empresa es alcanzada por esta resolución, y en caso afirmativo, que tipo de método va a utilizar, ya que independientemente de los tramites a realizar por uno o por otro, el método mas complejo, denominado RECE donde los comprobantes se autorizan por el propio sistema, requiere de un desarrollo y adquisición de productos de terceros, que deriva en la necesidad de trasladar dicho costo, en forma proporcional y por única vez, a aquellos interesados en utilizarlo.
Esta información es necesario tenerla para la primera semana de Marzo 2010.
Si su empresa recibió este documento es porque, a mi entender, esta incluida en la resolución de referencia, y por lo menos ha hecho un comprobante de exportación en el año que media entre el 01-02-09 y 31-01-10.
Este documento se encuentra publicado en www.datacomsys.blogspot.com
Carlos A.L.Herrero 22-02-2010
viernes, 12 de febrero de 2010
Version 100212
Modificaciones importantes en Datacomsys 7.4 Versión 100212/19
Stock
Trabajar con productos
Consultas de Producto/Pedido Producto/Remito y Producto/Facturas
A los paneles de las consultas mencionadas se le ha agregado los campos de código de cliente y razón social. Para el caso de remitos, en particular, también se han agregado los campos de códigos de proveedor y razón social para el caso de devoluciones.
Ventas
Comprobantes de venta
Impuestos internos
Tanto en minutas como en consultas de comprobantes de venta, se ha agregado la visualización de los cálculos correspondientes a impuestos internos.
(El cálculo o no, de impuestos internos se define, como siempre, en los legajos de los productos)
Número CAI y Fecha de vencimiento
Para los comprobantes de venta emitidos por auto impresores o bien comprobantes manuales, el sistema mantiene para cada uno el número CAI y fecha de vencimiento correspondiente.
Estos datos se siguen indicando en el legajo del punto de venta y se colectan al facturar o remitir.
Autorizaciones
Los procesos de autorizaciones de pedidos, remitos y facturas, en lo referente a topes de crédito, deuda vencida, atrasos y otros, ahora se han liberado en el sentido que cada instalación puede diseñar su propio esquema de autorizaciones.
Cuentas corrientes
Recibos de caja
Autorizaciones
El proceso de autorización de recibos se ha liberado a efectos que cada instalación diseñe su propio esquema.
AFIP
Resolución 1361
El modulo de Afip ahora cuenta con una actividad especial para el procesamiento y obtención del archivo necesario para cumplir con la resolución 1361 Ventas.
Administracion de personal
Liquidación de haberes
Procesos de cálculo
Se han agregado facilidades a los procesos de calculo permitiendo tomar en forma directa totales de venta o total de comisiones calculados en el modulo de comisiones, sea por venta o por cobranza.
También se han agregado sentencias condicionales, así como llamadas a procesos externos y específicos para cada instalación.
Las formulas que toman datos de otros conceptos de cálculo, pueden referirse al resultado de dicho calculo así como al parámetro 1, 2 o fijos que dicho concepto utilizo para calcularse.
El legajo del empleado mantiene hasta nueve datos que pueden ser utilizados como argumentos en formulas de conceptos.
Generales
Adaptación general del sistema
En el mes de enero hemos comenzado a adaptar al sistema para ser utilizado con bases de datos GNU (Postgres, Mysql), así como también la adaptación parcial para poder diseñar actividades en entorno de programación JAVA y migrar definitivamente a ese entorno.
Se prevé que dicha adaptación finalizará alrededor de diciembre 2010 a febrero 2011.
Facturación electrónica resolución Afip : 2758
Durante los meses de Febrero – Marzo – Abril, se procederá a la adaptación del sistema para la generación de facturas electrónicas de tipo E.
Esta adaptación se encuentra demorada por falta de concreción sobre ciertos datos necesarios por parte de la Afip.
Durante el mes de febrero hemos circulado a los distintos clientes sobre el tema, para que consulten con sus respectivos estudios contables sobre el alcance o no de dicha circular, que en principio, y de no haber prorroga, comenzará a regir a partir de marzo o abril 2010, según actividad.
Saber que instalación esta alcanzada o no, es importante para poder determinar la carga de trabajo, ya que es una modificación compleja, que afecta no solo al sistema sino a la administración que lo utilice, que requiere de terceros y presentaciones en la Afip, y que no podrá ser implementada de un día para otro, por mas que el sistema ya estuviere adaptado.
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 12-02-2010
Stock
Trabajar con productos
Consultas de Producto/Pedido Producto/Remito y Producto/Facturas
A los paneles de las consultas mencionadas se le ha agregado los campos de código de cliente y razón social. Para el caso de remitos, en particular, también se han agregado los campos de códigos de proveedor y razón social para el caso de devoluciones.
Ventas
Comprobantes de venta
Impuestos internos
Tanto en minutas como en consultas de comprobantes de venta, se ha agregado la visualización de los cálculos correspondientes a impuestos internos.
(El cálculo o no, de impuestos internos se define, como siempre, en los legajos de los productos)
Número CAI y Fecha de vencimiento
Para los comprobantes de venta emitidos por auto impresores o bien comprobantes manuales, el sistema mantiene para cada uno el número CAI y fecha de vencimiento correspondiente.
Estos datos se siguen indicando en el legajo del punto de venta y se colectan al facturar o remitir.
Autorizaciones
Los procesos de autorizaciones de pedidos, remitos y facturas, en lo referente a topes de crédito, deuda vencida, atrasos y otros, ahora se han liberado en el sentido que cada instalación puede diseñar su propio esquema de autorizaciones.
Cuentas corrientes
Recibos de caja
Autorizaciones
El proceso de autorización de recibos se ha liberado a efectos que cada instalación diseñe su propio esquema.
AFIP
Resolución 1361
El modulo de Afip ahora cuenta con una actividad especial para el procesamiento y obtención del archivo necesario para cumplir con la resolución 1361 Ventas.
Administracion de personal
Liquidación de haberes
Procesos de cálculo
Se han agregado facilidades a los procesos de calculo permitiendo tomar en forma directa totales de venta o total de comisiones calculados en el modulo de comisiones, sea por venta o por cobranza.
También se han agregado sentencias condicionales, así como llamadas a procesos externos y específicos para cada instalación.
Las formulas que toman datos de otros conceptos de cálculo, pueden referirse al resultado de dicho calculo así como al parámetro 1, 2 o fijos que dicho concepto utilizo para calcularse.
El legajo del empleado mantiene hasta nueve datos que pueden ser utilizados como argumentos en formulas de conceptos.
Generales
Adaptación general del sistema
En el mes de enero hemos comenzado a adaptar al sistema para ser utilizado con bases de datos GNU (Postgres, Mysql), así como también la adaptación parcial para poder diseñar actividades en entorno de programación JAVA y migrar definitivamente a ese entorno.
Se prevé que dicha adaptación finalizará alrededor de diciembre 2010 a febrero 2011.
Facturación electrónica resolución Afip : 2758
Durante los meses de Febrero – Marzo – Abril, se procederá a la adaptación del sistema para la generación de facturas electrónicas de tipo E.
Esta adaptación se encuentra demorada por falta de concreción sobre ciertos datos necesarios por parte de la Afip.
Durante el mes de febrero hemos circulado a los distintos clientes sobre el tema, para que consulten con sus respectivos estudios contables sobre el alcance o no de dicha circular, que en principio, y de no haber prorroga, comenzará a regir a partir de marzo o abril 2010, según actividad.
Saber que instalación esta alcanzada o no, es importante para poder determinar la carga de trabajo, ya que es una modificación compleja, que afecta no solo al sistema sino a la administración que lo utilice, que requiere de terceros y presentaciones en la Afip, y que no podrá ser implementada de un día para otro, por mas que el sistema ya estuviere adaptado.
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 12-02-2010
Suscribirse a:
Entradas (Atom)
