Italo Giurizzato Junior

Adilson, Para a cidade de Catanduva já tinha sido feito as devidas alterações, se foi necessário você fazer, isso significa que os seus arquivos estão desatualizados.

Bom dia Adilson, Qual cidade mudou de Pronim para Pronimv2? Foi alterado os arquivos Cidades.ini e Pronimv2 em função dessa mudança? Fez testes com o programa exemplo para essa cidade?

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

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

Bom dia Josafar, No caso do MDF-e as datas são: 10/09/2018 - Homologação e 15/10/2018 - Produção, conforme consta na Nota Técnica 2018/002 versão 1.02 que contem as informações sobre a alteração no layout do MDF-e, mas precisamente o novo grupo: infRespTec. Favor anexar o XML do MDF-e com o grupo infRespTec que foi rejeitado pela SEFAZ bem como o de retorno que contem a rejeição.

Maravilha, o famoso fsist esta bugado, não baixa corretamente um CT-e cujo documento emitido pelo remetente é Outros.

No manual costa que esse grupo é opcional, mas isso não significa que você pode informar ou não a revelia, existem regras. Abra o Manual do CT-e e procure pelo nome do grupo infDoc que você vai achar as regras onde esse grupo deve ser informado e quando ele pode estar ausente.

José, esses dois arquivos de retorno são da mesma empresa? Analisando os dois arquivos notei o seguinte: No primeiro ao realizar a consulta foi informado o valor 9190 como sendo o UltNSU e foi retornado Eventos e CT-e cujos NSU foram de 9191 até 9240. Logo a próxima consulta devemos informar o valor 9240 como sendo o UltNSU. No segundo ao realizar a consulta foi informado o valor 9803 como sendo o UltNSU e foi retornado somente eventos (normal) cujos NSU foram de 9804 até 9853. Logo a próxima consulta devemos informar o valor 9853 como sendo o UltNSU. Se esses dois arquivos de retorno pertencem a mesma empresa esta faltando arquivos de retorno, muitos por sinal, ou ocorreu um erro ao informar o valor de UltNSU na consulta seguinte.

Anexe o seu XML. Notei que esse que você anexou a titulo de exemplo o CFOP é 5359 e o Remetente da carga é um pessoa física.

Bom dia Juliana, Você esta com todos os fontes de todas as pastas atualizados? Reinstalou a suíte ACBr usando o ACBrInstall_Trunk2 com a opção Apagar arquivos antigos marcada? Esta muito estranho o arquivo 1-lista-nfse-soap.xml esta completamente vazio só tem a linha que informa o tipo de codificação do XML.

Bom dia José, Para que outras pessoas não fiquem confusas, peço que use os termos corretos. O DistribuicaoDFe do ACBrNFe é usado para baixar as notas fiscais de venda de mercadorias. O DistribuicaoDFe do ACBrCTe é usado para baixar os conhecimentos de transportes de cargas. Eu não sei como funciona o "Arquivei", mas o DistribuicaoDFe implementado tanto no ACBrNFe quanto o ACBrCTe e ACBrMDFe se utilizam do Webservices do Ambiente Nacional. Se a sua aplicação baixa os XMLs do CT-e emitidos por uma empresa deveria baixar os das outras empresas também. O que ocorre com as outras duas, qual é o erro? As outras duas são filiais, ou tem o CNPJ completamente diferentes?

Bom dia, O erro mudou, não é mais a chave da NFS-e? Você esta alimentando o campo: Nfse.RegimeEspecialTributacao ?

Bom dia, Não tem como, um CT-e tem que fazer referencia a uma NF (comum de papel) ou a uma NF-e ou a um outro tipo de documento (Outros) como por exemplo uma Carta Remessa de Mercadoria.

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

Boa tarde Juliana, Qual arquivo esta ficando vazio? O XML do RPS bem como o de envio pelo método Gerar estão sendo gerados sem nenhum problema correto? No programa exemplo do componente temos uma opção "Salvar envelope Soap", ela esta selecionada? Se não estiver, selecione faça um novo teste e anexe os XMLs gerados.

Boa tarde Mauricí, Você esta com todos os fontes de todas as pastas atualizados? Reinstalou a suíte ACBr usando o ACBrInstall_Trunk2 com a opção de apagar arquivos antigos marcada? Se sim, para as perguntas acima, você esta usando o arquivo INI do provedor atualizado?

Boa tarde Júlio, Muito obrigado pela colaboração, fiz uma pequena alteração no arquivo Cidades.ini e SystemPro.ini que quando tivermos mais cidades talvez não seja necessário alterar o INI do provedor. Favor atualizar e fazer novos testes.

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

Bom dia Osmar, Mesmo informando com os 25 dígitos a SEFAZ rejeita o CTe OS? Então o numero esta errado. Existe a regra N038 de validação da SEFAZ ( gera a rejeição 831 ) que diz o seguinte: Se tipo de serviço = Transporte de Pessoas e informado o Número do Registro Estadual, com UF de início igual à UF do Emitente. Verificar situação do Número do Registro Estadual junto à base de dados da SEFAZ ou órgão responsável na UF autorizadora. Observação: Validar o NroRegEstadual quando informado em <rodoOS> e no grupo <prop>. Essa regra é Facultativa, isso significa que cada UF poderá implementar ela ou não. Se em SP você informa 25 dígitos iguais a 1 e funciona, com certeza a SEFAZ-SP não implementou a regra, mas poderá implementar e quando isso ocorrer vai ocorrer a rejeição. Se em MS esta gerando a rejeição, podemos concluir que a regra acima foi implementada. Para descobrir se o Numero do Registro Estadual esta corretou ou não, bem como a sua situação, entre em contato com o órgão responsável por fornecer esse numero.

Boa noite Rene, Muito obrigado pela colaboração, as alterações já estão no repositório. Favor atualizar os fontes e faça novos testes usando o programa exemplo. Note que fiz alterações nos arquivos INI: Cidades.ini, Pronim.ini e Pronimv2.ini

Boa tarde Alisson, Muito obrigado pela colaboração, já enviei para o repositório.

Boa tarde Edson, Tente com essa alteração: case Fprovedor of proNotaBlu, proGiap: Result := (UpperCase(FRetornoNFSe.ListaNFSe.Sucesso) = UpperCase('true')); proISSDSF: Result := Alerta203 or (FDataRecebimento <> 0); proEgoverneISS: Result := ProcSucesso; else Result := (FDataRecebimento <> 0); end;

Boa tarde, Como eu disse antes, ao alimentar o componente com os dados do serviço é necessário informar a chave no campo ChaveNFSe. NFSe.ChaveNFSe := 'informar a chave aqui'; Se não alimentar o XML vai ser gerado sem essa informação. Para saber como gerar essa chave você deve entrar em contato com o provedor.

Breno, Muito obrigado pela colaboração, já enviei para o repositório.

Boa tarde Rodrigo, Em vez de você importar o arquivo *-gnre.xml, tente importar o arquivo *-env-lot.xml