ernesto.ricardo

Ítalo, Primeiramente obrigado pelo retorno. Havia uma situação com a compilação realmente que corrigimos. A prefeitura de Brusque mudou algumas regras para emissão, mas não sei se cabe alguma coisa de alteração, vou deixar aqui somente para conhecimento 1. Se o tomador do serviço for pessoa jurídica domiciliado no mesmo munícipio, o componente sempre deverá ser preenhido na tag "enderecoinformado" como não. (Informar sim somente para pessoas físicas) Tomador.Endereco.EnderecoInformado := snoNao 2. Informações das parcelas agora devem ser informadas somente se a tag estiver preenchida dessa forma CondicaoPagamento.Condicao := cpAPrazo Pelo que nos foi relatado (pelo suporte da IPM), esta nova versão esta seguindo o Padrão Nacional. Muitas regras e implementações não estão no Manual. Outra coisa que mudou. Para vendas parceladas, o cliente deverá habilitar a permissão no portal: Em manunteção seguir conforme abaixo: Após consultar, vai ter a opção de "Alterar" (que esta apagada ali na imagem) Dai precisa habilitar a caixinha "Exibe as formas de pagamento" para o webservice receber vendas parceladas. Com isso acredito que de pra encerrar o tópico. Daqui por diante são ajustes conforme novas regras de validação.

Beleza Ítalo, vou rever os fontes aqui...

Bom dia Italo, Ao tentar transmitir a NFS-e para a prefeitura esta ocorrendo o seguinte erro: Erro: X999 - Erro de Conexão: Ext202503.rarra content at the end of the document Em anexo os arquivos para análise.

Bom dia Ítalo! Muito obrigado pelo feedback. Vou dar update e na próxima segunda já efetuo o teste

Boa tarde a todos! Italo, conforme solicitado estou abrindo um tópico referente a alteração no sistema da NFS-e para Brusque. Segue link para maiores detalhes: https://brusque.atende.net/subportal/atualizacao-do-sistema-fiscal-web A Mudança ira ocorer em 10/03/2025. Aparentemente o XML continua o mesmo, porém, segundo informações do portal: O webservice de emissão de notas fiscais sofreu alterações na forma de autenticação e retorno, porém o layout do arquivo XML de envio continua o mesmo. Provavelmente será necessário ajustar os componentes para 10/03. Como não sei exatamente quais os trâmites nesta situação, estou abrindo o tópico conforme solicitado! Desde já agradeço.

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.