Italo Giurizzato Junior

Pablo, Quem esta compilando e disponibilizando o programa se não me engano é o Juliomar. Juliomar, o problema sitado pelo Pablo é resolvido executando o procedimento apresentado no link.

Boa tarde Pablo, Esse tipo de mensagem é porque a versão do Quick Report que você esta utilizando não possui essa propriedade. Ou seja a versão do Quick Report utilizado para escrever o DACTE é diferente da que você tem instalado no seu Delphi. Verifique se isso resolve o problema:

Bom dia, Você deve estar configurando o componente com o ambiente de produção e gerando o XML como ambiente de homologação ou vice-versa. Portanto existe 2 lugares onde devemos informar o ambiente: Configuração do Componente: case DM_CNT.ParametrosCTeWebServAmbiente.AsInteger of 0: ACBrCTe.Configuracoes.WebServices.Ambiente:=taHomologacao; 1: ACBrCTe.Configuracoes.WebServices.Ambiente:=taProducao; end; e Alimentação dos dados: case DM_CNT.ParametrosCTeWebServAmbiente.AsInteger of 0: Ide.tpAmb:=taHomologacao; 1: Ide.tpAmb:=taProducao; end; Espero ter ajudado.

Bom dia Ricardo Flexnet e DDSG, Sim o ACBrNFSe atende o lay-out da ABRASF, o problema esta nas variações que essas empresas promovem. A falta de documentação é com relação a montagem dos envelopes que são enviados para os webservices, que não existe uma padronização. Com certeza uma aplicação que emite a NFS-e, alimenta o contas a receber de forma integrada, automatizada, sem duvida é a solução.

Bom dia a todos, Esse é um problema sério. A NFS-e já começou errada, foi criado um lay-out muito fraco, por parte da ABRASF que por sinal não foi capaz de impor, apenas sugerir. Ai vira isso que temos, uma verdadeira bagunça, cada provedor faz do jeito que quer, e cada dia que passa, vamos chegando a conclusão que é mais facil o nosso cliente entrar no site da prefeitura, digitar os dados e emitir a NFS-e. O provedores não seguem um padrão, não disponibilizam documentação completa para que possamos, desenvolver a nossa aplicação. Isso torna as coisas mais complicadas.

Bom dia Junior, Realize uma pesquisa no fórum, existem varios tópicos tratando desse assunto.

Muito obrigado Isaque.

Boa tarde Isaque, Com certeza isso vai ser muito útil para quem se utiliza dos Monitores, parabéns.

Boa tarde Udenilson, Checando o XML realmente temos como conteudo da tag OutrasInformacoes <BR>. Veja bem o componente não gera esse XML ele apenas extrai ele do retorno do webservice e salva em disco. Portanto o problema é no sistema deles que esta gerando essa "sugeira", se você abrir o arquivo com o bloco de notas e alterar o <BR> por . (ponto) e salva-lo novamente você vai conseguir abrir ele com o IE.

Bom dia Beto, É bom acrescentar os endereços dos servidores vituais, por exemplo SVCRS. Verifique quais a sua aplicação utiliza alem do SEFAZ-SP. Ou liberes todos da lista que consta no portal.

Bom dia Udenilson, Se possível poste o XML gerado.

Valdomiro, Existem relatos nos fórum de alguns colegas, que para retornar uma nota foi necessário repetir a consulta centenas de vezes.

Bom dia Valdomiro, Você informou ultNSU = 0 mas no retorno obteve: cStat = 137 indCont = 1 e ultNSU diferente de zero. Enquanto indCont = 1 realizar uma nova consulta utilizando o numero retornado na tag ultNSU do último retorno.

Boa noite Udenilson, O componente gera o XML do RPS e salva na pasta RPS, após o envio para o webservice se for processado com sucesso, o mesmo retorna o XML da NFSe e é salvo na pasta NFSe. É esse XML que contem o numero da nota e é usado para imprimir o DANFSE.

