Italo Giurizzato Junior

Boa tarde Anderson, A resposta é não para todas as suas perguntas. A carga foi enviado ao destinatário? Se não foi, a transportadora deve enviar por e-mail o XML "*-procEventoCTe.xml referente ao cancelamento do CT-e, tanto para o remetente quanto para a contabilidade. Para que ambos tenham ciência e tomem as providencias referente ao cancelamento do CT-e em questão.

Boa tarde José, Que tipo de emitente é? Qual é o valor que você esta atribuindo a Ide.tpEmit ?

Boa tarde Luciano, Isso realmente pode ser um problema no ACBrNFeMonitor, é preciso analisar o código dele, para identificar o problema.

Boa tarde Luiz, Quando escrevemos a rotina para envio da carta de correção, temos que incluir esta linha: infEvento.tpEvento := teCCe; o teCCe é um enumerador que o Juliomar se refere, existe um enumerador para cada tipo de evento. E o valor do enumerador teCCe é 110110 e sempre será até que a SEFAZ resolva alterar que acredito ser difícil. Portanto o que o Juliomar e eu queremos dizer que, não faz sentido você querer ler o XML de uma CC-e só para ler esse código e armazena-lo no banco de dados por exemplo. Esse código não é um numero gerado pela SEFAZ e sim uma constante que identifica o tipo de evento a ser enviado. Para a SEFAZ 110110 se trata de uma CC-e, para nós desenvolvedores em vez de atribuir esse código, usamos o enumerador teCCe que significa: tipo de evento CC-e. Lembrando que o componente se encarrega de utilizar o código correspondente, ou seja, 110110 ao gerar o XML referente a CC-e. Espero ter ficado claro.

Boa tarde Fernando, De todos os provedores implementados no componente, somente um ou dois alteraram o layout da ABRASF incluindo a TAG OutrasInformacoes na estrutura do RPS. Por via de regra na estrutura do RPS não existe a TAG: OutrasInformacoes onde poderíamos estar colocando alguma informação extra, uma observação como você queira chamar. Sendo assim a resposta é não. Se você alimentar essa propriedade, como dito, para a maioria dos provedores ela será descartada ao gerar o XML do RPS. Ela só terá alguma informação caso o XML da NFS-e tiver essa TAG preenchida pelo provedor, sendo assim, essa TAG é de uso da prefeitura e não do emitente.

Boa tarde Rodrigo, rodo.veicTracao.prop.CNPJCPF:= CDSMdfePaiPROPR_CNPJCPF.AsString; (...) As propriedades referentes ao proprietário só devem ser alimentadas caso o proprietário do veiculo não seja o próprio emitente do MDF-e. Pela mensagem de erro de validação o conteúdo de CDSMdfePaiPROPR_CNPJCPF.AsString deve estar vazio. O componente gera o grupo <prop> mediante as seguintes condições: if (MDFe.Rodo.veicTracao.Prop.CNPJCPF <> '') or (MDFe.Rodo.veicTracao.Prop.RNTRC <> '') or (MDFe.Rodo.veicTracao.Prop.xNome <> '') then begin Gerador.wGrupo('prop', '#32'); (...) end; Você deve ter alimentado o RNTRC diferente de vazio e não alimentou o CNPJCPF, consequentemente o componente gerou o grupo <prop> e o validador acusou o erro. Lembre-e que o RNTRC (do proprietário) só deve ser informado quando o veiculo não pertence ao emitente do MDF-e. Cuidado para não confundir com o RNTRC do modal rodoviário: Rodo.RNTRC := sRNTRC; Espero ter ajudado.

Boa tarde, A mensagem diz que o elemento InscricaoEstadual é inesperado, ou seja, o validador não estava esperando encontrar essa TAG e sim InscricaoMunicipal. Ou a rotina que gera o XML esta gerando essa TAG indevidamente ou você esta utilizando um schema que não é do provedor Betha ou o schema esta desatualizado. Utilize os schemas que acompanham o programa exemplo.

Boa tarde Marcos, Segundo o manual devemos efetuar o encerramento toda vez que a carga for entregue ou se houver uma alteração na composição da carga ou veículo. Uma pergunta: quem vai realizar a entrega dessa carga agora? Se vai ser o mesmo motorista com o mesmo caminhão e não vai haver alteração na carga, não vejo motivo de efetuar o encerramento, até que a carga seja entregue. Agora se vai ocorrer a troca do caminhão, deve-se encerrar e emitir um novo.

Bom dia Felipe, Se ao solicitar o cancelamento é retornado um erro acusando que o CNPJ não possui permissão para efetuar o cancelamento e depois ao realizar uma nova tentativa de cancelamento acusa que a nota já esta cancelada, com certeza o problema é no provedor. Como que na primeira tentativa o CNPJ do emitente não possui permissão e depois acusa que esta cancelada? Sugiro que você entre em contato com o provedor e expõe o problema.

