Italo Giurizzato Junior

Bom dia a todos, No caso da NFS-e temos alguns passos a seguir: 1. Verificar se a cidade em questão se encontra no arquivo Cidades.ini, esse arquivo esta na pasta: ...\Exemplos\ACBrDFe\ACBrNFSe\ArqINI 2. Se não existe é preciso entrar em contato com a prefeitura para saber qual é a empresa que foi contratada para implementar a NFS-e na cidade. Essa empresa chamamos de provedor. 3. Verificar se na mesma pasta indicada acima existe um arquivo INI com o nome do provedor. 4. Se sim, basta incluir a cidade no arquivo Cidades.ini aos moldes das demais que se utilizam do mesmo provedor. 5. É importante obter as URLs de homologação e de produção desse provedor para a cidade em questão, pois em alguns casos devemos informar um fragmento dessas URLs no arquivo Cidades.ini 6. Por fim utilizar o programa exemplo do componente ACBrNFSe para iniciar os testes. Agora se o provedor não existe, vai ser necessário descobrir se ele segue a versão 1 ou 2 do layout da ABRASF ou se possui um layout próprio para que seja possível implementar ele no componente. Se ele possui um layout próprio o tempo e a dificuldade de implementar será grande comparada com os que seguem a ABRASF. Espero ter dado um norte.

Bom dia, Eriq e Farnetani muito obrigado pela contribuição, ainda hoje estarei enviando para o repositório.

Bom dia a todos, O evento Prestação de Serviço em Desacordo é emitido pelo tomador do serviço e não pela transportadora, sendo assim não se faz necessário o tomador estar habilitado a emitir o CT-e, muito pelo contrario. Devemos lembrar que o tomador pode ser o remetente da carga ou o destinatário ou o Expedidor (transportadora) ou Recebedor (transportadora). Observação: O Expedidor e Recebedor como dito acima são transportadoras, estas aparecem no CT-e quando o transporte da carga envolve outras transportadoras para que a mercadoria vá do remetente até o destinatário, logo temos o tipo de serviço Redespacho ou Redespacho Intermediário.

Boa noite Leonardo, Não tenho condições de testar, pois além de não ter um certificado digital, não tenho nenhum cliente que emite a GNRE. Logo acabo fazendo alterações que julgo que vai funcionar e fico no aguardo de um retorno de quem utiliza, mas vou voltar a verificar a rotina para ver se descubro algo que possa estar ainda errado. Quanto a informar o produto, você tem algum XML de GNRE a ser enviado que contenha essa informação?

Boa noite Onyx, Você alterou o componente para que a tag <qVol> seja gerada com 2 casas decimais, correto? Gerou o XML e mandou imprimir o DANFE, correto? Foi impresso da forma que o seu cliente deseja, correto? Depois assinou e tentou validar, correto? Ocorreu erro na validação? Com certeza sim, pois veja como esta definido no schema da SEFAZ essa tag: <xs:element name="qVol" minOccurs="0"> <xs:annotation> <xs:documentation>Quantidade de volumes transportados</xs:documentation> </xs:annotation> <xs:simpleType> <xs:restriction base="xs:string"> <xs:whiteSpace value="preserve"/> <xs:pattern value="[0-9]{1,15}"/> </xs:restriction> </xs:simpleType> </xs:element> Na linha: <xs:pattern value="[0-9]{1,15}"/> Esta claro que a tag <qVol> pode conter de 1 até 15 caracteres que estejam dentro do dominio [0-9], ou seja, somente dígitos. Na linha a baixo é um patter de uma tag que aceita até 15 dígitos, sendo 13 de corpo (parte inteira) e 2 decimais. <xs:pattern value="0|0\.[0-9]{2}|[1-9]{1}[0-9]{0,12}(\.[0-9]{2})?"/> Deu para perceber bem a diferença. Resumindo não ainda você fazer a alteração que você fez pois o Schema não vai aceitar um numero real onde se espera um numero inteiro. Mas vamos em frente e atrás vem gente. Mantenha a sua alteração e comente a linha que realiza a validação do XML, desta forma, não vai ocorrer o erro de validação e o XML vai ser enviado para a SEFAZ. Veja a linha que deve ser comentada a baixo: function TACBrNFe.Enviar(const ALote: String; Imprimir: Boolean; Sincrono: Boolean; Zipado: Boolean): Boolean; var i: integer; begin WebServices.Enviar.Clear; WebServices.Retorno.Clear; (...) NotasFiscais.Assinar; // NotasFiscais.Validar; Linha comentada para não realizar a validação do XML antes do seu envio Result := WebServices.Envia(ALote, Sincrono, Zipado); (...) end; end; Se a SEFAZ aceitar a tag <qVol> como sendo um numero real em vez de inteiro, podemos concluir duas coisas: 1. A SEFAZ não valida essa informação, ela simplesmente trata ela como sendo uma simples string com no máximo 15 caracteres. 2. A SEFAZ valida essa informação, logo os schemas disponibilizados por ela a anos esta errado a definição dessa tag. Estou ansioso em saber se a nota foi autorizada ou não.

Boa tarde, Você esta atribuindo a BC ao campo: vBCFCPUFDest? Pois se não estiver, a tag vai ser gerada com o valor zero.

Boa tarde, Verifique se você não esta definindo um nome para o PDF na propriedade NomeDocumento. Se sim, este deve estar acompanhado do Path, caso contrario vai ser salvo na pasta que contem o executável.

