Italo Giurizzato Junior

Boa tarde Luiz, Caso tenha, favor anexar o XML que foi recusado e o que foi autorizado pela SEFAZ para que possamos fazer os ajustes necessários.

Bom dia Delfino, Vamos analisar o problema e acredito que ainda hoje estaremos enviando para o repositório a correção.

Bom dia Gabriel, Estamos analisando o problema. Você esta usando o Capicom o WinCrypt?

Bom dia Dercide, Em qual momento ocorreu esse erro? Esta estranho, pois o XML com o pedido de cancelamento foi gerado e assinado e o XML de retorno foi salvo.

Bom dia Daniel, Se tratando de NFS-e precisamos tomar cuidado. Temos o XML do RPS e da NFS-e, é este último que devemos carregar para poder imprimir o DANFSE no papel ou gerar o seu PDF através do método ImprimirPDF. Utilize o programa exemplo para realizar os testes. Ao clicar no botão Imprimir ou PDF selecione o XML referente a NFS-e.

Bom dia Maiquel, Seria interessante testar com outra cidade que também usa o provedor Pronim. Pois essa configuração pode ser especifica para a cidade Feliz/RS.

Bom dia, O componente esta configurado para usar o Capicom ou WinCrypt?

Bom dia Danilo, Você esta configurando o componente com o Capicom ou WinCrypt? Se for com Capicom favor testar com WinCrypt.

Bom dia Barrys, Você esta tentando enviar o RPS através do método Gerar, tente através do método Enviar e depois pelo EnviarSincrono.

Bom dia Márcio, Muito obrigado pela correção, ainda hoje estarei enviando para o repositório.

Boa tarde Kelly, Mais uma vez muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Boa tarde BS, Os arquivos que você anexou se refere ao ambiente de homologação que conforme dito esta funcionando sem nenhum problema. Sendo assim eles não vão ajudar em nada, uma vez que o problema é no ambiente de produção.

Boa tarde a todos, Primeiramente, o evento de Prestação de Serviço em Desacordo se refere ao CT-e e não a NF-e. Segundo, no CT-e temos o Remetente e o Destinatário da Carga a principio um desses dois é o tomador do serviço. Conforme consta no Manual do CT-e versão 3.00 página 30, o respectivo evento deve ser enviado pelo Tomador. Portanto quem vai enviar o evento de Prestação de Serviço em Desacordo é o Tomador que pode ser o Remetente ou o Destinatário da Carga. Gustavo, acho que a sua rotina pode ser simplificada. ACBrCTe.EventoCTe.Evento.Clear; ACBrCTe.EventoCTe.Evento.Add; ACBrCTe.EventoCTe.Evento[0].infevento.chCTe := ChaveCTe; ACBrCTe.EventoCTe.Evento[0].infevento.CNPJ := emitente.cnpj_cpf; ACBrCTe.EventoCTe.Evento[0].infevento.dhEvento := now; ACBrCTe.EventoCTe.Evento[0].infevento.nSeqEvento := NumeroEvento; ACBrCTe.EventoCTe.Evento[0].infevento.tpEvento := tePrestDesacordo; ACBrCTe.EventoCTe.Evento[0].infevento.detEvento.xOBS := ObsDesacordo; ACBrCTe.EnviarEvento(NumeroEvento); ACBrCTe.EventoCTe.GerarXML; Agora é só testar.

É capaz do contador confundir Manifesto de Documentos Fiscais Eletrônicos com Manifestação do Destinatário.

Bom dia Barrys, Favor atualizar todos os fontes de todas as pastas, reinstale a suíte ACBr usando o ACBrInstall. Notei que o seu arquivo Cidades.ini esta muito desatualizado. Refaça os testes.

