Painel de líderes

Bom dia! Durante esse mês notei que em alguns clientes está salvando a data errada, aumentando um dia na data da venda. Isso em vários clientes, seguindo um padrão de dias mas não todos os dias. Imagino que tenha algo com ano bissexto. Com algumas pesquisas, no código do jACBrFramework, na class OleData.java e deixei da seguinte forma. Método setDate(double dtSrc); //<editor-fold defaultstate="collapsed" desc="OleDate Conversion Methods"> @SuppressWarnings("empty-statement") private void setDate(double dtSrc) { // source code copied from MFC 4.21 and modified long nDaysAbsolute; // Number of days since 1/1/0 long nSecsInDay; // Time in seconds since midnight long nMinutesInDay; // Minutes in day long n400Years; // Number of 400 year increments since 1/1/0 long n400Century; // Century within 400 year block (0,1,2 or 3) long n4Years; // Number of 4 year increments since 1/1/0 long n4Day; // Day within 4 year block // (0 is 1/1/yr1, 1460 is 12/31/yr4) long n4Yr; // Year within 4 year block (0,1,2 or 3) boolean bLeap4 = true; // TRUE if 4 year block includes leap year // values in terms of year month date. int tm_sec; int tm_min; int tm_hour; int tm_mday; int tm_mon; int tm_year; double dblDate = dtSrc; // temporary serial date // If a valid date, then this conversion should not overflow // Round to the second dblDate += ((dtSrc > 0.0) ? HALF_SECOND : -HALF_SECOND); // Add days from 1/1/0 to 12/30/1899 nDaysAbsolute = (long) dblDate + 693959L; dblDate = Math.abs(dblDate); nSecsInDay = (long) ((dblDate - Math.floor(dblDate)) * 86400.); // Leap years every 4 yrs except centuries not multiples of 400. n400Years = nDaysAbsolute / 146097L; // Set nDaysAbsolute to day within 400-year block nDaysAbsolute %= 146097L; // -1 because first century has extra day n400Century = (nDaysAbsolute - 1) / 36524L; // Non-leap century if (n400Century != 0) { // Set nDaysAbsolute to day within centurY nDaysAbsolute = (nDaysAbsolute - 1) % 36524L; // +1 because 1st 4 year increment has 1460 days n4Years = (nDaysAbsolute + 1) / 1461L; if (n4Years != 0) { n4Day = (nDaysAbsolute + 1) % 1461L; } else { bLeap4 = false; n4Day = nDaysAbsolute; } } else { // Leap century - not special case! n4Years = nDaysAbsolute / 1461L; n4Day = nDaysAbsolute % 1461L; } if (bLeap4) { // -1 because first year has 366 days n4Yr = (n4Day - 1) / 365; if (n4Yr != 0) { n4Day = (n4Day - 1) % 365; } } else { n4Yr = n4Day / 365; n4Day %= 365; } tm_year = (int) (n400Years * 400 + n400Century * 100 + n4Years * 4 + n4Yr); // Handle leap year: before, on, and after Feb. 29. if (n4Yr == 0 && bLeap4 && n4Day == 59) { /* Feb. 29 */ tm_mon = 2; tm_mday = 29; } else { if (n4Yr == 0 && bLeap4 && n4Day >= 59) { --n4Day; } // Make n4DaY a 1-based day of non-leap year and compute // month/day for everything but Feb. 29. ++n4Day; // Month number always >= n/32, so save some loop time */ for (tm_mon = (int) ((n4Day >> 5) + 1); n4Day > rgMonthDays[tm_mon]; tm_mon++); tm_mday = (int) (n4Day - rgMonthDays[tm_mon - 1]); } if (nSecsInDay == 0) { tm_hour = tm_min = tm_sec = 0; } else { tm_sec = (int) (nSecsInDay % 60L); nMinutesInDay = nSecsInDay / 60L; tm_min = (int) (nMinutesInDay % 60); tm_hour = (int) (nMinutesInDay / 60); } Calendar c = Calendar.getInstance(); c.set(Calendar.YEAR, tm_year); c.set(Calendar.MONTH, tm_mon - 1); c.set(Calendar.DAY_OF_MONTH, tm_mday); c.set(Calendar.HOUR, tm_hour); c.set(Calendar.MINUTE, tm_min); c.set(Calendar.SECOND, tm_sec); setTime(c.getTime().getTime()); // setYear(tm_year - 1900); // setMonth(tm_mon - 1); // super.setDate(tm_mday); // resolves ambiguity // between OleDate.setDate and // java.util.Date.setDate // setHours(tm_hour); // setMinutes(tm_min); // setSeconds(tm_sec); } //</editor-fold> Método toDouble(); public double toDouble() { // source code copied from MFC 4.21 and modified. Calendar c = Calendar.getInstance(); c.setTime(this); int wYear = c.get(Calendar.YEAR); int wMonth = c.get(Calendar.MONTH); int wDay = c.get(Calendar.DAY_OF_MONTH); int wHour = c.get(Calendar.HOUR);; int wMinute = c.get(Calendar.MINUTE);; int wSecond = c.get(Calendar.SECOND);; // Check for leap year and set the number of days in the month boolean bLeapYear = ((wYear & 3) == 0) && ((wYear % 100) != 0 || (wYear % 400) == 0); // Cache the date in days and time in fractional days long nDate; double dblTime; //It is a valid date; make Jan 1, 1AD be 1 nDate = wYear * 365L + wYear / 4 - wYear / 100 + wYear / 400 + rgMonthDays[wMonth - 1] + wDay; // If leap year and it's before March, subtract 1: if (wMonth >= 2 && bLeapYear) { --nDate; } // Offset so that 12/30/1899 is 0 nDate -= 693959L; dblTime = (((long) wHour * 3600L) + // hrs in seconds ((long) wMinute * 60L) + // mins in seconds ((long) wSecond)) / 86400.; double dtDest = (double) nDate + ((nDate >= 0) ? dblTime : -dblTime); return dtDest; } No caso do toDouble foi só removido variáveis sem uso e métodos deprecated No setDate foi removido métodos deprecated e ajustado o increment do dia, esse ajuste eu tirei de "https://github.com/tbrandt77/janrufmonitor/blob/master/modules/outlook/src/de/janrufmonitor/repository/OutlookDate.java" Caso alguém tenha o mesmo problema está ai, ao menos comigo até agora resolveu, qualquer problema que eu tiver, eu posto aqui.

