Italo Giurizzato Junior

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.

Boa tarde Marcelo, Anexo o arquivo 3-Rps.xml, mesmo você carregando o XML do RPS os dados não foram passados, alguma coisa esta faltando, deve existir algum erro ou esta faltando algo a ser implementado.

Boa tarde, A alteração foi feita por mim e disponibilizada no repositório em 01/05/2015, sendo assim se os seus fontes foram atualizados depois dessa data, já estão enviando as notas para o novo endereço a um bom tempo.

Boa tarde, Você esta usando o Capicom ou OpenSSL ou CapicomDelphiSoap?

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 Luciano, Se a consulta for através do método Consultar NFS-e por RPS você pode obter o numero da nota através da seguinte linha: nNumNota := ACBrNFSe1.WebServices.ConsNfseRps.NFSeRetorno.ListaNfse.CompNfse.Items[X].Nfse.Numero; Onde X é igual a zero, uma vez que você esta consultando uma NFS-e através de um RPS.

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.

Bom dia, Primeiramente muito obrigado pela colaboração, vou analisar o que você fez e fazer as devidas correções e disponibilizar no repositório se possível ainda hoje. **** Arquivo INI para o provedor Saatri já encontra-se disponível no repositório Trunk2, por favor atualize todos os fontes e inicie os testes.

Essa função salva em disco o XML da NFS-e. Qual é o retorno que você necessita?

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.

Luciano, Se o numero do RPS é sequencial e controlado pela aplicação e mesmo assim o provedor de vez em quando acusa que já existe um RPS com o mesmo numero, só tem duas respostas para isso: 1. a emissão da nota é feita por duas ou mais maquinas e sua aplicação não esta controlando de forma eficiente a emissão de duas notas ao mesmo tempo. 2. ou existe algum bug na sua aplicação que esta provocando essa duplicidade. Quanto a consultar existe um método chamado ConsultarNFSePorRPS onde você informa alguns dados referente ao RPS e caso exista uma NFS-e gerada a mesma será retornada. Os parâmetros do método são: function ConsultarNFSeporRps(ANumero, ASerie, ATipo, ACnpj, AInscricaoMunicipal: String; ASenha: String = ''; AFraseSecreta: String = ''; ARazaoSocial: String = ''): Boolean; A Senha, FraseSecreta e RazaoSocial depende do provedor, a principio não precisa informar.

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

Boa tarde Luciano, Uma coisa é esse numero que você passa como parâmetro no método Gerar, outra coisa é o numero que você informa ao alimentar o componente com os dados pertinentes ao RPS.

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.