Italo Giurizzato Junior

Bom dia Pedro, Você pode sim utilizar a mesma série e consequentemente a mesma sequencia de numeração sem nenhum problema, visto que a NF-e é um modelo de documento fiscal e a NFC-e é outro modelo. Uma mesma Empresa pode dependendo da situação emitir a NF-e ou a NFC-e, consequentemente em algum momento será emitido a NF-e serie 1 numero 1500 e em outro a NFC-e serie 1 numero 1500. Repito isso não tem problema nenhum pois são modelos de documentos fiscais diferentes. Modelo da NF-e é 55 e da NFC-e é 65.

Bom dia Rafael, O componente possui 3 propriedades que determina se os XMLs serão salvos em disco ou não. Configuracoes.Geral.Salvar := [True|False] => defini se os XMLs de envio/retorno serão salvos em disco ou não. Configuracoes.WebServices.Salvar := [True|False] => defini se os XMLs de envio/retorno (completos com as TAGs de envelope) serão salvos em disco ou não. Configuracoes.Arquivos.Salvar := [True|False] => defini se os XMLs de validade jurídica serão salvos em disco ou não.

Bom dia Leão, Os espaços em brancos que encontrei no seu XML são normais e estão previstos, não encontrou nenhum que invalidasse o seu XML.

Bom dia Fabio, O método consultar é para quando você já tem o XML assinado e só necessita do protocolo de autorização. Se o emitente perdeu o XML existem 2 soluções: 1. Se o XML em questão foi enviado por e-mail para o destinatário, basta entrar em contato com o mesmo e pedir que lhe envie por e-mail, simples assim. 2. Gerar e assinar o XML com os mesmos dados da primeira vez, tomando o cuidado da chave ser exatamente igual, depois executar o método consultar para obter o protocolo de autorização.

Bom dia Robinho, Qual problema?

Boa tarde Fabio, O Consultar não gera XML do CT-e ele apenas realiza uma consulta. O que ele faz é se você carregar o componente com o CT-e, após a consulta o mesmo será atualizado. Por exemplo, o XML do CT-e esta assinado mas não contem o protocolo de autorização. Você carrega o XML com o LoadFromFile e depois executa o Consultar. O XML do CT-e será atualizado, ou seja, vai ficar assinado e com o protocolo de autorização (caso a SEFAZ tenha autorizado).

Boa tarde Murilo, A mensagem de erro é clara: '' violates pattern constraint of '[!-ÿ]{1}[ -ÿ]{0,}[!-ÿ]{1}|[!-ÿ]{1}'.The element '{http://www.portalfiscal.inf.br/nfe}cExportador' with value '' failed to parse. Diz que o elemento cExportador contem uma string vazia, sendo assim você deve alimentar esse campo na sua rotina que alimenta o componente com os dados da nota. Te aconselho ter em mãos a estrutura completa do XML para saber quais são os campos obrigatórios e opcionais na hora de alimentar o componente. Você encontra a estrutura completa e atualizada do XML da NF-e na Nota Técnica 2013/005 versão 1.22

Boa tarde Rafael, Post como anexo o XML de envio do evento sem esse arquivo não tem como lhe ajudar.

Boa tarde, O problema é que esse provedor não segue o padrão ABRASF e isso dificulta muito a implementação. A migração do ACBrNFSe para o Trunk2 esta mais demorada por causa desse tipo de documento não seguir os mesmos moldes da NF-e, CT-e entre outros. Na NF-e você gera e assina o XML da NF-e e ao enviar o mesmo para o Web Service da SEFAZ esta analisa e se tudo estiver correto retorna simplesmente o protocolo de autorização. No caso da NFS-e não é assim que funciona, você gera e assina o XML do RPS, envia ele para o Web Service do provedor e este extrai os dados do RPS e gera e retorna o XML da NFS-e. Agora você soma a isso os provedores que usam o padrão ABRASF versão 1.00, os que usam a versão 2.00 e os que usam a versão 2.01 e sem contar com aqueles que alem de usar uma determinada versão do padrão resolveram acrescentar ou inverter alguma TAG de posição. Depois aparecem empresas (provedores) que não seguem o padrão, mas como atendem as necessidades da prefeitura, acabam sendo contratas, alias para muitos funcionários de prefeituras, Web Service deve ser algum restaurante novo onde você mesmo pega a comida. No primeiro momento o nosso objetivo é fazer com que o ACBrNFSe funcione no Trunk2 para os provedores que seguem o padrão ABRASF, depois vamos partir para aqueles que não seguem. Tem que ser assim não tem outro jeito.