Independentemente da exigência da ACBr, extinguir suporte ao delphi7, obrigatoriamente devemos acompanhar a evolução natural, vendemos serviços precisa ter qualidade, lembro de um cliente um dia disse assim: Olha vi em uma empresa uma tela ..., imediatamente lembrei que no d7, aquilo fica muito dificil complicado. Outro detalhe tive um professor da faculdade que nos dizia "olha procure se atualizar seus serviços, se não vão ter que ir vender apa- relho de rodar fita k7, na frente dos bancos...". Temos o famoso googles.... A primeira coisa a fazer é eliminar trocar ou ver se tem compatibilidade os famosos componentes... Na verdade essas bobas dificuldades irá nos aperfeiçoar, nossos clientes que paga o nosso pão de cada dia, também verá a diferença no resultado final e pagará satisfeito, agente ganha mais respeito, moral, outra coisa programador é programador e se for brasileiro coisa vai ter que andar... Obrigado, Leão

Nota Fiscal de Serviços - Eletrônica Muito complicado ( pra não dizer: Nada Recomendado ) incluir no Monitor, visto que cada Município pode ter suas particularidades e ainda podem mudar os provedores com frequência invalidando o recurso ( e mudam mesmo ) O ideal é que aplicativos destinados a cada município incluam esse recurso internamente ( relativamente fácil ) Sucesso