Jump to content

MFincotto

Membros
  • Content Count

    99
  • Joined

  • Last visited

Community Reputation

34 Excellent

About MFincotto

  • Rank
    Membro
  • Birthday 01/14/1989

Contact Methods

  • Website URL
    https://linkedin.com/in/marcos-a-fincotto/

Profile Information

  • Sexo
    Masculino
  • Localização
    Ribeirão Preto - SP

Recent Profile Visitors

530 profile views
  1. Boa tarde. NFC-e não tem. Eles fazem para NF-e, NFC-e, se fizerem, devem requerer que o cliente envie o XML para eles de alguma forma no momento da emissão.
  2. Rafael, eu concordo com você que a parametrização demasiada pode ocasionar defasagem no código. Porém, eu acredito que como tudo, este ponto pode demandar uma flexibilidade, pois é uma alteração tecnicamente simples, porém pode ocasionar transtornos para os desenvolvedores com seus clientes. Acredito que neste caso cabe uma tratativa.
  3. Boa tarde a todos. De acordo com a NT 2019.001, será implementada a validação do campo cNF: cNF não pode ser igual a nNF (id: B08). Foi implementado no componente o método ValidarCodigoDFe dentro da geração da chave de acesso na unit ACBrDFeUtil, tudo muito bem explicado aqui: Ví relatos de algumas pessoas passando por dificuldade com este ponto, pois atualizam seus fontes e geraram uma versão de seus produtos já com a nova validação. Entretanto, como somente o ambiente de homologação está realizando esta validação, as chaves geradas de forma "errada" estão caindo na validação, visto que ainda podem não ter sido reimplementadas. Sendo assim, segue uma dica que realizei para contornar sem impactar em uma nova atualização: function GerarChaveAcesso(AUF: Integer; ADataEmissao: TDateTime; const ACNPJ:String; ASerie, ANumero, AtpEmi, ACodigo: Integer; AModelo: Integer = 55; const AValidarCodigoNumerico: Boolean = False): String; var vUF, vDataEmissao, vSerie, vNumero, vCodigo, vModelo, vCNPJ, vtpEmi: String; begin if AValidarCodigoNumerico then begin if ACodigo > 0 then if not ValidarCodigoDFe(ACodigo, ANumero) then raise EACBrDFeException.Create('Código Numérico inválido, Chave não Gerada'); if ACodigo <= -2 then raise EACBrDFeException.Create('Código Numérico inválido, Chave não Gerada'); end; if ACodigo = -1 then ACodigo := 0; if ACodigo = 0 then ACodigo := GerarCodigoDFe(ANumero); vUF := Poem_Zeros(AUF, 2); vDataEmissao := FormatDateTime('YYMM', ADataEmissao); vCNPJ := PadLeft(OnlyNumber(ACNPJ), 14, '0'); vModelo := Poem_Zeros(AModelo, 2); vSerie := Poem_Zeros(ASerie, 3); vNumero := Poem_Zeros(ANumero, 9); vtpEmi := Poem_Zeros(AtpEmi, 1); vCodigo := Poem_Zeros(ACodigo, 8); Result := vUF + vDataEmissao + vCNPJ + vModelo + vSerie + vNumero + vtpEmi + vCodigo; Result := Result + Modulo11(Result); end; Criamos um parâmetro com valor default para validar a chave somente quando necessário, na chamada pode ficar assim: GerarChaveAcesso(CUF, DATAEMISSAO, DOCUMENTO, SERIE, NRONF, TIPOEMISSAO, CNF, MODELO, AMBIENTE = taHomologacao); Enfim, saliento que entendo a grande importância desta implementação sem a validação do ambiente, é somente uma dica para quem está meio perdido com essa alteração e quer manter uma retrocompatibilidade com fontes atualizados.
  4. Bom dia. Eu acredito que não foi um problema no componente e sim um possível problema de configuração, rede, etc. Tenho clientes que geram mais de 8 mil notas /dia e isso não ocorre. Faça uma análise mais detalhada. Para obter o XML, gere novamente e mande assinar, logo depois realize uma consulta para obter o protocolo de envio. Caso contrário, que eu saiba, ainda não existe um WS para download do XML da NFC-e. Abraços
  5. Verifique se não está enviando o cNF igual o nNF na chave de acesso.
  6. Concordo, porém em relação a fraudes e acesso indevido deveria ficar por conta da SEFAZ. Mais uma vez jogando a responsabilidade para nossas costas.
  7. Gostaria de levantar uma hipótese. Utilizando essa função, uma eventual necessidade de reconstrução da chave de acesso se tornaria impossível. Alguém pensou em utilizar o cNF sendo o nNF + 1?
  8. Bom dia. Conseguiu resolver? Se não, poste aqui o retorno da SEFAZ novamente, por favor.
  9. @fdsilva.desenv bom dia. Putz, realmente, ví UF errada. AM já está validando as informações do responsável técnico. O XML que não passou foi emitido offline e agora está sendo enviado certo?
  10. Pelo que ví são dois clientes diferentes. Verifique se o cliente da NF que não passou está habilitado. Outro ponto: As informações do responsável técnico para a UF 33 (RJ) não estão sendo validadas. Você pode, neste caso, omitir as informações. De acordo com as últimas informações que tenho, os estados que estão ou estariam validando essas informação são: AM, MS, PE, PR, SC e TO
  11. Boa tarde, tudo bem? Validei esse XML e olha o retorno: 203 - [Simulacao] Rejeicao: Emissor nao habilitado para emissao da NF-e Outro ponto: Tome cuidado ao postar dados em produção como você fez. Nós sempre tomamos o cuidado de mascarar essas informações que, para análise são irrelevantes. Grande abraço
  12. Boa tarde a todos. - Novos ajustes e inclusão do cancelamento no Demo. ACBrBlocoX_V3.zip
  13. Boa tarde pessoal. - Novos ajustes - Demo com novos ajustes AcbrBlocoX_V2.zip
  14. Bom dia, mais alguns ajustes realizados. ACBrBlocoX.zip
×
×
  • Create New...