João Paulo Müller

Sim, Juliomar. Mas o erro persiste. 2025020120250206-con-nfse-ser-tom-soap.xml 2025020120250206-lista-nfse-ser-tom-soap.xml

Olá! Estou com o seguinte erro quando faço a consulta de notas tomada no provedor ISSSaoPaulo: The page cannot be displayed because an internal server error has occurred Parece erro interno não tratado por eles, alguém já passou por esse problema? Vi relatos aqui de caracteres inválidos, porém, não encontrei nenhum caractere inválido no XML. Segue XML em anexos. Caso alguém saiba de algum canal de atendimento do provedor para que poço entrar em contato. 2024010120250120-con-nfse-ser-tom.xml 2024010120250120-con-nfse-ser-tom-soap.xml 2024010120250120-lista-nfse-ser-tom-soap.xml

Olá pessoal. Estou com o seguinte erro na consulta DFe utilizando o componente ACBrNFSeX provedor Nacional. E999 - Erro não catalogado Detalhe: Tem hora que funciona perfeitamente e hora que retorna esse erro, sem mexer em nada. A grande maioria das requisições retorna esse erro, de 20 - 50 consultas uma da certo. FIz um loop reprocessando até dar certo quando retorna esse erro, mas acredito não ser a melhor pratica. Alguém já passou por esse erro ou tem ideia do que pode ser? Segue em anexo xmls salvos pelo componente. 20241024173615-con-dfe.json 20241024173620-dfe.json

Olá prezados. Fiz um ajuste no registro C800 incluindo alguns campos que não estavam sendo importados no SPED. Segue alteração e unit em anexo. procedure TACBrSpedFiscalImportar_BlocoC.RegC800; begin with ACBrSpedFiscal.Bloco_C.RegistroC800New do begin COD_MOD := Valor; COD_SIT := StrToCodSit(Valor); NUM_CFE := Valor; DT_DOC := ValorD; VL_CFE := ValorF; VL_PIS := ValorF; VL_COFINS := ValorF; CNPJ_CPF := Valor; NR_SAT := Valor; CHV_CFE := Valor; end; end; ACBrEFDBloco_C_Importar.pas

Boa tarde, prezados. Na importação do SPED quando está importando o registro C170 e o campo quantidade por algum motivo não for preenchido o sistema dispara uma exceção: Verificando o código fonte identifiquei que para preencher o campo QTD do registro C170 está sendo utilizado a função ValorFV que retorna null caso a string estiver vazia, diferente dos demais campos float que é utilizado a função ValorF onde retorna 0 quando a string estiver vazia. Defeito QTD := ValorFV; Correção QTD := ValorF; Segue em anexo unit com a correção. Aproveitando o assunto, seria possível adicionar um tratamento de exceção para informar qual a linha que disparou erro na importação do SPED? Utilizando como exemplo esse caso que citei acima para eu identificar qual foi a linha que deu erro tive que depurar e levou um bom tempo, se tiver um tratamento de exceção que exibe a linha já ajudaria um bocado, mas seria só um complemento mesmo, acredito que corrigindo essa questão da QTD não ocorre mais problemas. ACBrEFDBloco_C_Importar.pas

Bom dia Juliomar. É na leitura do XML. Segue unit em anexo.pcnNFeR.pas

Olá Prezados, Passei por algumas situações em que o componente preenche o nItem com o valor diferente do que realmente consta na TAG det. Ao analisar o caso notei que no componente está sendo preenchido o nItem com uma ordem sequencial (I + 1), porém, acontece que há notas que são emitidas com o nItem fora dessa ordem. Isso acaba trazendo problemas quando preciso identificar o nItem em algum documento/declaração, como por exemplo, o DRCST que inclusive na validação confronta o nItem da declaração com a tag det do XML. Exemplo: // 1° item da NFe <det nItem="10"> O componente vai preencher o nItem com 1 não 10. Correção A correção é simples, já havia feito aqui na minha maquina e estava utilizando por um tempo, porém, quando atualizo o ACBr sempre perco essa alteração, portanto, se fosse possível fazer a correção direta na lib ficaria agradecido. Código atual: NFe.Det[i].prod.nItem := i + 1; Correção: NFe.Det[i].prod.nItem := nItem; Já existe uma variável (nItem) que obtém o valor correto da tag det, portanto, seria apenas utilizar essa variável.

Olá, pessoal. Realizei uma alteração no componente incluindo a natureza 118 (no118) no arquivo pnfsConversao, pois Chapecó utiliza essa natureza: 118 - ISS retido pelo tomador - Devido para Chapecó (Simples Nacional). Segue arquivo em anexo. pnfsConversao.pas

Olá pessoal. Agronômica - SC trocou provedor de Betha para Publica. Segue arquivos alterados em anexo. Cidades.INI Publica.ini

Obrigado Italo.

