Italo Giurizzato Junior

Cristian, Porque você inverteu a posição das TAGs Cnpj e InscricaoMunicipal? O correto é: <Prestador> <Cnpj>02457435000195</Cnpj> <InscricaoMunicipal>901466</InscricaoMunicipal> </Prestador> Porque você informou a Inscrição Municipal do Tomador sendo que este pode não ter? E alem disso esta invertido o correto é: <Tomador> <CpfCnpj> <Cpf>08528961826</Cpf> </CpfCnpj> <InscricaoMunicipal> xxxx </InscricaoMunicipal> </Tomador> Coloquei em negrito pois o Tomador pode não ter essa informação.

Bom dia Armando, Sim é só esses 2 Units a serem alteradas. Esta vendo como é fácil acrescentar uma nova cidade ao componente quando o provedor segue o padrão ABRASF, basta incluir as URLs e na Unit do provedor e o código IBGE da cidade na tabela de provedores que fica na Unit pnfsConversao. Muito obrigado pela colaboração, já esta disponível.

Cristian, Vamos a mais algumas alterações: Vide arquivo em anexo: Alterar.txt

Bom dia, Uma coisa é você emitir uma Nota de Serviço pelo site e outra pelo Web Services. Pelo site praticamente você esta informando os dados da nota, logo não existe o RPS. Por outro lado via Web Services requer que você gere um RPS envie este para o provedor que por sua vez vai gerar a Nota. Sendo assim a sua aplicação deve controlar a numeração sequencial dos RPS e o provedor controla a numeração sequencial das NFS-e. Vou fazer a alteração e disponibilizar quanto a cidade de Assis Chateaubriand e desde já muito obrigado pela colaboração.

Bom dia Idez, Qual foi o tipo de contingência? Dependendo da UF somente alguns tipos serão permitidos, por exemplo existe o tipo Off-Line, mas no Estado de São Paulo não será permitido, a principio o comerciante terá que optar pelo EPEC ou SAT.

Bom dia Carlos, A estrutura do XML do RPS é igual, mas o envelopamento que é diferente. Por isso que volto a frisar, se conseguir o envelope completo recepcionado pelo provedor e processado com sucesso ficaria muito mais fácil de fazer os ajustes. Se não desejar postar esse envelope completo no fórum, por conter dados reais de uma prestação de serviço, omita a estrutura do RPS que é que contem esses dados, ou envie ele completo para o meu e-mail. É preciso verificar junto ao provedor quais das duas URLs que devemos utilizar para o envio: a que só tem esse serviço implementado ou a que tem também o serviço de cancelamento. Isso é muito importante pois como disse o envelopamento do RPS é diferente.

Bom dia Cristian, Comparando o XML que você postou com o que o componente ACBrNFSe gera, no seu existe um grupo chamado <xmlEnvio> altere de: <xmlEnvio> (...) </xmlEnvio> para: <xml xmlns=""> (...) </xml>

Dércio, E o path do Quick Report contem o arquivo QR5RunDXE5.BPL ? Se não tem você deve incluir o path que contem o respectivo arquivo.

Boa tarde Leandro, Realize o seguinte teste: emita a carta 1 com a correção 1 depois emita a carta 2 com a correção 2. consulte a situação do CT-e para saber se é retornado na lista de eventos os dois eventos (carta de correção). se constar somente a correção 2, então faça outro teste. emita a carta 1 com a correção 1 depois emita a carta 2 com a correção 1 e 2. consulte a situação do CT-e para saber se é retornado na lista de eventos os dois eventos (carta de correção). Um dos dois deve funcionar.

Fabio, Você terá que usar o componente configurado para utilizar a DLL Capicom. Você deverá informar somente o numero de série do certificado. Estude o programa exemplo.

Boa tarde, Se não me falha a memória o ACBrNFeMonitor já esta preparado para emitir alem da NF-e o MDF-e também. Os comandos são idênticos os da NF-e, bastando alterar o NFe por MDFe, as sintaxes também são muito parecidas. O maior problema é a montagem do arquivo TXT a ser enviado para o monitor. Segue em anexo um exemplo: MDFe.txt Espero ter ajudado.

Boa tarde Dércio, Verifique no Library Path do Delphi em que posição esta o Path do Quick Repport, ele tem que estar antes dos Path dos componentes ACBr. Caso esteja antes verifique se o Path que consta contem o respectivo arquivo QR5RunDXE5, caso negativo, você deve incluir o Path onde o arquivo esta salvo e depois posiciona-lo de tal forma que fique antes dos Path dos componentes ACBr.

Boa tarde Celso, Implementei a cidade Porto Alegre/RS no provedor BHISS. Por favor realize os testes baseado nesse provedor. Não esqueça de utilizar os schemas que encontram-se na pasta BHISS, para validar o lote de RPS a ser enviado.

Boa tarde Carlos, Esse provedor pelo que notei, possui dois Web Services para recepcionar o RPS e gerar a NFS-e. Um deles só serve para isso e tem a estrutura que mencionei. Por outro lado o outro tem uma estrutura diferente e serve tanto para gerar a NFS-e quanto para cancelar. Vou fazer algumas alterações visando a utilização desse outro Web Services e vamos ver se conseguimos resolver o problema.

Boa tarde Paulo, Uma coisa é o status de retorno do envio do lote de eventos para a SEFAZ e outra coisa é o status do evento. O que você esta pegando é o status do lote (128 = Lote processado com sucesso). Para pegar o status do evento: sStat := IntToStr(ACBrNFe.WebServices.EnvEvento.EventoRetorno.retEvento.Items[0].RetInfEvento.cStat);

