Category: viavansi

Qué es la firma en cloud y qué ventajas ofrece

14 Oct 2016

Qué es la firma en cloud

Hoy queremos analizar una de las últimas tendencias en autenticación, la firma en cloud. Vamos a presentar su uso para la autenticación de trámites entre empresas o administraciones y explicaremos sus principales ventajas.

[…]

La experiencia de Viavansi en la jornada internacional de Firma Digital

06 Oct 2016

Jornada Firma Digital

El grupo Viavansi ha participado en el seminario internacional de firma digital para analizar sus principales usos, soluciones y aplicaciones. Además, los ponentes aprovecharon la jornada para debatir sobre la transformación digital de la República Dominicana.

[…]

Caso de éxito: La Plataforma de Preservación Open Science de ESFRI LIFEWATCH desplegada en la ICTS-RBD

09 Jun 2016

Plataforma Lifewatch desplegada en ICTS-RBD

En artículos anteriores hemos destacado la importancia de los datos abiertos en el marco de las estrategias que Europa se ha planteado para la consecución de los objetivos marcados para el 2020. Actualmente estamos en un entorno colaborativo donde la filosofía Open abarca todos los ámbitos. Hoy, os traemos un ejemplo de cómo Europa, a través de las diferentes entidades está jugando un papel crucial en el campo de la investigación: Plataforma de Preservación Open Data orientada específicamente a la temática de la ESFRI LIFEWATCH desplegada en la ICTS-RBD. […]

Las Autoridades de Certificación en Centroamérica y Caribe (Parte II)

27 May 2016

Autoridad de Certificación

Los países de Centroamérica y Caribe han venido aprobando distintas leyes en el marco del mundo del comercio electrónico, la firma digital y las Autoridades de Certificación (CAs). Antes de hablar de su evolución conjunta vamos a hacer un pequeño recorrido a través de algunos países  de Centroamérica y Caribe para conocer su situación particular:

[…]

Andalucía es Digital: nuevo proyecto desarrollado por Viavansi

21 May 2014

Andalucía es digital

El pasado día 16 de Mayo, el Consejero Economía, Innovación, Ciencia y Empleo presentó, con motivo del día de Internet, el portal AeD Andalucía es Digital. “Andalucía es digital es un portal que pretende acercar a la ciudadanía y las pequeñas empresas los servicios de la Junta de Andalucía relacionados con la Sociedad de la Información“.
 
El portal ha sido desarrollado durante 15 meses por Yaco y Viavansi, bajo la tutela de telefónica. Se trata de un CMS Liferay (implementado por Yaco) que recoge información vía iCMS (desarrollado por Viavansi) de un gran número de portales, entre los que destacan Guadalinfo, Andalucía Compromiso Digital (ACD), Edukanda, Aula Virtual y un largo etcétera.
 
Para Viavansi ha sido un importante esfuerzo de adecuación de iCMS a los requisitos específicos, incluyendo la modificación/creación de diversos drivers de conexión con los sistemas proveedores y una exhaustiva definición de colecciones de datos de estos últimos.
 
Además se han desarrollado en Android e iOS, apps para Edukanda y para el propio AeD, además de realizar un piloto de Realidad Aumentada basado en información recogida también vía iCMS de Wikanda.
 
Este proyecto se ha realizado dentro de las estrategias MiRA! de presencia web de la Junta de Andalucía en materia de innovación. Como continuación/evolución de esta estrategía, en este momento estamos ya embarcados en dos proyectos: 
 
  • Evolución del portal AeD. Con la absorción de varios sistemas antes conectados vía iCMS y la creación de una vasta Plataforma de Teleformación.
  • Nuevo Guadalinfo. Un enorme ecosistema, que ha crecido de manera “orgánica” y muy desorganizada, con un CMS Drupal modificado que se integra con múltiples sistemas, que se pasa a Liferay, renovando líneas estratégicas, homogeneízando tecnologías y optimizando flujos.

 

Referencias:

Módulo de Vacaciones OpenERP 6.1

30 Oct 2012

Una vez elegida OpenERP como la herramienta que mejor se adapta a nuestras necesidades, con frecuencia nos encontraremos con la necesidad de adaptar alguno de los módulos disponibles a los requisitos específicos de nuestra empresa.

