Mostrando entradas con la etiqueta saleslogix. Mostrar todas las entradas
Mostrando entradas con la etiqueta saleslogix. Mostrar todas las entradas

jueves, 27 de noviembre de 2014

Send 2 SLX en Thunderbird, desde Linux!

Siempre he sentido que para Linux hay muy poco soporte con SalesLogix, por lo que decidí crear mi propia funcionalidad de "Send2SLX" para Thunderbird.

Para usar este "Add-on" es necesario tener el portal de SData funcionando.

Aquí hay un video de cómo funciona y cómo se configura:


Este es el "Add-on" si lo desean probar:  ThunderBAR v1.0.0 by Scorpile

lunes, 10 de marzo de 2014

Auto cerrar el cliente de SalesLogix en inactividad (auto logoff auto logout)

Muchas veces en las implementaciones es necesario incorporar una funcionalidad para "auto cerrar" el cliente de SalesLogix cuando el usuario deja de utilizarlo.

En vista de que el cliente no trae esta funcionalidad directamente de la caja, aquí les traigo un programita en NET que se encarga de hacerlo.  Si analizan el código verán que esto aplica para cualquier aplicación, no únicamente SalesLogix, y si lo modifican un poco, pueden hacer "logoff" de la sesión del usuario en lugar de "matar" el EXE... todo depende de ustedes.

Les voy a mostrar puntualmente como monitorear y automatizar el cierre, pero cómo ejecutan el monitor cuando SalesLogix se abre se los dejo a su criterio.  Además, les estoy compartiendo el prototipo inicial aunque 100% funcional, así que no hay comentarios y parte del código puede no verse tan "lindo", por favor no critiquen!

Para esto utilicé Visual Basic NET 2010.  No recuerdo si tuve que añadir una referencia a Microsoft.VisualBasic.Compatibility.dll pero el código funciona perfectamente bien sin modificarle nada!

Primero, creamos un formulario en nuestra aplicación y le insertamos un ListBox que se llamará "List1".  Le agregamos un timer "Timer1" con intervalo de 50, y un "Timer2" con intervalo de 1000.

Luego en el código del formulario pegamos lo siguiente:

Option Strict Off
Option Explicit On
Imports VB = Microsoft.VisualBasic

