Jair - Fórmula

Sim, pode gerar problemas, pois, esses códigos ditam para o sistema algumas formas de tratamentos nos dados. Desta forma, contendo algo inválido pode ocorrer problema sim.

Olá @LUIZ ALEXANDRE CABRA, você não tem acesso a cadastrar os itens nessa tabela. Nela as constantes são fixas pelo sistema.

Consegui... Não é o print da tela, mas são os dados no banco, via select. Dá uma conferida nessa planilha, e atualiza ai. Depois, manda aqui para nós, para termos no formato de print das telas dessa configuração, ou mesmo exportando, no formato .LBA nos processos desta tela... Retorno Cobrança SICREDI.xlsx

Gerson é fera!! Ex RM, já trabalhou lá, antes da era TOTVS, por muito tempo. Já possui o sistema PDV Consult há décadas!! Muito bom mesmo.

Você tem o Layout disponibilizado pelo Banco?? Tenta pegar nele, que geralmente tem as informações, ai vai ajustando e vai testando. Até achei que tinha, mas o que tenho é SICOOB. Estou vendo se consigo este SICREDI. Caso consiga, aviso aqui.

Opa. Boa tarde!! Já achou aí?? Ahh, que bom que compartilhou com todos também

RESOLVIDO!!

Muito bom! Obrigado por compartilhar @macas caso tenha como postar uma imagem do cubo, o layout que montou, com os dados e tal, seria legal. Mesmo que esconda (deixe borrado) dados que possam ser confidenciais.

Não há uma regra fixa para definir os períodos no sistema RM. Desta forma, não tem como AFIRMAR quais períodos são de adiantamento, folha, ferias, 13o., etc. O que ocorre é que, as empresas usam suas regras para "ditar" quais são os períodos a usar. Tem gente que assume: 1 - Adto 2 - Folha 3 - Folha Complem 5 - Rescisões 6 - 13o. Salário 8 - PLR 10 - Outros Períodos ou mesmo algo assim: 1 - Adto 2 - Folha/Rescisões 3 - Dif. Folha 10 - 13o. Salário 20 - PLR Realmente, não tem regra... o mais importante, é que, não exista sequencia de pagamentos que ocorram (e possam gerar DEVES - arredondamento) onde uma folha seja calculada, e o DEVE dela você queria tratar num período anterior, por exemplo, se você pagar algo no período 10 em 10/07/2025 e depois tenha a Folha sendo paga em 30/07 no período 2. E se o usuário está criando os períodos de forma "correta" sempre, pode ler essa tabela que citou, e usar ela nas suas sentenças SQL.

Nas últimas versões liberadas do TOTVS RM, o desenvolvimento anda alterando telas do sistema para o novo formato (layout) em PO-UI, o que muitos não estão gostando, pois, são telas sem recursos que estamos já bastante acostumados, sem um visual que estamos acostumados, não permitem filtros como estamos acostumados, etc. Não é apenas questão de estar acostumado, mas de facilidades que faltam (ao menos por enquanto não temos nestas novas telas), e recursos a menos, que precisamos, como: Telas de Anexos, de SQL, Relatórios, de Gráficos, ... Possibilidade de engatilhar Fórmulas Visuais, seja como processos ou mesmo para adição de campos, alterações de propriedades de campos, validações, etc. Campos Customizáveis/Colunas Calculadas Formatação Condicional Associação de Actions Auto-Filtros, Filtros com Cons. SQL, Totalizadores, ... Vamos listar aqui quais são as telas que já estamos encontrando em PO-UI, citando de quais sistemas, e quais locais? Se tiver algum outro ponto, por enquanto todos negativos, que não foi citado acima, comentem também. E prós, alguém tem algum??