Haciendo un resumen rápido de lo que tenemos que tener en cuenta antes de elegir qué herramienta se adecua mejor a nuestra empresa y que “verdaderamente” necesitamos para cumplir todos los procesos de nuestro negocio ( esta ultima frase por la que hemos pasado casi de puntillas, quizás sea la fundamental o una de ellas para llevar a cabo una instalación de la herramienta con éxito y sin demasiados quebraderos de cabeza ), tenemos que tener asimilado que los objetivos de cualquier ERP son :

  • Optimización de los procesos empresariales.
  • Acceso a la información.
  • Posibilidad de compartir información entre todos los componentes de la organización.
  • Eliminación de datos y operaciones innecesarias de reingeniería

Además, un ERP como tiene que ser configurable y modular. Una vez elegida OpenERP como la herramienta que mejor se adapta a nuestras necesidades, con frecuencia nos encontraremos con la necesidad de adaptar alguno de los módulos disponibles a los requisitos específicos de nuestra empresa.

Con todo ello, deberemos probar la herramienta para tener claros las siguientes ideas fundamentales:

  • Qué módulos necesitaremos y cuáles no ( y por tanto no deberemos de instalarlos)
  • Realizar o pedir sólo los desarrollos de los módulos que verdaderamente necesitemos. En este apartado tenemos que hacernos a la idea que en muchos casos deberemos adaptar los procesos a la manera-estructura de OpenERP y no a la inversa, porque se trata de “configurar”-“customizar” la herramienta y no “crear” una nueva.

Al hilo de lo escrito, comentaremos el desarrollo de un modulo para gestionar vacaciones a petición de las necesidades de un cliente.

El módulo que desarrollamos fue una extensión al módulo vacaciones “hr_holidays” cuyo autor es OPENERP S.A. , que gestiona las vacaciones de los empleados del sistema. Este modulo basa su comportamiento en la asignación de días de ausencia aprobados por los responsables del departamento de RRHH y que los empleados van gastando en forma de “crédito”, es decir, por cada tipo de ausencia el empleado tiene derecho a un numero determinados de días que se podrá ir incrementando o disminuyendo en función del caso. Aún con la pobre definición de la funcionalidad que acabamos de hacer del módulo, refleja de una manera bastante cercana a como se comporta realmente ya que deja muchas lagunas para una mínima gestión de cualquier departamento de RRHH.

En una empresa pequeña de no mas de 5 empleados podría bastar el módulo para el personal pero a partir de un número mayor ya el gestionar vacaciones con dicho módulo no sería eficiente debido a:

  • No existen calendarios laborales ni festivos, en el momento que dos empleados o mas que puedan pertenecer a lugares de trabajo distinto (con diferente calendario laboral) sería un problema.
  • La gestión de las vacaciones en el cambio de año tampoco existe y corregir de año en año las vacaciones de cada empleado si éste es alto, tambien conllevaria un tiempo ineficiente.
  • En relación con el primer punto sólo existe la posibilidad de contar los días como naturales, dejando atrás la posibilidad que en dos puntos de trabajos distintos se cuentes de una manera u otra (O incluso como hemos desarrollado nosotros, el conteo natural o laboral va asociado al tipo de ausencia y dependiendo de ella, contara dias naturales o laborales).

A parte de esta situación inicial fue básico a la hora de hacer el desarrollo (y en verdad también para cualquier otro) saber manejar bien las fechas en python, concretamente la clase time y datetime y el comportamiento de sus dos metodos mas utlizados : strftime() y strptime(). También para la problemática del conteo de los días hábiles hicimos uso del método isoweekday() de la clase datetime para saber que dia es de la semana dada una fecha..

Con esta problemática, el punto de partida de nuestro desarrollo es el siguiente; creamos dos nuevas identidades calendario_laboral y festivo. Calendario_laboral tendrá una relación one2many con hr_employee y también tendrá una relación many2many con la entidad festivo. Con ello podremos crear múltiples calendarios laborales que podrán poseer los festivos correspondientes, cada año sólo deberemos meter los festivos una vez para luego asociarlos a calendarios sucesivos. A su vez un mismo calendario podré asociarlo también a los empleados que correspondan, así podremos contear las vacaciones en función del calendario que tenga el empleado asignado.

