This site uses cookies.
Some of these cookies are essential to the operation of the site,
while others help to improve your experience by providing insights into how the site is being used.
For more information, please see the ProZ.com privacy policy.
This person has a SecurePRO™ card. Because this person is not a ProZ.com Plus subscriber, to view his or her SecurePRO™ card you must be a ProZ.com Business member or Plus subscriber.
Affiliations
This person is not affiliated with any business or Blue Board record at ProZ.com.
Services
Translation, Interpreting, Editing/proofreading, Subtitling, MT post-editing, Transcription, Training
Expertise
Detailed fields not specified.
Rates
Payment methods accepted
MasterCard, PayPal, Check
Portfolio
Sample translations submitted: 3
Swedish to English: CILLA Contract purchasing system General field: Tech/Engineering Detailed field: Computers: Software
Source text - Swedish Inledning
Coop avtalssystem, CILLA hanterar inköpsavtal med leverantörer till CIKAB. Genom att systematisera avtalsskrivandet är tanken att skapa enklare och klarare inköpsavtal som kan matchas och jämföras mot leverantörens fakturor så att CIKAB i alla lägen faktureras/får rabatter/bonus enligt ingångna avtal.
CILLA innehåller funktioner för att göra avtalsskrivandet enkelt – med befintliga och nya leverantörer. Nya leverantörer måste vara registrerade som leverantörer för att CILLA ska kunna hitta dem. Tillfälliga/eller udda leverantör kan registreras i CILLA.
Från CILLA kan hela inköpsavtalet hanteras, alla villkor (rabatter, bonus, aktiviteter) kan registreras i CILLA, utskrifter av avtal med bilagor, visning/utskrift av RAS, koppla inlästa dokument till avtal kan göras med hjälp av CILLA.
Upplägget med flikar Huvuduppgifter, Omfattning, Rabatter osv. är hämtat ur befintliga avtalsmallar – för att göra det enkelt att hitta både i utskrivna avtal och i CILLA.
Cilla hanterar avtal för Food/Non Food, Indirekta varor, Externa avtal och EVM.
Förändringar - förbättringar– tillägg Cilla III
Cilla ger varningar till avtalsansvarig för utgående, åldrade och avtal där volymbonus förfaller till fakturering.
När ett avtal sätts om till status underskrivet så ges meddelande till användaren om att det är hög tid att kontakta supply mgmt.
Användare som är avaktiverade visas ej i listningar.
Sortering – i huvudbilden sorteras avtalen på Lev. Namn, väljer man annan sorteringsordning sorteras listan i 2:a hand på Lev.namn.
Prislistor visas i RAS-flik.
Rapportflik, utökade sökmöjligheter.
Sökfunktion för bilagor – kunna söka bilagor och till vilka avtal specifika bilagor är knutna. (Administratörsfunktion).
Scannade avtal – påskrivna avtal kan efter att de scannats in knytas till underskrivna avtal i Cilla. Funktionen kan även användas för att knyta avtal fristående från Cilla till leverantör. Scannade avtal är ett tillägg till befintliga funktioner (Ladda upp och koppla dokument).
Skapa leverantörer som ej finns i COOPS system.
Obetingad bonus – med manuell hantering av efterfakturering.
Utskriftsmall – Sve_Specialavtal_RAM_mall har lagts till – används i samband med att avtal knyts till leverantörer som COOP är ombud för.
Logistik avtal – helt omgjord jfrt med tidigare, stöd för olika villkor för färskt, torrt, fryst och nonfood.
EVM-avtal, stöd för EVM-avtal en ny avtalstyp för att hantera dessa avtal.
Ny meny – för att frigöra mer utrymme för sidorna som hör till Cilla
Manualen
Denna manual är uppdelad i två delar en övergripande del där flödet i CILLA beskrivs och en del där varje funktion beskrivs mer ingående och förklarat. Stamford Consult AB, 556413-4939 Sidan 5 av 44 Tel 054-13 79 90
Övergripande om CILLA
Avtalen kan bearbetas tills man lägger dem i status –underskrivet- man kan m.a.o lägga till och ta bort information i avtalet fram till och med att man lägger avtalet i status –underskrivet-.
När man flyttar sig mellan flikarna bör man spara. Om man ligger i redigeringsläge i huvuduppgifter är övriga delar av systemet låst tills man avbryter eller sparar.
Informationen som CILLA arbetar med artiklar, subkategorier, kategorier kommer från URF-databasen som uppdateras dagligen. Jobbar man med en ny leverantör eller lägger till kategorier/subkategorier för en befintlig leverantör där ännu inga artiklar finns blir funktionaliteten begränsad till att hantera kategorier och subkategorier (artikelrabatt kan inte skapas eftersom artiklarna inte är kända).
Inloggning
CILLA är ett system som nås via webbläsaren (Internet Explorer).
Inloggning sker på följande adress .
Använd den user och password du fått av systemansvarig för att logga in i systemet.
Notera att systemet bara nås inom COOP – man kommer inte åt systemet utifrån.
På vänster sida efter inloggning i CILLA finns menyerna, efterhand som CILLA växer kommer dessa menyer att utökas. Vid klick på ”MENY” så öppnas menyn.
Translation - English Introduction
Coop contract system, CILLA handles purchasing contracts with suppliers to CIKAB. By systemizing contract writing, the idea is to create simpler and clearer purchasing agreements that can be matched with and compared to the supplier’s invoices, allowing CIKAB at all times to be invoiced/given rebates/bonuses in accordance with entered contracts.
CILLA contains functions to simplify contract writing— with existing and new suppliers. New suppliers must be registered as suppliers to allow for CILLA to find them. Temporary/ or odd suppliers can be registered in CILLA.
From CILLA the purchasing agreement can be handled in its entirety. All conditions (rebates, bonuses, activities) can be registered in CILLA. Printouts of contracts with attachments, viewing/printout of RAS, linking read documents to contracts, can all be done with the aid of CILLA.
The arrangement of tabs Main data, Coverage, Rebates and so forth is gathered from existing contract templates. This is done to simplify navigating both printed contracts and CILLA.
CILLA handles agreements for Food/Non Food, Indirect goods, External contracts and EVM.
Changes – improvements – additions CILLA III
CILLA issues warnings to the contract manager for expiring, expired, and contracts where the volume bonus is due for invoice. When a contract status is changed to signed a message is displayed to the user that it is time to contact supply management.
Users having been deactivated are not shown in listings.
Sorting – in the main image contracts are sorted according to Sup. name. If another sorting order the list is sorted in 2nd hand according to Sup. name.
Price lists are shown in the RAS-tab.
Report tab, expanded search possibilities.
Search function for attachments – enabling searches for attachments and to which contracts specific attachments are linked.
(Administrator function)
Scanned contracts – signed contracts can, after being scanned, be linked to signed contracts in CILLA. The function can also be used to link contracts independent from CILLA to supplier. Scanned contracts is an add-on to existing functions. (Upload and connect document).
Create suppliers which are non-existing in COOPS system.
Unconditional bonus – with manual handling of post-invoicing.
Printout template – Sve_Specialavtal_RAM_mall has been added – to be used in conjunction with a contract being connected to suppliers which COOP are a representative of.
Logistics contract – completely reworked from before, support for various conditions for fresh, dry, frozen and non-food items.
EVM-contract, support for EVM-contract: a new type of contract, to manage these contracts.
New menu – to free up more space for the pages belonging to CILLA.
Manual
This manual is divided into two parts. One part where the flow in CILLA is described and one part where each function is described in detail more thoroughly. Stamford Consult AB, 556413-4939 Page 5 of 44 Ph. 054-13 79 90
Overarching about CILLA
Contracts can be processed until you attribute the status –signed- to them. In other words it is possible to add to and withdraw information from the contract until such a time that the contract has been attributed the status –signed-.
When navigating between tabs it is advisable to save. If you are in edit mode in main data other parts of the system are locked until you cancel or save.
The information CILLA works with: articles, subcategories, and categories come from the URF-database which is updated daily. If you work with a new supplier, or add categories/subcategories for an existing supplier that does not yet have articles available, the functionality with be limited to handling categories and subcategories (article rebate cannot be created as the articles are unknown).
Login
CILLA is a system accessed via Web browser (Internet Explorer).
Login is done at the following address.
Utilize the username and password obtained from the system administrator to log in to the system.
Please note that the system can only be reached from within COOP – it is not possible to access the system externally.
After login to CILLA the menus are located on the left side. As CILLA grows these menus will be expanded. By clicking on “MENU” the menu will open.
Swedish to English: Business Logic General field: Tech/Engineering Detailed field: Business/Commerce (general)
Source text - Swedish Contents
Inledning 3
Uppslagning av kund via MedMera-ID 4
Inläsning till kort-dimension 4
Översiktlig modell BI-CRM 4
Hantera flera loyaltyrader för varje kvitto 5
Relation mellan betalning och kund 6
Hantering av kunder med temporära MM-kort 7
Relation mellan betalning och produkt_avtal 8
Uppslagning i tabeller från BI-Ekonomi 9
Historiska butiksförändringar 10
Historiska kundförändringar 10
Postnummer 11
Inledning
I detta dokument beskrivs affärslogiken som relateras till BI-CRM på MedMera. Syftet med dokumentet är att beskriva bakgrunden till modelleringsbeslut och laddningslogik och målgruppen är i första hand utvecklare med även slutanvändare kan ha nytta av detta.
Uppslagning av kund via MedMera-ID
2008-03-17 till 20 genomfördes en ändring i KundMaster, så att kundmasterns kund-ID inte längre var kopplat till kundernas MedMera-ID. Istället finns MedMera-ID som ExternalID i Engagemang-kopplingen. För att gå runt detta och göra alla nödvändiga uppslagningar enkelt tillgängliga skapades vyn v_dCustomer_with_MMID.
Då data från Card och därmed KundMaster saknar engagemangskopplingar för vissa kunder, och vissa kunder kan förekomma med samma MedMera-ID/ExternalID på två olika KundMaster-kunder, innehåller nämnda vy en del affärslogik för att garantera att det bara finns en gällande kund per MedMera-ID. Dock kan det finnas flera historiska varianter av kunden, helt i linje med gällande SCD2-logik.
Inläsning till kort-dimension
En dimension som innehåller kort laddas i BI-CRM.
Följande poster läses in i dimensionen:
• Alla unika kortnummer i filen CARDS från Kundmastern
• Alla övriga kortnummer i fältet loyalty_card_number i filen loyalty från ODS
• Eventuellt alla övriga kortnummer i fältet payment_means_id i filen payment från ODS.
Två kopplingar mellan receiptPayment och dCard kommer att skapas, en för fältet fältet loyalty_card_number i filen loyalty från ODS (Loyalty link) och en för fältet payment_means_id i filen payment från ODS (Payment link)
Översiktlig modell BI-CRM
Hantera flera loyaltyrader för varje kvitto
Det är inte tillåtet att generera flera loyalty-rader för varje kvitto. Detta kan ändå inträffa när butiker levererar felaktig information till ODS.
Dubbletter i loyalty från ODS innebär att det finns flera rader som har samma kombination av följande fält:
• date_time
• KOSS_id
• terminal_id
• receipt_number
Finns dubbletter kommer BI-CRM endast läsa den av raderna som har lägst värde i fältet sequence_number i tabellen loyalty från ODS
Relation mellan betalning och kund
Här beskrivs hur vi knyter en kund till en betalning.
Informationen som används laddas från ODS och nedan visas en bild över de inblandade tabellerna.
För att hitta en kund till varje betalning används "loyalty link" i bilden ovan, dvs från payment via receipt till loyalty till CARDS-tabellen från kundmastern. I CARDS -tabellen finns ett customer_id. På detta sätt hittar vi kunder för alla kvitton som är kopplade till en kort via lojalitet.
En förutsättning för att det ska gå att entydigt knyta en betalning till en kund är dock att det aldrig finns mer än en rad i loyality för varje kvitto. Finns dubbletter kommer endast en rad behållas, se separat avsnitt.
Det finns dock två fall då denna uppslagning inte ger upphov till någon kund:
• Anonyma köp. Dvs. kvitton där inget lojalitetskort har dragits, då finns ingen rad i loyality-tabellen. I detta fall kommer betalningen kopplas till "Okänd kund" (Vad borde denna heta? "Anonym kund?")
• Köp av ny MM-kund med tillfälligt kort. Denna koppling är mer komplicerad och beskrivs mer utförligt nedan.
Hantering av kunder med temporära MM-kort
När kunder använder temporära kommer inga kunder att hittas. Däremot kommer korten att skapas som "plastposter" och dessa kommer att bli kopplade som lojalitetskort till transaktioner där det temporära kortet använts.
För att i efterhand slå upp rätt kund ska följande logik användas vid varje dags laddning:
1. Leta upp alla transaktioner som uppfyller följande:
o Har ett lojalitetskort som börjar på 600189
o Saknar kund
o Har ett transaktionsdatum under innevarande eller två föregående månader
2. Leta upp alla unika lojalitetskortnummer för dessa transaktioner
3. Använd de sista tio siffrorna i kortnumret för att leta bland kunderna på personnummer.
4. För alla kort som man hittar en kund med matchande personnummer för lägger man till en rad i kort-kundtabellen (fCustomerCardTransaction)
5. Uppdatera kund, hushåll, engagemangskombination och kundattribut i transaktionstabellen (customerKey, householdKey, engagementCombinationKey och customerAttributeKey i fReceiptPayment) för alla transaktioner som uppfyller följande
o Har ett lojalitetskort som börjar på 600189
o Saknar kund
o Har ett transaktionsdatum under innevarande eller två föregående månader
o har en rad i fCustomerCardTransaction
Detta innebär att kunder som kommer in i kundmastern inom två månader efter det att deras första transaktion registrerades kommer att få alla sina transaktioner uppdaterade med rätt kundnummer.
Relation mellan betalning och produkt_avtal
I detta avsnitt beskrivs hur en betalning relateras till en produkt_avtal i BI-CRM. Syftet är att för varje betalning specificera viken MedMera-betalprodukt som har använts. Relationen går enligt följande kedja:
Betalning -> kort -> konto -> produkt_avtal
Från BI-Ekonomi (som i sin tur läser från Card) hämtas informationen om till vilket konto ett specifikt kort hör och vilket produkt_avtal som det kontot avser. För att knyta en betalning till ett kort i denna relationskedja behövs dock viss logik appliceras när data hämtas från ODS till BI-CRM.
Del av datamodell från ODS avseende betalningar och kort
I bilden ovan visas en del av modellen för betalningar från ODS. Där kan vi se att det potentiellt finns två kort kopplade till samma betalnig, via Payment Link eller Loyalty Link. I tabellen nedan beskrivs ett antal fall med olika kombinationer av betalningssätt.
Fall Kopplingar till kort i ODS Koppling som ska användas för att slå upp kort för betalning
Betalar kontant och/eller med främmande kort Ingen Ingen
Betalar kontant och/eller med främmande kort och drar MedMera-Kort Loyalty Link (MedMera-kort) Loyalty Link (MedMera-kort)
Betalar med MedMera-kort Payment Link (MedMera-kort)
Loyalty Link (MedMera-kort) Payment Link (MedMera-kort)
Betalar del med MedMera-kort och del med MedMera-Visa Payment 1: Payment Link (MedMera-kort)
Payment 2: Payment Link (MedMera-Visa)
Loyalty Link (Något av korten) Payment 1: Payment Link (MedMera-kort)
Payment 2: Payment Link (MedMera-Visa)
Betalar del med främmande kort och del med MedMera-kort Payment 2: Payment Link (MedMera-kort)
Loyalty Link (MedMera-kort) Payment 1: Loyalty Link (MedMera-kort)
Payment 2: Payment Link (MedMera-kort)
Regeln som används för att avgöra vilket kort som ska användas för att hitta kontot och därmed betalprodukten som användes är alltså, i prioriteringsordning:
1. Om betalningen har en Payment-link, använd detta kort
2. Om det finns en Loyalty Link, använd detta kort
3. Inget kort
Ett viktigt antagande ligger till grund för denna logik, det är att det inte finns fler än en rad i loyalty för varje kvitto.
Uppslagning i tabeller från BI-Ekonomi
Historiska butiksförändringar
Den historiska laddningen av data från MMDW till BI-CRM har gjort uppslag mot en butiksdimension som laddats från organisationsmastern. Denna information innehåller endast butiksförändringar från och med december 2007.
Om butiksnummer (storeId) har återanvänts under de senaste tre åren innebär det eventuellt att vissa historiska transaktioner har kopplats till fel butik. För att utreda om det är fallet har en analys gjord avseende KossID och storeID. Om ett KossID alltid varit kopplat till samma storeID bör det inte finnas någon risk för detta.
Historiska kundförändringar
Kund är av "slowly changing dimension typ 2" och är av prestanda/volymskäl snowflakead med tre transaktionstabeller som kopplar ihop kund med andra tabeller. Transaktionstabellerna har liksom kund en begränsad giltighetstid.
För varje kund-key finns godtydligt många rader i fCustomerCardTransaction och fCustomerEngagementTransaction. I fCustomerTransaction finns endast en rad med isCurrent = 1 och godtyckligt antal "gamla" rader med isCurrent = 0.
Kundtransaktion kopplar en kund till en nyckel för en kombination av engagemang och en nyckel för en kombination av kundattribut som gäller vid ett visst tillfälle. Så fort ett engagemang eller ett kundattribut ändras skapas en ny rad i kundtransaktionen.
För att ladda detta korrekt loopar kundladdningen över alla datum som förekommer i laddningens indata. För varje datumvarv laddas alla kundrelaterade tabeller med data för det datumet.
Snowflake kombinerat med SCD2 medför vissa extra moment: om det finns en rad i en transaktionstabell där en foreign key pekar på en kund eller ett hushåll som inte längre har isCurrent = 1 så skall transaktionsraden kopieras och den nya raden peka till nu gällande poster i kund/hushållstabellerna.
För att inte leta igenom och verifiera alla rader i alla transaktionstabeller varje gång utgår detta steg istället från de kund- och hushålls-ID som finns i aktuella stagingtabeller. För de IDn som förekommer i staging görs en uppslagning, isCurrent-verifiering och hantering av eventuella SCD2-påverkade rader i transaktionstabellerna.
Tabeller som p.g.a. foreign keys hanteras på detta sätt är:
• fcustomerTransaction (refererar till customerKey, householdKey)
• fCustomerCardTransaction (refererar till customerKey)
• fCustomerEngagementTransaction (refererar till customerKey)
• dHousehold (refererar till customerKey)
Se även dokumentet "BICRM-Kundladdning detaljförklaring.doc"
Postnummer
Tabellen dPostalCode laddas i tre steg:
1. I första hand från rBD_POSTALCODEAREAS vilken innehåller mer korrekta postadressnamn än de som finns i rBD_POSTALCODE.
2. Finns det efter steg 1 kvar några postnummer i rBD_POSTALCODE som inte lagts in i dPostalcode så läggs postnumren in, ihop med de fält som går att ladda från rBD_POSTALCODE, övriga fält får "Okänd" och -1 som värden. För dessa postnummer sätts även "postalCodeCityName" till Postens postadressnamn, t.e.x "Solna, BP/Solna Strand" istället för officiella "SOLNA". Landskoden i dessa fall blir alltid SE eftersom källan endast innehåller Sverige.
3. När nya kundadresser kommer in verifieras dessa kunders postnummer mot dPostalCode. Om postnumret saknas läggs en rad in i dPostalCode med kundens postnummer, landskod och postadress, övriga fält får "Okänd" och -1.
Translation - English Contents
Introduction 3
Browsing customer via MedMera ID 4
Reading to ”kort-dimension” (Card Dimension) 4
Summary model BI-CRM 4
Handling of multilpe loyalty rows for each receipt 5
Linkage between payment and customer 6
Handling of customers with temporary MM-cards 7
Linkage between payment and produkt_avtal 8
Browsing tables from BI Economy 9
Historical store changes 10
Historical customer changes 10
Postal code 11
Introduction
In this document is a description of the business logic related to BI-CRM on MedMera. The purpose is to describe the background of the modelling decisions and loading logic. The target group is first and foremost developers, but end users may also benefit.
Browsing customer via MedMera-ID
2008-03-17 to 20 a change was made in ”KundMaster” (Customer Master), so that the customer masters customer-ID is no longer linked to the customers MedMera-ID. Rather MedMera-ID exists as ExternalID in the “Engagemang-kopplingen” (Engagement connection). To circumvent this and make all the necessary browsing easily available the view vyn v_dCustomer_with_MMID was created.
When data from Card, and in turn ”KundMaster” (Customer master) is missing, engagement connections for certain customers with the same MedMera-ID/ExternalID may occur for two different KundMaster customers. The view will contain some business logic to guarantee that there is only one valid customer per MedMera-ID. However, there may be multiple historical variants of the customer, in line with valid SCD2 logic.
Reading to “kort-dimension” (Card Dimension)
A dimension containing cards is loaded in BI-CRM.
The following posts are read into the dimension:
• All unique card numbers in the file CARDS from the “Kundmastern” (Customer Master)
• All other card numbers in the field loyalty_card_number in the file loyalty from ODS
• If necessary all remaining card numbers in the field payment_means_id in the file payment from ODS.
Two connections between receiptPayment and dCard will be created. One for the field loyalty_card_number in the file loyalty from ODS (Loyalty link) and one for the field payment_means_id in the file payment from ODS (Payment link)
Summary model BI-CRM
Handling of multiple loyalty rows for each receipt
It is not permissible to generate multiple loyalty rows for each receipt. This may still occur when stores deliver faulty information to ODS.
Duplicates in loyalty from ODS signifies there are multiple rows with the same combination of the following fields:
• date_time
• KOSS_id
• terminal_id
• receipt_number
If there are duplicates, BI-CRM will only read the row with the lowest value in the sequence_number field in loyalty table from ODS.
Linkage between payment and customer
Here we describe how we link a customer with a payment.
The information used is loaded from ODS. Below is an image of the involved tables.
To find a customer for every payment a "loyalty link" is used, as in the image above, i.e. from payment via receipt to loyalty to CARDS-table from the customer master. In the CARDS -table there is a customer_id. In this way we find customers for all the receipts connected to a card via loyalty.
A requirement to clearly connect a payment to a customer is that there is never more than one row in loyalty for every receipt. If there are duplicates only one row will be kept. See separate part.
However, there are two cases when this browsing does not give a source customer:
• Anonymous purchases. i.e. receipts where no loyalty card has been used, thus no row in the loyalty table. In this case the payment will be linked to an "Okänd kund" (unknown customer) (What should this be called? "Anonym kund?"(Anonymous customer))
• Purchase by a new MM-customer with a temporary card. This linkage is more complicated and is described in more detail further below.
Handling customers with temporary MM cards.
When customers use temporary cards, no customers will be found. However, the cards will be created as "plastposter" (plastic posts) and these will be connected as loyalty cards to transactions where the temporary card was used.
If order to later find the correct customer the following logic is to be used the daily loadings:
1. Find all transactions that fit the following:
o Have a loyalty card starting with 600189
o Missing customer
o Have a transaction date under the current or two previous months
2. Find all unique loyalty card numbers for these transactions.
3. Use the last 10 digits of the card number to search amongst customers according to personal code number.
4. For all cards, where a customer with matching personal code number are found, a row is added in the card customer table. (fCustomerCardTransaction)
5. Update customer, household, engagement combination and customer attribute in the transaction table (customerKey, householdKey, engagementCombinationKey and customerAttributeKey in fReceiptPayment) for all transactions fitting the following
o Has a loyalty card starting with 600189
o Missing customer
o Has a transaction date from the current or two previous months
o Has a row in fCustomerCardTransaction
This means, customers entering the customer master within two months after their previous transaction was registered will have all their first transactions updated with the correct customer number.
Linkage between payment and produkt_avtal
Described in this part is how a payment is linked to produkt_avtal in BI-CRM. The purpose is to specify which MedMera pay product is used for each payment. The linking proceeds according to the following flow:
Payment -> card -> account -> produkt_avtal
From BI Economy (which in turn reads from Card) information is gathered about which account a specific card belongs to, and which produkt_avtal the account refers to. To link a payment to a card in this chain, certain logic needs to be applied when data is gathered from ODS to BI-CRM.
Part of the data model from ODS regarding payments and cards
In the image above part of the model for payments from ODS is shown. We can see there are potentially two cards linked to the same payment, via Payment Link or Loyalty Link. The table below describes another case with different combinations methods of payment.
Case Linkages to cards in ODS Linkage to be used to find cards for payment.
Cash payment and/or with unknown card None None
Cash payment and/or with unknown card and swipe MedMera-Card Loyalty Link (MedMera-card) Loyalty Link (MedMera-card)
Pays with MedMera-card Payment Link (MedMera-card)
Loyalty Link (MedMera-card) Payment Link (MedMera-card)
Pays part with MedMera-card and part with MedMera-Visa Payment 1: Payment Link (MedMera-card)
Payment 2: Payment Link (MedMera-Visa)
Loyalty Link (Some of the cards) Payment 1: Payment Link (MedMera-card)
Payment 2: Payment Link (MedMera-Visa)
Pays part with unknown card and part with MedMera-card Payment 2: Payment Link (MedMera-card)
Loyalty Link (MedMera-card) Payment 1: Loyalty Link (MedMera-card)
Payment 2: Payment Link (MedMera-card)
The rule used to decide which card is used to find the account, and thus the point of payment, is in order of priority:
1. If the payment has a Payment-link, use this card
2. If there is a Loyalty Link, use this card
3. No card
An important assumption lies as base for this logic: there is not more than one row in loyalty for each receipt.
Browsing tables from BI Economy
Historical store changes
The historical loading of data from MMDW to BI-CRM has been browsing against the store dimension loaded from the organisation master. This information only contains store changes made from December 2007 and onwards.
If the store number (storeID) has been re-used during the last three years, it means that certain historical transactions have been connected with the wrong store. To determine if this is the case an analysis is done regarding KossID and storeID. If a KossID has always been linked to the same storeID there should not be any risk of errors having been made.
Historical customer changes
Customer is of "slowly changing dimension type 2" and is by performance/volume reasons snowflaked with three transaction tables linked with customers and other tables. Transaction tables have, like customer, a limited period of validity.
For every customer-key there are many arbitrary rows in fCustomerCardTransaction and fCustomerEngagementTransaction. In fCustomerTransaction there is only one row where isCurrent = 1 and arbitrary number of "old" rows with isCurrent = 0.
Customer transaction connects a customer to a key for a combination of engagements and a key for a combination of customer attributes valid at a certain occasion. As soon as an engagement or a customer attribute is changed, a new row in the customer transaction is created.
To load this correctly the customer loading is looped over all occurring dates in the indata for the loading. For every date round, all customer related tables with data for the date are loaded.
Snowflake combined with SCD2 carries with it a few extra phases: If there is a row in a transaction table where a foreign key points at a customer or a household that no longer has isCurrent = 1 then the transaction row is to be copied and the new row point to currently valid posts in the customer/household tables
In order not to search through and verify all rows of all transaction tables every time, this step starts from the customer and household ID’s existing in the current staging tables. For the ID’s occurring in staging a browse is done, isCurrent verification and handling of possible SCD2 influenced rows in the transaction tables.
Tables which because of foreign keys are handled in this way are:
• fcustomerTransaction (refers to customerKey, householdKey)
• fCustomerCardTransaction (refers to customerKey)
• fCustomerEngagementTransaction (refers to customerKey)
• dHousehold (refers to customerKey)
Also see the document "BICRM-Kundladdning detaljförklaring.doc"
Postal code
The table dPostalCode is loaded in three steps:
1. Firstly from rBD_POSTALCODEAREAS which contains more accurate postal code names than those from rBD_POSTALCODE.
2. If there are any postal codes left after step 1 in rBD_POSTALCODE that haven’t been added in dPostalcode the postal codes are added, together with the fields loadable from rBD_POSTALCODE. The remaining fields get "Okänd" (unknown) and -1 as values. For these postal codes "postalCodeCityName" are also added to the Posts postal address names, i.e. "Solna, BP/Solna Strand" instead of official "SOLNA". The country code in this case is SE as the source only contains Sweden.
3. When new customer addresses arrive their postal codes are verified against dPostalCode. If the postal code is missing a row is added in dPostalCode with the customer’s postal code, country code, and postal address. Any remaining fields get "Okänd" (unknown) and -1.
Swedish to English: Strategic Pricing General field: Bus/Financial Detailed field: Business/Commerce (general)
Source text - Swedish Tips som kan underlätta arbetet i LRO Strategic Pricing
Söka efter artikel i Strategic Pricing. 2
Ersättningstecknen ? och % 2
Sök på Artikelnummer (Stock Item i LRO) 4
Sök på POS-kod 4
Sök via artikelhierarki 5
Söka efter artikel i Strategic Pricing.
Det finns många sätt att hitta artiklar på i Strategic Pricing. Detta dokument exemplifierar några av dessa.
Ersättningstecknen ? och %
Ersättningstecken kan användas för att ersätta noll eller flera tecken. Antingen för att någon del av namnet eller numret är okänt eller för att ge flera rader som resultat. I Strategic Pricing kan ersättningstecken användas både i nummer- och textfält.
Tecknet ’?’ ersätter exakt ett tecken och är användbart då man vill avgränsa en sökning.
Exempel på sökning med ?:
Ovan söker vi efter alla artikelnummer som är 8 siffror långa och börjar med 20172 samt slutar med 00. Sökningen utförs genom att ange ”20172?00” i fältet för artikelnummer.
Observera att 2017200 inte ger en träff i detta fall eftersom det endast innehåller 7 siffror.
Tecknet ’%’ ersätter noll eller flera tecken och ger därför en vidare sökning.
Exempel på sökning med %:
Vi gör samma sökning som tidigare fast nu med % istället.
Sökningen utförs genom att ange ”20172%” i fältet för artikelnummer.
Utöver de 10 artiklar som sökningen med frågetecken gav får vi nu också träff på artikel 2017200
Sök på Artikelnummer (Stock Item i LRO)
En enskild artikels fullständiga artikelnummer anges och systemet returnerar då denna artikel i resultatlistan.
Alternativt kan delar av artikelnumret ersättas med ersättningstecken för att finna fler än ett artikelnummer(se stycket ovan om detta).
Sök på POS-kod
EAN-13 och VNR är de mest användbara men även andra POS-typer kan fungera om det finns registrerat för artikeln.
Exempel på sökning med VNR:
Sök alla artiklar som har VNR som börjar på 242-5103
Sök via artikelhierarki
Klicka på knappen ”Bläddra”
Klicka på plustecknet framför ART HIERARKI och ner till det subsegment som artiklarna finns i. Används allra helst när artiklarna finns kvar i NYA BNR. Fungerar dock också för den ”riktiga” kategorin.
Markera artiklarna genom att amvända CTRL(en och en) eller SHIFT(intervall)
Klicka på ”Välj”
Gå vidare som vanligt
Klicka ev. på knappen Filtera för att söka och lägga till fler artiklar.
Om rutan ”Visa Alla” markeras så innebär inte bara att artiklar utanför användarens behörighetsområde visas, utan också att flera artikelhierarkier visas. Dessa kan användas för att välja artiklar. De artiklar som är i fetstil tillhör användarens behörighetsområde och endast dessa kan vårdas.
Translation - English Tips to simplify work in LRO Strategic Pricing
Searching for an article in Strategic Pricing. 2
Replacement symbols ? and % 2
Search of ”Artikelnummer” (Article number) (Stock Item in LRO) 4
Search by ”POS-kod” (POS-code) 4
Search via ”artikelhierarki” (article hierarchy) 5
Searching for an article in Strategic Pricing.
There are several ways to find articles in Strategic Pricing. This document exemplifies some of these.
Replacement symbols ? and %
Replacement symbols can be used to replace zero or multiple signs. Either because some part of the name or number are unknown or to give several rows as results. In Strategic Pricing replacement signs can be used both in the number- and text-fields.
The symbol ’?’ replaces exactly one symbol and is usable when limiting for a search.
Example of a search with ?:
Above we search for all article numbers 8 digits long beginning with 20172 and finish with 00. The search is performed entering “20172?00” in the article number field.
Observe that 2017200 does not provide hits in this case as it only contains 7 digits.
’%’ replaces zero or more signs and thus provides a further search.
Example of a search with %:
We carry out the same search as earlier but now with % instead.
The search is performed by entering “20172%” in the article number field.
On top of the 10 articles that the search with the question mark found we also get a hit on article 2017200
Search of ”Artikelnummer” (Article number) (Stock Item in LRO)
A single articles’ full article number is provided and the system returns this article in the results list.
Alternatively parts of the article number can be replaces with replacement symbol in order to find more than one article number (regarding this see the section above)
Search by ”POS-kod” (POS-code)
EAN-13 and VNR are the most useful but other POS-types may also work if registered for the article.
Example of a search with VNR:
Search for all articles that have VNR starting with 242-5103
Search via ”artikelhierarki” (article hierarchy)
Click ”Bläddra” (Browse)
Click the plus sign in front of “ART HIERARKI” (article hierarchy) and down to the sub segment where the articles are located. Preferably used when the articles remain in NYA BNR. However, also works for the “real” category.
Highlight the articles by using CTRL(one by one) or SHIFT(interval)
Click ”Välj” (Select/Choose)
Proceed as usual
If needed, click the ”Filtera” (Filter) button to search and add more articles.
If the box ”Visa Alla” (Show all) is selected this does not only mean that articles outside the users access area are shown. More article hierarchies are also shown. These may be used to choose articles. The articles in bold belong to the users access area and only these can be utilized.
More
Less
Experience
Years of experience: 20. Registered at ProZ.com: Apr 2013.
Portfolio