Renato Rubinho

Boa tarde Italo, Tudo validado e ok. Pode fechar o tópico. Obrigado

Bom dia Italo, 1. Homologados os métodos - Fonte: ACBr_ApenasAbacoMetodos.zip ACBrNFSx.ConsultarNFSeporNumero ACBrNFSx.ConsultarNFSeGenerico ACBrNFSx.CancelarNFSe 2. Sugestão de implementação - Fonte: ACBr_AbacoMetodosComNovaProp.zip Se já existe algo que controle isso de outra forma, por favor me corrija. Ao tentar cancelar a NFSe no abaco(v1), se eu preencher o InfCancelamento.MotCancelamento, a TACBrNFSeProviderABRASFv1.PrepararCancelaNFSe sempre irá preencher a tag no xml. Com isso, eu preciso controlar quando devo preencher ou não o InfCancelamento.MotCancelamento de acordo com Provedor e Versão. Configurada uma propriedade para identificar se deve ser preenchido o motivo do cancelamento. Deixado padrão para preencher e quando não for para preencher, mudar para false no provedor, conforme feito no abaco(v1). Obs: caso implemente esta sugestão, pode desconsiderar o fonte do item 1, pois está contido neste também.

Desculpe ter feito picado, mas foi para evitar fazer algo errado e ficar patinando sem necessidade (assim como a alteração errada que fiz no ABRASF). Estou revisando todos os métodos e até amanhã confirmo. Obrigado

Legal Italo. Funcionou perfeitamente. Eu tinha caçado no abaco uma correção, mas não enxerguei, pensei que fosse algo geral mesmo. Já fiz mais uma correção nesta unit que você passou, pois a ConsultarNFSePorRps também estava com o parâmetro errado e não encontrava os dados da NFSe no retorno, conforme destacado na imagem a seguir contendo antes e depois da correção. 41-comp-nfse.xml 41-comp-nfse-soap.xml Abaco.Provider.pas

Boa tarde, No ACBrNFeX a consulta da situação do lote não estava lendo o Número do Lote e Situação do xml de retorno, pois estava focando no nível anterior. Anexo fonte com opção para ler do primeiro filho quando não encontrar o lote. No fonte, deixei uma linha comentada com a opção para consulta pelo nome fixo do nó como alternativa, mas entendo que o melhor é pegar o primeiro filho, independente do nome para atender outras situações que este venha a variar. ACBrNFSeXProviderABRASFv1.pas 8A20B3A578BB40D567A3-sit.xml 8A20B3A578BB40D567A3-sit-soap.xml

Bom dia Italo, Atualizado e ambos foram validados. Pode fechar o tópico. Obrigado.

Boa tarde @Italo Giurizzato Junior, Seguem ajustes ( ACBr001.zip ) no ACBrNFSeX para Varzea Grande/MT, provedor Abaco. 1. Não estava assinando o lote * Habilitei o ConfigAssinar.LoteRps para o provedor * Anexo ( xmls_antes_e_depois.zip ) contendo xmls antes e depois da alteração, gerados no programa exemplo para validação 2. O link requer o Valor dos Serviços como parâmetro, além do número da NFSe que também não era passado * Implementei a passagem do AValorServico como string na LinkNFSe * Corrigi os links de produção e homologação no ACBrNFSeXServicos.ini * Anexo ( ACBR_001.png ) destacando o link corrigido xmls_antes_e_depois.zip ACBr001.zip

Quando configurar o componente chama o método ACBrNFSex.LerCidades.

Tentou também as DLLs do outro link e as configurações de SSL e TLS das opções de internet? libcrypto-1_1-x64.dll libssl-1_1-x64.dll libcrypto-1_1.dll libssl-1_1.dll libeay32.dll e ssleay32.dll

Tenta desinstalar o Delphi e apagar a pasta. Apaga a pasta do ACBr também e clona de novo. Se não funcionar, no perfil do usuário atual, tenta criar um novo usuário e refazer o processo.

Verifica se resolve com as DLLs desses topicos.

A vantagem é não depender da ativação do SVC, mas para emitentes com volume muito grande de NFes, ter que reenviar posteriormente quando o serviço normalizar pode ser trabalhoso. Na minha opinião, o ideal é ter as duas opções, usando o SVC quando estiver ativo pois não tem retrabalho e usar o EPEC caso tenha urgência para emitir e o SVC não esteja ativo.

Esse tópico do Ítalo vai te ajudar. A contingência será ativada quando a normal estiver com problemas. Deve usar somente a contingência, pois se a normal estiver instável, receber seu lote, mas ficar em processamento, você não poderá usar o mesmo número de NFe na contingência. tpEmis deve ser SVCRS ou SVCAN, com isso a emissão será transparente para o usuário e não precisará fazer mais nada depois.

Duas ideias: Confirma a versão do midas.dll. Mesmo sendo valores "inteiros", confirma as configurações regionais, pois podem estar com erro em separador decimal, por exemplo. Tenta forçar uma nova configuração.

Boa tarde, O campo fone está só com dois dígitos. Validado no https://www.sefaz.rs.gov.br/nfe/nfe-val.aspx

Boa tarde, Dá uma olhada nesse xml, que foi autorizado com ICMS00, caso ajude no seu cenário.

Veja o cálculo que o Panda colocou no outro link. O vBC faz parte do cálculo agora. Se estiver zerado, este é seu problema. Eu tive o mesmo problema com uma simples remessa, com cst 00 pq o vBC estava zerado. Só preencher vBC resolveu.

Boa tarde, Segue link com informações.

Boa tarde, Segue link com informações.

Olha esse link, tem diversas instruções que podem ser úteis.

Boa tarde, Reinstala o certificado marcando a opção de permitir a exportação da chave privada.

Bom dia, Também cometi essa falha de análise, mas como Túlio disse, esses validadores devem considerar a versão em produção. A versão em produção segue ok, certo? Ainda não tive demanda para implementar e validar para MG.

Dá uma olhada nessa NT que o Panda citou. Melhor confirmar com um contador. Talvez tenha que preencher a base no vBCSTRet ou essa mudança da regra foi exatamente para essa mudança no resultado.

Bom dia, Tive uma rejeição semelhante(815) enviando uma NFe de Simples Remessa, quando BC, aliq e valor de ICMS estavam zerados. Não achei nada que explicasse, mas por lógica preenchi apenas o vBC do item e dos totais, com o mesmo valor de vBCUFDest, e autorizou.

Um cliente solicitou instruções para emitir NFe de Simples Remessa, apenas com o difal também. Segue o xml de exemplo enviado pela contabilidade (xml autorizado, mas eu substituí/excluí dados sensíveis) caso ajude no seu caso. Obs: Neste exemplo os valores não foram preenchidos em campos de ST. 210922071835_23200812345678000195550010000134581826904784.xml