Italo Giurizzato Junior

Boa tarde Open Net, Se possível post o XML.

Boa tarde a todos, Primeiramente se essas entregas são dentro do municipio, a transportadora não pode emitir o CT-e e sim Nota Fiscal de Serviço. Se for intermunicipal ai sim, vai emitir o CT-e. Outra coisa, um remetente e vários destinatários, duas perguntas: 1. Quem emitiu as NF-e, é esse remetente? 2. Quem é o tomador do serviço é o remetente? Se a resposta form sim para as duas perguntas, pesquise aqui no fórum sobre CT-e Globalizado. Existe sim a possíbilidade de se emitir um CT-e apenas, mas existem regras e a Transportadora tem que solicitar junto a SEFAZ o Regime Especial. Essas informações estão no Boletim Técnico 2012/001 de maio/2012. CTe_BT2012_001 Padroniza CTe Globalizado.pdf

Boa tarde Fabio, Você já deu uma olhada nas Notas Técnicas, me parece que tem uma que tratada desse assunto.

Boa tarde Fernando, Alteração feita e disponibilizada.

Boa tarde vcintra e Andeson, Muito obrigado pela colaboração.

Sandro, Você sabe quais são as informações que devemos informar quando o documento originário é outros? No seu arquivo consta apenas: [infOutros001] tpDoc=00 Favor acrescentar o campo nDoc informando o numero do documento, apesar de esta como opcional no manual, o ACBrNFeMonitor não gera o grupo infOutros se não tiver essa informação. Veja o exemplo: [infOutros001] tpDoc=00 nDoc=123

Bom dia Sandro, A mensagem de erro diz que o elemento rem esta incompleto, ou seja esta faltando email, infNF, infNFe, ... Vide o manual para saber quais desses campos faltantes são obrigatórios ou opcionais.

Bom dia Isaque, O projeto ACBrNFeMonitor possui uma unit chamada DoACBrCTeUnit. Alterações necessárias para que a mesma fique compativel com ambas as versões. Vamos a um exemplo: Atual: Desta forma basta Comentar / Descomentar a diretiva desejada no arquivo ACB.inc e compilar com a opção Build o projeto. A solução é simples mas um tanto quanto trabalhosa, para mais detalhes de outras alterações vide o arquivo alimentarcomponente.txt que encontra-se dentro da pasta ...\Exemplos\ACBrCTe. Na minha aplicação foram necessárias 18 alterações como a apresentada acima.

Bom dia Aprendiz_ce, Botões: [Consultar NFSe por Período] e [imprimir DANFSe]

Boa noite vca_rj, Não, isso não procede, você pode estar em produção e ficar realizando testes em homologação sem nenhum problema. Diga ao seu cliente para pedir ao contador mostrar onde isso esta escrito na legislação ou no manual ou notas técnicas publicadas pela SEFAZ. Com isso o seu cliente vai descobrir o quanto o contador dele, esta mau informado sobre o assunto.

Boa noite Marcio, Entendi o seu problema. Temos 2 situações: 1. O transporte já foi realizado e consequentemente o MDF-e esta encerrado, neste caso não vejo problemas. 2. A carga esta em trânsito, ai sim pode ocorrer problemas no momento de uma checagem do MDF-e em um posto fiscal de fronteira.

Boa tarde Marcio, Você chegou a tentar, executar o processo de anulação, substituição ? Acredito que uma coisa não tem haver com a outra, ou seja, se foi emitido ou não o MDF-e.

Boa tarde Fábio, Já esta disponivel a alteração das URLs, muito obrigado pela colaboração.

Boa tarde Wislei, Ao meu ver o correto é termos apenas um unico arquivo que seja capaz de imprimir tanto um quanto o outro. Estude mais um pouco, tenho certeza que você vai encontrar uma solução. Não me recordo se para a NFe temos o DANFE em Fast Report, se sim, que tal dar uma olhada como foi resolvido essa questão, visto que na NF-e também temos o segundo código de barras quando o DANFE é emitido em contingência.

Boa tarde Hasa, Logo no inicio notei alguns erros: Esta invertido o conteudo do CFOP e natOp, e o CFOP não pode estar formatado ou seja temos que informar 5102 e não 5.102 Na dhEmi consta apenas a data e o correto é informar a data e hora. Do resto parece estar em ordem.

