Italo Giurizzato Junior

Bom dia ALA, Onde você leu isso?

Bom dia Nathan Lançar como acréscimo e ratear entre os itens, não vejo problema nenhum. Mas é sempre bom conversar com dois ou mais contadores e verificar na legislação do Estado se tem alguma orientação fiscal sobre o assunto.

Boa tarde Ebnezer, A noticia sobre a Nota Fiscal Amazonense deixa claro que na NFC-e só é necessário a CPF do destinatário e mais nada. Sim, o XML da NFC-e contendo somente o CPF do destinatário será validada.

Boa tarde Santos, Primeiro já foi dito em diversas postagens que não é para instalar o ACBrGNRE pois este não esta pronto e você incluiu ele na sua instalação. Segundo os demais erros se refere ao Fortes Report, você tem ele instalado no Delphi?

Boa tarde Hugo, Se você estiver usando os fontes do Trunk2 e esta com todos eles atualizados a resposta é sim.

Boa tarde José Geraldo, Comentei a linha e já esta disponível.

Boa tarde Caetano, Nas maquinas que estão ocorrendo o erro experimente copiar para pasta que contem o executável o Midas.dll

Boa tarde Israel, No manual versão 2.00a do CT-e não traz nenhuma informação sobre o prazo para o cancelamento de um CT-e Complementar, acredito que deve ser o mesmo do Normal ou seja 168 horas a contar da data/hora da autorização.

Boa tarde Fábio, A alimentação do componente com os dados pertinentes ao transporte da carga não mudou em nada.

Boa tarde Douglas, Eu sempre compilei as minhas aplicações para o Capicom e sempre funcionou tanto para o Certificado A1 quanto para o A3. Com os novos fontes vou deixar configurado o componente para o Capicom.

Bom dia Dimas, Ao realizar o encerramento você primeiro carrega o XML do MDF-e, ou simplesmente envia o evento de encerramento? Acredito que se você: 1. Carregar o XML do MDF-e; 2. Efetuar o Encerramento; 3. imprimir o evento. Deva funcionar sem nenhum problema.

José Geraldo, Vamos fazer um teste: then begin // qrb_10_ModRodFracionado.Height := 0; <== comente esta linha qrb_11_ModRodValePedagio.Height := 0; if Versao = 103 then qrb_11_ModRodLot103.Height := 108 else qrb_11_ModRodLot104.Height := 102; end; Depois teste com Lotação e Carga Fracionada.

Bom dia a todos, Vamos analisar o código, mas precisamente a unit ACBrNFeWebServices, nas linhas 1258 e 1284 temos a chamada ao método GerarXML. Quem tem como objetivo gerar o XML com o protocolo de autorização. Mas notem ambos estão condicionados a: FPConfiguracoesNFe.Arquivos.Salvar. Caso essa propriedade esteja com o valor False, o XML não será salvo em disco, param que deseja armazena-lo no banco de dados apenas certamente vai atribuir o valor False. Isso faz com que o XML não receba o protocolo, sendo assim acredito que a solução seja remover o GerarXML da condição, por exemplo: FNotasFiscais.Items[J].GerarXML; // Gera novamente, para incluir informações de "procNFe" no XML if FPConfiguracoesNFe.Arquivos.Salvar then begin SalvarXML := (not FPConfiguracoesNFe.Arquivos.SalvarApenasNFeProcessadas) or FNotasFiscais.Items[J].Processada; if SalvarXML then FNotasFiscais.Items[J].GravarXML; end;

Leandro, Desculpe o puxão de orelha que vou lhe dar. Dentro da pasta Doctos\Manuais, temos um manual do componente e neste tem essa informação - página 11. ACBrCTe1.Enviar(ALote: Integer/String; Imprimir: Boolean = True): Boolean;

Bom dia Luis, Como não trabalho com Unix não sei lhe responder.

Bom dia Maurício, Você esta com todos os fontes atualizados?

Bom dia Sérgio, Pelo que estou entendendo a maquina que faz a emissão, ou seja, o envio a SEFAZ é a que esta no MT, correto? Porque você não altera a aplicação de tal forma que ao detectar que vai enviar um lote do PR ele mesmo faz a alteração do fuso horário? Idem para os demais processos, como o de cancelamento.