En una primera versión el conteo de los días hábiles o no, lo asociamos a los calendarios laborales pero luego decidimos asociárselo al tipo de ausencia de manera que crearemos un nuevo campo check “dias_habiles” que si esta marcado descontará los días hábiles que hay en el intervalo de tiempo que ha pedido las vacaciones el empleado. En el mismo objeto, crearemos también un checkbox “lanzar_fin” que será el que controle si en el wizard que crearemos para gestionar el cambio de año y la compensación de vacaciones, se creen o no las nuevas asiganaciones de vacaciones para los empleados.

    def dias_habiles(self, date_from, date_to):

        res = 0
        DATETIME_FORMAT = "%Y-%m-%d %H:%M:%S"
        date_from = datetime.datetime.strptime(date_from, DATETIME_FORMAT)
        date_to = datetime.datetime.strptime(date_to, DATETIME_FORMAT)
        date_from = datetime.datetime.date(date_from)
        date_to = datetime.datetime.date(date_to)
        while( date_from <= date_to):

            if(datetime.datetime.isoweekday(date_from)== 7 or datetime.datetime.isoweekday(date_from)== 6 ):
                res = res + 1
            date_from = date_from + relativedelta(days=+1)
        return res

Y con esto contaremos las vacaciones con el siguiente método:

    def _get_number_of_days(self, cr, uid, id, date_from, date_to, employee_id):
        """Returns a float equals to the timedelta between two dates given as string."""

        DATETIME_FORMAT = "%Y-%m-%d %H:%M:%S"
        from_dt = datetime.datetime.strptime(date_from, DATETIME_FORMAT)
        to_dt = datetime.datetime.strptime(date_to, DATETIME_FORMAT)
        timedelta = to_dt - from_dt
        diff_day = timedelta.days
        calendario_obj = self.pool.get("hr.holidays.calendario")
        id_cal = calendario_obj.search(cr, uid,[('employee_ids', '=',employee_id)])
        if id_cal:
            calendario = calendario_obj.browse(cr, uid,[id_cal[0]])[0]
            val_intervalo = []
            for festivos in calendario.festivos:
                val_intervalo.append(datetime.datetime.date(datetime.datetime.strptime(festivos.fecha,"%Y-%m-%d")))
            d1 = datetime.datetime.date(from_dt)
            d2 = datetime.datetime.date(to_dt)
            for elem in val_intervalo:
                if elem >= d1 and elem <= d2:
                            diff_day = round(diff_day) - 1
        hol = self.pool.get("hr.holidays.status")
        hol_obj = hol.browse(cr, uid, id)
        if hol_obj.id != False:
            if hol_obj.laborales == True:
                res = self.dias_habiles(date_from, date_to)
                diff_day = diff_day - res

        return diff_day

La idea del asistente de fin de año es regularizar las vacaciones de manera correcta de un año para otro. Para ello una vez que se hubiesen creado las vacaciones de la empresa con sus días correspondientes, si marcamos “lanzar_fin” el asistente creado volverá a reponer los días de disfrute hasta los marcados de nuevo. Resaltar en este apartado, que la única problemática que se nos planteó fue con las Vacaciones, ya que podrían darse 3 casos (supongamos que nuestra empresa tiene derecho a 30 días naturales)

  • Un empleado gasta 30 días —————-> se le asignaran de nuevo 30
  • Un empleado gasta 27 días —————-> se le debe asignar 33
  • Un empleado gasta 34 días —————-> se le debe asignar 26

