Ir para conteúdo
  • Cadastre-se

MFincotto

Membros
  • Total de ítens

    103
  • Registro em

  • Última visita

Contact Methods

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

Últimos Visitantes

1.491 visualizações

MFincotto's Achievements

Enthusiast

Enthusiast (6/14)

  • First Post
  • Collaborator Rare
  • Conversation Starter
  • Week One Done
  • One Month Later

Recent Badges

36

Reputação

4

Community Answers

  1. @EMBarbosa Fiz algumas refatorações no projeto BlocoX, retirada de alguns fields não utilizados de acordo com o manual. Analise para commit, por gentileza. Abraços. ACBrBlocoX.rar
  2. Pessoal, boa tarde. SEFAZ validando o valor do ICMS desonerado sempre maior que zero, porém, quando não tenho base ou quando o valor do produto é 0,01 centavo, por exemplo, teria que enviar o valor do icms desonerado zerado, porém a Sefaz está validando. Informando 0,01 notamos que a NFC-e é autorizada. Alguém está procedendo da mesma maneira tendo se deparado com uma situação semelhante?
  3. Boa tarde pessoal, MG fora mesmo?
  4. Bom dia pessoal. Realmente MG está complicado. Estou aplicando aqui os contornos feitos pelo Ítalo, entretanto devemos forçar o estado a reconhecer a caca e se adequar aos padrões nacionais.
  5. Bom dia, como vai? Está parecendo caractere inválido não escapado, de uma olhadinha:
  6. 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.
  7. 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.
  8. 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.
  9. 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
  10. Verifique se não está enviando o cNF igual o nNF na chave de acesso.
  11. 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.
  12. 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?
  13. Bom dia. Conseguiu resolver? Se não, poste aqui o retorno da SEFAZ novamente, por favor.
  14. @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?
  15. 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
×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.