ernesto.ricardo

Bom dia @Italo Giurizzato Junior A resposta do suporte depois de muitos e muitos e-mails: 14/11/24 08:39 [João Henrique Lima]: Certo, no caso o manual que temos disponível é um atualizado de agosto de 2024, e a respeito do schema não temos disponível um atualizado, porém se no caso o problema está na validação do schema, basta não fazer a validação, visto que o sistema irá aceitar ambas as formas de casas decimais, 2 ou 4. Pois fizemos os testes com ambas as formas e o sistema aceita, poderia por gentileza fazer o procedimento sem realizar a validação ? Neste caso Ajustei o Schema para não ter mais problemas com a validação, efetuei vários testes e deram todos OK. nfse.xsd NOTA: Eu comparei o schema no site da prefeitura com o do SVN da ACBR. Haviam mais listas de serviços no site da prefeitura que juntei no arquivo do ACBR. Por exemplo, sei que alguns clientes utilizam o código 16.02, que tinha no site da prefeitura e não tinha no ACBR. Segue schema para atualização no SVN.

Bom dia @Italo Giurizzato Junior, Estou em contato com o suporte deles para ver se eles ajustam o schema e fique correto. O Problema no ACBR é que ele valida o schema antes do envio (O que está correto). Validando, ele retorna este erro e não permite enviar. Erro: X800 - Erro de Validação: --> 1824 - Element '{http://www.abrasf.org.br/nfse.xsd}Aliquota': '3.9507' is not a valid value of the atomic type '{http://www.abrasf.org.br/nfse.xsd}tsAliquota'. Eu peguei o schema atualizado e vi que ele já esta diferente do que esta no SVN do ACBR, mas vou tentar ver se ajustam isso antes de subir aqui.

Boa tarde @Juliomar Marchetti! Tanto no RPS de Envio quanto no de retorno vai esta aliquota. No caso anterior foi o RPS enviado. Este foi o XML de retorno: Na prefeitura a NFS-e esta autorizada

Opa @Juliomar Marchetti, O XML esta correto, tanto é que "burlando" a verificação do schema a NFS-e é autorizada corretamente. Em versões antigas ainda é possível emitir a NFS-e sem problemas com o flag de validação so schema desativado. Grande @Italo Giurizzato Junior, Para este provedor em Blumenau, desativamos a vaidação do schema porque dava muito problema e o SimpliSS não tinha um schema correto. Aquele parâmetro que existia foi a solução para este problema, mas vou entrar em contato de qualquer forma para saber se houve alguma melhoria nesta questão. Inclusive, tem uma lista de serviços que não esta no schema deles e sempre barrava na emissão e até hoje não conseguimos resolver isso...

Boa tarde pessoal, Estou tentando transmitir a NFS-e com o novo componete. A configuração do ini esta correta, com 4 casas decimais para Blumenau: [4202404] ; Atualizado 13/01/2023 Nome=Blumenau UF=SC Provedor=SimplISS Versao=2.03 Params=Aliquota4Casas: ProRecepcionar=https://wsblumenau1.simplissweb.com.br/nfseservice.svc HomRecepcionar=https://wshomologacaoabrasf1.simplissweb.com.br/nfseservice.svc ProSoapAction=http://www.sistema.com.br/Sistema.Ws.Nfse HomSoapAction=http://nfse.abrasf.org.br ProLinkURL=https://blumenau.simplissweb.com.br/contrib/app/nfse/relatorio?cnpj=%Cnpj%&ser=E&inum=%NumeroNFSe%&icod=%CodVerif% ao tentar transmitir uma NFS-e com a alíquota de 3.9507 ocorre o erro de validação do schema: Erro: X800 - Erro de Validação: --> 1824 - Element '{http://www.abrasf.org.br/nfse.xsd}Aliquota': '3.9507' is not a valid value of the atomic type '{http://www.abrasf.org.br/nfse.xsd}tsAliquota'. Antigamente, havia um parâmetro para não validar o schema, mas acredito que ele foi removido. Este erro é de validação dentro do componete, não é da prefeitura. "Ignorei" este trecho para não dar erro e a NFS-e foi autorizada corretamente na prefeitura: Alguem tem alguma sugestão de como ajustar isso?

Bom dia Ítalo, Era justamento isso, removi eles e passou.

Bom dia Ítalo, Sim, eles foram atualizados para a versão mais recente e parou de emitir acusando este erro na assinatura. Acabei de verificar em outro cliente nosso de gaspar.. Esta emitindo notas fiscais normalmente na versão antiga do componente.

Boa tarde, Este problema voltou a ocorrer com o provedor thema em Gaspar/SC. Migramos os componentes antigos da NFS-e para o componente AcbrNFSeX, porém, outros clientes da mesma cidade estão emitindo em versões abaixo. Não vi alteração nos fontes do thema Fiz varios testes de envio e não consegui validar... Alguem poderia dar um help? Depurei a rotina de envio, para tentar encontrar alguma possível alteraçao posterior a assinatura, mas sem sucesso. 395-env-lot-sinc.xml 395-env-lot-sinc-soap.xml 395-lista-nfse-sinc.xml 395-lista-nfse-sinc-soap.xml

Boa Tarde Ítalo, Houver alguma evolução na implementação da NFS-e para este provedor?

Boa tarde pessoal, A um tempo atrás também passamos pela mesma dificuldade. O padrão de Blumenau e SP é um pouco diferente das outras cidades. Como o ACBR ainda não possui a implementação para estas cidades, e não possuíamos tempo hábil na época para desenvolvimento, nossa empresa adquiriu um componente para Delphi pago da Tecnospeed, onde fomos empresa piloto para a criação do mesmo. Aparentemente não vejo problemas em desenvolver o mesmo via Delphi (hoje utilizamos o Delphi XE), ou alguma restrição que impeça o desenvolvimento. Mas ficaria muito feliz se esta rotina fosse implementada via ACBR para manter a padronização com os componentes do restante do sistema. Se precisarem de alguma informação referente ao funcionamento da NotaBlu, podem entrar em contato com a Milene da prefeitura de Blumenau, uma das responsáveis pela Notablu pelos fones: 47 3381 7528, 47 3381 6732 ou 47 3381 6814. Assim que tivermos mais tempo voltaremos a análise para implementação da rotina através do ACBR.