En un primer acercamiento, se planteó el método de manera que en función de las vacaciones disfrutadas del año anterior se le creaba una nueva asignación con ese número de días. Pero esto solo será válido para el nuevo cambio de año y no en sucesivos, ya que el sistema de esta manera no puede diferenciar si un empleado gasta más o menos vacaciones porque le corresponde (de años anteriores) o porque los ha adelantado, y no actuará en consecuencia. Por tanto el sistema siempre asociará 30 días ( o los correspondientes) y controlará un nuevo tipo de ausencia creada por el modulo, “compensación de vacaciones” de manera que si alguien quiere gastar días de más del año que viene se le deberá asociar a este tipo de ausencia y en consecuencia creará una asignación negativa en los 30 días de vacaciones ( y por tanto se le descontarán las vacaciones anticipadas)

    def regulariza_vacaciones(self,cr,uid,ids,context):

        mes_actual=datetime.datetime.today().strftime("%m")
        dia_actual=datetime.datetime.today().strftime("%d")
        anio_actual=datetime.date.today().strftime("%Y")
        anio_anterior = str(int(anio_actual) - 1)

            # Year change can only be executed first 31 days in January
        if int(mes_actual) == 10 and int(dia_actual)<31:

                holidays = self.pool.get('hr.holidays')
                holidays_obj = self.pool.get('hr.holidays.status')
                holidays_ids = holidays_obj.search(cr, uid,[('lanzar_fin','=',True)])

                category_obj = self.pool.get('hr.employee.category')
                categoria = category_obj.search(cr,uid,[('name','=','Todos')])

                obj_emp = self.pool.get("hr.employee")
                emp_ids = obj_emp.search(cr, uid, [('category_ids',"=" , categoria[0])])

                for hol in holidays_obj.browse(cr, uid, holidays_ids):

                    for emp in emp_ids:

                        resto = holidays._get_remaining_days_by_holidays(cr, uid, emp, hol.id, anio_anterior)
                        if resto < 0:
                            resto = -resto
#                            if resto > hol.ndias:
#                                exc = resto - hol.ndias
#                                resto = hol.ndias - exc
                            if hol.name == "Vacaciones":
                                resto = hol.ndias
                            if hol.name == "Compensacion Vacaciones":
                                resto = -resto
                                hol.name == "Vacaciones"
                                hol.id = holidays_obj.search(cr, uid,[('name','=',"Vacaciones")])[0]

                        values = {
                                  'name' : hol.name,
                                  'holiday_type' : 'employee',
                                  'employee_id': emp,
                                  'type':'add',
                                  'holiday_status_id': hol.id,
                                  'state' : 'validate',
                                  'number_of_days_temp': resto,
                                   }
                        if(resto != 0):
                            holidays.create(cr, uid, values)

        else:
            raise osv.except_osv(_('Warning'),
                            _('La regularizacion de vacaciones en el cambio de año solo se puede realizar en el mes de Enero')) 

        return {}

cambio_anio_wizard()

Ya casi para acabar, deberemos crear las vistas correspondientes para dibujar los menús de la aplicación y colocarlos en los sitios que nos interesen; en nuestro caso “colgaremos” todo desde el menu de configuración de vacaciones, aprovechando el filtrado que trae por defecto el sistema que solo permite acceso a este menú al grupo “HR Manager”.

Para acabar este punto y todo el post, un pequeño apunte en cuanto a filtrados y permisos; el modulo por defecto como vemos a continuación trae los derechos de accesos configurados en el csv correspondiente en la carpeta security, en el que daremos acceso a las nuevas entidades creadas según grupos. Esta tarea en el desarrollo de cualquier modulo podemos encontrar varias veces que “no esta hecha”, ¿ que quiero decir con estas comillas? Que no es que no este hecha, es mas, considero que si no es un desarrollo muy concreto para un determinado proyecto debería de dejarse “a gusto del consumidor” que gestione permisos y accesos a sus necesidades ( una de las esencias del ERP).

"id","name","model_id:id","group_id:id","perm_read","perm_write","perm_create","perm_unlink"
"access_calendario_manager","hr.holidays.calendario manager","model_hr_holidays_calendario","base.group_hr_manager",1,1,1,1
"access_festivos_manager","hr.holidays.festivos manager","model_hr_holidays_festivos","base.group_hr_manager",1,1,1,1
"access_calendario_user","hr.holidays.calendario user","model_hr_holidays_calendario","base.group_user",1,0,0,0
"access_festivos_user","hr.holidays.festivos user","model_hr_holidays_festivos","base.group_user",1,0,0,0

Para quien quiera echarle un vistazo mas detenido o hacer uso del modulo que hemos comentado, está disponible para la comunidad en launchpad.

Cálculo de amortización de activos en OpenERP (I) (Spanish version)

23 Oct 2012

