Soumik Majumder Principal Business Consultant

As the OCR Invoice Capture utility gains more attraction among customers, support for the return PO invoice processing becomes a necessity.

Currently, returned purchase order type isn't supported by Invoice Capture as the Purchase Order virtual entity doesn't return the purchase order with type 'Returned order'. It blocks customers from fully automating their PO invoice processing operations.

Therefore, it is critical and urgent to add support for the Returned purchase order type to enhance accuracy and improve the user experience.

To better accommodate effective mapping of the invoice line items for various supplier invoice patterns, it'll be extremely helpful if some of the existing validations with the prebuilt AI builder model can be relaxed a bit to also allow line items mapping on non-consecutive pages.

On our current project, we receive invoices from one of the Singapore based supplier where they pass on all the procured part serial numbers in description column against the invoice lines view.

If the PO document involves procurement of parts in bulk, the invoice copy can end up being multi-paged where few of the pages in between may not even have any relevant line level details other than the part serial number list. In that situation, if we map the first page lines section details and try skip the interim pages those only contain part serial numbers, the application doesn't allow us to map the invoice line data on the subsequent pages as the few pages in between have been skipped. We receive an error suggesting Multipage tables cannot be tagged on non-consecutive pages.

Hence, to effectively map invoice lines on similar invoice patterns, it'll be extremely helpful if line items on non-consecutive pages are also permitted with prebuilt AI builder model.

Once we configure electronic invoicing for Malaysia or other eligible country regions following the regulatory guidelines, the out of the box 'Electronic document submission log' UI experience helps tracking communication results for individually submitted AR/ AP retail invoices to tax portal or batch submissions for AR invoices related to customer accounts sharing the general public TIN number 'EI000000000010'.

Once the retail invoices are batch submitted, currently there's no efficient UI experience to trace individual invoices those were part of the batch submission. As of now, we can validate the individual invoices associated with the batch submission instance only by referring to the output submission file or by navigating to the batch submission instance in tax portal experience. 

In the 'Electronic document submission log' view Microsoft has provided an out of the box view as 'Batch submission invoices' to trace the individual invoice documents reported but that option is limited for commerce invoices only.

It'll be extremely beneficial if the 'Batch submission invoices' can be purposed for retail invoices too so that business users can easily track the individual invoices reported against batch submission. This also becomes crucial for batch submission scenarios as for batch submission, the QR code or UUID gets assigned to the whole batch and we can't track these details against the posted invoice journal documents upon reporting.

For blanket PO scenarios in indirect procurement space there's a possibility where the PO document might have been fully invoiced as the initially allocated funds have already been used up. But we can expect fresh supplier invoices as the project may not have been ended from supplier endpoint and they would require additional funds to be allocated.

On such occasions, the Accounts Payable team will expect the invoice capture application to allow them to associate the invoiced blanket PO document with the captured invoice that can then be transferred to D365 pending invoice queue.

Once transferred to DAX, they will coordinate with global indirect procurement team to add additional funds to the invoiced PO by adding line items to the PO document and thereby allocating extra funds that the pending invoice can be processed against.

Currently, only fully or partially open (open order, received etc.) purchase orders appear in the purchase order lookup menu for the captured invoice in OCR. It will be extremely beneficial if this can further be extended to associate invoice purchase orders to the list to accommodate similar blanket PO scenarios.