Hvordan OCR-bestillinger for automatisering

En typisk anskaffelsesprosess hos ethvert selskap har flere dokumenter knyttet til seg Fakturaer, Innkjøpsordrer, Følgesedler osv. Denne prosessen har vært et konsekvent fokus for teknologibaserte forbedringer for å redusere overhead. En stor optimalisering har vært gjennom digitalisering av disse dokumentene som har ført til lavere kostnader, raskere behandlingstider og redusert feilprosent. Dette innlegget vil skissere den nåværende toppmoderne teknologien innen OCR-basert datafangst fra disse dokumentene som spesifikt fokuserer på kjøpsordrer.

Uten å gå for mye i detalj ser en typisk arbeidsflyt for anskaffelser slik ut:

1. Kjøper genererer en kjøpsordre
2. Leverandøren genererer en faktura
3. Kjøper genererer et GRN/ordre Kvittering Merknader

Det er noen subtile forskjeller mellom datafangstprosessen og kravene for hvert av disse dokumentene på grunn av forskjellen i informasjonen og strukturen til disse dokumentene. En stor forskjell er også på grunn av hvem som utarbeider dokumentet og som et resultat av hvem som har behov for å digitalisere dokumentet.

3-veis samsvar

En hovedårsak til digitaliseringen er fordi alle disse dokumentene må bekreftes og fortelle en konsistent historie om transaksjonen. Prosessen med bekreftelse av disse 3 dokumentene omtales som 3-veis matching. Behovet for og prosessen med 3-veis matching varierer veldig avhengig av hvem som gjennomfører kampen, kjøperen eller selgeren.

Kjøpers perspektiv:

Kjøperen genererer PO og Kvittering og har denne informasjonen som enkelt kan forenes i programvaren deres. Trenger å matche Faktura til innkjøpsordren og Kvittering. Kjøperen må digitalisere Faktura de andre dokumentene er allerede inne i deres ERP-system.

Det er en rekke grunner til at en kjøper må utføre 3-veis matching:

1. Sikre at kjøpet er autorisert ved å matche en faktura og GRN med en kjøpsordre
2. Sikre at riktig produkt er kjøpt ved å matche på tvers av dokumenter
3. Sikre at riktig mengde godkjent er anskaffet og levert.
4. Sikre at prisen betalt for hvert produkt var godkjent
5. Sikre at riktig leverandør ble valgt og at riktig leverandør til slutt vil få betalt siden de samme produktene kan anskaffes fra forskjellige leverandører
6. Matching av inventar med mengder i GRN for nedstrømskvalitet på data

Selgers perspektiv:

Selgeren genererer Faktura og må sørge for at PO og Kvittering samsvarer med informasjonen i fakturaen. Selgeren må digitalisere innkjøpsordren og kvittere for at fakturaen genereres fra hans ERP.

Selgers behov for 3-veis matching

1. Sjekke om en innkjøpsordre kan oppfylles gitt beholdning i systemet
2. Sikre at varer som sendes samsvarer med produktet som ble forespurt
3. Forsikre deg om at riktig kunde fikk tilsendt det forespurte produktet
4. Sikre at produktene som etterspørres er de som leveres til kunden
5. Sikre at riktige mengder gis til kunden
6. Å sikre at prisen i PO har en bruttomargin som kan oppfylles

---

Ser du etter en AI-basert OCR-løsning for å automatisere innkjøpsordrer? Gi nanonetter™ Intelligent automatiseringsplattform et spinn og legg innkjøpsordrene dine på autopilot!

---

Problemer med manuell 3-veis matching

Siden 3-veis matchingsproblemet er ganske kritisk for begge sider for å møte slutten av kontrakten, er effektivitet og nøyaktighet avgjørende. Dette er imidlertid en ganske høy prosesskostnad fra en rekke perspektiver:

Menneskelige kostnader ved dokumentsporing og feil

