Diego Foliene

Tópico movido para a área do SAC, para que o SLA de respostas seja considerado

Bom dia! Foi enviado no SVN na Rev-31463, alteração para que preencha a propriedade da classe web service. No entanto, vale explicar que na verdade não era um erro. O que acontece é que a informação é preenchida em outra propriedade. Por isso, agora, com a alteração recente, você pode escolher entre: ACBrMDFe.WebServices.Enviar.dhRecbto; Ou a propriedade que já recebia a informação antes: ACBrMDFe.Manifestos[Indice].MDFe.procMDFe.dhRecbto; Lembrando que para alteração surtir efeito, você precisa atualizar seus fontes e reinstalar o ACBr.

Bom dia! E-mail recebido, muito obrigado! Faremos alguns testes e reportamos aqui assim que descobrirmos algo.

Por favor, disponibilize o XML em [email protected] para que possamos usar nos testes. Não se esqueça do link do tópico no corpo do e-mail para posterior identificação.

Olá pessoal! Entre os dias 04 e 05 tivemos relatos em nossa comunidade do Discord de problemas para emitir CT-e para a Sefaz São Paulo, com o número de protocolo de CT-es autorizados sendo devolvido com tamanho 16 ao invés de 15. Considerando os últimos relatos, tudo indica que a situação foi normalizada e a resposta da Sefaz está de acordo com a documentação. Segue abaixo uma breve transcrição do ocorrido. Se você ainda está tendo problemas, é importante que deixe a Sefaz ciente através de um Fale Conosco. Os primeiros relatos começaram no dia 04/12/2023, por volta das 08h52 e informavam que a emissão era feita com sucesso, mas a Sefaz estava devolvendo um número de protocolo com 16 dígitos ao invés de 15 que é o tamanho estipulado, causando assim problemas. Por volta das 15h49, membros começaram então a reportar estarem recebendo no retorno: Durante este mesmo período, alguns membros mencionaram ter conseguido emitir CT-e enviando em contingência e nesses casos o número do protocolo devolvido era composto de 15 caracteres. No dia 05/12/2023, por volta das 08h46, participantes da comunidade cujos clientes emitiram CT-es em modo normal e receberam um número de protocolo com 16 dígitos estavam tendo dificuldades para realizar o cancelamento devido ao tamanho atípico. Outro detalhe que foi notado é o fato desses CT-es de 16 dígitos estarem retornando 01/01/0001 00:00 na informação da data/hora de aprovação ao realizar um consulta. Por volta das 14h00, tivemos relatos de sucesso ao cancelar os CT-es removendo o primeiro número do protocolo de 16 posições normatizando para o tamanho esperado de 15. A conclusão que se chegou por parte dos integrantes da comunidade é a de que o contador do campo do protocolo estourou passando então para 16 caracteres. As 15h02, um membro relatou que ao consultar as chaves dos CT-es que devolveram protocolo com 16 dígitos, a informação havia sido corrigida e o campo estava agora com caracteres. Não foi encontrado comunicado oficial a respeito do ocorrido no Portal Estadual durante o período.

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

Boa tarde! Foi gerada uma nova compilação da Lib englobando o ajuste que visa resolver o problema. Por favor, queira atualizar e realizar um novo teste.

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

Bom dia! Foi gerada nova compilação do ACBrMonitorPLUS, por favor, queira atualizar e realizar novos testes.

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

Bom dia pessoal! Conferindo no Portal da Nota Fiscal Eletrônica, consta aviso de que a Sefaz de São Paulo está com contingência agendada para o dia 10/12/2023, com previsão de inicio às 06h00 e com previsão de término às 16h00 do mesmo dia. Para usar o ACBr em contingência durante este período, siga as orientações deste tópico: Um agradecimento aos membros da comunidade que chamaram a atenção para o fato no canal #sefaz em nossa comunidade do Discord.

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

Boa tarde! Tivemos membros relatando no canal #sefaz que estavam com este problema e conseguiram emitir em contingência. Outros relataram também que a emissão já foi normalizada. Por favor, tente realizar um novo teste.

Boa tarde! Apenas dando um retorno. A TK foi alocada no sprint desta semana. Qualquer novidade relacionada será colocada aqui.

Fiz um teste usando o programa exemplo em C# e a última versão da LibNFSe disponível no fórum. Recebi os mesmos retornos que o @Italo Giurizzato Junior. Comparando o seu arquivo -env-lot-sinc.xml com o que gerei aqui, uma diferença que notei, é que o seu não tem esta seção. <Rps> <IdentificacaoRps> <Numero>1</Numero> <Serie>85</Serie> <Tipo>1</Tipo> </IdentificacaoRps> <DataEmissao>2023-12-01T00:00:00</DataEmissao> <Status>1</Status> </Rps> Veja se está informando a seção [IdentificacaoRPS] no arquivo INI que está passando.

Bom dia! Para confirmar isso, por favor, configure a Lib para salvar os arquivos de envelope definindo uma PathSalvar e também o valor sim para SalvarWS na seção [NFSe] das configurações. Feito isso, repita o teste para que ele gere para você os arquivos de envelope da requisição. Veja qual é o conteúdo do -soap de resposta, veja consta está mensagem nele. Caso afirmativo, por favor, me confirme qual é a cidade que está tentando emitir e disponibilize o -soap de envio para que eu possa fazer um teste aqui e comparar o seu -soap de envio com o que for gerado aqui para verificar se há diferenças.

Bom dia. Alteração enviada ao SVN na Rev-31426, por favor, queiram atualizar seus fontes, reinstalar o ACBr para realizar novos testes e reportar qualquer problema.

Bom dia. Tivemos um relato no tópico abaixo de outro membro que homologou utilizando a versão 2.02, por isso, optamos por esta. A alteração foi enviada ao SVN na Rev-31426, por favor, queira atualizar seus fontes, reinstalar o ACBr para realizar novos testes e reportar qualquer problema.

Realmente! Hmm, conferindo no HexEditor, consta a informação para o município, consta a informação do município, mas em palpite inicial, é possível que esteja relacionado ao ajuste feito para sanar o outro problema que reportou para Porto Velho/RO. Criada a #TK-4817 para análise do caso e parecer do consultor responsável. Por favor, vou lhe pedir também que: Confirme qual é a linguagem de programação que está usando para desenvolver. Realizar o teste colocando o ACBrNFSeXServicos.ini na pasta do .EXE e apontando o arquivo em IniServicos na seção NFSe.

Boa tarde! O código 1234567 não existe e de fato está errado.

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

Foi definida uma data para ocorrer a troca ou a mesma já ocorreu? Pergunto pela possibilidade de trocarmos agora, ainda não estar ativo e causar problemas para quem emite.

Boa tarde! Por favor, pode fornecer mais informações para que possamos ajudar? Qual é a cidade que está tentando emitir? O que quer dizer por não dar certo? Não aparece a informação no XML? A informação aparece, mas você recebe um erro?

Boa tarde! Obrigado pela informação. Por favor, foi informado se eles vão optar pela versão 1.00 ou pela versão 2.02 do layout?