Este es un post instructivo con algunos tips. Espero que los ayude y les guste.

Introducción:

El SIAP es un programa generado por la Administración de Ingresos Públicos (AFIP) de la República Argentina. Es un sistema hecho en Microsoft Visual Studio. El sistema consta de un modulo principal (SIAP) y submodulos secundarios, que suelen ser de la misma administración o de otras administraciones tributarias de la República Argentina. El sistema es mono puesto y mono usuario.

El aplicativo funciona en Microsoft Windows 9x o superior, excepto las versiones de 64 bits y bajo Windows Vista y Seven con algunas reservas; en las versiones de 64 bits funciona, pero hay un par de aplicativos que corren bajo SIAP que utilizan librerías de 32 bits que son INCOMPATIBLES con Windows X 64 bits.

Se sabe que puede correr bajo Wine, pero el depurador de Wine acusa innumerables bugs y reentradas de llamadas a procedimientos de librerías. No he tenido tiempo de probar 100% si realmente funciona y cuales son los alcances y compatibilidad con Wine.

Como describí anteriormente el SIAP es un sistema mono puesto y monousuario pero se puede hackear fácilmente para utilizarlo múltiples veces en una misma maquina. El problema de monousuario persiste ya que la base de datos se abre exclusiva por el aplicativo, aunque también hay hacks para usarlo en modo multiusuario (aunque no es recomendado). Si se puede usar múltiples copias del sistema al mismo tiempo (es decir, muchas ejecuciones de SIAP en carpetas diferentes). Ver mas abajo.

Sobre los módulos:

En la actualidad, el SIAP y los módulos, son casi independientes a nivel de datos. El SIAP guarda la información tributaria básica de los contribuyentes declarados (SISTEMA.MDB y AFIP.MDB) y cada modulo contiene a su vez sus tablas secundarias (llamadas generalmente algo.MDB con una numeración correlativa) y su tabla principal, que generalmente es el mismo nombre que el aplicativo, por ejemplo IVA.MDB. En este último, generalmente se almacenan las DDJJ y cualquier dato relevante del aplicativo en si.

Cada vez que se instala un modulo nuevo, este genera una carpeta en el programa SIAP con el nombre del modulo. En él se guardan los archivos MDB propios del programa, los ejecutables (que muestran el icono en el programa SIAP) y algunas librerías anexas. Opcionalmente el instalador también suele dejar librerías y componentes OCX en la carpeta de sistema de Windows.


Como guarda los datos cada modulo y que formato usan:

