A ideia: pegar o cadastro de parceiros (OCRD), filtrar só clientes (CardType = 'C'), juntar com as notas fiscais de saída (OINV) não canceladas e ficar com quem tem a última nota há mais de 90 dias.

SELECT T0.CardCode, T0.CardName, MAX(T1.DocDate) AS UltimaCompra
FROM OCRD T0
INNER JOIN OINV T1 ON T1.CardCode = T0.CardCode AND T1.CANCELED = 'N'
WHERE T0.CardType = 'C'
GROUP BY T0.CardCode, T0.CardName
HAVING MAX(T1.DocDate) < DATEADD(day, -90, GETDATE())
ORDER BY UltimaCompra;

Três cuidados:

1. O INNER JOIN deixa de fora quem nunca comprou. Se quiser ver também o cliente cadastrado que nunca recebeu nota, troque por LEFT JOIN e use HAVING MAX(T1.DocDate) IS NULL OR MAX(T1.DocDate) < ...
2. Devolução (ORIN) não entra aqui. Se o cliente comprou e devolveu tudo, ele ainda aparece como "comprou". Para carteira de cobrança, isso costuma ser aceitável; para comissão, não.
3. Troque o 90 por um parâmetro ([%0]) no Query Manager para o comercial escolher o período sem pedir alteração.

Rodando no Query Manager, dá para salvar como consulta e deixar no menu do usuário de vendas. Teste sempre numa base de testes antes.

Essa é uma das 20 do meu Pack 20 Queries SAP Business One: faturamento, aging de recebíveis, estoque, margem por item e outras, comentadas, em SQL Server e HANA, com PDF guia das tabelas e 3 pesquisas formatadas. É produto meu: https://pay.kiwify.com.br/hlEABhA?src=hashnode

Material independente. SAP e SAP Business One são marcas da SAP SE.

As tabelas que entram

• OINV e INV1: cabeçalho e linhas das notas fiscais de saída (A/R Invoice).
• OITM: cadastro de itens, só para trazer o nome.

A ideia: somar LineTotal por item no período, ordenar do maior para o menor, calcular o percentual acumulado e classificar em A (até 80%), B (até 95%) e C (o resto).

A query

WITH Vendas AS (
    SELECT
        L.ItemCode,
        SUM(L.LineTotal) AS Faturamento
    FROM INV1 L
    JOIN OINV H ON H.DocEntry = L.DocEntry
    WHERE H.CANCELED = 'N'
      AND H.DocDate >= '2026-01-01'
      AND H.DocDate <  '2027-01-01'
    GROUP BY L.ItemCode
),
Acumulado AS (
    SELECT
        V.ItemCode,
        V.Faturamento,
        SUM(V.Faturamento) OVER (ORDER BY V.Faturamento DESC, V.ItemCode
                                 ROWS UNBOUNDED PRECEDING) AS FatAcumulado,
        SUM(V.Faturamento) OVER () AS FatTotal
    FROM Vendas V
)
SELECT
    A.ItemCode,
    I.ItemName,
    A.Faturamento,
    CAST(100.0 * A.FatAcumulado / NULLIF(A.FatTotal, 0) AS DECIMAL(5,2)) AS [% acumulado],
    CASE
        WHEN 100.0 * A.FatAcumulado / NULLIF(A.FatTotal, 0) <= 80 THEN 'A'
        WHEN 100.0 * A.FatAcumulado / NULLIF(A.FatTotal, 0) <= 95 THEN 'B'
        ELSE 'C'
    END AS Curva
FROM Acumulado A
JOIN OITM I ON I.ItemCode = A.ItemCode
ORDER BY A.Faturamento DESC;

Pontos de atenção

• LineTotal vem na moeda local e sem impostos da linha. Se o comercial quiser o valor com impostos, troque por L.GTotal.
• Troque as datas pelo período pedido. No Query Manager, use [%0] e [%1] no lugar das datas para virar parâmetro.
• Devoluções (ORIN/RIN1) não estão descontadas. Para curva por faturamento líquido, some as devoluções no CTE Vendas com sinal negativo.
• A função de janela com ROWS UNBOUNDED PRECEDING pede SQL Server 2012 ou superior. Em HANA a sintaxe de janela é parecida; troque só o filtro de datas pelo formato do HANA.

Para levar mais pronto

Se o próximo pedido do financeiro for faturamento por cliente e mês, faturamento líquido ou contas a receber vencidas com aging, juntei 5 consultas prontas, em SQL Server e HANA, num pacote de R$ 9: Mini Pack 5 consultas SAP B1. É produto meu.

SAP e SAP Business One são marcas da SAP SE; este é um material independente.

Times de tecnologia resolvem problemas de coordenação o ano inteiro. Dá para aplicar o mesmo raciocínio aqui: definir uma fonte única da verdade, deixar as regras explícitas antes de começar e automatizar o que for repetitivo. Abaixo está o checklist que funciona bem para times remotos, híbridos ou presenciais.

1. Defina o dono e a fonte única da verdade

Antes de qualquer mensagem no canal, escolha uma pessoa responsável (ou um par, para não depender de quem pode tirar férias) e um único lugar onde a informação oficial mora.

