Italo Giurizzato Junior

Bom dia Antonio, Assim que eu tiver um retorno do pessoal da RFB/SERPRO lhe informo aqui.

Bom dia Antonio, Se foi eu lhe peço desculpas. Mas temos que analisar todos os fontes com alterações enviados por vocês, pois tivemos casos de aceitar colaboração e esta acabou gerando um efeito colateral com outros provedores. Outra coisa ao enviar alguma contribuição, envie somente a unit alterada e procure sempre fazer a alteração com os fontes atualizados. Você concorda que a função SiglaISO2ToCodIBGEPais retorna -1 caso não encontre a tag cPaisPrestacao não exista no XML. Desta forma ao tentar gerar novamente o XML, vai acabar gerando a tag com o valor ZZ. Se alterarmos a função para retornar o valor zero em vez de -1, não vamos precisar do IF que você incluir na unit que faz a leitura do XML. Desta forma resolvemos esse problema e se amanhã aparecer outro provedor que se utilize da mesma função não teremos que lembrar de colocar o IF, pois não teremos o mesmo problema que você esta enfrentando. Mais uma vez muito obrigado pelos testes, analise e apontar uma solução para o problema. Toda colaboração é sempre bem vinda, pois todos nós saímos ganhando. Você encontrou um erro, outros podem encontrar outros erros, se todos vão nos passando esses erros e uma possível solução, repito todos saem ganhando, pois o componente se torna a cada dia mais robusto.

Bom dia Rodrigues, Esse XML contem quebra de linha em cada tag que compõe o XML e ele esta identado.

Bom dia Lindomar, Pelo que me recordo o campo dPrev tem que ser um campo cujo tipo seja numérico de ponto flutuante. Devemos informar o valor zero quando não queremos informar uma determinada data.

Bom dia Lindomar, Como não sou eu que cuido da Lib, vou passar esse caso para o pessoal, eles vão retornar aqui mesmo neste tópico com uma resposta mais assertiva.

Felipe, Muito obrigado pela informação, já inclui na minha lista de tarefas. TK-4416

Boa tarde Lindomar, O ACBr se utiliza do caractere ";" para indicar uma quebra de linha, uma vez que o \r\n (posso estar escrevendo besteira) no XML vai se tornar um #13#10 e esses caracteres vão ser removidos automaticamente antes do XML ser assinado.

Boa tarde Antonio, Não seria o caso de mudar a função abaixo? function SiglaISO2ToCodIBGEPais(const t: string): Integer; var i: Integer; begin Result := -1; <==== mudar aqui para zero for i := Low(SiglaISO2Pais) to High(SiglaISO2Pais) do begin if SiglaISO2Pais[i] = t then begin Result := CodigoIBGEPais[i]; exit; end; end; end;

Boa tarde Antonio, Já passei para o pessoal da RFB e do SERPRO o problema de discordância entre o Manual e o Schema. Eles tem que dar um jeito nisso, pois Porto Alegre em outubro quem é autônomo vai ser obrigado a emitir pelo padrão nacional e em novembro as empresas ME EPP. Imagina todo esse povo enviando notas com informações erradas.

Boa tarde Silva, Através do programa exemplo tente enviar o RPS usando o botão [Enviar um RPS (Unitário)], apesar de existir o serviço de envio em lote no modo síncrono ele pode estar com problemas.

Boa tarde Felipe, Qual é o provedor?

Boa tarde Rodrigues, Infelizmente não temos essa informação, o componente sempre adota o ";", mas podemos fazer com que ele mude o caractere de forma automática ao gerar o XML a partir do momento que alguém descobre e nos conte qual é o caractere usado. Tem um provedor que utiliza os caracteres #10 e #13, mas eles são removidos do XML antes da sua assinatura, se o provedor se utiliza deles não vai ter solução.

Boa tarde Adilson, Você esta fazendo confusão. Informando o valor 5 a esse campo você esta dizendo que o Regime Especial de Tributação Municipal é Profissional Autônomo, que ao meu ver não tem nada haver com o MEI. Para gerar essa tag devemos alimentar o campo: NFSe.RegimeEspecialTributacao E ele aceita os seguintes valores: retNenhum, retCooperativa, retEstimativa, retMicroempresaMunicipal, retNotarioRegistrador, retISSQNAutonomos, e retSociedadeProfissionais. A tag opSimpNac que é alimentada com o conteúdo do campo: NFSe.OptanteSN pode receber os seguintes valores: osnNaoOptante, osnOptanteMEI, osnOptanteMEEPP.

