Painel de líderes

Foi criado novo recurso para atender a diversidade de fuso horário, em certas regiões do Brasil, a qual o Windows não conseguia administrar a mudança correta do horário de verão, nesses casos poderá ser parametrizado agora direto no seu sistema, resolvendo assim problemas de emissão de DFe, o qual o problema impedia a transmissão do mesmo. 1) tzSistema: O componente pegará o fuso horário do windows (que era o padrão do Trunk2); 2) tzPCN: O componente calculará automaticamente o fuso horário (que era o padrão do Trunk1); 3) tzManual: O componente pegará o fuso horário indicado em TimeZoneStr; 4) O default será tzSistema; 5) preenchimento do TimeZoneStr (Ex.: "-03:00")

Apliquei as seguintes modificações no SVN -- pcnAuxiliar -- (por: DSA) [+] Adicionado novo Tipo: TTimeZoneModoDeteccao = (tzSistema, tzPCN, tzManual); [+] Adicionada novca classe: "TTimeZoneConf" com as propriedades published: ModoDeteccao: TTimeZoneModoDeteccao TimeZoneStr: String [*] Removida a sobrecarga do método: "GetUTC" [+] Adicionado o método: "GetUTCSistema", que utiliza a rotina de synautil para detectar o TimeZone do Sistema Operacional [+] Adicionada uma variável global "TimeZoneConf: TTimeZoneConf", para permitir configurar a maneira que o método "GetUTC", irá se comportar de acordo com as propriedades de TTimeZoneConf -- ACBrDFeConfiguracoes -- [+] Adicionado a propriedade: TimeZoneConf: TTimeZoneConf em TWebServicesConf, para permitit configurar como o métoto pcnAuxiliar.GetUTC se comportará, na detecção do TimeZone (leia mais em: PCNComum-change-log.txt) -- pcnCCeNFe, pcnEnvEventoNFe, pcnNFeW, pcnProcNFe -- [*] Ajuste para usar nova versão de pcnAuxiliar.GetUTC (por: DSA) -- ACBrNFE, ACBrNFeNotasFiscais -- [*] Ajuste para propagar valores de ACBrNFE.Configuracoes.WebServices.TimeZoneConf para pcnAuxiliar.TimeZoneConf (por: DSA)

Já está finalizado o componente? acho que não ainda então toda a ajuda é bem vinda a começar por criar os pacotes para lazarus! basta adicionar aqui que subimos mas lembre-se ainda está no branches então não está acabado ainda

@Jose Carlos Barbosa, não estou duvidando, mas o que seu amigo deve ter te passado é que não sai os dados do faturamento, mas a banda sai sim Pede a ele, qual versão ele usa, e tb para te mandar um PDF do danfe e verá. O problema @Jose Carlos Barbosa, é que esse tipo de parâmetro se omitir a banda toda, irá gerar transtorno, pelo seguinte ex: Não existe parâmetro via comando para que vc habilite ou desabilite a omissão da banda, dai se for um DANFE que tiver faturas, seu usuário terá que ir no monitor antes e habilitar, quando ele emitir um que não tem fatura, ele terá que ir novamente no monitor e desabilitar, entendeu ?

As versões são iguais?

A propriedade "Exibir Campo Fatura" inibe os seguintes dados, ela não esconde o quadro todo da Fatura: if fExibeCampoFatura then begin RLLabelNUmero.Caption := ACBrStr( 'NÚMERO' ); RLLabelValor.Caption := ACBrStr( 'VALOR ORIGINAL' ); RLLabelDupl.Caption := ACBrStr( 'VALOR DESCONTO' ); RLLabelLIQ.Caption := ACBrStr( 'VALOR LÍQUIDO' ); // Define a Coluna dos label's RLLabelNUmero.Left := 264; RLLabelValor.Left := 439; RLLabelDupl.Left := 541; RLLabelLIQ.Left := 652; if NaoEstaVazio(FNFe.Cobr.Fat.nFat) then begin with FNFe.Cobr.Fat do begin RlbDadoNumero.caption := nFat; RlbDadoValorOriginal.caption := FormatFloatBr(vOrig,'###,###,###,##0.00'); RlbDadoValorDesconto.caption := FormatFloatBr(vDesc,'###,###,###,##0.00'); RlbDadoValorLiquido.caption := FormatFloatBr(vLiq ,'###,###,###,##0.00'); end; end end;