1. Det er en rotete prosess, spesielt når PO revideres flere ganger. Det kan være vanskelig å opprettholde riktig versjon av PO. Hvis det ikke gjøres riktig, kan det føre til flere betalinger, levering av ekstra varer osv.
2. Det er flere lignende dokumenter og transaksjoner mellom en hyppig leverandør, kjøper. Disse transaksjonene kan konsumeres.
3. Prosessen kan ikke skaleres. Å opprettholde optimale menneskelige ressurser er vanskelig når volumet av behandlingen endres raskt. De fleste bedrifter har disse avdelingene overbemannet for å kompensere for volumtopper

Betalings- eller anskaffelsesforsinkelser

1. Data fra dokumentene legges inn manuelt. Denne prosessen blir en flaskehals når volumet av dokumenter som behandles øker
2. Forsinkelser kan føre til forsinkelse i levering/betaling/anskaffelse. Fører til høye kostnader for arbeidskapital eller tap av inntekter på grunn av forsinkelser i innkjøp av råvarer etc.

Beholdningsfeil

1. Hvis lagersystemer ikke er korrekt integrert med denne prosessen, kan det være høye kostnader ved feilberegning av lagerbeholdning. Resulterer i overlager, dupliserte bestillinger, underlager og tap av inntekter.

Feil i 3-veis matching

Det er en rekke forskjellige feil som oppstår i denne prosessen. Nedenfor er noen eksempler

Leverandørmatchingsfeil

Leverandørmatching gjøres vanligvis basert på to ting, leverandørnavn og adresse. Siden samme selskap kan ha ulike datterselskaper og ulike forretningsenheter som utsteder lignende fakturaer.

Hvis adressen fra innkjøpsordren og Faktura ikke har riktig adresse og leverandørnavn identifisert, kan det være problemer med samsvar. Som det tydelig kan sees, fungerer ikke direkte tekstmatching ved å matche fakturaen og innkjøpsordren.

Innkjøpsordre	Faktura	status
Acme Inc.	Acme Inc.	Works
Acme Inc.	Acme Inc. Afrika	svikter
Acme	Acme LLC.	svikter
Acme LLC.	Acme LLC. Artilleriavdelingen	svikter

Produktmatchingsfeil

Produkter er den vanskeligste varen å matche siden de sjelden følger samme navn i innkjøpsordre og faktura og kvittering. Dette er mest sannsynlig den største årsaken til feil.

Årsaker til feil kan være fordi det er forskjellige versjoner av samme produkt, forskjellige størrelser, spesifikasjoner og priser. Produktet kan ha hatt en nylig oppdatering, en erstatning for en utilgjengelig vare ble levert osv.

Innkjøpsordre	Faktura	status
TYLENOL Sinustrykk og smerte	TYLENOL Sinustrykk og smerte	Works
Tylenol	TYLENOL Sinustrykk og smerte	svikter
TYLENOL Sinustrykk og smerte	TYLENOL® Sinustrykk og smerte	svikter
TYLENOL ekstra styrke	TYLENOL Extra Strength Smertestillende & Feber Reducer 500 mg kapsler	svikter
TYLENOL Extra Strength Smertestillende & Feber Reducer 500 mg kapsler	TYLENOL Extra Strength Smertestillende & Feber Reducer 250 mg kapsler	svikter

Kvantitetsmatchingsfeil

Selv om produktet matches riktig, kan det være feil i samsvar med kvantumet hvis produktet i et spesifisert antall ikke er tilgjengelig osv. Dette gjelder vanligvis også mellom innkjøpsordren og GRN siden det vanligvis er en tidsforsinkelse mellom disse to dokumentene.

Prismatchingsfeil

Hvis det var en endring i prisen i løpet av hele produktkjøpets livssyklus, eller hvis produktet ble oppdatert eller erstattet, kan denne feilen oppstå.

Dupliserte dokumenter

Hvis det er hyppige kjøp av lignende produkter fra samme leverandør, kan det være flere dokumenter som ser veldig like ut. Hvis referansenummeret til en PO ikke er nevnt i fakturaen og på GRN for enten fakturaen eller PO, er det et betydelig omfang for dokumentmismatch.

---

Digitalisering av innkjøpsordrer

For å samle alle relevante data fra innkjøpsordrer må følgende felt trekkes ut:

