Պահեստ և ERP սինքրոնիզացիա

01Պահեստներ, մնացորդներ և շարժեր

Պահեստը ցանկացած տեղ է, որտեղ ապրանք կա՝ կենտրոնական պահեստ, խանութի մասնաճյուղ, մատակարարի dropship մնացորդ։ Մնացորդը (stock level) մեկ տարբերակի ընթացիկ քանակն է մեկ պահեստում։ Հիմնական գաղափարն այն է, որ դուք երբեք պարզապես չեք վերագրում այդ թիվը։ Յուրաքանչյուր փոփոխություն մնացորդի շարժ է՝ տող, որն ասում է «+20 ստացվել է 118 գնման պատվերից», «−2 վաճառվել է 5531 պատվերում», «−1 վնասված», «+3 հաշվառման ուղղում»։ Մնացորդը շարժերի գումարն է՝ արագության համար cache-ավորված։ Ինչպես բանկային քաղվածքը, շարժերի պատմությունը բացատրում է յուրաքանչյուր թիվ, թույլ է տալիս վերակառուցել մնացորդները bug-ից հետո և տալիս է հաշվետվություններ՝ պահեստի արժեքավորում, «մեռած» մնացորդ և sell-through։ Գույքագրումները (stocktake) համեմատում են ֆիզիկական հաշվարկը համակարգի հետ և տարբերության համար ստեղծում ուղղիչ շարժեր։

1CREATE TABLE stock_movements (
2  id            BIGSERIAL PRIMARY KEY,
3  variant_id    BIGINT NOT NULL,
4  warehouse_id  BIGINT NOT NULL,
5  quantity      INTEGER NOT NULL,          -- positive in, negative out
6  reason        TEXT NOT NULL,             -- sale, receipt, transfer_out, count, waste
7  reference     TEXT,                      -- order or purchase order id
8  created_by    BIGINT,
9  created_at    TIMESTAMPTZ NOT NULL DEFAULT now()
10);
11 
12-- Rebuild or verify cached levels from history
13SELECT variant_id, warehouse_id, SUM(quantity) AS on_hand
14FROM stock_movements
15GROUP BY variant_id, warehouse_id;

02Հասանելի մնացորդ և ռեզերվներ

«On hand»-ը այն է, ինչ ֆիզիկապես պահեստում է։ «Available»-ը այն է, ինչ դեռ կարող եք խոստանալ՝ on hand-ը հանած ռեզերվը։ Ռեզերվը ստեղծվում է, երբ պատվերը տեղադրվում և վճարվում է (կամ մինչ վճարումը pending է՝ ժամկետով), և դառնում է իրական ելքային շարժ, երբ պատվերը հավաքվում և ուղարկվում է։ Եթե պատվերը չեղարկվում է կամ վճարումը ձախողվում է, ռեզերվն ազատվում է։ Storefront-ը պետք է ցույց տա հասանելի մնացորդը՝ գումարված այն պահեստներով, որոնք կարող են սպասարկել հաճախորդին։ Fulfilment-ի կանոններն ընտրում են աղբյուրը՝ մոտակա մասնաճյուղ, գլխավոր պահեստ, մատակարար, որն ուղիղ է առաքում, կամ backorder (վաճառել հիմա, առաքել համալրումից հետո)։ Այս կանոնները դարձրեք բացահայտ, որովհետև «ո՞ր պահեստն է սա ուղարկում» հարցը ազդում է առաքման ժամկետի, արժեքի և հաշվապահության վրա։

03Տեղափոխումներ, գնման պատվերներ և մատակարարներ

Տեղափոխումը (transfer) մնացորդը պահեստների միջև շարժում է երկու քայլով՝ ելքային շարժ, երբ այն դուրս է գալիս, և մուտքային, երբ հասնում է։ Այդ ընթացքում ապրանքը «ճանապարհին է» և չի պատկանում ոչ մի դարակի․ մոդելավորեք այդ վիճակը, այլապես մնացորդը կարծես անհետանում է։ Գնման պատվերները (PO) այն միջոցն են, որով մնացորդը մուտք է գործում․ դուք պատվիրում եք մատակարարից, PO-ն ունի սպասվող քանակներ և արժեքներ, իսկ ապրանքի ընդունումները (goods receipts) գրանցում են իրականում ժամանածը, որը կարող է լինել մասնակի կամ տարբեր։ Յուրաքանչյուր ընդունում ստեղծում է մուտքային շարժեր և թարմացնում ինքնարժեքը, որը սնում է մարժայի և արժեքավորման հաշվետվությունները։ Լավ տվյալներով կարող եք գեներացնել վերապատվիրման առաջարկներ՝ միջին օրական վաճառքը բազմապատկած մատակարարի lead time-ով՝ գումարած պահուստային մնացորդը, համեմատած հասանելի և ճանապարհին գտնվող մնացորդի հետ։

