Painel de líderes

Boa tarde @Renato Rubinho, Atualizei aqui e fiz os testes, todos enviados com sucesso, obrigado. Rubens

Bom dia! Conferindo em Portal da NFe > Consulta Disponibilidade, é possível observar que a Sefaz de Goias está indicando indisponibilidade dos serviços. Consultando no painel Situação SVC, podemos ver que a contingência foi ativada às 11h50 do dia 26/09/2023, com previsão de término às 00h00 do dia 27/09/2023. Para usar o ACBr em contingência durante este período, siga as orientações deste tópico: Um agradecimento ao membro @Felipe Mariano, por chamar atenção ao fato no canal #sefaz em nossa comunidade do Discord.

Olá Pessoal, Gostaríamos de anunciar que a integração do ACBrNFSeX para emissão da NFSe por API está concluída, utilizando todos os recursos existentes na API. Todos os serviços disponibilizados pela API da NFS-e Padrão Nacional foram testados e detalhados a seguir. O Enviar o DPS (Declaração de Prestação de Serviço) esta funcionando, temos como retorno o XML da NFS-e caso os dados estejam tudo OK. O Enviar Eventos (de cancelamento por exemplo) esta funcionando, temos como retorno o XML da efetivação do evento caso os dados do pedido estejam OK. O Consultar DPS por Chave esta funcionando, temos como retorno apenas a chave da NFS-e e mais nada. O Consultar NFS-e por Chave esta funcionando, temos como retorno o XML da NFS-e. O Consultar Evento nos permite realizar essa consulta de 3 formas diferentes: 1. Consultar Evento informando somente a chave da NFS-e esta funcionando, temos como retorno o XML do evento. 2. Consultar Evento informando a chave e o tipo de evento não esta funcionando, esta retornando o erro 404, esse problema já foi relatado a RFB. 3. Consultar Evento informando a chave, o tipo de evento e o numero sequencial esta funcionando, mas a API esta gerando o XML do evento codificado em base 64 duas vezes, esse problema já foi relado a RFB. O Consultar DFe nos permite realizar essa consulta de 2 formas diferentes: 1. Consultar DFe informando o NSU (Numero Sequencial Único) esta funcionando, temos como retorno os XMLs das notas e dos eventos. 2. Consultar DFe informando a chave da nota esta funcionado, temos como retorno o XML da nota e dos eventos vinculados a nota. O Obter o PDF da nota esta funcionando, mas o QR-Code esta incompleto não contem a URL e caso a nota esteja cancelada não aparece a Tarja Cancelado, esse problema já foi relatado a RFB. Uma coisa importante a ser dita é que todos os testes realizados foram feitos em ambiente de produção, pois o ambiente de homologação ainda apresentava alguma erros, como por exemplo: exigir que a cidade esteja conveniada para poder emitir a nota mesmo o contribuinte ser MEI. Vale também informar que tanto a API quanto ao Portal Nacional da NFS-e (para emitir a nota via web) estão com instabilidade gerando erros de timeout por exemplo. Foi detectado também no ambiente de produção que ao tentar consumir qualquer serviço ocorre o erro: network subsystem is unusable, mas ao tentar novamente consumir o serviço desejado funciona. Esse erro só esta ocorrendo em ambiente de produção no de homologação ele não ocorre, portanto é um problema na API de produção, esse problema já foi relatado a RFB. Esse é um resumo dos testes que eu realizei.

