Jump to content

click.png

click.png

click.png

click.png click.png click.png

click.png

click.png

click.png

click.png

click.png

click.png

click.png

click.png

click.png

nickolas.deluca

Membros
  • Posts

    16
  • Joined

  • Last visited

Recent Profile Visitors

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

nickolas.deluca's Achievements

Apprentice

Apprentice (3/14)

  • First Post
  • Collaborator Rare
  • Week One Done
  • One Month Later
  • One Year In

Recent Badges

9

Reputation

  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 grupo infDoc. O meu entendimento está correto? São essas duas regras que hoje classificam um MDFe como carga lotação? Agradeço pela atenção e aguardo ansiosamente pelo retorno.
  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 primeiro (20190730152717-ANe.xml) o webservice nos retorna o código de declaração, tudo certinho. Já quando eu faço o envio do segundo arquivo (20190730152717-ped-ANe.xml) o webservice retorna esse erro: <faultstring xsi:type="xsd:string">error in msg parsing: XML error parsing SOAP payload on line 8: Mismatched tag</faultstring> Por que o ACBr gerou esse segundo arquivo? imagino que seja ele que o ACBr esteja enviando e por isso gera o erro... Inclui os 2 arquivos gerados pelo componente, obviamente, alterei os dados de acesso na ATM, fora isso está exatamente como foi enviado e feito os testes. Alguma ideia de como resolver essa situação?
  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...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.