Adaptación de Cyclos para la moneda social la Jara

Vamos a recoger en este documento la forma de configurar Cyclos para realizar pruebas y
detectar las necesidades de la aplicación de gestión de la moneda social. Vamos a ir añadiendo
comentarios que respondan a la necesidad de analizar, revisar o hacer algo en cada una de las
4 líneas de trabajo. Cada una de ellas la pondremos con un color de fondo.

Configuración. Explorar si Cyclos permite la funcionalidad.

Programación. Es necesario tocar algo de código.
Adaptación de pagos desde móviles, tarjetas, tpv...
Diseño. Para que se parezca al estilo de Moneda Social Jara
Dudas o preguntas que surgen y pueden afectar a cosas que aún no tenemos claras.

Instalación de Cyclos

Lo primero es instalar en nuestro ordenador la última versión "Stand alone" de Cyclos desde
la página: http://www.cyclos.org/download .

La instalación es muy sencilla; lo puedes ver en:

http://www.cyclos.org/wiki/index.php/Installation_
%26_maintenance#Cyclos_stand_alone_installation_steps

Configuración
NOTA: El escenario planteado aquí en algunos aspectos es ficticio para probar posibilidades,
que podra o no corresponder a procesos actuales de la Jara o no, porque se exploran otras
funcionalidades interesantes posibles en el aplicación.