Un aspecto importante dentro de la contabilidad de una empresa son las amortizaciones. Es un proceso que se realiza al final del ejercicio contable, pero no por ello, menos importante. La solución OpenERP de la que hemos hablado en varias ocasiones en xnoccio, gestiona las amortizaciones mediante el Módulo de Activos (account_assets). Sin embargo, al realizar la implantación de este ERP en pymes españolas, nos hemos encontrado con que su funcionalidad resulta insuficiente. Esto no es obstáculo, ya que no resulta difícil adaptar los módulos actuales a necesidades específicas o incluso crear módulos nuevos. En el caso que nos ocupa, Viavansi ha ampliado las funcionalidades del módulo de activos de OpenERP 6.1.

En este artículo nos ocuparemos de explicar funcionalmente la mejora y en uno próximo detallaremos cuales han sido las modificaciones técnicas realizadas.

Los inmovilizados se van depreciando poco a poco, ya sea por su uso o por el paso del tiempo. Esta depreciación debe reflejarse contablemente, y su cálculo viene marcado por las tablas de amortización que publica la Agencia Tributaria. Los métodos que utiliza, son el coeficiente máximo en porcentaje y el periodo máximo en años.

Como decía, actualmente, los métodos que propone el módulo account_assets son insuficientes. Por eso, hemos diseñado uno nuevo método que cubra las siguientes necesidades:

  • Cálculo de la depreciación en porcentaje.
  • Cálculo de las amortizaciones al final del periodo indicado. Ej. si es mensual al final de cada mes, si es trimestral al final del trimestre, si es anual a 31/12.
  • Calculo parcial de la amortización. Tomará como referencia la fecha de compra para el inicio de la de amortización, y como fecha final el 31/12 si el periodo es anual.

Al igual que indicamos en el post anterior sobre órdenes de pago en OpenERP, tendremos instalada la versión 6.1 con la contabilidad española.

El funcionamiento del nuevo método es el siguiente:

1-. Definición de la categoría de activo

Todos los miembros de esa categoría tendrán definido los mismos parámetros. En nuestro ejemplo, será “Mobiliario”.

En Contabilidad → Configuración → Contabilidad financiera → Activos → Categoría de activos → Crear

Categoría de activo de mobiliario

Categoría de activos

2-. Creación del producto Mesa de oficina

Ese producto será acorde a la categoría de activo creada previamente.

En Ventas → Productos → Productos → Crear

Producto mesa de oficina

Cuando compras un inmovilizado, es importante definir la cuenta de ingresos y gastos que le corresponde según el Plan General Contable. En nuestro ejemplo, la cuenta 21600000000 Mobiliario.

3-. Creación del proveedor de inmovilizado

En Contabilidad → Proveedores → Proveedores → Crear

Proveedor de inmovilizado

Proveedor de inmovilizado

Para poder seleccionar la cuenta 52300000000 Proveedores de inmovilizado a corto plazo como Cuenta a pagar es necesario cambiar la configuración de la misma.

En Contabilidad → Configuración → Contabilidad financiera → Cuentas →En código ponemos 5230 y la editamos como se muestra a continuación:

Cuenta proveedor de inmovilizado a corto plazo

Cuenta proveedor de inmovilizado a corto plazo

Hemos cambiado el Tipo interno Regular por A pagar, el Tipo de cuenta Financieras por Terceros – A pagar y hemos clickeado en Permitir conciliación.

4-. Realización de la factura de compra

En Contabilidad→ Proveedores → Facturas de proveedor → Crear

Seleccionaremos el proveedor que hemos creado previamente, la fecha de factura y de vencimiento. Cuando añadamos el producto tendremos que asignar la categoría de activo “Mobiliario” como se muestra en la siguiente pantalla:

Producto con categoría de activo

Producto con Categoría de activo

Una vez añadido el producto en la factura, pulsaremos en Aprobar. Con esta acción conseguiremos que éste se convierta en un activo

Factura compra de inmovilizado

Factura compra de inmovilizado

5-. Confirmación del activo

En Contabilidad → Activos → Activos

Se ha creado el activo “Mesa de oficina”, lo abriremos para confirmarlo o para modificarlo si fuera necesario.

Activo mesa de oficina. General

Activo mesa de oficina. general

