italo.giurizzato.junior

Boa tarde Marcio, Qual é o valor que você esta passando para tpEmit ? No seu caso tem que ser: teTranspCargaPropria

Pode ser sim, esse componente talvez possua uma rotina própria pra formatar o telefone. Como não tenho conhecimento em Rave não posso em lhe afirmar.

Boa tarde Vanessa, O componente ACBrNFe possui 2 propriedades para definir o modelo e a versão do documento fiscal. ModeloDF = moNFe ou moNFCe VersaoDF = ve200 ou ve310 (para o moNFe). VersaoDF = ve300 ou ve310 (para o moNFCe). No momento devemos utilizar no caso da NF-e os seguintes valores: ModeloDF = moNFe VersaoDF = ve200 Agora se para a UF que você esta realizando testes esta participando do projeto piloto da NFC-e, já é possível realizar os testes com os seguitnes valores: ModeloDF = moNFe VersaoDF = ve310 Eu aconselho configurar esses parametros antes de um acesso a qualquer WebServices.

Boa tarde Eber, Favor atualizar os fontes e testar novamente.

No XML o numero é sem formatação. No DANFE que podemos formatar o numero. Você compilou a sua aplicação com a opção Build que esta no menu Project? Se sim, isso significa que o DANFE que você esta utilizando não utiliza a function FormatarFone que esta dentro da Unit ACBrDFeUtil.pas

Boa tarde, Favor atualizar os fontes e testar novamente.

Boa tarde Wellington, Primeiramente devemos lembrar que a emissão só é feita quando o transporte for intermunicipal ou interestadual. Segundo: Se toda a carga for para o mesmo destinatário o CT-e é de lotação, caso contrario é fracionado. Em qual situação se aplicaria o CT-e Glogalizado em um transporte de Mudanças?

Rafael, Desculpa, eu não quiz te ofender. Mas note que o Scott deixou claro que para o cancelamento tem que ser 1. Outra coisa, NT 2013/013 página 72, descrição do campo nSeqEvento: "Sequencial do evento para o mesmo tipo de evento. Para maioria dos eventos será 1, nos casos em que possa existir mais de um evento o autor do evento deve numerar de forma sequencial." Note que para a maioria dos evento o numero sequencial vai ser sempre 1, só será sequencial quando o tipo de evento permitir mais de um, que o caso da CC-e. Os demais eventos para o CT-e que são o Cancelamento, o EPEC e o Registrodo Multimodal são unicos, ou seja, só pode existir um desses eventos para o CT-e.

Bom dia Leonardo, Vou remover o código 51 da lista e disponibilizar a alteração. Peço a você e a todos que estão realizando testes com a NF-e versão 3.10, que reporte problemas após ter incluido a lista para determinar qual metodo a ser utilizado. Segundo a NT 2013/005 versão 1.02 que trata da versão 3.10, na página 5 consta como 03/02/2014 a data de inicio do ambiente de homologação e 10/03/2014 o de produção. Se você já esta realizando testes com a versão 3.10 em Mato Grosso, isso é porque a UF é participante do projeto piloto da NFC-e, correto?

Bom dia Rafael, Releia o que o Scott escreveu. Você tentou realizar o cancelamento colocando como numero sequencial do evento igual a 1 ?

Bom dia Régys, O Estado de Rondônia já utiliza a SEFAZ-Virtual do RS para emissão da NF-e, era de se esperar a adoção da NFC-e, caso ocorresse sucesso na emissão da NFC-e nas UF participantes do projeto piloto que também se utilizam da SVRS. Se não me falha a memória cerca de uma duzia de Estados brasileiros se utilizam da SVRS para emitir NF-e, pelo andar das carroagens, todas vão adotar a NFC-e e isso representa praticamente a metada dos Estados. Com certeza os empresarios e sindicatos do comércio vão pressionar as SEFAZ dos demais Estados a também adotarem. Me parece que já existe um movimento nesse sentido no Estado do Rio de Janeiro.

Boa noite Leonardo, Fiz essa alteração, pois não consta no Portal Nacional da NF-e os novos WebServices para as UF incluidas na condição. Vendo agora os XMLs que você postou, com essa alteração, você passou a ter erros, correto? E se remover o código 51 da lista de UFs a sua aplicação volta a funcionar, correto?

Boa noite infoel, No caso da NFS-e não se valida o XML do RPS e sim o Lote de RPS, dai o erro.