Una vez dentro como administrador, hacemos los siguientes cambios, (antes hay que dar al
botón de abajo “Change”:

• En Settings (Configuración) → Local Settings (Configuración local)

• Lenguaje: elegimos el español.
• Método de digitación de números: Izquierda a derecha.
• Desactivar Correo electrónico debe ser único.
Con esto es suficiente de momento, más adelante iremos viendo que cosas más puede
hacer falta cambiar. Las que tienen que ver con la visualización que cada cual elija lo
que le apetezca.

Crear monedas

• En Cuentas → Administrar monedas, editamos la existente (units) y sustituimos Nombre

por “jara”, Símbolo por “B”, Patrón también “B” al final. Ver si acepta símbolo particular

Crear cuentas

• En Cuentas → Administrar cuentas, nos aparecen varias. Eliminamos todas salvo

“Member account”.

Editamos “Member account” y cambiamos sus valores:

Nombre: “Registro de compra-ventas”
Descripción: Va a reflejar los totales de las ventas de productos y servicios
independientemente de la moneda en que se pague. Es sobre la que se aplicarán las
bonificaciones por ventas. Tendrá interés desde el punto de vista estadístico. No
reflejará jaras reales sino que puede ser mezcla de € y B, aunque de momento
 figurará la jara como su moneda ya que no parece que haya posibilidad de hacer
transacciones entre monedas diferentes.

Vamos para atrás y añadimos dos cuentas más:

• Nombre: “Cuenta del Moneda social”
Tipo: “Sistema”
Moneda: “jara”
Tipo de límite: “No limitado”

• Nombre: “Cuenta de jaras”

Tipo: “Miembro”
Descripción: Refleja los saldos reales de jaras de los/as usuarios/as.
Moneda: “jara”

Crear Grupos de usuarios/as

Vamos a Usuarios & Grupos → Administrar grupos: Eliminamos los tres de brokers, “Disabled
administrators”, “Removed administrators” e “Inactive members”.

Editamos “Full members” y modificamos:

• Nombre: “Proveedores”
• Deshabilitamos las dos opciones de “Configuración de préstamos”

Tras Aceptar, vamos abajo, al apartado “Cuentas del Grupo” (si ya hemos creado
las cuentas, sino volvemos luego) y editamos (o asociamos nueva cuenta) las
cuentas

“Registro de compra-venta”:
• Por defecto: Deshabilitamos
• Límite mínimo de crédito: 10.000.000 (aunque debiera ser ilimitado, esa
tipo de cuenta no lo permite)
• Alerta de mínimo de unidades: quitar
• Mensaje de mínimo de unidades: quitar
“Cuenta de jaras”:
• Por defecto: Habilitamos (es la cuenta que mostr Opción que genera
dudas ya que es de la cuenta que se envían los saldos por correo
electrónico y la que se usa para operaciones con móviles
• Límite mínimo de crédito: 500 (Esto además se puede personalizar para
cada usuario/a, así que hay mucho margen)

Tras Aceptar, vamos a la opción del botón “Permisos de Grupo” y hacemos lo

siguiente (vamos a dejar las opciones a lo mínimo y más adelante iremos viendo
que cosas nos sirven):
• Acceso: Deshabilitar “Alterar acceso a canales”
• Anuncios: Deshabilitar todo
• Cuenta: Deshabilitar todo
• Facturas: Deshabilitar todo (a revisar)
• Pagos: [A está opción se volverá dependiendo que las transacciones
estén creadas o no]
Pagos a miembro: “Compra”. (Aquí se seleccionan las operaciones (pagos)
que podrán hacer directamente los usuarios, y que se visualizarán como
opciones de selección al intentar hacer un pago [Comprobar bien todo
esto]. No habría que seleccionar los cargos automáticos a una
transacción.)
Devolver pago recibido: “Compra”. (Esto se utiliza para poder cancelar
una operación. Conviene habilitarlo ya que no hay manera de borrar ni
 modificar transacciones, y es posible que haya errores) [Comprobar bien
todo esto y ver si hay manera de limitar el tiempo en el que un pago
puede ser devuelto]
Quitar todo lo demás de momento
• Perfil del miembro: [a está opción se volverá dependiendo qué grupos
estén creados y queramos que se puedan ver los saldos entre ellos. En
principio todos podrán ver los de todos]
• Ver: “Proveedores”, “Consumidores”
• Preferencias: Deshabilitar todo
• Préstamo: Deshabilitar todo
• Referencias: Deshabilitar todo
• Reportes de miembros: Ver “Cuenta de jaras”. Son las cuentas que
mostrarán sus saldos al resto de miembros.
• Tarjetas: Deshabilitar todo

Agregamos un nuevo grupo:

• Tipo: “Miembro”
• Nombre: “Consumidores/as socios/as”
• Copiar configuración de: “Proveedores”
Tras Aceptar vamos a “Cuenta de jaras” y cambiamos:
• Límite mínimo de crédito: 0 (esto se cambiará en función de que aporten capital
social)

Crear transacciones

Las transacciones vienen a ser como el tipo de operaciones que se pueden realizar. Cada
cuenta puede tener diferentes tipos de transacciones.

• Registro de compra-ventas. Eliminamos los tres tipos de transacción existentes.

Agregamos nuevos tipos de transacción:

Nombre: “Compra”
• Descripción: Para registrar los totales de las compras de consumidores finales y
sobre la que se aplicarán las bonificaciones y tasas.
• Desde: “Registro de compra-ventas”
• A: “Registro de compra-ventas”
• Habilitado: Sí
• Invocar clase Java. Estudiar qué puede permitir esto.

• Cuenta de jaras. Agregamos nuevos tipos de transacción:

Nombre: “Bonificación por compra”

• Descripción: Para asignar la bonificación que reciben los usuarios al realizar una
compra.
• Desde: “Cuenta de jaras”
• A: “Cuenta de jaras”
• Habilitado: Sí
Nombre: “Tasa para Moneda social JARA”
• Descripción: Para asignar la tasa que recibe el Moneda social por cada compra.
• Desde: “Cuenta de jaras”
• A: “Cuenta de Moneda social”
• Habilitado: Sí
 Nombre: “Cuota”
• Descripción: Para cobrar la cuota anual.
• Desde: “Cuenta de jaras”
• A: “Cuenta de Moneda social”
• Habilitado: Sí

Crear Cargos de transacciones

Se utiliza para asignar cargos a operaciones determinadas. Los cargos son también tipos de
transacción que han debido ser creadas previamente.

Vamos a dar de alta los cargos que se efectuarán al realizar una operación de compra.

• Cuenta “Registro de compra-ventas” → Tipo de transacción “Compras”

Vamos al apartado “Cargos de transacción” y agregamos dos nuevas:

Nombre: “Bonificación consumidor/a”

• Habilitado: Sí
• Será cobrado a: “Miembro que está recibiendo (destino)”
• Será pagado a: “Miembro que está pagando (origen)”
• Permitir cualquier cuenta: Sí
• Tipo de transacción generado: “Bonificación por compra”
• Tipo de cargo: “Porcentaje”
• Cambiar valor: 3% Aquí está el asunto nodal. Este valor debería ser
personalizado para cada proveedor. La idea es ver de crear campos
personalizados de usuario (que sí se puede), y modificar el código para que este
valor se coja del registro del proveedor. Creo que lo mejor sería crear una nueva
opción de “Tipo de cargo” que fuera algo así como “Personalizada” y que diera
lugar a tener que seleccionar el nombre del campo personalizado. Si se os ocurre
otra forma la analizamos.
• Deducción: “No deduzca del monto total”
• Desde todos los grupos: Sí
• Para todos los grupos: Deshabilitamos y seleccionamos “Proveedores”

Nombre: “Comisión por venta para Moneda social JARA”

• Habilitado: Sí
• Será cobrado a: “Miembro que está recibiendo (destino)”
• Será pagado a: “Cuenta del sistema”
• Permitir cualquier cuenta: Sí
• Tipo de transacción generado: “Tasa para Moneda social JARA”
• Tipo de cargo: “Porcentaje”
• Cambiar valor: 2% El mismo comentario del cargo anterior.
• Deducción: “No deduzca del monto total”
• Desde todos los grupos: Sí
• Para todos los grupos: Deshabilitamos y seleccionamos “Proveedores”
Crear Cargos de Cuenta

Cargo de cuenta
 Nombre: “Cuota anual”
• Habilitado: Sí
• Modo de cobro: Monto fijo
• Origen-destino del pago: Miembro a sistema
• Tipo de transacción: Ver de crear una transacción propia (seguramente en
Cuenta del Moneda social) o usar “Tasa par Moneda social JARA”.
• Monto: Hay que conseguir que se pueda personalizar para grupos añadiendo
campo personalizado que sea “Cuota” y se obtenga el valor de allí.
• Enviar factura: Nunca (las cuentas del miembro pueden quedar negativas),
aunque implicaría en caso de negativo bloquear la cuenta y no parece que se
reciba mensaje por parte del Administrador. Quizá sea mejor la opción primera
de “Enviar factura al miembro si no tiene suficiente crédito” para darle tiempo a
contestar o ampliar crédito; habría que ver las opciones de control que esto
requiere. Tampoco veo si sería posible “Devolver” un cobro de estos.
• Modo de ejecución: Manual (ya veremos en su momento de ponerla en
programado o no). Interesa ver si es posible ejecutarla para usuarios específicos
y quizá variando el monto, ya que podemos imaginar usuarios que se incorporan
a mitad de año y queramos cobrar cuota proporcional.
• Grupos: Seleccionador todos los adecuados
Esta operación se puede ejecutar por el Administrador (Quizá Administrador de
usuarios) desde Cuentas → Cargos de cuenta.

Operativa
Antes de nada debemos añadir los usuarios que queramos en Usuarios & Grupos →
Administrar usuarios y en la última opción “Crear un miembro” seleccionamos el Grupo al que
va a pertenecer y se nos abre la ficha a rellenar. Conviene habilitar la última opción “Asignar
contraseña” para introducirla directamente ya que no tendremos habilitado el envío de correos
electrónicos.

Realizar pagos

En Cyclos, como en cualquier cuenta bancaria, es la parte pagadora la que tiene la potestad de
ejecutar o aceptar cargos. Nosotros aprovechamos esta característica para que en una
operación de compra típica, que actualmente se paga mayoritariamente en € y puede que una
parte en jaras, sea la parte compradora la que tenga que hacer el registro en internet (al
margen de ver los posibles procesos de pago por móvil, tarjeta, tpv...), apuntando el total de la
venta como parte pagadora (que irá a la cuenta no relevante “Registro de compra-ventas”)
para que automáticamente se asigne a su favor, en su “Cuenta de jaras”, los jaras de
bonificación, a la vez que la comisión en jaras para la Moneda social Jara van a la “Cuenta del
Moneda social”.

Para registrar un pago, simplemente pinchamos en la opción “Pago” e introducimos los datos
de la compra. Ahora solo tenemos una operación posible “Compra”, pero tendremos más y
dependiendo de ello, habrá que elegir la transacción u operación que queramos hacer y podrán
aparecer distintos campos a rellenar. Es importante rellenar el primer campo (código
destinatario) ya que dependiendo quién sea pueden aparecer diferentes tipos de transacciones
posibles. Quizá convenga cambiar el texto “Pago” por “Operaciones”; y el descriptor
“Cantidad” por “Total venta” aunque parece que esto afectaría a todas las operaciones y ya no
significarían lo mismo. Estos cambios se hacen en Traducción → Aplicación → Buscar; por
ejemplo la clave del descriptor mencionado es “transfer.amount”.
Aquí tenemos la segunda cuestión relevante que afecta a la programación. En esta operación
de “Compra” deberíamos conseguir que nos apareciera otro campo numérico llamado “Pagado
con jaras” en el que apuntar la parte que hayamos podido pagar con la moneda social. Creo
que la mejor manera de hacer esto, sin que afecte para nada al funcionamiento general de
Cyclos, es creando una variable que pueda ser seleccionada vía “Cargos de transacción” para
que aparezca el campo asociado en la ventana de Pagos; así, dentro de la transacción
“Compra” añadiríamos un cargo llamado “Pago con jaras” que habilitaría dicha opción. Cuando
se seleccione una operación que tenga asignado dicho cargo, aparecerá el campo en la
ventana de pago para que se rellene (valores permitidos igual o mayor de 0). Pero analizar
otras posibilidades de hacerlo.

Otro tema, aunque menor es que en la ventana de Pagos, tras el campo “Cantidad” aparece el
símbolo de la moneda B; realmente este campo será una mezcla de € y jaras y puede llevar a
confusión. Pero como digo es menor y tengo la sensación de que eliminarlo o cambiarlo puede
afectar a otras operaciones y páginas que no merecería la pena.

Devolución de pagos

No es posible borrar una transacción que ha sido realizada. En lugar de ello hay que devolver el
pago (lo tiene que realizar quien ha recibido el pago). En los permisos de grupo hay que
habilitar las transacciones que permiten esta operación. Para hacerla hay que buscar dicha
operación en la cuenta correspondiente a la operación, seleccionarla y aparecerá, abajo a la
derecha del cuadro “Detalles de transacción” un descripto llamado “Acciones” que al pincharlo
nos aparecerá un botón de “Devolución”.

Ahora voy señalando cosas que he ido mirando pero poco, o que habrá que mirar.

Campos personalizados

Habrá que ver cuales añadir para los diferentes perfiles de miembros. En principio seguros los
de % Bonificaciones para consumidores y Moneda social JARA. Aunque aquí tenemos alguna
duda; hay proveedores que tienen líneas de productos o servicios a los que quieren aplicar
diferentes bonificaciones, lo que implicaría que en vez de valores asociados al miembro debería
ser a una tabla de productos y servicios. Aquí podría entrar en juego los “Anuncios” que parece
dan la posibilidad de meter productos y servicios y también pueden tener campos
personalizados. Tengo dudas sobre lo que puede implicar todo esto en la operativa ¿Cómo
seleccionar el producto al ir a realizar el Pago en una transacción?; si es demasiado jaleo igual
es mejor dejarlo de momento y forzar a que los proveedores tengan una bonificación única.

Exportar e importar configuraciones

En Configuración.
No he conseguido saber claramente lo que se exporta e importa. Puede ser importante de cara
a la importación de los saldos o transacciones de la aplicación actual cuando migremos a ésta.

Anuncios

En teoría podría servirnos para dar de alta productos y servicios. Sólo que la web donde se verá
esto es la de konsumoresponsable.coop. Quizá pueda tener utilidad más adelante aunque me
ha parecido que se pude habilitar a usuarios a dar de alta anuncios pero no pueden
modificarlos o darlos de baja.

Filtros de pago

Parece que está bien de cara a informes y estadísticas. No he conseguido ver cómo se pueden
habilitar para usuarios diversos.

Reportes

Ver si se pueden crear informes personalizados. Y acceso de diversos usuarios.

Formulario de registro

Por ver.

Personalizar páginas
Gestión de contenido → Archivos estáticos:

• Página de bienvenida: personalizar (general_news)

• Ver otras

Usuarios

Comprobar lo que pasa cuando se bloquea a un usuario: si no dejamos que entre, si le dejamos
pero con todo deshabilitado, qué tipo de mensaje.... Hay que cambiarle de grupo; a mi me
daba error al intentar cambiar uno a “Disabled members”.

Posibles tipos a añadir:

• Consumidores/as no socios/as
• Consumidores colectivos
• Organizaciones (también proveedoras)
• Organizaciones (sólo consumidoras)

• Administradores de sistema
• Administradores de usuarios
• Usuarios bloqueados
• Usuarios eliminados

Transacciones

Pendientes de dar de alta:

Registro de compra-ventas

• Venta intermedia (Entre proveedores que uno es mayorista y otro minorista de un

producto o servicio. Será similar a “Compra” pero aún no claro si tiene sentido por las
reglas en cuanto a las bonificaciones).

Cuenta de jaras

• Cuota anual. Desde “Cuenta de jaras” a “Cuenta de jaras”.

• Pago interno. Por ejemplo para un pago dentro de un grupo de consumo que no lleva
bonificaciones ni tasas. Desde “Cuenta de jaras” a “Cuenta de jaras”.
• Salario. Algo que ya se están planteando algunas entidades y que de momento no
llevará “impuesto” pero quizá se plantee en un futuro. Desde “Cuenta de jaras” a
“Cuenta de jaras”.

Posibles
• Pago con jaras. Esta sólo será necesaria si no resolvemos lo de meter el campo
específico al hacer un Pago
• Fondo de Garantía. Se puede llegar a plantear que una parte de la tasa que va al
Moneda social JARA se guarde como garantía de la gente o entidades que se vayan del
Moneda social dejando una deuda. Habrá que valorar desde el propio Moneda social
JARA su pertinencia y cómo se hace: % de la tasa por venta, sobre volumen de jaras en
circulación...)

Cuenta externa

Se refiere a una relación entre una cuenta en un banco normal y nuestra moneda social.
Esta seguramente sea importante para el tipo de transacción:
 • Compra-venta de jaras. Existe la posibilidad de que los usuarios obtengan jaras
haciendo una transferencia equivalente de € a una cuenta bancaria normal.
Habrá que ver si hay manera de sincronizar las cuentas o hay que meter el
apunte bancario normal a mano.

Diseño

Ir mirando algo de homogeniezar el estilo con el de la página de la JARA, haciendo propuestas

de cambio de imágenes y no sé hasta donde de los estilos. En Gestión de contenido se puede
ver las opciones.

Otros comentarios

Cuando se pide la confirmación de un pago aparece una especie de “ticket”. En relación a los
cargos de transacción, cuando son a costa de quien paga (origen) aparecen en el ticket dichos
cargos. Si son a costa del destino no aparecen, como es en el caso de la transacción “Compra”.
Creo que sería interesante que apareciera aunque no sé si es posible.

En la configuración de Grupos hay una opción dentro de la caja “Configuración de pagos” que
dice “Ocultar moneda...). Mirar que significa esto.

En general para todos ir viendo las posibilidades de Cyclos que puedan ser interesantes para
nuestro modelo.