Bom dia, No Manual os modelos de MDF-e não tem a relação das chaves das NF-e ou CT-e. E no Ajuste SINIEF 21/2010 também não tem nada a esse respeito. Logo não se faz necessário a impressão da relação. Mas conforme o relato da Graça que algumas transportadoras foram multadas, acho prudente manter. Como você tem os fontes, basta fazer uma alteração para que o quadro que lista as chaves não seja impresso. Mas antes chama o seu cliente e diga, vou alterar para não imprimir, se você for multado não venha me culpar.

Bom dia, Se o componente esta configurado para salvar os XMLs de envio e de retorno, porque você não anexa para que possamos lhe ajudar. Sem esses arquivos ficamos de mãos atadas.

Bom dia Rodrigo, Muito obrigado pela colaboração, ainda hoje estarei analisando e se estiver tudo OK, vou enviar para o repositório.

Bom dia Windel, A questão não é o layout do XML do CT-e OS ou o Schema que valida o mesmo e sim as regras de validação que se encontram no WebService da SEFAZ. Se as regras estão corretas o problema então recai ao cadastro dessa Secretaria junto a SEFAZ. Eu não entendi, como uma Secretaria que tem um único CNPJ possui varias Insc. Estaduais? Se uma empresa possui uma Insc. Estadual a mesma é valida para o Estado inteiro, logo não importa a cidade. Uma coisa é a Insc. Estadual e outra é a Insc. Municipal, essa sim é por município.

Winder, Essa pessoa da SEFAZ que lhe respondeu esta mais por fora do que umbigo de vedete. O grupo <toma4> esta definido no schema chamado cteTiposBasico_v3.00.XSD na linha 453 portanto dentro da definição do tipo TCTe que se encontra na linha 114. Por outro lado o grupo <toma> esta definido na linha 2881, portanto dentro da definição do do tipo TCTeOS que se encontra na linha 2394. Resumindo, se você vai emitir um CT-e o componente se utiliza da definição do tipo TCTe, por outro lado se for emitir um CT-e OS ele se utiliza da definição do tipo TCTeOS e dentro desse tipo não existe o grupo <toma4>.

Boa tarde a todos, A relação das chaves foi incluída para facilitar o fiscal, pois desta forma deixa claro em "papel" quais são as notas referenciadas naquele MDFe. E se não me falha a memória o DAMDFE feito em Fortes Reportes apresenta a cidade e as chaves das notas onde a carga vai ser descarregada.

Boa tarde Windel O grupo <toma4> só existe no CT-e (modelo 57) no CT-e OS (modelo 67) temos o grupo <toma> conforme consta no manual. O grupo <toma> só não é gerado em caso de Excesso de Bagagem, veja no seu XML que a tag <tpServ> tem o valor 6 que significa Transporte de Pessoas, ou seja Fretamento. Logo, devemos gerar o grupo <toma>. Como você informando 9 em indIEToma isso significa que o tomador não é contribuinte, neste caso a tag <IE> dentro do grupo <toma> não deve ser gerada. Se o tomador for contribuinte mas é isento a tag <IE> deve ser gerada com a palavra "ISENTO".

Bom dia, Se não esta gerando a tag <mdfeProc> significa que o MDF-e enviado não foi autorizado. Você precisa configurar o componente para salvar os XMLs secundários. Configuracoes.Geral.Salvar := True Desta forma os arquivos de envio e de retorno da SEFAZ serão salvos em disco, desta forma será possível ver o que esta ocorrendo. Aliais a sua aplicação tem que pegar o status e a descrição do mesmo e apresentar na tela caso seja diferente de 100, pois pode esta ocorrendo uma rejeição e esta não esta sendo apresentada.

Luís, Só existe uma única rotina referente a eventos. Isso que você esta fazendo é uma consulta. Porque você não pega o XML referente ao evento logo após o seu envio? Desta forma você sabe o tipo de evento que se trata o XML, pois se você solicitou o cancelamento, o XML que você vai pegar é o de evento de cancelamento e não de carta de correção por exemplo.

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