Diego Foliene

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Boa noite! Traz sim, mas somente se o web service de consulta devolver a informação. Por exemplo este é o resultado ao consultar o CNPJ do Pão de Açucar no CNPJWS:

Boa tarde! Conferindo no Log do SVN, as alterações mais recentes na unit de retorno do Bancoob foram no dia 21/06. Já as da versão 3 da API foram no dia 28/06. Conferindo na rotina LerRetorno de ambas e comparando com o JSON que disponibilizou, você está utilizando a versão comum e não a V3. Pode confirmar por favor? Se de fato não for a V3, consegue fazer um teste de debug? Coloque o break-point no local indicado pelo print e veja se a rotina de leitura se comporta como o esperado.

Olá pessoal! Conferindo no Portal da Nota Fiscal Eletrônica, é possível observar que a Sefaz de Minas Gerais ativou a contingência no dia 04/07/2024 às 08h20, com previsão de permanecer ativada até às 12h00 do mesmo dia. Para utilizar o ACBr em contingência durante este período, siga as orientações do tópico abaixo. Um agradecimento ao membro de nossa comunidade @Felipe Mariano por compartilhar a informação em nosso Discord.

Obrigado pela contribuição, em breve será validada para possível inclusão ao svn #TK-5692

Olá pessoal! A Sefaz do Ceará divulgou um comunicado informando que no dia 05/07/2024 das 07h00 até às 08h00 será feita uma manutenção programada nos serviços relacionados ao Conhecimento de Transporte Eletrônico. Durante este período a emissão e a autorização não serão afetadas, mas a consulta do CT-e emitido estará indisponível. Leia o comunicado na íntegra AQUI.

Boa tarde! Fiz alguns testes em meu ambiente. Também fiz testes forçando a resposta do Web service com o conteúdo dos envelopes disponibilizados. Mesmo assim, não consegui reproduzir o problema. Por favor, peço que atualize para a versão mais recente da Lib disponível para download no fórum e faça um novo teste para conferir se o problema ainda persiste. Outro ponto que também vale destaque. Revise suas configurações da seção [DFe] do arquivo ACBrLib.ini. Se estiver usando as configurações correspondentes a Capicom, refaça de acordo com Configurações recomendadas para Certificados e WebServices (SSL/Crypt/HTTP), pois capicom foi descontinuada.

Por favor, faça o teste que solicitei mais acima com o comando CTe.SetVersao.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Bom dia! Por favor, faça um teste chamando o comando CTE.SetVersaoDF("4.00") antes de executar o comando que cria o XML do CTe e o que faz o envio.

Bom dia! Gerando pelo portal de homologação não é disponibilizado o XML do processamento do lote e ao tentar via web service com o componente recebo o retorno de "CNPJ não habilitado para uso do serviço". Então não consegui um arquivo para demonstrar, mas ele não está imprimindo a informação porque a mesma não consta no XML. De acordo com a página 23 da versão mais recente do manual, a string copia e cola que é usada para gerar o QrCode do PIX deve vir em uma tag <qrcodePayload> a qual não consta no arquivo que disponibilizou acima. Não vejo alternativa a não ser questionar a Sefaz através de um Fale Conosco para questionar o por quê de a informação não estar sendo devolvida no retorno do web service. Se tiverem um arquivo que possua essa tag qrCodePayload em seu conteúdo e mesmo assim o componente não esteja fazendo a leitura, peço, por favor, que disponibilizem o mesmo para teste.

Bom dia! Você precisaria colher mais informações para poder entender o problema. É a mesma impressora sendo utilizada tanto no caso que vai normal e no que demora? A impressora estava livre no caso que demorava(não tinha nada na fila de impressão ou ocupando a porta)? Sua rotina faz uso de algum comando que recarregue todas as configurações da biblioteca antes de fazer a impressão? Se testar uma mesma nota com as mesmas informações no CNPJ que funciona e no que apresenta lentidão o comportamento é o mesmo?

