Italo Giurizzato Junior

Boa tarde Silva, Até onde sei a emissão da NFS-e Padrão Nacional nessa primeira etapa do projeto piloto é via site e não via webservice.

Boa tarde Adilson, O programa exemplo não esta configurado? Outra coisa, esse XML que você anexou se refere ao RPS e não a NFS-e. Para imprimir o DANFSE devemos carregar o XML da NFS-e.

Boa tarde, É preciso ter os shemas de validação, o manual com o layout do XML, as URLs de homologação e produção para começar. Pelo XML que você anexou, deu para nota que não segue a ABRASF, sendo assim será necessário criar uma unit para gerar o XML. Fazer alterações nas unit que fazem a leitura dos retornos de envio, consulta, etc

Bom dia Fernando, Faça o seguinte teste: Na Unit ACBrANeWebServices altere a linha: FPDFeOwner.SSL.UseCertificateHTTP := True; para FPDFeOwner.SSL.UseCertificateHTTP := False;

Boa tarde Fabio, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Boa tarde André, Em vez de libWinCrypt tenta com libCapicom.

Boa tarde Adilson, Com certeza esse DANFSE deve estar com algum erro. Infelizmente não conheço o Fast Report, logo não saberei como descobrir onde esta o erro e fazer as devidas correções.

Boa tarde Tulio, Qual é o valor de SSLLib?

Entre em contato com o provedor e questione sobre o ambiente de homologação.

Boa tarde Marcio, E como que fica as demais cidades que se utilizam do mesmo provedor? Todas elas tiveram as suas URLs (Homologação e Produção) também alteradas? Pelo que me recordo somente essa cidade estava com a URL diferente das demais E por conta dessa falta de padronização que foi necessário colocar o IF no ACBrNFSeConfiguracoes. Temos que garantir que o componente funcione para todas as cidades do respectivo provedor.

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

Acredito que no de produção vai funcionar.

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

Creio que não é, veja a URL da cidade de Jaguariuna/SP que contratou o provedor Giss: https://ws3524709.giss.com.br/nf/nfse-ws Marilia contratou o provedor: SigISS

Boa tarde Marcos, A Unit pnfsNFSeW_Equiplano a alteração que você fez acredito que não esta correta, pois o GerarXML se refere ao gerar o XML do RPS que vai ser enviado, não pode ser ai o que você quer fazer. A Unit ACBrNFSeWebServices, que você fez alteração esta desatualizada, favor atualizar e aplique novamente a alteração. A Unit pnfsNFSeR esta ok, assim que possível vou enviar para o repositório.

Boa tarde Henrique, Ao atualizar os fontes você notou que o arquivo INI do provedor infisc-v11 foi alterado? Você esta usando o novo INI?

Boa tarde, Esta configurado para o ambiente de homologação ou produção? No de homologação estou tendo erro de timeout, já no de produção esta enviando sem nenhum problema e esta retornando o protocolo que atesta que recebeu o Lote de RPS.

Você tem certeza que a empresa contrata pela prefeitura de Marilia é Giss? Esse XML não tem nada haver com o layout da ABRASF. Como disse antes o provedor Giss segue a versão 2 do layout da ABRASF.

Pessoal, Nessa segunda postagem sobre o grupo de Informações do Responsável Técnico, vou colocar o posicionamento de cada SEFAZ se vão exigir ou não, a medida que eu tomar conhecimento. SEFAZ-SP nesse primeiro momento não vai exigir. SEFAZ-RS nesse primeiro momento não vai exigir. SEFAZ-MS vai exigir o grupo.

