Italo Giurizzato Junior

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.

Boa tarde Stainle, Com o programa exemplo também ocorre o mesmo problema? Se não ocorre, a dica é estudar a rotina que configura o componente do programa exemplo.

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

Boa tarde Rejane, Já enviei as duas unit para o repositório. Muito obrigado pelos testes.

Por favor, faça mais um teste agora, mantenha a unit que enviei antes e a orientação no que diz respeito a alimentação do campo. E troca essa outra unit em anexo. pcnCIOTW_eFrete.pas A tag só vai ser gerada se o valor de EntregaDocumentacao for diferente de edNenhum.

Nilton, Já foi feito a correção, agora é só esperar o pessoal liberar uma nova versão do Monitor.

Bom dia Nilton, Muito obrigado pelo alerta, vamos verificar e fazer as devidas correções.

Rejane, Troque a unit por essa outra em anexo. pcnConversaoCIOT.pas Ao alimentar o componente atribua o valor edNenhum ao campo EntregaDocumentacao. É para gerar a tag vazia, vamos ver se vai ser aceito.

Sendo assim, precisamos criar um enumerador para essa tag chamada edNenhum que ao atribuir esse valor ao campo: EntregaDocumentacao, vai fazer com que a tag seja gerada vazia. Acredito que essa tem que ser a solução.

Bom dia Luis, Se tratando de evento temos 3 XMLs: (*-ped-eve.xml) trata-se do XML que é enviado para a SEFAZ, (*-eve.xml) trata-se do retorno da SEFAZ, (*-procEventoCTe.xml) resultado final do processamento, nada mais é do que a união dos outros dois XMLs. Para imprimir o evento devemos carregar o componente com o conteúdo desse ultimo XML. Caso você armazene no banco de dados o XML, o conteúdo completo é obtido através da leitura da propriedade: (...).EventoRetorno.retEvento.Items[0].RetInfEvento.XML