Italo Giurizzato Junior

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

Bom dia todos, Por favor não fiquem criando tópicos repetidos, pesquisem antes de criar os tópicos. Vou fechar este por já existir outro tratando do mesmo problema.

Bom dia todos, Além de atualizar todos os fontes de todas as pastas, reinstalaram a suíte ACBr com a opção de apagar arquivos antigos marcada?

Bom dia Maikon, Você esta usando o certificado da Matriz para realizar a manifestação, correto? Mas ao informar o CNPJ esta informando o da Matriz ou da Filial? O que ocorre em ambos os casos?

Bom dia Lucas, O arquivo INI do provedor com a nova URL já se encontra no repositório.

Bom dia a todos, Vou fechar esse tópico pois ele cresceu de mais, esta com 14 páginas. E desculpe a todos, existem postagens nele que não esta ajudando em nada. Criei outros dois tópicos, um para tratar do WebService de Migração e outro do Novo WebService. Peço que não fiquem postando perguntas do tipo: * Alguém conseguiu enviar? * Estou com o mesmo problema. No tópico que crie referente ao novo WebService, mostro o que esta acontecendo com o provedor, o porque do erro de assinatura invalida. Desde já peço que compreendam a minha atitude.

Bom dia a todos, Favor utilizar esse tópico para tratar de assuntos relacionado ao novo WebService da cidade de Blumenau. Para enviar notas usando esse WebService basta alterar o arquivo Cidades.ini deixando a configuração para a cidade de Blumenau conforme abaixo: [4202404] Nome=Blumenau UF=SC ;Provedor=NotaBlu Provedor=SimplISSv2 NomeURL_H=homologacaoabrasf NomeURL_P=blumenau Note que a linha que se refere ao provedor NotaBlu esta comentada. Observação: Até onde sei o envio de notas através desse WebService usando o componente ACBrNFSe esta funcionando, o problema é que a WebService ao validar a assinatura leva em consideração TAGs que ao realizar a assinatura elas não estão presentes, com isso temos uma rejeição que acusa que a assinatura não é valida. Vamos fazer uma comparação com a NF-e. Na NF-e devemos gerar o XML, assinar e depois incluir o XML assinado no lote. De forma reduzida temos o XML da NF-e assinada: <NFe> <infNFe Id="...."> (...) </infNFe> <Signature> (...) </Signature> </NFe> De forma reduzida temos o Lote <enviNFe> com uma nota assinada: <enviNFe> <idLote>1</idLote> <NFe> <infNFe Id="...."> (...) </infNFe> <Signature> (...) </Signature> </NFe> </enviNFe>'; De for semelhante temos abaixo o XML do RPS assinado e o Lote com o RPS. <Rps> <InfDeclaracaoPrestacaoServico Id="...."> (...) </InfDeclaracaoPrestacaoServico> <Signature> (...) </Signature> </Rps> <GerarNfseEnvio> <Rps> <InfDeclaracaoPrestacaoServico Id="...."> (...) </InfDeclaracaoPrestacaoServico> <Signature> (...) </Signature> </Rps> </GerarNfseEnvio>'; Como vocês podem ver é a mesma coisa. Geramos o XML do documento, assinamos e incluímos dentro do Lote para ser enviado. Esse provedor diz que estamos fazendo errado, pois o correto seria gerar o XML do RPS, incluir ele dentro do Lote e depois assinar o RPS. Como assinamos o RPS com base no elemento <InfDeclaracaoPrestacaoServico> visto que ele é quem possui o atributo ID isso faz com que o TAG <GerarNfseEnvio> não é leva em consideração, pelo simples fato que essa TAG se refere ao Lote e ela não consta no XML do RPS que foi assinado, mas o provedor insiste que devemos gerar o XML do RPS com essa TAG para depois assinar. No meu entendimento eles estão equivocados. Por fim peço que sigamos as regras abaixo para este tópico: 1. Não realizar alterações nos fontes da pasta ACBrDFe, pois isso pode gerar um efeito colateral nos demais Documentos Fiscais Eletrônicos; 2. Ao realizar alterações nos fonte do componente ACBrNFSe se certificar de que essa alteração não vai gerar efeitos colaterais nos demais provedores. 3. Não postar que também esta com o mesmo problema, pois isso faz com que o tópico cresça com postagem que não ajuda em nada. 4. Postar somente quando tiver algum avanço com alguma alteração no código e favor anexar o código para os demais testarem. 5. Postar alguma informação relevante para o grupo passada pelo provedor. Desde já muito obrigado pela colaboração e compreensão de todos.

