Italo Giurizzato Junior

Prezados Representantes das Empresas Desenvolvedores de aplicações para emissão e gestão de NF-e/NFC-e, Informo que a SEEC/DF irá iniciar, em 01/11/2020, a exigência, em produção, do preenchimento do campo relativo ao Código de Benefício Fiscal - cBenef, com as Regras de Validação - RV estabelecidas na NT 2019.001, versão 1.50, conforme estabelecido no art. 3º da Portaria SEEC nº 386/2019. O Ato Declaratório COREN nº 01/2020, definiu a Tabela de Código Benefício Fiscal por CST que deverá ser utilizada pelas empresas para realização da configuração das aplicações responsáveis pela emissão e gestão de NF-e/NFC-e. Esclareço que todas as RV constantes do item 3.6.1 da Nota Técnica (N12-85, N12-86, N12-90, N12-94, N12-97 e N12-98) serão aplicadas nos moldes estabelecidos, bem como suas respectivas exceções 2, 3 e 4. Por fim, seguem os links para a legislação e a Tabela com os Códigos por CST: * Portaria SEEC/DF nº 386/2019 - [[http://www.fazenda.df.gov.br//aplicacoes/legislacao/legislacao/TelaSaidaDocumento.cfm?txtNumero=386&txtAno=2019&txtTipo=7&txtParte=.]] * Tabela de Código Benefício Fiscal por CST – Ato Declaratório COREN nº 01/2020 – SEEC/DF - [[http://www.fazenda.df.gov.br/aplicacoes/legislacao/legislacao/TelaSaidaDocumento.cfm?txtNumero=1&txtAno=2020&txtTipo=734&txtParte=.]]

Boa tarde Cristofer, Conseguiu implementar? Caso não teve tempo, você tem o manual referente a versão 2 que mostra como deve ser gerado o XML contendo varias guias e vários documentos na mesma guia?

Bom dia Diego, Já enviei para o repositório a sua correção, mais uma vez muito obrigado.

Bom dia Ramalho, Quais são as URLs de homologação e produção da cidade de Pires do Rio?

Bom dia Mesquita, O problema é simples, veja no Schema a definição do elemento EnviarLoteRpsEnvio: <xsd:element name="EnviarLoteRpsEnvio"> <xsd:complexType> <xsd:sequence> <xsd:element name="IdentificacaoRequerente" maxOccurs="1" minOccurs="1" type="tcIdentificacaoRequerente"/> <xsd:element name="LoteRps" type="tcLoteRps"/> </xsd:sequence> </xsd:complexType> </xsd:element> Note que antes do elemento "LoteRps" foi incluído por esse provedor o elemento "IdentificacaoRequerente". A mensagem de erro de validação deixa claro isso. Vamos simplificar e traduzir a mensagem de erro: mensagem original: Element '{http:\\shad.elotech.com.br\/schemas\/iss\/nfse_v2_03.xsd}LoteRps' is unexpected according to content model of parent element '{http:\\shad.elotech.com.br\schemas\iss\nfse_v2_03.xsd}EnviarLoteRpsEnvio'.Expecting: {http:\\shad.elotech.com.br\/schemas\/iss\/nfse_v2_03.xsd IdentificacaoRequerente} Simplificando: Element LoteRps is unexpected according to content model of parent element 'EnviarLoteRpsEnvio'. Expecting: {IdentificacaoRequerente} Traduzindo: O elemento LoteRps é inesperado de acordo com o modelo de conteúdo do elemento pai 'EnviarLoteRpsEnvio'. Esperando: {IdentificacaoRequerente}. Conforme o fragmento do Schema colocado acima, dentro do elemento EnviarLoteRpsEnvio deve vir primeiro o elemento IdentificacaoRequerente e depois o LoteRps. Sendo assim se faz necessário uma alteração na unit pnfsNFSeG, mais precisamente na função Gera_DadosMsgEnviarLote. Veja esse fragmento dessa função onde foi feita uma alteração semelhante para o provedor SigEp. else begin if Provedor = proSigep then begin Gerador.Prefixo := Prefixo4; Gerador.wGrupo('credenciais'); Gerador.wCampo(tcStr, '#01', 'usuario ', 01, 15, 1, UserWeb); Gerador.wCampo(tcStr, '#02', 'senha ', 01, 05, 1, SenhaWeb); Gerador.wCampo(tcStr, '#03', 'chavePrivada', 01, 01, 1, ChaveAcessoPrefeitura); Gerador.wGrupo('/credenciais'); end; Gerador.Prefixo := Prefixo3; if Provedor in [proCoplan, proSIAPNet] then Gerador.wGrupo('LoteRps' + FaVersao + FaIdentificador) else Gerador.wGrupo('LoteRps' + FaIdentificador + FaVersao + FaNameSpace); (...) No caso do provedor SigEp antes do elemento LoteRps existe o elemento credenciais. Caso queira contribuir com o projeto, faça a alteração e anexe a unit alterada para que possamos analisar.

Bom dia a todos, Deixo aqui uma dica. Quando começa um problema de conexão sem nenhuma alteração na sua aplicação, com certeza o problema é no provedor. Não adianta ligar para o provedor, pois eles sempre vão negar que o problema é no webservice. O melhor caminho é solicitar ao seus clientes que abram um protocolo na prefeitura relatando o problema. Lembre-se que o provedor recebe da prefeitura e não de você, logo esta se lixando com você. Agora os contribuintes reclamando com a prefeitura que não conseguem emitir notas a coisa muda de figura.

Bom dia Douglas, Tem provedor que o layout do XML baixado do site é diferente do XML gerado pelo webservice.

Bom dia Wanderson, Você definiu as margens via código?

Bom dia, Ao emitir um MDF-e onde o responsável pelo transporte é um TAC - Agregado ou equiparado TAC, devemos informar no MDF-e as informações do pagamento do Frete ou enviar o Evento de Pagamento da Operação de Transporte quando o serviço for finalizado. Resumindo: As informações do pagamento do frete devem ser enviadas para a SEFAZ. Se o pagamento ocorrer antes da realização do serviço, devemos gerar o MDF-e com o grupo <infPag>, por outro lado se o pagamento ocorrer após o termino do serviço, devemos enviar o Evento.

Bom dia André, Na unit pnfsConversao temos a função ProvedorToVersaoNFSe, você informa o provedor (enumerador) e ela retorna a versão do provedor, veja: function ProvedorToVersaoNFSe(const AProvedor: TnfseProvedor): TVersaoNFSe; begin case AProvedor of proABRASFv2, pro4R, proABase, proActconv2, proAgiliv2, proBethav2, proCoplan, proDigifred, proeReceita, proFIntelISS, proFiorilli, proGoiania, proGovDigital, proISSDigital, proISSe, proLink3, proMitra, proNEAInformatica, proNotaInteligente, proProdata, proPronimv2, proPVH, proSaatri, proSiam, proSisPMJP, proSystemPro, proTecnos, proVirtual, proVitoria, proVersaTecnologia, proSafeWeb, proWebISSv2, proSH3, proSiapNet, proISSJoinville, proSmarAPDv2, proAsten, proELv2, proTiplanv2, proGiss, proDeISS, proTcheInfov2, proSigep, proDataSmart, proDesenvolve, proCenti, proRLZ, proSigCorp, proGiap, proiiBrasilv2, proSimplISSv2, proMegaSoft, proModernizacaoPublica, proElotech, proFuturize: Result := ve200; proInfiscv11, proLencois: Result := ve110; else Result := ve100; end; end; No "case" da função acima o provedor que não constar na lista iniciada por proABRASFv2 e que não for o Infisc e lencois acaba caido no "else", logo a versão 1. Temos também a função ProvedorToLayoutXML que retorna o layout do XML, veja: function ProvedorToLayoutXML(const AProvedor: TnfseProvedor): TLayoutXML; begin case AProvedor of proABRASFv1, proAbaco, proActcon, proBetha, ProBHISS, proCIGA, proDBSeller, proDSFSJC, proFISSLex, progeNFe, proGinfes, proGovBR, proISSCuritiba, proISSFortaleza, proISSIntel, proISSNet, proLexsom, proMetropolisWeb, proNatal, proNFSeBrasil, proPronim, proPublica, proRecife, proRJ, proSalvador, proSilTecnologia, proSimplISS, proSJP, proSpeedGov, proThema, proTinus, proTiplan, proWebISS: Result := loABRASFv1; proABRASFv2, pro4R, proABase, proActconv2, proAsten, proBethav2, proCenti, proCoplan, proDataSmart, proDeISS, proDesenvolve, proDigifred, proELv2, proElotech, proeReceita, proFIntelISS, proFiorilli, proFuturize, proGiss, proGoiania, proGovDigital, proiiBrasilv2, proISSDigital, proISSe, proISSJoinville, proLink3, proMegaSoft, proMitra, proModernizacaoPublica, proNEAInformatica, proNotaInteligente, proProdata, proPronimv2, proPVH, proRLZ, proSaatri, proSafeWeb, proSH3, proSiam, proSiapNet, proSigCorp, proSigep, proSimplISSv2, proSisPMJP, proSmarAPDv2, proSystemPro, proTcheInfov2, proTecnos, proTiplanv2, proVersaTecnologia, proVirtual, proVitoria, proWebISSv2: Result := loABRASFv2; proAgili, proAgiliv2: Result := loAgili; proEgoverneISS: Result := loEGoverneISS; proEL: Result := loEL; proEquiplano: Result := loEquiplano; proGoverna: Result := loGoverna; proInfisc, proInfiscv11: Result := loInfisc; proISSDSF, proCTA: Result := loISSDSF; proSiat: Result := loSiat; proSP: Result := loSP; proCONAM: Result := loCONAM; proSmarAPD: Result := loSmarAPD; proIPM: Result := loIPM; proGiap: Result := loGiap; proAssessorPublico: Result := loAssessorPublico; proSigISS: Result := loSigISS; proWebFisco: Result := loWebFisco; proLencois: Result := loLencois; else Result := loNone; end; end; Através desta função você sabe se o provedor segue o layout da ABRASF versão 1 ou 2 ou se tem um layout próprio.

Bom dia Will, Pelo que entendi o provedor resolveu de uma hora para outra mudar o layout do XML? Se sim, você consegue os Schemas e o manual que apresenta essas mudanças?

Bom dia Diego, Muito obrigado pela colaboração, vou incluir na minha lista de tarefas, assim que possível vou analisar a sua alteração.

Bom dia Beatriz, Essas URLs são do webservice ou do site? No arquivo INI devemos informar a URL do webservice. No arquivo SigISS.ini temos: [URL_P] RecepcaoLoteRPS=%NomeURL_P%/ws/sigiss_ws.php?wsdl GerarNFSe=%NomeURL_P%/ws/sigiss_ws.php?wsdl [URL_H] RecepcaoLoteRPS=%NomeURL_H%/ws/sigiss_ws.php?wsdl GerarNFSe=%NomeURL_H%/ws/sigiss_ws.php?wsdl Note que temos na URL a variável %NomeURL_P% para Produção e %NomeURL_H% para Homologação. Já no arquivo Cidades.ini temos: [3304904] Nome=Sao Goncalo UF=RJ Provedor=SigISS NomeURL_H=https://testenfse.pmsg.rj.gov.br:443 NomeURL_P=https://nfse.pmsg.rj.gov.br:443 A titulo de exemplo a cidade de São Gonçalo. Quanto o componente for acessar o webservice de São Gonçalo vai utilizar as URLs: Homologação -> https://testenfse.pmsg.rj.gov.br:443/ws/sigiss_ws.php?wsdl Produção -> https://nfse.pmsg.rj.gov.br:443/ws/sigiss_ws.php?wsdl Note que o componente automaticamente troca a variável pelo seu valor informado no arquivo Cidades.ini Favor verificar quais são as URLs de Produção e Homologação utilizadas no webservice para a cidade de Araras.

Boa tarde Lucas, Na Nota Técnica 2020/001 do MDF-e Integrado que trata sobre esse assunto não deixa claro isso. Mas acredito que deve ser um acordo entre o emitente do MDF-e e o TAC contratado. Se vai pagar adiantado informa no MDF-e, por outro lado se vai pagar somente quando terminar o serviço, não informa no MDF-e e envia o evento quando o serviço for concluído.

Boa tarde Douglas, Já enviei para o repositório a sua contribuição, muito obrigado.

Boa tarde João, Já enviei para o repositório a sua contribuição, muito obrigado.

Boa tarde Marcos, Já enviei para o repositório a sua contribuição, muito obrigado.

Bom dia Jeanny, Me recordo que ao emitir o CT-e Normal de MG deve constar a URL de MG na string do QR-Code, mas ao emitir em Contingência (SVC-SP) tinha que ser trocado para a URL da SVC-SP. Depois mudou não era mais para trocar, agora não sei mais em que pé esta essa confusão.

Bom dia, Muito obrigado pela informação, com certeza será útil para os demais desenvolvedores.

Bom dia Beatriz, No arquivo Cidades.ini, a cidade de Araras se utiliza do provedor SimplISS. Ela mudou para SigISS? Se sim, favor entrar em contato com a prefeitura ou com o provedor e solicitar as URLs de homologação e produção para que possamos atualizar o arquivo Cidades.ini

Bom dia Celson, O certificado não venceu?

Bom dia Sandro, Favor anexar a unit alterada para que possamos analisar o problema.

Bom dia Junior, Pelo que me recordo é diferente não sei como poderias parametrizar isso.

Bom dia Marcos, Muito obrigado pela contribuição, já inclui na minha lista de tarefas, assim que possível vou analisar.

Bom dia André, Em vez de consultar o lote, porque você não consulta a situação do lote?