• Lista de participantes: um só arquivo ou ferramenta, com permissão de edição restrita.
• Canal de avisos: um canal ou thread fixada só para a confra. Discussão paralela pode existir, decisão oficial fica ali.
• Datas-chave publicadas logo no primeiro aviso: prazo para confirmar presença, data do sorteio, data do evento.

Se a informação aparece em dois lugares, ela vai divergir. É o mesmo princípio de não duplicar estado entre dois serviços.

2. Monte a lista de participantes uma vez só

Puxe a lista do sistema de RH, do diretório da empresa ou do próprio workspace do Slack, em vez de digitar nome por nome. Confira três coisas:

• Quem entra: só o time, a área inteira, terceirizados, estagiários? Decida e escreva.
• Acompanhantes: a confra presencial aceita +1? Isso muda o número do buffet.
• Quem está remoto: em time híbrido, separe quem participa só do amigo secreto (com envio do presente) de quem vai ao evento presencial.

3. Confirmação de presença com prazo e sem ambiguidade

"Reage com 👍 se for" não é confirmação, é palpite. Para fechar com buffet, espaço ou delivery, você precisa de:

• uma resposta explícita (vou / não vou / talvez até tal data);
• o número de acompanhantes;
• restrições alimentares, se houver comida;
• um prazo claro, com um lembrete dois ou três dias antes.

No fim do prazo, quem não respondeu conta como "não vai" para efeito de pedido. Avise isso no primeiro aviso, e não no último.

4. O sorteio: sigilo de verdade e restrições

O papelzinho falha em time remoto por motivos óbvios, e o "alguém sorteia e manda no privado" falha porque essa pessoa fica sabendo de todos os pares. O mínimo que um sorteio decente precisa ter:

• Ninguém, nem quem organiza, vê os pares. Cada participante só descobre quem tirou.
• Ninguém tira a si mesmo. Parece óbvio, mas script improvisado às vezes esquece.
• Restrições configuráveis: casais que trabalham no mesmo time, gestor e liderado direto, ou quem pediu para não tirar determinada pessoa.
• Refazer sem drama: se alguém entra ou sai depois do sorteio, existe um jeito de sortear de novo sem expor os pares anteriores.

Se você pensou em escrever um script para isso, é um ótimo exercício de permutação sem ponto fixo (derangement). Só lembre que quem roda o script consegue ver o resultado, a não ser que o envio seja automático e o log não guarde os pares.

5. Regras de valor e de troca, escritas antes do sorteio

A maior parte das brigas do amigo secreto vem de regra combinada de boca. Escreva e fixe no canal antes de sortear:

• valor mínimo e máximo do presente;
• se vale vale-presente, presente digital ou doação;
• como funciona para quem está remoto (envio pelo correio, entrega por app, data limite de postagem);
• se haverá lista de desejos e até quando ela pode ser editada;
• o que acontece se alguém desistir depois do sorteio.

Modelo para colar no Slack ou no WhatsApp

🎁 Amigo secreto do time — regras

• Valor: entre R$ ___ e R$ ___
• Sorteio: dia __/__. Cada pessoa recebe quem tirou de forma privada.
• Lista de desejos: preencha até __/__ (ajuda muito quem tirou você).
• Quem está remoto: envie o presente até __/__ para chegar antes da troca.
• Troca: dia __/__, às __h, [local ou link da call].
• Desistência depois do sorteio: avise a organização até __/__
  para refazermos o sorteio sem expor ninguém.
• Dúvidas: só nesta thread 🙏

Troque os campos e fixe a mensagem. Parece burocrático, mas evita a conversa constrangedora de dezembro.

6. Check-in no dia do evento

Em confra presencial com muita gente, a lista impressa na entrada vira gargalo: fila, busca por sobrenome, nome escrito errado. Algumas alternativas:

• QR Code por convidado confirmado: lê na entrada e a presença fica registrada.
• Lista digital pesquisável no celular de quem recebe as pessoas, se não houver QR.
• Exportação final (CSV) com quem confirmou e quem compareceu, útil para fechar a conta com o fornecedor e para o planejamento do ano seguinte.

7. Feche o ciclo

Depois do evento, publique um resumo curto: quantas pessoas foram, o que funcionou, o que mudar. Guarde a lista e as regras num lugar fácil de achar. No ano que vem, quem organizar começa do segundo passo, e não do zero.

Resumo do checklist

• Responsável definido e um único canal oficial
• Lista de participantes importada, com critério de quem entra
• Confirmação de presença com prazo e número de acompanhantes
• Sorteio com sigilo, sem autossorteio e com restrições
• Regras de valor e de troca fixadas antes do sorteio
• Check-in no dia sem lista impressa
• Resumo e arquivamento para o próximo ano

Se não quiser montar tudo na mão

Dá para fazer todo esse fluxo com planilha, formulário e um script de sorteio, e para muitos times isso basta. Se preferir algo pronto, o TeConvidei junta confirmação de presença, sorteio do amigo secreto com sigilo entre os pares e check-in por QR Code num link só. O sorteio do amigo secreto é grátis, e a confra sai por R$ 29,90 por evento, pagamento único. Os detalhes para empresas estão em www.teconvidei.com/empresas.