Lindomar, Eu não trabalho com C# somente com Delphi logo não sei como ele vai passar esse valor para a Lib para que o XML seja gerado. No Delphi temos o tipo: TpcteTipoDocumento = (tdDeclaracao, tdDutoviario, tdCFeSAT, tdNFCe, tdOutros); as funções de conversão: function TpDocumentoToStr(const t: TpcteTipoDocumento): string; begin result := EnumeradoToStr(t, ['00', '10', '59', '65', '99'], [tdDeclaracao, tdDutoviario, tdCFeSAT, tdNFCe, tdOutros]); end; function StrToTpDocumento(out ok: boolean; const s: string): TpcteTipoDocumento; begin result := StrToEnumerado(ok, s, ['00', '10', '59', '65', '99'], [tdDeclaracao, tdDutoviario, tdCFeSAT, tdNFCe, tdOutros]); as linhas responsáveis por gerar as tags: Gerador.wCampo(tcStr, '#320', 'tpDoc ', 02, 002, 1, TpDocumentoToStr(CTe.infCTeNorm.infDoc.InfOutros[i].tpDoc), DSC_TPDOC); Gerador.wCampo(tcStr, '#321', 'descOutros', 01, 100, 0, CTe.infCTeNorm.infDoc.InfOutros[i].descOutros, DSC_OUTROS); Gerador.wCampo(tcStr, '#322', 'nDoc ', 01, 020, 0, CTe.infCTeNorm.infDoc.InfOutros[i].nDoc, DSC_NRO); Gerador.wCampo(tcDat, '#323', 'dEmi ', 10, 010, 0, CTe.infCTeNorm.infDoc.InfOutros[i].dEmi, DSC_DEMI); Gerador.wCampo(tcDe2, '#324', 'vDocFisc ', 01, 015, 0, CTe.infCTeNorm.infDoc.InfOutros[i].vDocFisc, DSC_VDOC); Gerador.wCampo(tcDat, '#325', 'dPrev ', 10, 010, 0, CTe.infCTeNorm.infDoc.infOutros[i].dPrev, DSC_DPREV); Uma informação importante é que o grupo infOutros é uma lista, ou seja, o XML do CT-e pode conter vários grupos infOutros, no manual diz que podemos ter N ocorrências, no componente limitamos em 990. Essas classes do C# vão ter que criar a lista InfOutros e alimentar os seus campos corretamente, pode ser ai que a coisa esteja pegando.

Boa tarde Lindomar, Primeiramente temos que ter em mente que um CT-e só pode ter o grupo infNF ou infNFe ou infOutros, ou seja, somente um desses 3 grupos podem estar presentes no CT-e. Vamos tomar como base o infOutros: Analisando o manual temos que somente o campo tpDoc é obrigatório e os valores validos são: 00 - Declaração; 10 - Dutoviário; 59 - CF-e SAT; 65 - NFC-e; 99 - Outros Se for 99 devemos alimentar o campo descOutros. Pela imagem que você anexou o valor atribuído a tpDoc é "declaracao", talvez seja esse o problema, no meu entendimento deveria ser "00"

Bom dia Antonio, Temos tomar cuidado ao alterar uma função definida no ACBrNFSeXConversao, pois se ela é usada por mais de um provedor, pode gerar um efeito colateral. Outra coisa, segundo os schemas temos o seguinte: <xs:simpleType name="TSTribISSQN"> <xs:annotation> <xs:documentation> Tributação do ISSQN sobre o serviço prestado: 1 - Operação tributável; 2 - Exportação de serviço; 3 - Não Incidência; 4 - Imunidade; </xs:documentation> </xs:annotation> <xs:restriction base="xs:string"> <xs:whiteSpace value="preserve"/> <xs:enumeration value="1"/> <xs:enumeration value="2"/> <xs:enumeration value="3"/> <xs:enumeration value="4"/> </xs:restriction> </xs:simpleType> O que tudo indica uma discordância com o manual. Vou questionar o pessoal da RFB e da SERPRO para saber qual é o correto.

Bom dia Bruno, Caso você tenha acesso a um contador seria interessante questionar ele. No meu entendimento é a pessoa mais indicada para nos informar qual seria a regra que devemos seguir para definir quando a tag deve ser gerada ou não. Você acha que consegue isso?

Bom dia Elison, Muito obrigado pela colaboração, já inclui na minha lista de tarefas para atualizar o INI e checar esse problema. TK-4413

Bom dia Antonio, Favor anexar a unit alterada para que possamos analisar. Desde já muito obrigado pela colaboração. Outra coisa importante: No que se refere ao prestador no DPS informe somente o CNPJ, fone, email e o grupo regTrib com os campos opSimpNac e regEspTrib.

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

Bom dia Victor, Você pegou os fontes de onde? Repito a alteração foi enviada no dia 30/08/2023 para o SVN oficial do Projeto ACBr.

Bom dia Dinael, Com essa configuração era para salvar os arquivos XML sim. Por favor faça os testes usando o programa exemplo.

Bom dia Antonio, Não fiz nenhuma alteração no fonte de impressão do DANFSE e sim em outras units. Alguns provedores permitem que seja informado uma lista de serviços, ao checar notei que alguns deles não tem uma tag com o total, somente quantidade e valor unitário, então inclui a linha para calcular o total. Com isso já deveria resolver o problema de mostrar o valor total. Eu não trabalho com o Fast somente com o Fortes, logo não tenho como testar, para saber se em algum momento ele esta zerando o valor total. Outra coisa: 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.

Bom dia Regis, Me desculpa, mas este tópico esta sendo tratado problemas com o provedor IPM. Favor criar um novo tópico para tratarmos do provedor Tecnos. Outra coisa, o XML do RPS não ajuda em nada, precisamos do XML (soap) de retorno tanto do envio quanto da consulta. Por favor crie um novo tópico e anexe junto esses arquivos. Desde já muito obrigado pela compreensão.

Bom dia Gladston, Primeiramente, a comparação de uma emissão via site com uma via webservice é complicada, pois via site você só o XML da NFS-e, já via webservice você tem o XML do RPS e da NFS-e. Logo não da para comparar o XML da NFS-e do site com o XML do RPS gerado e enviado para o WebService. Por conta disso reforço o pedido. Pega o XML de um RPS gerado e enviado pelo emissor antigo e compare com o XML do RPS gerado pelo emissor novo. Eu entendo que o emissor que você se refere é a sua aplicação, correto?