Vanlig liste over felt som skal trekkes ut (på tvers av innkjøpsordrer kan de ha forskjellige navn):

Faktureringsadresse	Betalingsbetingelser	Sub Total
Kjøperens navn	postnummer	Emne
Kontakt Navn	Produkt	Totalt
valuta	Dato for kjøpsordre	Pris
Lever til	Antall	Leverandørnavn
Tidsfrist	Rekvisisjonsnr

Nåværende løsninger og deres problemer

Mal + tekstmatching

Dette innebærer å definere den nøyaktige regionen for å se etter en bestemt informasjon. Så la oss si at hvis du ønsker å trekke ut datoen og formatet er nøyaktig det samme på tvers av dokumenter og datoen forekommer på nøyaktig samme sted i dokumentet. Vi definerer området som skal ses etter i dokumentet for datoen.
Her er prosessen:

1. Konverter dokumentet til et bilde
2. Vi gir et eksempeldokument
3. Merk regionen der datoen er funnet (dokumentet er sett på som et koordinatsystem der øverste venstre hjørne er (0,0)) vi kan merke (200,300 350,450) til (XNUMX XNUMX) som er området av interesse for datoen
4. Når det er et nytt dokument går vi og sjekker (200,300 350,450) til (XNUMX XNUMX) og trekker ut teksten der

Historisk har dette vært en av de vanligste tilnærmingene til å løse dette problemet. Dette skyldes en rekke årsaker:

1. Enkelhet av programvare og å implementere. En kompetent programmerer kan lage denne løsningen på mindre enn en dag
2. Det er ingen usikkerhet om hvordan løsningen vil fungere, hvis dokumentet har nøyaktig samme format vil det fungere perfekt
3. Det krever svært begrensede dataressurser for å trekke ut dataene

Det er imidlertid noen veldig åpenbare utfordringer gitt hvor rudimentær denne metoden er:

1. Det fungerer ikke hvis det er en liten forskjell i dokumenter
2. Det fungerer ikke hvis kjøperen oppdaterer formatet sitt
3. For hver kjøper er det et nytt format som må settes opp
4. Det fungerer ikke for skannede dokumenter

OCR + NLP + Tekstmatching

OCR + NLP er en nyere teknikk for å trekke ut data fra dokumenter. OCR er et ganske godt studert problem og å trekke ut tekst fra dokumenter fungerer mesteparten av tiden. Det neste trinnet er å ta all råteksten som er trukket ut fra dokumentet og deretter prøve å analysere hver av de individuelle tekstdelene i dokumentet

Innen NLP er det en rekke teknikker som kan brukes for å løse dette problemet

1. Regex (regulære uttrykk)

For å trekke ut en dato vil et regulært uttrykk se slik ut:

^(?:(?:31(/|-|.)(?:0?[13578]|1[02]|(?:Jan|Mar|May|Jul|Aug|Oct|Dec)))1|(?:(?:29|30)(/|-|.)(?:0?[1,3-9]|1[0-2]|(?:Jan|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec))2))(?:(?:1[6-9]|[2-9]d)?d{2})$|^(?:29(/|-|.)(?:0?2|(?:Feb))3(?:(?:(?:1[6-9]|[2-9]d)?(?:0[48]|[2468][048]|[13579][26])|(?:(?:16|[2468][048]|[3579][26])00))))$|^(?:0?[1-9]|1d|2[0-8])(/|-|.)(?:(?:0?[1-9]|(?:Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep))|(?:1[0-2]|(?:Oct|Nov|Dec)))4(?:(?:1[6-9]|[2-9]d)?d{2})$

Utdrag 01/02/2020

kilde: https://stackoverflow.com/questions/15491894/regex-to-validate-date-format-dd-mm-yyyy

Ulempen med den Regex-baserte løsningen er at hvert nytt format må programmeres separat. Hvis det er et nytt format, må det legges til det regulære uttrykket. Den identifiserer ikke om en bestemt dato er leveringsdatoen, forfallsdatoen eller datoen for innkjøpsordren.

2. NER (Navngitt entitetsgjenkjenning)

For å trekke ut felttyper ved hjelp av NER

