Power BI com Senior: como acompanhar requisições e pedidos de compra em um só painel

Para acompanhar requisições e pedidos de compra do Senior em um só painel, o Power BI precisa ler as tabelas de cada etapa do processo e ligar todas pelo mesmo item: da requisição ao almoxarifado, passando pela solicitação de compra, pela cotação e pela ordem de compra, até a nota fiscal de entrada. Com essa cadeia montada, o painel mostra em que etapa cada compra está e quanto tempo ela passou em cada uma. Sem ela, o que existe são relatórios soltos por tela do ERP, e a pergunta mais comum da área, "onde está a minha compra?", continua sendo respondida por telefone.

Quais tabelas do Senior entram no painel?

Os nomes abaixo são do Gestão Empresarial | ERP da Senior, o antigo Sapiens, e aparecem na documentação oficial do produto. Outros ERPs da Senior, como o Mega, têm estrutura própria, e customizações mudam o que existe em cada base. Por isso a lista é um ponto de partida para o mapeamento, e não um dicionário fechado.

1. 1.Requisição de produto (E207EME): o pedido interno de material ao almoxarifado. Quando não há saldo para atender, o atendimento da requisição pode gerar uma solicitação de compra.
2. 2.Solicitação de compra (E405SOL): a necessidade formal de compra, com produto, quantidade e comprador responsável.
3. 3.Cotação (E410COT e E410LCO): as propostas dos fornecedores e o vínculo entre a cotação e o item da ordem de compra que nasceu dela.
4. 4.Ordem de compra (E420OCP e E420IPO): o cabeçalho e os itens do pedido ao fornecedor. É aqui que passa a aprovação multinível, com as situações em análise, aprovada e cancelada.
5. 5.Nota fiscal de entrada (E440NFC e E440IPC): o recebimento. Os itens da nota trazem o número e a sequência do item da ordem de compra, o que permite comparar pedido e entrega linha a linha.

Os cadastros de fornecedores (E095FOR) e de produtos (E075PRO) completam o modelo como dimensões, junto com filial, comprador, centro de custo e calendário.

Por que a situação gravada na solicitação não basta?

O atalho mais tentador é ler a situação gravada na própria solicitação e contar quantas estão abertas. No Senior, esse atalho não funciona: segundo o suporte da Senior sobre o campo E405SOL.SitSol, essa informação não é atualizada pelas rotinas do sistema e não deve ser usada. A situação real sai do cruzamento com a cotação e com a ordem de compra. É o tipo de detalhe que só aparece quando alguém confere o painel contra a tela do ERP, e que derruba a confiança no relatório se for descoberto depois da publicação.

O mesmo vale para a aprovação. A situação da ordem mostra se ela está em análise, aprovada ou cancelada, mas não diz há quanto tempo ela espera nem em qual nível parou. Para medir o gargalo, o modelo precisa da data de cada aprovação por nível, e onde essa informação fica gravada depende da versão e da configuração da aprovação multinível de ordens de compra. Vale confirmar isso no mapeamento, antes de prometer o indicador para a diretoria.

Como ligar as etapas em um modelo só?

O desenho que funciona melhor tem uma tabela fato no nível do item, com uma linha por item de solicitação e uma coluna de data para cada marco: requisição, solicitação, cotação, emissão da ordem, aprovação e recebimento. As chaves que ligam uma etapa à seguinte são empresa, filial, número do documento e sequência do item. Os itens da nota de entrada, por exemplo, apontam para a ordem pela filial, pelo número e pela sequência do item da ordem. Nesse desenho, a etapa atual de cada item é a última data preenchida, e o tempo de cada etapa é a diferença entre duas datas.

Três cuidados evitam números errados nesse encadeamento:

• Relações de um para muitos: uma solicitação pode ser atendida por mais de uma ordem, e uma ordem pode ter várias notas de entrada quando a entrega é parcial. Somar quantidades sem tratar isso duplica valores.
• Filial em todas as chaves: números de documento se repetem entre filiais. Uma ligação feita só pelo número mistura pedidos de unidades diferentes.
• Compras sem origem: ordens emitidas direto, sem solicitação ou cotação, precisam aparecer no painel como uma categoria própria. Se sumirem do modelo, o tempo de ciclo parece melhor do que é.

Com a fato montada, a medida de tempo entre a solicitação e a ordem de compra considera só os itens que já viraram ordem:

Dias Solicitação até OC =
AVERAGEX (
    FILTER (
        fItensCompra,
        NOT ISBLANK ( fItensCompra[DataOC] )
    ),
    DATEDIFF ( fItensCompra[DataSolicitacao], fItensCompra[DataOC], DAY )
)

Os nomes de tabela e coluna são do modelo do Power BI, não do Senior. A mediana (MEDIANX, com o mesmo filtro) costuma ser mais útil que a média, porque meia dúzia de itens parados há meses puxa a média para cima.

O que o painel revela em um exemplo?

Para dar escala, considere uma indústria imaginária, sem ligação com nenhum projeto da Insight Pro, que registrou 300 itens de solicitação de compra em agosto. No fim do mês, 210 já tinham virado ordem de compra, 40 esperavam cotação, 30 estavam em cotação e 20 foram cancelados. A mediana de tempo foi de 4 dias até a cotação, mais 6 até a emissão da ordem, mais 5 na aprovação e mais 12 até a nota de entrada: 27 dias do pedido interno à chegada do material.

A leitura por etapa muda a conversa. Dos 27 dias, 15 acontecem dentro de casa, antes de o fornecedor receber o pedido. Ao abrir a aprovação por valor, o painel mostra que as ordens acima de R$ 50 mil esperam em média 9 dias, contra 2 dias das demais, porque todas passam pelo mesmo diretor. Cobrar prazo do fornecedor não resolveria esse atraso; revisar a alçada de aprovação, sim.

Como conectar o Power BI ao Senior?

• Leitura direta do banco: consulta às tabelas do ERP com um usuário somente leitura, usando o gateway de dados local do Power BI para a atualização agendada quando o banco fica na rede da empresa. É o caminho mais comum em projetos de médio porte.
• Réplica ou camada intermediária: as tabelas de compras são copiadas para um banco ou data warehouse próprio antes de chegar ao Power BI. Faz sentido quando a TI não quer consultas na base de produção ou quando o painel cruza o Senior com outras fontes.
• Integrações do próprio fornecedor: quando o ERP roda em nuvem gerenciada e o acesso ao banco não é liberado, a extração passa pelos serviços de integração que a Senior disponibiliza, com o escopo combinado com ela.

A Senior também oferece BI na plataforma Senior X, com data marts prontos para algumas áreas, como o de recebimento. O Power BI faz mais sentido quando a empresa já padronizou a ferramenta ou precisa cruzar compras com dados que não estão no ERP, como planilhas de cotação e sistemas de transporte. O raciocínio de acesso e de chaves é o mesmo que descrevemos para o Power BI com TOTVS Protheus, com outra nomenclatura de tabelas.

Se hoje a pergunta sobre o status de uma compra passa por três pessoas e duas telas do Senior, o ponto de partida é saber se os dados do seu ambiente permitem montar essa linha do tempo item a item. É o que verificamos no diagnóstico gratuito de integração da Insight Pro, dentro do serviço de Engenharia de Dados: conferimos o acesso ao banco, as tabelas e as datas disponíveis na sua versão do Senior, apontamos onde o encadeamento quebra e devolvemos um escopo para o painel de requisições e pedidos, com prazo e investimento, antes de qualquer contratação.