Concepto del ERP y propuesta para crear un FIVE-ERP

[jnavas]

Saludos cordiales.

Soy Juan Navas, creador de AdaptaPro, tengo 27 años desarrollando aplicaciones comerciales, hace más de 10 años decidimos crear un sistema de concepto ERP, logramos crear una solución para uso propio que nos permitía conocer todas las actividades o compromisos de la empresa en forma de semáforo, esto nos llevó a gestionar nuestra empresa bajo los fundamentos de la gerencia: Planificación, Dirección, Supervisión y evaluación.
Hemos estado conversando con Antonio Linares para crear un nuevo producto comercial ERP de código Abierto con muchas funcionalidades predefinidas donde podamos concretar en cada país a un socio representante que pueda adaptarlo a los tributos y exigencias formales en cada país. El negocio se fundamenta en cuatro pilares:
1. Tecnologías (todos lo referente al binario o kernel de la aplicación)
2. Conceptualización (Como se vende, implementa y utiliza un ERP), herramienta para empresarios y luego para usuarios que deben trabajar mediante tareas indicadas por el ERP.
3. Comercialización o Agentes de Ventas.
4. Prestación de Servicios mediante proyectos de implementación. Un ERP debe ser utilizado en modo de producción (Planificación de todas las actividades de los usuarios, certificación de resultados y capacitación de usuarios y asesorías permanentes). Contamos con un sistema de gestión de proyectos para uso nuestro y para comercialización.

Mi página Web, actualmente está en rediseño mediante gestor de contenidos y plantillas, nuestras aplicaciones están siendo adaptadas hacia las NIFF (Normas internaciones de Información Financiera) y NIC (Normas internacionales de contabilidad) que nos permitiré ser implementado con facilidad de ser implementado en cualquier país que adopte estas normas.
Estamos en la búsqueda de socios para el desarrollo y comercialización de esta herramienta en cada país. Agradezco cualquier comentario o propuesta para presentar un nuevo ERP.
Actualmente estamos creando video en youtube de presentación del concepto ERP de AdaptaPro . Nuestro ERP será la referencia de experiencia y planteo rediseñar un nuevo modelo ERP.
Porque llegamos a crear un ERP: Precedenctes.
Juan Navas “Creador de DataPro y AdaptaPro”, recopiló más de 20 años de experiencia siendo director y/o accionista de diversas firmas jurídicas dedicadas la actividad comercial “AdaptaPro”, gracias la responsabilidad legal, diseño un modelo de sistema proactivo basado en la planificación en las soluciones en diversas áreas: Tributario, Proyectos, Gestión de Clientes o (CRM) Finanzas, Laboral y demás deberes formales. La experiencia directa en AdaptaPro y experiencia obtenida en miles de implementaciones fue la materia prima para gestar un modelo de solución empresarial de alcance “ERP”, donde la gestión de la empresa se realiza mediante previa planificación y medidores de gestión para conocer las actividades: Realizadas en su debido momento, las actividades no realizadas en la fecha establecida y las actividades por realizar. Además el concepto logra evitar de manera proactiva las omisiones o incumplimientos causados por el factor humano: La memorización, discrecionalidad, desconocimiento y la disposición.
El concepto o filosofía del ERP está en la manera de realizar las transacciones o actividades del usuario, en un ERP el usuario de tesorería es informado mediante un formulario de actividades todas las actividades o tareas que debe realizar: Calcular y Pagar Impuestos, Servicios de electricidad, teléfonos, nóminas, entre otros. En cambio un sistema para la administración es discrecional, el usuario es quien decide las actividades que va a realizar y luego las registra en el sistema para luego generar listados o informes.
Aspectos tecnológicos:
Debe estar basado en el modelo de bases de datos relaciones (RDBMS), todas las aplicaciones deben utilizar la misma base de datos sin procesos de integración ni redundancia de datos.
Arquitectura Abierta: Mediante el concepto de diccionario de datos o Metadatos “todas las tablas podrán ser adaptadas según la necesidad del cliente”.
Código fuente abierta o disponible: Todos los programas que generan las transacciones financieras podrá estar disponible para que el usuario las adapte a sus necesidades o país. En nuestro caso hemos utilizado FIVESCRIPT adaptado a nuestro criterio, y programas (PRG) precompilados en modulos HRB

