Pyramid affärssystem styr era order och er webb

Ni har order, lager, inköp och kundreskontra i Pyramid sedan länge. Nu ska produktwebben eller kundportalen visa samma artiklar, priser och saldon. Beställningarna ska tillbaka till Pyramid utan att någon behöver registrera dem igen.

Med Pyramid affärssystem börjar integrationsproblemen ofta när ingen har bestämt vilka uppgifter som får lämna systemet. Kartan över uppgifternas hemvist är det viktigaste beslutet. Den anger vem som äger varje uppgift, vad kanalerna får visa och vilka ändringar som får skrivas tillbaka.

Pyramid affärssystem är er transaktionskärna

En kund lägger en beställning från sin avtalade prislista. Artikeln finns på flera lagerställen och kunden har särskilda leveransvillkor. Webbgränssnittet behöver presentera köpet begripligt, medan affärssystemet behöver kontrollera att ordern går att behandla.

Pyramid Business Studio är ett svenskt, modulärt affärssystem för handel och tillverkning. För integrationsarbetet är den aktiverade kombinationen av moduler viktigare än hela modulutbudet.

Transaktionskärna betyder här att Pyramid ansvarar för de affärsregler som styr artikel, pris, lagerställe och order. Kopplingen ska använda tillgängliga rutiner för validering och spårbarhet. Webben publicerar ett bestämt urval och tar emot beställningar inom dessa gränser.

Bestäm vilket system som får ändra en uppgift innan ni bestämmer hur uppgiften ska överföras. Anta att marknadsavdelningen vill ändra produktens visningsnamn. Den ändringen kan höra hemma i PIM, medan artikelnumret behöver förbli stabilt i Pyramid. Ett nytt visningsnamn ska kunna publiceras utan att orderns artikelidentitet förändras.

Systemets långa livslängd kräver också eftertanke. För ert projekt behöver ni känna till den faktiska installationens version, moduler och äldre anpassningar.

En gammal anpassning kan exempelvis bestämma hur leveransvillkor sätts. Om webbprojektet förbiser regeln kan en tekniskt korrekt order ändå bli fel för kunden. Därför behöver ekonomi, försäljning och systemansvarig godkänna samma karta över flödena.

Era data har en hemvist i varje flöde

Artikelidentitet och grundegenskaper har sin hemvist i Pyramid. PIM kan samla och berika produktinformation, som sedan publiceras till produktwebb, kundportal och återförsäljarkanaler. Bestäm vilka fält PIM får ändra och vilka som bara får läsas. Annars kan en synkronisering skriva över redaktionella ändringar.

Strukturerad produktinformation ger er en plats att hantera och berika innehållet innan det distribueras till kanalerna. Låt artikelnumret ligga kvar i Pyramid, medan beskrivningar, bilder och kanaltexter hanteras i PIM. Då ändras presentationen utan att orderns artikelidentitet påverkas.

Pris, avtal och rabatt hämtas från Pyramid. Portalen visar priset för den inloggade kunden, med de villkor som gäller. En separat rabattberäkning i webben skapar regler som också måste hållas uppdaterade.

Lager och lagerställe publiceras som en kopia, med en fördröjning som ni behöver ta höjd för. Pyramid hanterar reservationer och lagerrörelser när ordern behandlas. Skilj därför mellan ett visat saldo och ett bekräftat leveransbesked, särskilt när flera kanaler använder samma lager.

Order och kunduppgifter skrivs tillbaka genom en dokumenterad importrutin. Avgränsa integrationen mot affärssystemet till bestämda fält och händelser. Bestäm också hur systemet hanterar en leveransadress som ändras vid beställningen.

Artikel, pris och lager skrivs aldrig tillbaka från kanalerna, eftersom Pyramid äger dem. Order och kund är de enda flöden som går tillbaka, och då via en dokumenterad importrutin.

Synkronisera ändringar med markör eller tidsstämpel och gör överföringen idempotent. Då ger en upprepad överföring samma resultat. Ni behöver också en statuslogg över lyckade och misslyckade poster. Kontrollera artikelnummer, enhet, momskod, lagerställe och språk före publicering.

Databasen avgör hur kopplingen byggs

Inventeringen kommer före ritningen. Ta reda på databasmotor, Pyramid-version, aktiverade moduler och tillgängliga åtkomstkomponenter. Kontrollera också vem som får konfigurera anslutningen och vem som ansvarar för driften.

Svenska installationer kan använda Action PSQL, tidigare Pervasive SQL och Btrieve, eller Microsoft SQL Server. PSQL nås normalt via Pervasive ODBC. SQL Server kan läsas med vanliga SQL-verktyg. Pyramid Link Access kan ge ODBC- eller OLE DB-åtkomst för externa webb-, analys- och portallösningar.