A continuación haremos una breve aclaración sobre los campos que se muestran en la pestaña General anterior.

  • El valor bruto coincide con el precio de coste que definimos en el producto.
  • El valor contable será el mismo que el anterior si el inmovilizado no tiene valor residual.
  • La fecha de compra se rellenará manualmente a tipo informativo, y se utilizará para activos que ya estén en la empresa.
  • La fecha de la última amortización tiene un doble sentido. Para activos nuevos, será la fecha de compra y para aquellos que ya existían en la empresa, será la fecha en la que se realizó la última amortización.
  • El campo Primera amortización, será la fecha en la cual se realizará la primera amortización.
  • El resto de campos de esta pestaña viene marcado por los valores definidos en la categoría de activos, pero pueden ser modificados si fuera necesario.

En la pestaña Tabla de amortización se muestra la evolución que irá sufriendo el inmovilizado.

activo mesa de oficina. tabla de amortización

Activo mesa de oficina. Tabla de amortización

Previamente, habíamos definido que íbamos a amortizar un 10% anual. Si observamos la líneas de depreciación, la primera y la última son diferentes. Ello es debido a que el importe a amortizar no es un año completo, si no el periodo que va desde la fecha de compra hasta el 31/12. Marcamos esa fecha porque en la mayoría de las empresas el año fiscal y el natural coincide. Por ello, debemos reflejar sólo la parte de gasto que corresponde a ese ejercicio.

Una vez confirmado el activo, podremos calcular los asientos de depreciación. Pulsaremos en Calcular asientos de la línea de depreciación si solo es un activo, o seguiremos el siguiente enlace si queremos calcular el de todos los inmovilizados de la empresa a la vez.

En Contabilidad → Procesamiento periódico → Asientos recurrentes → Calcular amortizaciones → Buscamos el periodo 12/2012 y pulsaremos en Calcular. El asiento que se crea es el siguiente:

Asiento de amortización

Asiento amortización

Para terminar todo el proceso pulsaremos en Enviar para que el asiento quede como Asentado. A partir de ahora, podremos cambiar el porcentaje de amortización y la longitud del periodo pulsando en Cambiar duración, en la pestaña General del activo.

Cambiar duración de activo

Cambiar duración de activo

Órdenes de pago OpenERP (Spanish version)

11 Oct 2012

Hoy en día, la relación existente entre una empresa y sus bancos es muy estrecha. Cada vez son menores los pagos en efectivo, en favor de otros tipos de pago como transferencias, recibos domiciliados, cheques, pagarés, nóminas, efectos, etc.

En este artículo describiremos la manera de configurar OpenERP para poder efectuar las órdenes de pago. Para ello, será necesario tener instalada la versión 6.1 con la contabilidad española.

OpenERP utiliza el módulo de la localización española l10n_es_payment_order para la exportación de ficheros bancarias según las normas CSB 19 (recibos domiciliados), CSB 32 (descuentos comerciales), CSB 34.1 (emisión de transferencias, cheques bancarios, nóminas, pagarés y pagos certificados internacionales) y CSB 58 (anticipos y gestión de cobro de créditos) para poder ser enviados a la entidad bancaria.

Como hemos comentado en anteriores artículos, OpenERP tiene una estructura modular, de ahí que para el correcto funcionamiento de algunas acciones sea necesario configurar otras. Antes de generar las órdenes de pago/cobro deberemos realizar los siguientes pasos:

En Administración → Compañías → Compañías → Pestaña Información general

  • Rellenar la dirección y el CIF/NIF de la compañía. El CIF estará compuesto por el código del país (ES), la letra y el número correspondiente. Por ejemplo, ESB12345678.

En Administración → Configuración → Asistentes de configuración → Asistentes de configuración → Configurar sus cuentas bancarias

  • Lanzar el asistente de configuración “Configurar sus cuentas bancarias”. Aquí crearemos las cuentas que tiene la compañía y que utilizará para realizar sus movimientos bancarios.

En Contabilidad → Proveedores → Proveedores → Crear

  • Crear un proveedor. En la pestaña General rellenaremos la dirección. En Contabilidad definiremos el tipo de pago Transferencia CSB, el CIF/NIF de la empresa y crearemos la cuenta bancaria del proveedor.

Una vez realizadas estas configuraciones, vamos a explicar los pasos que hay que seguir para crear una remesa de pago de transferencias bancarias según la norma CSB 34.1.

