Month: February 2023

For this week, I was able to implement the logic of regenerating original quantities of previous ItemHistory that were currently not computed and stored 0 as an original quantity.

Started off by using DbContext in ViewModel to get all list of histories then proceeded to use a foreach loop, where each row of history was subjected to a function that computed its original quantities, eventually saved the updated history to database using SaveAsync().

Once the logic was coded, it was time to test it. Added a test-case for previous histories original values calculation, as it was 0 previously. Faced issue with DateTime, as I was using DateTime.now(), so using OrderBy() didn’t actually ordered the rows. As this feature is considered a service of ItemHistory, it became clear that there needed to be a separate file to test it, so a HistoryServiceTest was formed.

Next, Mr.Peter decided to put the code to the test, and we discovered a bug in the algorithm that caused a source history to go unnoticed. Mr.Peter made me fix the code and showed me a better way to test. Moreover, another bug was discovered that allowed previous non-computed rows of history to take their value in current history, so the condition was changed to skip non-computed rows. Once all bugs were fixed the logic looked promising.

Finally, began Code review with Mr.Peter. Discussed on one more condition to use item status while calculating original values of ItemHistory. Added Status to History and added a test-case to check if the correct StatusId was being assigned on creation of ItemHistory.

This marked the end of my 3-month internship with Tong Hin.

For this week, I was able to implement the logic of calculating the original quantities for history and proceeded to implement logic for previous histories quantities calculation.

Started off by running an SQL script to include additional columns. Updated the overridden AddAsync method to populate the additional fields in a history according to business rule. Made use of edge cases to test the logic in the repository, some bugs were discovered that prevented the detection of previous locations for both the source and the destination, and fixed it.

Moreover, I was struggling to understand how to test the repository’s create logic because I was currently using the UI to test the logic, which is not a good method. Mr. Peter was able to clarify this for me. Created HistoryRespositoryTests and added testcases to test the repository logic through various conditions and edge cases. Furthermore, discussed the importance of populating existing history data quantities.

Lastly, I realized I had hardcoded the disable property in barcode, so I converted it to a boolean property and binded it to the IsEnabled property. Moved onto a new task to populate previous history quantities. Added a button to the UI which on interaction will retrieve all histories and populate their original quantities. I was able to successfully retrieve all histories from the database and display them in the UI.

For this week, I was working on the feature to compute the existing and final quantities of history.

Started off by coding an algorithm to compute these values, the aim was to design an algorithm with minimal computational complexity. Since in my last meeting with Mr. Peter, I was informed that any changes in database would only be made when all other ways of performing this task return unsuccessful. Therefore, I was left with no other option than to store the data locally. The idea was to store the final quantity of a history quantity which would be the existing quantity of the following history for the same item.

Created a static class to hold global variables, stored final and initial quantity in a global variable to prevent data being lost on a new API call. Eventually, I was able to design an algorithm which correctly computes each quantity; However, storing data locally meant that the data will be lost when the App restarts. After considering these facts and also the computational cost Mr. Peter instructed me to change my approach and use a database for storing quantities.

To store the values in the database, I added four new fields to the entity. I override the create method for history entity so that it now populates the new fields based on the logic. Finally, I ran a stock adjustment test to see if the new fields were being filled in.

In the last week at Tong Hin, I managed to refactor the cancel ongoing accept stock take command to fit with the refactor background service which uses channel. Afterward, I need to fix the some of the problem for the signalR where the if the process is finished faster than the connection being establish the progress bar will not being updated.

In order to figure on how to fix the existing problem, I needed to mock the signalr service in the background service so the output of the signalr will be display on the unit test instead. The mock is done in order to simulate the client connection which will establish the connection and receive the input from the server.

After some fail attempt in mocking the background service, I move on to doing the code review with Mr. Peter.

For this week, I was able to implement some new features and fix bugs in the History View. Started by separating the View and ViewModel from ItemView and ItemViewModel respectively. Successfully displaying it as a separate tab in ItemView.

Next, I made the barcode disabled, along with its checkbox, to prevent any changes from being made. Discovered that the application was making pointless calls to the API even when it was not being used, this issue was fixed. Moreover, I implemented another feature that gives users an option to view the item’s history in ascending or descending date format. To achieve this I had to make changes to both the API and UI, the UI now contains a checkbox which on checking/unchecking will make separate API calls to display data in different date order. Furthermore, I was able to provide users with the ability to alter the number of rows displayed per page.

Finally, I started brainstorming on a new task which involves comparing and computing old and new data for warehouses. I discovered that I needed to make a separate API call to get the final item quantity. I was able to make the API call in such a way that the entire data set loaded at the same time. Adding logic to determine existing item quantity still remains.