Italo Giurizzato Junior

Boa tarde Maico, Vai ser necessário debugar para saber exatamente em qual linha ocorre o erro. O XML de retorno tanto o de soap quanto o não soap estão sendo salvos.

Boa tarde Pessoal, Quanto mais prestadores de serviço protocolarem uma reclamação que a API não esta funcionando para o caso do Simples Nacional ME/EPP a prefeitura vai pressionar a Receita Federal e ou SERPRO. Ai o SERPRO vai ter que dar plantão esse feriado e final de semana para consertar a cagada que eles fizeram (isso se a kaka é deles). Como eu já disse que o problema pode ser alguma parametrização errada na API de produção por parte da prefeitura, ai quem vai fazer plantão é o pessoal da prefeitura.

Gabriel, Desculpa me enganei, no caso do Ginfes somente o lote é assinado. Mas veja isso: <ns4:ValorLiquidoNfse>-1.00</ns4:ValorLiquidoNfse> Esta correto o valor liquido da nota ser um valor negativo?

Bruno, Para uma melhor analise eu preciso do soap de retorno e não de envio, uma vez que o erro ocorre ao tentar tratar o retorno.

Douglas, Substitua a unit pela que esta em anexo. Reinstale o ACBr e faça um novo teste. IPM.Provider.pas

Boa tarde Bruno, Configure o componente para salvar os arquivos "soap". Faça um novo teste e anexe os arquivos "soap" para que possamos analisar o problema.

Não seria mais fácil informar os dados dessa fatura na discriminação do serviço? Usar o caracter ";" para gerar a quebra de linha.

Boa tarde Douglas, No campo Discriminacao do RPS notei que você não usou a quebra de linha que é recomendado. Por favor gere um novo RPS inserindo o caracter ";" onde você deseja que ocorra a quebra de linha. Depois você anexa o XML desse novo RPS e o XML da NFS-e referente a esse RPS. Só assim vamos poder analisar melhor o problema.

Boa tarde, No layout do DPS contempla esse tipo de informação?

Boa tarde Fabiano, Não sei se a sua solução não vai gerar efeito colateral com outras versões do Delphi (não sei qual você usa) ou com o Lazarus ou até mesmo com outros provedores. Talvez o melhor lugar por enquanto é colocar na unit IPM.Provider. Na função: function TACBrNFSeXWebserviceIPM.TratarXmlRetornado(const aXML: string): string; Trocar a linha: Result := String(NativeStringToUTF8(Result)); por : Result := AnsiToUTF8(Result); Faça essa alteração e faça novos testes.

Boa tarde Gabriel, 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. O XML de envio somente o lote esta assinado e o Ginfes requer que tanto o RPS quanto o Lote sejam assinados.

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

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

Bom dia Dercide, Já esta no SVN.

Bruno, Já esta no SVN.

Bom dia Eliandro, Peça para todos os seus clientes protocolarem na prefeitura uma reclamação sobre o problema que estão enfrentando. Como existem informações que a prefeitura parametriza na API e não sei se é algum erro de parametrização ou se é um erro mesmo na API.

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

Bom dia Marcelo, Na unit pcnGerador temos a procedure wAlerta responsável por gerar os alertas, veja: procedure TGerador.wAlerta(const ID, TAG, Descricao, Alerta: string); var s: string; begin // O Formato da mensagem de erro pode ser alterado pelo usuario alterando-se a property FFormatoAlerta: onde; // %TAGNIVEL% : Representa o Nivel da TAG; ex: <transp><vol><lacres> // %TAG% : Representa a TAG; ex: <nLacre> // %ID% : Representa a ID da TAG; ex X34 // %MSG% : Representa a mensagem de alerta // %DESCRICAO% : Representa a Descrição da TAG s := FOpcoes.FFormatoAlerta; s := StringReplace(s, '%TAGNIVEL%', FTagNivel, [rfReplaceAll]); s := StringReplace(s, '%TAG%', TAG, [rfReplaceAll]); s := StringReplace(s, '%ID%', ID, [rfReplaceAll]); s := StringReplace(s, '%MSG%', Alerta, [rfReplaceAll]); s := StringReplace(s, '%DESCRICAO%', Trim(Descricao), [rfReplaceAll]); if Trim(Alerta) <> '' then FListaDeAlertas.Add(s); end;

