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

igor.oliveira3

Membros
  • Content Count

    44
  • Joined

  • Last visited

Community Reputation

8 Neutral

About igor.oliveira3

  • Rank
    Membro

Recent Profile Visitors

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

  1. Sefa MG já está fazendo a validação corretamente quando se tem mais de uma NF-e vinculada. Transmiti aqui normalmente
  2. Boa tarde, BigWings. É porque em testes já foram enviados vários comprovantes de entrega para esse mesmo CT-e, transmitidos e cancelados. Quando se emite um segundo comprovante com o mesmo nSeqEvento dá rejeição de duplicidade, mesmo que o primeiro que foi enviado tenha sido cancelado.
  3. Boa tarde. O XML está sendo gerado pelo ACBr, gerou a tag vazia porque passei o '' como valor. Mas tentei das duas formas gerando a tag vazia ou nem gerando a tag. Só é aprovado quando se tem uma chave NF-e preenchida mesmo. Porém pelo que eu entendi já era esperado segundo essa regra, quando é um CT-e tipo NORMAL sempre deve ter pelo menos uma NF-e vinculada a ele, quando é de outro tipo nem é necessário um comprovante de entrega. Me deparei com um segundo problema, nesse mesmo assunto. Pela especificação para cada chave NF-e vinculada, deve-se gerar um grupamento -infEntrga>
  4. @JeannyPaiva, quando gerei um comprovante de um CT-e que não possui NF-e (Sem chave NFe) , não geramos o grupamento infEntrega, e assim deu rejeição 999. Aconteceu isso com você?
  5. Bom dia, Italo. Sim a empresa possui tanto NF-e quanto CT-e. De início a Sef - MG reconheceu que havia um erro na validação mesmo, e que havia corrigido no servidor de homologação. Então fiz a transmissão novamente e o retorno foi o 873 mesmo a data do hash estando superior a data de transmissão do CT-e, como exigido na NT. Nesse caso já reportei novamente a eles e estou aguardando respostas. Ainda vou testar o cenário que a Jeanny falou para verificar se comigo também vai voltar a dar a rejeição 999.
  6. Jeanny, tive o retorno hoje também. Deixou de dar o erro 999, na minha situação passou a dar rejeição 873, relacionada a data/hora de geração da hash de entrega. Porém, está atendendo as regras da NT. Enviei o questionamento sobre tal, e estou aguardando reposta novamente.
  7. Bom dia @BigWings, entrei em contato agora pela manhã, mas o canal de dúvidas técnicas é apenas o e-mail. Então enviei o e-mail relatando a situação e anexando os xml, porém eles dão um prazo de 48 horas para a resposta.
  8. Achei que fosse a tag de chave NFe vazia mas gerei esse e tive o mesmo retorno 1-ped-eve.xml
  9. Boa tarde, estou enviando o Comprovante de entrega eletrônico(CT-e) no ambiente de homologação para o estado de Minas Gerais, porém o retorno que tenho é 999 - Erro não catalogado. Segue em anexo os arquivos xml de envio e resposta 2-eve.xml 2-ped-eve.xml
  10. Ao enviar Ct-e em ambiente de homologação está sendo retornado sempre o código "217 - Lote em processamento". Não há um retorno de rejeição nem de aprovação. Alguém está passando por isso? Transmissão no estado de Goiás e usuário transmitindo normalmente em ambiente de produção
  11. É isso mesmo que o Hugo falou. Porém, mesmo ajustando tudo conforme definido pelo provedor, continuo com o mesmo erro. Minha alternativa foi gerar e assinar o xml pelo ACBr e transmitir usando WSDL importer
  12. Italo, gerando com o envelope já atual eu continuo tendo o seguinte problema utilizando o ACBr. Lembrando que o webservice para Rio Verde - GO é http://rioverde.centi.com.br/servicos/wcf/service/servicenfse.svc?ws --------------------------- Debugger Exception Notification --------------------------- Project SAgrVFat.exe raised exception class EACBrWinReqResp with message 'Erro: Requisição não enviada. Erro: 0 - BWBMAQMDoBATDjAyNDM1MzAxMDAwMTczoDgGBWBMAQMEoC8TLTIwMTAxOTczNTc4MDAxODkx MDQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMKAXBgVgTAEDB6AOEwwwMDAwMDAwMDAwMDAw DQYJ
  13. Bom dia. Consegui realizar a transmissão com resposta de sucesso com o seguinte envelope em anexo. Realizei o teste sem usar o ACBr xmlTesteSucesso.xml
  14. Boa tarde, Italo. Criei o tópico pelo fato de que nem sempre o provedor que está no Cidades.ini é o que o município está utilizando atualmente. Isso aconteceu com Sorriso-MT recentemente, o qual eu iniciei os testes de transmissão utilizando o provedor descrito do Cidades.ini. Passamos algum tempo tentando fazer funcionar até entrar em contato com a Agili e descobrir que o provedor não era o correto. O que acontece com Patos de minas é que no Cidades.ini o provedor está como ISSIntel , porém o manual disponível do portal da prefeitura remete ao provedor Governa. Então antes de inici
×
×
  • Create New...