Programa DPXBASE
// Programa : DPCONTENIDOS
// Fecha/Hora : 14/12/2014 23:06:29
// Propósito : Incluir/Modificar DPCONTENIDOS
// Creado Por : DpXbase
// Llamado por: DPCONTENIDOS.LBX
// Aplicación : Administración del Sistema
// Tabla : DPCONTENIDOS

#INCLUDE "DPXBASE.CH"
#INCLUDE "TSBUTTON.CH"
#INCLUDE "IMAGE.CH"

FUNCTION DPCONTENIDOS(nOption,nId)
LOCAL oBtn,oTable,oGet,oFont,oFontB,oFontG
LOCAL cTitle,cSql,cFile,cExcluye:=""
LOCAL nClrText
LOCAL cTitle:="Gestión de Contenidos"

cExcluye:="CON_ID,;
CON_CODIGO,;
CON_ACTIVO"

DEFAULT nID :=SQLGET("DPCONTENIDOS","CON_ID"),;
nOption:=1

DEFINE FONT oFont NAME "Verdana" SIZE 0, -10 BOLD
DEFINE FONT oFontB NAME "Arial" SIZE 0, -12 BOLD ITALIC
DEFINE FONT oFontG NAME "Arial" SIZE 0, -11

nClrText:=10485760 // Color del texto

IF nOption=1 // Incluir
cSql :=[SELECT * FROM DPCONTENIDOS WHERE ]+BuildConcat("CON_ID")+GetWhere("=",nID)+[]
cTitle :=" Incluir {oDp:DPCONTENIDOS}"
ELSE // Modificar o Consultar
cSql :=[SELECT * FROM DPCONTENIDOS WHERE ]+BuildConcat("CON_ID")+GetWhere("=",nID)+[]
cTitle :=IIF(nOption=2,"Consultar","Modificar")+" Gestión de Contenidos "
cTitle :=IIF(nOption=2,"Consultar","Modificar")+" {oDp:DPCONTENIDOS}"
ENDIF

oTable :=OpenTable(cSql,"WHERE"$cSql) // nOption!=1)

IF nOption=1 .AND. oTable:RecCount()=0 // Genera Cursor Vacio
oTable:End()
cSql :=[SELECT * FROM DPCONTENIDOS]
oTable :=OpenTable(cSql,.F.) // nOption!=1)
ENDIF

oTable:cPrimary:="CON_ID" // Clave de Validación de Registro

oCONTENIDOS:=DPEDIT():New(cTitle,"DPCONTENIDOS.edt","oCONTENIDOS" , .F. )

oCONTENIDOS:nOption :=nOption
oCONTENIDOS:SetTable( oTable , .F. ) // Asocia la tabla <cTabla> con el formulario oCONTENIDOS
oCONTENIDOS:SetScript() // Asigna Funciones DpXbase como Metodos de oCONTENIDOS
oCONTENIDOS:SetDefault() // Asume valores standar por Defecto, CANCEL,PRESAVE,POSTSAVE,ORDERBY
oCONTENIDOS:nClrPane:=oDp:nGris

IF oCONTENIDOS:nOption=1 // Incluir en caso de ser Incremental
// oCONTENIDOS:RepeatGet(NIL,"CON_ID") // Repetir Valores
oCONTENIDOS:CON_ID :=oCONTENIDOS:Incremental("CON_ID ",.F.)
ENDIF

//Tablas Relacionadas con los Controles del Formulario

oCONTENIDOS:CreateWindow() // Presenta la Ventana

// Opciones del Formulario


//
// Campo : CON_ID
// Uso : Id del Registro
//
@ 3.0, 1.0 SAY oCONTENIDOS:oCON_ID VAR oCONTENIDOS:CON_ID ;
BORDER ;
FONT oFontG;
SIZE 16,10;
RIGHT

@ oCONTENIDOS:oCON_ID :nTop-08,oCONTENIDOS:oCON_ID :nLeft SAY "Id del Registro" PIXEL;
SIZE NIL,7 FONT oFont COLOR nClrText,15724527


