Italo Giurizzato Junior

Boa tarde Lucas, Favor anexar também o XML de retorno da SEFAZ que contem a rejeição.

Favor anexar o XML que foi enviado.

Favor atualizar, reinstalar os componentes e repita os testes.

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

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

Boa tarde Bruno, Quando isso ocorre, ou seja, você envia o XML do MDF-e para SEFAZ o mesmo é autorizado, mas o XML fica sem o protocolo de autorização é muito simples de resolver. 1. Carregue o XML do MDF-e assinado através do método LoadFromFile; 2. Execute o método Consultar; Pronto, se o MDF-e em questão foi autorizado pela SEFAZ, o seu XML será atualizado, ou seja, vai receber o protocolo de autorização.

Boa tarde Marcio, O problema é que para CSOSN 900 os campos a serem alimentados são: vBCFCPST, pFCPST e vFCPST. E você alimentou os campos: pFCP e vFCP.

Flavio, Os componentes ACBr só valida um XML caso este esteja assinado, logo ao validar o mesmo já valida a assinatura. Como disse o colega Alisson, ele já usa o componente enviando os eventos sem nenhum problema.

Flavio, A mensagem de erro ocorre quando você pega o XML assinado e tenta validar ele nesse site que você informou? Se sim, porque você esta tentando validar nesse site? O componente após gerar e assinar o XML já valida o mesmo.

Boa tarde Israel, O provedor Ginfes segue a versão 1 do layout da ABRASF e segundo esse layout não existe o serviço SubstituicaoNFSe. Esse serviço só esta disponível para os provedores que seguem a versão 2 do layout da ABRASF.

Boa tarde Jean, Pela mensagem de erro que esta aparecendo noto que os seus fontes estão desatualizados. Favor atualizar todos os fontes de todas as pastas, reinstale a suíte ACBr usando o ACBrInstall_Trunk2 e faça novos testes.

Boa tarde, Acredito que encontrei o problema, ainda hoje estarei enviando para o repositório a correção.

Boa tarde Hugo, O problema é que Salvador na assinatura digital esta se utilizando de apenas uma transformação, o ACBr se utiliza de duas, pois é o que é usado em todos os documentos fiscais eletrônicos. Na assinatura do XML exemplo de Salvador no grupo X509Data consta o elemento X509SubjectName que não é usado no padrão. E também existe a presença do grupo KeyValue que não é usado na assinatura padrão. Quando me refiro assinatura padrão, é a assinatura utilizada pela NF-e, NFC-e, CT-e, CT-e OS, MDF-e, BP-e, e-Social, Reinf e a maioria dos provedores de NFS-e.

Boa tarde Mateus, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Boa tarde Mateus, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Boa tarde Flavio, Ao instalar o certificado, você ativou a opção de exportável? Você esta fazendo testes usando o programa exemplo do componente ACBreSocial?

Descobri que o componente estava removendo a assinatura do pedido de cancelamento que se encontra dentro do pedido de SubstituicaoNFSe. Fiz a correção. Favor atualizar os fontes e faça um novo teste. Notei também que no exemplo o código de cancelamento é 2 e não 1.

Bom dia Hugo, Pede ao provedor um XML assinado para que possamos analisar, quem sabe descobrimos onde esta o problema.

Bom dia Dercide, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Bom dia, Favor entrar em contato com o provedor e solicitar um XML de Substituição NFSe de exemplo para que possamos analisar.

Bom dia Jean, A sua aplicação não esta ainda usando o arquivo Fiorilli.ini desatualizado? A URL do SoapAction se encontra nesse arquivo, se ele esta desatualiza, o erro ainda vai ocorrer.

Bom dia Sergio, O Monitor não carrega automaticamente as versões é preciso neste caso alterar a lista do componente cbVersaoWSReinf. Na propriedade Items com componente mencionado acrescente no final: 1_04_00

Bom dia a todos, Já participei de vários eventos, mas como visitante, o Dia do ACBr vai ficar na minha memoria para sempre. Falar pessoalmente com pessoas que admiro muito. Obrigado a todos pela oportunidade.

igmaster, Ao enviar o evento de encerramento deste MDF-e qual é a mensagem exata retornada pela SEFAZ? Não faz nenhum sentido o que esta ocorrendo. Ao enviar um MDF-e em seu XML temos a tag <procEmi> que informa se o aplicativo usado é do Fisco ou não. Mas ao enviar o evento essa informação não existe no XML, logo não tem nada haver, ou seja, podemos usar um aplicativo para enviar o MDF-e (da SEFAZ por exemplo) e outro (não da SEFAZ) para enviar o evento de encerramento. Agora me explica o motivo de encerrar o MDF-e em relação a carga presa na barreira.

Boa tarde Hugo, Se tratando de Salvador não será possível usar o libCapicom e nem o libCapicomDelphiSoap, esses dois não funcionam quando o identificado é "id" tudo minúsculo. Por outro lado o libWinCrypt funciona com esse identificado.