Bom dia Rômulo, Muito obrigado pela colaboração, já esta disponível no Trunk2.

Isaac, Você utiliza os fonte do Trunk ou Trunk2? Se for o Trunk abra a uni ACBrNFeUtil e se for o Trunk2 abra o arquivo INI: ACBrNFeServicos.

Bom dia Isaac, Por favor pesquise antes de postar, sobre as novas URLs da SEFAZ-RS e da SEFAZ-Virtual do Rio Grande do Sul já foi dito aqui por dezenas de vezes que já foram atualizadas nos componentes por mim no dia 01/05/2015, sendo assim se os seus fontes estão 100% atualizados não há motivo de se preocupar.

Bom dia Sandro, Arquivo tipo Compartilhamento, são os que devemos compartilhar com os destinatários e transportadoras, se tratando de NF-e temos: *-nfe.xml (nota fiscal eletrônica propriamente dita), esse XML tem que estar assinado e protocolado. *-procEventoNFe.xml (processamento do Evento de NF-e), esse XML contem a solicitação do evento e o retorno da SEFAZ acusando que o evento foi ou não vinculado a NF-e bem como o protocolo da SEFAZ. Temos ainda o *-procInutNFe.xml (processamento da Inutilização de numeração), esse XML contem a solicitação de inutilização de numeração e o retorno da SEFAZ acusando que foi autorizado a inutilização. Esse arquivo no meu entendimento só devemos enviar para o escritório de contabilidade. Você poderia postar em anexo o XML que aparece esse erro de: Arquivo XML não é do tipo Compartilhamento para que possamos analisar?

Bom dia Daniel, O problema em si não é a rotina do nosso amigo Cleonir e sim o XML de consulta gerado pelo componente e enviado para SEFAZ. Esse XML possui a TAG <xServ> onde consta a descrição do serviço a ser executado pelo Web Service, que por sinal até hoje não sei o motivo dessa TAG, uma vez que a TAG principal do XML é <consMDFeNaoEnc> e por ela acredito que o Web Service seja capaz de identificar o que desejamos. Mas tudo bem, na Nota Técnica 2015/001 página 5 temos a estrutura dessa consulta, nota-se que o conteúdo da TAG <xServ> é: CONSULTAR NÃO ENCERRADOS. Veja que a palavra: não, tem a vogal acentuada. Esse é o primeiro caso, e é ai onde mora o problema, se não acentuar o XML será rejeitado pois no schema o conteúdo dessa TAG esta definida da seguinte forma: <xs:element name="xServ" type="TServ" fixed="CONSULTAR NÃO ENCERRADOS"> Sendo assim temos que gerar o XML dessa consulta em UTF8 de tal forma que o conteúdo da referida TAG esteja de acordo com o schema.

Bom dia, Como você faz referencia a NF-e e NFC-e, acredito que você postou em lugar errado, pois aqui estamos tratando da NT 2015/003 do CT-e e não da NT de mesmo numero da NF-e. Mas como essas duas NT tratam do mesmo assunto vamos abrir a NT na página 6: Temos as regras sobre o grupo <ICMSUFDest>, delas podemos concluir varias coisas: 1. pela regra NA01-10 a nota cujo modelo é 65 (NFC-e) será rejeitada se for informado o grupo <ICMSUFDest>, podemos então concluir que só vamos gerar esse grupo para a NF-e. 2. pela regra NA01-20 o grupo <ICMSUFDest> deve ser informado quando <idDest>=2 (Operação Interestadual) e <indFinal>=1 (Consumidor Final) e <indIEDest>=9 (não contribuinte do ICMS). Podemos concluir que o grupo <ICMSUFDest> deverá ser gerado quando vendermos para uma pessoa física situada em outro Estado, portanto ela não é contribuinte do ICMS e é um consumidor final. Espero ter ajudado.