Friend Class Form1
    Inherits System.Windows.Forms.Form
    Private Declare Function GetAsyncKeyState Lib "user32" (ByVal vKey As Integer) As Short
    Dim timeout As Short
    Dim start As Short
    Dim hwnd As Integer = 0

    Private Sub Form1_Activated(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Activated
        Me.Hide()
    End Sub 
   
    Private Sub Form1_Load(ByVal eventSender As System.Object, ByVal eventArgs As System.EventArgs) Handles MyBase.Load
        On Error GoTo Err
        start = 0
        Me.ShowInTaskbar = False
        timeout = CDbl(VB.Command()) * 60
        Exit Sub
err:
        timeout = 300
    End Sub

    Private Sub Timer1_Tick(ByVal eventSender As System.Object, ByVal eventArgs As System.EventArgs) Handles Timer1.Tick
        Dim i As Object
        Dim lngBufferLen As Integer
        Dim strClassName As String
        Dim lngResult As Integer

        For i = 0 To 255
        If GetAsyncKeyState(i) Then              
            End If
        Next i
        Dim auxhwnd As Integer = GetForegroundWindow()
        lngBufferLen = GetWindowTextLength(auxhwnd) + 1
        strClassName = Space(lngBufferLen)
        lngResult = GetWindowText(auxhwnd, strClassName, lngBufferLen)
        strClassName = VB.Left(strClassName, lngBufferLen - 1)
       
        If InStr(1, strClassName, "Sage SalesLogix") > 0 Then
            hwnd = auxhwnd
            For i = 0 To 255
                If GetAsyncKeyState(i) Then
                    List1.Items.Add("Tecla o Mouse - " & strClassName & " Handle: " & auxhwnd.ToString)
                    start = 0
                End If
            Next i
        End If
    End Sub
   
    Private Sub Timer2_Tick(ByVal eventSender As System.Object, ByVal eventArgs As System.EventArgs) Handles Timer2.Tick
        On Error GoTo salida
        start = start + 1
        If start = timeout Then
            If hwnd <> 0 Then
                Dim pid As Integer
                GetWindowThreadProcessId(hwnd, pid)
                Dim xproc As Process = Process.GetProcessById(pid)
                xproc.Kill()
                MsgBox("Se ha cerrado el SalesLogix porque ha llegado al tiempo límite de inactividad!", vbInformation, "Inactividad Detectada")
            End If
            End
        End If
        Exit Sub
salida:
    End Sub

End Class


Ahora, creamos un módulo que yo llamé "Module1" y le pegamos lo siguiente:

Option Strict Off
Option Explicit On
Module Module1
    Public Declare Function GetForegroundWindow Lib "user32" () As Integer
    Public Declare Function GetWindowTextLength Lib "user32"  Alias "GetWindowTextLengthA"(ByVal hwnd As Integer) As Integer
    Public Declare Function GetWindowText Lib "user32"  Alias "GetWindowTextA"(ByVal hwnd As Integer, ByVal lpString As String, ByVal cch As Integer) As Integer
    Public Declare Function GetWindowThreadProcessId Lib "user32.dll" (ByVal hwnd As IntPtr, ByRef lpdwProcessID As Integer) As Integer

End Module

Listo! Prueben abriendo un SalesLogix, luego ejecuten el programa.  Si vieron el Form Load, notarán que si al ejecutarlo lo hacen con un número, estarán estableciendo el tiempo en minutos del "time out" que cierra el SalesLogix.  Si no lo establecen, se va por default a 5 minutos.

Si hacen clic con el ratón, o presionan alguna tecla, verán en el ListBox como va registrando la actividad, y luego del tiempo establecido de no usarlo, pues lo cerrará.

El truco con el programita, es que SalesLogix debe estar "en foco" en algún momento mientras se monitorea para que se pueda recoger el "hwnd" del EXE, pero les digo que desde que lo uso, nunca nadie ha reportado que el SalesLogix se ha mantenido abierto luego de la cantidad de minutos establecida.

Si esta entrada te sirvió, porfa, haz clic a algún anuncio y míralo un par de segundos... ;)

lunes, 28 de octubre de 2013

Importar data a SalesLogix sin Scribe ni Inaport - Herramienta gratis

Siempre se dice que es necesario importar la data utilizando las claves que maneja SalesLogix, y ciértamente, aunque funciona insertar un valor numérico convertido a cadena, la verdad que se ve muy poco profesional trabajar de esta manera.

Se me ha dado un par de ocasiones, que en la implementación es necesario cargar maestros de datos con gran número de registros (10,000 ó +) que me han pasado en un Excel y por alguna razón, no he tenido disponibilidad de usar ni Scribe ni Inaport.

Para fines educativos, he creado una herramienta que permite generar un número determinado de registros, y luego por "query" de base de datos, he realizado los "updates".

Para descargar la herramienta lo puedes hacer de GitHub https://github.com/scorpile/Development donde también encontrarás el código fuente.  Eso si! Es una herramienta que hice muy rápido y no hice el "error handling" así que no critquen!

Primero necesitamos importar todos los registros que deseemos cargar del Excel a SQL u Oracle.  Yo lo he conseguido creando la tabla auxiliar (a la que llamaré TEST) y colocando los campos que corresponden a las columnas en el Excel.  Luego he creado una fórmula en Excel para crear una sentencia p.ej: "INSERT INTO TEST (ACCOUNT,CONTACT,EMAIL,MAINPHONE) VALUES ('VALOR','VALOR','VALOR','VALOR')" y he concatenado las columnas para que se registren los valores.  Propagando la fórmula hasta abajo, he logrado conseguir insertar todos mis valores.



Luego abrimos la herramienta:


