wmixvideo / nfe

Nota Fiscal Eletrônica em Java.
Apache License 2.0
647 stars 376 forks source link

Impossibilidade de setar campos nulos devido a validações adicionais nos métodos .SET() #842

Closed edudoda closed 1 year ago

edudoda commented 1 year ago

Pessoal, notei que alguns campos da biblioteca não podem ser alterados para NULL se tiverem sido preenchidos, mesmo quando as validações permitem que ele seja vazio (required=false), isso exige que tenha que se criar um objeto novo e passar todos os campos novamente.

Ex: Suponha que o usuário tenha criado uma nota e preenchido o objeto NFNotaInfoItemImpostoICMS60 (ou icmsst ou icmsst) com o atributo percentualFundoCombatePobrezaRetidoST = 0,00 e salvo o arquivo.

Ao tentar alterar para limpar e remover esse campo via método .set() é lançada uma exceção pois há uma validação interna "adicional" if (percentualFundoCombatePobrezaRetidoST.signum() < 0) que não prevê que esse campo possa ser nulo (sendo que não é um campo obrigatório).

  @Element(name = "pFCPSTRet", required = false)
    private String percentualFundoCombatePobrezaRetidoST;

  public void setPercentualFundoCombatePobrezaRetidoST(final BigDecimal percentualFundoCombatePobrezaRetidoST) {
        if (percentualFundoCombatePobrezaRetidoST.signum() < 0) {
            throw new IllegalStateException("Percentual fundo de combate a pobreza precisa ser maior que zero!");
        }
        this.percentualFundoCombatePobrezaRetidoST = DFBigDecimalValidador.tamanho7ComAte4CasasDecimais(percentualFundoCombatePobrezaRetidoST, "Percentual fundo combate pobreza retido ST");
    }

Boa parte das validações são através de classes * "Validador" como a DFBigDecimalValidador** que já leva essa questão em consideração, veja:

 public static String tamanho4Com2CasasDecimais(final BigDecimal valor, final String info) {
        return DFBigDecimalValidador.parse(valor, "0.00", 5, 2, info);
   }

 private static String parse(BigDecimal valor, final String formato, final int tamanho, final int posicaoPontoFlutuante, final String info) {

      if (valor == null) {    // AQUI É TRATADO SE O CAMPO PODE SER VAZIO!!!!   
            return null;
        }
        if (valor.toPlainString().length() > tamanho || StringUtils.split(valor.toPlainString(), ".")[0].length() > (tamanho - (posicaoPontoFlutuante + 1)) || valor.scale() > posicaoPontoFlutuante) {
            throw new NumberFormatException(String.format("Valor %s extrapolou o tamanho de casas", info));
        }
        valor = valor.round(new MathContext(valor.precision(), RoundingMode.UNNECESSARY));
        return new DecimalFormat(formato, DecimalFormatSymbols.getInstance(Locale.US)).format(valor);
    }

Portanto a dúvida/sugestão é: não seria o caso de tratar essas validações internas existentes nos métodos SET da biblioteca para permitir atribuir como NULL novamente? Ou ainda melhor, jogar todas essas validações ''avulsas''em uma nova classe como com.fincatto.documentofiscal.validadores.SignalValidador ou algo do tipo?

fincatto commented 1 year ago

Boa tarde @edudoda. Faz sentido permitir voltar pra nulo sim. Se estiver apto a mandar um PR, vai ser bem vindo.