José, Como você utiliza o ACBrNFeMonitor acredito que não tem como. Para quem desenvolve em Delphi temos o componente ACBrMail, com ele podemos anexar quantos XML desejarmos e enviar.

Boa tarde José, Eu não utilizo o ACBrNFeMonitor e nem participei do seu desenvolvimento, essas respostas vou lhe ficar devendo.

Boa tarde Allan, Como dito no que se refere a evento no ACBrNFe tudo é feito pela mesma rotina. Se o cancelamento foi protocolado pela SEFAZ, o que pode ser: 1. Quando você emitiu a CC-e a SEFAZ estava com algum problema e retornou aquela rejeição e agora esse problema foi sanado. 2. ou na verdade o erro é outro, mas a SEFAZ retornou que o erro era na assinatura. 3. ou a SEFAZ esta com algum erro ao tratar o evento CC-e.

Boa tarde Henrique, A carta de correção é um evento, e o envio de evento por e-mail já foi implementado.

Verifique se no Library Path do Delphi a pasta ...\Fontes\ACBrCapicom vem antes de ...\Fontes\ACBrDFe.

Boa tarde, O programa exemplo do ACBrCTe ainda esta com o DACTE feito em Quick Report, dai o erro.

Bom dia Rodrigo, A function SituacaoNFeToStr mudou de nome, agora ela se chama: SituacaoDFeToStr.

Bom dia Jairo, A SEFAZ criou um Web Services chamando DistribuicaoDFe para que possamos obter em um primeiro momento um resumo da NF-e e se efetuarmos a manifestação do destinatário teremos em uma nova consulta o XML completo da NF-e. Algo semelhante a SEFAZ criou um Web Services também chamado DistribuicaoDFe mas para o MDF-e - Manifesto Eletrônico de Documentos Fiscais que estará se não me falha a memória em outubro deste ano. Acredito que a SEFAZ irá criar também um DistribuicaoDFe para o CT-e, vamos aguardar. Desconfio que a Nota Técnica sobre esse Web Services seja a de numero 2, note que no Portal Nacional do CT-e temos a Nota Técnica 2015/001 e a 2015/003 esta faltando a de numero 002, estranho você não acha? Agora me diz, você quer baixar o XML para resolver o problema de quem, do emitente do CT-e ou do tomador do serviço? Se for do emitente, lembre-se que você pode gerar e assinar novamente o CT-e tomando o cuidado de gerar com a mesma chave e depois com o componente carregado com o respectivo XML, basta executar o método Consultar, este vai buscar a situação atual do CT-e e vai atualizar o XML acrescentando ao mesmo o protocolo de autorização. Espero ter ajudado.

Bom dia Rodrigo, Analisando o seu XML de CC-e notei erro de conceito e de preenchimento. Conceito: o campo nroItemAlterado só deve ser informado quando a informação ser alterada pertence a uma lista e neste caso você informa a posição dentro dessa lista. Exemplo: Motorista, podemos informar o nome e o CPF de um ou mais motoristas, suponha que foi informado 3 motoristas e o nome do segundo esta errado e você deseja efetuar a correção através da CC-e. Como alimentar os campos da CC-e: grupoAlterado = moto campoAlterado = xNome valorAlterado = <informar aqui o nome correto do motorista> nroItemAlterado = 2 Como é o segundo nome da lista que esta errado foi informado a posição 2 ao campo nroItemAlterado. Preenchimento: se você abrir através de um navegar o arquivo 0-ped-eve-soap.xml vai notar que o campo: valorAlterado esta vazio, ou seja você não esta informando o novo valor do campo alterado. Outra coisa o nome do grupo e do campo tem que seguir a nomenclatura do XML, sendo assim esta errado informar: Ide o correto é ide (tudo em minusculo). Faça as devidas correções e tente novamente.

Bom dia, Qual ambiente, homologação ou produção? Você esta usando os fontes do Trunk ou Trunk2? Checou a validade do certificado?