Diego Foliene

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

Bom dia! Acredito ter encontrado a causa da divergência. Você está carregando um arquivo INI com as informações do RPS e está gerando o PDF. Em meu teste, eu carreguei o XML que disponibilizou anteriormente e fiz a impressão. São processos diferentes: Ao carregar o arquivo INI, a biblioteca faz a leitura do mesmo preenchendo as propriedades correspondentes. Ao carregar o XML, a biblioteca faz a leitura do mesmo, preenchendo as propriedades correspondentes e fazendo um processamento interno de algumas propriedades totalizadoras. Por isso não tive problemas ao testar carregando o XML que disponibilizou. Criada a #TK-5607 em nosso backlog para verificar possibilidade de melhoria da rotina de leitura do INI para que também realize este processamento interno. Durante este tempo, peço que carregue o XML para geração do PDF. VALE RESSALTAR que o DANFSe é o espelho do XML de uma NFSe, então para a correta exibição de todas as informações, o XML que deve ser carregado é o de uma nota fiscal de serviços. Se carregar o XML de um RPS, não vai dar erro, porque alguns campos coincidem, mas também não vai exibir todas as informações, visto que algumas delas são exclusivas do XML da nota.

Por favor, o mesmo problema ocorre se testar com o programa exemplo? Comparando o seu arquivo com o que foi gerado em meu ambiente, seu arquivo não tem a Inscrição Municipal do prestador informada.

Por favor, qual é a versão da Lib que está utilizando? Fiz um teste com a versão mais recente disponível no fórum e o exemplo em C# e o resultado foi semelhante ao do programa exemplo, mostrando o Valor Total da Nota = 50,00; Atualize a Lib para a versão mais recente disponível no fórum e repita o teste. Se o problema persistir, disponibilize o log da Lib configurado no nível paranoico para análise.

Boa tarde! Qual é o valor de FNServico.rps_tipo ? A estrutura das rotinas de conversão é como segue: function TACBrNFSeXProvider.TipoRPSToStr(const t: TTipoRPS): string; begin Result := EnumeradoToStr(t, ['1', '2', '3', '0'], [trRPS, trNFConjugada, trCupom, trNone]); end; function TACBrNFSeXProvider.StrToTipoRPS(out ok: boolean; const s: string): TTipoRPS; begin Result := StrToEnumerado(ok, s, ['1', '2', '3', '0'], [trRPS, trNFConjugada, trCupom, trNone]); end; Tudo indica que sua função está convertendo para o valor zero que corresponde a trNone. Sugiro que coloque um break-point nessa linha e usando o step-into(F7) e o watch-list veja quais sãos os valores assumidos pelo TipoRPS.

Tópico movido para a área do SAC, para que o SLA de respostas seja considerado

Boa tarde! Que bom que deu certo! Criada a #TK-5603 para análise da solicitação de permitir um número de protocolo como parâmetro do comando e parecer por parte da equipe de consultores.

Boa tarde! O arquivo .pdf que disponibilizou não está abrindo aqui em meu ambiente, parece estar com erro. Por favor, você está utilizando componente nativo para Delphi/Lazarus, Monitor ou Lib? Se estiver usando Delphi/Lazarus, está usando Fortes ou Fast? Fiz um teste com o exemplo nativo em Delphi e o PDF gerado trouxe os valores.

Bom dia! De fato, conferindo no manual a cardinalidade do campo é 0-1, indicando que o mesmo é opcional. Criada a #TK-5602 para análise do caso e parecer por parte da equipe de consultores.

Bom dia @WesleySantos e @lucimauro! As considerações de vocês estão corretas, ao cancelar a nota fiscal, a Lib e o Monitor fazem a consulta da nota automaticamente pela chave de acesso para pegar o número do protocolo. Isso é feito, porque de acordo com o layout dos eventos, ele é uma informação obrigatória. Por favor, abram um Fale Conosco junto a Sefaz para questionar como deverá ser feito o cancelamento sem esta informação.

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.

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