Vid SQL Server behöver ni dimensionera säkerhetskopiering, läsrättigheter, indexering och belastningstest separat från webbplattformen. En tung export kan påverka verksamhetens arbete även när webbservern fungerar normalt. Testa därför samtidigt som representativa arbetsuppgifter körs i affärssystemet.

Vid PSQL behöver ni uttryckligen testa ODBC-drivrutin, DSN, teckenkodning och serveråtkomst. Fel inställning kan ge selektiva läsfel. Prova därför verkliga artikeltexter och kunduppgifter med svenska tecken, tomma fält och långa värden. Med Pyramid Link Access gäller samma princip om minsta behörighet mot webb, analys och portal.

Ge anslutningen minsta nödvändiga behörighet. En process som enbart läser artiklar ska ha rättigheter för just den uppgiften. Separata identiteter gör det också lättare att se vilken process som orsakat ett fel.

Mät batchtid, antal ändrade poster, felkvot och fördröjning till publicerad kanal. Samma beslut om uppgifternas hemvist kan kräva olika tester beroende på databasmotorn.

Egenskaper publiceras från en egen läsmodell

En läsmodell behöver en tydlig uppdateringsregel som anger när den ändras och vad som händer om en överföring misslyckas. Det avgör hur snabbt nya egenskaper syns och hur ni hanterar tillfälligt inaktuella värden.

Pyramids e-line kan överföra egenskapsdata till en SQL-databas på webbservern via ODBC och rutin 791, E-line Kommunikation. Den separata databasen ger webbplatsen en modell för snabba läsningar, utan att varje sidvisning behöver fråga Pyramids transaktionsdatabas.

Er produktwebb eller PIM-lösning kan använda publiceringsmodellen. Med PIM samlar ni produktinformation strukturerat, berikar den och distribuerar den till webbplatser, kundportaler och återförsäljarkanaler. Läs mer om hur PIM-data struktureras och används.

Avgränsa vilka egenskaper som ska publiceras och hur ofta modellen uppdateras. Sätt också en gräns för hur gammal information får vara. Om överföringen stannar behöver webbplatsen antingen visa senast publicerade värden eller markera att uppgiften inte är aktuell.

Ge läsprocessen en separat databasanvändare och utse ansvarig för säkerhetskopiering. Dokumentera hur modellen återskapas efter en återställning och hur den återupptar synkroniseringen från senast kända läge.

Tekniskt giltiga värden kan ändå bli missvisande i handeln. En försäljningsenhet kan till exempel tolkas fel. Låt verksamheten godkänna representativa produkter med språk, förpackningar och egenskaper innan publiceringen breddas.

I specifikationen anger ni källa, mål, uppdateringsintervall, felkö och ansvarig för avvisade poster. Skilj mellan saknade värden och avsiktligt tomma fält. Annars kan nästa överföring radera en manuell komplettering.

Svenska bolag bygger ut Pyramid i etapper

Pyramid byggs ofta ut stegvis, i takt med att verksamheten förändras. Användare, e-handel, transportadministration och elektronisk fakturering läggs till under åren, och därför behöver en integration spegla både grundflöden och senare tillägg.

När ni bygger ut en portal kan en ny modul påverka vilka orderstatusar som ska visas. En transportkoppling kan tillföra leveransreferenser som saknades vid första lanseringen. Dokumentera därför varje status betydelse och ange vilket system som äger den.

Ett exempel på en lösning i ett Pyramid-landskap är den nya lösningen för Skyltar & Märken, en del av Addtech. Den bygger på Glansers funktionsbibliotek och Litium och är integrerad mot Pyramid.

Lång livslängd gör integrationsomfattningen svårare att uppskatta än gränssnittet antyder. En orderknapp kan behöva ta hänsyn till kreditspärrar, restorder och kundundantag. Sådana beroenden påverkar kalkylen.

Spara beslut om fält, statusar och undantag tillsammans med testerna. Då kan ni se vilka delar som påverkas när nästa modul tillkommer och ge båda parter ett gemensamt underlag för att godkänna ändringen.

Faktura och personuppgifter följer med ordern

En portal som enbart visar orderstatus lämnar fakturaansvaret odefinierat. Någon behöver äga sambandet mellan order, faktura, kreditnota och bilagor. Referenserna måste fungera även när dokumenten lagras i olika system.

