Inköpsflödet: förfrågningar till ordrar till mottagningar
Gå igenom hela inköpscykeln för Internal Teams API: läs godkända inköpsförfrågningar, skapa inköpsordrar, associera rader och registrera mottagningar.
Den här guiden går igenom hela inköpscykeln med Internal Teams API: tekniker skapar inköpsförfrågningar (PR:er), ditt inköpssystem gör om dem till inköpsordrar (PO:er) med en leverantör, och varor kommer in som mottagningar som uppdaterar lager. Den förutsätter att du har en partner-API-nyckel (se introduktionen).
Alla exempel förutsätter:
Statusvokabulär
Inköpsförfrågningar: requested, denied, cancelled, approved, orderInProgress, ordered, partially_ordered, fulfilled, partially_fulfilled. En PR:s status räknas om från dess rader allteftersom de associeras till PO:er, så det mesta av rörelsen sker automatiskt.
Inköpsordrar: new, ordered, received, partially_received, cancelled, closed.
1. Läs godkända inköpsförfrågningar
Varje frågeparameter annan än pagineringsparametrarna fungerar som ett likhetsfilter på entitetens kolumner (status=approved, stockLocationId=42), alltid inom ditt företags omfång.
För en tvär-PR-arbetslista, fråga rader direkt:
PR-statusar kan också sättas direkt när ditt godkännandeflöde finns utanför OpenWrench: PATCH .../purchase_requests/{id}/{status} för valfri status i vokabuläret, och PATCH .../purchase_requests/{id}/cancelled för att avbryta (endast från requested eller approved; annars 400).
2. Skapa inköpsordern
POST /v1/partners/inventory/purchase_orders skapar PO:n med dess rader i ett anrop. Krävs: status (vanligtvis new), partEquipmentVendorId, currencyId och createdByEmail. totalCost krävs om inte ditt företags lagerinställningar markerar PO-kostnad som icke-obligatorisk (den är obligatorisk som standard). supplierCompanyId och supplierFacilityId härleds från din nyckel.
Varje rad sätter isEquipmentLine och sedan antingen part*-fälten eller equipment*-fälten. prLineItemIds registrerar vilka PR-rader PO-raden uppfyller. Att skicka ett id på översta nivån ersätter en befintlig PO:s skrivbara fält istället för att skapa en ny.
Associera PR-rader
Om du inte länkade PR:er via prLineItemIds vid skapandet, associera dem uttryckligen:
Varje listad PR-rad flyttas till orderInProgress med sitt associatedPurchaseOrderLineItemId satt, och varje förälder-PR:s status räknas om. Id:n som din nyckel inte kan läsa hoppas tyst över (anropet kan returnera en tom lista), så verifiera de returnerade posterna mot vad du skickade.
Revidera rader
POST /v1/partners/inventory/purchase_order_line_items/bulk tar en JSON-array av rader, alla refererande till samma supplierPurchaseOrderId, och har ersättningssemantik:
Alla befintliga ej mottagna rader på PO:n raderas först, sedan skapas de skickade. Skicka den fullständiga avsedda uppsättningen öppna rader varje gång. Radstatus kan inte sättas här: nya rader börjar som new, och en rad som skickas igen med sitt id behåller sin status.
PO:s del-/utrustnings-/inköpsförfrågan-id-listor räknas om och inköpsorder-aviseringen skickas igen. supplierFacilityId/supplierCompanyId per post kommer från din nyckel; poster utan skrivbehörighet hoppas tyst över.
3. Markera ordern lagd
Detta sätter PO:n till ordered och mejlar ordern till leverantören. Framgångssvaret är bekräftelsestränghöljet ("type": "Email", "data": "Email has been sent"), inte PO:n; hämta om PO:n för dess nya tillstånd. För att avbryta istället, PATCH .../purchase_orders/{id}/cancel (som returnerar den uppdaterade PO:n).
4. Registrera mottagningar när varor kommer
PUT /v1/partners/inventory/purchase_order_receipts registrerar mottagning mot en PO-rad. På den här slutpunkten måste updatedBy och supplierFacilityId anges i kroppen; de härleds inte från nyckeln.
Regler:
receiptNumber, purchaseOrderId, purchaseOrderLineItemId, receivedQuantity, updatedBy och supplierFacilityId är obligatoriska.
receivedQuantity måste vara skilt från noll; ett negativt värde registrerar en retur.
- Uppdatering av en mottagning justerar de mottagna kvantiteterna och kostnaderna på PO-raden och lagerposterna vid destinations-lagerplatsen.
- För serialiserad utrustning, skicka en post per enhet i
equipmentPerStockLocationReceiptValues, assetReceiptValues eller receiptValuesWithoutId. Arrayens längd måste vara lika med receivedQuantity, dessa arrayer får inte åtfölja en retur, och serie- eller tillgångsnummer som redan används avvisas.
- Leverantörsfakturametadata (
invoiceNumber, invoiceCurrency, invoiceTotal, exchangeRate, invoiceTotalPostExchange) kan fångas på mottagningen.
Läs tillbaka en mottagning med GET /v1/partners/inventory/purchase_order_receipts/{id}.
Idempotens och felhantering
- Skapanden är inte idempotenta: att försöka igen på ett timeout-drabbat PO-skapande kan duplicera ordern. Använd list-slutpunkten med ett filter (till exempel på dina
receiptNumber-liknande externa referenser) för att kontrollera innan du försöker igen.
- Behörighetsproblem yttrar sig som
400 (med standardfelshöljet), och tyst-överhoppade id:n på bulk- och associate-slutpunkterna innebär att ett “lyckat” anrop kan ha gjort mindre än du bad om. Stäm alltid av svarspayloaden mot din förfrågan.
- Katalog-slutpunkterna tillhandahåller de
partId, equipmentTypeId, partEquipmentVendorId och stockLocationId-värden det här flödet behöver.
- Varje ändring av inköpsorder, orderrad eller mottagning som görs via de här slutpunkterna registreras i inköpsorderns granskningslogg i OpenWrench, tillskriven kontakten bakom din API-nyckel.