FORMULÁRIO SOLICITAÇÕES
Autor: Manassés Vicente | Publicado: 2008-06-11T08:59:00-07:00

No cadastro das solicitações, para que algumas regras fosse imposta resolvi fazer tres formulário de solicitação. Um que fosse possível incluir todas as solicitações menos as que tratam de cobertura, isso é, as que não tem o solicitado conhecido no momento da inclusão da mesma. Outra que fosse possível a inclusão que tratasse apenas das solicitações de coberturas, isto é, já se conhecia o solicitante através de outro tipo de solicitação e já se conhece o solicitado. E uma terceira onde fosse possível navegar entre os registros apoiando uma consulta rápida, e a atualização do status apenas.Para isso as tres precisariam conter as mesmas regras, então qualquer alteração que eu faça no Cad_Solicitacao fica mais fácil excluir os outros formulários e salvar o Cad_Solicitacao alterado com novos nomes: Cad_Solicitado e Cad_Solicitacao_Status.Em Cad_Solicitado eu preciso alterar Layout / Blocos /alterar o nome para CADASTRO DO SOLICITADO, em seguida em Campos / IDTIPOSOLI / Lookup de Edição colocar o seguinte comando select:SELECT IDTIPOSOLI, sc_concat(IDTIPOSOLI, ' - ', TIPO_SOLICITACAO)FROM TIPO_SOLICITACAOWHERE IDTIPOSOLI = 0 or IDTIPOSOLI = 2 or IDTIPOSOLI = 4 or IDTIPOSOLI = 6 or IDTIPOSOLI = 8 or IDTIPOSOLI = 10 or IDTIPOSOLI = 12 or IDTIPOSOLI = 14ORDER BY IDTIPOSOLIEm Campos / IDSTATUS / Lookup de Edição terá a alteração do comando select para:SELECT IDSTATUS, STATUS_SOLICITACAOFROM STATUS_SOLICITACAOORDER BY STATUS_SOLICITACAOEm Aplicação / Configuração / Descrição alterar para CADASTRO DO SOLICITADOE assim finalizamos esse formulário com a replicação de todas as alterações do formulário mestre para esse.Em Cad_Solicitacao_Status é preciso alterar Layout / Blocos /alterar o nome para SOLICITAÇÕES, em seguida em Campos / IDTIPOSOLI / Lookup de Edição colocar o seguinte comando select:SELECT IDTIPOSOLI, sc_concat(IDTIPOSOLI, ' - ', TIPO_SOLICITACAO)FROM TIPO_SOLICITACAOORDER BY IDTIPOSOLIEm Campos / IDSTATUS / Lookup de Edição terá a alteração do comando select para:SELECT IDSTATUS, STATUS_SOLICITACAOFROM STATUS_SOLICITACAOEm Campos / IDSITUACAO / Lookup de Edição é necessário alterar para:SELECT F_SITUACAO.IDSITUACAO, F_SITUACAO.NOMEFROM F_SITUACAOEm Formulário / Barra de Ferramentas eu preciso rertirar a opção de inclusão e deixar:Inicio, Retorna, Avança, Final,  Alterar, SairAinda em Formulário / SQL preciso alterar para IDEMPRESA = '[var_idempresa]' em Cláusula Where para que seja listado todas as situações.Em Aplicação / Configuração / Descrição alterar para SOLICITAÇÕESPara finalizar conferir em Aplicação / Variáveis Globais se tem apenas a variável idempresa.Ainda assim teremos o problema pois o select não busca as informações do cooperado, isso porque não repassamos a variável idsituacao através do controle, também pela forma que recuperamos essas informações através do evendo ajax onChange nos campos solicitante e solicitado.No campo IDSITUACAO em Valor no Banco de Dados / Atualização escolhemos a opção Calculado pelo banco de dados, na esperança que viessem todas as solicitação com todos os status de cooperado. Temos que fazer mais alguns testes a esse respeito.Os campos contrato e cont em lookup de consulta receberam o seguinte código:select cadcon.con_descricaofrom solicitacaoleft outer join contrato_cooperado on (solicitacao.idempresa = contrato_cooperado.idempresa) and (solicitacao.solicitante = contrato_cooperado.idpessoa)left outer join cadcon on (contrato_cooperado.con_codigo = cadcon.con_codigo)Os campos setor e seto em lookup de consulta receberam o seguinte código: select f_lotacao.nomefrom solicitacaoinner join f_lotacao on (solicitacao.idempresa = f_lotacao.idempresa) and (solicitacao.idlotacaoa = f_lotacao.idlotacao)Os campos funcao e func em lookup de consulta receberam o seguinte código:  select f_cargo.nomefrom solicitacaoinner join f_cargo on (solicitacao.idempresa = f_cargo.idempresa) and (solicitacao.idcargoa = f_cargo.idcargo)O campo projeto em lookup de consulta recebeu o seguinte código:select empresa.apelidofrom solicitacaoinner join empresa on (solicitacao.idempresa = empresa.idempresa)O campo situacao em lookup de consulta recebeu o seguinte código: select f_situacao.nomefrom solicitacaoinner join f_situacao on (solicitacao.idempresa = f_situacao.idempresa) and (solicitacao.idsituacao = f_situacao.idsituacao) O campo IDSITUACAO da tabela f_situacao é um domínio float e o da tabela solicitacao é integer, sem possíbilidade de se criar tal relacionamento assim o campo traz o nome do projeto ao invés de trazer o da situação, vai ser preciso validar isso.}Um outro problema que encontrei nos eventos do php e em eventos ajax foi com a cláusula or que o suporte informou ser possível usar || quando or não funcionar, e a <> que informaram !=, nenhum nem outro funcionaram quando na verdade eu nao deveria usar a opção or e sim and.Algo que na correria me faz perder tempo é se: Se na condicional tiver = então or, se na condicional tiver <> então and, em garnde parte das situações.Outro problema que deu um sufoco, e me fez perder umas 4 horas revisando sintaxe e tabela verdade foi o sc_date_empty no evento onValidate para acusar o valor nulo, e só foi resolvido usando empty, aí eu pergunto os eventos ajax usam macro e os eventos do php não?Outra confusão que no = do if ou seja uma comparação o php interpreta como atribuição então tem que ser ==Um outro recurso interessante para o evento ajax, é usar sc_erro_mensagem("A data inicial do evento não pode ser vazia!"); para que a mensagem saia em vermelho na frente do campo nas opções de aviso curto e quando envolver uma explicação mais detalhada usar echo"mensagem" para obter uma janela poup-up com a mensagem.Apenas os eventos ajax onChange nos campos não são suficientes para imposição das regras, devido a isso elas foram repassadas para eventos onValidate afim de que não seja possível incluir solicitação que quebre alguma regra.Temos trinta tipo de solicitações,e vamos distribuílas em grupos distintos:0 ESCOLHA O TIPO DE SOLICITACAO1 SUBSTITUICAO2 COBERTURA SUBSTITUICAO3 AFASTAMENTO TEMPORARIO4 COBERTURA AFASTAMENTO TEMPORARIO5 LICENCA GESTACAO6 COBERTURA LICENCA GESTACAO7 LICENCA MATERNIDADE8 COBERTURA LICENCA MATERNIDADE9 ACIDENTE DE TRABALHO10 COBERTURA ACIDENTE TRABALHO11 ACIDENTE TRAJETO12 COBERTURA ACIDENTE TRAJETO13 DESCANSO ANUAL14 COBERTURA DESCANDO ANUAL15 AUSENCIA COMUNICADA PELO SETOR16 COBERTURA DE CREDITO17 INCIDENTE NA AFERICAO DA PRODUCAO18 ASSOCIACAO19 DESLIGAMENTO20 INCLUSAO PROJETO21 DESLIGAMENTO DO PROJETO22 VINCULO CONTRATUAL23 DESLIGAMENTO DO CONTRATO24 TROCA DE PLANTAO25 REVISAO DE PRO-LABORE26 ABERTURA CONTA BANCARIA27 CRACHA28 CRACHA - SEGUNDA VIA29 COTA-PARTE30 ALTERACOES DADOS CADASTRAISAlgumas solicitações não receberão críticas:24 TROCA DE PLANTAO25 REVISAO DE PRO-LABORE26 ABERTURA CONTA BANCARIA27 CRACHA28 CRACHA - SEGUNDA VIA29 COTA-PARTE30 ALTERACOES DADOS CADASTRAISElas não tem nenhum tipo de implicação com data, bem como podem ser repetidas para o mesmo solicitante numa mesma data, enfim, são meramente informativas ou pedem esclarecimentos, não tendo implicação direta com a previsão de labor do cooperado. A troca de plantão está neste grupo pois é um tipo de solicitação que na prática se traduz em duas solicitações, então desaconselhamos o uso dela em rpol de uma outra abordagem, pois apenas ela, faria com que tivéssemos uma outra modelagem de dados, ou um código muito maior, considerando que é o tipo mais sujeito a falhas e golpes, pois não gera desconto pecuniário, não a utilizaremos. Faz parte desse grupo pois futuramente a partir do momento em que a informatização das solicitações estiverem funcionandoa contento, iremos implementá-la, com código apenas.Esse grupo recebe um tipo de crítica:18 ASSOCIACAO19 DESLIGAMENTO20 INCLUSAO PROJETO21 DESLIGAMENTO DO PROJETO22 VINCULO CONTRATUAL23 DESLIGAMENTO DO CONTRATOEsse tipo de solicitação existe apenas para que o cooperado venha informar a cooperativa a sua pretenção, assim não é necessário validarmos a data, validarmos conteúdo, validarmos a repetição. Somente precisamos esconder um campo de data e validarmos a nulidade do campo para uma melhor compreenção do formulário. Futuramente elas estarão vinculadas a um tipo de relatório específicos ao ato associativo ou de desligamento.É preciso alertar quanto a ter um procedimento na cooeprativa para quando aparecer um desligamento ou desligamento de projeto, ter uma consulta personalizada para saber se aquele cooperado não tem solicitações posteriores a cobrir, para que sejam alteradas. No momento da inclusão da solicitação não é necessário esse tipo de verificação, uma vez que o usuário do sistema não terá autonomia para nenhuma medida.Poderíamos pensar que uma regra que implique que a solicitação de desligamento seja numa data posterior a atual fosse bem vinda, mas na verdade dentro do contexto cooperativista, isso traz mais transtornos que solução.Esse grupo tem uma crítica:15 AUSENCIA COMUNICADA PELO SETOR16 COBERTURA DE CREDITO17 INCIDENTE NA AFERICAO DA PRODUCAOComo o grupo anterior, esse grupo tem apenas uma crítica para uma maior legibilidade do formulário. No outro escondíamos um campo data, neste escondemos o solicitado, uma vez que implica apenas em solicitante. A única validação é de data inicial nula. A figura 15 é apenas para o tomador de serviço ter um valor base estimado para usar a própria ausência do cooperado sem aviso num outro serviço, este é um fato gerador de crédito para o tomador de serviço, que ele gastará com a figura 16, assim os valores de um tem que ser próximos aos do outro, porém aqui ele chamará o profissional que ele quiser, pro setor que lhe convir, sem estar relacionando diretamente a falta de um com a cobertura do outro.Os próximos dois grupos são separados em dois formulários distintos, porém as regras de um estão no outro também:1 SUBSTITUICAO3 AFASTAMENTO TEMPORARIO5 LICENCA GESTACAO7 LICENCA MATERNIDADE9 ACIDENTE DE TRABALHO11 ACIDENTE TRAJETO13 DESCANSO ANUALCom exceção da figura 1, os demais tipos de solicitação eles tratam de um período de tempo, assim eles implicam: Apenas um  solicitado para todo o período solicitado.  Vários  solicitados para todo o período.  É preciso  esconder o campo solicitado desses tipos.  O afastamento  temporário, o acidente de trabalho ou acidente de projeto  podem não ser conhecido a data final no momento da inclusão  da solicitação.  É  necessário uma regra que avise a existência de  solicitações dos tipos 2, 4, 6, 8, 10 , 12, 14 do  solicitante no papel de solicitante e solicitado posteriores ou  igual a data inicial da sua solicitação,  desconsiderando as que existirem posteriormente a data final da  solicitação.  É preciso  conhecer a existência de solicitações do  solicitante no papel de solicitante dos tipos 1, 3, 5, 7, 9, 11, 13  com data igual a da solicitação ou posteriores a data  inicial e anteriores a data final da mesma.  A substituição  precisa de uma validação de no máximo 5 no mês  para aquele solicitante. //Inicialmente criei um select para retornar o tipo de substituição e solicitante, depois fiz outro select apenas para retornar o mês, e juntei os dois, vendo que o resultado era o pretendido, mas não sabia como pegar apenas o mês do campo data no formulário, primeiro porque eu tinha definido o campo como data e hora, assim ele desmebrou um único timestamp em dois campos, pesquisando o php vi a função que retornava parte de uma string qualquer (substr), e comecei os testes. Visualmente no formulário a data estava dd/mm/aaaa, mas na verdade o formulário estava tratando-a internamente como aaaa-mm-dd hh:mm, assim bastou definir a variável abaixo:if({IDTIPOSOLI}==1){$mes = substr({INICIO}, 5, 2);sc_lookup(rs,"Select count(*) from solicitacaowhere SOLICITANTE = {SOLICITANTE}AND IDTIPOSOLI = 1AND (extract (month from (inicio)) = $mes)");if(({rs[0][0]})>=5){sc_error_message("Limite excedido para o mês solicitado.");}}Agora só falta colocá-la em eventos onValidate para não ser possível passar.A substituição  precisa ainda validar se o solicitante está em qualquer tipo  de solicitação cobertura como solicitado para a  referida data, a fim de enviar uma mensagem output ao usuário  autorizando-o a incluir a solicitação, bem como é  preciso validar se não existe um outro pedido de substituição  ou afastamento do solicitante como solicitante para a data referida  nesta.A substituição  não pode ser num período de tempo superior a 24 horas.  Para todos os  tipos desse grupo não podem existir data inicial nula.  Para os tipos 1,  5, 7, e 13 a data final não pode ser nula.  O descanso anual  uma validação de no máximo 1 no ano, por um  período não superior a 30 dias.  Licença  maternidade no máximo uma no ano por um período não  superior a 90 dias, precisa validar a existência do tipo  licença gestação num período de 12 meses  pois não é permitido ter as duas nesse período.  Licença  gestação no máximo uma no ano por um período  não superior a 90 dias, precisa validar a existência do  tipo licença maternidade num período de 12 meses pois  não é permitido ter as duas nesse período.  Ufa, nem sei se tem mais....rsrrsrs  Esse grupo recebe várias críticas como o grupo anterior, mas me parece ser um grupo mais homogêneo no tocante as críticas:2 COBERTURA SUBSTITUICAO4 COBERTURA AFASTAMENTO TEMPORARIO6 COBERTURA LICENCA GESTACAO8 COBERTURA LICENCA MATERNIDADE10 COBERTURA ACIDENTE TRABALHO12 COBERTURA ACIDENTE TRAJETO14 COBERTURA DESCANDO ANUALJá separamos esse grupo em outro formulário a fim de padronizarmos o tipo de solicitação e a sua visualização no relatório. Uma vez que é desse grupo de solicitação que sairão as validações para pagamento. No grupo anterior tratávamos de descontos, aqui apenas de pagamento.E as regras são: Data Inicial e  Data Final não superiores a 24 hs.  Um solicitado para  cada solicitante, e uma solicitação para cada serviço,  ou seja mesmo tratando de cobertura de afastamento temporário,  e mesmo tendo apenas um solicitado para cada solicitante, é  necessário o lançamento de todas as solicitações  de cobertira correspondente a cada serviço. Ex.: Cooperado  Fulano fez a solicitação do tipo 3 - Afastamento  Temporário com data inicial 01/01/2008 e data final  10/01/2008, nesse período ele trabalharia nos dias 02, 04,  06, 08 e 10. Assim teremos 5 solicitações do tipo 4 -  Cobertura Afastamento Temporário, uma para cada dia, todas  elas tendo o Fulano como solicitante, e conforme o caso, só o  sicrano como solicitado em todas elas. Podemos ainda ter o sicrano  no dia 02, o beltrano no dia 04, o nãoseioqueano no dia 06, o  fulanodinovo no dia 08 e o sicranonovamente no dia 10 como  solicitados.  A pesquisa de repetencia deve levar em  consideração menor que a data inicial e maior que a  data final, considerando a hora de entrada e de saída. Os  tipos de solicitações que podem existir...  //abaixo é apenas um lembrete, mas será incrementado com mais regrassc_lookup(rst, "select funcionario.idlotacao, f_lotacao.nome, funcionario.idcargo, f_cargo.nome, contrato_cooperado.con_codigo, cadcon.con_descricaofrom contrato_cooperadoinner join funcionario on (contrato_cooperado.idempresa = funcionario.idempresa) and (contrato_cooperado.idpessoa = funcionario.idpessoa)inner join f_lotacao on (funcionario.idempresa = f_lotacao.idempresa) and (funcionario.idlotacao = f_lotacao.idlotacao)inner join f_cargo on (funcionario.idempresa = f_cargo.idempresa) and (funcionario.idcargo = f_cargo.idcargo)inner join cadcon on (contrato_cooperado.con_codigo = cadcon.con_codigo)where funcionario.idempresa == [var_idempresa]and funcionario.idsituacao == '[var_idsituacao]'and funcionario.IDPESSOA == {SOLICITANTE}");if (!empty({rst})){{IDLOTACAOA}={rst}[0][0];{SETORDES}={rst}[0][1];{IDCARGOA}={rst}[0][2];{FUNDES} = {rst}[0][3];{CON_CODIGOA}={rst}[0][4];{CONTDES}={rst}[0][5];}evento ajax INICIO onChange$data_hoje = date('Y-m-d');$data_incremento = sc_data($data_hoje, "aaaa-mm-dd", "+ ", 3, 0, 0);if(({IDTIPOSOLI}!= 9 and {IDTIPOSOLI}!= 11 and {IDTIPOSOLI}!=15 AND {IDTIPOSOLI}!=16 AND {IDTIPOSOLI}!=17) AND ({INICIO} < $data_incremento)) { sc_error_message('Data inicial menor que o permitido!'); sc_set_focus({INICIO}); echo "Caro usuário, para esse tipo de solicitação a Data Inicial da mesma deve ser dois dias posteriores a data atual. Informe ao cooperado que a Cooperativa necessita ter prazo para que seja possível encontrar um substituto para a sua solicitação. Os tipos de solicitação 9, 11, 15, 16 e 17 não fazem parte dessa regra! Não se esqueça de colocar a hora de entrada! O acidente de trabalho ou trajeto podem ser incluídos no mesmo dia que aconteceram portanto a data atual pode ser informada e até mesmo uma data anterior! Isso também é possível para o incidente na aferição, ausência e crédito!"; } if(sc_date_empty({INICIO})) { sc_erro_mensagem("Data inicial vazia!"); sc_set_focus({INICIO}); echo "Caro usuário, é necessário preencher o campo Data Inicial para efetivar a inclusão da solicitação. Lembre-se: Os tipos de solicitação que não tem necessidade de data, o campo data não aparecerá como opção!"; }     evento ajax FIM onChange $data_hoje = date('Y-m-d'); $data_incremento = sc_data($data_hoje, "aaaa-mm-dd", "+ ", 3, 0, 0); if((({IDTIPOSOLI}!= 9) and ({IDTIPOSOLI}!= 11) and ({IDTIPOSOLI}!= 15) and ({IDTIPOSOLI}!=16) and ({IDTIPOSOLI}!=17)) and ({FIM} < $data_incremento)){ sc_error_message('Data final menor que o permitido!'); sc_set_focus({FIM}); echo "Caro usuário, para esse tipo de solicitação a Data Final da mesma deve ser igual ou maior que a Data Inicial. Não se esqueça de colocar a hora de saída! Os tipos de solicitação 9, 11, 15, 16 e 17 não fazem parte dessa regra! O acidente de trabalho ou trajeto podem ser incluídos no mesmo dia que aconteceram portanto a data atual pode ser informada e até mesmo uma data anterior! Isso também é possível para o incidente na aferição, ausência e crédito!"; } $hs = sc_dif_date({FIM},"aaaa-mm-dd",{INICIO},"aaaa-mm-dd"); if((({IDTIPOSOLI}!= 3) and ({IDTIPOSOLI}!=5) and ({IDTIPOSOLI}!=7) and ({IDTIPOSOLI}!=9) and ({IDTIPOSOLI}!=11) and ({IDTIPOSOLI}!=13)) and ($hs > 1)){sc_error_message('Data final maior que o permitido!');sc_set_focus({FIM});echo "Caro usuário, para esse tipo de solicitação a Data Final da mesma deveser igual a data atual ou no máximo um dia posterior!Não se esqueça de informar a hora de saída!Os tipos de solicitação 3, 5, 7, 9, 11 e 13 não fazem parte dessa regra pois tratamum perí0do de tempo que pode chegar a alguns meses, assim sendo, para esses tiposmencionados não será necessário informar a hora de entrada nem a hora de saída!";}if((({IDTIPOSOLI}!=3) and ({IDTIPOSOLI}!=9) and ({IDTIPOSOLI}!=11) and ({IDTIPOSOLI}!=15)and ({IDTIPOSOLI}!=16) and ({IDTIPOSOLI}!=17)) and (sc_date_empty({FIM}))){sc_erro_mensagem("Data final vazia!");sc_set_focus({FIM});echo "Caro usuário, é necessário preencher o campo Data Finalpara efetivar a inclusão da solicitação. Lembre-se: Os tipos de solicitaçãoque não tem necessidade de data, o campo data não aparecerá como opção!Uma exceção foi concedida aos tipos de solicitação 3, 9, 11, 15, 16, 17; uma vez queo afastamento, o acidente de trabalho e de trajeto pode não ser conhecido no momentoda inclusão da solicitação a data de retorno do cooperado solicitante.Abrimos uma possíbilidade para as vezes em que não se conhece a escala docooperado que teve incidente na aferição; ou foi comunicada a ausência do mesmomas não se conhece a escala; ou solicitado o crédito mas não se sabe a escala!Nesses casos é importante que o usuário busque pelo contrato essas informaçõesporque posteriormente os tipos 15, 16 e 17 não participarão dessa exceção!";}eventos onValidateif ({IDTIPOSOLI} = 0){sc_erro_mensagem("Tipo de Solicitação não aceito!");sc_set_focus({IDTIPOSOLI});}if (({IDTIPOSOLI}<>19 and {IDTIPOSOLI}<>21 and {IDTIPOSOLI}<>23 and {IDTIPOSOLI}<>24and {IDTIPOSOLI}<>25 and {IDTIPOSOLI}<>26 and {IDTIPOSOLI}<>27 and {IDTIPOSOLI}<>28and {IDTIPOSOLI}<>29 and {IDTIPOSOLI}<>30) and (sc_date_empty({INICIO}))){sc_erro_mensagem("A data inicial do evento não pode ser vazia!");sc_set_focus({INICIO});}if(({IDTIPOSOLI}<>3 and {IDTIPOSOLI}<>9 and {IDTIPOSOLI}<>11 and {IDTIPOSOLI}<>15and {IDTIPOSOLI}<>16 and {IDTIPOSOLI}<>17 and {IDTIPOSOLI}<>18 and {IDTIPOSOLI}<>20and {IDTIPOSOLI}<>22 and {IDTIPOSOLI}<>24 and {IDTIPOSOLI}<>25 and {IDTIPOSOLI}<>26and {IDTIPOSOLI}<>27 and {IDTIPOSOLI}<>28 and {IDTIPOSOLI}<>29 and {IDTIPOSOLI}<>30)and (sc_date_empty({FIM}))){sc_erro_mensagem("A data final deve ser preenchida");sc_set_focus({FIM});}$data_hoje = date('Y-m-d');$data_incremento = sc_data($data_hoje, "aaaa-mm-dd", "+ ", 3, 0, 0);if(({IDTIPOSOLI}=1 or {IDTIPOSOLI}=2 or {IDTIPOSOLI}=3 or {IDTIPOSOLI}=4or {IDTIPOSOLI}=5 or {IDTIPOSOLI}=6 or {IDTIPOSOLI}=7 or {IDTIPOSOLI}=8or {IDTIPOSOLI}=10 or {IDTIPOSOLI}=12 or {IDTIPOSOLI}=13 or {IDTIPOSOLI}=14)and ({INICIO} < $data_incremento)) { sc_error_message('A data inicial do evento deve ser dois dias posteriores a data atual!'); sc_set_focus({INICIO}); }  if(({IDTIPOSOLI}=1 or {IDTIPOSOLI}=2 or {IDTIPOSOLI}=4 or {IDTIPOSOLI}=5 or {IDTIPOSOLI}=6 or {IDTIPOSOLI}=7 or {IDTIPOSOLI}=8 or {IDTIPOSOLI}=10 or {IDTIPOSOLI}=12 or {IDTIPOSOLI}=13 or {IDTIPOSOLI}=14) and ({FIM} < $data_incremento)) { sc_error_message('A data final não deve ser MENOR que a data inicial do evento!'); sc_set_focus({FIM}); }  $hs = sc_dif_date({FIM},"aaaa-mm-dd",{INICIO},"aaaa-mm-dd");  if(({IDTIPOSOLI}=1 or {IDTIPOSOLI}=2 or {IDTIPOSOLI}=4 or {IDTIPOSOLI}=6 or {IDTIPOSOLI}=8 or {IDTIPOSOLI}=10 or {IDTIPOSOLI}=12 or {IDTIPOSOLI}=114 or {IDTIPOSOLI}=15 or {IDTIPOSOLI}=16 or {IDTIPOSOLI}=17) and ($hs > 1)){sc_error_message('A data final do evento não deve ser SUPERIOR à 1 dia que a data inicial!');sc_set_focus({FIM});}evento onRefreshif({IDTIPOSOLI}== 1 or {IDTIPOSOLI}== 3 or {IDTIPOSOLI}== 5 or {IDTIPOSOLI}== 7or {IDTIPOSOLI}== 9 or {IDTIPOSOLI}== 11 or {IDTIPOSOLI}== 13 or {IDTIPOSOLI}== 15or {IDTIPOSOLI}== 16 or {IDTIPOSOLI}==17 or {IDTIPOSOLI}==0){sc_field_display({SOLICITADO}, 'off');sc_field_display({TREINAMENTO}, 'off');sc_field_display({IDCARGOB}, 'off');sc_field_display({IDLOTACAOB}, 'off');sc_field_display({CON_CODIGOB}, 'off');}elseif({IDTIPOSOLI}== 2 or {IDTIPOSOLI}== 4 or {IDTIPOSOLI}== 6 or {IDTIPOSOLI}== 8or {IDTIPOSOLI}== 10 or {IDTIPOSOLI}== 12 or {IDTIPOSOLI}== 14){sc_field_display({INICIO}, 'on');sc_field_display({FIM}, 'on');sc_field_display({SOLICITADO}, 'on');sc_field_display({TREINAMENTO}, 'on');sc_field_display({IDCARGOB}, 'on');sc_field_display({IDLOTACAOB}, 'on');sc_field_display({CON_CODIGOB}, 'on');}elseif({IDTIPOSOLI}== 18 or {IDTIPOSOLI}== 20 or {IDTIPOSOLI}== 22){sc_field_display({FIM}, 'off');sc_field_display({SOLICITADO}, 'off');sc_field_display({TREINAMENTO}, 'off');sc_field_display({IDCARGOB}, 'off');sc_field_display({IDLOTACAOB}, 'off');sc_field_display({CON_CODIGOB}, 'off');}elseif({IDTIPOSOLI}== 19 or {IDTIPOSOLI}== 21 or {IDTIPOSOLI}== 23){sc_field_display({INICIO}, 'off');sc_field_display({SOLICITADO}, 'off');sc_field_display({TREINAMENTO}, 'off');sc_field_display({IDCARGOB}, 'off');sc_field_display({IDLOTACAOB}, 'off');sc_field_display({CON_CODIGOB}, 'off');}else{sc_field_display({INICIO}, 'off');sc_field_display({FIM}, 'off');sc_field_display({SOLICITADO}, 'off');sc_field_display({TREINAMENTO}, 'off');sc_field_display({IDCARGOB}, 'off');sc_field_display({IDLOTACAOB}, 'off');sc_field_display({CON_CODIGOB}, 'off');}