Italo Giurizzato Junior

Boa noite Douglas, Enviei para o repositório as correções, favor atualizar os fontes e refaça os testes.

Boa noite Heronim, Você esta usando qual botão do programa exemplo?

Boa noite Lucas, Pode ser que as condições colocadas no IF estejam erradas, vou analisar com mais calma e fazer as devidas correções.

Boa noite Douglas, A primeira alteração acredito que esteja correto. No caso da segunda, temos outra alternativa, veja abaixo. No arquivo ISSDSF.ini temos esses bloco: Layout=ISSDSF VersaoDados= VersaoXML=1 NameSpace=http://localhost:8080/WsNFe2/lote Cabecalho=0 Dados=0 Se em Dados você alterar o valor de zero para 1, faz com que na mensagem de dados seja trocado todos os < e > pelo '&lt;' e '&gt;', logo não se faz necessário a segunda alteração. Já a terceira e a quarta alteração, desculpe não entendi o motivo de comentar as linhas, pois isso pode levar a um efeito colateral.

Boa noite Heronim, O certificado digital do emitente da nota esta instalado? O numero de sério do mesmo foi passado para o componente? Você esta usando o programa exemplo do ACBrNFSe para realizar os testes?

Boa noite Werner, Não se deve alterar o tipo, pois você vai emitir o DANFE e entregar ao cliente, no DANFE consta a chave e o QR-Code que por sua vez se utiliza de alguns dados da chave. Na chave consta que o tipo é 9 e depois você muda para 1 para enviar para SEFAZ, quando o cliente for consultar será informado que a nota não existe. Isso vai fazer o cliente acreditar que comprou um produto sem nota. Se a nota for rejeitada, devemos corrigir o dado errado e enviar novamente. Lembre-se que o EPEC é um evento e só devemos usar quando ocorre problema de conexão com a SEFAZ. E volto a frisar, é importante saber quais os tipos de contingência aceitos pela UF do emitente da NFC-e.

Boa noite a todos, Exatamente, os provedores que seguem a versão 2 do layout da ABRASF não possuem o Web Service para consultar a situação do Lote. Pois essa informação é retornada ao Consultar o Lote.

Boa noite, Você não acha que tem alguma coisa estranha? A cidade configurada no programa exemplo diz que o provedor é WebISS e não GovDigital.

Boa noite, Esses eventos são retornados pelo método DistribuicaoDFe dos componentes ACBrNFe, ACBrCTe e ACBrMDFe.

Boa noite, Esse LoadXML é uma procedure da sua aplicação ou do componente?

Boa noite a todos, Peço que leiam a Cartilha MDFe Nacional Agosto/2016 que se encontra disponível no link abaixo: https://mdfe-portal.sefaz.rs.gov.br/

Boa noite Claudio, Esse tópico é para tratar de questões relacionadas ao componente ACBrCTe e não do ACBrMDFe. Por favor preste mais atenção ao postar.

Boa noite Werner, Você esta fazendo errado, não se deve alterar o tipo de emissão de 9 para 1 para enviar para SEFAZ quando os problemas forem sanados. Deve-se manter o mesmo tipo. Por favor leia com muito atenção o Manual de Especificações Técnicas da Contingencia Offline versão 2.0 que esta disponível no link abaixo. Note que existe dois modos de contingência: por evento (EPEC) e Off-Line, é preciso saber qual dos dois que se a SEFAZ-Autorizadora aceita. http://www.nfe.fazenda.gov.br/portal/listaConteudo.aspx?tipoConteudo=33ol5hhSYZk=

Boa noite, Desculpe a demora, fiz a alteração que você propôs e já esta no repositório, favor realizar novos testes.

Boa noite Gabriel, Muito obrigado pela colaboração, já esta no repositório.

Boa noite Dércio, O erro ocorre quando se utiliza qual método? Você esta usando o Capicom ou OpenSSL?

Boa noite, O motivo é simples. o tipo de evento: teMDFeAutorizado tem código: 610610 e o teMDFeAutorizado2 tem código: 310610 O porque disso pergunte a SEFAZ, pois até agora não entendi o motivo.

Boa noite Douglas, O componente sofreu inúmeras alterações, e a postagem que você achou se refere ao componente antigo "Trunk" e não o atual "Trunk2". Quando fiz a migração do Trunk para o Trunk2 usei a ultima versão do componente, se alguma correção foi aplicada antes da migração ela foi considerada.

Boa noite Werner, Como assim outro XML? Por favor poste somente a chave de uma NFC-e impressa em contingência e depois a chave da mesma ao ser enviada para SEFAZ, após os problemas terem sidos sanados.

Boa noite Luiz, Como dito anteriormente o grupo <seg> só deve ser gerado e o modelo do documento for 67, caso contrario não. Se o seu negócio é transporte de cargas então o modelo do documento é o 57, sendo assim você deve configurar o componente ACBrCTe da seguinte forma: ModeloDF := moCTe; VersaoDF := ve300;

Boa noite Werner, No banco de dados é preciso ter um campo na tabela de notas que diga se o DANFE foi impresso em contingência ou não. Se foi impresso em contingência significa que não foi enviado para SEFAZ, e existe um prazo para que essas notas sejam enviadas. Se não me falha a memória é de 24 horas (uteis).

Boa noite Cesar, Já tentou alterar a série?

Boa noite Tiago, Você comparou o seu XML com o manual? Notou que antes do dhIniViagem existe o grupo <infMunCarrega>? E que é obrigatório.

Boa noite Luis, Se a placa é a mesmo, me explica como o mesmo caminhão no mesmo dia vai sair de SP e vai para MG e também vai sair de SP e vai para o RJ? Por outro lado se o caminhão vai de SP para MG e depois de MG para RJ para finalizar a entrega, então o segundo MDF-e tem que ser de MG até RJ, você não concorda?

Boa noite Luiz, O grupo <seg> que você viu no manual, note que ele esta inserido no grupo <infCTeNorm>, correto? Mas veja a descrição do grupo <infCTeNorm> : Grupo de informações do CT-e OS Normal. Eu coloque em negrito "OS" para chamar a atenção. Na versão 3.00 temos dois modelos de documentos, o 57 que é o CT-e que conhecemos e o 67 que é o CT-e OS - Outros Serviços. O modelo 57 é destinado ao transporte de carga e nesse modelo não existe mais o grupo <seg>. Já o modelo 67 é destinado para o transporte de valores, transporte de pessoas e bagagem extra, neste caso o grupo <seg> existe e da forma que você mencionou na sua última postagem.