FUNCTION CalculoNoGet( ... )
RETURN .T.
Pra que serve?
Imagine vários cálculos no GET... a complicação que fica.
Agora com essa função - apenas exemplo:
@ 3, 5 GET mQtde PICTURE "@E 999,999,999.99" VALID ;
CalculoNoGet( mValorItem := mQtde * mValorUnitario, ;
mDesconto := mValorItem * mPercentualDesconto, ;
mIcms := ( mValorItem - mDesconto ) * mAliquotaIcms )
Substituiu minha anterior ReturnValue( .T., cálculos )
A função não precisa fazer nada, apenas serve pra "organizar" todos os possíveis cálculos.
Um OkQtde() poderia ser interessante, mas precisaria passar muitas variáveis como parâmetro.
Mas a mais legal de hoje foi esta:
A ANP não aceita quantidade fracionada, e isso pode acontecer com combustível.
Como resolver?
Colocar algo específico para o cliente, para o grupo combustíveis, para uma lista de NCM, indicar no produto se aceita decimal?
Ué.. o que vai pra ANP tem código da ANP.... pronto... resolvido.
STATIC FUNCTION QtdeOk( mipQtde )
IF SubStr( jpitem->ieUnid, 1, 2 ) == "UN" .AND. Str( Int( mipQtde ), 16, 5 ) != Str( mipQtde, 16, 5 )
MsgStop( "INVÁLIDO!" + hb_eol() + "Se produto vendido por unidade, quantidade NÃO pode conter decimais" )
RETURN .F.
ENDIF
IF ! Empty( SoNumeros( jpitem->ieAnp ) ) ) .AND. Str( Int( mipQtde ), 16, 5 ) != Str( mipQtde, 16, 5 )
MsgStop( "INVÁLIDO!" + hb_eol() + "ANP NÃO aceita quantidade com decimais" )
RETURN .F.
ENDIF
RETURN .T.
Pronto.
Pode ser usado pra qualquer cliente e qualquer produto, sem exceção.
Nada de gambiarra, nada de complicação, nada de parâmetros adicionais, manutenção fácil.
E quando cadastrarem produtos novos... com código ANP... não precisa alterar mais nada.
Aproveitando, pra "apertar novamente a tecla":
Não tem nada aí de "expert", são coisas simples que todos podem fazer.
E um aplicativo.... pode até ser complicado... mas é feito com a combinação de muitas coisas simples.
A pergunta que todos devem fazer:
Estão fazendo muitas coisas simples pra resolver algo complexo, ou estão complicando até o que é simples?