Jump to content
Notícias do ACBr

click.png

click.png

click.png

click.png

click.png

click.png

click.png

click.png

click.png

consultoria_sticker.png

Conteúdo para desenvolvedores
 ao vivo de terça a quinta!
Saiba mais

dev.png

logo_acbr_paygo.png

TEF ACBr PayGo
Seja um revendedor e ofereça uma solução completa para seu cliente.


Saiba mais

beneficios.png

João Paulo Müller

Membros
  • Content Count

    325
  • Joined

  • Last visited

  • Days Won

    2

João Paulo Müller last won the day on November 5 2017

João Paulo Müller had the most liked content!

Community Reputation

88 Excellent

3 Followers

About João Paulo Müller

  • Rank
    Membro Ativo
  • Birthday 01/01/1991

Profile Information

  • Sexo
    Masculino
  • Location
    Rio do sul - SC

Recent Profile Visitors

1,691 profile views
  1. 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, s
  2. Bom dia Juliomar. É na leitura do XML. Segue unit em anexo.pcnNFeR.pas
  3. 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="
  4. 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
  5. Olá pessoal. Agronômica - SC trocou provedor de Betha para Publica. Segue arquivos alterados em anexo. Cidades.INI Publica.ini
  6. 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 <> retNenhu
  7. Boa tarde. Não sei te dizer, recebi esse comunicado de uma acessória, mas vou ver se descubro algo e coloco aqui.
  8. 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
  9. 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
  10. 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!
  11. 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?
  12. 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); [...] @Big
  13. 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
×
×
  • Create New...