[Bruno]
-
Total de ítens
64 -
Registro em
-
Última visita
Tipo de Conteúdo
Blocks
Notes ACBrLibNFe
Fóruns
Downloads
Calendário
Posts postados por [Bruno]
-
-
22 horas atrás, Italo Giurizzato Junior disse:
Boa tarde Bruno,
Para podermos incluir no XML os caracteres #13 e #10, tanto o XML do RPS quanto o Lote de RPS não podem ser assinados.
Olhando a procedure Configuracao que esta na unit ISSRio.Provider notei que somente o pedido de cancelamento que deve ser assinado, achei estranho isso.
Pois normalmente quando o cancelamento requer assinatura, o RPS e ou o Lote de RPS deve ser assinado também.
Você pode verificar isso?
Boa tarde Ítalo,
Confirmei com o pessoal responsável pelo provedor questionando se os serviços web service como (Envio, Consulta e cancelamento) a assinatura do arquivo é opcional ou para alguns deles é obrigatória e eles me responderam o seguinte
"Prezado Sr. Bruno,A assinatura do arquivo XML é opcional.Para mais informações, sugerimos a leitura do item 3.7 do Documento Contendo as Instruções Básicas de Uso do Webservice, disponível em https://notacarioca.rio.gov.br >> Ajuda e Orientações >> Manuais de Ajuda >> Manuais Técnicos de Integração via Webservice."
-
14 horas atrás, Italo Giurizzato Junior disse:
Boa tarde Bruno,
Para podermos incluir no XML os caracteres #13 e #10, tanto o XML do RPS quanto o Lote de RPS não podem ser assinados.
Olhando a procedure Configuracao que esta na unit ISSRio.Provider notei que somente o pedido de cancelamento que deve ser assinado, achei estranho isso.
Pois normalmente quando o cancelamento requer assinatura, o RPS e ou o Lote de RPS deve ser assinado também.
Você pode verificar isso?
Bom dia, irei confirmar essas informações sim Ítalo!
-
4 horas atrás, Italo Giurizzato Junior disse:
Bom dia Bruno,
Que estranho, até onde sabemos a cidade do Rio de Janeiro/RJ possui um webservice próprio que chamamos de ISSRio.
Eles deixaram de usar o webservice próprio e contrataram o provedor IPM?
Boa tarde ítalo, desculpe a confusão, estou trabalhando em dois casos, quebra de linha para Rio de Janeiro/RJ e outra situação para a prefeitura de Gravataí que aí, sim, é provedor IPM, na hora de criar o título acabei informando nome do provedor errado, só depois que postei notei o erro, tentei editar/excluir o post, mas não encontrei nada para tal.
-
A única for que encontrei de conseguir enviar minha mensagem foi através do envio por imagem, caso contrário não estava sendo possível, estava sendo sempre bloqueado!
-
5 horas atrás, Italo Giurizzato Junior disse:
Bom dia Bruno,
Realmente da forma que esta hoje esta errado e a sua alteração ao meu ver pode ocorrer em uma outra situação.
Vamos supor que o prestador é da cidade A e o tomador da cidade B.
Eu entendo que "Local de Prestação do Serviço" é o local onde o serviço foi executado,
Sendo assim o a cidade de execução de serviço não seja do tomador e sim do prestador e até uma terceira cidade.
Acredito que o correto seria criar uma classe chamada LocalPrestServ onde teríamos os dados do Local de Prestação do Serviço.
O que você acha?
Boa tarde Ítalo, acredito que dessa forma que você sugeriu irá resolver de vez todas as situações!
-
Boa tarde, cliente me reportou a seguinte situação, prestador Cotia/SP tomador Itapevi/SP, ao gerar a nota fiscal e acessar o portal para visualizar a nota fiscal é demonstrado que a cidade serviço é Cotia/SP.
Na impressão da nota fiscal os dados do tomador estavam corretos (Itapevi/SP), analisando o manual da prefeitura notei que os dados que devem ser enviados para (DadosServico) é sobre local prestação serviço.
Ao analisar a unit Giap.GravaXml.pas notei que estava sendo passado os dados do prestador.
function TNFSeW_Giap.GerarDadosServico: TACBrXmlNode;
begin
Result := CreateElement('dadosServico');
Result.AppendChild(AddNode(tcStr, '#1', 'bairro', 1, 25, 1,NFSe.prestador.Endereco.Bairro, ''));
Result.AppendChild(AddNode(tcStr, '#1', 'cep', 1, 9, 1,NFSe.prestador.Endereco.CEP, ''));
Result.AppendChild(AddNode(tcStr, '#1', 'cidade', 1, 30, 1, NFSe.prestador.Endereco.xMunicipio, ''));
Result.AppendChild(AddNode(tcStr, '#1', 'complemento', 1, 30, 0,NFSe.prestador.Endereco.Complemento, ''));
Result.AppendChild(AddNode(tcStr, '#1', 'logradouro', 1, 50, 1,NFSe.prestador.Endereco.Endereco, ''));
Result.AppendChild(AddNode(tcStr, '#1', 'numero', 1, 10, 1, NFSe.prestador.Endereco.Numero, ''));
Result.AppendChild(AddNode(tcStr, '#1', 'pais', 1, 9, 1,NFSe.prestador.Endereco.xPais, ''));
Result.AppendChild(AddNode(tcStr, '#1', 'uf', 1, 2, 1,NFSe.prestador.Endereco.UF, ''));
end;Ajuste para enviar os dados do tomador.
function TNFSeW_Giap.GerarDadosServico: TACBrXmlNode;
begin
Result := CreateElement('dadosServico');
Result.AppendChild(AddNode(tcStr, '#1', 'bairro', 1, 25, 1,NFSe.Tomador.Endereco.Bairro, ''));
Result.AppendChild(AddNode(tcStr, '#1', 'cep', 1, 9, 1,NFSe.Tomador.Endereco.CEP, ''));
Result.AppendChild(AddNode(tcStr, '#1', 'cidade', 1, 30, 1, NFSe.Tomador.Endereco.xMunicipio, ''));
Result.AppendChild(AddNode(tcStr, '#1', 'complemento', 1, 30, 0,NFSe.Tomador.Endereco.Complemento, ''));
Result.AppendChild(AddNode(tcStr, '#1', 'logradouro', 1, 50, 1,NFSe.Tomador.Endereco.Endereco, ''));
Result.AppendChild(AddNode(tcStr, '#1', 'numero', 1, 10, 1, NFSe.Tomador.Endereco.Numero, ''));
Result.AppendChild(AddNode(tcStr, '#1', 'pais', 1, 9, 1,NFSe.Tomador.Endereco.xPais, ''));
Result.AppendChild(AddNode(tcStr, '#1', 'uf', 1, 2, 1,NFSe.Tomador.Endereco.UF, ''));
end;Após o ajuste a nota fiscal passou a ser gerada com os dados esperados.
Este é um ajuste paliativo, pois podemos ter situações onde o prestado é Cotia, tomador de Cotia e local prestação de serviço Itapevi, mas acredito que dessa forma estará "menos" errado, este provedor atende outras cidades e não cheguei a verificar se trabalham da mesma forma para os dados (DadosServiço).
Em anexo está a unit com o ajuste mais manual utilizado.
-
Em 04/01/2024 at 09:59, Italo Giurizzato Junior disse:
Bom dia Bruno,
Lembre-se que alterar a unit ACBrNFSeXGravarXml_ABRASFv2, essa alteração passa a valer para todos os provedor que seguem a versão 2 do layout da ABRASF.
Só podemos alterar essa unit quando temos certeza que todos os provedores seguem essa configuração.
O lugar mais indicado é alterar a unit GravarXml do referido provedor.
Exemplo:
procedure TNFSeW_DSF200.Configuracao; begin inherited Configuracao; FormatoAliq := tcDe2; GerarNSRps := False; NrOcorrExigibilidadeISS := -1; end;Lembrando que:
// Numero de Ocorrencias Minimas de uma tag // se for 0 só gera a tag se o conteudo for diferente de vazio ou zero // se for 1 sempre vai gerar a tag // se for -1 nunca gera a tagOutra coisa:
Segundo os Schemas que temos para esse provedor a tag é obrigatória, veja:
<xsd:element name="ExigibilidadeISS" type="tsExigibilidadeISS" minOccurs="1" maxOccurs="1" />
Quando o mínimo de ocorrências é 1 significa que é obrigatória.
Os valores aceitos são:
<xsd:simpleType name="tsExigibilidadeISS"> <xsd:annotation> <xsd:documentation>Exigibilidade do ISS da NFS-e ( 1 - Exigivel; 2 - Nao incidencia; 3 - Isencao; 4 - Exportacao; 5 - Imunidade; 6 - Exigibilidade Suspensa por Decisao Judicial; 7 - Exigibilidade Suspensa por Processo Administrativo) </xsd:documentation> </xsd:annotation> <xsd:restriction base="xsd:byte"> <xsd:pattern value="1|2|3|4|5|6|7" /> </xsd:restriction> </xsd:simpleType>
Note que o erro que você esta tendo é de que o valor informado esta incorreto e não que a tag não deve constar no XML.
O componente usa os seguintes valores:
function TACBrNFSeXProvider.ExigibilidadeISSToStr( const t: TnfseExigibilidadeISS): string; begin Result := EnumeradoToStr(t, ['1', '2', '3', '4', '5', '6', '7', '8'], [exiExigivel, exiNaoIncidencia, exiIsencao, exiExportacao, exiImunidade, exiSuspensaDecisaoJudicial, exiSuspensaProcessoAdministrativo, exiISSFixo]); end;Note que existe o valor 8 = ISS Fixo que não é utilizado pelo provedor em questão.
Bom dia Ítalo, sim tenho ciência de todas essas observações, estávamos tendo essa situação e o cliente insistia em dizer que o erro era por causa do envio da tag no xml e estava exigindo que gerássemos um xml sem a tag, apenas para não mais se indispor com o cliente ia fazer alterar o fontes momentaneamente para não enviar mais a tag, e assim o cliente aceitar que o erro era de cadastro e não do sistema, mas consegui contornar a situação de outra forma e provar que o erro era realmente de cadastro, obrigado pela atenção Ítalo.
-
12 horas atrás, Bruno Lucas Batista. disse:
-
Boa noite, estou homologando emissão para a prefeitura de Sorocaba/SP que é administrada pelo provedor DSF, ao enviar a nota fiscal para emissão estou recebendo o erro (Tipo de exigibilidade do ISSQN incorreto.) ao analisar o manual de integração em nenhum lugar menciona sobre o envio da tag “ExigibilidadeISS”, alterei meu fonte e não estou mais alimentado o componente com informação, alterei também FNrOcorrExigibilidadeISS de FNrOcorrExigibilidadeISS := 1 para FNrOcorrExigibilidadeISS := 0 d a unit (ACBrNFSeXGravarXml_ABRASFv2) para ser opcional, mas continua saindo a tag no xml, como faço para que essa tag não seja mais gerada?
-
4 horas atrás, Renato Rubinho disse:
Bom dia,
Por via das dúvidas, confirme o caminho que você está apontando para garantir se está realmente na pasta correta atualizada.
Você está utilizando a opção para o componente montar os caminhos e deixando na pasta raiz dos schemas?
Caso o problema persista, por favor veja se ocorre o mesmo com o programa de exemplo para termos o mesmo cenário de testes.
Bom dia,
Acabei de confirmar e está apontando para a pasta correta, inclusive fiz um teste mandando a série da rps com mais de 5 dígitos e cnae com mais de 9 dígitos e não passou na validação, mas para a validação da tag alíquota não está barrando.
-
Em 11/12/2023 at 11:44, Italo Giurizzato Junior disse:
Bom dia Bruno,
Quais são os valores de: SSLLib, CryptLib, HttpLib, XmlSignLib e SSLType ?
Boa noite Ítalo, estou usando as seguintes configurações:
SSLLib := TSSLLib(libWinCrypt);
SSLCryptLib := TSSLCryptLib(cryWinCrypt);
SSLHttpLib := TSSLHttpLib(httpWinHttp);
SSLXmlSignLib := TSSLXmlSignLib(xsLibXml2);
SSLType := TSSLType(LT_TLSv1_2); -
Em 08/12/2023 at 13:57, Italo Giurizzato Junior disse:
Boa tarde Bruno,
Como que fica a validação do XML, pois segundo o schema a definição da tag Aliquota tem no máximo 2 casas decimais, veja:
<xsd:simpleType name="tsAliquota"> <xsd:restriction base="xsd:decimal"> <xsd:totalDigits value="4" /> <xsd:fractionDigits value="2" /> <xsd:minInclusive value="0" /> </xsd:restriction> </xsd:simpleType>
Bom dia Ítalo, está aí uma boa pergunta, como passou pela validação do schemas sendo que estou enviando informação fora do padrão estabelecido? Acabei de confirmar meu schemas e está igual ao seu inclusive os fontes foram atualizados na quinta-feira pela manhã ajustando apenas o ponto mencionado tópico, e o arquivo o env-lot-sinc xml foi gerado com informação <Aliquota>3.000000</Aliquota>.
-
Boa tarde, após a mudança da versão 1.0 para 2.03 do provedor DFS não estava conseguindo fazer a emissão, sempre recebia o retorno de que a alíquota não havia sido localizada, entrei em contrato com o suporte enviei o xml de envio e o de retorno, após analise deles fui informado que a formatação para a tag Alíquota deveria ser com seis casas após a vírgula, fiz os ajuste a no método Configuracao da unit DSF.GravarXml alterando de FormatoAliq := tcDe2; para FormatoAliq := tcDe6; e a emissão ocorreu com sucesso se acharem relevante o ajuste fico feliz em ajudar.
Em anexo arquivo já ajustado
-
23 horas atrás, Italo Giurizzato Junior disse:
Bom dia Bruno,
Além de incluir o valor referente a versão, você também atualizou as URLs?
Pois as URLs da versão 2.03 são diferentes da 1.00
Bom dia Ítalo, acabei não me atentando a esse detalhe, acabei de ajustar e fiz os testes, esta funcionando 100% no padrão ABRASF 2.03.
Alterado de:
Nome=Sao Jose dos Campos
UF=SP
Provedor=DSF
ProRecepcionar=https://notajoseense.sjc.sp.gov.br/notafiscal-ws/NotaFiscalSoap
HomRecepcionar=https://homol-notajoseense.sjc.sp.gov.br/notafiscal-ws/NotaFiscalSoapPara:
Nome=Sao Jose dos Campos
UF=SP
Provedor=DSF
Versao=2.03
ProRecepcionar=https://notajoseense.sjc.sp.gov.br/notafiscal-abrasfv203-ws/NotaFiscalSoap
HomRecepcionar=https://homol-notajoseense.sjc.sp.gov.br/notafiscal-abrasfv203-ws/NotaFiscalSoapSegue em anexo arquivo com as atualizações, se acharem valido ajuste fico feliz em ajudar!
-
Bom dia, na sexta-feira recebi a informação do pessoal do provedor (DSF) que são responsáveis pelo web service da prefeitura de São José dos campos de que a partir de Janeiro de 2024 somente irão aceitar arquivos no padrão ABRASF 2.03, me antecipando fiz a alteração no arquivo ACBrNFSeXServicos.ini adiconando (Versao=2.03) mas, ao envia estou recebendo a seguinte mensagem:
Código Erro: X999
Motivo: Erro de Conexão: soap:Client - Message part {http://nfse.abrasf.org.br}RecepcionarLoteRpsSincrono was not recognized. (Does it exist in service WSDL?)
Correção:
-
Boa tarde, estou tento problema para emissões para o provedor de São José dos Campos/SP que é administrado pelo provedor DSF, estou enviado nota fiscal com código CNAE com 9 dígitos que foi informado pela própria prefeitura, porém recebo erro de validação schemas, ao verificar o fonte percebi que esta sendo validado com o schemas da pastas 1.00 onde CNAE neste schema aceita até 7 dígitos, o schemas da pasta 2.03 esta configurado para aceitar até 9 dígitos porém não estou encontrando onde altero para que o componente faça a validação com schemas da pasta 2.03.
-
Sim os fontes foram atualizados hoje, segue arquivos com as alterações.
-
29 minutos atrás, Bruno Lucas Batista. disse:
Boa tarde, estou com a seguinte situação, gerando nota fiscal para a prefeitura de Valinhos/SP que é administrada pelo provedor SigISSWeb, nesta emissão o prestador é de Valinhos/SP e o tomador Campinas/SP, seguindo a orientação do manual preciso enviar a informação "F" para a tag (iss_retido)
pelo que eu pude observar (TNFSeW_SigISSWeb) ela só esta preparada para receber S/N
Acabei fazendo os seguintes ajustes meus fontes, caso tenham interesse em subir a alteração:
Unit: ACBrNFSeXConversao
Alterado de: TnfseSituacaoTributaria = (stRetencao, stNormal, stSubstituicao, stNenhum);
Para: TnfseSituacaoTributaria = (stRetencao, stNormal, stSubstituicao, stNenhum, stRetidoForaMunicipio, stDevidoForaMunicipioNaoRetido);
Unit: SigISSWeb.GravarXml
Alterado de:
if NFSe.Servico.Valores.IssRetido = stRetencao then
NFSeNode.AppendChild(AddNode(tcStr, '#1', 'iss_retido', 1, 1, 1, 'S', ''))
else
NFSeNode.AppendChild(AddNode(tcStr, '#1', 'iss_retido', 1, 1, 1, 'N', ''));Para:
if NFSe.Servico.Valores.IssRetido = stRetencao then
NFSeNode.AppendChild(AddNode(tcStr, '#1', 'iss_retido', 1, 1, 1, 'S', ''))
else if NFSe.Servico.Valores.IssRetido = stRetidoForaMunicipio then
NFSeNode.AppendChild(AddNode(tcStr, '#1', 'iss_retido', 1, 1, 1, 'F', ''))
else if NFSe.Servico.Valores.IssRetido = stDevidoForaMunicipioNaoRetido then
NFSeNode.AppendChild(AddNode(tcStr, '#1', 'iss_retido', 1, 1, 1, 'D', ''))
else
NFSeNode.AppendChild(AddNode(tcStr, '#1', 'iss_retido', 1, 1, 1, 'N', '')); -
Boa tarde, estou com a seguinte situação, gerando nota fiscal para a prefeitura de Valinhos/SP que é administrada pelo provedor SigISSWeb, nesta emissão o prestador é de Valinhos/SP e o tomador Campinas/SP, seguindo a orientação do manual preciso enviar a informação "F" para a tag (iss_retido)
pelo que eu pude observar (TNFSeW_SigISSWeb) ela só esta preparada para receber S/N
-
Descobri, foi alterado o nome da property de WSChaveAcesso para WSChaveAutoriz, e também agora o componente faz a formatação (Insc.Municipal-TOKEN).
4 minutos atrás, Italo Giurizzato Junior disse:Boa tarde Bruno,
Esta errado a sua configuração, veja:
procedure TACBrNFSeXWebserviceGiap.SetHeaders(aHeaderReq: THTTPHeader); var Auth, Token: string; begin with TConfiguracoesNFSe(FPConfiguracoes).Geral.Emitente do begin Token := WSChaveAutoriz; Auth := InscMun + '-' + Token; // Auth := InscMun + '-' + UpperCase(EncodeBase64(Token)); end; aHeaderReq.AddHeader('Authorization', Auth); aHeaderReq.AddHeader('postman-token', Token); end;Informe o Token na propriedade WSChaveAutoriz e a Inscrição Municipal em InscMun.
O Componente faz o resto.
Depois que abri o post que fui revisar pela ultima vez os métodos notei essa mudança. Obrigado Ítalo.
-
Boa tarde, após atualizar o componente para versão "X" não estou mais conseguindo emitir notas para Cotia/SP o provedor Giap, sempre que envio recebo o seguinte retorno: <?xml version="1.0" encoding="UTF-8"?> <nfeReposta> <notaFiscal> <messages> <code /> <message>Parâmetro Authorization fora do formato especificado (Inscrição Municipal-TOKEN) exemplo: 123456-ABDY0ABEFFRE3Z4VIRZKZKIIY9ILJ99J./n Qualquer duvida consulte o manual no site: http://nfse.cotia.sp.gov.br/ords/cotia/f?p=907</message> <Correcao /> </messages> </notaFiscal> </nfeReposta>estou enviando a informação para o componente como esta sendo solicitada no manual de integração disponível em "https://nfse.cotia.sp.gov.br/ords/cotia/f?p=907:94":ACBrNFSeX1.Configuracoes.Geral.Emitente.WSChaveAcesso :=
InscMunicipal+ '-' + token;Houve alguma alteração para o envio desta informação?
Desde já agradeço atenção!
-
Boa tarde atualizei os fontes e voltei a me deparar a situação acima, notei que na procedure "Configuracao" foi adicionado uma condição para definir se gera ou não a tag "ValorISS"
if (NFSe.OptanteSimplesNacional = snNao) and
(NFSe.RegimeEspecialTributacao in [retMicroempresaMunicipal, retMicroempresarioEmpresaPP]) then
NrOcorrValorIss := 1
else
NrOcorrValorIss := -1;pela condição definida só ira gerar a tag "ValorISS" se o prestador for retMicroempresaMunicipal ou retMicroempresarioEmpresaPP e não for OptanteSimplesNacional, na minha emissão o prestador não é Optante Simples Nacional "snNao" e também não possuí um regime tributário especial "retNenhum" então caio na condição NrOcorrValorIss := -1, e o xml é gerado sem a tag "ValorISS", recebo o retorno de que o "ValorIss" não foi informado, após pesquisar nos manuais disponíveis não encontrei nenhuma informação sobre a regra da geração da tag ValorIss para validar a condição.
-
Bom dia, estou fazendo testes de diversas situações para o prefeitura de Valinhos/SP onde o provedor responsavel pelo mesmo é SigISSWeb.
Me deparei com o seguinte situação, ao enviar uma nota fiscal onde o valor bruto é de R$ 11.452,80 nesta nota fiscal tem dedução de ISS (572,64) + IR (114,53) + INSS (1.259,81) sendo assim o valor liquido da nota fiscal é de R$ 9.505,82, estou enviando as seguintes informações para o componente.
Servico.Valores.ValorServicos := ValorDefault(cdsFaturaNFSe.FieldByName('VALORBRUTO').AsFloat,0); //(R$ 11.452,80)
Servico.Valores.ValorLiquidoNfse := ValorDefault(cdsFaturaNFSe.FieldByName('VALORLIQUIDO').AsFloat,0); //(R$ 9.505,82)
estou recebendo o seguinte retorno do provedor:Erros de Validacao :
O Valor do Servico nao pode ser maior do que o Valor da Nota Fiscal.
O Valor do Servico deve ser Valor da Nota menos Deducao.
Ao analisar o xml de enivo (-ger-nfse.xml) está sendo gerado da seguinte forma:<valor_nf>9505,82</valor_nf>
<deducao>0,00</deducao>
<valor_servico>11452,80</valor_servico>
Alterei a unit "SigISSWeb.GravarXml"De:
NFSeNode.AppendChild(AddNode(tcDe2, '#1', 'valor_nf', 1, 15, 1,
NFSe.Servico.Valores.ValorLiquidoNfse, ''));NFSeNode.AppendChild(AddNode(tcDe2, '#1', 'deducao', 1, 15, 1,
NFSe.Servico.Valores.ValorDeducoes, ''));NFSeNode.AppendChild(AddNode(tcDe2, '#1', 'valor_servico', 1, 15, 1,
NFSe.Servico.Valores.ValorServicos, ''));
Para:NFSeNode.AppendChild(AddNode(tcDe2, '#1', 'valor_nf', 1, 15, 1,
NFSe.Servico.Valores.ValorServicos, ''));NFSeNode.AppendChild(AddNode(tcDe2, '#1', 'deducao', 1, 15, 1,
NFSe.Servico.Valores.ValorDeducoes, ''));NFSeNode.AppendChild(AddNode(tcDe2, '#1', 'valor_servico', 1, 15, 1,
NFSe.Servico.Valores.ValorLiquidoNfse, ''));
Após o ajuste a nota fiscal foi gerada, este teste foi feito no ambiente de homologação, sendo assim se acharem válido o ajuste peço a gentileza que suba esta contribuição para componente. -
Boa tarde, irei tentar fazer o contato com eles e tirar essa duvida, assim que tiver algum retorno posto aqui. Obrigado!
-
2
-
Quebra de linha para prefeitura do Rio de Janeiro provedor ISSRio
em ACBrNFSe
Postado
Ítalo boa tarde!
Acabei de testar a quebra de linha para prefeitura do rio de janeiro e funcionou perfeitamente, obrigado!