Vamos lá. Para tratar por SQL um condicional em que, somente para algumas pessoas que tenham um determinado perfil associado, seja bloqueado o campo no cadastro de funcionário, deverá fazer algumas alterações na sua FV. Vejamos: 1) Adicione duas novas atividades no fluxo de sua FV (Se/Senão e Executar Consulta SQL 2) Deixe então desta forma, onde a sua atividade anterior, já criada, ficará dentro do condicional, caso atenda a regra para o bloqueio. Renomeie suas atividades para melhor entendimento quando visualizado. 2.1) Na primeira atividade agora, você deve adicionar uma sentença SQL, que pode ser feito pelo botão direito do mouse (em cima do nome desta) ou preenchendo manualmente os campos com os alertas em vermelho na parte da esquerda do painel. ou 2.2) Após selecionar a sua SQL (ela pode ser criada nesse momento que vai inserir também, quando usado pelo botão direito em cima da atividade) ficará desta forma abaixo. Código da Aplicação: P Código da Coligada: 0 Código da Sentença: TestaPerfil 2.3) Já os parâmetros da consulta, ao ser lida a sua consulta, ela exigindo parâmetros, eles aparecem logo acima do RM.NET, e devem ser preenchidos. Você deve usar, neste caso, as informações de contexto, como nesse exemplo que foram preenchidas. 3) Esta é a sentença que precisa ser adicionada para os testes de perfis. Neste caso, está testando se o usuário possui o perfil "Cad", e/ou outros perfis, podendo ser ajustado conforme o seu caso, e não apenas nos perfis da Folha, como em outros perfis de outros módulos. Ajuste a SQL conforme o que precisar. 4) No primeiro quadro de condicional à esquerda (chamei de "SeAtendeCondicao"), você deve preencher uma condição com regra declarativa, onde na expressão deve estar desta forma abaixo. No segundo quadro, não precisa ter nada, nem mesmo o quadro, se não quiser fazer nada no caso de não atender a condição informada: 5) Finalizados os preenchimentos dos parâmetros, e todas as amarrações, seu fluxo estará assim como abaixo, podendo ser gravado e usado. Veja que não há mais quaisquer alertas em vermelho indicando que falta preencher algo. AGORA, com a sua FV engatilhada no cadastro de usuários, vai bloquear apenas para quem tiver os perfis específicos que deixou configurado na SQL de testes... No meu caso aqui, eu não tenho o perfil "Cad" associado no meu usuário de testes. O campo estava liberado normalmente. Após associar no meu usuário este perfil, entrei de novo nos funcionários, e o campo estava bloqueado. Removi, e voltei a ter acesso completo ao campo. BloqueiaAlteracaoCPF_comSQL.TotvsWF

Exato. Como comentei acima. Vamos ter que tratar isso com uma consulta SQL, lendo os perfis que tem acesso a alterar, e quem não atender a esse critério, mantemos a atividade da alteração de propriedades da coluna, bloqueando o acesso.

Profissionais com mais de 20 anos liderando inovações, nossa missão é transformar complexidades em soluções eficientes. Especialistas em consultoria, customizações e treinamentos, estamos aqui para elevar seu negócio ao próximo nível. https://www.bemper.com.br/ Rua Acarape, 138 - Santa Clara, Vespasiano - MG, Brasil +55-(31) 3197-0225 suporte@bemper.com.br

Deixa eu te perguntar uma coisa... Esse pessoal que não pode alterar, por acaso não é do mesmo grupo que pode fazer a inclusão do funcionário, é?? Se não for, você pode também travar isso pelo perfil, de forma que, o pessoal que inclui tem acesso a alterar, já o pessoal das lojas (que apenas fazem consultas), podem visualizar, mas não alteram. Já verificou essa permissão nos perfis? Porque, desta forma, nem precisaria da FV. Seria essa permissão abaixo, que você deixaria habilitado apenas nos perfis que podem alterar a informação. Se precisar mesmo que seja tratado nela, podemos fazer via SQL, que analisa os perfis do usuário e então, entra ou não na condição de alteração das propriedades do campo.

Exatamente. Isso que imaginei quando li o email de resposta "genérico" que recebi.