• PO-ների կարգավիճակներ՝ draft → sent → partially received → received → closed։
• Ընդունման պահին գրանցեք միավորի արժեքը․ մարժաները կախված են դրանից։
• Հետևեք մատակարարների արդյունավետությանը՝ ուշացած առաքումներ և քանակների տարբերություններ։

04Սինքրոնիզացիա հաշվապահության և ERP-ի հետ

ERP-ն (enterprise resource planning) կամ հաշվապահական համակարգը բիզնեսի back office-ն է՝ ապրանքներ, գներ, հաճախորդներ, հաշիվ-ապրանքագրեր և մնացորդ՝ հարկային նպատակներով։ Նախ որոշեք սեփականությունն ըստ տվյալի տեսակի։ Տարածված բաժանում՝ ERP-ին են պատկանում ապրանքների կոդերը, գները և պաշտոնական մնացորդը, խանութին՝ նկարագրությունները, նկարները, SEO-ն և առցանց պատվերները։ Հետո սինքրոնացրեք սեփականության ուղղությամբ։ ERP-ների API-ների մեծ մասը դանդաղ է կամ batch-ի վրա կողմնորոշված, ուստի սինքրոնացրեք պլանավորված job-երով՝ փոխված գներն ու մնացորդը քաշեք մի քանի րոպեն մեկ, նոր պատվերներն ու վերադարձները push արեք դրանց կատարվելուն պես՝ queue-ի միջոցով, իսկ ամեն գիշեր կատարեք ամբողջական համեմատություն։ Յուրաքանչյուր job դարձրեք idempotent՝ համընկեցնելով կայուն արտաքին ID-ներով, մշակեք batch-երով և պահեք sync log՝ քանակներով և սխալներով։ Թույլ տվեք ադմիններին կարգավորումներից միացնել և անջատել առանձին job-երը․ դա անգնահատելի է ERP-ի սպասարկման ժամանակ։

1// Laravel scheduler: each sync is a separate, non-overlapping job
2use Illuminate\Support\Facades\Schedule;
3 
4Schedule::job(new SyncPricesFromErp)->everyFiveMinutes()
5    ->withoutOverlapping()->when(fn () => settings('erp.sync_prices'));
6 
7Schedule::job(new SyncStockFromErp)->everyTenMinutes()
8    ->withoutOverlapping()->when(fn () => settings('erp.sync_stock'));
9 
10Schedule::job(new CompareCatalogueWithErp)->dailyAt('03:00')
11    ->withoutOverlapping();
12 
13Schedule::job(new CheckErpHealth)->everyFiveMinutes(); // alerts admins on failures

05Կոնֆլիկտներ, health check-եր և անվտանգության ցանցեր

Sync-երը ձախողվում են լուռ ձևերով՝ ERP-ն չի աշխատում, ապրանքի կոդը վերանվանվել է, գների import-ը զրո է պարունակում։ Պաշտպանեք ձեզ։ Health check-երը հետևում են յուրաքանչյուր job-ի վերջին հաջող գործարկմանը և alert են ուղարկում, երբ այն չափազանց հին է կամ սխալների տոկոսը կտրուկ աճում է։ Sanity կանոնները մերժում են կասկածելի փոփոխությունները՝ գնի 90% անկում, ամբողջ մնացորդի զրոյացում, և պահում դրանք վերանայման համար։ Պահեք նախորդ արժեքները, որպեսզի ադմինը կարողանա մեկ click-ով հետ շրջել գների վատ import-ը։ Կոնֆլիկտների դեպքում հաղթում է սեփականատերը․ եթե երկու կողմն էլ փոխել են դաշտը, վերցրեք արժեքը այն համակարգից, որին այն պատկանում է, և log արեք վերագրումը։ Գիշերային համեմատության հաշվետվությունը ցուցակագրում է այն ապրանքները, որոնք կան միայն մի կողմում կամ տարբերվում են, որպեսզի մարդիկ տվյալներն ուղղեն աղբյուրում՝ խանութը patch անելու փոխարեն։

06Ֆիսկալ կտրոններ

