Submit your additional exercise workflow
Having Difficulty extracting the checkbox data i am using a form extractor , Request you all to please guide me @Melisa_Miranda
SpecAI_DU_Performer.zip (151.3 KB)
here is my workflow please let me know where i went wrong, i have configured every classifiers and extractors and yet its not extracting the data from the kyc form @postwick @Anil_G @supermanPunch @Melisa_Miranda @ppr
Hello @Jai_Pande
I reviewed your workflow. It is pretty good. Great work implementing it 
I however, have few suggestions and guides for you.
Regarding the Date field extraction:
I saw the output files and the date fields were extracted as a number. You did correct by specifying the field as a type “Date” in Taxonomy. However, in forms like this we may need to add an extra setting by specifying the expected date format in the form. This is done because the document itself doesn’t say which format the date is in as we write it in a single line with numbers and no separations for day, month, etc.
So in the Taxonomy, we can set the expected date format
Regarding the Checkboxes:
the type set in the Taxnomy (Boolean) is correct. We also highlight the textbox area in the Form Extractor to indicate where it is. These two steps can work. However, there can also be scenarios where it requires a extra step here as well.
In the Form Extractor, we have a place to configure the usual characters that may show up for checkboxes. We can add those automatically and manually. Following is a screenshot.
Click on the “Add recommended” text next to it to automatically add the common characters. You can also edit manually.
Try adding this and running it again. It will most probably work. Feel free to reach out to me if it doesn’t work. We can work together.
I have another suggestion for you regarding the name fields like the “full name”. You can try using the data type in Taxonomy as “Name” instead of “Text”. There is nothing wrong in using “Text”. However, using the property “Name” will give you added formatting functionality. The extracted name will be separated automatically into “First Name”, “Middle Name”, and “Last Name” just like it does for Address and Dates.
Give it a try and see the magic
Overall, great job friend!! Happy to see your learning… Keeping going!
Thanks
Lahiru
First of all it means alot when you responded sir.
I managed to solve the conundrum by first splitting the PDF into single pages and then inserting a single type of PDF into the template to enhance the Template of Form Extractor
Regards
@sanjay3 Thank you for your workflow submission.
We will review and provide feedback shortly.
Hello @sanjay3
Great to see your efforts in learning AI. I have reviewed your submission and here is some feedback.
Your solution includes the Dispatcher (REFramework) and the Document Understanding flow.
The use of REFramework is a good choice for the dispatcher. However, there are few things that you can improve as a part of best practices. You included the folder reading activity in the Process.xaml to capture all files that require processing. Ideal scenario would be to include this in the INIT state and push it out as a DataTable from the InitAllApplications.xaml. If you look at the Main.xaml, there is a predefined datatable that we can use as transaction items. If we can assign the values to that, we can pass them as Data Rows to the Process state.
The other approach is, instead of converting to Datatable, use a List. Either way, it is always good to define it in the INIT itself. The reason to define in INIT has multiple benefits:
Here I assume that you had the idea of triggering the DU job multiple times for each queue item?
I say this because I don’t see the looping back to get the next queue item. Can you also share whether you planned to trigger the DU job based on a Queue Trigger? If so, that is perfect
I also liked the fact that you have included the DU activities inside a Try Catch.
Good naming methods.
I noticed a few fields where you can use better data types. For example, a few fields were referring to names of people with the data type “Text”. You can use the data type “Name” here. It will also help to automatically format the names into First, middle, and last names.
Its great that you added the date format for those tricky dates
Your classification method is correct. Can you explain a bit on how you trained your classifier? What was your approach in training?
The Train Classifier Scope has to be included after the manual classification step. For example, after Present Classification Screen. So you need to swap the two activities to reorder it. The reason is, we do the training only after the manual validation. and based on manual validation results If we use the auto-classified results for training, we may also train using the wrong data (if the automatic one is wrong).
Signature Fields option is only applicable for the fields that include the human signature. We only configure it when we need to detect whether a signature is present or not. It should point only that field. In your scenario, it is mentioned for most of the fields. Hence, you need to fine-tune that setting to point only to the field that requires the signature.
This is probably the reason why you get “YES” “NO” as the output for most of those fields in the Excel.
Though that is the practice, I kind of see a pattern in how you have configured it. Can you explain your thinking behind this? I would like to understand better and be a bit more specific
The use of a try catch is wonderful. I just noticed that in the Catch section you are setting the transaction status to “Success”. I believe it should be “Failed” with Application Exception
That’s what I have for now… I look forward for your reply so we can talk about those little pointers I mentioned.
Thanks again and keep learning!
Thanks
Lahiru
Thank you for the feedback
For the Dispatcher , based on your feedback I will work on that and follow the best practice
The Document Understanding flow, yes my idea was to process one file at a time.
Taxonomy Manager specifiers , I will work on that.
For Classifiers training, I manually split the document which are merged i.e. (AC Open and KYC From). After that when I run my flow it was automatically splitting the document which are merged.
For the Train Classifier Scope , I will make changes as per your feedback
6.Try Catch , yeah It should be failed, it was mistake from my side
Once again thank you for the feedback
Regards,
Sanjay
Awesome… That is perfect…
Feel free to text here in case you need any assistance
Hi @Jai_Pande,
Thanks for submitting the workflows for the advanced challenges! Appreciate your interest. Keep it going!
Hi folks,
I’m using a Form Extractor for this exercise and am running into issues when I try to extract the applicant’s name from the “AC Open” forms.
As you can see below, there a variety of ways that the applicant name has been input. Some applicants write their entire name in the “First Name” field (Document #1). Some write their entire name so that it overlaps with the “First Name” and “Middle Name” fields (Document #2). Some write their First, Middle, and Last names separately, in the correct fields (Document #3).
Document #1 -
Document #2 -
Document #3 -
I can’t seem to concoct a Custom Selection area that would pick up on all of these, without also extracting the “First Name,” “Middle Name,” and “Last Name” labels. As in the screenshot below, the extracted name is going to be “AKIRA YUKI TANAKA middle name last name”.
What’s the move here? I’ve considered making a template with a custom “Applicant Name” selection area for each of these three documents, but that seems to defeat the purpose of making a template to begin with (am I going to make a template for each new theoretical edge case in future documents?)
Does the way that names are written to these documents make the documents Semi-Structured? If so, is this a use case that would be better served by the ML Extractor?
Thanks for your help,
Caleb
Appreciate your interest in solving the exercise. Thank you for reaching out.
Our UiPath MVP @Lahiru.Fernando will soon assist you with your query.
Thanks
Hello Caleb,
This is a very good question. Thanks for asking and trying it out
We added this scenario because this is common in some enterprise DU projects too. This exercise is a good practice to prepare for the little challenging parts when processing forms 
In this particular case, the Form Extractor design is correct. It should cover the entire field area as you have done. The reason here is because we don’t know where the user will write the names (similar to the three documents).
This is a very good question. The answer is: No… it doesn’t make this document semi-structured. The document is still structured. But we need to address slight variations because of the default text they included in the actual form.
The Form Extractor configuration cannot handle this part. This is more towards data cleansing. We can apply simple data cleansing steps to cleanse the field data and remove the default text if captured. It’s similar to a String Replace. Below is a sample code I did to show you how it can be done.
As you see in the image, We can add an IF condition after the Data Extractor Scope. The IF condition checks if it is an Account Opening Form. This is added because we don’t need to add this cleansing step for all document types. Inside the IF activity, we have an Assign that replaces the default text. Below is the code.
AutoExtractionResult.ResultsDocument.Fields(6).GetValue().Value = AutoExtractionResult.ResultsDocument.Fields(6).GetValue().Value.Replace("Last Name / Surname","").Replace("Surname", "").Replace("Last Name","").Replace("Middle Name", "").Replace("First Name", "").Replace("Name","").Trim
This is just a sample I did to show the replace step in a simple way. You can of course follow best practices and do it in a much nicer way. What happens here is that we check for the default text words in the string and replace them with an empty string. The result will give you only the extracted name. We update the AutoExtractionResult variable itself here because it can later be used for Validation Station.
You can place the Validation station below this cleaning step to view the results as shown in the image.
Great question again… Hope this helps and clears the doubts you had. Happy to assist if you have further questions.
Thanks
Lahiru
That is all super helpful! Thanks! I’ll try the things you’ve mentioned.
Hi all,
Thanks again for your help so far! Another question I’ve run into as I’m working through this:
I’m trying to extract “Birth Date” from the Account Opening forms. Here’s how I have it set up in the Taxonomy manager:
Details Screen
Rules Screen
The “Date of Birth - Required” rule merely specifies that this field cannot be empty.
When processing the documents, UiPath Document OCR (understandably) runs into issues trying to read the date below:
According to OCR, this is 250T1972. Despite not being a valid date, this field isn’t flagged in the Validation Station.
If I were dealing with a “Text” field, I would simply add a Regex rule to flag this, but the “Date” field type does not allow for Regex rules (as depicted on the Rules page above). I could change Birth Date to be a “Text” field but feel like this would be a sloppy fix. Shouldn’t date fields be flagged in Validation station if they can’t be parsed as a Date using the provided format? Is there a way to implement this?
Thanks,
Caleb
Another great question
Well, we don’t have the pattern check in the Rules yet for dates. But, of course we can build a rule for this in the validation step.
Usually, once we do the data extraction we try to validate the extracted data. This step is done before presenting the validation station. Given the scenario, we can implement a similar approach.
Steps:
We have discussed more about building these steps in the DU Template course. But you can still implement a simple rule as I described.
Hope this helps
Thanks
Lahiru
Very helpful, once again! Appreciate your help, Lahiru.
Thanks,
Caleb
