João Paulo Müller

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

Boa tarde. O WS de migração deles possui apenas o ambiente de Produção, já os demais WS possui os dois ambientes (Homologação e Produção).

Boa tarde Ernesto, Esse defeito é em ambiente de homologação, produção ou ambos?