Italo Giurizzato Junior

Boa noite José, Segundo a página 97 da Nota Técnica 2013/004 versão 1.00a temos: Campo: <idUnidTransp> Informar a identificação conforme o tipo de unidade de transporte. Por exemplo: para rodoviário tração ou reboque deverá preencher com a placa do veículo.

Boa tarde Gabriel, O seu caso com certeza é o transporte Rodoviário, mas veja o que esta escrito na página 134 (versão 2.00a do Manual do CT-e), mais precisamente o grupo #257 <infQ>. Para o Aéreo é obrigatório o preenchimento desse campo da seguinte forma. 1 - Peso Bruto, sempre em quilogramas (obrigatório); 2 - Peso Cubado; sempre em quilogramas; 3 - Quantidade de volumes, sempre em unidades (obrigatório); 4 - Cubagem, sempre em metros cúbicos (obrigatório apenas quando for impossível preencher as dimensões da(s) embalagem(ens) na xDime do leiaute do Aéreo). Como você pode ver no caso do modal Aéreo temos que informar o peso bruto e cubado bem como a quantidade de volumes. Portanto esse desenvolvedor precisa ler um pouco mais. Venhamos e Convenhamos: Qual é o problema de você informar que a carga a ser transportada do Remente A até o Destinatário B é composta por 10 Caixas que totalizam um peso bruto de 5 Kg. Para o calculo do frete onde leva-se em consideração o peso temos que informar o 5 Kg, mas para o destinatário o que interessa é que ele vai receber as 10 caixas contendo os produtos que ele adquiriu. Se essa informação constar no DACTE fica fácil a conferencia.

Boa tarde Flavio, Favor atualizar os fontes e testar novamente. Alterei a cidade para o provedor Pronim.

Boa tarde Alexandre, Relaxa, fontes alterados e disponibilizados.

Boa tarde Alexandre, Muito obrigado pela colaboração, já esta disponível.

Boa tarde Robson, Muito obrigado pela informação, logo estarei disponibilizando.

Boa tarde Márcio, Muito obrigado pela colaboração, logo estarei disponibilizando.

