Ընկերությունը կոսմետիկայի ներմուծող և մեծածախ բաշխիչ է։ Վաճառքի ալիքները՝ սրահներ, բաշխիչներ, մանրածախ, marketplace-ներ (Shopify, Amazon, Etsy, Walmart), կոնսիգնացիա։ Պորտֆելը՝ ~700 ակտիվ SKU՝ երեք պահեստով և մի քանի հաշվով։ Խնդիրը «մնացորդ կա՞, թե՞ ոչ» չէր, այլ՝ ինչպես հաշվել պաշարը մեծածախի համար՝

• Պակասուրդի բացեր։ Մինչ թիմը նկատում էր, որ ապրանքը բացակայում է, վաճառքն արդեն կորած էր։ Շտապ պատվերով վերականգնումը նշանակում էր մի քանի հավելյալ շաբաթ՝ անդրսահմանյան լոգիստիկայի պատճառով։
• Կոշտ հաշվետվություն։ ERP-հաշվետվությունը կառուցվում է մեկ անգամ՝ ընդմիշտ։ Ղեկավարության նոր հարց՝ ձևը վերամշակելը դանդաղ է և թանկ։
• «Պակասը» զրոյի մասին չէ։ Մեծածախի համար ապրանքը «վերջացած» է, երբ ընկնում է հարմարավետ շեմից ցածր (օր.՝ նվազ. առաքումից ցածր)։ Տարբեր SKU-ների համար՝ տարբեր շեմ։
• Ոչ ամեն համալրում է նոր ժամանակահատված սկսում։ Եթե գործընկերը վերադարձրեց ապրանք՝ դա հաշվապահական իրադարձություն է, ոչ թե վաճառքի վերսկսում։ Այդ «համալրումից» օրական միջին հաշվելը փչացնում է հաշվարկը։
• ERP-ի կարգաբերում՝ դանդաղ և թանկ։ Բիզնես-տրամաբանության ամեն ճշգրտում ծրագրավորողի միջոցով՝ շաբաթներ և հաշիվ։

Ճարտարապետություն

Առանցքային որոշումը՝ ERP-ից քաշել միայն չմշակված տվյալ (մնացորդ, վաճառք, PO), իսկ ամբողջ բիզնես-տրամաբանությունը հաշվել Excel-մոդելում DAX-ով։ Սա տալիս է երկու բան՝ կանոնները կարող են փոխվել առանց ERP-ծրագրավորողին անհանգստացնելու, և հաշվետվության կարգաբերումը վերցնում է րոպեներ, ոչ թե շաբաթներ։

Պաշարի կադրային մոտեցումը

Հիմնական հասկացությունը՝ հասանելիության կադրն է։ Սա այն ժամանակահատվածն է, որի ընթացքում ապրանքն իրապես վաճառվում էր (ոչ թե նստած էր վերադարձներում կամ շեմից ցածր)։ Օրական վաճառքը հաշվվում է միայն կադրերի ներսում։

Կադրի պարամետրերը (կոնկրետ ամեն SKU-ի և պահեստի համար) ապրում են Google Sheets-ում՝

Օրական վաճառք՝ սահող պատուհաններ

Բազային չափիչը վերջին 30 օրվա վաճառքն է՝ ինքնաշխատ «աջ եզրով»՝ կա՛մ ընթացիկ օրացուցային համատեքստը, կա՛մ վաճառքի վերջին փաստացի ամսաթիվը (արդիական է, եթե ֆայլը բացվում է այլ օրը)՝

-- Units Sold (last 30 days)
VAR BaseDate =
    IF(
        ISFILTERED('Calendar'[Date]) || ISCROSSFILTERED('Calendar'),
        MAX('Calendar'[Date]),
        MAX('Sales'[Date])
    )
RETURN
    CALCULATE(
        [Units Sold],
        DATESINPERIOD('Calendar'[Date], BaseDate, -30, DAY)
    )

Զուգահեռ հաշվվում է միտում չափիչը՝ վերջին 30 օրվա հարաբերությունը 31–90 օր առաջ միջին ամսական ինտենսիվությանը։ Դա անմիջապես ցույց է տալիս՝ ապրանքն արագանո՞ւմ է, դանդաղո՞ւմ, թե՞ կայուն է։

-- Վաճառքի դինամիկա՝ (30օր) / (միջին ամիս 31-90օր պատուհանում)
IF(
    [Units Sold (last 30 days)] &&
    [Units Sold (avg month over 30-90 window)],
    [Units Sold (last 30 days)] /
    [Units Sold (avg month over 30-90 window)] - 1
)

Գնորդը տեսնում է ոչ միայն «քանի օրվա պաշար է մնացել», այլև «ուր է գնում ապրանքը»։ Դա փոխում է առաջնահերթությունները՝ արագացող ապրանք՝ փոքր բուֆերով՝ պատվիրել առաջինը, դանդաղող՝ մեծ բուֆերով՝ կարող է սպասել։

Մնացորդը «ճիշտ» ամսաթվին, ըստ ի.անձի