//
// Campo : CON_CODIGO
// Uso : Contenido
//
@ 4.8, 1.0 GET oCONTENIDOS:oCON_CODIGO VAR oCONTENIDOS:CON_CODIGO VALID !VACIO(oCONTENIDOS:CON_CODIGO,NIL);
WHEN (AccessField("DPCONTENIDOS","CON_CODIGO",oCONTENIDOS:nOption);
.AND. oCONTENIDOS:nOption!=0);
FONT oFontG;
SIZE 320,10

oCONTENIDOS:oCON_CODIGO:cMsg :="Contenido"
oCONTENIDOS:oCON_CODIGO:cToolTip:="Contenido"

@ oCONTENIDOS:oCON_CODIGO:nTop-08,oCONTENIDOS:oCON_CODIGO:nLeft SAY "Contenido" PIXEL;
SIZE NIL,7 FONT oFont COLOR nClrText,15724527


//
// Campo : CON_ACTIVO
// Uso : Activo
//
@ 6.6, 1.0 CHECKBOX oCONTENIDOS:oCON_ACTIVO VAR oCONTENIDOS:CON_ACTIVO PROMPT ANSITOOEM("Activo");
WHEN (AccessField("DPCONTENIDOS","CON_ACTIVO",oCONTENIDOS:nOption);
.AND. oCONTENIDOS:nOption!=0);
FONT oFont COLOR nClrText,NIL SIZE 76,10;
SIZE 4,10

oCONTENIDOS:oCON_ACTIVO:cMsg :="Activo"
oCONTENIDOS:oCON_ACTIVO:cToolTip:="Activo"





oCONTENIDOS:Activate({||oCONTENIDOS:ViewDatBar()})


STORE NIL TO oTable,oGet,oFont,oGetB,oFontG

RETURN oCONTENIDOS

/*
// Barra de Botones
*/
FUNCTION ViewDatBar()
LOCAL oCursor,oBar,oBtn
LOCAL oDlg:=oCONTENIDOS:oDlg


DEFINE CURSOR oCursor HAND
DEFINE BUTTONBAR oBar SIZE 52-15,60-15 OF oDlg 3D CURSOR oCursor


IF oCONTENIDOS:nOption=2


DEFINE BUTTON oBtn;
OF oBar;
NOBORDER;
FONT oFont;
FILENAME "BITMAPS\\XSALIR.BMP";
ACTION (oCONTENIDOS:Close())

oBtn:cToolTip:="Salir"

ELSE

DEFINE BUTTON oBtn;
OF oBar;
NOBORDER;
FONT oFont;
FILENAME "BITMAPS\\XSAVE.BMP";
ACTION (oCONTENIDOS:Save())

oBtn:cToolTip:="Grabar"

DEFINE BUTTON oBtn;
OF oBar;
FONT oFont;
NOBORDER;
FILENAME "BITMAPS\\XCANCEL.BMP";
ACTION (oCONTENIDOS:Cancel()) CANCEL

oBtn:cToolTip:="Cancelar"

ENDIF

oBar:SetColor(CLR_BLACK,15724527)
AEVAL(oBar:aControls,{|o,n|o:SetColor(CLR_BLACK,15724527)})

RETURN .T.


/*
// Carga de Datos, para Incluir
*/
FUNCTION LOAD()

IF oCONTENIDOS:nOption=1 // Incluir en caso de ser Incremental
oCONTENIDOS:CON_ID :=oCONTENIDOS:Incremental("CON_ID ",.F.)
ENDIF

RETURN .T.
/*
// Ejecuta Cancelar
*/
FUNCTION CANCEL()
RETURN .T.

/*
// Ejecución PreGrabar
*/
FUNCTION PRESAVE()
LOCAL lResp:=.T.

lResp:=oCONTENIDOS:ValUnique(oCONTENIDOS:CON_ID )
IF !lResp
MsgAlert("Registro "+CTOO(oCONTENIDOS:CON_ID),"Ya Existe")
ENDIF

RETURN lResp

/*
// Ejecución despues de Grabar
*/
FUNCTION POSTSAVE()

EJECUTAR("DPCNTMNU",oCONTENIDOS:CON_ID)

RETURN .T.

/*
<LISTA:CON_ID:Y:SAY:Y:N:Y:Id del Registro,CON_CODIGO:N:GET:N:N:N:Contenido,CON_ACTIVO:N:CHECKBOX:N:N:Y:Activo>
*/

[Antonio Linares]

Juan,