Achou o problema na segunda mensagem! tu não instalou ou não fez corretamente do Fortes Report Comunitty Edition .. vá ao github.com e baixe de lá

Quanto ao comportamento (perguntas 1, 2, 3 e 4) pelo que entendi dos fontes alterados é isso mesmo que você falou... Quanto à última pergunta: preencha com '-03:00' E obrigado novamente, conforme o mcnonino disse: "Vai ajudar muito".

Daniel, apenas para confirmar se eu entendi corretamente a alteração. 1) tzSistema: O componente pegará o fuso horário do windows (que era o padrão do Trunk2); 2) tzPCN: O componente calculará automaticamente o fuso horário (que era o padrão do Trunk1); 3) tzManual: O componente pegará o fuso horário indicado em TimeZoneStr; 4) O default será tzSistema; 5) Aqui uma dúvida: como preencher o TimeZoneStr? (Ex.: "-3", "-0300" ou "-03:00") E muito obrigado pela alteração. Vai ajudar muito.

Bom dia! acabei de subir uma correção ! na próxima compilação já vai estar certo ! Obrigado por reportar e desculpe o transtorno

Boa noite, Sim, o componente imprimir o DANFE de uma nota Denegada, o que precisa verificar se logo acima do protocolo esta escrito: Protocolo de Denegação em vez de Protocolo de Autorização.

Regys, muito obrigado pela retorno, Deus seja louvado através de sua vida... Muito obrigado Mesmo Daniel respondeu de uma forma direta, obrigado meu amigo...!! Responta que precisava, acabei aqui descobrindo isto na prática, tenho um .exe responsável por códificar / decodificar texto para meu sistema, ao migrar ele para XE "Unicode" usei AnsiString e String... Usando String ao decodificar não voltava para o mesmo texto, alguns caracteres eram perdidos, dai cheguei a conclusão do Daniel, agora ele com sua vasta experiência evidencia o que notei aqui... Muito obrigado a todos, e em parte pressão de vocês me vez evoluir estou satisfeitíssimo com todos os meus projetos na plataforma XE.

Boa tarde! Gostaria de contribuir no desenvolvimento do componente porém também fora do meu horário de trabalho pois aqui também tenho outros desenvolvimentos, porém baixei a branch e não consegui instalar o componente no meu Delphi versão XE5. O ACBR foi instalado com sucesso, porém o pacote do eSocial não consigo, da erro... vou tentar novamente hoje a noite quando estiver em casa pois preciso testar e confirmar até em que ponto está para dar continuidade, pois a empresa que eu trabalho necessita gerar esses arquivos. Gostaria de saber se caso precise de ajuda para concluir a instalação deste componente se posso contar com algum dos desenvolvedores e como fazer ?

É isso mesmo que o Tiago falou, estamos só eu e ele encabeçando o desenvolvimento, e temos as tarefas do dia-a-dia que temos que desenvolver.. assim sempre que da um tempo voltamos ao desenvolvimento do componente... mas fica lento, pq temos prioridades que ficam a frente do desenvolvimento do componente.. Quanto mais gente ajudar é melhor para o progresso do componente.... Como ele falou alem de ter um componente que sera utilizado por mais empresas a parte de atualizações posteriormente ira ficar mto mais fácil... hj ele ja está com boa parte desenvolvida então não precisa começar é so seguir o que ja tem e implementar as regras que ainda faltam... Abraço

