Italo Giurizzato Junior

Boa tarde Weriton, Não existe nenhuma relação entre o método de envio com a forma de emissão. Se uma nota foi emitida em contingência Off-line, assim que os problemas forem sanados devemos envia-la para SEFAZ. O método síncrono é para quando o lote de notas possui apenas UMA nota se você tem 5 notas emitidas em Off-line você pode montar um lote com as 5 notas e enviar de uma só vez, mas neste caso o método tem que ser assíncrono.

Boa tarde Graça, Já baixei e salvei na minha pasta de Manuais e Notas Técnicas da NF-e, agora é ler nos horários de folga.

Boa tarde Fábio, Esta errado a forma de usar o DistribuicaoDFe, o correto é: ACBrNFe1.DistribuicaoDFe(31,'03341645000186','0',''); function DistribuicaoDFe(AcUFAutor: Integer; ACNPJCPF, AultNSU, ANSU: String): Boolean; O terceiro parâmetro se refere ao último NSU, por outro lado o quarto se refere a um NSU especifico. Você tem que deixar um dos dois como sendo uma string vazia. Outra coisa o certificado não esta vencido? Lembre-se que o Web Service foi disponibilizado semana passada, portanto pode não estar funcionando 100% ainda.

Rodrigo, Esses grupos servem para você detalhar a carga, dentro da Unidade de Transporte, portanto é opcional.

Jefferson, Se o provedor em questão é o Betha, se não me falha a memória houve uma atualização recente nos schemas do mesmo. Você esta utilizando os schemas mais atuais, disponibilizados junto com o programa exemplo?

Rodrigo, Existem TAGs obrigatórias que estão dentro de Grupos opcionais. Se você não informar nenhuma TAG desse Grupo o mesmo não é gerado e consequentemente o validador não vai acusar erro.

Bom dia Alessandra, Vamos as TAGs dPrev: campo 278 se refere a data prevista de entrega que pode ou não constar em uma Nota Fiscal comum de papel. campo 300 se refere a data prevista de entrega que pode ou não constar em uma NF-e. campo 325 se refere a data prevista de entrega que pode ou não constar em outro tipo de documento que não seja NF ou NF-e, por exemplo uma Carta Remessa de Material. Nos 3 casos acima a data prevista de entrega, é uma data que foi acordado ou não entre o remetente e o destinatário. Como essa data pode existir ou não nos 3 casos a TAG: dPrev é opcional. Por outro lado o campo 3 do layout - Rodoviário, se refere a data prevista de entrega que a transportadora deve estipular. Independente de algum acordo com o remente ou com o destinatário, a transportadora tem que estipular uma data de entrega, sendo assim a TAG: dPrev que fica dentro do grupo <rodo> é obrigatória.

Bom dia Jefferson, Como algumas pessoas acabam postando em lugares errados, por favor qual é o provedor?

Bom dia Rodrigo, Se você não sabe o que é obrigatório ou não em um MDF-e, a dica é simples: Portal Nacional do MDF-e: Nota Técnica 2013/004 versão 1.00a do MDFe - Outubro/2013 Nessa NT você encontra a estrutura completa do XML e a informação se é obrigatório ou não um determinado dado.

Bom dia Herivelton, Vamos ao Manual versão 2.00a do CT-e, página 134, onde temos a estrutura do XML, mais precisamente o grupo <infDoc> onde colocamos as Informações dos documentos transportados pelo CT-e, ou seja, a chave da NF-e. Na descrição do grupo diz que ele é opcional quando se tratar de Redespacho Intermediário e Serviço vinculado a multimodal, já na observação do mesmo temos: Poderá não ser informado para os CT-e de redespacho Intermediário. Nos demais casos deverá sempre ser informado. Acredito que essa informação do manual responde a sua pergunta.

Bom dia Stefan, O volume que você se refere é m3 (metro cúbico) e não litros, correto? Se sim, você leu a minha postagem acima, #2 ? Na sua postagem #4 o fragmento de XML diz que a carga possui 8 Kg (peso) e tem 0,0260 m3 (volume), ou seja estou discriminando ela em peso e volume, poderia ainda informar a quantidade de unidades. Se a minha carga é composta por 2 caixas ( 2 unidades), com peso total de 20 Kg e ocupa um volume de 1 m3, posso ter essas 3 informações dentro do grupo <infCarga>, neste caso vou ter 3 <infQ>, um para cada informação, ou seja, um para Unidades, outro para Kg e o outro para m3.

