Aderência Disponibilizar a Exportação por Saída de Pluma
3 - Alteração
Criado botão “Exportar Arq. Plumas“ na Venda de Pluma, que fica habilitado em vendas fechadas, e ao clicar nele gera um arquivo no lugar desejado com as plumas no layout padrão para importar na tela de Entrada de Pluma.
PSGA » Cotton» Movimentação » Pluma » Produção Pluma
2 - Objetivo
Ajuste na visualização de fardos na tela de produção de pluma
3 - Alteração
Para não haver alteração em index da tabela no Cliente foi então alterado a Ordenação da GRID para 0, que representa a Ordenação do RECNUM. E para fazer a ordenação inversa foi adicionado a propriedade pbReverseOrdering como Verdadeiro.
PSGA » Cotton » Utilitários » Exportação de Dados do Lote
2 - Objetivo
Acrescentar filtros de fardo e endereço na tela de importação de fardos
3 - Alteração
Criados os filtros "Fardo Inicial" e "Fardo Final" na tela de exportação de fardos. Os campos irão filtrar pelo código do fardo (os 6 últimos digitos, excluindo o último digito, do código de barras)
Criado o Filtro "Endereço Fazenda" para filtrar os fardo por endereço do Take-UP, Romaneio de Emblocamento ou produtor.
Ajustado o filtro que estava incorreto na lookup de consulta de romaneio de entrada de algodão
Criados os filtros por produtor inicial e final nas lookups de romaneio de produção, emblocamento e takeup
PSGA » Cotton » Utilitários » Exportação de Dados do Lote
2 - Objetivo
Criar filtros na tela de exportação de dados dos Fardos
3 - Alteração
Criados os filtros "Data Inicial e Final de Beneficiamento" na tela de exportação de fardos do lote. Os campos irão filtrar os fardos pelo campo thpluma.data
PSGA » Cotton » Utilitário » Exportação de Dados de Fardinho. PSGA » PSGA-APP.
2 - Objetivo
Implementar a Ordenação da Exportação de Fardos para Classificação.
3 - Alteração
Foi alterado a query: RETORNA_RECNUM_EXPORTCLASS
Foi criado a query: RETORNA_RECNUM_FARDO_EXPORTCLASS
Mesmo sabendo que a geração de cada classificação tem um tempo de diferença perceptivo, foi adicionado mesmo assim uma ordenação pelo Recnum.
Já os fardos presentes no arquivo são adicionados via integração muitas vezes ao mesmo tempo, não havendo ordenação pelo fardo e sim pelo Recnum, gerando uma classificação com fardos desordenados. Sendo assim foi removido a query que fazia a adição desses fardos em código e adicionado em uma query externa, já ordenando assim pelo código do fardo. E deixando em query para futuras customizações.
Ajustar relatórios de lotes para considerar armazenagem
3 - Alteração
Foi realizado novas analises durante o desenvolvimento, onde foi esclarecidos alguns pontos:
O relatório de Resumo de Emblocamento por Data foi feito exclusivamente para o Cliente em questão para suprir a necessidade de acompanhar o movimento da produção nas suas fases de emblocamento, take-up e saída dependendo do Período informado, ou seja dentro desse período esperasse ver qual era a Ultima atualização desse bloco. Na época nenhum relatório oferecia esse acompanhamento, e o relatório de Resumo de Emblocamento Padrão é utilizado de forma constantes em diversos outros clientes não podendo realizar uma alteração grande sem nenhum impacto. Como o pedido ia além de uma customização foi realizado então a tarefa para a geração do relatório de emblocamento por Data.
Sabendo disso o relatório foi criado. E agora surgiu o problema que não havia sido analisado na época, as Reentradas de pluma, onde para esse problema é encaixado outras situações:
Após estudar a rotina de reentrada foi percebido que reentradas para o mesmo produtor não geram um novo emblocamento, sendo utilizado o mesmo do Beneficiamento, e nesse processo a data é atualizada, assim perdendo a Data que foi criado o emblocamento.
Porém o problema não se resolve apenas impedindo de atualizar já que ambas as datas, tanto da criação do emblocamento quanto da reentrada são importantes.
Sabendo dessas informações fica inviável realizar alguma alteração na rotina de reentrada ja que a mesma está funcionando normalmente e a Data de criação do emblocamento só interfere no relatório em questão. Então foi alterado a query INSERE_PLUMA_STATUS_TWROMBLO que é responsável pela montagem do relatório.
Na query foi realizado uma relação com a criação de emblocamento a partir da importação de classificação visual, utilizando a tabela de Log da Classificação TLOGCLAS, onde a mesma data gravada nessa tabela é a mesma utilizada na geração do Emblocamento.
Foi ajustado o relatório para ter uma amostragem semelhante ao relatório de resumo de Emblocamento Padrão.
Foi aproveitado para ajustar a condição da RV para considerar relatório personalizado para o Emblocamento por Data, que antes não estava sendo considerado.
OBS.:
Sobre a especificação dessa AG onde foi informado que o problema também está no Relatório de Lotes Resumido por Tipo:
Na verdade esta informação quis dar referência ao “Relatório de Lotes Resumidos”, que no cliente está renomeado para “Relatório de Lotes Resumido por Tipo”. E como foi dito anteriormente, esse relatório é utilizado por diversos clientes e não é formado por querys ou outras formas diferentes, sua filtragem é diretamente na tabela, e ele tem a função de mostrar a informação do Bloco Atualmente. Uma informação fixa. E como a data do Bloco na reentrada é alterada, esse relatório irá mostrar baseado na data alterada. Para ele considerar esse caso seria necessário gerar um novo campo ou uma alimentação de data diferente, porém seria necessário realizar uma nova analise considerando todos os pontos dos dois processos. Como o relatório Resumido por data já atende essa especificação, o cliente não necessitaria do relatório Padrão.
4 - Configuração
Parâmetro P_GERA_EMBLOCAMENTO_AUTO_IMP_CLASS ser igual a 'S'
PSGA » Cotton » Relatórios » Relatórios de Pluma » take-up (Relação de fardos disponíveis em take-up).
2 - Objetivo
Ajustar o relatório para imprimir apenas ttakeups que não foram embarcados.
3 - Alteração
Implementado view para retornar somente takeups que possuvem fardos disponíveis e vinculado ao relatório TRelRomTakAlgPluDisp.rpt. Também foi personalizado o mesmo relatório no cliente Cooperbem, com mudanças no layout.
PSGA » Cotton » Relatórios » Outros Relatórios » Relatório de Movimentação por Período.
2 - Objetivo
Corrigir saldos negativos de relatório por conta das armazenagens.
3 - Alteração
Foi realizado alguns testes e percebido que o filtro do TIPO de ENTRADA só é utilizado na parte da query que busca os valores de beneficiamento do algodão, e removendo o mesmo não fez diferença, já que nesse caso a Pluma faz uma referencia obrigatória com a Produção, onde a mesma sempre é do Tipo “Venda“. Nesse caso então foi apenas removido essa filtragem.
PSGA » Cotton » Relatórios » Outros Relatórios » Relatório de Movimentação por Período.
2 - Objetivo
Inserir percentual do total dos beneficiamento no relatório de movimentação por período.
3 - Alteração
Criado o Campo PERC_QUEBRA_TOT na tabela TWMOVPER;
Adicionado um UPDATE ao fim da QUERY INSERE_RESUMO_MOVIMENTO_PERIODO que atualiza os valores do Percentual de Quebra Total dos Resumos dos Subprodutos.
PSGA » Cotton » Relatórios » Outros Relatórios » Relatório de Movimentação por Período.
2 - Objetivo
Corrigir Relatório de Movimentação por Período
3 - Alteração
Foi adicionado na parte inicial da query uma adição de '23:59:59' na Data Final obtido na Entrada do relatório. Nessa situação a Data Inicial por padrão sempre iniciaria as 00:00:00 e a data Final finalizaria as 23:59:59.
PSGA » Cotton » Pluma » Relatórios » Pluma » Lote bloco » Relatório de Lotes Resumido por Tipo
PSGA » Cotton » Pluma » Relatórios » Pluma » Lote bloco » Relatório de Lotes Resumido por data
2 - Objetivo
Corrigir os filtros de lote resumido para imprimir por tipo e status
3 - Alteração
Devido as diversas divergências de resultados do relatório de lote por data em relação com o estoque do usuário foi feito uma analise e desenvolvimento do mesmo diretamente na base do cliente para verificar pontualmente o que estava acontecendo:
Foi encontrado alguns problemas em registros antigos que não foram atualizados devidos as diversas atualizações que foram feitas recentemente. Alguns emblocamentos sem Data, alguns registros no estoque com a data padrão, impedindo o reprocessamento de recalcular os mesmo. Plumas de entrada que estavam sem data também. Além de outros problemas individuais espalhados.
Foram corrigidos todos aqueles que causavam problema nos cálculos do relatório.
Foi percebido que a filtragem por período não estava funcionando corretamente. Como essa rotina depende mais do tempo do que qualquer outra informação, fazer as ligações necessárias para mostrar a informação completa se tornou complexa e custosa em nível de performance;
Para essa situação foi criado uma View para criar toda movimentação de estoque da pluma nas rotinas de emblocamento e seguintes (Lote, Takeup e Saída). Subdivido já esses registros dessa view em prioridades sendo:
o registro direto da Tpluma no estoque no nível 1, onde quer dizer que é o primeiro momento do beneficiamento.
O 2 para a saída ainda em beneficiamento.
O 3 é para a reentrada, utilizando a TCPLUMAI para buscar no estoque.
O 4 é para a saída na reentrada.
Como o take-up não gera estoque, é adicionado ao final utilizando a relação desses registros com a Data do mesmo.
Foi realizado varias possibilidades de query a fim de reduzir o tempo de execução para ser o máximo semelhante a como já estava funcionando. Onde dependendo do registro pode ser igual ou no máximo 1 a 2 segundos a mais. Porém em compensação o tempo de execução sem nenhuma filtragem, onde é realizado a amostragem de todos os resultados reduziu de 1 minuto para 25 segundos.
Foi removido a filtragem do Tipo de entrada que era feito diretamente no relatório e foi colocado para filtrar pela tabela de trabalho TWROMBLO, utilizando o novo campo adicionado TP_ENTRADA.
O valor desse campo é adicionado na query que preenche as informações da TWROMBLO.
A relação do tipo de entrada ficou da seguinte maneira:
Se a Prioridade (valor tirado da VIEW criada) for igual a 1 então esse registro pode ser tanto para Beneficiamento ou para Venda, já que nesse caso é o primeiro passo do emblocamento.
Se a prioridade for 3 ou 4, quer dizer que ja esta em reentrada, e ne nesse caso só sobra a armazenagem.
Se a prioridade for 2, quer dizer que se trata de uma saida, então é verificado o TIPO_MOVIM da mesma, se for igual a 1 se trata de uma Venda, e se for igual a 4 se trata de um beneficio que vai para armazenagem.
PSGA » Cotton » Pluma » Relatórios » Relatório de Lotes Resumido por Tipo.
2 - Objetivo
As plumas com reentrada para armazenagens não estão constando no relatório de Lote Resumido por Tipo.
3 - Alteração
Foi alterado a View VW_PLUMA_STATUS_DISP_TKP_EMB, não sendo necessário trabalhar diretamente os o STATUS_MOVIMENTACAO. No caso foi apenas adicionado uma relação não obrigatória com a TPLUMA e para cada relacionamento com as tabelas que determinam o estado da movimentação do bloco (TROMBLOH, TTAKEUPH, TVENPLUH) foi realizado uma condição que verifica se o Proprietário atual da Pluma é igual ao produtor da determinada tabela, no caso positivo é utilizado a condição de igualdade com o código Único da tabela em verificação com o código da mesma tabela que é gravada na própria TPLUMA. Por exemplo, caso for uma nova reentrada para o mesmo produtor, as informações do campo TPLUMA.TVENPLUH_COD e TPLUMA.TROMTAK_COD serão apagadas, e no caso o resultado na VIEW não encontrará nenhum take-up ou venda, fazendo com que os registros sejam categorizados como disponível. No caso contrário da reentrada ser para outro produtor, o método da VIEW se mantém não fazendo essa verificação, pois nesse caso os códigos de TVENPLUH_COD e TROMTAK_COD da tpluma podem ser diferentes da Origem não podendo realizar essa condição.
PSGA » Cotton » Movimentação » Relatórios » Outros Relatórios » Relatório de Movimentação por Período.
2 - Objetivo
Corrigir saldo do relatório de acordo com a data informada para saídas,
3 - Alteração
Foi ajustado a query INSERE_RESUMO_MOVIMENTO_PERIODO para verificar se houve entrada e saída de beneficiamento pelo Inventário, nos casos de subprodutos
Foi adicionado uma tabela temporária para guardar o valor do calculo da quebra residual para fazer a soma em um update na tabela de trabalho com os valores conseguidos dos subprodutos, para evitar que o subproduto de uma safra anterior que não era quebra residual, porém que nessa safra é, não interfira no calculo do mesmo.
Foi alterado o relatório de Resumo de movimento por período em conformidade com a customização do Cliente para poder remover essa customização.
PSGA » Cotton » Movimentação » Relatórios » Outros Relatórios » Relatório de Movimentação por Período
2 - Objetivo
Criar filtro no relatório de movimentação por período
3 - Alteração
Em conversa com a Analista Keyla foi verificado uma melhor opção de Filtragem:
Como o relatório imprime 5 relatórios distintos e independentes, onde cada um representa um produto derivado da Pluma, a opção foi criar 5 checkBox referente a cada um dos cinco relatórios.
Foi adicionado um CheckBox geral que seleciona todos os relatórios, e outros 5 para selecionar cada um independente. Podendo assim escolher quais dos 5 quer imprimir.
Essa ideia foi apresentado devido o problema da Quebra Residual, onde um dos subprodutos da Pluma sempre terá uma variação em seu peso baseado no Peso de Origem do Algodão em Caroço menos o que foi gerado da Pluma menos os dois subprodutos que possuem quebra Fixa. Sendo assim é essencial que seja gerado os resultados de todos os subprodutos e uma filtragem direta na query poderia afetar os resultados.
Além do mais fica mais simples selecionar os relatórios que quer verificar já que esse sempre foi o objetivo de filtrar o produto.
ATUALIZAÇÃO: Ajustado na query que gera os registros na tabela de trabalho para considerarem primeiro os parâmetros personalizados dos subprodutos padrão, e só se não haver nenhum registro considerar o parâmetro geral.
ATUALIZAÇÃO 2: Adicionado a filtragem da RV de centro de custo e Safra para filtrar a tabela TQBRPROD dentro da query INSERE_RESUMO_MOVIMENTO_PERIODO. Isso para não selecionar subprodutos de outras safras ou centros de custo na formação da quebra residual.
PSGA » Cotton » Relatórios » Outros Relatórios » Relatório de Movimentação por Período
PSGA » Cotton » Relatórios » Pluma » Lotes Bloco (Relatório de Lotes Resumido por Data)
2 - Objetivo
Criar campo de data de origem devido os históricos das plumas e lotes devido reentradas
3 - Alteração
Foi gerado os campos DATA_ORIGEM nas tabelas TPLUMA e TROMBLOH
Alteração dos Relatórios TRelEntProdDia, TRelFardosPorTipo e TRelRomEmbloResumidoData e querys relacionadas para respeitar a DATA de origem
Alterado para o relatório de Emblocamento resumido por Data verificar tanto o Beneficiamento quanto a Reentrada.
Adicionando o Update do campo DATA_ORIGEM na query depois apenas nas versoes Trunk e 18.
Adicionando a alimentação do campo DATA_ORIGEM na geração de registro pelo DD e pelas rotinas que geram Pluma e Emblocamento.
Adição da alimentação do campo DATA_ORIGEM na integração com o CGA no PDXDts do cliente.
As partes relacionadas a query e relatórios já foi implementada no cliente para teste, durante os testes foram encontrados divergências nos valores com um relatório de Referência que o cliente possuía.
Dentre as divergências foi encontrado duas situações corrigidas:
A primeira era relacionado a campos da DATA_ORIGEM que vieram com valores de Horas, o que acabou se perdendo nas igualdades das querys. Foi corrigido na base do cliente e na nossa Base.
A segunda era relacionada ao UPDATE do campo DATA_ORIGEM da TPLUMA. Para recuperar a origem foi utilizado uma relação com a produção, a entrada e a classificação visual, sabendo que no cliente em questão a integração das Plumas ocorre ao mesmo tempo da integração da classificação visual. Porém dependendo da data da pluma, a rotina da classificação não ocorria ao mesmo tempo, e acabaram recebendo a data direto da Produção o que acabou não ficando exato. Para essas plumas foi realizado um update buscando a data direto pelo LOG de criação da mesma.
Além das duas situações anteriores corrigidas, havia + alguns divergências com o relatório (Mural) de referência, que não estão erradas. Mas sim o próprio relatório de Referência que não tinha todas as informações na época:
A primeira divergência é relacionada a 1 (uma) carga de entrada a mais no mês de setembro. Porém no Mural era informado que para esse mês havia 1454 cargas de entrada, porém na base existe 1455 registros, então o relatório atual mostra as cargas reais de fato.
A segunda divergência é relacionada a 20 cargas de entrada a mais que estavam em produção no mês de Agosto e Setembro. Da mesma maneira da analise anterior, a quantidade de registros de cargas produzidas não só nesse Mês, mas no total possui essas 20 cargas. Na época da geração do Mural havia um problema relacionado as cargas em produção que não recebiam a Data de Beneficiamento, sendo que não só esse mas outros relatórios verificam se a carga está em produção ou não por essa data.
A terceira divergência é relacionado a falta de 123 fardos, porem em analise no banco de dados é verificado que existem no total 208934 plumas geradas na safra 23. Se realizarmos a somatória dos resultados do mural esse valor excede, chegando em 209057. Essa diferença ocorre no mês de agosto e provavelmente pode ser algo relacionado a safra, como o relatório foi criado nesse mesmo mês, poderia existir alguns problemas de agrupamento por safra.
A ultima divergência é relacionado ao peso dos fardos que é ligada diretamente a divergência anterior, já que com a quantidade de plumas alteradas o peso total também será alterado.
Por fim tanto o relatório de Pluma diário (Atual) e o relatório de Resumo de movimento por período apresentam valores iguais.
A análise das divergências pode ser verificada pela query:
Introdução da verificação de detalhes da cidade e obtenção de informações como o código IBGE, UF e descrição da cidade.
A lógica de verificação foi ampliada para verificar não apenas o endereço da transportadora, mas também se a cidade associada possui um código IBGE válido.
Em caso de ausência do código IBGE para a cidade, uma mensagem detalhada é exibida, mencionando explicitamente a cidade que está faltando o código.
Corrigir a funcionalidade de TAB para campos e variedades na tela.
3 - Alteração
Adicionado centro de custo e safra no buffer da TLOTESH nas rotinas de Produção da Pluma e Cadastro de Lotes ao procurar registro. Permitindo informar manualmente o código do lote;
Adicionado também centro de custo e safra no buffer da TROMENT na rotina de Produção da Pluma, permitindo informar manualmente o código da pluma para posicionar um registro já cadastrado.
PSGA » Cotton » Movimentação » saída de subprodutos
2 - Objetivo
Ajustes na captura de informação dos campos no PSGA e envio para o Agrotitan
3 - Alteração
Seguindo as especificações fornecidas, efetuamos ajustes e aprimoramentos nos campos de PRESTADOR, CIDADE, UF e ESPÉCIE. Essas mudanças asseguram o correto funcionamento da rotina relacionada às notas de saída para retorno de subprodutos e pluma.
4 - Configuração
Configurar o parâmetro P_ROMANEIO_SAIDA_BENEFIC_INTEGRA_NF_AGRO como 'S'
PSGA » Cotton » Movimentação » Relatórios » Relatórios Pluma » Lotes Bloco (Relatório de Fardos por bloco)
2 - Objetivo
Ajustar para reentrada de armazenagem - Relatório de Fardos por Bloco.
3 - Alteração
Foi alterado a query VW_PLUMA_STATUS_DISP_TKP_EMB para respeitar o novo campo STATUS_MOVIMENTACAO das tabelas TTAKEUPI, TVENPLUI e TVENPTK;
Foi corrigido também a query INSERE_PLUMA_STATUS_TWROMBLO que é utilizada para alimentar algumas tabelas da RV de Lotes para também respeitar o novo campo STATUS_MOVIMENTACAO;
Foi corrigido um relatório personalizado da COOPERBEM “TRelRomEmbloResumidoLocal“ para utilizar a View VW_PLUMA_STATUS_DISP_TKP_EMB, respeitando assim já o novo campo.
Ajustar para reentrada de armazenagem - Processo de Armazenagem do Terceiro
3 - Alteração
“Atenção“: Foi replicado nas tela TVWTCPLUMAH o que ja havia na v17Cooperbem paras as vTrunk v18, junto com a TDGIMPORTAPLUMA que é uma dependencia da tela.
Nessa tarefa foi feito o preenchimento do campo STATUS_MOVIMENTACAO no processo de Entrada de Pluma. Assim como as tabelas que serão utilizadas nos processos após a entrada. Seguindo o que foi solicitado na tarefa.
Foi criada Triggers para o preenchimento do campo STATUS_MOVIMENTACAO ao criar novos registros nas tabelas TROMBLOI e TTAKEUPI.
Também foi criada uma trigger na TPLUMA para garantir que sempre que for inserida uma nova pluma e o campo PROPRIETARIO estiver vazio, o mesmo seja preenchido com o produtor da pluma.
PSGA » Cotton » Movimentação » saída de subprodutos
2 - Objetivo
Implementar dados da transportadora para as notas de saída de retorno de subprodutos e pluma (JSON)
3 - Alteração
Incorporada a propriedade "Transportador" no corpo JSON da requisição "ConfirmarNotaSaidaSefazWMS" direcionada à API agroWMS. Essa implementação foi realizada nas seguintes rotinas:
Cotton » Movimentação » Pluma » Venda/Saída
Cotton » Movimentação » Saída de Subprodutos.
4 - Configuração
Configurar o parâmetro P_ROMANEIO_SAIDA_BENEFIC_INTEGRA_NF_AGRO como 'S'
Foi gerado a query CALCULA_RENDIMENTOS_THPLUMA para alimentar os campos de CAROCO_KGS, CAROCO_PERC, FIBRILHA_KGS, FIBRILHA_PERC, OUTROS_KGS e OUTROS_PERC (Sendo o campos OUTROS referente aos resíduos)
Após a finalização foi verificado que a soma dos valores juntamente com o valor da Pluma não batia com os totais da Entrada. Sendo assim foi verificado que havia um erro na query REPROCESSA_ESTOQUE_TROMENQB que faz a atualização dos valores de Peso e Percentual do subproduto que faz a quebra residual. Foi corrigido acertando assim o valor do subproduto que faz a variação devido a quebra residual.
Após acertar isso foi verificado que todas as Produções de Plumas que haviam vinculo com um lote em comum (Ou seja, um lote com vinculo com mais de uma produção) estavam com os percentuais individuais muito abaixo, não fechando o calculo com os valores de caroço, fibrilha e resíduo. Foi verificado então que o percentual da pluma estava referenciado ao Total da Pluma da Entrada, e não ao Total referente a produção, isso ocorria na Integração CGA-PSGA, foi corrigido na query de integração.
A rotina foi aplicada no Reprocessamento de Rendimentos da tela de Produção de Pluma e na tela de Rendimentos. Além de estar na rotina de fechamento da tela de Produção de Pluma.
4 - Configuração
P_TMOVPCAR_SPRODUTO: Produto que será o Caroço Padrão.
P_PRODUTO_PADRAO_FIBRILHA: Produto que será a Fibrilha Padrão.
P_PRODUTO_PADRAO_RESIDUO”: Produto que será o Resíduo Padrão.
P_UTILIZA_QUEBRA_RESIDUAL: “S” para informar que irá realizar a quebra residual.
Implementar a Geração e Envio automático das Planilhas de Classificação
3 - Alteração
Foi gerado o projeto PSERV_EXPORTCLASS.src
Foi adicionado o projeto nos arquivos de compilação do PSGA
Foi criado os parâmetros:
P_EXPORTCLASS_PADRAO_LAYOUT
P_EXPORTCLASS_ARQUIVO_LAYOUT
P_EXPORTCLASS_DESTINO_PADRAO
Foi gerado as querys:
RETORNA_RECNUM_EXPORTCLASS
INFO_CORPO_EMAIL_EXPORTCLASS
Foi gerado os Multilinguais:
SCONFAPP.ROTINA
Index: 10, Label: Exportação de Classif. Visual, Item_Save: 10
MSG.EXPORTCLASS_CORPO_EMAIL
Foi criado o Campo:
Na tabela TPLACLA o campo ENVIADO -> ASCII, 1
Foi alterado o campo:
Na tabela SCONFAPP o campo Rotina de ASCII(1) par ASCII(2)
A query RETORNA_RECNUM_EXPORTCLASS tem a funcionalidade de retornar os Recnuns das classificações que estão com o STATUS_CGA fechado, porém ainda estão abertos no PSGA, além de precisar estar com o ENVIADO diferente de '1' que no caso é Não enviado.
A query INFO_CORPO_EMAIL_EXPORTCLASS serve para buscar pelas as informações para serem adicionada no corpo do e-mail para cada classificação enviada. É trabalhada em conjunta com o ML: MSG.EXPORTCLASS_CORPO_EMAIL, onde cada '#' no ML representa a um valor recebido pela query, em ordem.
Integração PSGA X AGROTITAN desenvolver a query do json para enviar os dados para geração de nota no agro
3 - Alteração
Para possibilitar que o cliente efetue a cobrança de beneficiamento do PSGA e salve a nota no agro, optamos por utilizar uma API REST já existente no Agrotitan, por meio da rota "/viasoftserver/rest/TDmAPI/ConfirmarNotaEntradaWMS". Para as requisições feitas ao sistema Agro, utilizamos o seguinte modelo de body JSON contendo as seguintes informações:
Esse modelo de body JSON contém as informações necessárias para a requisição ao sistema Agro. Cada campo é preenchido com os respectivos valores relevantes para o processo em questão, como o número da nota, o CPF/CNPJ, os valores dos produtos, dados relacionados a logística, entre outros. O modelo de body JSON fornecido é adaptado conforme as especificações e requisitos da integração com o sistema Agro, garantindo a consistência e a correta transmissão das informações necessárias para a interação entre os sistemas envolvidos. Parâmetros relacionados à Integração com o Agrotitan:
P_AGROWMS_API_URL: Descrição: URL da API do Agrotitan. Tipo: String Exemplo: "http://27.0.0.1"
P_AGROWMS_API_PORT: Descrição: Porta utilizada para a conexão com a API do Agrotitan. Tipo: String Exemplo: "9090"
P_AGROWMS_API_AUTH: Descrição: Credenciais de autorização para acessar a API do Agrotitan. Tipo: String Exemplo: "usuario-api:senha-api"
Observações:
Esses parâmetros são utilizados no contexto da integração entre o PSGA e o Agrotitan.
Certifique-se de fornecer os valores corretos para esses parâmetros, conforme as configurações da sua aplicação e ambiente.
As descrições fornecidas são genéricas e devem ser adaptadas de acordo com a implementação específica do sistema.
4 - Configuração
P_AGROWMS_API_URL: Descrição: URL da API do Agrotitan. Tipo: String Exemplo: "http://27.0.0.1"
P_AGROWMS_API_PORT: Descrição: Porta utilizada para a conexão com a API do Agrotitan. Tipo: String Exemplo: "9090"
P_AGROWMS_API_AUTH: Descrição: Credenciais de autorização para acessar a API do Agrotitan. Tipo: String Exemplo: "usuario-api:senha-api"
Integração PSGA X AGROTITAN para notas de saída de cobrança (criar tela)
3 - Alteração
Para atender à demanda de cobrança de beneficiamento no Agrotitan através do PSGA, utilizando a integração via feita na https://nimitz.atlassian.net/browse/AG-19069 , foi desenvolvida uma tela com os campos essenciais para suportar esse processo de integração. Além disso, foi implementada a funcionalidade de importação de beneficiamentos para facilitar o preenchimento dos campos, agilizando o fluxo de trabalho e garantindo a precisão dos dados importados.
Utilizar Qtde de Rolos para Alimentar o Múltiplo de desconto de embalagem a na Tabela
3 - Alteração
Tratado para dar desconto múltiplo de acordo com a quantidade de rolos informados no campo QTDE_ROLOS caso parâmetro P_ROLO_APENAS_INFORMATIVO esteja ativo
Exemplo: Supondo que na Tabela utilizada a embalagem/Lona seja de 4KG teremos para 10 Rolinhos = 10x4Kg
Implementar Preenchimento automático do Depósito, Fazenda e Variedade no Romaneio de entrada de Algodão
3 - Alteração
Tratado exiting do campo oSfpespro_Pes_codigo_Busca para caso parametro P_ROLO_APENAS_INFORMATIVO='S' verificar se ha apenas um almoxarifado para o produtor escolhido e preencher caso sim
Tratado exiting do campo oSfpespro_Pes_codigo para verificar se ha apenas uma fazenda para o produtor escolhido e preencher caso sim
Tratado exiting do campo oSicampos_Cod_campopara verificar se ha apenas uma variedade (consultar SICAMPOS) para o campo escolhido e preencher caso sim
Adicionada verificação caso os campos já estejam preenchidos manualmente
Integração PSGA X AGROTITAN para notas de entrada de algodão (verificar monitor de notas)
3 - Alteração
Não teve replicação
Foi colocado a API do Monitor de NFe do PSGA no Servidor do cliente, e configurado para apenas baixar os XMLs em uma pasta, e pra ficar sempre aberto no servidor.
Integração PSGA X AGROTITAN para notas de entrada de algodão (ajuste na tela).
3 - Alteração
Para atender à demanda de entrada de notas no Agrotitan através do PSGA, utilizando a integração via fita "https://nimitz.atlassian.net/browse/AG-18696 ", foi desenvolvida uma tela com os campos essenciais para suportar esse processo de integração. Além disso, foi implementada a funcionalidade de importação de arquivos XML para facilitar o preenchimento dos campos, agilizando o fluxo de trabalho e garantindo a precisão dos dados importados.
Integração PSGA X AGROTITAN para notas de entrada de algodão (processo)
3 - Alteração
Para possibilitar que o cliente efetue a entrada no Romaneio de entrada de algodão do PSGA e salve a nota no agro, optamos por utilizar uma API REST já existente no Agrotitan, por meio da rota "/viasoftserver/rest/TDmAPI/ConfirmarNotaEntradaWMS". Para atender a essa necessidade de envio de requisições HTTP para APIs REST, desenvolvemos a função "EnviarRequisicaoHttp". Essa função foi criada com o objetivo de simplificar e tornar mais eficiente o processo de integração com a API do Agrotitan, reduzindo o esforço necessário para realizar essas operações. Função EnviarRequisicaoHttp(String sApiUrl, String sPort, String sMethod, String sRoute, String sJson, String sAuthorization) Retorna HttpResponse Descrição: Esta função é responsável por enviar requisições HTTP para uma API REST. Parâmetros: sApiUrl: URL da API onde a requisição será enviada. sPort: Porta utilizada para a conexão com a API. sMethod: Método HTTP utilizado na requisição (por exemplo, GET, POST, PUT, DELETE). sRoute: Rota da API para a qual a requisição será enviada. sJson: Corpo da requisição no formato JSON. sAuthorization: Credenciais ou token de autorização necessários para acessar a API. Retorno: HttpResponse: Objeto contendo a resposta da API após o envio da requisição. Exemplo de Uso: HttpResponse response = EnviarRequisicaoHttp("http://exemplo.com ", "8080", "GET", "/usuarios", "", "Bearer token123"); Observações: Certifique-se de fornecer os parâmetros corretos para a função de acordo com as especificações da API em questão. A função deve ser adaptada para a linguagem de programação utilizada, respeitando a sintaxe e estrutura da mesma. É recomendado realizar tratamento de erros e exceções ao utilizar essa função para garantir a robustez do código. Para as requisições feitas ao sistema Agro, utilizamos o seguinte modelo de body JSON contendo as seguintes informações: { "Estabelecimento": 0, "NumeroNota": "", "SerieNota": "", "Pessoa": "", "CnpjCpf": "***", "InscEstadual": "", "Email": "@.", "Operacao": "00", "CepEndereco": "", "DataEmissao": "03/10/2022", "HoraEmissao": "10:33:00", "DataEntSai": "03/10/2022", "HoraEntSai": "10:33:00", "ValorProdutos": 143000, "ValorFrete": 0, "TipoFrete": "P", "ValorSeguro": 0, "ValorOutros": 0, "ValorTotal": 143000, "StatusNFe": 100, "ChaveAcessoNFe": "", "MotivoNFe": "", "DataEnvioNFe": "03/10/2022", "DataAutorizaNFe": "03/10/2022 09:34:00", "ProtAutorizaNFe": "*****************", "ProtCancelaNFe": "**********", "JustCancelaNFe": "*********", "EnviarSefaz": "False", "LRomaneios": [ { "IdRomaneio": "1", "EstabRomaneio": 1, "PessoaRomaneio": "", "EntradaSaida": "E" } ], "LItens": [ { "Seq": 1, "CodProduto": 1, "Quantidade": 28600, "ValorUnitario": 5, "DescontoUnitario": 0, "CFOP": 5901, "LocalEstoque": 0013, "EstabOrigem": 0, "SeqNotaOrigem": 0, "SeqNotaItemOrigem": 0, "Complemento": "", "LItemLotes": [ {noformat}
] } ]
} Esse modelo de body JSON contém as informações necessárias para a requisição ao sistema Agro. Cada campo é preenchido com os respectivos valores relevantes para o processo em questão, como o número da nota, o CPF/CNPJ, os valores dos produtos, dados relacionados a logística, entre outros. O modelo de body JSON fornecido é adaptado conforme as especificações e requisitos da integração com o sistema Agro, garantindo a consistência e a correta transmissão das informações necessárias para a interação entre os sistemas envolvidos. Parâmetros relacionados à Integração com o Agrotitan: P_AGROWMS_API_URL: Descrição: URL da API do Agrotitan. Tipo: String Exemplo: "http://27.0.0.1" P_AGROWMS_API_PORT: Descrição: Porta utilizada para a conexão com a API do Agrotitan. Tipo: String Exemplo: "9090" P_AGROWMS_API_AUTH: Descrição: Credenciais de autorização para acessar a API do Agrotitan. Tipo: String Exemplo: "usuario-api:senha-api" P_ROMANEIO_ENT_ALGODAO_INTEGRA_NF_AGRO: Descrição: Indica se a integração com o Agrotitan para Notas Fiscais está habilitada no Romaneio de Entrada de Algodão. Tipo: string(S/N) Exemplo: S P_ROMANEIO_ENT_ALGODAO_DADOS_AGRO_POR_OPE: Descrição: Define se os dados do Agrotitan serão preenchidos automaticamente no Romaneio de Entrada de Algodão por operação. Tipo: string(S/N) Exemplo: N Observações: Esses parâmetros são utilizados no contexto da integração entre o PSGA e o Agrotitan. Certifique-se de fornecer os valores corretos para esses parâmetros, conforme as configurações da sua aplicação e ambiente. As descrições fornecidas são genéricas e devem ser adaptadas de acordo com a implementação específica do sistema.
Adequar a Impressão do Romaneio de entrada conforme Modelo
3 - Alteração
Feita as mudanças para o relatório personalizado e padrão de acordo com o modelo. O modelo foi utilizado como base e colocada as coisas a mais que o padrão tinha em relação ao que o cliente disponibilizou. Retirada a parte da logo da empresa;
Ajustada fórmula do sub-relatório de rolos para se adequar ao novo parâmetro do servidor;
PSGA » Cotton » Básicos » Cadastros de Subproduto de Produção
PSGA » Cotton » Movimentação » Pluma » Rendimento
PSGA » Cotton » Movimentação » Pluma » Produção de Pluma
2 - Objetivo
Melhoria Aderência Cooperbem Implementar Quebra No Mesmo Almoxarifado de Entrada
3 - Alteração
Criado um flag para a buscar do almoxarifado através da Troment , alterar o processo no momento que gerar o rendimentos e no reprocessamento de estoque
PSGA » Cotton » Básicos » Cadastro de Subprodutos de Produção
PSGA » Cotton » Movimentação » Pluma » Produção
2 - Objetivo
Melhoria Aderência Cooperbem alterar o Cálculo de Rendimento
3 - Alteração
Desativar o parâmetro P_PRODUCAO_CODIGO_RESIDUO e substituir P_PRODUCAO_CODIGO_QUEBRA_RESIDUAL para melhora o entendimento
Criado parâmetro P_UTILIZA_QUEBRA_RESIDUAL = S cliente cooperbem e N para os demais clientes. Alterar o ML do TQBRPROD.RESIDUO - "RESIDUO" para Quebra Residual
Criado Validação no Campo quebra residual, só pode marcar um única vez de acordo safra e centro de custos
Criado Validação do P_PRODUCAO_CODIGO_QUEBRA_RESIDUAL se o tiver marcado como P_UTILIZA__QUEBRA_RESIDUAL = S na tela de Produção de pluma e rendimento
Criado calculo quando no subproduto da quebra estiver marcado Campo quebra residual, e o mesmo calculo deve refletir na query que recalcula os rendimentos
4 - Configuração
Parâmetros presentes na ag: P_PRODUCAO_CODIGO_QUEBRA_RESIDUAL, P_PRODUCAO_CODIGO_RESIDUO, P_UTILIZA__QUEBRA_RESIDUAL
Corrigir tela do CGA Lançamentos de Fardos Manual salvando errado não respeitando a mala.
3 - Alteração
Criado rotina de atualização do fardo inicial da mala, para quando o fardo produzido for menor que o fardo inicial da mala atual. Usuário escolhe se quer atualizar ou não;
Criado função para gerar arquivo txt de log de confirmação do usuário, bem como a pasta UserConfirmations dentro da pasta Data\LOG;
Implementado geração do log txt na confirmação da atualização do fardo inicial da mala.
Ajustar a leitura do CGA quando for do tipo manual/Leitor.
3 - Alteração
Implementado:
Novo RadioButton ‘Leitor’ para o modo de leitura da etiqueta;
Em modo de leitura ‘Leitor’, agora o foco volta para o campo de etiqueta e limpar o mesmo, após registrar um fardo.
Alterado para bloquear o cadastro de fardo já existente, nem mesmo permitindo alterar o peso pela tela de produção. A validação passa a ser na leitura da etiqueta;
Mudança de foco conforme regra de negócio, para que a navegação dos campos Etiqueta, Pesagem, radio buttons do modo de pesagem e leitura de etiqueta e o botão de Registrar Produção seja executada conforme o especificado na Análise.
Foi colocado a verificação da Ultima Classificação do beneficiamento apenas no caso necessário do uso do mesmo. Que é na geração de itens da classificação durante a produção.
Integração PSGA X AGROTITAN desenvolver a query do json para enviar os dados para geração de notas de retorno no agro.
3 - Alteração
Para possibilitar que o cliente efetue devoluções no PSGA e salve a nota no agro, optamos por utilizar uma API REST já existente no Agrotitan, por meio da rota "/viasoftserver/rest/TDmAPI/ConfirmarNotaEntradaWMS". Para as requisições feitas ao sistema Agro, utilizamos o seguinte modelo de body JSON contendo informações citadas no campo “Descrição da Implementação”.
PSGA => Cotton » Movimentação » Saída de Subprodutos
Agrotitan » Agro3c » Notas » Manutenção
2 - Objetivo
Integração PSGA X AGROTITAN para notas de saída de retorno (ajuste nas telas).
3 - Alteração
Implementação de tudo o que está nas informações técnicas. Além disso, foi criado um campo VALOR_NOTA_AGRO na tabela APROMSAI para ter o valor de produto e o valor total para a TAGROSAI.
Corrigir a definição do calculo do Peso Liquido Saída.
3 - Alteração
Cadastrado novo parâmetro P_UTILIZA_PESO_TOTAL_SAIDA_PLUMA para substituir o parâmetro P_INTEGRA_COTTON_AGROTITAN no calculo do peso liquido total da venda da pluma, uma vez que há clientes diferentes usando a integração PSGA x AGRO e usando os campos de peso total da venda, para cálculo do peso líquido da venda de pluma divergentes.
4 - Configuração
Parâmetro P_UTILIZA_PESO_TOTAL_SAIDA_PLUMA configurado de acordo com o teste a ser feito.
Cotton » Movimentação » Pluma » Entrada de armazenagem
Cotton » Movimentação » Pluma » Lote de emblocamento
Cotton » Movimentação » Puma » take-up
2 - Objetivo
Ajustar para reentrada de armazenagem - Processo Beneficiado.
3 - Alteração
Criado os Campos: TPLUMA.STATUS_MOVIMENTACAO TVENPLUI.STATUS_MOVIMENTACAO TVENPTK.STATUS_MOVIMENTACAO TCPLUMAI.STATUS_MOVIMENTACAO TROMBLOI.STATUS_MOVIMENTACAO TTAKEUPI.STATUS_MOVIMENTACAO Ajustado para gravar status conforme o solicitado na especificação TPLUMA.STATUS_MOVIMENTACAO = 'beneficiado' ao Fechar Produção pluma TROMBLOI.STATUS_MOVIMENTACAO = 'beneficiado' ao emblocar pluma TVENPTK.STATUS_MOVIMENTACAO = 'beneficiado' ao inserir em takeup TVENPLUI.STATUS_MOVIMENTACAO e TPLUMA.STATUS_MOVIMENTACAO = 'Saída' ao Fechar Venda TVENPTKP.STATUS_MOVIMENTACAO e TPLUMA.STATUS_MOVIMENTACAO = 'Saída' ao Fechar Venda
Cotton » Movimentação » Pluma » Cobrança de Beneficiamento.
2 - Objetivo
Validação na tela de cobrança pra endereço informado.
3 - Alteração
Adição de Propriedades:
Na Popup TDGIMPORTBENEFAGRO, foi adicionada a propriedade psTipoEndereco para armazenar o tipo de endereço.
Atualização da Consulta SQL:
A query foi ampliada para incluir uma junção com a tabela SFAZENDA para obter o tipo de endereço.
A variável @TIPO_ENDERECO foi adicionada para filtrar os registros com base no tipo de endereço informado.
Modificação de Funções:
Na função LoadBeneficiamentos, o valor de psTipoEndereco é recuperado para a variável local sTipoEndereco.
Interface de Usuário:
No botão "Importar" da interface, foi adicionado um comando para definir o valor de psTipoEndereco baseado no que o usuário selecionou ou inseriu.
Objetivo das Modificações: As alterações garantem que, ao importar registros na tela de cobrança de beneficiamento, apenas as produções do endereço específico sejam carregadas, prevenindo registros incorretos.
Os contratos tem vários valores unitários diferentes é demorado e causar erros tendo que entrar nos contratos para ver o valor unitário e preencher manual, surgindo a necessidade de preencher esse valor de forma automática.
3 - Alteração
Adicionado para preencher automático o campo “Valor Nota Agro” com o valor unitário do contrato, quando informar o contrato nos telas de Romaneio.
Sempre que trocar o contrato irá atualizar o campo "Valor Nota Agro".
4 - Configuração
“P_ROMANEIO_SAIDA_BENEFIC_INTEGRA_NF_AGRO“ for “S“
No cadastro de operação de estoque, na aba estoque a flag “Retorno de beneficiamento“ deve está marcada.
Para realizar as gerações de notas pelo psga após cadastrar o romaneio irá agilizar o processo e evitar erros,
3 - Alteração
Remover a condiçaõ de verificar o tipo de movimento da pluma, para liberar os campos de envio de notas para todos os tipos de movimento da tela.
Cada tipo de movimento tem um parâmetro para configurar a operação conforme quadro abaixo, antes liberava apenas para o tipo 4 -Retorno de Beneficiamento.
1- VendaP_OPERACAO_PADRAO_DEVOLUCAO_PLUMA_VENDA2 - TransferênciaP_OPERACAO_PADRAO_TRANSF_PLUMA3 - Devolução de ArmazenagemP_OPERACAO_PADRAO_DEVOLUCAO_ARMAZENAGEM_PLUMA4 - Retorno de BeneficiamentoP_OPERACAO_PADRAO_RETORNO_BENEFICIAMENTO_PLUMA
4 - Configuração
“P_ROMANEIO_SAIDA_BENEFIC_INTEGRA_NF_AGRO“ for “S“
No cadastro de operação de estoque, na aba estoque a flag “Retorno de beneficiamento“ deve está marcada.