Entraremos en Contabilidad → Configuración → Varios → Modo de pago → Crear

  • Daremos un nombre al modo de pago que sea suficientemente representativo, ya que posteriormente lo seleccionaremos en la orden de pago.
  • Seleccionaremos el tipo de pago y remesa.
  • En Datos del presentador, seleccionaremos nuestra empresa, la cuenta bancaria que utilizaremos para la remesa y pondremos el nombre de la compañía que se reflejará en el archivo.
  • En Opciones CSB 34, detallaremos si es una transferencia, un cheque, un pagaré o un pago certificado. Para nuestro ejemplo será una transferencia bancaria.
  • En Datos adicionales, podemos definir si lo gastos corren por cuenta del ordenante o del beneficiario, así como el concepto de la transferencia.
OpenERP, modo de pago

OpenERP, modo de pago

Una vez definido el modo de pago crearemos la factura del proveedor. Antes de aprobarla deberemos comprobar que el tipo de pago sea Transferencia CSB, que tenga estipulado una fecha de vencimiento y que la cuenta bancaria del proveedor esté seleccionada en la pestaña Otra información.

A continuación nos iremos a Contabilidad → Pago → Órdenes de pago → Crear

  • Seleccionaremos el modo de pago que hemos creado previamente.
  • Elegiremos crear los asientos contables por pago directo o por extracto bancario.
  • Pulsaremos en Seleccionar facturas a pagar/cobrar. Nos mostrará una pantalla dónde deberemos introducir una fecha posterior a la del vencimiento y un importe superior al de la factura. Se mostrarán las facturas que cumplan todas las condiciones.
  • Seleccionaremos aquellas que queramos incluir en la remesa de pago y pulsaremos en Añadir a la orden de pago.
  • A continuación, pulsaremos en la acción Export file que aparece en el menú de la derecha. Nos generará un archivo que guardaremos y que posteriormente utilizaremos para importarlo en el programa de remesas del banco.
OpenERP, órdenes de pago

OpenERP, órdenes de pago

Por último, para poder importar el archivo generado por OpenERP será necesario estar dado de alta en el banco en la norma 34.1, para nuestro ejemplo, en las Transferencias 34.1. El resultado obtenido es el siguiente:

Simulador de remesas de banco

Simulador de remesas de banco

Espero que lo hayáis encontrado útil. Para más información y/o ayuda personalizada sobre OpenERP podéis contactarnos sin ningún compromiso.

Estrenamos web

23 Mar 2011

Hoy hemos publicado la nueva versión de nuestra web viavansi.com; ha sido un desarrollo más o menos rápido, basado en Drupal, para poder sacar algo a la calle y sustituir a la anterior que cuando menos podía calificarse de “vetusta”. Después de esta vendrán los rediseños del resto de portales del grupo, como viafirma.com, avansi.com.do (nuestra filial dominicana) y el de este mismo blog xnoccio.com.

No dudéis en hacernos llegar vuestros comentarios o sugerencias. Gracias!

Casos de éxito e-Government

16 Feb 2011

logo de viafirma inbox

Durante los días 5 al 7 de Abril de 2011 se celebrará en la Feria de Madrid la XVIII Edición de SIT ASLAN, donde se expondrán los casos de éxito en Administraciones y Organismos Públicos más innovadores.

El Ayuntamiento de Pozuelo de Alarcón (Madrid) expondrá su Plan de Innovación en Administración Electrónica para el cumplimiento de la Ley 11/2007 de Acceso Electrónico de los Ciudadanos a los Servicios Públicos.

Como resultado, un nuevo modelo de relación con la ciudadanía y la implantación de un conjunto de proyectos tecnológicos al servicio de los ciudadanos y empleados públicos.

Entre estos proyectos, queremos destacar la implantación de dos de nuestras soluciones, como Viafirma Platform como Plataforma de Autenticación y Firma Electrónica, y Viafirma Inbox y Portafirmas Electrónico.

logo de viafirma platform

logo de viafirma inbox

Con estas soluciones de Viavansi, el Ayuntamiento de Pozuelo apuesta por la multicanalidad y la neutralidad tecnológica, permitiendo el consumo de los servicios de firma electrónica desde dispositivos móviles (m-government) como iPhone, iPad, Android o BlackBerry, y desde cualquier sistema operativo y navegador.

Enhorabuena a todo el equipo que participó y ya podéis terminad vuestras votaciones, el plazo acaba el 22 de febrero.