Bom dia a todos, Favor utilizar esse tópico para tratar de assuntos relacionado ao WebService de Migração da cidade de Blumenau. Para enviar notas usando esse WebService basta alterar o arquivo Cidades.ini deixando a configuração para a cidade de Blumenau conforme abaixo: [4202404] Nome=Blumenau UF=SC Provedor=NotaBlu ;Provedor=SimplISSv2 ;NomeURL_H=homologacaoabrasf ;NomeURL_P=blumenau Note que as 3 últimas linhas estão comentadas. Observação: Até onde sei o envio de notas através desse WebService usando o componente ACBrNFSe esta funcionando e somente o método Gerar foi implementado, as notas são enviadas diretamente para o ambiente de produção.

Bom dia, O que esta faltando?

Bom dia a todos, Qual é a versão do Monitor?

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

Bom dia a todos, Vou fechar esse tópico, pois já tem o do Marcelo, como ele mesmo sugeriu.

Bom dia, Muito simples: 1. Atualizar todos os fontes de todas as pastas; 2. Reinstalar a suíte ACBr com a opção de apagar arquivos antigos marcada; 3. Compilar a sua aplicação com a opção Build; 4. Copiar para a pasta os Schemas atualizados para a pasta que a sua aplicação utiliza (configuração PathSchemas) Observação: os XML antigos não tem a string do QR-Code logo ao imprimir o DAMDFE não vai ser impresso o QR-Code.

Bom dia, Segundo o Manual do DACTE o local é esse e em mais nenhum outro lugar.

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

Bom dia Jobson, DACTE feito em Fast ou Fortes Report? Você poderia anexar o PDF e o XML para que possamos analisar?

Bom dia José, Peça ao seu cliente o XML de um CT-e que ele emitiu sem o seguro de carga e anexe aqui para que eu possa analisar.

Bom dia Marcel, Temos duas situações, uma quando é a SEFAZ-Autorizadora que esta parada e outra é quando a internet do Emitente não esta funcionando. Quando é a internet do Emitente que não esta funcionando, para o CT-e e NF-e temos a opção do envio do evento EPEC através de uma conexão 3G por exemplo. Assim que for sanado os problemas envia o CT-e ou a NF-e para a SEFAZ-Autorizadora. Já o MDF-e você muda gera novamente o XML com o tpEmis = 2 (Contingência) e imprimir o DAMDFE, assim que for sanado os problemas envia para a SEFAZ. Se o problema é na SEFAZ-Autorizadora, tanto para o CT-e quanto para a NF-e temos a opção de envio para a SVC - SEFAZ-Virtual de Contingencia. Para o CT-e temos a SVC-SP e SVC-RS é preciso saber qual das duas atende a SEFAZ-Autorizadora do Emitente. Para a NF-e temos a SVC-AN e SVC-RS também é preciso saber qual das duas atende a SEFAZ-Autorizadora do Emitente. Já o MDF-e não tem uma SVC, logo a solução é a mesma usada quando o problema é do lado do Emitente.

Sim

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

André, Erro de validação não tem nada haver com a configuração refere ao certificado. Se a propriedade PathSchema esta apontando para a pasta XYZ e esta está com todos schemas atualizados e em especial o arquivo cteTiposBasico_v3.00.xsd contem a definição do elemento infCTeSupl, não tem o porque ocorrer o erro de validação informando que esse elemento não é esperado. Favor anexar o XML que esta ocorrendo erro de validação.

Boa tarde Sergio, Entre em contato com a SEFAZ, o problema é lá.

Boa tarde Luiz, Em vez de alterar, porque você não atualiza os fontes?

Boa tarde, O XML do CT-e que você carregou para poder imprimir o DACTE contem a string do QR-Code? Se não tem, não vai imprimir mesmo.

Beleza, E agora ao tentar enviar continua dando o mesmo erro de validação?