Renato Rubinho

Boa noite, Não vi relatos parecidos em outros canais. Caso o problema persista, como já se passaram as 6h do primeiro problema, siga os passos para o preenchimento do formulário e, se possível, atualize o tópico com o resultado para poder ajudar quem tiver o mesmo problema.

Boa tarde, Muito provável que seja um problema específico no ambiente de homologação deles. Não vi outros relatos deste problema nesse município. Envie o RPS para suporte do provedor para verificarem se tem algo específico nele que gerou a excessão ou se o ambiente de homologação está com problema generalizado.

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

A mensagem diz: O elemento xNome não é esperado. É esperado xLgr. Falta preencher este campo.

Boa noite, Veja se assim resolve: Se foi preenchido infEvento.tpEvento para verificar se foi o evento de cancelamento Ou NFE.InutNFe.nNFIni ou NFE.InutNFe.nNFFin, por exemplo, para identificar se é inutilização.

Boa tarde, Veja o critério para mostrar o qrcode no fortes retrato, preenchendo o link ou outrasinformacoes. ../trunk2/Fontes/ACBrDFe/ACBrNFSeX/DANFSE/Fortes/ACBrNFSeXDANFSeRLRetrato.pas

Certo, a ideia era para confirmar se eventualmente a conversão de data poderia estar gerando alguma exceção, não preenchendo as demais propriedades. No modelo da documentação está preenchida a Seção [EVENTO] ao invés de [CCE], teste dessa forma para ver se funciona. https://acbr.sourceforge.io/ACBrMonitor/NFEEnviarEvento.html https://acbr.sourceforge.io/ACBrMonitor/CartadeCorrecao.html Caso negativo, por favor aguarde os consultores responsáveis pelo monitor que tem maior conhecimento para te ajudar. Consegue validar em produção para verificar se não se trata de um erro em homologação?

Boa noite, Você sempre usou a data com apenas 2 dígitos no ano? Uma hipótese pode ser algum erro na conversão de data, interrompendo o processo e não preenchendo as propriedades seguintes. Não sei se é o caso, mas por via das dúvidas, tente preencher o ano com 4 dígitos.

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

Boa tarde, Você mudou para utilizar a DistribuicaoDFePorNSU ao invés da DistribuicaoDFePorUltNSU Com isso a consulta está sendo feita para o NSU específico zero ao invés da consulta por último NSU a partir do zero.

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

O XML temp1.xml é o RPS para envio ao provedor. O provedor é responsável pela geração do xml da NFSe, que consta na ListaNfse do outro xml que você anexou.

O envio não deve estar correto, não está retornando um erro no envio? Cole um print do retorno do envio com o programa de exemplo.

Isso é um indicativo que o problema é lá, assim como o Juliomar indicou. Não está funcionando corretamente. Acompanhe o grupo do discord que indiquei, que a discussão está grande a respeito. E mantenha os fontes atualizados caso existam ajustes, assim como a atualização da url.

Boa noite, Você está com os fontes atualizados e verificou se o mesmo problema acontece com o programa de exemplo? Veja se este tópico ajuda em algo.

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

Acompanhe o grupo do discord e tópico a seguir para maiores informações. https://discord.com/channels/798697718800318484/801796941813907456

Não somem, se baixou no outro sistema através da DistribuicaoDFe e ainda está dentro do período, será distribuído ao consultar novamente, iniciando a consulta com ultNSU zero. Crie um log na rotina e veja se todos os NSUs estão sendo baixados, garantindo que a falha não esteja no sistema. Se "pular" algum NSU, deve ser falha na rotina. Lembrando que a sincronização da UF autorizadora com o ambiente nacional não é imediata, podendo ser o caso de aguardar até que o documento seja distribuído. No passado houveram casos de NFEs sem data de saída não serem distribuídas, não houve confirmação da Sefaz, mas pode ser alguma anomalia deste gênero. Se identificarem um padrão ou confirmarem que alguma NFe realmente não foi distribuída, abram um fale conosco com a Sefaz para identificarem o motivo.

Tópico duplicado, fechando.

No print está acusando que está selecionado Brasília, mas o padrão dela não é o Padrão Nacional, ela usa ABRASF 2.04. Corrija o "Layout da NFSe" para lnfsProvedor que deverá funcionar adequadamente. Obs: Salve as configurações após alterar o layout, na dúvida, feche e abra novamente o programa de exemplo.

Boa tarde, Veja se a inscrição municipal do prestador está correta e se o certificado é do CNPJ correto.

A mensagem diz que está faltando preencher o campo tribFed ou totTrib.

Bom dia, Até onde eu sabia, a autenticação básica do office365 não iria mais funcionar a partir de 01/01/2023. Será necessária a autenticação com OAuth2. Veja se isso se aplica também ao hotmail.com e outlook.com.br No link a seguir tem uma citação de 31/03/2023. Levante essas informações, se for isso mesmo, não conseguirá mais usar. https://learn.microsoft.com/pt-br/exchange/clients-and-mobile-in-exchange-online/deprecation-of-basic-authentication-exchange-online

Bom dia Willian, Revise as documentações do padrão nacional que deve encontrar maiores detalhes. Veja nos anexos relacionados a lista de serviços / NBS que a composição dos códigos é ITEM + SUBITEM +DESDOBRO NACIONAL http://svn.code.sf.net/p/acbr/code/tools/DFe/NFSe_Nacional/Manuais/

Aumentar o timeout não deveria parar de funcionar algo, tem algum problema de ambiente ainda. Confirme se está usando: * winCrypt * Tls 1.2 * Todas as atualizações do Windows feitas * Driver da leitora atualizado É o melhor a fazer, o A3 é uma praga e com A1 poderá utilizar OpenSSL sem depender mais de nada do Windows.