Olá pessoal, Lá vamos nós mais uma vez, só que agora é a vez de algumas melhorias no CT-e. E quais são as novidades da versão 4.00 do CT-e? Eliminação do SOAP Header dos Webservices Não precisamos se preocupar pois o componente vai se encarregar de não gerar o grupo <Header> ao montar o Envelope a ser enviado para o WebService da SEFAZ. Eliminação da Denegação e do CTe de Anulação Com essa nova versão não teremos mais como emitir um CT-e de Anulação, somente CT-e Normal, CT-e Complementar e CT-e de Substituição. O Manual não diz o porque, mas acredito que essa alteração vem de encontro com o DC-e (Declaração de Conteúdo Eletrônico). Quanto a Denegação o que tudo indica nenhum CT-e vai ser Denegado, ou seja, ou ele vai ser autorizado ou rejeitado. Eliminação do Serviço de Autorização Assíncrono O envio do CT-e passa a ser no modo síncrono e unitário, ou seja, somente um CT-e por vez será enviado para o WebService e já teremos como resposta o protocolo de autorização ou a rejeição. Ampliação do Nro Seq dos Eventos Antes um tipo de evento que poderia ser enviado mais de uma vez (por exemplo Carta de Correção) estava limitado a 20, agora o limite é 999. Eliminação do serviço de inutilização Com a versão 4.00 não teremos mais como inutilizar um numero de um CT-e que não foi enviado para a SEFAZ, acredito que caso ocorra um pulo, por exemplo, foi enviado o CT-e de numero 500 e por algum problema foi enviado o CT-e de numero 505, vai ser possível em seguida enviar os CT-e de números 501, 502, 503 e 504 para depois voltar a sequencia normal ou seja emitir o CT-e de numero 506 em diante. Sobre os prazos A versão 4.00 vai estar disponível a partir de 04/2023 em ambiente de Homologação e a partir de 06/2023 em Produção. Quanto as Soluções ACBr Haverão ajustes no componente ACBrCTe para atender a versão 4.00, oque naturalmente se refletirá nas versões posteriores da ACBrLibCTe e do ACBrMonitor. Fiquem atentos as atualizações dos fontes do ACBr e não percam o bonde. Quanto a minha Aplicação? Com certeza a sua aplicação deve ter uma opção para emitir CT-e de Anulação e Inutilização de Números, pois bem essas opção não poderão mais poder ser utilizadas com a nova versão. Sugerimos que apresente uma mensagem ao usuário informando que essa opção não esta mais disponível na versão 4.00 do CT-e. Se a sua aplicação permitia o envio de um lote de CT-e, agora só será possível enviar um de cada vez, logo você vai ter que mudar isso. Com certeza a sua aplicação envia eventos, fique atento a esta questão: para os tipos de eventos que permite enviar mais do que 1 para o mesmo CT-e, lembre-se que agora o limite passou de 20 para 999. Leitura recomendada: Temos os manuais (que são 3) da versão 4.00 em nossas biblioteca. http://svn.code.sf.net/p/acbr/code/tools/DFe/CTe/

Bom dia pessoal, tudo bem? Ao imprimir NFS-e no padrão nacional cortava a chave de acesso, só imprimia os 50 primeiros caracteres, ai verifiquei que era na criação do ClientDataSet (na linha 443 do arquivo em anexo), então ajustei conforme o arquivo em anexo, se acaso acharem pertinente subir esse código, em anexo tem o fr3 que estou usando com alguns ajustes também. ATT. ACBrNFSeXDANFSeFR.pas DANFSe_EL.fr3

Sim, podemos alterar no fonte para o windows criar a chave se necessário. Linha 85 do ACBrConsultaCNPJNavegar.pas, alterar para True: Reg.OpenKey('SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BROWSER_EMULATION', True);

se está ocorrendo isso é porque tem alguma informação errada ainda.

Descobri o erro, no Windows server não tem a key FEATURE_BROWSER_EMULATION, portanto foi só criar ela usando o CreateKey Reg.OpenKey('SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BROWSER_EMULATION', False); Reg.CreateKey('SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BROWSER_EMULATION'); Reg.WriteInteger(ExtractFileName(Application.ExeName), 11001); //isto é necessário para poder rodar no internet explorer 11

@Luiz Antonio Ubaldini Realmente aconteceu aqui comigo. Estamos analisando com o time. te posiciono qdo terminarmos