Շատ երկրներում յուրաքանչյուր վաճառք պետք է գրանցվի հարկային մարմնում ֆիսկալ սարքի կամ cloud ծառայության միջոցով, որը վերադարձնում է ֆիսկալ կտրոնի համար (հաճախ տպված կամ ցույց տրված որպես QR կոդ)։ Վերադարձներին պետք են իրենց սեփական ֆիսկալ վերադարձի կտրոնները՝ կապված սկզբնականի հետ։ Վերաբերվեք սրան ինչպես վճարային ինտեգրացիային՝ ստեղծեք կտրոնի գրառում կարգավիճակով, ուղարկեք այն queue-ի միջոցով retry-ներով, պահեք ֆիսկալ համարը պատվերի վրա և alert ուղարկեք ձախողումների դեպքում։ Retry արեք միայն այն ժամանակ, երբ դա անվտանգ է․ եթե ծառայությունը կարող էր գրանցել կտրոնը մինչև timeout-ը, նախ ստուգեք՝ կրկնօրինակներից խուսափելու համար։ Մասնաճյուղերը կամ դրամարկղերը, որոնք կարող են աշխատել offline, պետք է ունենան offline ռեժիմ, որը կտրոնները հերթագրում է և ուղարկում կապը վերականգնվելուն պես՝ օրենքով թույլատրված ժամկետում։

07Համաձայնեցվածություն շարժերի և cache արված մնացորդների միջև

Շարժերը պատմությունն են, իսկ մնացորդների մակարդակները՝ cache, ուստի դրանք երբեք չպետք է շեղվեն միմյանցից։ Գրեք երկուսն էլ նույն transaction-ում. insert արեք շարժը և թարմացրեք մակարդակը պայմանական հրամանով, որը չի կարող բացասական դառնալ, եթե backorder-ները թույլատրված չեն։ Lock-երի հերթականությունը կարևոր է, երբ մեկ գործողությունը դիպչում է մի քանի տողի, օրինակ՝ տեղափոխումը կամ բազմատող պատվերը. միշտ lock արեք տողերը նույն հերթականությամբ (օրինակ՝ ըստ variant_id-ի, ապա warehouse_id-ի), որպեսզի խուսափեք deadlock-ներից։ Պահեք գիշերային ստուգման job, որը գումարում է շարժերը յուրաքանչյուր տարբերակի և պահեստի համար և համեմատում cache արված մակարդակի հետ. ցանկացած տարբերություն bug է, որը պետք է ուսումնասիրել, այլ ոչ թե լուռ ուղղել։ Գրառումների մեծ ծավալների դեպքում շարժերը կարելի է partition անել ըստ ամիսների, իսկ հին ամիսները ամփոփել սկզբնական մնացորդների մեջ։

1BEGIN;
2-- 1. Decrease the cached level only if enough is available
3UPDATE stock_levels
4SET on_hand = on_hand - 3
5WHERE variant_id = 42 AND warehouse_id = 1 AND on_hand - reserved >= 3;
6-- 0 rows → ROLLBACK and report out of stock
7 
8-- 2. Record why it changed
9INSERT INTO stock_movements (variant_id, warehouse_id, quantity, reason, reference)
10VALUES (42, 1, -3, 'sale', 'order:5531');
11COMMIT;

08Պաշարների գնահատում և ինքնարժեքի մեթոդներ

Մնացորդը դարակների վրա դրված գումար է, ուստի ֆինանսական բաժինը հարցնում է, թե որքան արժե այն և ինչ ինքնարժեք ուներ յուրաքանչյուր վաճառք։ Դա կախված է ինքնարժեքի մեթոդից։ Weighted average cost-ը յուրաքանչյուր մուտքի ժամանակ վերահաշվարկում է միավորի ինքնարժեքը. (հին քանակ × հին ինքնարժեք + ստացված քանակ × նոր ինքնարժեք) / ընդհանուր քանակ։ Այն պարզ է և տարածված ERP-ներում։ FIFO-ն (first in, first out) ենթադրում է, որ ամենահին միավորները վաճառվում են առաջինը, ուստի յուրաքանչյուր վաճառք սպառում է ինքնարժեքի շերտերը ամենահին մուտքից. դա պահանջում է շերտեր յուրաքանչյուր մուտքի համար, բայց ճշգրիտ է արտացոլում աճող գները։ Ինչ էլ ընտրեք, այն պետք է համապատասխանի ERP-ին կամ հաշվապահական համակարգին, հակառակ դեպքում խանութում և հաշվապահությունում մարժաները չեն համընկնի։ Ինքնարժեքը գրանցեք վաճառքի շարժի վրա վաճառքի պահին, ճիշտ ինչպես գների snapshot-ները պատվերներում, որպեսզի հետագա մուտքերը չվերագրեն պատմական մարժաները։