Están generados con la versión 95/97 de Access (en realidad, es legado de Visual Studio, se generan en esa versión compatible) siguiendo una estructura determinada. Todos los MDB de TODOS los módulos (incluyendo el SIAP) tienen clave. La clave de TODOS los MDB generalmente es "naDdePraKciN" (sin las comillas). Puede que para abrir los archivos, sea necesario primero correr una aplicación creada por la afip llamada reparabase.exe que se encuentra en aquí (http://www.afip.gob.ar/genericos/guiavirtual/consultas_detalle.aspx?id=2061603) ya que con el paso del tiempo, el archivo .MDB suele truncar datos y es necesaria correr esa herramienta para reparar y compactar la base antes de abrirla con Microsoft Access o cualquier herramienta que permita abrir la versión del .MDB



Backup:

La copia de seguridad puede hacerse de varias maneras.

1.- Por sistema: El SIAP posee un modulo de backup propio. El mismo genera un backup comprimido (ZIP) de las MDB de los módulos existentes del contribuyente a generar el backup. Su principal ventaja es que el backup de esta manera, genera se realice el backup de ese contribuyente, y que el backup resultante sea solo la información de este. Su principal desventaja en radica en que deben existir en el SIAP destino del backup (donde se piensa restaurar la información) los módulos CON LAS MISMAS VERSIONES; si alguna no fuera igual, el backup falla. El .ZIP del backup esta protegido por una contraseña. Para recuperar la información del backup (o un MDB en particular) se puede hacer lo siguiente sin necesidad de romper la contraseña: Desde el aplicativo SIAP, ejecutar la recuperación del backup, y cuando genere el error (o bien en el proceso intermedio) ir a la carpeta donde este instalado o ejecutando el SIAP y copiar la carpeta temporal que contiene el backup (el sistema descomprime previamente ahí el contenido del ZIP, y por lo tanto lo deja accesible para poder copiarlo descomprimido y sin clave). Por ultimo, este método SOLO HACE BACKUP DE UN CONTRIBUYENTE A LA VEZ. No estoy seguro si este método agrega la información a un modulo existente, aunque debería ser así.

2.- Por modulo: Cada modulo tiene a su vez su sistema de backup. Como en el caso anterior, es necesario la misma versión del modulo para recuperar la información. En este caso se recupera TODA LA INFORMACION DEL MODULO, es decir, recupera TODOS LOS DATOS DE TODOS LOS CONTRIBUYENTES. No estoy seguro si este método agrega la información a un modulo existente, aunque debería ser así.

3.- Por copia directa. Se puede copiar TODO EL SIAP (carpeta de instalación y módulos) y restaurarla luego en un sistema destino copiándola en el mismo lugar. Para recuperar 100% toda la instalación, se recomienda instalar el SIAP y los módulos en la PC destino, y luego pisar la copia instalada por la copia del backup de la PC origen; esto es más que nada, por las librerías y OCX que se instalan el %SYSTEM% de Windows. Si algún modulo no se instala, puede ocurrir algún error al momento de ejecutar ese modulo, por alguna librería u OCX faltante.

4.- Copia directa del modulo: Al igual que el caso anterior, se puede copiar solo un modulo para migrarlo a una PC destino. En la PC destino, se debe instalar el modulo previamente y luego pisar con la carpeta copia ese modulo instalado. Recordar que debe estar declarado el contribuyente en el SIAP para que la información del modulo aparezca. También recordar que la realización de este tipo de copia, significa enviar las DDJJ de otros contribuyentes también para dicho modulo. Este tipo de backup sobrescribe el destino así que no puede agregar información de esta manera a lo existente (ver punto 1 y punto 2). Este tipo de backup es el recomendado a la hora de actualizar un modulo. Para actualizar un modulo, siempre recomiendo copiar la carpeta del modulo existe (por ejemplo IVA) con otro nombre (por ejemplo 11102012.IVA) y luego realizar la instalación del modulo. Si llegara a haber algún problema, simplemente abría que borrar la carpeta del aplicativo (IVA) y renombrar la anterior como la carpeta original (11102012.IVA a IVA). Como nota, hay que tener presente que SIAP dará una alerta al iniciarse si encuentra carpetas adicionales (como 11102012.IVA) así que la misma se debe OCULTAR para que la alerta no aparezca.

Multiples SIAP simultaneos:

Como dije anteriormente, el SIAP es mono puesto y monousuario. Monopuesto porque debería ejecutarse solo en una PC donde este instalado y monousuario porque al abrirlo, bloquea las MDB del SIAP y de los módulos en ejecución para una sola instancia del aplicativo. Sin embargo, se pueden ejecutar tantas copias del aplicativo como quieran, solo el limite lo dictamina las capacidades de la PC. Para esto, debería tener tantas copias del SIAP en carpetas diferentes y sus módulos correspondientes como SIAP quiera correr. Por experiencia personal le sugiero dos métodos de trabajo:

1.- Por impuesto. En este caso, debería tener tantos SIAP como impuestos discrimine. Cada SIAP debería tener cargado TODOS los contribuyentes que use, y cada SIAP debería tener un modulo (o varios del mismo IMPUESTO) para trabajar. Su principal ventaja es que ese SIAP se usaría solo para ese impuesto; eso le permite tener una persona abocada a la liquidación de ese impuesto y no entra en conflicto con otros usuarios cuando deben usar el aplicativo (porque solo lo usa una persona). Sus principales desventajas son que debe actualizar cada SIAP con su modulo (aunque no es tan traumático ya que los ciclos de pago de esos impuestos o liquidaciones se hacen cada ciertos periodos dejando ventanas de tiempo) y que ese modulo contiene toda la información de todos sus contribuyentes (y que por ende, para dar un backup de un contribuyente debería usar el método de backup Nro 1 del apartado Backup).

2.- Por contribuyente. En este caso el SIAP tiene solo un contribuyente con todos los módulos que este utiliza. Si tiene empleados que liquidan determinados clientes, esta es su mejor opción porque este empleado no bloqueara SIAP de otros contribuyentes. Otra ventaja es que ese SIAP engloba todas las liquidaciones del cliente, así que puede utilizar el método 3 del apartado backup para enviarle esa información a su cliente y solo le enviara la información de el completamente funcional en un SIAP. Su principal desventaja es que la actualización de los módulos es mucho mas tediosa (deberá actualizar modulo por modulo en cada SIAP).

Para todos los casos, el SIAP puede almacenarse en cualquier método (ZIP drive, USB, RED) con la única restricción de respetar una ruta corta de directorios (una ruta excesivamente larga puede causar problemas de apertura de archivos) y que en la maquina a ejecutar el SIAP tenga los módulos instalados localmente (al igual que el SIAP) ya que sin ese requisito puede fallar al ejecutar el SIAP o cualquier modulo asociado por las librerías y o algún componente OCX.


Actualización:

Para todos los casos el (los) SIAP a actualizar DEBEN ESTAR CERRADOS. El modulo que se ejecuta conoce la ruta del SIAP por el archivo que se encuentra en c:Windows llamado afipPath.sys; este archivo es un archivo de texto que en su interior tiene la ruta donde esta instalado el SIAP. Todos los módulos utilizan este archivo para saber donde instalarse.


Modo único.
SIAP: Luego del backup (cualquiera de los puntos 1,2,3 o 4 de apartado Backup) correr el instalador y proceder a la actualización según el proveedor del modulo lo indique en las instrucciones. Con eso se actualiza. Esta forma es para un SIAP local.

Modo multi SIAPs.
En este caso la actualización es un poco más tediosa. Generalmente hago los siguientes pasos:

1.- Si existe modulo local instalado, lo renombro como modulo.bak (por ejemplo, IVA.bak)
2.- Hago backup siguiendo el punto 4 del apartado backup y lo renombro como fecha.modulo (ejemplo 10122012.IVA). Oculto la carpeta copia para que el SIAP no me tire la alerta.
3.- Corto y pego en el SIAP local el modulo a actualizar (IVA por ejemplo) de la carpeta SIAP de red o donde este al SIAP local (Usualmente c:archivos de programaS.I.ApAFIP)
4.- correr el instalador y proceder a la actualización según el proveedor del modulo lo indique en las instrucciones.
5.- Cortar y pegar el modulo actualizado del SIAP local nuevamente a su carpeta de red o donde este.
6.- Comprobar que el modulo este correctamente actualizado ejecutando el SIAP copia.
7.- Volver el modulo copia en el siap local a su nombre original (de IVA.bak por ejemplo, a IVA).
Con eso se actualiza un modulo que existe en una carpeta distinta del SIAP original local.

Otra variante.

En este caso, el procedimiento anterior difiere un par de pasos, y lo utilizo generalmente cuando son actualizaciones masivas. Esta forma, no es recomendable si no se tiene extrema pericia en MSDOS y la línea de comandos.

Cada modulo posee un instalador generalmente de Visual Studio. Al descomprimir el instalador veremos en esa carpeta archivos con una extensión que al final generalmente tienen un símbolo "_"; estos archivos están comprimidos y para descomprimirlos se usa el comando EXPAND. A su vez también existe un archivo llamado setup.lst que contiene la información que necesita el instalador para saber donde van los archivos. Ese archivo es un archivo de texto que puede ser abierto con el NOTEPAD o cualquier editor de texto. El archivo se muestra algo así:

[ BootStrap ]
File1=1,,Setup1.ex_,Setup1.exe,$(WinPath),,,10/30/2003 16:18:26,306176,5.01.1,"","",""
File2=1,,VB5StKit.dl_,VB5StKit.dll,$(WinSysPath),,$(Shared),2/20/1997 0:00:00,29696,5.0.37.16,"","",""

[ Files ]
File1=1,,TEXTPF.OC_,TEXTPF.OCX,$(WinSysPath),$(DLLSelfRegister),$(Shared),1/27/2000 5:28:26,65024,1.0.0.5,"","",""
file2=1,,FILEWIN.DL_,FILEWIN.DLL,$(WinSysPath),,$(Shared),4/27/2011 15:43:10, 405504,,"","",""
File3=1,,bar25it.TT_,bar25it.TTF,$(AppPath),,$(Shared),9/27/2001 15:43:30,15596,,"","",""
file4=1,,cm.ex_,cm.exe,$(AppPath),,,9/22/2011 15:43:50, 1267200,2.00.0003,"","Ingresos Brutos - Convenio Multilateral","$(AppPath)cm.exe"
file5=1,,SI020003.md_,SI020003.mdb,$(AppPath),,,9/22/2011 15:22:36, 747520,,"","",""
file6=1,,Si. Fe. Re. - Convenio Multilateral.IC_,Si. Fe. Re. - Convenio Multilateral.ico,$(AppPath),,,12/14/2004 16:25:06, 766,,"","",""
file7=1,,cm03.rp_,cm03.rpt,$(AppPath),,,4/14/2011 15:33:39, 153237,,"","",""
file8=1,,cm04.rp_,cm04.rpt,$(AppPath),,,4/14/2011 15:33:39, 157505,,"","",""
file9=1,,dayf_03.rp_,dayf_03.rpt,$(AppPath),,,9/22/2011 15:26:24, 15786,,"","",""
file10=1,,dayf_04.rp_,dayf_04.rpt,$(AppPath),,,9/22/2011 15:27:05, 13775,,"","",""
file11=1,,dj_per.rp_,dj_per.rpt,$(AppPath),,,9/22/2011 15:29:38, 14834,,"","",""
file12=1,,dj_pera.rp_,dj_pera.rpt,$(AppPath),,,9/22/2011 15:30:16, 9313,,"","",""
file13=1,,dj_rec.rp_,dj_rec.rpt,$(AppPath),,,9/22/2011 15:30:56, 11186,,"","",""
file14=1,,dj_ret.rp_,dj_ret.rpt,$(AppPath),,,9/22/2011 15:31:22, 11348,,"","",""
file15=1,,finteres.rp_,finteres.rpt,$(AppPath),,,4/14/2011 15:33:39, 149582,,"","",""
....
file32=1,,SIFERE.HL_,SIFERE.HLP,$(AppPath),,,5/4/2007 15:33:12, 214510,,"","",""
file33=1,,SiFeRe.cn_,SiFeRe.cnt,$(AppPath),,,5/4/2007 15:32:30, 5165,,"","",""
file34=1,,FILEWIN2.DL_,FILEWIN2.DLL,$(WinSysPath),,$(Shared),4/27/2011 15:43:08, 405504,,"","",""

[ Setup ]
Title=Si. Fe. Re. - Convenio Multilateral
DefProgramGroup=AFIP - Aplicaciones
DefaultDir=$(ProgramFiles)S.I.ApAFIPCM
Setup=Setup1.exe
AppExe=cm.exe
AppToUninstall=cm.exe
AppPath=


Aquí nos interesan un par de datos:

DefaultDir=$(ProgramFiles)S.I.ApAFIPCM
indica donde se instalara el aplicativo y cual es su carpeta. En este caso el aplicativo tiene su carpeta llamada CM dentro del SIAP.

file6=1,,Si. Fe. Re. - Convenio Multilateral.IC_,Si. Fe. Re. - Convenio Multilateral.ico,
El .ico generalmente dice el nombre del aplicativo. Aqui sabemos que el aplicativo es SIFERE - Convenio multilateral (la carpeta recuerdan, se llama CM, que es Convenio Multilateral )

(WinSysPath) y (AppPath) en los archivos.
Cuando al lado del archivo diga (WinSysPath) ese archivo debería guardarse en la carpeta SYSTEM32 (o SYSTEM) en el Windows en cuestion. Cuando diga (AppPath) en cambio, el archivo debe guardarse en la carpeta propia del modulo (en este caso CM).

Entonces, ahora descifrando un poco las líneas entendemos que:


File1=1,,TEXTPF.OC_,TEXTPF.OCX,$(WinSysPath),$(DLLSelfRegister),$(Shared),1/27/2000 5:28:26,65024,1.0.0.5,"","",""
El archivo que se descomprimirá se llama TEXTPF.OCX y se guardara en SYSTEM (o SYSTEM32). Ese archivo debe registrarse (DLLSelfRegister) utilizando el comando regsvr32 /s TEXTPF.OCX

y así cada archivo que se encuentre en cada línea...

Entonces, podríamos hacer un batch (archivo de proceso por lotes) que haga lo siguiente:

Copia la carpeta modulo con un nombre de backup.
Oculta la carpeta backup del modulo.
Expande los archivos del aplicativo y los copia a la carpeta destino.
Registra los archivos que sean necesarios.

Un ejemplo de un batch podría ser lo siguiente:

//codigo

@echo off
cls
echo EXPANDE pulenta gpj 1.0bbbbbbb
echo lindo batch que me ahorra laburete
echo forma de uso:
echo .
echo expande "E:SIAPsS.I.Ap EmiliaAFIP\" 16112011
echo .
echo Si los path contienen espacios poner el path real entre
echo comillas dobles y doble barra final
echo si el path no es con espacios, basta ponerlo directamente
echo recordando poner la barra final.
echo el segundo parametro es la fecha de actualización del aplicativo.
echo .
echo actualizando (recordar poner final)
echo %1
echo backup de fecha (recordar usar DDMMAAAA)
echo %2
echo si es incorrecto presione CTRL+C
if not exist %1 goto end
if not exist %2 goto end
pause
mkdir %1%2.gmp >nul
xcopy %1gmp %1%2.gmp /s /e >nul
attrib +h %1%2.gmp >nul
echo backup completo y cubierto, iniciando inflado...
echo .
echo .
expand BIENES.RP_ %1gmpBIENES.RPT
expand cboDB.oc_ %1gmpcboDB.ocx
expand "Ganancia Minima Presunta.ic_" %1gmp"Ganancia Minima Presunta.ico"
expand GMP.CN_ %1gmpGMP.CNT
expand GMP.EX_ %1gmpGMP.EXE
expand GMP.HL_ %1gmpGMP.HLP
expand RPFRM1.RP_ %1gmpRPFRM1.RPT
expand RPFRM2.RP_ %1gmpRPFRM2.RPT
expand SI090000.MD_ %1gmpSI090000.MDB
rem librerias en sistema
expand TEXTPF.OC_ %windir%system32TEXTPF.OCX
expand FECHA32.OC_ %windir%system32FECHA32.OCX
expand FILEWIN2.DL_ %windir%system32FILEWIN2.DLL
rem fuente de codigo de barras
expand 3of9.tt_ %windir%fonts3of9.ttf
rem registrar librerias silenciosamente
regsvr32 /s %windir%system32TEXTPF.OCX
regsvr32 /s %windir%system32FECHA32.OCX
regsvr32 /s %windir%system32FILEWIN2.DLL
:end

//codigo


De esta manera, con un batch puede actualizar gran cantidad de SIAP mucho más sencillamente (aunque desde luego, puede fallar). En este caso el batch hace una copia de la carpeta, la oculta, y luego expande los archivos sobre los existentes. Este paso remplazaría a los pasos del método anterior.
Para generar la lista de archivos a expandir, se puede usar el comando dir /b >>archivo.bat donde dir con el parámetro /b solo deja los nombres y extensión (saca toda la información extendida) y >>archivo.bat redirecciona el resultado de pantalla a un archivo.bat

Espero que les haya servido el post. Saludos.

NOTA: Al postear, he visto que se eliminan las barras invertidas (\) el post sin modificación lo encuentran en mi blog si no se dan maña.


Diego Leonardo Revechini
http://www.olafitoweb.com.ar