Jump to content
Notícias do ACBr

click.png

click.png

click.png

click.png

click.png

click.png

clube mobile


Cursos grátis para toda base ACBr
+ Promoção Clube Mobile para o ACBr Pro

Saiba mais

adriano santos

click.png

click.png

click.png

click.png

click.png

click.png

nickolas.deluca

Membros
  • Content Count

    16
  • Joined

  • Last visited

Community Reputation

9 Neutral

About nickolas.deluca

  • Rank
    Novato

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Realmente Lucas, agora que tu falou, percebi que vi errado... estranho que a SEFAZ ta obrigando a inserção destes campos...
  2. Sobre a latitude e longitude, pelo que eu entendi na nota técnica, os 2 são obrigatórios... especificado como [1,1] Sobre o produto predominante, a gente ta obrigando o usuário a especificar o produto predominante sempre... pelo que eu entendi da nota técnica, ele é obrigatório... especificado como [1,1] O grupo de informações de pagamento não é obrigatório somente se o pagamento for à vista, se for a prazo tu tem que informar... especificado como [0,n], ai tem uma observação dizendo: Informar somente se indPag for à Prazo.
  3. @Italo Jurisato Junior desculpa te incomodar, mas por um acaso a ACBr tem algum webservice que retorne o CEP com a latitude e a longitude? baita sacanagem da SEFAZ fazer a gente fornecer esses dados... Nas APIs que a gente usa, nenhuma delas fornece a latitude e longitude...
  4. Pois é, também foi isso que eu entendi após ler mais sobre no link enviado pelo @BigWings. Já estamos desenvolvendo as modificações nessa NT. Também aproveito para agradecer aos demais que comentaram suas duvidas, sem duvidas serão uteis para responder as nossas dúvidas também.
  5. Ok, vamos utilizar a mesma validação do CTe para o desenvolvimento então, obrigado @BigWings!
  6. Boa tarde pessoal, Estamos implementando as modificações referentes a NT2020_001 v1.03 e me surgiu uma duvida. Sobre o grupo InfLotacao, a nota técnica diz que é para somente informar esse grupo de tags quando o MDFe for de carga lotação, porém, como definir se um MDFe é de carga lotação ou não? isso não ficou bem claro pra mim. Eu li em uma das validações e entendi que o grupo deverá ser gerado quando : 1 - O modal do MDFe for moRodoviario e o tpEmit for igual a teTransportadora. 2 - O tpEmit for igual a teTranspCTeGlobalizado e o MDFe possuir apenas um DFe transportado no
  7. As vezes, de forma completamente aleatória, ao consultar o status de envio de uma nota fiscal de serviço na prefeitura de Criciúma (A prefeitura usa o ambiente da Betha Sistemas) ocorre uma exceção na IDE (Delphi 10 Seattle): O estranho é que nem os arquivos de envio e retorno do ACBr chegam a ser salvos na pasta para que possamos verificar alguma inconsistência. E também esse erro é completamente aleatório, visto que a próxima nota enviada retorna o status corretamente. Alguém sabe o que pode ser?
  8. Apenas pra finalizar o assunto, funcionou perfeitamente Italo. Muito obrigado!
  9. Boa tarde Italo, desculpa a demora pra responder. Fiz os testes, Infelizmente ainda deu erro no envio. Este foi o retorno do componente: 500 - Inativo ou Inoperante tente novamente. Notei que alguns arquivos foram gerados pelo ACBr e decidi investiga-los. O primeiro arquivo gerado foi o 20190730152717-ANe.xml e este arquivo realmente foi gerado sem o grupo do qrCodMDFe. Notei que o ACBr gerou outro arquivo logo em seguida, 20190730152717-ped-ANe.xml e dentro deste arquivo ainda existe a tag qrCodMDFe. Fiz então a simulação pelo SoapUI com os 2 arquivos, com o prim
  10. Boa tarde, Apenas acrescentando a discussão, essa foi a resposta que o pessoal da ATM nos passou por email... respondemos o email e deixamos claro que não podemos fazer alteração em documento de XML já autorizado... até agora eles não nos responderam e pelo que eu entendi essa é a resposta final deles. Alguém tem alguma sugestão de como devemos proceder?
  11. Agora faz sentido. Por precaução, vou manter a geração do QR Code apenas em homologação até que a ATM nos dê uma solução.
  12. Ótima notícia, porém agora fiquei mais confuso ainda sobre o por que o MDFe não declara com a TAG e o CTe averba normalmente... Talvez a ATM já esteja providenciando as devidas alterações? Estamos aguardando a resposta deles, em contato por telefone eles já afirmaram que a nossa solicitação não foi a única... Qualquer coisa, volto a postar aqui.
  13. Bom dia, após fazer o teste de envio sem a tag ![CDATA] verificamos que realmente deu problema na validação dos dados do XML. Utilizei o link da propria SEFAZ do RS e da erro na validação dos dados da linha 99, que é justamente a tag do qrCodMDFe, voltamos a aplicar a TAG CDATA e funciona perfeitamente. Vamos continuar o contato com o pessoal da ATM, se obtivermos retorno volto a postar aqui. Valeu pessoal!
  14. Farei este teste segunda feira, ai volto aqui a posto o resultado, até!
×
×
  • Create New...