Bom dia Leandro, O método Enviar possui dois parâmetros: Numero do lote e Imprimir, sendo que este segundo o valor padrão é True se você atribuir o valor False o DACTE não será impresso. ACBrCTe1.WebServices.Envia(NumLote, False);ACBrCTe1.Conhecimentos.ImprimirPDF;

Bom dia José Geraldo, Você chegou a realizar testes com carga Fracionada e Lotação e qual foi o resultado?

Bom dia Gilberto, Noto conforme a segunda imagem onde é possível incluir os documentos fiscais eletrônicos que o emitente se trata de uma transportadora (primeiro campo no canto superior esquerdo da imagem) sendo assim os documentos que devemos incluir no MDF-e tem que ser CT-e e não NF-e como você esta fazendo. Quando o emitente for uma transportadora o componente somente incluir CT-e, por outro lado se o emitente não for uma transportadora o componente somente incluir NF-e.

Boa tarde a todos, Por favor atualize os fontes e compilem novamente.

Boa tarde Emerson, Por favor atualize os fontes e teste novamente.

Bom dia Sidnei, Quando você diz que o seu cliente tem XML autorizados mas sem a assinatura, não ficou claro se esses XMLs foram emitidos pelo seu cliente ou são XML que ele recebeu dos fornecedores dele. Se são XMLs de fornecedores, a coisa esta estranha, pois neste caso eles não tem validade jurídica, pois conforme a legislação vigente o destinatário no caso o seu cliente tem o direito de receber o XML assinado e com o protocolo da SEFAZ que confere que o mesmo foi autorizado. Neste caso ele deve solicitar ao fornecedor o XML assinado e protocolado, ou conforme o Juliomar disse, com o DistribuicaoDFe é possível obter a lista de notas emitidas contra o CNPJ do destinatário, fazer a manifestação (eventos) das notas e novamente realizar uma nova consulta através do DistribuicaoDFe. Teremos como resposta nessa segunda consulta o XML completo da NF-e, ou seja, assinado e protocolado. Agora se o XML que você se refere foi emitido pelo seu cliente, talvez seja necessário remover o protocolo de autorização para poder carregar ele, para que seja possível realizar a assinatura e por fim realizar uma consulta a SEFAZ para obter o protocolo de autorização.

Bom dia ALA, Se o transporte esta sendo realizado por um veiculo simples, no caso uma VAN, então porque a sua aplicação esta adicionando um veiculo reboque na lista? No MDF-e temos que ter um e somente um veículo tração e opcionalmente podemos ter de 1 até 3 veículos reboques. Favor rever a sua rotina que alimenta o componente. Ou o usuário sem querer querendo incluiu um reboque e não passou os dados dele, como a placa por exemplo. É interessante você ter um cadastro de veículo e nesse cadastro ter uma informação se ele comporta um reboque ou não, no caso da VAN a informação seria NÃO. com base nessa informação ao selecionar o veículo VAN a aplicação impede que seja informado o reboque.

Bom dia Luis, O componente não gera o XML com quebras de linhas conforme XML da sua primeira postagem. Note que o arquivo *-procEventoCTe é composto pelos grupos: <eventoCTe> e <retEventoCTe>, no primeiro temos a TAG <descEvento> com o seguinte conteúdo: Carta de Correcao (sem cedilha e acento) e no segundo temos a TAG <xEvento> com o conteúdo: Carta de Correção (com cedilha e acento). O grupo <eventoCTe> é gerado pelo componente e enviado para SEFAZ, por outro lado o grupo <retEventoCTe> é gerado e retornado pela SEFAZ, o componente por sua vez se encarrega de unir esses dois grupos conforme orientação do Manual versão 2.00a do CT-e página 108 - Item 12.4 Acredito que cabe aplicarmos um filtro na resposta da SEFAZ, ou seja, substituir cedilha por C e as vogais acentuadas por não acentuadas. Agora no que diz respeito a quebra de linhas inseridas no XML não faço a menor ideia do que possa estar ocorrendo. Sei que o outlook costuma fazer essas quebras, mas no seu caso, realmente não sei o que pode estar ocorrendo. No arquivo que contem as quebras de linha foi salvo na mesma maquina que foi salvo o que não contem as quebras? O que contem as quebras foi aberto e posteriormente salvo (sem querer) através de algum programa?