• Weighted average. մեկ ինքնարժեք յուրաքանչյուր տարբերակի և պահեստի համար, թարմացվում է մուտքի ժամանակ։
• FIFO. ինքնարժեքի շերտեր յուրաքանչյուր մուտքի համար, սպառվում են ամենահիններից սկսած։
• Վերադարձները մնացորդ են մտնում այն ինքնարժեքով, որով դուրս են եկել, այլ ոչ թե այսօրվա ինքնարժեքով։

09Ինտեգրացիայի pattern-ներ. polling, event-ներ և outbox

Մեկ այլ համակարգում փոփոխությունների մասին իմանալու երկու եղանակ կա. polling (ժամանակացույցով հարցնել «ի՞նչ է փոխվել T պահից հետո») և event-ներ (մյուս համակարգը push է անում webhook-ներ կամ message-ներ)։ Շատ ERP-ներ աջակցում են միայն polling։ Poll արեք watermark-ով՝ ձեր մշակած վերջին updated timestamp-ով կամ change ID-ով, որը պահվում է յուրաքանչյուր job-ի համար, և պատուհանը թեթևակի համընկնող դարձրեք՝ ժամացույցների շեղումը հանդուրժելու համար՝ հենվելով idempotent upsert-ների վրա, որպեսզի կրկնակի ընթերցումները անվնաս լինեն։ Ձեր ուղարկած տվյալների համար օգտագործեք transactional outbox pattern-ը. պատվերի հետ նույն database transaction-ում insert արեք տող outbox աղյուսակում, իսկ worker-ը կարդում է outbox-ը և ուղարկում ERP, կրկնելով մինչև հաստատում ստանալը։ Սա երաշխավորում է, որ commit արված պատվերը վերջիվերջո export կլինի, իսկ rollback արվածը՝ երբեք, առանց distributed transaction-ների։

1CREATE TABLE outbox (
2  id           BIGSERIAL PRIMARY KEY,
3  topic        TEXT NOT NULL,        -- erp.order_created, erp.return_created
4  payload      JSONB NOT NULL,
5  attempts     INT NOT NULL DEFAULT 0,
6  sent_at      TIMESTAMPTZ,
7  created_at   TIMESTAMPTZ NOT NULL DEFAULT now()
8);
9 
10-- Worker: claim a batch without blocking other workers
11SELECT id, topic, payload FROM outbox
12WHERE sent_at IS NULL
13ORDER BY id
14LIMIT 50
15FOR UPDATE SKIP LOCKED;

10Բազմապահեստային բաշխում և բաժանված առաքումներ

Մի քանի պահեստի դեպքում յուրաքանչյուր պատվեր փոքր օպտիմալացման խնդիր է. ո՞ր վայրերը պետք է կատարեն որ տողերը։ Տարածված կանոններ՝ առաջնահերթության կարգով. ամեն ինչ առաքել մեկ վայրից, եթե հնարավոր է (մեկ ծանրոցն ավելի էժան է), նախընտրել հաճախորդին ամենամոտ վայրը, խուսափել մասնաճյուղի ցուցափեղկի մնացորդը սպառելուց և մատակարարի dropship-ը կամ backorder-ը օգտագործել միայն որպես վերջին միջոց։ Կանոնները գրեք որպես scoring function և որոշումը գրանցեք պատվերի վրա, որպեսզի պահեստի աշխատակիցներն ու support-ը տեսնեն, թե ինչու է ընտրվել տվյալ վայրը։ Բաժանված առաքումներին պետք են իրենց սեփական գրառումները. մեկ պատվեր, մի քանի shipment, յուրաքանչյուրը՝ տողերով, tracking-ով և կարգավիճակով, իսկ պատվերը դառնում է առաքված միայն այն ժամանակ, երբ բոլոր shipment-ները առաքված են։ Ռեզերվները պետք է արվեն յուրաքանչյուր պահեստի համար checkout-ի ժամանակ, ոչ թե ավելի ուշ, հակառակ դեպքում բաշխումը կարող է ձախողվել այն բանից հետո, երբ հաճախորդն արդեն վճարել է։