Bom dia Magrão, Exatamente, o Web Service NFeDistribuicaoDFe no momento tem por finalidade obter a lista de NF-e emitidas contra o seu CNPJ para que você possa se manifestar, bem como um resumo dos eventos e se a NF-e receber a manifestação do destinatário o mesmo vai poder realizar o Download da mesma. Com relação ao CT-e, o que esta disponível no momento é apenas o resumo dos eventos.

Boa noite Paulo, Primeiramente, por favor não post o conteúdo do arquivo e sim anexa o mesmo. Outra coisa no final o fechar aspas esta depois do fecha parenteses. qCarga=10008.0000 ,1,1)" altere para: qCarga=10008.0000" ,1,1)

Boa tarde Rodrigo, O que você esta informando que fez com que fosse solicitado o numero do lacre?

Boa tarde Alessandra, Manual versão 2.00a do CT-e, página 147. Temos a TAG <dPrev> do layout - Rodoviário, essa TAG é obrigatória.

Boa tarde Marcelo, Como dito anteriormente, se eles fornecerem um exemplo do Envelope de envio de um lote fica muito mais fácil de fazer as devidas correções.

Boa tarde Eduardo, É preciso saber qual é o provedor que atende a cidade de Gramado, alem disso se o mesmo for um provedor ainda não implementado no componente, precisamos saber se o mesmo segue ou não o padrão ABRASF.

Bom dia Eduardo, Pelo que entendi a sua aplicação já gera o XML do RPS, correto? Pois bem, sem entrar no mérito do porque de tudo isso, em vez de utilizar o componente para fazer tudo, vamos ao que possa ser uma solução: 1. Configurar o componente para a cidade desejada; 2. Executar o LoadFromFile para ler o XML gerado pela sua aplicação; 3. Executar o Assinar; 4. Executar o SaveToFile para gravar o XML assinado;

Bom dia, Se o comerciante emite a NF-e referenciando um cupom fiscal, sem duvida é a pedido do cliente. Só que a NFC-e não é um cupom fiscal e sim uma Nota Fiscal Eletrônica também, como a NF-e, com apenas uma diferença é especifica para o consumidor final. Sendo assim no meu entendimento não faz sentido uma NF-e referenciar uma NFC-e. Mas se assim desejar, é necessário informar a chave da NFC-e em refNFe.

Bom dia Fabricio, Por favor não post o conteúdo de um arquivo e sim post como anexo o arquivo. Outra coisa, você postou o conteúdo de 2 arquivos sem nenhuma separação, desta forma fica difícil identificar onde um termina e começa o outro. Um detalhe importante é sabido e basta você pesquisar no fórum sobre a SEFAZ-MG, vai encontrar diversas postagem do pessoal reclamando que vira e meche ela deixa de funcionar a contento.

Bom dia Rodrigo, Tente desta forma: ACBrMDFe.WebServices.EnvEvento.EventoRetorno.retEvento.Items[0].RetInfEvento.cStat

Rafael, Você não respondeu a minha pergunta. Pois acabo de compilar com Build a minha aplicação e nem sequer o DCU da unit ACBrCertificado foi gerado.

Cesar, Por favor atualize e teste novamente.

Bom dia, Com os ajustes que você fez, esta conseguindo emitir para a cidade de Esteio/RS através do provedor Thema? Se sim, post como somente os fontes que você alterou para que possamos disponibilizar no repositório.

Bom dia, Primeiramente, por favor procure sempre anexar o arquivo e não postar o seu conteúdo. Segundo, veja a mensagem de erro, ela se refere a dEmi - Data de Emissão e você colocou no seu arquivo: cNF=00010016 dhEmi=2014-10-04T09:44:00-03:00 tpNF=1 Como não foi informado que se tratava da versão 3.10 o Monitor esta gerando e validando como sendo a versão 2.00 O monitor ainda se utiliza dEmi como nome do campo e não dhEmi, para ambas as versões. Uma coisa é o nome do campo no arquivo INI e outra coisa é o nome da TAG no XML. Se não me falha a memória a forma correta de informar a Data/Hora de Emissão é: cNF=00010016 dEmi=04/10/2014 09:44:00 tpNF=1 Note que devemos colocar um espaço em branco entre a data e a hora. Para definir a versão do XML como sendo 3.10 devemos iniciar o arquivo INI com: [infNFe] versao=3.10 [identificacao] (...)