Boa noite Asterix, Acredito que o problema deve ser na SEFAZ, uma fez que o XML esta em conformidade com o Manual e com o Schema.

Boa noite Carlos, Como o MDF-e perante os demais documentos fiscais, ele ainda esta engatinhando. A idéia do MDF-e é facilitar a fiscalização da carga nas fronteiras entre os estados. . Como não existe fiscalização nas entradas dos municipios, acho um cumulo exigir a emissão do MDF-e para transporte intermunicipal. No ajuste sinief atualizado, diz que o Estado podera exigir a emissão do MDF-e para um CT-e de Lotação, outro absurdo. O MDF-e contem somente as informações sobre o veículo, motorista, a quantidade de documentos fiscais e o peso total. Um CT-e de lotação já possui todas essas informações. Lhe pergunto, para que gastar uma segunda folha para colocar os dados que ja constam no CT-e?

Jeferson, Isso é apenas um exemplo, e não a regra a ser seguida por todas as UFs.

Asterix, Você tem razão, a unit pcteCTeW estava impondo a condição de Lotação = Sim para gerar o grupo Vale-Pedario. Alteração feita e disponibilizada. Favor atualizar os fontes e testar novamente, informando Lotação = Não

Boa tarde cipolari, Talvez na minha postagem anterior não ficou claro. Mas pode sim emitir mais de um MDF-e para o mesmo caminhão, continuando no exemplo da postagem anterior podemos sim emitir os dois MDF-e desde que seja no mesmo dia. E quando o motorista for sair da Bahia, deve-se informar a transportadora para que a mesma efetue o encerramento do primeiro. E consequentemente quanto o caminhão descarregar o resto da carga no Amazonas, o motorista de informar a transportadora para que a mesma efetue o encerramento do segundo MDF-e.

Boa tarde Jeferson, O Estado do Maranhão se utiliza da SEFAZ Virtual - Ambiente Nacional. Precisamos saber quais as URLs tanto de homologação quanto de produção utilizadas para a NFC-e. Não sabemos se ocorreu mudança, ou seja, para a NF-e é uma e para a NFC-e é outra. Como é o caso de Mato Grosso; NF-e: https://nfe.sefaz.mt.gov.br/nfews/... NFC-e: https://nfce.sefaz.mt.gov.br/nfcews/... Note que muda de nfe para nfce, é isso que precisamos saber no caso da SEFAZ Virtual - Ambiente Nacional. Tendo essa informação, podemos implementar no componente, ai disponibilizar uma nova versão do ACBrNFeMonitor, uma vez que o motinor se utilzia do componente ACBrNFe.

Boa tarde Asterix, Notei que você colocou como SIM no indicador de lotação, neste caso é necessário informar os dados do veículo e do motorista. No que diz respeito ao Vale Pedágio, você colocou o CNPJ do destinatário como sendo a empresa fornecedora do vale-pedágio, esta correto? E no CNPJ do responsável pelo pagamento do vale-pedário, foi informado um CNPJ do destinatário, também esta correto isso? Veja bem estamos falando do vale-pedágio e não do componente pedágio que compõe o valor do frete a ser pago pelo tomador do serviço.

Bom dia Asterix, Post como anexo o XML do CT-e que foi rejeitado, quero verificar.

Bom dia Galvaonv, Leia as postagens que encontram-se no tópico ACBrMDFe.

Bom dia Eber, Solicite ao provedor GovDigital, as URLs de homologação e de produção para a cidade de Lavras/MG.

Bom dia Jonas, A sua anteração não confere com os schemas que hoje estão disponiveis. Por favor entre em contato com o GovBR e solicite os schemas que eles utilizam. E os questione se todas as cidades atendidas por eles seguem os mesmos schema.

Bom dia Carlos, Acredito que seja possível sim emitir 2 ou mais MDFe para o mesmo veiculo e para o mesmo par de estado, veja a regra G055. Nota Técnica 2014/001 página 2 item 4. A regra de validação G055, que verifica se existe MDF-e não encerrado para a placa do veículo de tração, considerando CNPJ base, UF carregamento, UF descarregamento e Data de emissão diferente, passará a retornar a chave de acesso mais antiga que está causando bloqueio do MDF-e na mensagem de Rejeição. Note que a regra faz referencia a data de emissão. Será rejeitado se a data de emissão for diferente, mas se você emitir os 4 MDFe no mesmo dia subentende que não será rejeitado.