Llenamos los datos del Servidor (ya se que dice Serevidor, fue un "typo" y ya les dije que fue algo rápido).  Este es el de SLX y no el de BD.  Igual el conector y el pass del usuario Admin.

Colocamos la tabla que en este caso utilizaré Account, utilizaré el campo USERFIELD1 para enlazar, y en este caso es necesario marcar el checkbox "Utilizar" del SECCODEID ya que la tabla Account tiene habilitada la seguridad.  Colocamos una cantidad N de registros a insertar.

Al final, presionamos el botón "Realizar la Inserción" y el programa se conectará a SalesLogix e insertará la cantidad especificada de registros en la tabla especificada, y en el campo de enlace, colocará valores como "SLXKey1, SLXKey2, SLXKey3 ... SLXKeyN".

Por último, realizamos el update con el siguiente "query":

UPDATE SYSDBA.ACCOUNT SET SYSDBA.ACCOUNT.ACCOUNT = AUX.ACCOUNT FROM
(
SELECT 'SlxKey' + CAST (ROW_NUMBER () OVER (ORDER BY CAMPO) + 3 AS varchar) AS ID,ACCOUNT FROM SYSDBA.TEST
) AS AUX WHERE SYSDBA.ACCOUNT.USERFIELD1 = AUX.ID


Mucho cuidado!  Como pueden apreciar, estamos actualizando el valor de Account.Account con el valor del campo Valor en la tabla auxiliar "Test".  Obvio los demás campos los ponemos en el mismo update.

Si no se tiene cuidado con lo que se está haciendo, en lugar de una ayuda lo que vamos es a destruir nuestra tabla.

