Su uso es muy sencillo:
$ clive http://www.youtube.com/watch?v=oHg5SJYRHA0

fetch http://www.youtube.com/watch?v=oHg5SJYRHA0 ...done.
verify video link ...done.
RickRollD.flv  100%   7.7M /  7.7M                              57.1K/s  02m18s

Hay más opciones, como “-f best” para descargar la versión con el formato de mejor calidad o si queremos descargar solo el audio podemos hacer:

$ clive --exec="ffmpeg -i %i -acodec libvorbis %i.ogg;" http://www.youtube.com/watch?v=oHg5SJYRHA0
$ clive --exec="ffmpeg -i %i %i.mp3;" http://www.youtube.com/watch?v=oHg5SJYRHA0

La opción que buscamos es ‘Key sequence to kill the X server‘:

Una vez configurado el modo de pago ya podemos generar remesas desde ‘Contabilidad -> Pago -> Órdenes de cobro‘.

Pulsamos sobre ‘Nuevo’ y solo tenemos que indicar el modo de pago antes de poder “Seleccionar facturas a pagar/cobrar”.

Para la norma 43 haremos lo mismo pero definiendo primero los conceptos bancarios.

Vamos a ‘Contabilidad -> Configuración -> Contabilidad financiera -> Diarios -> Diarios‘ y en el diario de venta (SAJ: Sales Journal) marcamos ‘Permitir cancelación de asientos’.

Desde el menú de ‘Contabilidad -> Configuración -> Contabilidad financiera -> Diarios -> Diarios’ seleccionamos un diario.

En la sección de ‘Atajos’ encontramos el asistente ‘Renumerar asientos contables’.

Lo lanzamos y seleccionamos los diarios y periodos a renumerar.

Cuando termina, el asistente nos avisa de que ha realizado la operación solicitada.

Para solventar esto instalamos el módulo ‘nan_account_invoice_sequence’ (cómo instalar módulos en OpenERP) que nos crea cuatro secuencias para facturas normales y facturas rectificativas de clientes y proveedores: account invoice in (facturas a clientes), account refund in (fac. rectificativas), account invoice out (facturas de proveedores), account refund out (fac. rectificativas).

Debemos ir a los diarios y asignar las nuevas secuencias desde el menú de ‘Contabilidad -> Configuración -> Contabilidad financiera -> Diarios -> Diarios’.

Asignamos al diario ‘Purchase Journal’ la secuencia ‘Account invoice out’.
Asignamos al diario ‘Sales Journal’ la secuencia ‘Account invoice in’.

Si vamos a mantener el formato y la numeración de facturas utilizado hasta ahora (por ejemplo FAC/2012/0001), basta con indicar en la nueva secuencia el siguiente número de factura. Abrimos ‘Administración -> Configuración -> Secuencias -> Secuencias’.

Es decir, si hemos emitido 20 facturas, indicamos que el siguiente número es el 21.
Para que todo sea correcto, ejecutamos el asistente de renumerar asientos contables en OpenERP. Con esto ya hemos terminado.

Si deseamos modificar la numeración de las facturas existentes, bien porque cambiamos el formato, bien porque la numeración no es correcta, en vez de lanzar la renumeración automática de asientos es preferible ir factura a factura y hacer: cancelar->borrador->validar->cancelar->borrador->validar (es decir cancelamos y validamos dos veces cada factura).
ATENCIÓN: Esto tiene varios problemas. Primero, las facturas emitidas y enviadas a clientes, legalmente no pueden cambiar su número así como así. Segundo, las facturas ya pagadas habrán generado los correspondientes movimientos que también habrá que deshacer y rehacer.
En general es mejor no modificar la numeración de las facturas una vez se han emitido en producción.

Sin embargo hay una forma casi igual de sencilla y mucho más potente, con dos sesiones, usando los túneles SSH.
Primero, desde el cliente, hacemos un túnel ssh desde el puerto 3690 del servidor a nuestro puerto local 3690:
$ ssh usuario@servidor -p xxxx -i id_dsa_key_ssh -L 3690:localhost:3690

A partir de hay usamos svn como si estuviese instalado en local:
$ svn co svn://servidor/proyecto

Los túneles ssh son uno de los mejores inventos… se pueden usar para acceder “localmente” a cualquier servidor externo, de cualquier servicio (postgres, svn…) de forma segura y cómoda.

#!/bin/bash
#
# unidades_red 0.2 - GPL
# (c) 2007-05 Guimi
# http://guimi.net
#
# Ult mod: Guimi 2012-03
#

# Solicitamos la clave
echo  -n "Introduzca su clave de red: "
# Tomamos nota del estado de stty
oldmodes=`stty -g`
# Quitamos el echo para que no se muestre la clave
stty -echo
# Leemos la clave
read clave
# Volvemos a situar stty como estaba
stty $oldmodes
# Generamos un salto de linea
echo

