Italo Giurizzato Junior

Boa tarde Guilherme, Se não me falha a memória o provedor de Farroupilhas não consegue manter um padrão entre as cidades que ele atende. Ele coloca essa porcaria de tag <IdCidade> em lugares diferentes dependendo da cidade atendida. Ainda tem a capacidade de dizer que seguem o layout da ABRASF, segue porcaria nenhuma, no layout da ABRASF não existe o grupo <tcDeclaracaoPrestacaoServico>, <IdCidade>, <tcDadosServico>.

Bom dia Guilherme, Acredito que você não entendeu, a Juliana lhe pediu para anexar o arquivo do XML e não incluir ele na postagem como um texto. Da forma que você fez fica complicado a analise do mesmo.

Bom dia Marcos, Você não esta passando o CPF/CNPJ formatado com pontos, barra e traço? Não tem nenhum digito errado? Esta informando zero a esquerda para completar os 14 dígitos do CNPJ e 11 do CPF?

Bom dia, Você esta usando o arquivo GeisWeb.ini que se encontra no repositório? Pois nele esta sim informado o SoapAction do EnviarLoteRps, veja: [SoapAction] Recepcionar=urn:https://www.geisweb.com.br/producao/itatinga/webservice/GeisWebServiceImpl.php#EnviaLoteRps ConsSit=* ConsLote=urn:https://www.geisweb.com.br/producao/itatinga/webservice/GeisWebServiceImpl.php#ConsultaLoteRps ConsNFSeRps=* ConsNFSe=urn:https://www.geisweb.com.br/producao/itatinga/webservice/GeisWebServiceImpl.php#ConsultaNfse Cancelar=urn:https://www.geisweb.com.br/producao/itatinga/webservice/GeisWebServiceImpl.php#CancelaNfse Gerar=* RecSincrono=* Substituir=* O campo Recepcionar contem o referido SoapAction.

Bom dia Mesquita, Configura o componente para salvar os arquivos Soap eles podem dar uma pista para o problema. Configuracoes.WebServices.Salvar := True;

Bom dia Eduardo, Você esta com todos os fontes de todas as pastas atualizados? Esta fazendo testes usando o programa exemplo? Até onde sei a cidade de Vila Velha é atendida pelo provedor Vitoria e este requer que o conteúdo do grupo <mensagemXML> seja convertido em string, no XML que você anexou ele esta no formato XML. No arquivo Vitoria.ini temos: ; 0 = False / 1 = True (se True então converte Cabeçalho e Dados para String) [XML] Layout=ABRASFv2 VersaoDados=2.01 VersaoXML=2.00 NameSpace=http://www.abrasf.org.br/ Cabecalho=0 Dados=1 Dados=1 significa que a mensagem de dados, que neste caso é o conteúdo do grupo <mensagemXML> tem que estar no formato string. Se o valor de Dados for zero o conteúdo será um XML e não string. Esse pode ser o motivo do erro 400.

Bom dia, Como a Nota Técnica não deixa claro alguns pontos, vou me basear no seguinte paragrafo da NT 2020/001 versão 1.04 que trata do MDF-e Integrado: Geração de informações para facilitar a negociação de direitos de recebimentos de fretes, por parte do TAC, junto a instituição financeira onde possui conta corrente, sem a interferência de atravessadores. No meu entendimento a geração de informações de pagamento tanto no MDF-e quanto no envio do evento é para facilitar o recebimento do valor do frete contratado com o TAC. Uma transportadora que é responsável pelo transporte e o motorista é funcionário da mesma, acredito que o pagamento do frete já esta incluído no salario. Posso esta errado. Quanto ao grupo de produto predominante, existe uma regra de validação que diz que o grupo deve existir se o tpEmit for 1 ou 3, mas não existe nenhuma outra regra que diz que se o tpEmit for 2 não deva existir o grupo. Sendo assim não vejo problemas e informar o grupo.

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.