Histórico da Página

(Obrigatório)

Informações Gerais

   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>.

O Portal Agrícola é um sistema Web e tem como objetivo disponibilizar, de forma rápida e clara, informações referentes à recepção da matéria prima, pagamento e recebimento de fornecedores.

 

 

(Obrigatório)

Definição da Regra de Negócio

1. 1.     Cadastro de Notícias

Objetivo: Permite o cadastro e edição de notícias do portal agrícola.

Menu: Básico > Notícia

Atividade: Implementar um mecanismo (flag) para controle das notícias públicas (FG_PUBLICO = “S”) e privatas (FG_PUBLICO = “S”). Modificar a estrutura da tabela PA_NOTICIA para atender o flag FG_PUBLICO.

1. 2.     Cadastro de Links

Objetivo: Permite o cadastro e edição de links do portal agrícola.

Menu: Básico > Links

Atividade: Implementar um mecanismo (flag) para controle das notícias favoritas (FG_FAVORITO = “S”) e comuns (FG_FAVORITO = “N”). Modificar a estrutura da tabela PA_LINK para atender o flag FG_FAVORITO.

1. 3.     Visualização de Auditoria

Objetivo: Permite a consulta de LOGs e auditoria do portal agrícola.

Menu: Visualização > Auditoria

Atividade: Implementar consulta otimizada para busca de LOGs e eventos de auditoria do portal agrícola. Utilizar implementação de LazyList para melhorar desempenho dos recursos de listagem de ações, usuários executadores e parâmetros de informações enviadas/realizadas.

1. 4.     Visualização de Consulta

Objetivo: Permite a execução de consultas catalogadas para fornecedores e prestadores de serviço no portal agrícola.

Menu: Visualização > Consulta

Atividade: Modificar a execução das consultas catalogadas no portal agrícola para resultarem em relatórios no formato PDF. Dessa forma, ao invés de os resultados serem exibidos em uma tabela (grid) de informações, um arquivo PDF deve ser gerado e disponibilizado para o usuário solicitante (fornecedor e/ou prestador de serviços). Deverão ser utilizados os recursos da API de DynamicReports para a geração dinâmica das consultas. Tal implementação deve atender as consultas já existentes, bem como a novas (descritas no item de especificação 5 deste documento).

1. 5.     Cadastro de Consulta

Objetivo: Permite o cadastro e edição de consultas catalogadas do portal agrícola.

Menu: Básico > Consulta

Atividade: Catalogar 11 novas consultas para fornecedores e/ou prestadores de serviços.

As consultas são:

01_01_07 – Relatório de Impureza

01_01_08 – Relatório de Produção por Operadores

01_01_09 – Sumário de Cargas

01_01_10 – Produção por Recursos

01_01_11 – Relatório de Cargas por Local - Diário

01_01_12 – Sumário de Produção por Equipamento

01_01_13 – Posição Geral de Entrega de Matéria Prima

01_01_14 – Demonstrativo Diário de Entrega Quinzenal

01_03_01 – Demonstrativo de Pagamentos de Parceria

01_04_01 – Resumo de Contratos COFINANC

01_02_06 – Extrato Financeiro Consolidado

1. a.     01_01_07 – Relatório de Impureza

[Código da Consulta]

01.01.07

[Nome da Consulta]

Relatório de Impureza

[Descrição da Consulta]

O relatório de impureza tem por objetivo demonstrar a qualidade da entrega de cana por parte do fornecedor. Neste caso será analisado o percentual de impureza frente ao volume de cana entregue. Os dados demonstrarão o índice de eficiência por operador no ato do carregamento da cana no campo, pois estarão demonstrados os dados da fazenda, operador, equipamento, volume de cana com impureza, percentual analisado e o quanto de cana foi detectado sem impureza.

[Categoria da Consulta]

Consultas.Entrada de Cana

Ícone da Consulta

Particularidadese/ou Especificidades da Consulta

1. Esta consulta, como demonstrado, possuirá quatro níveis de quebras ou totalizações: Fazenda, Operador, Equipamento e Total Geral.
2. A cada troca de operador, o SQL totalizador de operadores deverá ser executado e sua linha deverá ser exibida em negrito imediatamente após a última linha de equipamento.
3. A cada troca de fazenda, o SQL totalizador por fazenda deverá ser executado e sua linha deverá ser exibida em negrito imediatamente após a última linha de operador.
4. Ao final da pesquisa, executar o SQL de totalização geral. Sua linha deverá ser exibida em negrito imediatamente após a última linha de fazenda.