As tabelas que entram

• OITM: cadastro de itens (ItemCode, ItemName, InvntItem).
• OITW: saldo por depósito (WhsCode, OnHand).
• OINV e INV1: cabeçalho e linhas das notas fiscais de saída (A/R Invoice).

A ideia: pegar todo item de estoque com saldo maior que zero e excluir os que aparecem em alguma nota de saída não cancelada nos últimos 90 dias.

A query

SELECT
    T0.ItemCode,
    T0.ItemName,
    T1.WhsCode,
    T1.OnHand,
    (SELECT MAX(H.DocDate)
       FROM INV1 L
       JOIN OINV H ON H.DocEntry = L.DocEntry
      WHERE L.ItemCode = T0.ItemCode
        AND H.CANCELED = 'N') AS [Ultima venda]
FROM OITM T0
JOIN OITW T1 ON T1.ItemCode = T0.ItemCode
WHERE T0.InvntItem = 'Y'
  AND T1.OnHand > 0
  AND NOT EXISTS (
        SELECT 1
          FROM INV1 L
          JOIN OINV H ON H.DocEntry = L.DocEntry
         WHERE L.ItemCode = T0.ItemCode
           AND H.CANCELED = 'N'
           AND H.DocDate >= DATEADD(DAY, -90, GETDATE())
  )
ORDER BY T1.OnHand DESC;

Pontos de atenção

• Troque -90 pelo período que o comercial pedir. Para virar parâmetro no Query Manager, use [%0] no lugar do número.
• A coluna "Última venda" vem nula quando o item nunca foi faturado. Esses costumam ser os primeiros candidatos à promoção (ou à baixa).
• Se a empresa usa devolução (ORIN), a query ainda conta a nota de saída original como venda, o que costuma ser o comportamento esperado.
• Em HANA, troque DATEADD(DAY, -90, GETDATE()) por ADD_DAYS(CURRENT_DATE, -90).

Para levar mais pronto

Se o próximo pedido do financeiro for faturamento, notas menos devoluções ou contas a receber vencidas, juntei 5 consultas prontas (faturamento do período, por cliente e mês, faturamento líquido, vencidas com dias de atraso e aging por faixa), em SQL Server e HANA, num pacote de R$ 9: Mini Pack 5 consultas SAP B1. É produto meu.

SAP e SAP Business One são marcas da SAP SE; este é um material independente.

P.S. Organizando a confra da firma? O sorteio de amigo secreto online é grátis: teconvidei.com/amigo-secreto

De onde vem a regra

• Ajuste SINIEF 03/2026 (CONFAZ): torna obrigatório informar o CIOT no MDF-e nas prestações de transporte rodoviário de cargas por conta de terceiros e mediante remuneração.
• NT MDF-e 2026.001: cria a validação 684 no modal rodoviário.
• Resolução ANTT nº 6.078/2026 (altera a 5.862/2019): prevê multa de R$ 10.500 por deixar de cadastrar a Operação de Transporte ou de informar/vincular o CIOT no MDF-e quando devido (art. 19).

Quem cai na validação

Pela NT, no modal rodoviário:

• tpEmit = 1 (prestador de serviço de transporte, com CT-e);
• tpEmit = 3 (CT-e globalizado);
• tpEmit = 2 com tpTransp informado.

Carga própria sem frete a terceiros, em regra, fica fora da 684, mas vale confirmar o enquadramento caso a caso.

A ordem que o sistema precisa respeitar

1. Gerar o CIOT (12 dígitos) antes de iniciar a operação.
2. Emitir o(s) CT-e (o CT-e não tem campo de CIOT).
3. Emitir o MDF-e com o grupo infCIOT (CIOT + CPF/CNPJ de quem gerou).
4. Encerrar MDF-e e CIOT depois da viagem.

Na prática, o ponto de quebra é o passo 3 acontecer antes do 1: depois de 23/11, isso vira rejeição e caminhão parado no pátio.

Armadilhas que valem uma validação no seu código

Sugestões para quem desenvolve

• Bloquear no front a emissão do MDF-e rodoviário com tpEmit 1 ou 3 (ou 2 com tpTransp) sem infCIOT preenchido, antes de ir à SEFAZ.
• Validar tamanho (12 dígitos) e dígito do CPF/CNPJ no infCIOT localmente.
• Rodar os MDF-e reais de hoje contra a homologação para ver quantos já cairiam na 684.

Regras mudam: confira sempre a NT e o MOC vigentes no portal do MDF-e (SVRS), a legislação da ANTT e o CONFAZ. Conteúdo informativo, não substitui orientação contábil ou jurídica.

Produto meu, para quem quiser a versão impressa: fiz uma cola de 1 página com esse fluxo, os campos do infCIOT e as rejeições mais comuns, por R$ 7: https://pay.kiwify.com.br/yYrsRGP?src=hashnode

— Materiais Fiscais

P.S. Fim de ano chegando: se você organiza o amigo secreto da confra da firma, dá para fazer o sorteio online e grátis aqui: sorteio de amigo secreto.