Olá pessoal! Foi publicado no dia 02/07/2024 a nota técnica 2024/002 para NF3e. Seguindo o que parece ser uma tendência para os documentos fiscais eletrônicos, esta NT estabelece o fim do serviço de recepção de lote de forma assíncrona para a NF3e. Dentre as justificativas apontadas para esta desativação temos: Complexidade em manter o serviço assíncrono controlando o envio e posterior busca de resultados. Estatísticas apontam que 95% das emissões já ocorrem no modelo síncrono. Após a desativação, quem tentar emitir em modo assíncrono vai receber a rejeição: DATAS Desativação no ambiente de Homologação: 02/09/2024 Desativação no ambiente de Produção: 07/09/2024 E como fica o ACBr? O componente ACBrNF3e atende a ambos os modos de envio, sendo configurado via parâmetro no comando Enviar. // Parâmetros do método Enviar: // 1o = Número do Lote // 2o = Se True imprime automaticamente o DANF3e // 3o = Se True o envio é no modo Síncrono, caso contrario Assíncrono. ACBrNF3e.Enviar(StrToInt(vNumLote), True, True); Então a partir das datas citadas, em um exemplo enviando o número de lote 1, mandando imprimir e lendo os dados do retorno será assim: //Faz o envio ACBrNF3e.Enviar('1', True, True); //Lê os dados do retorno. ACBrNF3e.WebServices.Enviar.XXXXX Leia a NT na íntegra AQUI.

Olá pessoal! Conferindo no Portal da Nota Fiscal Eletrônica, é possível conferir que a Sefaz de São Paulo está com a contingência agendada para o dia 14/07/2024, com previsão de início às 06h00 e término às 16h00 do mesmo dia. Para utilizar as soluções ACBr em contingência durante este período, siga as orientações do tópico abaixo: Um agradecimento ao membro de nossa comunidade @Felipe Marianopor compartilhar a informação em nosso Discord.

Também recebemos relatos de que a Sefaz do Paraná devolveu está rejeição no dia 02/07/2024 pela manhã. Por volta das 12:15 e 12:25 ao tentar emitir era recebido Notas emitidas após este período foram autorizadas, dando a entender que a UF do PR também havia ativado a regra e a desativou após relatos de problemas. Um agradecimento ao membro de nossa comunidade @VagnerBegnini por compartilhar a informação conosco.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Apenas para referência para outros colegas que possam vir a ter o mesmo problema: // Parâmetros do método Enviar: // 1o = Número do Lote // 2o = Se True imprime automaticamente o DAMDFE // 3o = Se True o envio é no modo Síncrono, caso contrario Assíncrono. // Obs: no modo Síncrono só podemos enviar UM MDF-e por vez. ACBrMDFe1.Enviar(StrToInt(vNumLote), True, True);`

Olá pessoal! Desde a ativação no ambiente de produção das regras de validação da Nota Técnica 2023/004, alguns membros de nossa comunidade tem relatado estar recebendo a rejeição: Essa rejeição é devolvida quando é informado na nota o tipo de pagamento Cartão de Crédito (tPag=03), Cartão de Débito (tPag=04) ou Pagamento Instantâneo (PIX) - Dinâmico (tPag=17) e não é informado o grupo card. Conforme regra de validação da própria rejeição: Considerando os múltiplos relatos em diferentes Sefaz e o fato de a implementação da regra ser opcional a critério da UF. Nossos colegas da AFRAC buscaram mais informações, entrando em contato com as Sefaz de PB, PE, MG e RJ questionando sobre a ativação desta regra em específico, obtendo as seguintes respostas: Sefaz de MG: “Vamos retornar à regra anterior, ou seja, sem ativar a validação em questão, portanto, apenas para cartão. Para isso, teremos que subir uma versão da aplicação. Enquanto isso, a opção é usarem o código 20 ao invés do 17." Sefaz da PB: “Quem informava o código 17 para Pix estático deve informar o código 20. Iremos publicar no site oficial da Sefaz ainda hoje (01/07) após às 17h." Portanto, para evitar a rejeição, o Pix deverá ser informado no código 20 e, assim, evitar o preenchimento do código de autorização desse formato de pagamento. Em tempo, irão realizar pedido à SVRS para desativar temporariamente a regra de validação Y04-10 para o estado da Paraíba. A expectativa é que a SVRS faça isso até amanhã pela manhã (02/07), portanto, no momento, a solução é informar o código 20 no Pix para não obrigar a informar o grupo de cartões, onde terá que informar o E2dID Sefaz de PE: Aguardando resposta. Sefaz do RJ: "Isso ocorreu porque as empresas estavam acostumadas a informar o código 17 para o PIX. Agora elas devem informar o código 20 se for PIX estático. Se continuarem a informar o código 17 é o PIX dinâmico e a regra de validação exige informar o grupo card, pelo menos o código de autorização do PIX (endToEndId - e2eid ). A AFRAC encaminhou pedido de reavaliação para desativação dessa regra de validação nas UF´s que não disciplinaram a interligação dos pagamentos tal como realizado no RS e MT." Este tópico foi feito baseado em comunicado publicado no Radar AFRAC e que pode ser encontrado na íntegra AQUI.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Vamos continuar no tópico abaixo:

Boa tarde. Tópico vinculado a #TK-5672. Vou fechar o tópico que abriu como usuário comum e seguimos por aqui.