Bom dia Isaque, Pasta: ...\Fontes\ACBrComum Arquivo: ACBr.inc // Definições para o compomente ACBrCTe // Define o Pacote de Liberação / Descomente o pacote a ser utilizado // Atenção: descomente apenas uma das definições //------------------------------------------------------------------------------ //{$DEFINE PL_103} {$DEFINE PL_104} //{$DEFINE PL_200} Desta forma o componente gera segundo a versão 1.04 Outra coisa, com a mudança para a versão 2.00 o grupo com as informações dos documentos originários mudaram de lugar, ou seja, não estão mais dentro do grupo remetente e sim dentro de um grupo especifico desta forma temos que mecher na rotina que alimenta o componente, veja este exemplo: // Nota Fiscal Eletrônica {$IFDEF PL_200} with infCTeNorm.infDoc.infNFe.Add do {$ELSE} with Rem.InfNFe.Add do {$ENDIF} begin chave := DM_CNT.NotasChaveNFe.AsString; PIN := DM_CNT.NotasPinSuframa.AsString; end; end; Para mais detalhes sobre outras mudanças vide o arquivo AlimentarComponente.txt que encontra-se na pasta: ...\Exemplos\ACBrCTe.

Bom dia Rafael, Como dito anteriormente o componente tem que estar configurado com o mesmo ambiente que consta no XML, veja: Configuração do componente: case DM_CTA.ParamDFeWSAmbiente.AsInteger of 0: ACBrCTe.Configuracoes.WebServices.Ambiente := taHomologacao; 1: ACBrCTe.Configuracoes.WebServices.Ambiente := taProducao; end; Alimentação do componente com os dados pertinentes ao transporte da carga: case DM_CTA.ParamDFeWSAmbiente.AsInteger of 0: Ide.tpAmb := taHomologacao; 1: Ide.tpAmb := taProducao; end; Espero ter ajudado.

Alex, Na verdade foi liberado no dia 01/11/2013 o ambiente de produção, mas isso não significa obrigatoriedade, uma vez que a versão 1.04 ainda vai ser aceita até 01/06/2014.

Rafa, Vai depender da versão do Fortes utilizado na época para fazer o DANFSE.

Bom dia Igor, Primeiramente o componente tem uma propriedade chamada VersaoDF que aceita os valores ve100 e ve100a Segundo, no portal do MDF-e você encontra os manuais e notas técnicas, essa é a fonte para saber a estrutura do XML de uma versão e da outra.

Bom dia Alex, Acredito ter encontrado o problema. Quando o ACBrNFeMonitor le o arquivo INI, no que diz respeito ao CST é lido o valor atribuido como sendo uma string, portanto: CST = 40 e CST =40 são coisas diferentes, note que no primeiro temos um espaço em branco entre o = e o 40, sendo assim ao ler esse valor como string temos: " 40" em vez de "40". Outra coisa importante para os CST: 40, 41 e 51 devemos montar o arquivo INI da seguinte forma: [iCMS45] CST=40 [iCMS45] CST=41 [iCMS45] CST=51 e não como você tinha feito: [iCMS40] CST=40 desta forma esta errado. Dica: para aqueles que utilizam o ACBrNFeMonitor, tanto para emitir a NFe quanto o CTe. Para saber se o monitor lê um campo como valor ou string, é preciso abrir o fonte do mesmos, fica mais fácil montar sempre o arquivo INI da seguinte forma: [nome do grupo] campo=valor não deixe espaço em branco antes e depois do = Teste e reporta aqui se dessa forma funcionou.

Rafa, Vou tentar descobrir, ai posto aqui. Enquanto isso deixo um recado para quem desenvolveu, postar aqui, a versão do Fortes e para qual Delphi.

Bom dia Rafa, Não sei lhe responder sobre a versão do Fortes Report utilizado. Os Documentos Auxiliares desenvolvidos por mim, são feitos em Quick Report versão 5.02 para o Delphi 7.

Boa noite Andeson, Muito obrigado pela colaboração, já esta disponivel no SVN.

Boa noite Alex, O problema relatado com o ICMS, ocorre na emissão da NFe ou CTe?