Histórico da Página
Este documento é material de especificação dos requisitos de inovação, trata-se de conteúdo extremamente técnico. |
---|
(Obrigatório)
Informações Gerais
Especificação | |||
Produto |
| Módulo |
|
Segmento Executor |
| ||
Projeto1 |
| IRM1 |
|
Requisito1 |
| Subtarefa1 |
|
Chamado2 |
| ||
País | ( ) Brasil ( ) Argentina ( ) Mexico ( ) Chile ( ) Paraguai ( ) Equador ( ) USA ( ) Colombia ( ) Outro _____________. | ||
Outros | <Caso necessário informe outras referências que sejam pertinentes a esta especificação. Exemplo: links de outros documentos ou subtarefas relacionadas>. |
Legenda: 1 – Inovação 2 – Manutenção (Os demais campos devem ser preenchidos para ambos os processos).
(Obrigatório)
Objetivo
<Nesta etapa informar o objetivo da especificação do requisito, ou seja, o que a funcionalidade deve fazer. Exemplo: Permitir que o usuário defina o percentual mínimo em espécie (dinheiro), a referência mínima para calculo dos débitos do aluno e o período de validade do parâmetro de negociação>.
(Obrigatório)
Definição da Regra de Negócio
- DESENVOLVIMENTO PARTICIPATIVO – CONTROLE DE COMPRAS E APROVAÇÃO DE FATURAMENTO DIRETO
- O processo de compras de material para um contrato é diferente do processo de compras ‘normal’, ou de pedido extra.
- Para as compras de material dos contratos, geralmente, a empresa incorporadora necessita aprovar a ‘compra’ antes de realizar a entrada da NF do material no seu nome
- Para que seja possível controlar este processo (fazer com que um usuário somente dê entrada numa NF de faturamento direto para um contrato, se existir uma OC aprovada para o contrato), faz-se necessário o desenvolvimento participativo abaixo:
CONTRATO:
ETAPA 1 (DESENVOLVIMENTO 1) – O Contrato deve ter valor default (código) para deduções e retenções e código do faturamento direto (deduções)
ð Se preenchidos, os itens gerados manualmente ou automaticamente como descritos abaixo devem vir com estes itens preenchidos;
ð Colocar um anexo para os fornecedores que podem fornecer para aquele contrato. (Se não tiver pode qualquer um)
- Será criado um serviço pelo TOP, consumido pelo Nucleus, verificando os fornecedores que poderão ser inseridos na Ordem de compra.
- Não será tratado cotação.
- Deverá ser modificada a tela do movimento exibindo o contrato e o fornecedor
SOLICITAÇÃO DE FATURAMENTO DIRETO:
ETAPA 1 (DESENVOLVIMENTO 1) – RECONHECER O PEDIDO DE FATURAMENTO DIRETO
ð O pedido de faturamento direto continuará partindo do módulo de engenharia (através do Pedido Extra), porém, com algumas particularidades;
ð Deverá ser criado no pedido Extra um Parâmetro de Projeto que cadastra de tipo de movimento fixo, pois o Lookup é liberado para o usuário selecionar qualquer tipo de movimento. Caso a opção seja habilitada, o TOP sempre usará o movimento do Parâmetro para Faturamento Direto, em caso negativo o TOP continua deixando o usuário informar o movimento.
ð Criar um Flag na capa do pedido extra “pedido de faturamento direto”
ð Se o Flag for marcado, tem que habilitar um ‘combo’ para o usuário selecionar o contrato (apareça somente os contratos de serviços ou de marco contratual ou contrato de Parcela Fixa)
ð Na aba “item do pedido de material extra”:
- Não precisa mais aparecer o campo ‘contrato’ -> automaticamente some o campo “contrato” (pois todos os itens que serão pedidos estarão vinculados ao contrato informado na capa do pedido extra)
- As tarefas a serem exibidas serão apenas as tarefas que estão no contrato que ainda tem saldo.
ð A partir do momento em que o pedido for gerado no sistema de compras (Nucleus), o tipo de movimento gerado deverá contar a informação do número do contrato (código do projeto e código do contrato)
ð Exemplo:
ð
- O número do contrato deve estar gravado na tabela, mas não deverá gerar a “DEDUÇÃO” (a dedução será somente no tipo de movimento que tiver o parâmetro “DEDUZ CONTRATO” habilitado)
- Ao receber o tipo de movimento, a informação “numero do contrato” deverá ser passado para os demais tipos de movimentos gerados
- Deverá ser alterada esta tela para também exibir o fornecedor do contrato.
EXEMPLO:
- Uma empresa que terceiriza toda a parte de construção (ex.: empresas que constroem shopping center, centros de convenções e outros), geralmente constrói 90% através de contratos de prestação de serviços;
- Nestas empresas, geralmente o próprio fornecedor do serviço quem faz a cotação de preços de material junto aos fornecedores;
- Elas (ou o responsável pelo projeto) lançam no sistema uma ORDEM DE COMPRAS relativo ao faturamento direto, informando o número do contrato;
- O encarregado pela obra somente irá dar entrada em uma NF de faturamento direto, caso exista uma OC aprovada (a empresa incorporadora garante que não todos os pagamentos à fornecedores de faturamento direto serão aprovados).
ETAPA 2 (DESENVOLVIMENTO 2) – VINCULAR A DEDUÇÃO DO FATURAMENTO DIRETO NAS TAREFAS DO CONTRATO (DURANTE A LIBERAÇÃO DA MEDIÇÃO DO CONTRATO)ð
- Quando existir um pedido extra com faturamento direto, deve deduzir de acordo com o rateio no movimento e deve ser preenchido automaticamente sempre, permitindo ao usuário, modificar o valor deduzido se necessário.
- Será feita uma consistência na liberação de contrato, para garantir a integridade (evitando que seja medido 100% de uma atividade que ainda possua nota fiscal a ser deduzida). Para isto será analisado se o saldo da tarefa a medir é superior ao que falta deduzir, caso contrário o sistema Barra.
- (Saldo Medir > Falta Deduzir)
- Será criado um Parâmetro de Projeto para os códigos padrões de “Dedução” e “Retenção”. Este parâmetro irá atuar tanto para faturamento direto quanto para outras formas de dedução e retenção.
ð O botão “gera integração com suprimentos/faturamento” não deve ser executado sem que o período seja liberado (é obrigatório clicar no botão de liberação do período primeiro). Para esta situação será criado um Parâmetro de Projeto que exigirá essa obrigatoriedade.
OBS.: Para os contratos que usam “DEDUÇÃO POR TAREFA”, na aba “deduções do contrato”, deveria ser apresentado automaticamente todos os itens comprados por tarefa. Será necessário reformular a tela (para dar mais usabilidade / visibilidade) a tarefa que será deduzida.
Motivo: O usuário ao realizar uma medição (liberação da medição) pode esquecer de deduzir o material de faturamento direto desta medição.
Ao efetuar uma medição de 100% de uma tarefa, se o usuário esquecer de deduzir o faturamento direto da tarefa, como ele vai deduzir essa NF no futuro (pois a tarefa já foi medida 100%)? Para este cenário a consistência na Liberação, deixará tratado para não acontecer de existir deduções maiores ao saldo a medir.
=> Consistências ao realizar medições / liberação das medições:
a) Se alguém informar manualmente uma outra retenção/dedução (no momento de realizar a liberação da medição), esta deve ser rateada globalmente (ratear da forma como faz hoje, uma vez que esta retenção/dedução manual não estará vinculada a uma NF - ratear proporcional para todas as tarefas), ou abrir a possibilidade de rateio nos itens medidos.
Exemplo: fornecimento de alimentação.
b) Só deixar deduzir um item de faturamento direto se tiver uma medição para a tarefa em questão (tarefa que tem rateio no movimento), e se essa medição puder absorver a dedução (integralmente ou em parte).
c) Controlar o saldo de faturamento direto (não deixar medir 100% e liberar 100% de uma tarefa, se tiver faturamento direto pendente para a tarefa).
d) Não será permitido a liberação para o faturamento sem antes se entrar na tela de liberação, e na tela de liberação o botão ao lado do campo “vlr retido pdo” deixará de existir, e o calculo deve ser feito de forma automática ao se entrar na tela ou se efetuar alterações na outra aba.
DETALHAMENTO DO COMPORTAMENTO DO NOVO PARÂMETRO – USA DEDUÇÃO POR TAREFA ****
Este ponto estava sendo tratado no CHAMADO TRQANC
Foi detectado pelo cliente um problema no rateio nas atividades ao efetuar a liberação da medição de um contrato que tenha faturamento direto.
De forma resumida (segue abaixo um passo a passo com as telas desta simulação), o problema acontece quando há um contrato com mais de um item associado, e há uma NF de compras faturamento direto para apenas UM dos itens associados.
Ao realizar a liberação da medição do contrato, os valores “deduzidos” em relação ao faturamento direto estão sendo rateados em todos os itens associados ao contrato, conforme exemplo abaixo:
CÓDIGO DA TAREFA | VALOR ORÇADO | VALOR CONTRATADO | VALOR MEDIDO (100%) | VALOR DE FATURAMENTO DIRETO | RETENÇÃO TÉCNICA (5%) | VALOR LIBERADO PELO SISTEMA | VALOR QUE DEVIA SER LIBERADO |
01.01.07.01 | R$ 50.000,00 | R$ 50.000,00 | R$ 50.000,00 | R$ 23.780,00 | R$ 2.500,00 | R$ 39.573,33 | R$ 23.720,00 |
01.01.07.02 | R$ 100.000,00 | R$ 100.000,00 | R$ 100.000,00 | R$ - | R$ 5.000,00 | R$ 79.146,67 | R$ 95.000,00 |
TOTAIS | R$ 150.000,00 | R$ 150.000,00 | R$ 150.000,00 | R$ 23.780,00 | R$ 7.500,00 | R$ 118.720,00 | R$ 118.720,00 |
Percebe-se no exemplo acima, que o valor de R$ 23.780,00 relativo às compras de faturamento direto estão associadas apenas ao item 01.01.07.01. No momento de efetuar a medição e gerar a liberação, este valor está sendo deduzido proporcionalmente entre todas as atividades medidas do contrato.
Esta problemática faz com que o “valor apropriado” na tarefa, fique incorreto.
SEGUE ABAIXO PASSO A PASSO DA SIMULAÇÃO:
1 – Simulação 01 - Cadastro do contrato:
2 - Simulação 02 - Entrada de NF Faturamento direto
Foi efetuada uma compra de dois itens (madeira e gesso) para o primeiro item associado ao contrato (01.01.07.01), totalizando R$ 23.780,00
3 - Simulação 03 - Rateio por centro de custo do item 01
O produto de número 1 comprado no faturamento direto foi apenas para a atividade 01.01.07.01
4 - Simulação 04 - Rateio por centro de custo do item 02
O segundo item da NF também foi associado apenas a atividade 01.01.07.01
5 - Simulação 05 - Valor do Faturamento Direto Dentro do Contrato
Após dar entrada nas NF, os dois produtos estão sendo vistos no anexo do contrato (“Produtos faturados no contrato”)
6 - Simulação 06 - Medição do contrato
Foi efetuada uma medição de 100% dos dois itens do contrato, totalizando R$ 150.000,00
7 - Simulação 07 - Liberação da medição do contrato (Valores informados)
No momento de liberar o período medido R$ 150.000,00, foram deduzidos 100% dos itens do faturamento direto (também houve uma retenção técnica).
8 - Simulação 08 - Valor total retido
9 - Simulação 09 - Pagamento da medição do contrato
Geração da ordem de pagamento da medição
10 - Simulação 10 - Rateio por centro de custo do pagamento da medição do contrato
Na figura abaixo é possível observar que a ordem de pagamento da medição levou o rateio proporcional (ou seja, a apropriação de custo das duas atividades ficarão incorretas, pois os produtos de faturamento direto foram comprados apenas para a atividade 01.01.07.01, e no pagamento da medição estes produtos foram deduzidos de todos os itens do contrato).
CÓDIGO DA TAREFA | VALOR ORÇADO | VALOR CONTRATADO | VALOR MEDIDO (100%) | VALOR DE FATURAMENTO DIRETO | RETENÇÃO TÉCNICA (5%) | VALOR LIBERADO PELO SISTEMA | VALOR QUE DEVIA SER LIBERADO |
01.01.07.01 | R$ 50.000,00 | R$ 50.000,00 | R$ 50.000,00 | R$ 23.780,00 | R$ 2.500,00 | R$ 39.573,33 | R$ 23.720,00 |
01.01.07.02 | R$ 100.000,00 | R$ 100.000,00 | R$ 100.000,00 | R$ 0,00 | R$ 5.000,00 | R$ 79.146,67 | R$ 95.000,00 |
TOTAIS | R$ 150.000,00 | R$ 150.000,00 | R$ 150.000,00 | R$ 23.780,00 | R$ 7.500,00 | R$ 118.720,00 | R$ 118.720,00 |
ð Para
- Para este item será necessário modificar a Tela de dedução mostrando qual a tarefa será deduzida e consequentemente criar uma nova consistência onde o total da dedução não poderá ser maior que o total medido da tarefa.
Opcional
Protótipo de Tela
<Caso necessário inclua protótipos de telas com o objetivo de facilitar o entendimento do requisito, apresentar conceitos e funcionalidades do software>.
Protótipo 01
Opcional
Fluxo do Processo
<Nesta etapa incluir representações gráficas que descrevam o problema a ser resolvido e o sistema a ser desenvolvido. Exemplo: Diagrama - Caso de Uso, Diagrama de Atividades, Diagrama de Classes, Diagrama de Entidade e Relacionamento e Diagrama de Sequência>.
Opcional
Dicionário de Dados
Arquivo ou Código do Script: AAA – Negociação Financeira / *Versao=CP.2014.12_03*/
Índice | Chave |
01 | <FI9_FILIAL+FI9_IDDARF+FI9_STATUS> |
02 | <FI9_FILIAL+FI9_FORNEC+ FI9_LOJA+FI9_EMISS+FI9_IDDARF> |
03 | <FI9_FILIAL+FI9_FORNEC+ FI9_LOJA+FI9_PREFIX+FI9_NUM+FI9_PARCEL+FI9_TIPO> |
Campo | <AAA_PERESP> |
Tipo | <N> |
Tamanho | <6> |
Valor Inicial | <Varia de acordo com o tipo informado. Por exemplo, quando o campo “tipo” for date, neste campo pode ser informado uma data>. |
Mandatório | Sim ( ) Não ( ) |
Descrição | <Referência Mínima para Cálculo> |
Título | <Ref.Calc.> |
Picture | <@E999.99> |
Help de Campo | <Informar o % que o aluno pagará em dinheiro. Esse % poderá ser alterado durante a negociação> |
(Opcional)
Grupo de Perguntas
<Informações utilizadas na linha Protheus>.
Nome: FINSRF2
X1_ORDEM | 01 |
X1_PERGUNT | Emissão De |
X1_TIPO | D |
X1_TAMANHO | 8 |
X1_GSC | G |
X1_VAR01 | MV_PAR01 |
X1_DEF01 | Comum |
X1_CNT01 | '01/01/08' |
X1_HELP | Data inicial do intervalo de emissões das guias de DARF a serem consideradas na seleção dos dados para o relatório |
(Opcional)
Consulta Padrão
<Informações utilizadas na linha Protheus>
Consulta: AMB
Descrição | Configurações de Planejamento |
Tipo | Consulta Padrão |
Tabela | “AMB” |
Índice | “Código” |
Campo | “Código”; ”Descrição” |
Retorno | AMB->AMB_CODIGO |
(Opcional)
Estrutura de Menu
<Informações utilizadas na linha Datasul>.
Procedimentos
Procedimento |
|
|
|
Descrição | (Max 40 posições) | (Max 40 posições) | (Max 40 posições) |
Módulo |
|
|
|
Programa base |
|
|
|
Nome Menu | (Max 32 posições) | (Max 32 posições) | (Max 32 posições) |
Interface | GUI/WEB/ChUI/Flex | GUI/WEB/ChUI/Flex | GUI/WEB/ChUI/Flex |
Registro padrão | Sim | Sim | Sim |
Visualiza Menu | Sim/Não | Sim/Não | Sim/Não |
Release de Liberação |
|
|
|
Programas
Programa |
|
|
|
Descrição | (Max 40 posições) | (Max 40 posições) | (Max 40 posições) |
Nome Externo |
|
|
|
Nome Menu/Programa | (Max 32 posições) | (Max 32 posições) | (Max 32 posições) |
Nome Verbalizado[1] | (Max 254 posições) | (Max 254 posições) | (Max 254 posições) |
Procedimento |
|
|
|
Template | (Verificar lista de opções no man01211) | (Verificar lista de opções no man01211) | (Verificar lista de opções no man01211) |
Tipo[2] | Consulta/Manutenção/ Relatório/Tarefas | Consulta/Manutenção/ Relatório/Tarefas | Consulta/Manutenção/ Relatório/Tarefas |
Interface | GUI/WEB/ChUI/Flex | GUI/WEB/ChUI/Flex | GUI/WEB/ChUI/Flex |
Categoria[3] |
|
|
|
Executa via RPC | Sim/Não | Sim/Não | Sim/Não |
Registro padrão | Sim | Sim | Sim |
Outro Produto | Não | Não | Não |
Visualiza Menu | Sim/Não | Sim/Não | Sim/Não |
Query on-line | Sim/Não | Sim/Não | Sim/Não |
Log Exec. | Sim/Não | Sim/Não | Sim/Não |
Rotina (EMS) |
|
|
|
Sub-Rotina (EMS) |
|
|
|
Localização dentro da Sub Rotina (EMS) |
|
|
|
Compact[4] | Sim/Não | Sim/Não | Sim/Não |
Home[5] | Sim/Não | Sim/Não | Sim/Não |
Posição do Portlet[6] | 0 – Top Left 1 – Top Right 2 – Bottom Left 3 – Bottom Right | 0 – Top Left 1 – Top Right 2 – Bottom Left 3 – Bottom Right | 0 – Top Left 1 – Top Right 2 – Bottom Left 3 – Bottom Right |
Informar os papeis com os quais o programa deve ser vinculado |
|
|
|
Cadastro de Papéis
<O cadastro de papéis é obrigatório para os projetos de desenvolvimento FLEX a partir do Datasul 10>.
<Lembrete: o nome dos papeis em inglês descrito neste ponto do documento, devem ser homologados pela equipe de tradução>.
Código Papel | (máx 3 posições) |
Descrição em Português* |
|
Descrição em Inglês* |
|
[1] Nome Verbalizado é obrigatório para desenvolvimentos no Datasul 10 em diante.
[2] Tipo é obrigatório para desenvolvimento no Datasul 10 em diante
[3] Categorias são obrigatórias para os programas FLEX.
[4] Obrigatório quando o projeto for FLEX
[5] Obrigatório quando o projeto for FLEX
Este documento é material de especificação dos requisitos de inovação, trata-se de conteúdo extremamente técnico. |
---|