Srs., Infelizmente o desenvolvimento do componente do eSocial está devagar, até por que o projeto está mto nebuloso ainda e não se sabe se o prazo vai ser realmente 09/2016(o que na minha opinião e na de muitos desenvolvedores é impossível de acontecer), o projeto está desacreditado e acabamos tendo nossos esforços alocados para atender demandas mais palpáveis e urgentes, por tanto o melhor que pode acontecer para que o ACBreSocial seja finalizado, é termos mais programadores colocando a mão na massa, pois apenas em dois o processo vai ser inevitavelmente lento, isso apenas no delphi, tenho o Lazarus instalado mas não consegui nem parar para fazer o pacote para o mesmo até pq não desenvolvi nada em lazarus até o momento...(alguém familiarizado se habilita?) Entrei na idéia de colaborar com esse componente sabendo 0% de criação de componentes e o aprendizado foi enorme, ou seja não há pq minimizar nossas capacidades todos nós temos condições de contribuir codificando, fica mais uma vez o convite aos colegas que estão nessa "corrida maluca" pra implantar o eSocial em nossos sistemas, que colaborem codificando e implementando aquilo que falta para que possamos ter essa ferramenta útil a nosso favor o quanto antes. Forte Abraço!

Não quiz dizer que tenha sido finalizado... até acho que está no começando e ainda tem muita coisa para começar a andar, já se fala que vai sari a versão 2.2 e por baixo dos bastidores o ambiente de homologação apenas no segundo semestre...

Obrigado @Juliomar Marchetti Alguma previsão? Visto que o suporte ao Delphi 7 está com os dias contatos, ai muitos vão ter que correr para outra alternativa, uma delas o Lazarus...

Em nenhum lugar, pois não foi ainda acabado o projeto! só tem para delphi que está sendo feito

Boa tarde pessoal, Aonde foi colocado o Pacote para instalação do eSocial para o Lazarus? Grato.

Claramente ele não tá usando o mesmo! esse dele é em fast e trabalha direto com a aplicação o seu é em fortes e usa o monitor

Isaque, obrigado, Eu fiz o que a Juliana comentou, realmente tinham me passado errado o digito da agencia, aparentemente deu certo, mas vou baixar a versão nova tambem, assim que o banco me retornar, eu dou um retorno. Obrigado Ivã

Vinicius, Estamos caminhando, mas antes vamos fazer uma pausa para o almoço. Quando eu retornar, vou analisar os aquivos que você anexou. Quero agradece-lo pelos testes e retornos.

A banda não é omitida, ela sempre será impressa independente do parâmetro definido, lei a essa resposta desse link http://www.projetoacbr.com.br/forum/topic/28127-ref-a-proriedade-acbrnfedanferl1exibecampofatura/?do=findComment&comment=185177

Lembrando que essa NFe deve continuar armazenada, e quando for gera-la para o Sped (se for o caso) sua situação deve estar como 04 - NFe, NFC-e ou CT-e denegado

Bom dia, terá que criar sua própria versão, e mantê-la.

O STF suspendeu através de liminar: http://oglobo.globo.com/economia/stf-da-liminar-suspendendo-cobranca-de-icms-no-comercio-eletronico-18695607 A cada dia me surpreendo com nosso governo, além da grande bagunça que é nossa legislação fiscal, e de não terem interesse de "organizar a casa", ainda continuam inventando moda! Como será que vai ficar? Teremos que esperar as cenas do próximo capítulo. Depois da trabalheira danada que tivemos pra colocar isso pra rodar.... Só em nosso Brasil mesmo!!

Pessoal, vamos usar a busca antes de postar algo, já existe até o momento 3 posts sobre isso, vou fechar todo e centralizar no primeiro.

José tem até um tópico sobre isso! e acabei de responder lá

Obrigado pela colaboração! já está no svn

Você deveria mudar o título do tópico para "DIFAL no Comércio Eletrônico suspenso pelo STF". Para as vendas presenciais continua tudo como está. Mas torço para que o próximo capítulo seja suspender completamente esse DIFAL.

O padrão é sempre apresentar a forma de pagamento.( avista , a prazo ou outras ) A propriedade exibicampofatura somente controla os dados de fatura.

Isso é no Delphi, o que o install faz é pegar da variável PATH do windows e sobrepor na IDE do Delphi, se na variável PATH do windows já estiver bagunçado, vem bagunçado para o Delphi, ai sim tem que arrumar na mão.