Bom dia! Pelo que pude entender, eles abriram um chamado interno para verificar se tem mesmo algum problema no EndPoint de consulta, então estão conferindo se tem erro. Mas também recomendaram você a usar os WebHooks ao invés de fazer a consulta manualmente.

Olá pessoal! Ao acessar o site do Portal do Bilhete de Passagem Eletrônico, na aba de avisos, consta o seguinte recado publicado no dia 06/06/2024: Fonte: https://dfe-portal.svrs.rs.gov.br/bpe/Avisos O mesmo aviso pode ser encontrado nos portais dos demais documentos citados. O tópico abaixo pode auxiliar na emissão do MDFe utilizando as soluções ACBr:

Olá pessoal! Foi publicado no dia 07/06/2024 no Portal da Nota Fiscal Eletrônica um aviso informando que as contingências para os estados do Rio Grande do Sul que haviam sido ativadas anteriormente(desde 06/05/2024) devido as dificuldades enfrentadas, serão desativadas no dia 13/06/2024. Veja o conteúdo do aviso na íntegra: Fonte: https://www.nfe.fazenda.gov.br/portal/informe.aspx?ehCTG=false&Informe=n8lLJ91ulpk=

Olá pessoal! Foi publicado no dia 07/06/2024 a a versão 1.01 deste informe técnico. A nova versão apenas corrigiu o item 5 para que o mesmo contemplasse outras formas de crediário. Alterando a descrição atual: Para a nova: O informe pode ser lido na íntegra AQUI. A Tabela atualizada pode ser encontrada AQUI.

Contextualizando Se você está tentando emitir uma nota fiscal de serviços eletrônica para o provedor Ginfes, um dos possíveis retornos que pode receber é: <Codigo>E160</Codigo> <Mensagem>Arquivo enviado fora da estrutura do arquivo XML de entrada.</Mensagem> <Correcao>Envie um arquivo dentro do schema do arquivo XML de entrada.</Correcao> A mensagem parece ser alto explicativa e indica que o arquivo que foi enviado está com erro na estrutura, certo? Infelizmente, não é tão simples assim. Os arquivos gerados pela solução ACBr estão de acordo com os schemas e o leiaute fornecido pelo provedor. Na verdade este erro parece ser devolvido pelo Ginfes não só para problemas de leiaute, mas também para "situações genéricas". Vejam alguns exemplos: Erro E160 - Arquivo enviado fora da estrutura do arquivo XML de entrada: Neste tópico um colega relata que resolveu o problema ao corrigir o número do lote que não estava alimentando no componente. Ginfes - Franca = Erro E160: Neste tópico um colega confirma que conseguiu resolver o problema ao corrigir os dados que preencheu no componente para geração da nota. Formatação do campo Aliquota da NFSe: Neste tópico o colega confirma que o CPF do tomador estava incorreto e após correção conseguiu emitir. Erro E160 - Arquivo enviado fora da estrutura do arquivo XML de entrada: Neste tópico um colega conseguiu superar este erro após corrigir um valor que estava indo negativo no XML. Esse erro também pode ocorrer caso você não seja prestador da cidade que esteja fazendo testes, em vez do provedor retornar que o seu CNPJ não consta no cadastro deles, o retorno é esse erro E160 que acusa que o arquivo enviado esta fora da estrutura. Mas então o que eu posso fazer? Caso você tenha recebido este erro ao tentar emitir uma nota para uma cidade que é atendida pelo provedor Ginfes, revise todas as informações presentes no XML gerado. Se mesmo depois disso o problema persistir, entre em contato com o provedor e questione o por quê de estar recebendo esta rejeição. Ao fazer isso, o provedor pode apontar se alguma informação presente no XML está em desacordo com o cadastro da base de dados mantida pelo mesmo.

Aviso publicado no canal Sefaz RS ICMS:

Notícia relacionada: "Procergs retoma operação após 20 dias fora do ar"

Em anexo boletim econômico tributário compartilhado no canal #sefaz em nosso Discord pelo membro de nossa comunidade @gabriel.hilbig boletim-economico-tributario-receita-estadual-enchentes-2024-edicao-n-01 (1).pdf