Lo que deben tener cuidado es con valores en los campos que ya contengan la comilla simple " ' " en cuyo caso, desde el Excel las reemplazarían por doble comilla simple (2 veces ' ).

miércoles, 11 de julio de 2012

Manipular campos por su nombre (por programación)

Esto que voy a escribir no sólo aplica a SalesLogix, sino a cualquier programación que estén haciendo en C#, o en cualquier otro lenguaje NET si prestan suficiente atención.

Un usuario me dió la tarea de crear un formulario con 50 preguntas parametrizables, cuya respuesta debería poderse escribir mediante un TextBox, o mediante un PickList (equivalente del dropdown en SalesLogix).

Al final, lo que se quiere lograr, es que en una tabla "Extension" (relación 1 a 1 con la tabla principal) hayan 50 campos con las preguntas y las respuestas así:  Campo "Preg1" - Valor "Es casado/a?: Si".

Poner los campos en el AppArchitect es súmamente sencillo, para hacerlo, coloqué un Label con nombre L, junto le puse un TextBox con nombre T, y junto le puse un Picklist con nombre P.  Para efectos de velocidad, los puse dentro de un "Control Container" (esto es sólo en SalesLogix).  Luego sólo fue necesario darle copiar al control container e ir pegando los 49 restantes (obviamente ya había creado las celdas).

El SalesLogix lo que hará es pegar los controles y cada vez que los pegas, le suma 1 al Id de cada control, es decir, la primera vez que pegué, el Label le puso L2, al TextBox le puso T2 y al PickList le puso P2.

Muy importante! Al terminar de pegar los controles hay que ir a renombrar los primeros objetos a L1, T1 y P1 respectivamente.

Ok, ahora viene la parte interesante.

Quiero hacer constar, que ninguno de los controles está "Binded" sino que voy a mover todo por programación!

Primero ponemos un botón y en el evento le asignamos el Business Rule "Save".

Generamos y hacemos "deploy to..." del proyecto (para que vaya el código), y buscamos el "SmartPart" con nuestra encuesta y ubicamos el método donde se guarda el formulario.

Copiamos todo lo que está el método y volvemos al AppArchitect, cambiamos que el botón en lugar de hacer "Business Rule" ahora sea un "C# Snippet Action Item" y pegamos lo que copiamos del formulario en el portal que hicimos el deploy.

Al código, justo antes de donde está " _entity.Save(); " hay que agregar lo siguiente:

for (int i = 1; i<=50; i++)
{
Label lctn = (Label)this.FindControl("L" + i.ToString());
TextBox tctn = (TextBox)this.FindControl("T" + i.ToString());
Sage.SalesLogix.Web.Controls.PickList.PickListControl pctn = (Sage.SalesLogix.Web.Controls.PickList.PickListControl)this.FindControl("P" + i.ToString());

_entity.ExtensionEntity_ReqInfo["Preg" + i.ToString()]=lctn.Text + ": " + tctn.Text + pctn.PickListValue;
}

Como pueden observar, la referencia a mi tabla actual se llama " _entity ", y tiene una tabla extensión que se llama " ExtensionEntity_ReqInfo " con los 50 campos que se llaman "Preg1, Preg2...Preg50".

Las 3 primeras líneas son para obtener los controles en cuestión.  La línea final es para llenar la tabla en cada campo "Preg1...Preg50" con la concatenación de [Pregunta] + ": " + [Respuesta].

Ahora agreguemos un evento al "Load" del formulario que también será "C# Snippet Action Item" y al crearlo, asegurémonos de poner en True la opción para que el método sea llamado cada vez que se repinta el formulario.

En el código coloquen lo siguiente:

string WfRelId = DialogService.DialogParameters["WfRelId"].ToString();
Sage.Entity.Interfaces.IC_Preguntas pregs = Sage.Platform.EntityFactory.GetById<Sage.Entity.Interfaces.IC_Preguntas>(WfRelId);


for (int i = 1; i<=50; i++)
{
Label lctn = (Label)this.FindControl("L" + i.ToString());
TextBox tctn = (TextBox)this.FindControl("T" + i.ToString());
Sage.SalesLogix.Web.Controls.PickList.PickListControl pctn = (Sage.SalesLogix.Web.Controls.PickList.PickListControl)this.FindControl("P" + i.ToString());
string qeRI = (string)pregs["Question" + i.ToString()];
string prRI = (string)_entity.ExtensionEntity_TicketReqInfo["Preg" + i.ToString()];
lctn.Text = qeRI;
if (lctn.Text != "") { if ((string)pregs["ControlType" + i.ToString()] == "TextBox") { tctn.Visible = true; tctn.Text = prRI.Replace(qeRI + ": ",""); }

else
{ pctn.Visible = true; pctn.PickListName=(string)pregs["PicklistRespName" + i.ToString()]; pctn.PickListValue = prRI.Replace(qeRI + ": ",""); }   }
}


Las 2 primeras líneas son, 1, para obtener un parámetro con el ID de registro que corresponde a las preguntas que queremos hacer, y 2, para obtener el registro con las 50 preguntas, las 50 especificaciones de si es TextBox o PickList, y los 50 posibles nombres de PickList.

Esa tabla llamada C_Preguntas, tiene 4 campos que son el ID, 50 columnas de pregunta "Question1...Question50", 50 columnas de tipo "ControlType1...ControlType50" y 50 columnas para establecer el nombre del picklist "PicklistRespName1...PicklistRespName50".

Las preguntas van callendo en la línea con la variable " qeRI " y las respuestas en la siguiente en la variable " prRI ".  Pero ojo, al guardar, dijimos que la respuesta se guardaba como [Pregunta] + ": " + [Respuesta].  Por eso hay unos Replace en la sentencia siguiente.

En el IF, vemos que dependiendo del "ControlType", si es TextBox, mostramos el campo TextBox correspondiente con su respuesta, y si no, el PickList con el valor seleccionado.

Ya con esto, manipulamos por programación y sin mucho esfuerzo, los 50 campos del formulario.

martes, 24 de enero de 2012

Fuentes más pequeñas en diálog Area-Category-Issue (SLX7.5.3 Web)

Este es un problema más que nada estético.

Resulta que las fuentes del control Area-Category-Issue son muy grandes y a veces se hace dificil seleccionar la opción adecuada.

Hasta que Sage no incorpore una propiedad para establecer el ancho de los "dependant" lookups estamos lmitados a por lo menos hacer más pequeñas las letras.

Para esto, buscamos en la carpeta "css" el archivo que se llama sage-styles.css y agregamos el siguiente estilo:

.formtable .yui-panel .hd select
{
    font-size: 80%;
}

Con esto haremos las letras más chicas y nos dará un pequeño espacio adicional para leer las opciones:





En este caso era para Area-Category-Issue, pero la verdad el cambio funciona para cualquier lookup dependiente.

Actualización:  Existe un post en CustomerFX de un conocido programador.  El enlace es http://customerfx.com/pages/integrationblog/2012/07/27/expanding-the-area-category-issue-picklist-popup-screen-in-the-saleslogix-web-client.aspx y en el mismo explica cómo modificar unos archivos "js" (javascript) internos del SalesLogix los cuales permiten ampliar este dependent lookup.

Actualización 2:  Utilizando CSS encontré un método mucho mejor, como mil veces más sencillo y aplica para cualquier campo que necesiten ampliar.  El post lo puse en:  http://www.slxdeveloper.com/forum.aspx?forumid=4002&postid=32203

Expandir los nombres de los reportes (SLX 7.5.3 Web)

Constantemente los clientes se quejan de que el espacio donde se ven los reportes es muy reducido, y el nombre de la mayoría siempre queda truncado por el tamaño del control.

Para solucionarlo, deben buscar el smartpart que se llama Reporting.ascx y buscar la línea que tiene el control de selección de reportes.  Pueden hacer una búsqueda de:  select name="reportname"

Seguidamente vamos a modificar el DIV que está al inicio, y le vamos a colocar 500 pixeles de ancho en el atributo STYLE.  También vamos a agregar el atributo STYLE al "select control" y le pondremos de ancho un 100%.  La línea completa debería quedar así:

<div style="width:500px"><select name="reportname" id="reportname" onchange="reportNameChanged()" size="12" style="width:100%"></select></div>

Puse en negrita lo que deben agregar.

Al visualizar el listado de reportes se debería ver así:


Mucho mejor para los usuarios que el pequeño espacio que trae por defecto!

lunes, 23 de enero de 2012

Mostrar formularios del DialogWorkSpace en un Sales Process (SLX7.5.3)

Muchos de ustedes habrán notado que no es posible mostrar formularios en los Sales Processes web.

Recientemente tuve la necesidad de revisar esto por un flujo muy interesante de un cliente, así que les traigo la solución, un poco "dirty" como dirían, pero totalmente funcional.

Paso 1 - Procesando los "Form" en los Sales Process:

Busquen dentro de la carpeta SmartParts, la carpeta OpportunitySalesProcess.  Dentro abran para editar en notepad el archivo que se llama OpportunitySalesProcess_ClientScript.js y realicen una búsqueda de la función executeAction.  Allí podrán ver que la opción case 'Form' no hace absolútamente nada, así que deberán cambiarla de la siguiente manera:

        case 'Form':
            ProcessAction.prototype.Init = Init_Form;
            boolExecute = true;
            break;


Paso 2 - Creando la función para mostrar el diálogo:

Ok, ahora vamos a crear la función que nos permitirá mostrar nuestro diálogo.  Busquemos un espacio para escribir nuestra función y escriban lo siguiente:

function Init_Form() {
    var xmlDoc = sp_GetXmlDoc(this.xml);
    var objFrm = xmlDoc.getElementsByTagName('FormAction');
    var strFormName = objFrm[0].getElementsByTagName('LanForm')[0].getElementsByTagName('Name')[0].firstChild.nodeValue;
    DialogWorkspace.show(strFormName,'800','800','800','800');
    this.Finish();
    return false;
}

Ven los 800?  Lastimósamente no he logrado que el formulario sea de más de 500x500 y que esté en otro lugar que no sea X=0 Y=0, pero como es funcional, no me molesta tanto.  Vieron también que dice LanForm?  Déjenlo así, ya verán por qué.

Paso 3 - Creando el formulario... perdón, los!

Esto es lo único que puede parecer trillado.  Hay que crear el formulario en LAN y en WEB, es decir, en Architect y en Application Architect.  Por qué? porque el campo para poner el Web Form en el Sales Process utiliza los formularios que se hagan desde el WebAdmin, y no vamos a regresar a 7.0 con su programación horrible...  queremos un formulario de 7.5.3.

Como la función que hice no pasa parámetros (si encuentran la manera correcta de hacerlo les ruego que me avisen) el formulario que van a abrir recibirá el ID de la oportunidad, así que es mejor que vayamos a la entidad Opportunity para crear el formulario y de allí ya depende de su ingenio para darle funcionalidad.

Yo le voy a llamar dlgTestDrive:


Recuerden crear en el Architect un formulario que se llame igual, aunque esté vacío!



Paso 4 - Incorporando el formulario al Sales Process:

Ahora creamos un Sales Process y en algún punto, seleccionamos acción Form, y buscamos nuestro formulario:

Ahora falta únicamente probarlo, para ellos abrimos un SalesLogix desde Web, buscamos alguna oportunidad, le ponemos el Sales Process y buscamos el paso con el form.  Le damos clic a la descripción y:

Excelente!

miércoles, 18 de enero de 2012

Problemas con los campos moneda en SalesLogix Web 7.5.3

Por alguna razón, los campos tipo moneda (Currency) fallan cuando se utilizan navegadores con localizaciones en lugares fuera de "en-US", como en mi caso que es "es-PA" porque estoy en Panamá.

El problema que se presenta es que o bien sale un mensaje que dice "input string not in correct format" que impide marcar el botón para guardar, o al guardar el número, por ejemplo "3.99", el maldito se guarda como "399000" y si seguimos presionando guardar el número se va multiplicando por 1000...  súmamente molesto...

Afortunadamente he encontrado una manera de lidiar con los campos moneda y consiste en cambiar los campos tipo moneda a tipo número (Numeric).

Esto depende en gran medida de la implementación, si se van a utilizar todas las pantallas con campos tipo moneda o solo algunos.  En todo caso, si se va a realizar input a estos campos, cambiarlos a tipo número me ha dado muy buenos resultados.

Algo importante es que al cambiar los campos a tipo número, hay que colocarles el formato que queremos.  En Panamá, el formato sería {0:#,##0.00} lo cual nos presentaría 3211.3 como 3,211.30.

Si estamos en un formulario nativo del Application Architect, hay una propiedad de todos los campos en los formularios que se llama Data Bindings.  Dentro se "bindea" el campo a un atributo en la base de datos, y bajo el campo llamado "Binding" hay uno que dice Format String, que sería el lugar para colocar el formato que mostré.

Si es un formulario custom, y se están usando los WebEntityBindings, se colocaría el formato así:

WebEnityBinding miControl = new WebEntityBinding("CampoEnBD", "Text", "{0:#,##0.00}", "");

En ambos casos es muy importante setearle la propiedad "Format Type" del campo a "Number" o el formato no funcionará de la manera correcta.

martes, 10 de enero de 2012

El SalesLogix Mobile 2011 R1 desde un BlackBerry OS 5

Esto es una solución simple y sencilla para aquellas personas que están en países donde por algún motivo no es fácil o barato tener un nuevo BlackBerry con OS 6.

Si tienen un Curve u otro modelo de aquellos que sólo soportan BBOS 5, me es grato informarles que podrán utilizar el nuevo portal Mobile de SalesLogix (2011 R1, si, el que es HTML5 y CSS3) simplemente instalando Opera Mini.

viernes, 22 de julio de 2011

Lookup se cambia a Nulo en un DialogWorkspace

En 7.5.3 me vi en una situación donde por código hay que crear un registro en una tabla al presionar un botón, pero hay que seleccionar un valor de una Lookup para crear el registro.

Se decidió crear la funcionalidad en un SmartPart ubicado en el DialogWorkspace, y además que se pudieran establecer condiciones en tiempo real para el filtrado.  Se agregaron 3 checkbox para establecer las condiciones del filtrado por lo que obviamente hay que setear los 3 checkboxes para autopostback, pero al probar la funcionalidad tanto de los 3 checks como del mismo Lookup, el valor devuelto por el Lookup siempre se cambia a nulo luego del postback.

Primero hay que estar seguro que el "Entity" tenga bien mapeado el campo de visualización.  Luego hay que asegurarse que el Lookup esté seteado para binding tipo "String" y no "Object".  Con esto el valor se mantiene pero al traer un elemento del Lookup lo que vendrá es el SLXId del registro.

Agregamos un campo TextBox en el formulario que llamaremos lkID y le ponemos visible = false.  También agregamos un handle al evento LookupResultValueChanged y dentro del procedimiento le asignamos el valor del Lookup así:  this.lkID.Text = this.MyLookup.LookupResultValue.ToString();

Luego agregamos un evento Pre_Render al formulario si no lo tiene ya, y colocamos:

     if (lkID.Text+"$" != "$")
      {
          Sage.Entity.Interfaces.IAccount swssel = Sage.Platform.EntityFactory.GetById<Sage.Entity.Interfaces.IAccount(lkID.Text);
this.MyLookup.Text = swssel.Account;
      }


Oviamente suponiendo que estabamos haciendo un Lookup sobre la entity IAccount.

De esta manera ya tendríamos el SLXId seleccionado en el campo lkID y el texto en la propiedad Text del mismo Lookup.

Luego complemento con lo de los filtros al Lookup en tiempo real porque me han preguntado muchas veces sobre el tema.

martes, 12 de octubre de 2010

Sumar sólo días laborales en C#

Una funcionalidad que he buscado durante mucho tiempo en Internet es cómo hacer un AddDays que agregue sólo los días laborales.

Adicional a esto, la funcionalidad debe ser para C# porque la quiero utilizar en un proyecto WEB en IIS de SalesLogix.  Si alguien conoce una funcionalidad de SalesLogix que lo haga le agradezco me notifique porque no hay documentación de esto.

Al final, si existe o no esta funcionalidad, yo hice mi propia función y aquí les detallo las consideraciones y el código fuente de la función para que puedan adaptarla a sus necesidades.  La función que yo diseñé tenía que cumplir con lo siguiente:

  1. Debe permitir el AddDays sólo de días laborales de lunes a viernes (aquí en Panamá no se trabaja sábados ni domingos en algunas empresas).
  2. Debe contemplarse una tabla de días feriados la cual tendrá una vista de mantenimiento manual.
  3. Sólo se van a agregar días completos, no fracciones de días, y no importa la hora del día en que se haga el AddDays.
Luego de mucho investigar no encontré ninguna función que cumpliera al 100% estos requerimientos, o que funcionara completamente sin errores ni cálculos errados.

Al analizar un poco los códigos encontrados, todos terminaban en 1 bucle para contar los días 1 por 1 como si estuviéramos frente a un calendario.

Las otras funciones que no utilizan el conteo, se basan en cálculos para contar los días, pero todos caen en un mismo error, que consiste en dividir la cantidad de días que queremos sumar entre 7 para saber el número de fines de semana que hay, y agregar este número al número original.

Esto es un completo error, porque están dividiendo días que aún no han transcurrido, por ejemplo, si quiero una actividad que va a durar 6 días, no me está contemplando el fin de semana en el que ya estaríamos cayendo.  Lo correcto, es dividirlo entre 5, que son los días realmente laborales, y al final sumarle los 2, ven?  No es lo mismo sumarle 2 por cada 7, que sumarle 2 por cada 5.  Pero mucho cuidado, esto es considerando que es una suma, si por el contrario quisieran sacar las semanas o el número de días laborales entre 2 fechas (diferencia de días, subtract o datediff), no es la misma situación y entonces si es correcto dividir entre 7, porque las 2 fechas si tienen los 2 días del fin de semana de por medio.

Lo otro es lo de la tabla de feriados.  La mayoría de los códigos verifican esta tabla por cada uno de los días a sumar, esto también me pareció muy ineficiente.

Mi solución es la siguiente:

protected DateTime DateAgregarLaborales(Int32 add, DateTime FechaInicial)
{
    if (FechaInicial.DayOfWeek == DayOfWeek.Saturday) { FechaInicial=FechaInicial.AddDays(2); }
    if (FechaInicial.DayOfWeek == DayOfWeek.Sunday) { FechaInicial=FechaInicial.AddDays(1); }
    Int32 weeks = add / 5;
    add += weeks * 2;
    if (FechaInicial.DayOfWeek > FechaInicial.AddDays(add).DayOfWeek) { add += 2; }
    if (FechaInicial.AddDays(add).DayOfWeek == DayOfWeek.Saturday) { add +=2; }
    Int32 libres =  LibresEntre(FechaInicial,FechaInicial.AddDays(add));

    if (libres>0) { return DateAgregarLaborales(0,FechaInicial.AddDays(libres+
add)); }
    else { return FechaInicial.AddDays(add); }
}

Las primeras 2 líneas verifican si el día en que se está haciendo la suma es sábado o domingo, esto para no contemplarlo porque queremos saltarnos esos días.

Los días se dividen entre 5 y se multiplica el resultado por 2 para sacar los días libres por cada semana.

Se verifica si el día final es menor al día actual lo cual valida sumas de intervalos menores a 5 o que la fecha quede en domingo (es 0 en C#), y si se estima que el día final es sábado, se suman nuevamente 2 días.

Al final se está consultando una función que se llama LibresEntre para consultar a la tabla de feriados y ver si hay días libres entre la fecha inicial y la resultante, y si resulta haber uno o más días libres, se llama recursivamente a la misma función para evitar caer nuevamente en días no laborales.  Esto traerá como resultado que a lo sumo, sólo habrá 1 iteración entre la función inicial y su re-llamada.

Esta es la función para los días libres, que está pensada para MS SQL:

protected Int32 LibresEntre(DateTime Fi, DateTime Ff) 
{
    Sage.Platform.Data.IDataService service = Sage.Platform.Application.ApplicationContext.Current.Services.Get<Sage.Platform.Data.IDataService>();
    System.Data.IDbConnection cnn = service.GetConnection();
    cnn.Open();
    System.Data.IDbCommand cmd = cnn.CreateCommand();
    string sql = "select isnull(sum(case when datepart(dw,fecha_feriado)=1 or datepart(dw,fecha_feriado)=7 then 0 else 1 end),0)";
    sql += " from dias_feriados where fecha_feriado>='" + Fi.ToString("MM/dd/yyyy") + " 00:00:00' and fecha_feriado<='" + Ff.ToString("MM/dd/yyyy") + " 24:00:00'";
    cmd.CommandText = sql;
    System.Data.IDataReader MyDataReader = cmd.ExecuteReader(System.Data.CommandBehavior.CloseConnection);
    Int32 dias  = 0;
    while (MyDataReader.Read())
    {
        dias = MyDataReader.GetInt32(0);
    }
    MyDataReader.Close();
    cnn.Close();
    cmd.Dispose();

    return dias; 
  }

Esta función devuelve los días feriados no sábado y no domingo entre el rango de fechas.

Lo último que deben tomar en cuenta es que cuando hagan su programa, recuerden hacer que FechaInicial =  DateAgregarLaborales(0, DateTime.Now()) para que la fecha inicial también sea considerada.

Por favor, si esta función les ayuda en su trabajo, hagan clic en los Ads que vean. 

lunes, 6 de septiembre de 2010

SalesLogix, dulce, complejo, indispensable...

Esta es la herramienta que ADR Technologies promociona más en el área de centroamérica.

Es un CRM que incorpora muchas ideas novedosas en este tipo de sistemas.

Totalmente configurable y personalizable.

Esta herramienta cuenta con sus propios IDE's, y es en su plataforma Web que quemo mis pestañas constantemente...

Por el momento creo que será el tema principal de mis publicaciones.