Italo Giurizzato Junior

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

Bom dia Zanatta, Pelo que me recordo todos os Documentos Fiscais Eletrônicos (NF-e, CT-e, NFS-e, etc) usa o sha1, somente o e-Social e o Reinf que utilizam o sha256. O ACBr utiliza como padrão o sha1 e essa alteração para o sha256 para ser usado no e-Social e no Reinf é feita via código do próprio componente. Ou seja, não existe uma propriedade de configuração para selecionar se deseja sha1 ou sha256.

Bom dia Eldo, Pelo comentário que consta a direita da referida linha diz que a UF a ser informada é de quem emitiu o CT-e. Quem é que emitiu o CT-e? A transportadora e não o destinatário da mercadoria, correto? Seguindo o seu exemplo a UF a ser informada é PR pois é a UF da transportadora (quem emitiu o CT-e).

Felipe, Favor atualizar todos os fontes de todas as pastas, reinstale o ACBr e faça novos testes.

Vanderlei, Como a sua unit esta desatualizada com o que esta no SVN. Favor atualizar todos os fontes de todas as pastas, reinstale o ACBr e faça novos testes.

Boa tarde Gleiko, Já esta no SVN.

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

Boa tarde Gabriel, Favor atualizar todos os fontes de todas as pastas, reinstale o ACBr e faça novos testes.

Felipe, Você utiliza o Fortes ou o Fast Report? Você poderia anexar o XML da NFS-e para que possamos analisar?

Ronaldo, Porque você não utiliza a DLL: ACBrLibNFSe ?

Boa tarde Felipe, Lista de checagem: Você tem fontes com alterações locais? Verifica se não tem nenhuma unit do ACBr com uma bolinha vermelha em seu ícone, caso afirmativo delete a unit. Atualize todos os fontes de todas as pastas. Reinstale o ACBr com a opção de apagar arquivos antigos marcada. Compile a aplicação com a opção Build.

Boa tarde Antonio, No novo componente ACBrNFSeX não é usado os arquivos Cidades.ini e os INI dos provedores. No componente novo temos o arquivo ACBrNFSeXServicos.ini que contem as cidades atendidas pelo componente. Para cada provedor temos 3 units, exemplo: SimplISS.Provider , SimplISS.GravarXml e SimplISS.LerXml. Para saber se é necessário o uso do certificado digital, basta abrir a unit Provider do provedor em questão. Veja a imagem que o Diego anexou, nela esta claro que para a verão 2.03 do provedor SimplISS devemos assinar o XML do RPS, assinar o Lote de RPS ( quando o RPS é enviado em Lote ) e assinar o RPS quando este é enviado de forma unitária ( serviço GerarNfse ).

Boa tarde, O componente gera e envia o XML do RPS. Quem gera o XML da NFS-e é o WebService do provedor, caso o RPS que foi enviado esta com todas as informações corretas. A principio em um envio Síncrono já teríamos como retorno o XML da NFS-e ou a lista de erros. Se nenhum dos 2 esta sendo retornado vai ser necessário consultar a nota pelo RPS. Você poderia anexar o XML (soap) de retorno desse envio para que possamos analisar?

Boa tarde Felipe, Já inclui na minha lista de tarefas para analise. TK-4315

Boa tarde Ronaldo, Você trabalha com qual linguagem?

Boa tarde Vanderlei, Muito obrigado pela colaboração, já inclui na minha lista de tarefas. TK-4314

Boa tarde Felipe, Lista de checagem: Você tem fontes com alterações locais? Verifica se não tem nenhuma unit do ACBr com uma bolinha vermelha em seu ícone, caso afirmativo delete a unit. Atualize todos os fontes de todas as pastas. Reinstale o ACBr com a opção de apagar arquivos antigos marcada. Compile a aplicação com a opção Build.

Boa tarde, Você esta usando o componente antigo ACBrNFSe? Se sim, 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/

Boa tarde rlmariz, Essa data/hora que esta no XML retornado pela consulta esta errada. Favor entrar em contato com o provedor e expor o problema.

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

Boa tarde rlmariz, Esse XML é o retorno do webservice referente a consulta. É para ter salvo em disco dentro da pasta Notas o XML da nota retornado por essa consulta. Nesse XML consta o grupo NfseCancelamento, dentro desse grupo tem o pedido de cancelamento, mas a data/hora do cancelamento consta: 0001-01-01T00:00:00 Te aconselho a entrar em contato com o problema e questionar sobre o porque dessa data/hora. O que isso significa, a nota foi ou não cancelada? Se foi não deveria constar a data/hora do cancelamento?

Boa tarde a todos, Conforme consta na página 6 do Manual CTe Anexo I Leiaute e Regras de Validação v4.00 o conteúdo da tag xNome do Remetente, Expedidor, Recebedor e Destinatário em ambiente de homologação tem que ser: “CTE EMITIDO EM AMBIENTE DE HOMOLOGACAO - SEM VALOR FISCAL" conforme as regras de validação: G002, G003, G004 e G005. Notem que a sigla CTE não contem hífen. Por outro lado na página 71 do Manual CTe Visão Geral v3.00a a sigla CTE tem o hífen, ou seja, o conteúdo tem que ser: “CT-E EMITIDO EM AMBIENTE DE HOMOLOGACAO - SEM VALOR FISCAL” conforme as regras de validação: G002, G003, G004 e G005. Resumindo: Segundo as regras de validação mencionadas acima, para a versão 3.00 tem que ser "CT-E" e para a versão 4.00 tem que ser "CTE". Pelo menos é o que consta nas regras de validação de cada manual. As SEFAZ Autorizadoras tem que entrar em um acordo, ou segue a risca o que esta nos manuais ou o ENCATE publica uma Nota Técnica retificando o manual da versão 4. Mas de toda forma todos tem que usar as mesmas regras de validação. Quem tem clientes que a UF x é uma uma forma e na UF y é de outra para a mesma versão, aconselho a entrar em contato com a SEFAZ que esta em desacordo com o manual e pedir explicação. Quanto mais desenvolvedor entrar em contato com as SEFAZ-Autorizadoras questionando a falta de padrão, quem sabe eles resolvem corrigir essa kaka.

Bom dia Luciano, Já esta no SVN.

Boa tarde Diego, Acabei de fazer um teste usando o programa exemplo, veja o resultado: Requisição Ambiente: 1 Cidade : Joinville/SC Provedor: ISSJoinville Versão: 2.04 Método Executado: Enviar Lote Parâmetros de Envio Numero do Lote: 1 Parâmetros de Retorno Data de Envio : 09/08/2023 Numero do Prot: Numero da Nota: Link : Código Verif. : Sucesso : False Erro(s): Código : E73 Mensagem: O CNPJ do PRESTADOR 999999 não está cadastrado no sistema NF-em ou não possui permissão de emitir NF-em. | CNPJ não encontrado na base de dados. Correção: Confira o numero do CNPJ informado. Caso esteja correto, o prestador não está inscrito no município. Como você pode ver não ocorreu esse erro, tudo me leva a crer que você não esta configurando o componente corretamente no que se refere as propriedades: SSLLib, CryptLib, HttpLib, XmlSignLib e SSLType.

Bom dia Luciano, Muito obrigado pela colaboração, já inclui na minha lista de tarefas. TK-4300