Italo Giurizzato Junior

Boa tarde cne, Vamos fazer uma correção, o prazo de cancelamento não é de 7 dias e sim 168 horas a contar da data e hora de autorização. Portanto se um CT-e foi autorizado no dia 20 as 10:00 o prazo para o seu cancelamento encerra-se no dia 27 as 10:00, isso significa que as 10:01 não é mais permitido o cancelamento do mesmo. Alem do prazo em horas existe diversas regras que devem ser observadas, como por exemplo, carga em transito ou entregue. Se a carga esta em transito ou já foi entregue ao destinatário significa que o serviço esta ou foi realizado, sendo assim não cabe o cancelamento do CT-e. Quando foi dito: "As regras aplicadas ao evento de cancelamento serão aplicadas ao Web Service de Cancelamento que será descontinuado futuramente." Significa que com o advento do cancelamento por evento novas regras foram criadas, como as duas modalidades de cancelamento coexistiram por um certo tempo, essas novas regras foram também aplicadas ao Web Service de cancelamento que depois foi desabilitado. Portanto você não tem que se preocupar com essa frase e sim se preocupar com as regras.

Boa tarde leufmt, Entendi o usuário lança vários RPS e depois tem a opção de selecionar os que deseja enviar para o provedor e este retornar as respectivas notas. Como ocorre esse envio, é por lote ou de um em um? A sugestão que dou é usar o envio por lote (até 50 RPS), caso o provedor tenha essa opção disponível.

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.