# OJO: LA CLAVE SE REGISTRA
sudo mount -t cifs //SERVIDOR/RECURSO /MONTAJE/ -o username=guimi,workgroup=MIRED,iocharset=utf8,file_mode=0777,dir_mode=0777,password=$clave

Una solución pasa por expect.
# aptitude install expect

#!/usr/bin/expect -f
#
# unidades_red 0.3 - GPL
# (c) 2012-03 Guimi
# http://guimi.net
#
# Ult mod: Guimi 2012-03
#
# Tomamos el primer parametro como clave
#set clave [lrange $argv 0 0]

# Solicitamos la clave de red
send_user "Introduzca su clave de red: "
stty -echo
expect_user -re "(.*)\n" {set clave $expect_out(1,string)}
stty echo
send_user "\n"

# Anulamos la salida por terminal
log_user 0

# Conectamos las unidades de red
spawn sudo mount -t cifs //SERVIDOR/RECURSO /MONTAJE/ -o username=guimi,workgroup=MIRED,iocharset=utf8,file_mode=0777,dir_mode=0777
expect "*assword:"; send "$clave\r"
expect eof

spawn sudo mount -t cifs //SERVIDOR/RECURSO2 /MONTAJE2/ -o username=guimi,workgroup=MIRED,iocharset=utf8,file_mode=0777,dir_mode=0777
expect "*assword:"; send "$clave\r"
expect eof

Para solventarlo vamos al foro de OSCommerce, donde tenemos los parches.

Después siguiendo esta receta de cómo generar (diff) y aplicar (patch) parches, bajamos de github los parches, añadiendo “.patch” al URL y aplicar los parches.

$ wget https://github.com/osCommerce/oscommerce2/commit/79c601a7b3ee87943b92a5e6d77ce02480b49ffe.patch
$ wget https://github.com/osCommerce/oscommerce2/commit/88d550f392d86c02d2fe16d0b93f1de8aa6a6770.patch
$ wget https://github.com/osCommerce/oscommerce2/commit/1bfed2f6bf0e9c1c0ce4b160bce1e881cc6e6ef8.patch
$ wget https://github.com/osCommerce/oscommerce2/commit/15101263fa27b523139b405f99b1613c71a8e2c1.patch
$ wget https://github.com/osCommerce/oscommerce2/commit/bc2bcd9b1bd2148bf852409b3843543555bc01e2.patch
$ patch -p1 < 79c601a7b3ee87943b92a5e6d77ce02480b49ffe.patch

patching file catalog/admin/backup.php
patching file catalog/admin/cache.php
Hunk #1 succeeded at 91 with fuzz 2.
patching file catalog/admin/configuration.php
patching file catalog/admin/ext/modules/payment/sofortueberweisung/install.php
[...]
patching file catalog/admin/includes/functions/general.php
Hunk #1 FAILED at 939.
1 out of 1 hunk FAILED -- saving rejects to file catalog/admin/includes/functions/general.php.rej
[...]
patching file catalog/includes/modules/payment/paypal_express.php
Hunk #1 FAILED at 59.
1 out of 1 hunk FAILED -- saving rejects to file catalog/includes/modules/payment/paypal_express.php.rej
[...]

Si nos fijamos en esta parte de la salida:

patching file catalog/admin/includes/functions/general.php
Hunk #1 FAILED at 939.
1 out of 1 hunk FAILED -- saving rejects to file catalog/admin/includes/functions/general.php.rej

Vemos que al parchear el fichero "catalog/admin/includes/functions/general.php" en la línea 939 ha habido un error.
Tenemos más información en "catalog/admin/includes/functions/general.php.rej". Lo que hace patch en este casp es generar 3 ficheros:
- general.php es el fichero original CON los cambios que SÍ ha aplicado.
- general.php.orig es el fichero original.
- general.php.rej contiene los cambios que NO ha aplicado.
Así si el parche incluye varios cambios para un fichero puede ocurrir que unos cambios se apliquen y otros no.
En este caso no queda más remedio que revisar el cambio no realizado a mano.

Puede ocurrir que el archivo a parchear no exista. En ese caso tendremos solo dos ficheros:
- x.orig con 0 bytes, es copia del original. Como éste no existía, es un archivo en blanco.
- x.rej los cambios que no se han aplicado.
Basta con confirmar que es correcto que el fichero no exista. podría ocurrir que esté movido (revisar porqué), o que sea de un módulo del que no disponemos -lo habitual- (ignorar).

Igual con el resto de parches:

$ patch -p1 < 88d550f392d86c02d2fe16d0b93f1de8aa6a6770.patch
$ patch -p1 < 1bfed2f6bf0e9c1c0ce4b160bce1e881cc6e6ef8.patch
$ patch -p1 < 15101263fa27b523139b405f99b1613c71a8e2c1.patch
$ patch -p1 < bc2bcd9b1bd2148bf852409b3843543555bc01e2.patch