Bom dia, Toda a carga vai ser descarregada em GO? Se sim, com certeza é uma falha no validador da SEFAZ que não esta prevendo essa possibilidade de percurso: SP->MG->GO. A minha sugestão é entrar em contato com a SEFAZ e expor o problema. Pois você não é obrigado a realizar um percurso uma vez que existe uma outra alternativa, mas não pode utiliza-la pois a SEFAZ não autoriza o MDF-e para essa outra alternativa de percurso.

Bom dia a todos, Luciano, existe o ACBrMonitor e o ACBrNFeMonitor, sendo que este último é que devemos utilizar para emitir NF-e, NFC-e, CT-e e MDF-e. Rubens, o ACBrNFeMonitor, se utiliza do componente ACBrNFe para emitir NF-e e NFC-e, o problema é que o componente é pré-configurado para emitir NF-e na versão 2.00, sendo assim devemos utilizar os comandos: SetModeloDF e SetVersaoDF para definir o modelo e a versão do documento fiscal que desejamos emitir. No caso da NF-e devemos executar os comandos: SetModeloDF("55") SetVersaoDF("2.00") ou SetVersaoDF("3.10") Para a NFC-e: SetModeloDF("65") SetVersaoDF("3.10") Outra coisa importante, no arquivo INI referente a emissão da nota devemos incluir: [infNFe] Versao = 2.00 ou 3.10 para definir a versão do documento fiscal e [identificacao] mod = 55 ou 65 para definir o modelo do documento fiscal.

Bom dia a todos, Primeiramente, lembrem-se que é responsabilidade da aplicação controlar o numero do RPS que deve ser sequencial. O numero da NFS-e por sua vez é controlado pelo Web Services. Quanto as funções de consulta, o programa exemplo possui 4 botões: [Consultar Situação do Lote] [Consultar Lote] [Consultar NFSe por RPS] [Consultar NFSe por Período] É importante ressaltar que dependendo do provedor alguma dessas funções podem não estar disponível como por exemplo: Consultar Situação do Lote.

Boa tarde, Um bom material é a Nota Técnica 2013/005 versão 1.10

Boa tarde Luciano, Antes de tentar enviar a nota emitida em contingência Off-line faça com que o ACBrNFeMonitor execute os seguintes comandos: SetModeloDF("65") SetVersaoDF("3.10") Desta forma ele fica configurado para a NFC-e na versão 3.10

Boa tarde, Interessante. Como eu verifico o que tem no Portal Nacional do MDF-e e nele não tem essa opção.

Qual DANFSE você esta utilizando, Quick Report? Se não for, o problema pode ser esse.

Bom dia Thiago, Favor atualizar os fontes e testar novamente.

No programa exemplo, você tem o botão [Consultar pela chave] este é o exemplo que você precisa. E tem também o botão [Encerramento] apesar dele solicitar o XML, note que ele se utiliza do XML para extrair algumas informações. Informações estas que você pode muito bem passar para o componente para efetuar o encerramento.

O protocolo de autorização esta presente no XML e no DAMDFE, o XML você diz que não tem e o DAMDFE? Caso não tenha o DAMDFE também o jeito é: Tendo a chave, é possível realizar uma consulta através do componente ACBrMDFe e desta forma obter a situação do MDF-e. Se ele estiver autorizado, será retornado o protocolo de autorização.

Bom dia Werner, Uma pequena correção, a versão da NF-e é 3.10 e não 3.0 Pode não ter muita importância, mas acontece que existe a versão 3.00, mas esta foi a primeira versão para o projeto piloto da NFC-e. Hoje com a unificação da NF-e e NFC-e temos para ambos os documentos fiscais a verão 3.10

Bom dia, Não existe opção para realizar o Download do XML do MDF-e. O que não ficou claro é o que foi utilizado para emitir o MDF-e, se foi o programa gratuito da SEFAZ ou uma aplicação própria que se utiliza do ACBrMDFe. Se é uma aplicação própria que se utiliza o ACBrMDFe é possível efetuar o encerramento bastando informar a chave, o protocolo de autorização bem como a cidade de encerramento.

Bom dia Thiago, Pelo jeito você não utiliza o componente ACBrNFe. Se não utiliza, porque não passa a utilizar?

Bom dia Thiago, Muito obrigado pela colaboração, já esta disponível.

Bom dia brsamn, Por favor atualize os fontes e teste novamente. Ao alimentar o componente continue utilizando o ";" para informar a quebra de linha no campo Discriminação. Verifique se ao gerar o XML do RPS o mesmo foi trocado por "\s\n". Envie o lote contendo esse RPS e verifique o conteúdo da TAG Discriminação do XML na NFS-e. Visualize tanto pelo componente quanto pelo site essa NFS-e e veja como fica essa informação.

Boa tarde, O mais estranho é o Registro de Passagem da NF-e, protocolado no dia 6. A mercadoria circulou, ou seja, foi enviada para o destinatário?