Gracias por compatir tu experiencia y tus ideas con nosotros

[jnavas]

Antonio
Gracias, deseo publicar experiencia o practicas de un ERP

Podemos citar el siguiente caso de gestión en un ERP dotado de CRP y RMA:

Una empresa o tienda que vende equipos electrónicos (TV, Portátiles, Tablas entre otros) comprados a un importador o representante de (x) marcas, realiza la venta de un TV a un cliente con garantía de 6 meses por parte del importador. El cliente a los tres meses reporta una avería o desperfecto al vendedor “Tienda”.

Si la tienda o vendedor no ha contemplado en su implementación o adquisición de licencias de software (ERP) el procedimiento protocolar para gestionar un reclamo del cliente, la actividad o gestión de los reclamos será gestionada de manera “perceptiva o discrecional por parte de la persona que recibió el reclamo”- Posiblemente gestione la solución con el cliente mediante llamadas o envió de correos entre el importador (Proveedor) y comprador (cliente) sin registros electrónicos o en bases de datos de la gestión realizada.
Cuando se utiliza una herramienta ERP, esta actividad se soluciona de la siguiente manera:

1. Se implementa un sistema de reclamos o gestión de clientes bien sea mediante (CRM) o (RMA) según sea el caso.
2. Se capacitan a los usuarios para gestionar de manera formal el reclamo del cliente y se certifican todos los procesos y resultados.
3. Todo reclamo se registra directamente en la ficha o registro de cliente mediante el registro de la factura de venta y producto vendido. El registro genera tareas mediante registros indicando el departamento y/o personas involucradas. El jefe de reclamos cuando ingresa al sistema es notificado “Automáticamente” de todos los reclamos que debe gestionar con el proveedor. Según sea el caso, registra en la tabla de expediéntenles del proveedor las gestiones que debe realizar para resolver el reclamo del cliente hasta lograr que el producto vendido sea reparado o reemplazado según sea el caso.
4. La gerencia podrá conocer de manera proactiva: La cantidad de reclamos, reclamos en desarrollo, reclamos resueltos antes de la fecha pautada, los reclamos resueltos luego de la fecha pautada, logrando así conocer los niveles de eficiencia en cada departamento o trabajador (Usuario).
5. Quedan registrados en la base de datos todos los procedimientos realizando por la empresa vendedores de las actividades o gestiones para lograr la satisfacción del cliente.
6. Si el personal que gestiona las actividades de gestión del cliente decide no trabajar más en la tienda o vendedor, los propietarios puedes asignar las tareas al personal que lo reemplaza.
7. En caso que el comprador acuda a instancias legales, el vendedor cuenta con argumentos de gestión utilizando para resolver en feliz términos el reclamo solicitado por el comprador.

[thefull]

Buenas

Ideas.

Hablando a nivel técnico, no de negocio.

Hoy en dia, teniendo Harbour la posiblidad de compilar codigo, más que Script, se podría hacer que cada llamada haga un hbmk2 del prg, para generar un hrb,si se ha producido un cambio, y este
sea cargado en memoria. El ERP debería tener harbour en una carperta para esta tarea.
Esto nos da la misma flexibilidad que el Script, pero MUCHO más rápido en su ejecución.

Como a mi me gusta mostrar las palabras en codigo, este es un fichero de parches que he diseñado como prueba de concepto, teniendo ya el HRB compilado ;

Code: Select all  Expand view  RUN

   STATIC s_parches_off   // patches que NO queremos que se carguen
   STATIC s_parches_on    // patches que se cargan desde \PATCH\

   MEMVAR P__pointer_patch

Function Main()
   // No se si es por Harbour o no, pero la visibilidad de la variable afecta al modulo donde se ejecuta.
   // Por lo tanto, declarandola PUBLIC, la visibilidad del HRB es global a la aplicacion
   PUBLIC P__pointer_patch := {=>}  // Punteros a HRB
   HSETCASEMATCH( P__pointer_patch, .F. )

   set_parches_off()  // Informa que parches no queremos que se carguen en el sistema
   load_Patch()        // Carga todos los parches de la ruta PATCH