Olá pessoal, Estava com um problema para envio de NFs para o município de Blumenau quando cliente era do Simples Nacional . Notei que não estava sendo gerada a tag RegimeEspecialTributacao quando provedor é proSimplISSv2, porém, foi constado a necessidade de geração dessa tag também para esse provedor. Ajustei essa alteração na unit pnfsNFSeW_ABRASFv2, linha 965: // Código do repositório: if not (FProvedor in [proSigep, proiiBrasilv2, proSimplISSv2, proMegaSoft, proSiapSistemas]) then if NFSe.RegimeEspecialTributacao <> retNenhum then Gerador.wCampo(tcStr, '#6', 'RegimeEspecialTributacao', 01, 01, 0, RegimeEspecialTributacaoToStr(NFSe.RegimeEspecialTributacao), DSC_REGISSQN); Correção: //Removido proSimpliisV2 if not (FProvedor in [proSigep, proiiBrasilv2, proMegaSoft, proSiapSistemas]) then if NFSe.RegimeEspecialTributacao <> retNenhum then Gerador.wCampo(tcStr, '#6', 'RegimeEspecialTributacao', 01, 01, 0, RegimeEspecialTributacaoToStr(NFSe.RegimeEspecialTributacao), DSC_REGISSQN); Segue em anexo unit com a alteração. Desde já agradeço a atenção. pnfsNFSeW_ABRASFv2.pas

Boa tarde. Não sei te dizer, recebi esse comunicado de uma acessória, mas vou ver se descubro algo e coloco aqui.

Prezados (as) Hoje (25), o presidente do Sescon/SC juntamente com as demais entidades contábeis do Estado participaram da reunião com a SEFAZ para tratar da prorrogação da entrega do Bloco X. Após manifestações das entidades e dos próprios representantes da SEFAZ a entrega foi prorrogada para o mês de março/2021. O ato oficial sairá no início da próxima semana. Além disso, foi tratado sobre a Nota Fiscal Eletrônica de Consumidor. A norma legal de implementação sairá nos próximos dias e as empresas terão três opções para aderir. A opção escolhida é que vai definir se a empresa deverá ou não entregar o Bloco X. A opção também vai até março/2021 Bom final de semana a todos.

Bom dia Italo. Eu que agradeço.

Olá pessoal, Não sei se seria o caso de um novo tópico, vou por aqui mas caso for necessário registro um tópico novo. Estou incluindo o suporte ao município de Canoinhas e percebi que na função StrToNaturezaOperacao da unit pnfsConversao não tem as strings de natureza '17' e '18', sendo que Canoinhas utiliza essas naturezas Segue em anexo a unit pnfsConversao alterada com a inserção das natureza 17 e 18. pnfsConversao.pas RelatorioNatureza.pdf

Claro Daniel, está certo. Perdão, fiz a anlise em cima da minha própria sugestão de alteração, por isso estária incorreto... O código do repositório é esse mesmo que você comentou e vai funcionar perfeitamente. Obrigado!

Olá Daniel, agradeço o retorno. Acredito que atribuindo o valor 1 nesse else deixará a próxima condição em sequencia sem lógica: [...] if I = 0 then I := PosEx(IdAttr+'=', AXML) // offset default é 1 else I := PosEx(IdAttr+'=', AXML, I) [...] Vai funcionar da mesma forma, pois ira cair no else e chamar o terceiro parametro (I) com o valor 1, mas acredito que esse IF I = 0 não terá mais uso, pois em nenhum momento será atribuido o valor 0 a váriavel I, confere?

Opa, fiz a alteração que você sugeriu e funcionou perfeitamente em ambiente de homologação. Vou fazer um teste em produção para confirmar. Pensei que iria dar problema na rotina a baixo que identifica o final da tag docElement, por isso acabei não mexendo nessa rotina. //Função AdicionarSignatureElement URI := EncontrarURI(ConteudoXML, docElement, IdAttr); TagEndDocElement := '</' + docElement + '>'; I := PosLast(TagEndDocElement, ConteudoXML); if I = 0 then raise EACBrDFeException.Create('Não encontrei final do elemento: ' + TagEndDocElement); [...] @BigWings Obrigado pela ajuda e atenção.

Boa tarde, @BigWings. Utilizo o componente apenas para fazer a assinatura e envio do XML atráves da classe ACBrDFeSSL, não utilizo o componente ACBrNFSe por completo. Faço a assinatura da seguinte forma: A := ACBrDFE.Assinar(XML, 'Pedido></CancelarNfseEnvio', 'InfPedidoCancelamento'); Acredito que a função EncontrarURI da forma que está pode acabar gerando problemas para outros provedores em casos que não encontrar o DocElement, consequentemente a variavel I receber o valor 0 (o qual está incorreto, pois o offset deveria ser 1). Entendo que com a sugestão proposta a baixo resolveria por completo a situação, tanto do meu caso, quanto para outros cenários em que o DocElement não for encontrado, ou seja, não seria uma implementação especifica para min, mas sim uma correção de bug. [...] if (docElement <> '') then I := Pos('<'+docElement, AXML) else I := 0; if I = 0 then I := PosEx(IdAttr+'=', AXML) // offset default é 1 else I := PosEx(IdAttr+'=', AXML, I) [...]

Segue em anexo Unit alterada. ACBrDFeUtil.pas