Bom dia, Pela mensagem de erro retornada ao enviar em produção me leva a crer que deva ter alguma informação errada deste prestador no cadastro do simples nacional. Tem que ver se esse MEI continua como sendo MEI, pois ele pode mudado em função do seu faturamento anual.

Bom dia Fabiano, O inicio informando o encoding é incluído pelo componente antes de salvar em disco. O componente detecta que o conteúdo é um XML e automaticamente acrescenta o encoding. Pelo o que eu entendi ao executar o xmlParseDoc em um XML que não esteja codificado em UTF-8 o valor de loadedDoc vai ser nil. Se isso ocorrer executa novamente o xmlParseDoc mas executando a função AnsiToUtf8, Com essa alteração a leitura do XML ocorreu sem nenhum problema? Como ficou as vogais acentuadas e o cedilha?

Bom dia Douglas, A questão é o seguinte: 1. sempre devemos ao alimentar o componente usar como quebra de linha o caracter ";" conforme o tópico abaixo. 2. Ao gerar o XML poderá ocorrer a troca do ";" por outro caracter conforme configuração definida na unit provider do provedor que no caso do IPM temos o seguinte: procedure TACBrNFSeProviderIPM204.Configuracao; begin inherited Configuracao; ConfigGeral.QuebradeLinha := sLineBreak; ConfigGeral.Identificador := ''; ConfigGeral.ConsultaPorFaixaPreencherNumNfseFinal := True; ConfigWebServices.AtribVerLote := ''; ConfigMsgDados.GerarPrestadorLoteRps := True; end; Como você pode ver vai ocorrer a troca do ";" pelo LineBreak que é #13, isso explica a troca. Quando o componente faz a leitura do XML da NFS-e realiza o processo inverso, veja: Descricao := ObterConteudo(ANodes[i].Childrens.FindAnyNs('Discriminacao'), tcStr); Descricao := StringReplace(Descricao, FpQuebradeLinha, sLineBreak, [rfReplaceAll, rfIgnoreCase]); Que no caso do provedor IPM vai substituir o LineBreak por LineBreak, ou seja, vai ficar exatamente igual, mas vai ocorrer a quebra de linha no DANFSE. Lembre-se que o XML a ser utilizado para imprimir o DANFSE tem que ser o XML da NFS-e e não o XML do RPS. Até agora não consegui entender o problema que você esta tendo. Você poderia anexar o XML do RPS gerado pelo componente e da NFS-e gerada pelo webservice do provedor após o envio desse RPS, para que possamos analisar?

Fabiano, O problema é que o provedor esta retornando o XML no formato ANSI em vez de UTF-8.

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

Paulo, Não existe nenhuma tag com esse nome. Pelo para o seu cliente solicitar a essa indústria um XML de um CT-e que contenha essa informação.

No XML de homologação você esta identificando o prestador como sendo MEI <regTrib> <opSimpNac>2</opSimpNac> <regEspTrib>0</regEspTrib> </regTrib> Mas em produção não <regTrib> <opSimpNac>1</opSimpNac> <regEspTrib>1</regEspTrib> </regTrib> A final de contas o prestador é ou não é MEI? Outra coisa não informe o campo xNome do prestador. Por fim mude o conteúdo do grupo tribMun de: <tribMun> <tribISSQN>1</tribISSQN> <tpRetISSQN>1</tpRetISSQN> </tribMun> para: <tribMun> <tribISSQN>4</tribISSQN> <tpRetISSQN>1</tpRetISSQN> </tribMun> Faça estas alterações e tente novamente.