Skatteverkets krav på obligatoriska fakturauppgifter omfattar bland annat unikt löpnummer, köparens namn och adress samt varornas mängd och art. Där ingår även beskattningsunderlag, enhetspris, skattesats och momsbelopp, för både elektroniska fakturor och pappersfakturor. Elektroniskt lagrade fakturauppgifter ska enligt samma vägledning vara läsbara och oförändrade under lagringstiden.

Ett belopp i portalen behöver kunna kopplas till det fullständiga fakturaunderlaget. Spara stabila dokumentreferenser och bestäm var originalunderlaget finns. Testa att en behörig användare kan hitta rätt faktura från en order. Kontrollera också hur en kreditnota kopplas till underlaget och hur bilagor följer med vid återläsning.

Skatteverket definierar en elektronisk faktura som utfärdad och mottagen i elektroniskt format, med mottagarens godkännande som huvudregel. Upphandlande myndigheter och enheter ska acceptera elektroniska fakturor, där europeisk standard gäller om annan standard saknar avtal. Mottagare och avtal behöver därför styra fakturakanalen. Order och faktura behöver en stabil koppling och en ansvarig lagringsplats, kreditnotor och bilagor behöver hänvisa till rätt underlag, och för kund- och kontaktuppgifter behöver ni bestämma ändamål, behörighet och gallringsregel.

Personuppgifter behöver en egen avgränsning. IMY:s princip om lagringsminimering innebär att uppgifterna sparas så länge ändamålet kräver och därefter raderas eller avidentifieras. Gallringen måste samtidigt ta hänsyn till underlag som behöver bevaras enligt andra tillämpliga krav.

En kundportal bör därför visa ett beslutat urval av kund-, kontakt- och orderuppgifter. Ange vad som händer när en kontaktperson slutar eller kundrelationen upphör. Att kopiera samtliga fält från Pyramid innebär att ni också behöver motivera och förvalta hela kopian.

Upplägget kräver registervård före automatisering

Ni behöver utse personer som äger artikel, pris, lagerställe och kund. De måste kunna besluta vilka dubbletter som tas bort och vilka värden som gäller. Leverantören kan bygga kontrollerna, men verksamheten behöver avgöra vad uppgifterna betyder.

Avsätt tid för att testa läsning, orderimport, felposter och återläsning av faktura. Använd normala beställningar tillsammans med verkliga undantag. En testorder som saknar rabatt, restnotering och alternativ leveransadress ger ett begränsat godkännande.

Vänta med automatiseringen om publiceringen skulle sprida fel priser eller saldon. Då behöver registervården bli klar först. En koppling kan upptäcka felaktiga värden, men någon hos er måste kunna rätta dem. En odokumenterad specialregel behöver bli ett beslutat arbetssätt innan utvecklaren kan bygga den.

En standardkoppling med fast omfattning passar när produkt-, kund-, lager- och orderflöden går att beskriva tydligt. Den passar sämre när varje order har egna undantag som ingen kan formulera. Bestäm då om regeln ryms i befintlig konfiguration eller behöver en isolerad kundunik del.

Kontrollera också om det egentliga behovet gäller affärssystemet självt. Om Pyramid saknar förutsättningar för era beslutade processer behöver det arbetet få en egen bedömning. En webbkoppling löser ingen bristande process i affärssystemet.

En ren contentwebb utan pris, lager och order behöver däremot ingen skrivande orderkoppling. Begränsa omfattningen till de uppgifter besökaren faktiskt behöver. Det minskar antalet flöden ni måste testa och underhålla.

Tre frågor visar om integrationen håller

Fråga vem som tar ansvar för ordervalideringen när Pyramid uppdateras, och vilka åtgärder som ingår utan ny offert. Svaret visar om integrationen har en ägare efter go-live eller om varje uppgradering blir ett nytt uppdrag.

Fråga vilka fält webb och portal får publicera, hur länge de sparas och hur de gallras när en kund slutar. Svaret visar om leverantören har tänkt på personuppgifterna eller bara på flödet.

Fråga hur order, faktura och kreditnota kopplas mellan systemen och vad som händer när en överföring misslyckas eller körs två gånger. Svaret visar om felhanteringen är byggd eller bara utlovad. En genomgång av integration mot affärssystemet beskriver hur flöden och ansvar kan delas upp.

Tillsammans visar svaren om kartan över datahemvist håller: Pyramid äger artikel, pris, lager och order, medan webb, PIM och portal publicerar eller skriver tillbaka de fält som ni har beslutat om.

Hos Glanser kan ni se hur vi arbetar med integrationer mot affärssystemet och använd er karta över artikel, pris, lager och order som underlag när ni bedömer nästa steg.