Boa tarde, Pessoal. Encontrei onde está o problema, acontece que da revision 17491 para a revision atual teve alterações na função ExtraiURI, que passou a se chamar EncontrarURI e teve sua estrutura alterada. Encontrei o erro na seguinte rotina: [...] if (docElement <> '') then I := Pos('<'+docElement, AXML) else I := 0; //AQUI QUANDO É PASSODO O PARAMETRO I O VALOR ESTÁ 0, NO ENTANTO, O OFFSET PADRÃO SERIA 1 I := PosEx(IdAttr+'=', AXML, I); if I = 0 then // XML não tem URI Exit; [...] Pelo que pude perceber o parametro offset da função PosEx deveria inciar em 1 não 0, como na rotina acima onde é feito o Pos no docElement está retornando o valor 0 para a variavel I, está sendo passado o valor 0 para o parametro offset, o qual tem seu valor default 1. Acredito que seria incorreto atribuirmos o valor 1 para a variavel I, devido a comparação posterior para verificar se foi encontrado a URI no XML, portanto dexei a seguinte sugestão de alteração: [...] if (docElement <> '') then I := Pos('<'+docElement, AXML) else I := 0; if I = 0 then I := PosEx(IdAttr+'=', AXML) // offset default é 1 else I := PosEx(IdAttr+'=', AXML, I) [...] Peço por gentileza se os moderadores/commiters poderiam analisar essa sugestão de alteração. Grato!

Olá Prezados, Estou com erro no cancelamento da NFs de Betha. Ao cancelar a nota recebo um XML apenas com Fault String 172, pelo codigo indica um erro de assinatura. Notei que nas versões anteriores do sistema esse erro não estava ocorrendo, então voltei o ACBr para a revision que o cancelamento estava funcionando e voltou a funcionar. Voltei para a revision 17491 e consegui fazer o cancelamento normalmente. Ao analisar os XML notei a seguinte diferença na contrução do XML para cancelamento: No arquivo a esquerda esta funcionando, portanto, notei que a diferença está no <Reference URI="#canc3". Alguém poderia me orientar como faço para inserir essa URI="#canc3" na revision atual? OBS: Para esse municipio realizamos a contrução do XML manualmente e utilizamos o compontene ACBr apenas para realizar o envio e assinatura.

Obrigado pelo Retorno. Legal, assim que obter o retorno compartilhe essa informação conosco. Com relação a InfPag, você já implementou ? Como implementou ou pretende implementar? Estou pensando em disponibilizar os campos para preenchimento do usuário. Existe algum tipo de integração pra facilitar o preenchimento dessas informações?

Boa tarde pessoal, estive analisando a NT 2020.001 e pude observar que agora será gerado o CIOT automaticamente pelo MDFe. Nesse caso não será mais necessário o preenchimento das tags do grupo <infCIOT> ? Estou em dúvida pois vejo no fórum um fluxo bem grande sobre o componente ACBrCIOT. Esse componente é utilizado para geração do CIOT, confere? Mas se o CIOT será gerado automaticamente pelo MDFe então não será mais necessário o uso deste componente? Há alguma outra necessidade de uso desse componente (ACBrCIOT) ? Vi no fórum o pessoal usando o evento proprietário do veículo, porém não entendi a necessidade do mesmo. Ainda sobre o CIOT, o Italo publicou um tópico sobre a grande preocupação em gerar o CIOT, mas essa informação já não existia anteriormente através do grupo <InfCIOT> ? Outra dúvida que tenho é sobre o grupo <InfPag>, como estão tratando o preenchimento das informações deste grupo? Disponibilizam os campos para o usuário parametrizar ou há alguma integração necessária? Agradeço a atenção.

Bom dia Pessoal, Tivemos a solicitação de um cliente para enviar o valor total dos tributos ( soma das alíquotas Federal + Estadual + Municipal, conforme confirmado com Pedro - SimplISS). Analisando o componente NFSe notei que na unit pnfsNFSeW_ABRASFv2 o campo era preenchido com 0 Gerador.wCampoNFSe(tcDe2, '#22', 'ValTotTributos ', 01, 15, 1, 0.0, DSC_VINSS); Alterei para preencher com uma nova propriedade criada Gerador.wCampoNFSe(tcDe2, '#22', 'ValTotTributos ', 01, 15, 1, NFSe.Servico.Valores.ValorTotalTributos); Realizei o ajuste no componente para enviar esse campo conforme valor definido na nova propriedade que criei: Unit pnfsNFSe; .... // Alterado Linha 185 e 227 TValores = class(TObject) private FValorServicos: Currency; FValorDeducoes: Currency; ... FvValorTotalTributos: currency; public property ValorServicos: Currency read FValorServicos write FValorServicos; property ValorDeducoes: Currency read FValorDeducoes write FValorDeducoes; ... //Provedor proSimplISSv2 property ValorTotalTributos: currency read FvValorTotalTributos write FvValorTotalTributos; end; Realizei os testes e esta funcionando corretamente. Alguém poderia analisar e fazer o commit? Anexei as unit para analise. pnfsNFSe.pas pnfsNFSeW_ABRASFv2.pas