Նրբությունը, որ կոտրում է միամիտ չափիչները՝ օրական մնացորդը պահվում է որպես կտրվածքներ կոնկրետ ամսաթվերին, բայց ոչ ամեն SKU-ն ունի գրառում ամեն օրվա համար։ Պետք է վերջին հայտնի ամսաթիվը՝ ըստ SKU-ի, առանձին կենտրոնական պահեստի համար՝

-- Բացարձակ մնացորդ, ԿՊ (կենտրոնական պահեստ)
VAR LastDate1 =
    CALCULATE(
        MAX('Stock'[Date]),
        ALLEXCEPT('Stock', 'Stock'[Item.SKU]),
        'Stock'[Entity] = "[Կենտրոնական ՊՀ]"
    )
VAR Result =
    CALCULATE(
        SUM('Stock'[Qty]),
        'Stock'[Date] = LastDate1,
        'Stock'[Entity] = "[Կենտրոնական ՊՀ]"
    )
RETURN Result

Ընդհանուր պատկերի համար (բոլոր պահեստները)՝ այլ ձևանմուշ՝ SUMX SUMMARIZE-ի վրա՝ ըստ ի.անձի և SKU-ի, ներսում LASTDATE-ով։ Ամեն «ի.անձ × SKU» համադրություն ստանում է իր վերջին գրառումը՝

-- Ժամանակահատվածի վերջի մնացորդ (ագրեգատ՝ ըստ պահեստների)
SUMX(
    SUMMARIZE('Stock', 'Stock'[Entity], 'Stock'[Item.SKU]),
    CALCULATE(
        SUM('Stock'[Qty]),
        LASTDATE('Stock'[Date]),
        'Stock'[Qty] <> BLANK()
    )
)

Ծածկույթի օրեր և առաջարկություն

Մնացորդն ու օրական վաճառքը ձեռքին՝ հաշվում ենք պարզ, բայց տեղեկատվական ցուցանիշ՝

-- Ծածկույթի ամիսներ
DIVIDE(
    [End-of-period stock],
    [Units Sold (last 30 days)],
    "infinity"
)

Պատվերի քանակի առաջարկությունը հավաքվում է երեք բաղադրիչից՝

Եթե արդյունքը բացասական է՝ պատվեր պետք չէ։ Եթե դրական է՝ դա «չմշակված» առաջարկություն է, որը մենեջերը խաչաձև ստուգում է ABC-դասի և միտում-չափիչի հետ։

ABC-վերլուծություն՝ երկչափ

Մոդելը պահում է ABC-դասակարգման երկու տարբերակ՝ նախապես հաշվված (ETL-փուլում) և տեղադրված ABC ALL աղյուսակում՝

• ALL — դասակարգում ամբողջ պորտֆելով։ Օգտակար է ընդհանուր վարկանիշի և գնումների առաջնահերթության համար։
• InBrand — դասակարգում բրենդի ներսում։ Օգտակար է կոնկրետ բրենդ գնահատելու համար. նույնիսկ B-դասի ապրանքը կարող է «աշխատաձի» լինել նեղ գծի ներսում։

-- Ներբրենդ գնահատական (չափիչով, ոչ ուղիղ սյունակով —
-- որպեսզի արձագանքի համատեքստում դատարկ վաճառքին)
IF([Units Sold],
    SUM('ABC ALL'[Percentage InBrand])
)

Գնորդն առաջինը նայում է հատումները՝ A ALL-ով և A InBrand-ով՝ զրո մնացորդով՝ ապրանք, որտեղ կորուստն անմիջապես տեսանելի է։

Մուտքերը Google Sheets-ից

Մեկ Google Sheet — երկու դեպք։ Նույն թերթը, որ պահում է կադրի պարամետրերը (ժամկետ, շեմեր, թիրախ-պաշար), պահում է նաև գնագոյացման պարամետրերը (RRP, մեծածախ, գնի տեսակներ)։ Power Query-ն այն քաշում է որպես սովորական աղյուսակ՝

-- Գներ GS-ից (պարզեցված)
let
    Source = Csv.Document(
        Web.Contents("https://docs.google.com/spreadsheets/d/.../export?format=csv&gid=..."),
        [Delimiter=",", Encoding=65001, QuoteStyle=QuoteStyle.Csv]),
    Header = Table.PromoteHeaders(Source),
    Types  = Table.TransformColumnTypes(Header, {
        {"Item.SKU",            type text},
        {"Lead time, days",     Int64.Type},
        {"Zero threshold CW",   Int64.Type},
        {"Flag threshold",      Int64.Type},
        {"Target stock, days",  Int64.Type}
    })
in
    Types

DAX-չափիչներում պարամետրերը ներքաշվում են LOOKUPVALUE-ով կամ ֆակտ-աղյուսակների հետ կապերով՝ ըստ SKU-ի։ Արժեքը փոխվում է GS-ում՝ հաջորդ «Թարմացնել»-ի ժամանակ այն հասնում է մոդել և վերահաշվարկում դրանից կախված ամեն ինչ։