Return nil

 function Load_Patch( cRuta )
     Local cPath_Patch
     Local   cDirectory_patch  := "PATCH"
     Local aPatchs
     Local cCurPath, aFile
     Local l, p

     s_parches_on := {}
     hb_default( @cRuta, hb_CurDrive() + hb_osDriveSeparator() + hb_ps() + CurDir() + "\" )

     cPath_Patch:= cRuta + cDirectory_patch +"\"
     aPatchs := Directory(  cPath_Patch + "*.hrb")

   for each aFile in aPatchs
        lHacer := .T.
        aeval( s_parches_off ,{|x| if( UPPER( x ) == UPPER( aFile[1] ), lHacer := .F. ,  ) } )
        if lHacer
            P__pointer_patch[ aFile[1] ] := hb_hrbLoad(  HB_HRB_BIND_OVERLOAD , cPath_Patch + aFile[1] )
            // ?  "Cargando..." + aFile[1]
            AADD( s_parches_on, {aFile[1]} )
        endif  
   next  

return nil

// Determina que los ficheros PARCHE1.HRB y PARCHE2.HRB no se van a cargar en el sistema
// Esto puede ser, porque la nueva versión del EXE, ya tiene corregido esa funcionalidad, y no es necesario cargarlo.
function set_parches_off()
return s_parches_off := { "PARCHE1.HRB", "PARCHE2.HRB }

 

¿ Crees que esta es una solución plausible para el sistema ERP?

Saludos

[jnavas]

Thefull
Gracias por tu respuesta.

Actualmente harbour tiene funcionalidad de compilar y ejecutar un programa PRG en un modulo HRB gracias a que el compildor forma parte del binario final. Ya no es necesario crear modulos HRB desde ejecuciones externas.

Nuestra aplicacion fue creada hace 10 años y para ese entonces no estaba el compilador incluido en el binario final. Actualmente estamos recompilando nuestras aplicaciones con todas las mejoras de FiveWin y los avances de Harbour. El uso de scripts ya no es necesario gracias a las funcionalidades incluidas en harbour.

[jnavas]

The full
de errata:
Gracias por tu respuesta
por
Gracias por pregunta, cualquier duda estamos atentos.

[jnavas]

Thefull
Interesante el codigo fuente que has publicado.

te explico nuestra experiencia sobre el ERP.

El codigo fuente para los ERP estan enfocados en aspectos financieros del negocio, las miles de implementaciones que hemos realizado se basan en adaptar procesos del negocio y para facilitar el trabajo de los desarrolladores hemos creados diversas clases :

1. Formularios con methods combinados con programas (UDF) predefinidas : LOAD, SAVE, AFTERSAVE, POSTSAVE, AFTERDELETE, POSTDELETE..No requiere el uso e recursos y el usuario puede personalizar ubicacion fuente y colores de cada control.
2. Generador de codigo fuente para formularios y reportes partiendo de una tabla con sus vinculos (Mediante diccionario de datos)
3. Documento con Grids (Mediante Xbrowse.
4. Las implementaciones con elementos tecnicos han sido con impresoras fiscales y algunas funciones (UDF) que desea implementar el integrador.
5. En nuestro ERP no utilizamos variables estaticas, contamos con una objeto unico de variable publica que contiene todas las variables unicas del sistema y se peuden agregar mas classdata de manera dinámica. Si las nuevas funcionalidades de harbour nos permiten utilizar variables estaticas en un programa HRB y la circunstancia los amerita sera implementada.
6. Desarrollar en un modelo ERP requiere seguir reglas de desarrollo.

[jnavas]

Thefull
Aprovechando tu pregunta y codigo publicado, te explico:

1. Un ERP no debe pretender ser una ambiente unico de desarrollo para un cliente. Su concepto o arquitectura debe permitir agregar nuevas opciones y/o funcionalidades. como por ejemplo: Ejecutar un programa binario externo o llamar a un enlace de un sitio Web.
2. Los procesos abiertos o (Programas fuentes del ERP) estan enfocados en los procesos financieros principalmente.
3. Si el integrador que desarrolla la implementacion requiere hacer algunos programas binarios en cualquier herramienta de desarrollo es totalmente valida, dede cumplir con la flexibilidad del diccionario de datos y utilizar la misma base de datos. Mi recomendacion es contratar con el cliente la entrega de los programas fuentes y formalizar su mantenimiento para los casos de futuras versiones o en caso se concluya la relacion comercial el cliente pueda optar por opciones de continuidad.