Use obrigatoriamente "AnsiString", quando estiver manipulando "buffers" ou conteúdo binário (caracteres não legíveis) Por exemplo, no ACBrECF, recebemos muito caracteres de controle do protocolo (ETX, STX, NUL)... Nesse caso é necessário o AnsiString...

Testa!

Conversamos mais cedo eu e o @jeancantu sobre o método validar, estou trabalhando em outra funcionalidade mas vamos ver essa questão nos namespaces que no caso do eSocial são vários, diferentemente da nfe ou do cte por exemplo, obrigado por reportar @GuilhermeCosta

Bom dia! Pessoal, com relação a validação dos xmls, ocorre um erro ao validar os esquemas no methodo "TDFeCapicom.Validar" dentro do ACBrDFeCapicom.pas, ao chamar a função "Schema.add(FpDFeSSL.NameSpaceURI, ArqSchema);", o erro ocorre devido o atributo "NameSpaceURI" estar vazio. Seguindo o exemplo de como é feito no CTe, deveria ser criada uma constante no "ACBreSocial.pas" como o caminho do namespace para validação dos XMLs, e o methodo "GetNameSpaceURI". Porém, no eSocial, existe um namespace para cada evento. Alguma ideia de como proceder para validação, pensei em passar o namespace de cada evento no methodo "GerarCabecalho", mas não sei se seria uma boa pratica. Obrigado.

Existe um componente em fase de desenvolvimento o que já temos são as rotinas para geração, assinatura e validação dos xmls dos eventos do esocial, vc baixa no svn do ACBr mas ao invés de baixar da pasta trunk2 vc muda por branches, qualquer dúvida estou a disposição.

Boa tarde! Por acaso temos alguma novidade quanto ao eSocial ? Trabalho em uma empresa de desenvolvimento de software exclusivo para RH do setor público situada em Ribeirão Preto, porém temos uma ferramenta de desenvolvimento própria que foi feita em Delphi e gostaria de sugerir a utilização do componente dentro da nossa ferramenta de desenvolvimento. Já existe componente, consigo gerar algum xml de exemplo já em Delphi mesmo e assinar para que possa demonstrar aqui na empresa? Tenho o interesse em desenvolver um monitor em Delphi caso já tenha algo do componente pronto! Aguardo contato email/hangout [email protected]

Natanael até o momento não há novidade, tive que desviar do eSocial para atender uma demanda aqui da empresa onde trabalho, talvez o @jeancantu tenha algo a nos dizer

Bom dia @Tiago Ravache, Alguma novidade sobre a situação que levantei sobre a Chave de Acesso?

Beleza! Agora vamos ver o que pessoal sugere quanto ao método para gerar a chave do eSocial

sim, 100%

Foi o que imaginei compilou o exemplo agora?

Bom vamos analisar com o pessoal essa parte da geração da chave e em que momento é melhor fazermos isso... sobre a compilação do exemplo tu me consegue um print?

@Tiago Ravache, longe de mim ter que gerar no eSocial o xml antes de enviar para o componente, só preciso de uma entrada da chave na mão de forma que o componente não mude o que gerei pelo sistema ao alimentar minha tabela. Quero ser mais prático quanto a esta situação.

Bom passa bem detalhado o erro, por favor pode ser um print...como não consegui reproduzir o erro fica dificil definir o que seja... sobre o gerar chave criamos o método e incluímos ali para teste a idéia é que funcione como funciona hoje na NFe... mas ainda não está implementado igual...

Eu inclui, mas no diretório não consta os programas relacionados.

É usado essa unit 'OpenSSLExt.pas' apenas no Lazarus, ou seja, Para o delphi 2006 ou 7 você precisa comentar essa unit pra compilar. Aparecerá outro erro na sequencia na Unit ACBrDFeOpenSSL.pas: Linha 107/onde se lê : {$IFDEF USE_libeay32}libeay32 {$ELSE}OpenSSLExt{$ENDIF}; faça: {$DEFINE USE_libeay32}libeay32; Creio que faltou um tratamento(Diretiva de Compilação) no ACBR para evitar isso. Espero ter ajudado!

Eu entendo pouco sobre SAT, mas se o número for randômico mesmo então ele não pode ter a limitação de ser único...