Campos da Consulta

Filtros da Consulta

1. 
   b. 01_01_08 – Relatório de Produção por Operadores
   

[Código da Consulta]

01.01.08

[Nome da Consulta]

Relatório de Produção por Operadores

[Descrição da Consulta]

O relatório de produção por operadores tem por função demonstrar a atuação dos colaboradores da empresa/uisna nas frentes de colheitas e transportes. Essa consulta sintetiza informações como quantidade de cargas trabalhadas, viagens realizadas, volume de cana em toneladas e o raio (distância) médio trabalhado no período.

[Categoria da Consulta]

Consultas.Entrada de Cana

Ícone da Consulta

 Image Added

Particularidades e/ou Especificidades da Consulta 

1. Esta consulta será uma listagem simples, com o detalhamento a nível de operador.
2. Haverá uma linha totalizadora ao final de todo o relatório, conforme SQL específico.

Campos da Consulta

Filtros da Consulta

1. c. 01_01_09 – Sumário de Cargas
   
   

[Código da Consulta]

01.01.09

[Nome da Consulta]

Sumário de Cargas

[Descrição da Consulta]

O relatório de Sumário de Cargas tem por objetivo demonstrar a quantidade de cana entregue pelo fornecedor, quantidade de cargas, média de t/cargas e média de TMP.

[Categoria da Consulta]

Consultas.Entrada de Cana

Ícone da Consulta

Image Added

Particularidadese/ou Especificidades da Consulta

1. Esta consulta, como demonstrado, possuirá três níveis de quebras ou totalizações: Frente, Fazenda e Total Geral.
2. A cada troca de Frente, o SQL totalizador porFrente deverá ser executado e sua linha deverá ser exibida em negrito imediatamente após a última linha da referida Frente. Uma observação aqui é que este SQL traz o total de todas as Frentes listadas na consulta, portanto teremos de filtrar de qual Frente queremos buscar o total.
3. A cada troca de Fazenda, o SQL totalizador por Fazenda deverá ser executado e sua linha deverá ser exibida em negrito imediatamente após a última linha da referida Fazenda.Uma observação aqui é que este SQL traz o total de todas as Fazendas listadas na consulta, portanto teremos de filtrar de qual Fazenda queremos buscar o total.
4. Ao final da pesquisa, executar o SQL de totalização geral. Sua linha deverá ser exibida em negrito imediatamente após a última linha de totalizador de Frente.

Campos da Consulta

Filtros da Consulta

(Obrigatório)

Definição da Regra de Negócio

<Regra de negócio é o que define a forma de fazer o negócio, o processo definido e/ou as regras que devem ser contempladas. Devem ser descritas restrições, validações, condições e exceções do processo. Caso necessário, incluir neste capítulo também regras de integridade que devem ser observadas no momento do desenvolvimento>.

<Na tabela abaixo informe quais são as rotinas envolvidas, o tipo de operação, a opção de menu e se necessário uma breve descrição das regras de negócio relacionadas a rotina>.

Exemplo de Aplicação:

• Criar o campo “% Mínimo Espécie” (AAA_PERESP) onde o usuário informará o % que o aluno pagará em dinheiro. Esse % poderá ser alterado durante a negociação.
• Criar o campo “Referência Mínima para Cálculo” (AAA_REFCAL) onde o usuário informará um dos 4 valores disponíveis para pagamento das mensalidades  como a referência mínima para calcular o débito total do aluno.
• Criar o parâmetro MV_ACPARNE que definirá se as informações de “% Mínimo Espécie” e “Referência Mínima para Cálculo” serão obrigatórias.
• O parâmetro MV_ACPARNE deve ter as seguintes opções: 1=Obrigatório e 2=Opcional. Deve ser inicializado como opcional>.

Tabelas Utilizadas

• SE2 – Cadastro de Contas a Pagar
• FI9 – Controle de Emissão de DARF>.

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*/

(Opcional)

Grupo de Perguntas

<Informações utilizadas na linha Protheus>.

Nome: FINSRF2

(Opcional)

Consulta Padrão

<Informações utilizadas na linha Protheus>

Consulta: AMB

(Opcional)

Estrutura de Menu

<Informações utilizadas na linha Datasul>.

Procedimentos

Programas

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>.