SEFAZ Paraíba disponibilizada na SVRS Comunicamos que o ambiente de autorização da SVRS está habilitado para emissão de NF3e para o estado da Paraíba nos ambientes de homologação e produção. NF3e - Nota Fiscal de Energia Elétrica Eletrônica. Fonte: Portal DFe SVRS

Boa tarde Tulio, Muito obrigado pela informação, já foi feito a alteração e enviado para o repositório.

Bom dia, Engraçado ontem acessei o site da prefeitura de Matias Barbosa e constava que a empresa contratada para emissão da NFS-e é a GeNFe. O site continua com o antigo, não mudaram ainda? Ou esse Futurize na verdade é a GeNFe?

Bom dia Beto, Tem que usar o programa exemplo e não a sua aplicação. Se funcionar com o programa exemplo ai você compara a rotina que configura o componente do programa exemplo com o seu.

Bom dia Valter, Para eliminar a duvida, vai ser necessário entrar em contato com o provedor e questionar sobre o respectivo campo.

Bom dia Diego, Muito obrigado pelo retorno e pela correção, já enviei para o repositório.

Camilo, Resumindo o que o Juliomar lhe passou: Se o certificado digital for A1 e não estiver instalado você informa o path + nome do PFX no campo Caminho que se encontra no quadro Certificado e a senha do mesmo no campo Senha e não informe o numero de serie do mesmo. Essa configuração da para ser utilizado com o libOpenSSL e libWinCrypt. Se o certificado for A1 e estiver instalado, você só informa o numero de serie. Se o certificado for A3, informe somente o numero de serie e só pode ser utilizado com o libWinCrypt. Todos os MDF-e não importa de qual UF é o emitente, o componente redireciona para a SVRS - SEFAZ-Virtual do Rio Grande do Sul e esta por sua vez só aceita o TLS 1.2, portanto em SSLType o valor obrigatoriamente tem que ser LT_TLSv1_2.

Bom dia Valter, Se tratando de NFS-e tudo é possível. Os provedores que seguem o layout da ABRASF temos um campo chamado Serie onde devemos informar a série do RPS, já os provedores que não seguem o layout da ABRASF costumam mudar o nome do campo para SerieRPS e outros. Onde você viu o campo SeriePrestacao? No final acredito eu que apesar do nome do campo ser diferente, faz referencia a mesma informação, ou seja, a série do RPS.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Beto, Você esta fazendo testes usando o programa exemplo?

Bom dia Beto, Informe o numero do lote no método que esta usando para o envio no caso o Enviar. Vide o programa exemplo.

Bom dia Maiquel, Assim que você tiver uma lista das cidades que necessitam da assinatura e das que não necessitam, por favor crie uma postagem e coloque essa lista. Pois estou trabalhando no Refactoring do componente ACBrNFSe e vai ser possível contornar esse problema com nova versão do componente.

Bom dia Camilo, Tenha em mente o seguinte: As rotinas responsáveis por assinar, validar estabelecer a conexão com a SEFAZ, enviar, obter o retorno é única, ou seja, a rotina que assina o XML da NF-e é exatamente a mesma que assina os demais DF-e. Outra coisa, acredito que hoje nenhuma SEFAZ-Autorizadora aceita a criptografia diferente de TLS 1.2, sendo assim o valor de SSLType tem que ser TL_TLS1_2 e o valor de SSLLib não pode ser libCapicom uma vez que este não suporta o TLS 1.2 Se o certificado digital for A1, você pode usar o libOpenSSL, desta forma tanto faz se o Windows esta atualizado ou não. Não misture os schemas da NF-e com do CT-e e com do MDF-e, tenha uma pasta de schemas para cada DF-e que a sua aplicação emite. As versões vigentes da NF-e/NFC-e é 4.00 do CT-e e MDF-e é 3.00 Antes de iniciar a implementar qualquer DF-e ou outra funcionalidade como por exemplo emissão de boleto usando o ACBrBoleto, procure sempre fazer testes com os programas exemplos. Temos um programa exemplo para cada componente ACBr. Além do componente, o programa exemplo é o que existe de comum entre nós. Como o Juliomar deixou claro, não conhecemos a sua aplicação não sabemos como você esta implementado. Se no programa exemplo funciona, você precisa estudar a rotina de configuração do componente no programa exemplo para saber o que esta faltando na rotina de configuração da sua aplicação. Espero ter ajudado.

Boa tarde André, Muito obrigado pela informação, assim que possível vou fazer a alteração no arquivo INI do provedor e enviar para o repositório.

Boa tarde Maiquel, Testou os 3 métodos de envio? Fez testes também em ambiente de produção? Pois tem provedor que esquece de deixar o ambiente de homologação em perfeitas condições de uso.

Boa tarde, Vou analisar o que você fez, assim que possível darei um retorno. Desde já muito obrigado pela colaboração.

Bom dia Eduardo, Esse provedor possui um layout próprio é preciso verificar se a rotina que faz a leitura do XML já esta preparada para ler esse layout. Se não estiver vai ser necessário fazer as alterações necessárias. Caso queira contribuir com o projeto, fique a vontade.

Boa tarde Carlos, Se para esse provedor se faz necessário ter uma terceira assinatura no que se refere a Substituição de NFSe, teremos que fazer uma alteração no componente, pois ele não contempla essa terceira assinatura. Uma vez que esse provedor é o primeiro a requerer isso.