The overarching flow of invoice control (as of time of writing) is relatively simple: B[User creates invoice mapping] B --> C[User uploads invoice and specifies mapping in Scope] C --> D[Fetch preSignedURL from backend] D -->|Successful| E[Upload to GCP bucket using preSignedURL] E -->|Successful| F[Call SaveReference in backend] F --> G[Trigger backend's Pub-Sub] G -->|File type: XLSX/CSV| H[Call CompareCSVInvoiceToDTA] G -->|File type: PDF| I[Call ComparePDFInvoiceToDTA] subgraph CompareInvoiceToDTA H --> J[Parse into InvoiceRow with invoice mapping] I --> J J --> Z[Multi-row processing?] Z -->|Yes| Y[Group InvoiceRows with common identifier] Z -->|No| K[Find appropriate DTA] Y --> K[Find appropriate DTA] end K --> L[Calculate expected vs actual costs] L --> M[Populate invoice table on Scope] M --> N[End] `} /> ### Data structures There are a few different categories of data structures in invoice control that are important to keep track of. The uploaded invoice is represented using Once processed, the controlled invoice can be accessed with these two structs: A user configures a 'parsing schema' by creating an invoice mapping: The invoice mapping can then include any number of column mappings: If more than one mapping points to the same skrym column, it is necessary to use a It is also possible to use default values for invoice columns, which can be useful when there is no column for a fixed value. We have one struct for storing the information from the invoice: And another struct for storing calculation results based on that information: The invoice row extensions represent a one-to-many relationship between an invoice row and certain calculation results or fees. For questions, it is best to reach out to , , or who were part of the hackathon to create the invoice control service.

Invoice Control