[NFSe] ISSCampinas (Campinas/SP) v2.03 — Alíquota truncada em 2 casas no ACBR

[João Vitor Bogo]

Ao emitir NFS-e para prestador, cuja **alíquota efetiva do ISS possui 4 casas decimais** (ex.: `4,2947%`), a prefeitura de Campinas rejeita a emissão com:

 

Citar

Código  : L999
Mensagem: Não é permitida a edição da alíquota para valores menores do que o indicado.
A alíquota retida mínima foi calculada conforme o registro das emissões de notas de sua empresa para o período de cálculo e utilizando os dados do PGDAS caso a declaração tenha sido disponibilizada pela Receita Federal.

A mesma nota, emitida manualmente pelo portal da prefeitura, é aceita normalmente.

A Unit ISSCampinas.GravarXml.pas configura o formato da alíquota com **2 casas decimais**:
 

procedure TNFSeW_ISSCampinas203.Configuracao;
begin
  inherited Configuracao;

  FormatoAliq := tcDe2;   // <-- trunca 4,2947 para 4,29
  ...
end;

A tag `<Aliquota>` é gerada por esse `FormatoAliq` na base ABRASFv2 (`ACBrNFSeXGravarXml_ABRASFv2.pas`, método `GerarValoresServico`).

Com `tcDe2`, a alíquota efetiva `4,2947` é gravada como `4,29` no XML enviado. Campinas calcula a **alíquota retida mínima** do Simples Nacional a partir do PGDAS (no caso, `4,2947`) e rejeita porque o valor informado (`4,29`) é **menor** que o mínimo indicado.

A diferença é exclusivamente a precisão da alíquota: `4,29` (truncada) versus `4,2947` (efetiva).

## Correção sugerida

São necessárias duas alterações, ambas no lado do ACBr (que distribui tanto o provider quanto o schema):

### 1. Formato da alíquota

procedure TNFSeW_ISSCampinas203.Configuracao;
begin
  inherited Configuracao;

  FormatoAliq := tcDe4;   // permite a alíquota efetiva do Simples (4 casas)
  ...
end;

Após a mudança, o XML passa a enviar `<Aliquota>4.2947</Aliquota>`.

### 2. Schema — `Schemas/NFSe/ISSCampinas/2.03/nfse.xsd`

O tipo `tsAliquota` está restrito a 2 casas decimais e total de 4 dígitos, o que faz a validação local do ACBr barrar a alíquota de 4 casas com:

Erro de Validação: 1838 - Element 'Aliquota': [facet 'fractionDigits']
The value '4.2947' has more fractional digits than are allowed ('2').

 

<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>

 

<xsd:simpleType name="tsAliquota">
  <xsd:restriction base="xsd:decimal">
    <xsd:totalDigits value="5" />
    <xsd:fractionDigits value="4" />
    <xsd:minInclusive value="0" />
  </xsd:restriction>
</xsd:simpleType>

## Teste

Com as duas alterações aplicadas, a NFS-e que vinha sendo rejeitada por L999 foi aceita pela prefeitura de Campinas em ambimente de Produção enviando a alíquota com 4 casas (`4,2947`).

Segue anexo os 2 arquivos com a alteração

ISSCampinas.GravarXml.pas

nfse.xsd

[Juliomar Marchetti]

Dúvida e para quem usa somente duas casas ?

continua funcionando normalmente ou é uma alteração geral?

[João Vitor Bogo]

Boa pergunta, na teoria pra quem usa 2 casas continua de boa, o schema que ajustei deveria aceitar os dois jeitos, então a prefeitura deveria ler por exemplo 5.2300 igualzinho a 5.23.

Pra ser sincero eu não tenho nenhum outro cliente com alíquota de 2 casas em Campinas pra testar isso na prática agora. Pela lógica funciona (o valor é o mesmo e o schema ficou mais flexível), mas eu mesmo ainda não vi uma emissão real de 2 casas rodando depois da alteração. Se alguém aí tiver esse caso e quiser confirmar...