Boa tarde a todos, Sim não existe mais. Antes foi implementado rotinas especificas para a carta de correção, com o surgimentos de novos eventos, foi criado uma rotina genérica que atende todos os eventos, tais como: Carta de Correção e Cancelamento. Se a sua aplicação já realiza o cancelamento por evento, compare a rotina para alimentar o componente com os dados e altere a rotina da CC-e.

Boa tarde Fabio, Sim, o certificado digital A1 ou A3 (cartão ou token) e-CNPJ pode ser utilizado sem nenhum problema, não hã necessidade de um certificado especifico para emitir o CT-e. O importante que esse e-CNPJ seja de uma empresa credenciada junto a SEFAZ a emitir CT-e. Se você possui uma empresa de desenvolvimento de software e possui o e-CNPJ, vai ser possível apenas utiliza-lo para assinar o XML, enviar o CT-e para SEFAZ, isso não será possível. Pelo simples fato de você não ser uma transportadora, logo a SEFAZ não vai te credenciar a emitir CT-e.

Bom dia, Muito obrigado pela colaboração, já esta disponível.

Bom dia a todos, Mesmo que hoje ainda esteja em fase de teste (projeto piloto) deve utilizar a versão 3.10

Bom dia Fabio, Acredito que você deva ter entendido errado, ou eu escrito algo errado. De qualquer forma: Sou uma pessoa física, e nunca comprei um certificado digital. Quando iniciei o desenvolvimento da minha aplicação, utilizei um certificado A1 disponibilizado pela SEFAZ-RS. Este certificado só serve para assinar o XML, não é possível estabelecer uma conexão com a SEFAZ utilizando esse certificado. Os testes que realizei de envio para SEFAZ foi utilizando o certificado de um cliente. Infelizmente as SEFAZs não disponibilizam ou permitem que você adquira um certificado e seja credenciado na SEFAZ para só e somente só utilizar o ambiente de homologação.

Bom dia Daniel, A SEFAZ não faz uso dessa informação para nada, é apenas uma informação para o consumidor final, para que este fique com mais raiva do governo sabendo o quando o mesmo embolsa quando compramos um produto. O importante é a informação aparecer no papel. Me parece que vai sair uma nova versão do Manual de especificação do DANFE NFC-e e nessa nova versão não vai mais constar a seção V do DANFE, seção esta onde é impresso o valor aproximado dos tributos. Os tributos segmentados deverão ser informados na área de informações complementares, isso deverá constar também na nova versão do manual. Vamos aguardar.

Bom dia André, Fiz uma alteração no ACBrNFeWebServices e já esta disponível, por favor atualize os fontes e compile novamente o monitor para ver se o problema é sanado quanto a mensagem de Disgest Value não confere.

Boa tarde Daniel, É possível fazer uma alteração no DANFE NFC-e para que se o vTotTrib for zero a banda não seja gerada. Neste caso você deixaria o vTotTrib com o valor zero e os tributos segmentados colocaria nas informações complementares. Atualize os fontes e teste, alimentando vTotTrib com o valor zero para todos os itens e consequentemente para o total também.

Boa tarde Celso, Esse provedor realmente não esta implementado. Para implementar é preciso obter algumas informações: Segue o padrão ABRASF? Quais são as URLs de homologação e de produção? Schemas; Exemplos dos XMLs de envio e de retorno.

Boa tarde a todos, Acessei o endereço: "http://financas2.barradogarcas.mt.gov.br:8080/SCEM/servlet/agerarnfse_barradogarcas?wsdl" E constatei o seguinte: URL para gerar a NFS-e em ambiente de produção é: "https://financas2.barradogarcas.mt.gov.br:8080/SCEM/servlet/agerarnfse_barradogarcas" SoapActuon é: "http://www.abrasf.org.br/nfse.xsdaction/AGERARNFSE_BARRADOGARCAS.Execute" A mensagem de entrada possui a seguinte estrutura: <gerarnfse_barradogarcas.Execute> <Entrada> <Rps> (...) </Rps> </Entrada> </gerarnfse_barradogarcas.Execute> O arquivo a seguir contem a mesma estrutura dentro do grupo <Body>. 17-ger-nfse-soap.xml E ao enviar temos como resposta o seguinte arquivo: 17-lista-nfse-soap.xml Note que ele apresenta uma mensagem de falha de processamento: <faultstring>Error reading Rps Error reading Entrada Error reading gerarnfse_barradogarcas.Execute</faultstring> Diz que ocorreu um erro ao ler o Rps. Eu achei estranho essa definição que encontra-se no WSDL: <complexType name="tcCpfCnpj"> <all> <element name="Cpf" type="xsd:string"></element> <element name="Cnpj" type="xsd:string"></element> </all> </complexType> Uma vez que no Schema temos: <xsd:complexType name="tcCpfCnpj"> <xsd:choice> <xsd:element name="Cpf" type="tsCpf" minOccurs="1" maxOccurs="1" /> <xsd:element name="Cnpj" type="tsCnpj" minOccurs="1" maxOccurs="1" /> </xsd:choice> </xsd:complexType> Pelo WSDL me leva a crer que as duas TAGs: Cpf e Cnpj devem constar no XML o que contradiz com o Schema que deixa claro que apenas uma deles deve constar. Volto a dizer que se nos fossemos fornecido um XML completo que foi recebido pelo Web Service e o mesmo foi processado com sucesso ficaria muito mais fácil fazer os devidos ajustes.