Ett artikelnummer som fortfarande fungerar är inte samma sak som en artikel som företaget kommer att sälja till dig, så IFS-ersättningen når Pimcore långt innan en katalog anger något som företaget inte längre lagerför.
Serviceföretag byter ständigt ut delar, och IFS registrerar det som en ersättning: den här levereras inte längre, den andra tar dess plats, och allt som redan är installerat fortsätter att fungera. En katalog har inget sådant koncept. Så Pimcore har den gamla posten med sin specifikation och sitt fotografi, en specificerare laddar ner den, och beställningen anländer för något som företaget slutade köpa för två år sedan. Ingen har fel och alla slösar bort en vecka. Att koppla samman IFS och Pimcore överför ersättningen, så en katalogpost säger vad den är nu snarare än vad den var när någon berikade den.

När IFS ersätter en artikel pekar Pimcore-ingången på vad som ersätter den, så en specificerare hänvisas till den aktuella artikeln istället för att beställa en som företaget inte längre levererar.
Eftersom kopplingen mellan det gamla numret och det nya bibehålls kan någon som underhåller utrustning som installerats för flera år sedan fortfarande nå rätt del via katalogen.
En ersättning ärver innehållet som redan skrivits i Pimcore istället för att börja tomt, så en supersession skapar inte tyst en katalogpost utan något i sig.
Tekniska detaljer läses från IFS snarare än omskrivs, så det som anges i ett Pimcore-datablad och det som serviceföretaget har beskriver exakt samma komponent.
När IFS registrerar att en artikel är ersatt uppdaterar Alumio Pimcore-posten för att namnge vad som ersätter den, så att katalogen dirigerar en specificerare framåt istället för att låta dem beställa ett nummer som inte kommer att uppfyllas.
Specifikationen och dokumenten som redan har berikats mot den gamla Pimcore-produkten är kopplade till ersättningen, så den nya produkten anländer användbar istället för att behöva en veckas arbete innan någon utomstående kan läsa den ordentligt.
Tekniska värden som lagras i IFS publiceras till matchande Pimcore-attribut i den cykel du anger, så ett datablad som någon laddar ner återspeglar den komponent som företaget tillhandahåller snarare än en version från en tidigare version.
Alumio fungerar som en central integrationsplattform mellan försäljningskanaler och logistiksystem. Order dirigeras, transformeras och valideras, samtidigt som statusuppdateringar skickas tillbaka till varje kanal.
Autentisera dina system med Alumios färdiga kopplingar. Välj bland över 200 kopplingspaket i vår marketplace, utöver obegränsade anpassade integrationer.
Definiera hur datafält mappas mellan system i ett visuellt gränssnitt. Justera format, berika poster och tillämpa affärslogik – helt utan behov av anpassad kod.
Konfigurera flöden så att de körs i realtid baserat på händelser, enligt ett schema eller både och. Minska manuell datainmatning och låt Alumio hantera förflyttning och transformering mellan system.
När din första integration är live, ansluter du enkelt ditt ERP, PIM, WMS eller CRM till samma hubb. Befintliga flöden fortsätter att köras. Ingen ombyggnad från grunden krävs.
Den andra kopplingen som de flesta serviceföretag gör är till varhelst anbud besvaras, eftersom en specificerare som läser ett Pimcore-datablad vanligtvis sammanställer en ansökan och IFS har ingen insyn i den alls. Vad de laddade ner och vad de slutligen specificerade är värt att veta. Alumio har den kopplingen parallellt med denna, så katalogen och anbudet beskriver samma komponenter.
Det kan det, och supersessionslänken färdas som sin egen informationsbit. Alumio läser delar, deras specifikationer och ersättningsrelationerna som IFS har, och skriver dem till matchande Pimcore-objekt på den cykel du ställer in. Att behålla länken snarare än att bara radera den gamla posten är det som gör att någon med äldre utrustning fortfarande kan hitta den aktuella delen. De tillgängliga objekttyperna är de som Pimcore exponerar, så länken behålls på det sätt den förstår.
Nej, detta är konfigurerat snarare än kodat. Det är databladet som någon bygger om i ett dokument varje gång en specifikation ändras som visas. Vilka IFS-värden som mappas till vilka Pimcore-attribut, och vad en supersession gör med ett befintligt objekt, är poster i Alumio. IFS-installationer har lokal konvention, så Code Transformer täcker ett fält som inte mappas som det är.
Ersättningen, där det gamla numret fortfarande går att hitta, är den del som de flesta kataloger gör fel i ena eller andra riktningen. Att ta bort den ersatta posten gör att alla som underhåller äldre utrustning, och lämnar den oförändrad, inbjuder till beställningar som företaget inte kommer att uppfylla. Genom att överföra ersättningslänken från IFS kan Pimcore göra båda: det gamla numret matchas, och det det matchar är det som faktiskt levereras.
En specifikation som ändrades medan en anbudsinfordran var öppen är ett fel med en tillhörande kostnad, eftersom någon redan har offererat från den version de laddade ner. Alumio övervakar varje uppdatering live och registrerar IFS-delen och de värden den innehöll, så ett objekt som Pimcore vägrar utlöser en varning som namnger delen och orsaken. Återförsök körs där de är konfigurerade, så ingenting lämnas tyst kvar på en gammal revision.
Prata med en integrationsspecialist på Alumio. Vi tar fram rätt arkitektur för dina system, i rätt skala, så att din verksamhet förblir stabil genom alla förändringar.