Bom dia! Esta chave 15230934010606000120550010000006791000000740 consta em produção <tpAmb>1, pelo que se nota no conteúdo do teu retorno você está tentando cancelar em <tpAmb>2 (homologação). Verifique se é isto mesmo.

Boa noite, Obrigado pela colaboração. Foram enviadas correções ao SVN que devem resolver o problema relatado, Rev-30742 Por favor atualize os fontes, reinstale os componentes, verifique se o problema foi resolvido e, se possível, nos informe se foi o resultado esperado.

Olá @Juliana Tamizou @Italo Giurizzato Junior Vou entrar em contato com o provedor sobre esse problema e retorno aqui. Obrigado,

Fiz esse teste, como você solicitou. Ao remover o ini da pasta e iniciar a dll, ele cria novamente igual ao print que você mandou acima (valor 0 na tag: 'SSLHttpLib'). E com isso realmente a falha na inicialização não ocorre. Mas para você simular o erro que eu passei no post, basta deixar o valor assim (valor 4 na tag: 'SSLHttpLib'): A falha na inicialização da dll vai ocorrer por causa do valor 4 na tag: 'SSLHttpLib'. Anexei os dois logs, com valor 0 e valor 4 abaixo. Obs.: Quando o valor está 4, você vai perceber no log que é feita a tentativa de inicializar a dll, mas já finaliza em seguida, pois o valor 4 é inválido para o campo e com isso não consegue gravar o restante do log. Obs2.: Meu arquivo ACBr.ini chama-se BOLETO.INI ACBrLibBoleto-20230925 _ SSLHttpLib=0.log ACBrLibBoleto-20230925 _ SSLHttpLib=4.log

Boa tarde Edson, Você esta usando o componente ACBrNFSe ou ACBrNFSeX? Se esta usando o ACBrNFSe, lhe convido a iniciar os testes com o novo componente de emissão de NFS-e: ACBrNFSeX O componente antigo: ACBrNFSe não está mais tendo manutenção. Faça os testes usando o programa exemplo do novo componente. Manual de Migração https://www.projetoacbr.com.br/forum/topic/63017-manual-de-migração-para-o-novo-componente-de-emissão-de-nfs-e/

Olá pessoal! Aqueles que fazem uso dos componentes do ACBr se deparam rotineiramente com duas propriedades que a princípio parecem ser redundantes. Estou falando de: //Configuração no componente ACBrDFe.Configuracoes.Geral.VersaoDF //Preenchimento do DFe no componente ListaDFes.Items[Indice].MeuDFe.InfDFe.Versao No entanto, apesar de parecerem se tratar da mesma informação, cada uma das propriedades tem funções diferentes. ACBrDFe.Configuracoes.Geral.VersaoDF: está configuração no componente, define para qual web service será encaminhado o XML. Ela também afeta algumas configurações do arquivo de envelope da requisição, que é o arquivo XML acrescido de mais informações para ser enviado a Sefaz. ListaDFes.Items[Indice].MeuDFe.InfDFe.Versao: está propriedade define qual é a versão do XML. Está é uma informação importante, necessária e obrigatória nos layouts dos DFes. Mas então você pode perguntar: Ou se você já abriu os fontes do ACBr para analisar: O ACBr faz isso como uma tentativa de ajudar os desenvolvedores, mas isso não deve ser confundido. Atualmente, a versão do XML deve coincidir com a versão do web service. Imagine uma situação em que é carregado/preenchido um NF-e com a versão 4.00, mas a versão DF configurada no componente é a 3.00? Vai ocorrer erro. Por isso o ACBr faz essa distinção para ajudar. Não. Como já foi dito, as propriedades tem funções distintas, uma é a versão do web service e a outra é a versão do XML. Imagine uma possibilidade no futuro de que a Sefaz crie uma nova versão do web service que permita receber XMLs de diferentes versões? Se uníssemos essas propriedades agora, não seria possível enviar versões diferentes usando componente.