results = stanford_ner_tagger.tag(article.split()) print('Original Sentence: %s' % (article)) for result in results: tag_value = result[0] tag_type = result[1] if tag_type != 'O': print('Type: %s, Value: %s' % (tag_type, tag_value))

Skriver
Type: DATE, Value: 01/02/2020

kilde: https://towardsdatascience.com/named-entity-recognition-3fad3f53c91e

Ulempen med NER-basert utvinning er at det fungerer bra for veldefinerte typer, men feiler for en rekke typer som adresser og ting som ikke er standardformater. Det fungerer bra for datoer, valuta, telefonnumre osv. Det fungerer av og til for navn og enheter. Den lider av et lignende problem med å ikke vite hvilken dato det er leveringsdatoen, forfallsdato eller dato for innkjøpsordren.

3. Tving leverandøren/kjøperen til å bruke programvaren din til å sende inn dokumentet

Hvis en leverandør eller en kjøper har betydelig innflytelse i en transaksjon, kan han tvinge den andre parten til å bruke programvaren deres til å sende inn dokumentet. Dette fjerner de fleste problemer og overfører hele ansvaret til leverandøren og ingen dokumentdigitalisering er nødvendig. Dette lider imidlertid av det åpenbare problemet med å ikke være allestedsnærværende og krever at den andre parten samhandler med programvaren din. Selv om noen få 3 parter ikke følger denne protokollen, krever det en betydelig innsats for å legge den til ditt eksisterende system.

---

Dyp læring

Deep Learning-teknologien har blitt ganske avansert i nyere tid når det gjelder å trekke ut data og enda viktigere å trekke ut funksjoner som kan føre til bedre spådommer.

Graph Convolutional Neural Networks (GCN) kan brukes til å trekke ut data fra disse dokumentene. Vi mater GCN med en rekke forskjellige funksjoner, som hver brukes for å kunne trekke ut riktig informasjon.

Det kan deles inn i 2 trinn:
1. Funksjon utvinning

Vi trekker ut ulike funksjoner fra hver tekstblokk.

a) Tekstfunksjoner

b) Visuelle egenskaper

c) Plasseringsfunksjoner

d) Størrelsesfunksjoner

e) Fontfunksjoner

2. Grafskaping

Disse funksjonene lages for hver tekstblokk og deretter lages en graf. For hver tekstblokk blir den bestått funksjonene til naboen. Med graffunksjonene og andre funksjoner opprettet for hver tekstblokk blir den deretter klassifisert som et av interessefeltene eller som Ingen.

Dokumentmatching

For å matche dokumentene er Deep Learning også en flott løsning der ekstraherte felt fra hver av dokumenttypene kan analyseres for å gi en endelig prediksjon om dokumentene samsvarer.

Problemer med dyp læring

Det er to typer informasjon som skal trekkes ut

1. Problemer med nøkkelverdier (PO-nummer, dato osv.)

• Identifisere nøkkelverdipar. De er ikke jevnt plassert på tvers av formater og uklart hvor mange naboer de skal se gjennom.
• Ta hensyn til flere språk.
• Ikke nok data til å trene for en bestemt nøkkel (klasseubalanse)

2. Problemer med tabellverdier

• Klassifisering av enhver boks som tabell
• Manglende tabeller på sider med flere tabeller
• Slår sammen to lukkede kolonner
• Feiltolkning av sidekanter som tabellkanter

3. Andre problemer

• Rotasjon og beskjæring
• Bilder av dårlig kvalitet
• Datadrift

---

Bruke nanonetter

Løse problemene med å bruke Deep Learning for OCR på innkjøpsordrer

Bruke Nanonets API Du kan automatisk trekke ut alle de nødvendige nøklene som kreves for samsvarende dokumenter. Bare last opp et dokument og få alle de utpakkede feltene returnert i det formatet du velger.

Vi takler de fleste problemene som er oppført ovenfor, slik at du ikke trenger å bruke tid på å finne opp hjulet på nytt.

Nøkkelverdipar:

1. Identifisere nøkkelverdipar. De er ikke jevnt plassert på tvers av formater.

