Merk
Tilgang til denne siden krever autorisasjon. Du kan prøve å logge på eller endre kataloger.
Tilgang til denne siden krever autorisasjon. Du kan prøve å endre kataloger.
Notat
Retail Interest Group etter Dynamics 365 Commerce har flyttet fra Yammer til Viva Engage. Hvis du ikke har tilgang til det nye Viva Engage-fellesskapet, kan du fylle ut dette skjemaet (https://aka.ms/JoinD365commerceVivaEngageCommunity) som skal legges til og holde deg engasjert i de siste diskusjonene.
Denne artikkelen forklarer hvordan du starter returer for kontant-og-bære-transaksjoner eller kundeordrer i Microsoft Dynamics 365 Commerce-salgssted (POS).
Notat
I Commerce versjon 10.0.20 og nyere er en ny funksjon kalt Unified return processing experience i POS tilgjengelig. Denne funksjonen gir en mer konsekvent og enhetlig returprosess i POS, uavhengig av transaksjonstypen (hentesalgstransaksjon eller kundeordre) eller den opprinnelige kanalen ordren ble opprettet i. Aktiver denne nye funksjonen for å forbedre den generelle påliteligheten av returbehandling gjennom POS.
Når du har aktivert funksjonen, kan du ikke deaktivere den.
Behandle returer ved hjelp av returtransaksjonsoperasjonen
Legg til returtransaksjonsoperasjonen i pos-skjermoppsettet. I versjoner før utgivelsen av Commerce versjon 10.0.20 støtter returtransaksjonsoperasjonen bare behandling av returer for hentesalgstransaksjoner på riktig måte. Etter at du har aktivert funksjonen Enhetlig returbehandling i POS i utgivelsen av Commerce versjon 10.0.20 eller nyere, støtter også returtransaksjonsoperasjonen behandling av returer som stammer fra kundeordrer, for eksempel ordrer for henting eller hjemlevering som allerede er fakturert.
Fra returtransaksjonsoperasjonen kan brukere søke etter en hentesalgstransaksjon eller kundeordre de kan returnere mot, ved å angi et av følgende fire søkekriterier. Brukere kan angi disse kriteriene ved hjelp av et enhetstastatur, skjermtastatur eller en strekkodeskanner.
- Mottaks-ID
- Ordrenummer
- Kanalreferanse-ID (også kalt ordrebekreftelses-ID)
- Faktura-ID
Hvis en transaksjon eller ordre samsvarer med søkekriteriene, vises siden For returnerbare produkter . Brukere kan angi elementene de skal returnere. De kan også angi returantall og årsakskoder.
For hver ordrelinje i listen over produkter som kan returneres, viser POS informasjon om det opprinnelige bestillingsantallet og antallet fra alle returer som er behandlet tidligere. Returantallet som en bruker angir for en ordrelinje, må være mindre enn eller lik verdien i feltet Tilgjengelig for retur.
Hvis en bruker har det fysiske produktet under returbehandling og produktet har en strekkode, kan brukeren skanne strekkoden for å registrere returen. Hver skanning av strekkoden øker returantallet med én vare. Hvis strekkodeetiketten imidlertid har et innebygd antall, angis dette antallet i Returnerer nå-feltet.
Brukere kan også velge varer manuelt på siden Produkter som kan returneres og deretter oppdatere Returnerer nå-feltet ved hjelp av detaljruten.
Hvis det største tilgjengelige Returnerer nå-antallet angis for en transaksjon, kan brukeren velge Velg alle-operasjonen på POS-applinjen for å angi maksimalt antall som kan returneres på alle linjer.
For hver linje som har et Returnerer nå-antall, må brukeren velge en returårsakskode ved hjelp av detaljpanelet. Når det gjelder returer av hentesalgstransaksjoner, konfigureres returårsakskodene som informasjonskoder i butikkens funksjonalitetsprofil. Når det gjelder returer av kundeordrer, konfigureres returårsakskodene på siden Koder for returårsaker i Dynamics 365 Commerce Headquarters.
Når returantallet og årsakskoden er angitt for hvert element som må returneres, kan brukeren velge returoperasjonen på pos-applinjen for å fortsette behandlingen. Transaksjonssiden for salgssted vises, der de returnerte elementene som brukeren valgte på den forrige siden, legges til i handlekurven. Returnerer nå-antallene for varene vises som negative antallslinjer på transaksjonen, og den totale refunderingen beregnes.
Forbedringer for brukeropplevelse
Hvis det er mer enn ett element å returnere i en transaksjon, og butikkmedarbeideren velger flere elementer som skal returneres, viser returrutenettet bare den siste valgte raden som merket. Denne virkemåten kan forvirre tilknyttingen og få dem til å tro at bare ett enkelt element er valgt. Du kan begrense dette problemet fra og med Commerce versjon 10.0.36 ved å aktivere funksjonen Forbedret brukeropplevelse for salgsstedsreturer. Denne funksjonen gjør rutenettet for returprodukter til et flervalgsnett hvor brukere kan velge og slette utvalget av returprodukter. Flervalgsrutenettet åpner automatisk dialogboksen for returårsak. Derfor kreves det færre trinn for å åpne og lukke dialogboksen for returårsak. Denne funksjonen innfører også Hopp over salgsfakturavalg under retur konfigurasjonen i salgsstedsfunksjonalitetsprofilen. Hvis denne konfigurasjonen er aktivert, kombinerer systemet alle returprodukter fra en ordre, uavhengig av fakturaen de ble oppfylt fra. Derfor reduseres antall trinn kasserere må utføre, siden de ikke trenger å finne og velge riktig faktura for å returnere en vare.
Forbedret brukeropplevelse for pos returnerer funksjonsforbedringer er tilbakeportert til Commerce versjoner 10.0.33 til 10.0.35, men for disse versjonene må du aktivere forbedringene ved å oppdatere konfigurasjonsfiler i sandkassen, utvikling eller testmiljøer, og deretter kontakte Microsoft for å aktivere dem i produksjon. For interne miljøer endrer du bin\CommerceRuntime.config filen under den fysiske banen til Detaljhandelserver for å legge til "FeatureState.Dynamics.AX.Application.RetailUnifiedReturnUXImprovementFeature" value="true" innstillingene og "FeatureState.Dynamics.AX.Application.RetailSkipInvoiceSelectionDuringReturnFlight" value="true" . Hvis du ikke vil hoppe over fakturavalgvisningen, lar du være å legge til den andre innstillingen i konfigurasjonsfilen.
Andre returalternativer i POS
Brukere kan legge til linjer i en returtransaksjon hvis de oppretter en bytteordre. Brukere kan legge til flere returelementer i en returtransaksjon ved hjelp av returproduktoperasjonen for en valgt salgslinje for positivt antall som operasjonen allerede har lagt til.
Notat
Returprodukt-operasjonen i salgssted gir ingen validering mot opprinnelige transaksjoner, og lar ethvert produkt returneres. Microsoft anbefaler at du bare tillater autoriserte brukere å utføre denne operasjonen, eller fremtvinge at en overordnet overstyrer er nødvendig.
Når funksjonen Enhetlig returbehandling i POS er aktivert, kan brukere også bruke Vis journal-operasjonen i POS til å starte en retur for en hentesalgstransaksjon eller kundeordre. De kan deretter velge en transaksjon i journalen og velge Retur-operasjonen på POS-applinjen. Denne operasjonen er bare tilgjengelig hvis det finnes linjer som kan returneres, i ordren. Den starter den samme brukeropplevelsen som Returtransaksjon-operasjonen.
Brukere kan også bruke operasjonen Tilbakekall ordre i POS til å søke etter og tilbakekalle kundeordrer. (Denne operasjonen kan ikke brukes for hentesalgstransaksjoner). Etter at en kundeordre er valgt i dette tilfellet, kan Retur-operasjonen på POS-applinjen brukes til å starte en retur for kundeordren. Denne operasjonen er bare tilgjengelig hvis det finnes linjer som kan returneres, i ordren. Den starter den samme brukeropplevelsen som operasjonen Returtransaksjon eller Vis journal.
Hvis en refundering forfaller ved kassen, kan du konfigurere betalingspolicyer for refundering som begrenser betalingsmetodene som brukes til å refundere kunder. Hvis en opprinnelig transaksjon ble betalt med et kredittkort, avhengig av betalingsprosessoren og systemkonfigurasjonen, kan brukerne utstede en refundering til det opprinnelige kortet. I dette tilfellet kan refunderingen behandles uten at kunden må bruke kredittkortet på nytt på, siden det opprinnelige betalingstokenet brukes til å utstede refunderingen.
Returordrer posteres til Commerce Headquarters som salgsordrer
Når funksjonen Enhetlig returbehandling i POS er aktivert, skrives alle returer som opprettes i POS, til Commerce Headquarters som salgsordrer med negative linjer. I utgivelser før Commerce versjon 10.0.20 kan brukere velge om returordrer skal posteres som salgsordrer med negative linjer, eller om de skal være returordrer som opprettes via autorisasjonsprosessen for retur av materiell (ARM).
Alternativet for å bruke RMA-prosessen til å opprette returer i pos er avskrevet i den enhetlige returbehandlingsopplevelsen i pos-funksjonen . Etter at denne funksjonen er aktivert, opprettes alle returer som salgsordrer med negative linjer.
Returner behandlingsforbedringer når forbindelsen til hovedkvarteret er nede
I de fleste tilfeller, når du behandler en retur i POS, prøver systemet å foreta et sanntidstjeneste (RTS) kall til Handelshovedkvarteret for å validere gjeldende antall som er tilgjengelige for retur. Denne valideringen bidrar til å forhindre svindelscenarioer der en kunde prøver å returnere den samme varen flere steder.
Hvis du vil håndtere situasjoner der nettverks- eller tilkoblingsproblemer hindrer RTS-kallet, synkroniserer en prosess regelmessig returantallsdata fra Handelshovedkvarteret til en butikkkanaldatabase. Denne retursporingen på kanalsiden bidrar til å sikre at tilgjengelige returantall som vises i pos, er rimelig nøyaktige, selv når tilkoblingen til hovedkvarteret ikke er tilgjengelig. Den sikrer også at POS kan fortsette å validere informasjonen på kanalsiden for å bidra til å forhindre falske returer. Hvis du vil bidra til å minimere sannsynligheten for at den samme varen returneres mer enn én gang, planlegg batch-jobben Oppdater returantall i commerce-hovedkontoret, slik at den kjører ofte. Kjør denne jobben med samme frekvens som P-jobben som henter nye transaksjoner fra Handelskanaler til handelshovedkvarteret.
Oppdater jobben for returkvantiteter beregner antallet som er tilgjengelig for retur for alle salgsordrer som finnes i Commerce Center. Du må sende dataene som jobben beregner til kanaldatabaser, slik at butikkkanalene kan oppdateres. Bruk returmengder (1200) distribusjonsjobb for dette formålet. Siden data om antallet som kan returneres, synkroniseres fra Commerce Headquarters hvis en retur behandles i POS, men serviceoppkallet i sanntid ikke kan utføres, kan POS bruke returinformasjonen på kanalsiden til å validere antallene som er Tilgjengelig for retur for en gitt salgslinje.
Når serviceoppkall i sanntid ikke kan utføres og POS bruker data på kanalsiden til returvalidering, får brukerne en advarsel om at de oppretter en «frakoblet» retur. Derfor er de klar over at tilgjengelig for returantall som vises i pos, kan være utdatert og ikke lenger nøyaktig, avhengig av når jobben for returantall for oppdatering sist behandlet og synkronisert til kanalen.
En kunde har for eksempel nylig behandlet en retur for en ordrelinje i en annen kanal, men dataene er ennå ikke synkronisert til kanaldatabasene gjennom jobben For oppdateringsreturantall . Kunden går deretter til en annen butikk og prøver å returnere den samme varen på nytt. Hvis butikken i dette tilfellet ikke kan foreta et serviceoppkall i sanntid til Commerce headquarters for å hente returdata i sanntid, tillater salgsstedet at varen returneres igjen. Brukeren blir imidlertid varslet om at informasjonen som brukes til å validere returen, kan være utdatert. Meldingen som brukeren mottar, er bare en advarsel. Den forhindrer ikke brukeren fra å fortsette med behandling av returen.
Hvis informasjonen på kanalsiden av en eller annen årsak ikke er oppdatert og en retur behandles for et antall som overskrider det faktiske antallet som er Tilgjengelig for retur, genereres kanskje en feil når utdragspostering kjøres for å opprette transaksjonen i Commerce Headquarters.
Frakoblet behandling av returer
Når salgsstedet er frakoblet og ikke kan koble til Commerce Scale Unit (CSU), er returalternativene begrenset. Bare transaksjoner du opprettet frakoblet, og som fremdeles er tilgjengelige i den frakoblede databasen, kan returneres frakoblet. Hvis du opprettet en transaksjon i frakoblet modus, men pos gikk tilkoblet før forsøket på å returnere transaksjonen, viser systemet en feilmelding. Denne feilmeldingen sier at operasjonen ikke er tilgjengelig i frakoblet modus fordi systemet sendte den opprinnelige transaksjonen til den elektroniske databasen, og at transaksjonen kan returneres fra en annen POS-enhet (noe som kan føre til overretur).
Notat
Når funksjonen Enhetlig returbehandling i POS er aktivert, blir nye valgfrie funksjoner som støtter validering av serialiserte produktreturer, tilgjengelige. Hvis du vil ha mer informasjon, kan du se Returnere serienummerkontrollerte produkter i Point of Sale (POS).
Versjonsdetaljer
Listen nedenfor inneholder minimumskravene for versjon for de ulike komponentene.
- Commerce Headquarters: versjon 10.0.20
- Commerce Scale Unit (CSU): versjon 9.30
- Point of Sale (POS): versjon 9.30
Aktiver riktig avgiftsberegning for returer med delvis antall
Denne funksjonen sikrer at når en ordre returneres ved hjelp av flere fakturaer, er avgiftene lik avgiftsbeløpet som opprinnelig ble belastet.
- I arbeidsområdet Funksjonsbehandling søker du etter Aktiver riktig avgiftsberegning for returer med delvis antall.
- Velg funksjonen Aktiver riktig avgiftsberegning for returer med delvis antall og velg deretter Aktiver.
Definere returlokasjoner for detaljhandelbutikker
I Commerce kan du konfigurere returlokasjoner som er basert på infokoder for detaljhandel og årsakskoder for salg og markedsføring. Når kunder returnerer kjøp, indikerer selgere ofte årsaken til returen. Du kan angi at returnerte produkter skal gå til forskjellige returplasseringer på lageret, basert på informasjonskoder og årsakskoder som kasserere velger i pos-registeret.
En kunde returnerer for eksempel et defekt produkt, og selgeren behandler returtransaksjonen. Når Retail POS viser informasjonskoden for returer, velger selgeren delkoden for mangelfulle returer. Det returnerte produktet tildeles deretter automatisk til en bestemt returlokasjon.
En returplassering kan være et lager, en plassering i et lager eller til og med en bestemt pall, avhengig av lagerplasseringene organisasjonen har konfigurert. Du kan tildele hver returlokasjon til en eller flere handelsinformasjonskoder og salgs- og markedsføringsårsakskoder.
Forutsetninger
Før du kan konfigurere returplasseringer, kan du konfigurere følgende elementer:
- Koder for detaljhandelinformasjon – Spør i pos-registeret som du har konfigurert i retail-modulen . Hvis du vil ha mer informasjon, kan du se Konfigurer informasjonskoder.
- Årsakskoder for salg og markedsføring – Ledetekster i pos-registeret som du har konfigurert i salgs- og markedsføringsmodulen . Hvis du vil ha mer informasjon, kan du se Definere returårsakskoder.
- Lagerlokasjoner – stedene der beholdningen lagres. Hvis du vil ha mer informasjon, kan du se Konfigurer lagerlokasjoner.
Definer returlokasjoner
Følg disse trinnene for å konfigurere returplasseringer:
Gå til Retail og Commerce > Kanaloppsett > Lagre og velg et lager.
På hurtigfanen Detaljhandel i feltet Standard returlokasjon velger du lagerlokasjonen som skal brukes for returer der informasjonskoder eller årsakskoder ikke er tildelt til returlokasjoner.
I feltet Standard returpall velger du pallen som skal brukes for returer der informasjonskoder eller årsakskoder ikke er tildelt til returlokasjoner.
Gå til Retail og Commerce > Lagerstyring > Returlokasjoner.
Velg Ny for å opprette en returlokasjonspolicy.
Angi et unikt navn og en beskrivelse for returlokasjonen.
Notat
Hvis en nummerserie er konfigurert for returplasseringer, angis navnet automatisk.
I hurtigfanen Generelt angir du Utskriftsetiketter til Ja for å skrive ut etiketter for alle produktene som er tildelt returlokasjoner.
Angi alternativet Blokker lager til Ja for å ta de returnerte produktene på standard returlokasjon, ut fra lageret og hindre at de blir solgt.
Følg denne fremgangsmåten for å tildele bestemte delkoder til returlokasjoner;
- Velg Legg til på hurtigfanen Informasjonskoder for detaljhandel.
- Velg en informasjonskode for returer i Informasjonskode-feltet.
- I Delkode-feltet velger du en delkode for årsaken til returen. Feltet Beskrivelse viser beskrivelsen av den valgte delkoden.
- I Butikk-feltet velger du butikken der informasjonskoden brukes.
- Bruk feltene Lager, Lokasjon og Pall-ID til å angi en returlokasjon. Hvis du vil angi en bestemt lokasjon i en butikk, kan du for eksempel velge en butikk i Butikk-feltet og en lokasjon i Lokasjon-feltet.
- Merk av for Blokker lager-avmerkingsboksen for å ta returnerte varer ut av lageret og hindre at de blir solgt.
Følg denne fremgangsmåten for å tildele bestemte salgs- og markedsføringsårsakskoder til returlokasjoner;
- Velg Legg til i hurtigfanen Årsakskoder for salg og markedsføring.
- Velg en ny årsakskode for returer i feltet Årsakskode. Feltet Beskrivelse viser beskrivelsen av den valgte årsakskoden.
- I Butikk-feltet velger du butikken der årsakskoden brukes.
- Bruk feltene Lager, Lokasjon og Pall-ID til å angi en returlokasjon. Hvis du vil angi en bestemt pall på en lokasjon på et lager, kan du for eksempel velge et lager i Lager-feltet, en lokasjon i Lokasjon-feltet og en pall i Pall-feltet.
- Merk av for Blokker lager-avmerkingsboksen for å ta returnerte varer ut av lageret og hindre at de blir solgt.
Notat
Hvis en returplasseringspolicy brukes for en vare, men returårsaken til at en kasserer velger, ikke samsvarer med noen kode som du angir på hurtigfanen Detaljhandelinformasjonskoder eller Hurtigfanen Salgs- og markedsføringsårsakskoder , går elementet til standard returplassering som du definerer på Lager-siden . I tillegg bestemmer innstillingen for Blokker lager-avmerkingsboksen på hurtigfanen Generelt på siden Returlokasjoner om den returnerte varen skal lagersperres.
Gå til Retail og Commerce > Handelsprodukthierarki.
Velg en returlokasjon i feltet Returlokasjon i hurtigfanen Behandle kategoriegenskaper for lager. Fordi du kan definere flere returplasseringspolicyer for samme lager, bestemmer verdien du velger her, returplasseringspolicyen som brukes.
Kjente problemer
Når du foretar en global retur, gjenspeiler ikke returtransaksjonen tidligere returnerte antall
PROBLEM: Når du foretar en global retur, gjenspeiler ikke returtransaksjonen tidligere returnerte antall.
Dette problemet kan for eksempel oppstå når du utfører følgende trinn.
- Utfør et salg i butikk A av en vare med et antall på fem.
- Utfør en retur på dette salget i butikk A for en mengde på to.
- Hent transaksjonene til headquarters.
- Prøv å gjøre en avkastning på det opprinnelige salget fra trinn 1 i butikk B. Når du har angitt mottaksnummeret, viser salgssted et antall på fem, i stedet for forventet antall på tre.
ÅRSAK: Dette problemet oppstår når flere CSU-er er i bruk. Butikk A bruker én CSU og butikk B en annen CSU i dette eksemplet. Hver CSU har sin egen database, så butikk A har ikke informasjon om transaksjoner som er gjort i butikk B, og butikk B har ikke informasjon om transaksjoner som er gjort i butikk A.
Tiltak for å redusere problemet
Følg disse trinnene for å redusere dette problemet:
- Aktiver funksjonen Forbedret brukeropplevelse for salgsstedsreturer i arbeidsområdet Funksjonsbehandling (Systemadministrasjon > Arbeidsområder > Funksjonsbehandling) i Commerce headquarters.
- Kjør jobben Oppdater returantall med høy frekvens.
- Kjør distribusjonsplanjobben Returantall (1200) for å oppdatere butikkene med høy frekvens.
Når du utfører denne fremgangsmåten, synkroniseres de returnerte antallene mellom CSU-er, og alle returer skal deretter gjenspeile returnerte antall fra andre butikker. Trinn 2 og 3 sikrer at informasjon fra hver CSU ofte sendes til headquarters via RTS-oppkall (Real-time Service).
Tilleggsressurser
Returnere serienummerkontrollerte produkter i Point of Sale (POS)
Koblede refunderinger av tidligere godkjente og bekreftede transaksjoner
Opprette og oppdatere en retur- og refunderingspolicy for en kanal
Visuelle konfigurasjoner av brukergrensesnittet for salgssted