Boa tarde Pessoal, Primeiro foi o CT-e e o MDF-e a ter o seu layout alterado para contemplar um novo grupo: <infRespTec> Informações do Responsável Técnico, agora esta chegando a vez da NF-e. Os 3 componentes já estão preparados para gerar esse grupo. Alguns desenvolvedores já estão gerando o grupo <infRespTec> para o CT-e e MDF-e, tanto em homologação quanto em produção. No caso da NF-e as datas previstas são: para o ambiente de homologação é 25/02/2019 e para produção é 29/04/2019 alterado para 03/06/2019 (conforme consta na versão 1.30 da NT 2018/005). Quero deixar claro que essas datas se referem ao prazo para que as SEFAZ finalizem a implementação em seus webservices, portanto somente a partir dessas datas é que poderemos enviar o XML da NF-e com esse grupo. Portanto, a partir do dia 25/02/2019 teremos um prazo de 3 meses para realizar os testes em ambiente de homologação. Outra coisa importante a ser dita é que esse grupo é opcional, mas vai ficar a critério de cada UF torna-lo obrigatório ou não. Quais são as informações que compõe esse grupo? O grupo <infRespTec> é composto pelos campos: CNPJ da empresa que desenvolveu o software, xContato é o nome da pessoa responsável pelo software, email e fone dessa pessoa ou da empresa. Caso você opte por gerar esse grupo independente da UF exigir ou não, as 4 informações acima deveram constar. Como dito acima os componentes ACBrNFe, ACBrCTe e ACBrMDFe já estão preparados para gerar o grupo <infRespTec>, para que isso ocorra basta acrescentar na sua rotina que alimenta o componente com os dados que vão fazer parte do XML as seguintes linhas... O exemplo abaixo é para a NF-e: with ACBrNFe.NotasFiscais.Add.NFe do begin (...) infRespTec.CNPJ := xCNPJ_RespTec; // CNPJ da Empresa infRespTec.xContato := xContato_RespTec; // Nome do Contato infRespTec.email := xEmail_RespTec; // email do Contato ou Empresa infRespTec.fone := xFone_RespTec; // fone do Contato ou Empresa end; As linhas em negrito acima são exatamente iguais para o CT-e e MDF-e. Nas Notas Técnicas da NF-e, CT-e e MDF-e que se refere a esse grupo tempos ainda mais dois campos: idCSRT e hashCSRT que vão ficar para uma segunda etapa. O CSRT - Código de Segurança do Responsável Técnico, trata-se de um código alfa numérico que será fornecido pela SEFAZ através de uma página própria ou por um webservice, conforme consta na Nota Técnica. Sendo assim, enquanto a SEFAZ não criar essa página ou webservice não temos como solicitar o CSRT e portanto não podemos incluir no XML o idCSRT que é um numero sequencial e o hashCSRT que é o resultado do hash (SHA1 - Base64) da concatenação do CSRT mais a chave do documento. Os componentes já possuem no rol de configurações, as propriedades idCSRT (Integer) e CSRT (String), nessa primeira etapa devemos atribuir o valor zero a idCSRT e uma string vazia para o CSRT, para que os campos: idCSRT e hashCSRT não sejam gerados. Os valores padrões estabelecidos pelo componente são: idCSRT = 0 e CSRT = '' (string vazia). Reforço que o preenchimento dessas propriedades só devem ser feitas a partir do momento que a SEFAZ lhe fornecer o idCSRT e o CSRT. Vamos supor que as UF: x, y e z venham a exigir o grupo <infRespTec> e criem uma pagina ou webservice para fornecer o CSRT, caso você tenha clientes usando ou seu software para emitir NF-e ou CT-e ou MDF-e será necessário solicitar o CSRT em cada uma das UF. Resumindo o CSRT fornecido pela UF x só é valida para os seus clientes dessa UF que usam o seu software. Quais são as UF que vão exigir o grupo <infRespTec> não sabemos, logo devemos ficar atentos. A minha sugestão é que o seu software gere esse grupo independente da UF exigir ou não, pois o dia que ela resolver exigir você não vai precisar fazer nada, pois já consta no XML o grupo. A questão agora é quanto ao CSRT, como dito anteriormente, vai ficar para uma segunda etapa visto que, se faz necessário a SEFAZ criar a página ou webservice. O meu conselho é que no seu software na tela de configuração tenha os campos: idCSRT e CSRT para que você possa informa-los assim que obter. Detalhe importante, os campos idCSRT e hashCSRT só serão gerados no XML e de forma automática dentro do grupo <infRespTec> a partir do momento que as propriedades de configuração: idCSRT e CSRT passarem a ter valores validos. O texto ficou longo, mas espero ter passado todas as informações necessárias para que vocês possam fazer as alterações em seus softwares e desta forma ficarem em conformidade com as nas Notas Técnicas. Para quem não leu as NT, por favor leiam. NT 2018/005 versão 1.20 - Alteração do layout da NF-e https://sourceforge.net/p/acbr/code/HEAD/tree/tools/DFe/NFe/NT/2018/ NT 2018/002 versão 1.01 - Alteração do layout do CT-e https://sourceforge.net/p/acbr/code/HEAD/tree/tools/DFe/CTe/NT/2018/ NT 2018/002 versão 1.02 - Alteração do layout do MDF-e https://sourceforge.net/p/acbr/code/HEAD/tree/tools/DFe/MDFe/NT/2018/

Boa tarde Wesclei, Na minha maquina não abre, tentei com o Chrome e com o Edge. Se for possível, baixe o material disponível compacta e anexa aqui no fórum. Desde já muito obrigado pela colaboração.

Boa tarde, O provedor Giss ele não segue a versão 2 do layout da ABRASF? Porque o layout do XML da NFS-e tem tags completamente diferentes da versão 2?

Boa tarde, Use o ";" ponto e virgula, pois na hora de imprimir o DANFSE o componente faz a quebra de linha.

Boa tarde, Tente usar o libCapicom, para ver se ocorre o mesmo erro.

Fernando, O seu código esta errado, pelo simples fato dele não realizar o envio. É preciso debugar para saber porque esta aparecendo a mensagem de que o certificado não foi informado.