Ved å bruke GCN-implementeringen vår er vi i stand til å analysere nøkler på tvers av dokumenter. Vår GCN-implementering inkluderer optimaliseringer for å finne det riktige nabolagssøket for å få det beste tråkket mellom funksjonseksplosjon og mangel på kontekst for at modellen skal tolke riktig hvilken nøkkel hver tilhører

2. Ta hensyn til flere språk.

Modellene våre har blitt trent opp med tekstinnbygginger som er språkagnostiske. Dette oppnås ved å lage et funksjonsrom slik at ordet innebygging for 'Faktura' og 'Faktura' (Faktura på tysk) og चलाना (Faktura på hindi) alle kartlegger til samme funksjonsområde. Så teksttrekkene blir språkuavhengige og modellen trenger ikke trenes per språk.

3. Ikke nok data til å trene for en bestemt nøkkel (klasseubalanse)

Vi har et stort korpus av økonomiske dokumenter som modellene våre er opplært i, som reduserer dette problemet.

tabeller

1.Klassifisere enhver boks som tabell

Vi har bygget en robust klassifiserer som kan identifisere en rekke forskjellige tabeller i forskjellige formater og innstillinger. Dette bruker en blanding av visuelle funksjoner og layoutfunksjoner sammen med tekstbaserte funksjoner for å identifisere strukturen til tabellen.

2. Manglende tabeller på sider med flere tabeller

Etter å ha identifisert hver av de forskjellige tabellstrukturene på tvers av sider, har vi en flettelogikk som bestemmer om strukturen er lik nok til å slå sammen og om en tabell på en tidligere side var ufullstendig for å avgjøre om to tabeller skal slås sammen.

3. Slå sammen to lukkede kolonner

Hvis vi bare stoler på visuelle funksjoner, blir dette et problem siden det er vanskelig å identifisere rombasert separasjon. Med inkludering av visuell tekst og posisjonsbaserte funksjoner blir det imidlertid mulig å identifisere hvor typen data i en kolonne er forskjellig nok til å kalles en ny kolonne.

4. Feiltolkning av sidekanter som tabellkanter

På samme måte som ovenfor løses dette problemet ved å bruke en rekke funksjoner for å finne ut om en bestemt struktur er en tabell eller en sidekant.

Andre problemer

1. Rotasjon og beskjæring

Vi har implementert en rotasjons- og beskjæringsmodell som en del av forbehandlingstrinnet vårt for å identifisere kantene på et dokument og deretter orientere dokumentet riktig. Denne bruker en modell som ligner på en objektdeteksjonsmodell med objektivfunksjonen modifisert for å identifisere 4 hjørner i motsetning til 2 punkter som er standard i et objektdeteksjonsproblem. Dette løser både rotasjon og beskjæring

2. Uskarphet og dårlig dokumentkvalitet

Vi har en kvalitetsmodell plassert som en del av vår forbehandlingspipeline som kun aksepterer dokumenter over en viss kvalitetsterskel. Dette er en binær klassifikator som er en enkel bildeklassifiseringsmodell trent på en rekke dokumenter som har både god og dårlig kvalitet. I dokumentfangstrørledningen kan dokumenter avvises tidlig hvis de ikke oppfyller kvalitetsstandardene som kreves, og kan sendes for gjenfangst eller manuell behandling.

2. Datadrift

Datadrift er et problem når modellen bare eksponeres for data fra en enkelt leverandør eller enkelt region. Hvis modellen har blitt trent historisk på en rekke forskjellige leverandører, geografiske bransjer etc, reduseres muligheten for datadrift betraktelig siden den allerede har vært utsatt for disse variansene.

Begynn å digitalisere POer og Fakturaer Nå med nanonetter – 1 Klikk PO Digitalisering:

Videre Reading

Oppdatering 1:
Lagt til ytterligere lesestoff rundt uthenting av informasjon fra innkjøpsordrer og bruk av OCR for automatisering

Oppdater 2: Vi har forbedret nøyaktigheten til modellene våre betydelig for å trekke ut data fra PO-er.

Sett opp en demo

Sett opp en demo for å lære om hvordan Nanonets kan hjelpe deg med å løse dette problemet