Boa tarde Leandro, Se a tenta as datas ( postagem #1 ). Quanto ao componente já esta tudo pronto, estamos esperando a liberação do ambiente de homologação para iniciarmos os testes.

Boa tarde, A solução que vejo é utilizar uma aplicação a parte para importar os CT-e da versão 1.04.

Bom dia Liandro, Se não me falha a memória existem vários post no fórum que trata desse problema: Erro no suporte a canais seguros.

Bom dia Maiko, Na página 87 da Nota Técnica 2013/013 acredito que deve responder as suas duvidas. No caso da carta de correção temos o grupo evCCeCTe (parte geral do XML referente ao registro de eventos). Dentro dele encontramos um outro grupo chamado infCorrecao, note que a sua ocorrência é 1-n, isso significa que podemos ter no minimo 1 e no máximo n correções (o componente limita esse n em 990). O elemento nroItemAlterado só é utilizado quando o campo alterado pertencer a uma lista, veja descrição do mesmo: Preencher com o índice do item alterado caso a alteração ocorra em uma lista. Por exemplo: Se corrigir uma das NF-e do remetente, esta tag deverá indicar a posição da NF-e alterada na lista. OBS: O índice inicia sempre em 1 Ao informar o documento originário, ou seja, o documento emitido pelo remetente da carga, lembre-se que podemos informar mais do que 1. Vamos a um exemplo: O remetente por algum motivo qualquer emitiu 3 NF-e para o mesmo destinatário. E as mercadorias constantes nas 3 NF-e vão ser transportadas de uma só vez, neste caso devemos informar as 3 NF-e como sendo os documentos originários. Sendo assim teremos uma lista de NF-e com índice = 1, 2 e 3. Se vai ser emitido uma CC-e para corrigir algo referente a segunda NF-e o elemento nroItemAlterado vai receber o valor 2. Espero ter ajudado.

Bom dia Wislei, Você deve ter notado que temos no componente duas propriedades Salvar, uma em Geral e outra em Arquivos. Os arquivos *-ped-evento.xml e *-eve.xml não serão salvos se ambas as propriedades receberem o valor False. E temos também o SalvarEvento em Arquivos. Fiz uma alteração no componente, para que o mesmo tenha o seguinte comportamento: Se ACBrMDFe.Configuracoes.Geral.Salvar for True vai salvar os 3 arquivos (-ped-evento.xml, -eve.xml e -procEventoMDFe.xml); Se ACBrMDFe.Configuracoes.Arquivos.Salvar for True vai salvar os 3 arquivos (-ped-evento.xml, -eve.xml e -procEventoMDFe.xml); Se ACBrMDFe.Configuracoes.Arquivos.SalvarEvento for True vai salvar o arquivo (-procEventoMDFe.xml); Sendo assim se a sua intenção é salvar apenas o -procEventoMDFe.xml a configuração é: ACBrMDFe.Configuracoes.Geral.Salvar := False; ACBrMDFe.Configuracoes.Arquivos.Salvar := False; ACBrMDFe.Configuracoes.Arquivos.SalvarEvento := True; Favor atualizar os fontes.

Bom dia Maiko, Quanto a obrigatoriedade eu não sei quando começa, mas dentro da pasta ...\Exemplos\ACBrCTe temos um arquivo texto chamado AlimentarComponente, abra-o com o bloco de notas e procure por: vTotTrib. Você vai notar que não é realizado nenhum calculo, simplesmente eu pego o valor que encontra-se no banco de dados e passo para o componente. No banco de dados tenho uma tabela chamada Conhecimento que contem um campo chamado vTotTrib. Após a digitação de todos os dados realizo o seguinte calculo: vTotTrib := TotalFrete * Tributo / 100; Tributo é 4.20 % (por exemplo), esse percentual você encontra na mesma tabela IBPT que contem os percentuais dos produtos para emissão da nota fiscal. Feito o calculo, o resultado é salvo no campo já mencionando na tabela Conhecimento (banco de dados).

Boa noite Wislei, Vamos estudar sobre o assunto.

Bloqueado por duplicidade.

Boa noite Jose, Mas qual é o erro?

Boa noite Edmilson, Quando o remetente da carga é obrigado a emitir NF-e, ao informar o documento originário devemos informar a chave da mesma e nada mais. A necessidade é para satisfazer a exigência da transportadora ou do destinatário? Se sim, coloque no campo de observação.

Boa noite Edson, Esse erro só ocorre quando ao alimentar o componente, a propriedade ID é alimentada. Se atribuirmos uma string vazia ou não atribuir nada a propriedade ID jamais você terá problemas.

Boa tarde Ailton, Muito obrigado pela colaboração, já esta disponível.

Noto que o CT-e esta sendo enviado para a SEFAZ é de MG, é sabido que a SEFAZ-MG costuma de vez em quando retornar algumas mensagens malucas. Você vira o XML de ponta cabeça compara com o manual e não consegue encontrar nada de anormal. Não creio que seja o valor da TAG lota, pode ser o RNTRC que contem zeros, experimente colocar o numero valido em vez de zeros.

Nesse site você tem que abrir o XML com o bloco de notas, selecionar o conteúdo e colar no quadro especifico do site, caso contrario não funciona.

Boa tarde Lucas, Isso mesmo, no envio da NFC-e em modo síncrono não temos o numero do recibo no retorno. Mas a SEFAZ-AM retorna o numero do recibo no envio síncrono. Ela é exceção, as demais seguem a regra.

Boa tarde, O problema pode esta no bloco referente ao modal.

Boa tarde a todos, Muito obrigado pela colaboração, em breve vou disponibilizar.

Bom dia Wanderson, Muito obrigado pela colaboração, em breve será disponibilizado.