Claudemir Neste caso, temos uma outra solução: svalor := SeparaDados( sXML, sNomeCampo ); o conteudo de svalor vai ser o "valor_campo".

Pierry, Tire o ponto que você esta passando para o RNTC. Transp.veicTransp.RNTC := '.'; mude para: Transp.veicTransp.RNTC := '';

Boa tarde Pierry, Poste o fragmento de código onde você alimenta o componente com esses dados referente a transportadora.

Edudidu, Sim, a emissão em contingência FS-DA é a mais facil de implementar uma vez que você muda o tipo de emissão, imprimir o DACTE em papel FS-DA e quando os problemas técnicos foram sanados, envia para SEFAZ sem mudar o tipo, ele continua como sendo teFSDA, ou seja não mude para Normal. No caso do CTe existe ainda o EPEC - Evento Prévio de Emissão em Contingência. Leia atentamente a NT 004/2012 que trata sobre o assunto. Detalhe o componente ACBrCTe já atende essa NT, mas os webservices ainda não estão disponíveis, o ambiente de homologação só vai ser liberado em 01/04/2013. Boa leitura.

Boa tarde Kiko, No meu exemplo condição 4 onde temos a transportadora cobrando o frete do emitente da NFe, a empresa que você se refere é a emitente da NF-e que como dito vai pagar o frete, sendo assim vai lançar esse documento no seu registro de entrada, estou correto? Neste caso quem tem direito ao crédito é o emitente da NF-e e não o destinatário da mercadoria, é isso?

Boa tarde a todos, Ao meu ver o problema é sim o programa utilizado pelo escritório que não consegue prever todas as situações: <IE></IE> ou <IE/> ou <IE /> Vocês acham que o escritório vai dizer que o programa utiliza não preve todas as situações, como fica a sua imagem perante a todos os clientes. É mais fácil dizer que o seu programa que esta gerando o XML de forma incorreta, desta forma é a sua imagem que esta em jogo e não a do escritório.

Boa tarde cvpereira, A coisa é mais simples que você imagina: veja esta function que você pode incluir no seu componente: function RetirarPrefixos(AXML, sPrefixo: String): String; begin AXML := StringReplace( AXML, sPrefixo, '', [rfReplaceAll] ); result := AXML; end; Como utilizar: Primeiro você carrega o XML para dentro de uma variável string, por exemplo sXML, depois executa a função: sXML := RetiraPrefixos(sXML, 'ns1:'); Agora você tem o XML sem o prefixo nas tags.

Boa tarde a todos, Sim, quanto mais opniões, mais informações e idéias, mas devemos sempre deixar claro que não somos os donos da verdade, e sempre buscar orientação, nesses casos, com o contador do nosso cliente. Outro detalhe é sempre bom ao conversar com o contador ter o cliente presente também, se isso não for possível, pedir a explicação de por escrito (e-mail).

Boa tarde, É bom que se deixe claro, que isso se refere as UF participantes do projeto piloto como é o caso do Amazonas. A intenção é que esse projeto que começou com meia duzia de Estados, no decorrer deste ano outros Estados resolvam optar pela NFC-e, observando é claro o resultado obtido pelos demais.

Boa tarde Edudidu, No caso do CTe só temos os 4 tipos de emissão: teNormal, teFSDA, teSVCRS ou teSVCSP. Portanto dependendo da situação e da UF você vai utilizar um tipo ou outro. O tipo teFSDA é o de contingência utilizado pelo CTe. Já os tipos teSVCRS e teSVCSP são as SEFAZ Virtuais de Contingência RS e SP. Para mais detalhes sobre esses 2 tipos de emissão favor ler a NT 003/2012 disponivel no Portal Nacional do CT-e.

Peterson, Você concorda que o destinatário desta forma esta reembolsando o emitente no que diz respeito ao frete. E para que o destinatário não saiba disso eles colocam o valor do frete em despesas acessórias e não como frete.