Mirabito CS - Dogukan Atakur; Emre Demir; Mert Vural;

Week 1 09/18/2024

Attendance: Emre DEMIR, Dogukan ATAKUR, Mert Can VURAL

Summary:

The primary objective for our project group is to integrate AI with older POS (Point of Sale) registers and to build the foundation of the loyalty system’s API based on Conexxus specifications, using XML as the data interchange format for communication between systems.

Accomplishments:

• Discussed the integration of AI into the old POS systems.
• Set up the development environment with .NET and Visual Studio Code through Microsoft's Extensions.
• Started watching Certificate Courses and gained experience in backend development technologies such as C#, .NET, and XML.
• Established that Denis will be responsible for setting up the customer database to track purchases and discounts in our development environment.
• Agreed on testing the system using simulated transactions in the lab.

To-Do:

• Review the provided Conexxus specification documents.

Week 2 09/23/2024

Attendance: Emre DEMIR, Dogukan ATAKUR, Mert Can VURAL

Summary:

Initially, the team began by implementing a TCP client-server console application to simulate the loyalty system. After thorough scrutiny of the provided JSON documents through Swagger, we decided to shift focus to implementing the system using a Web API.

Accomplishments:

• Implemented a TransactionService with routes to start, add details, and complete transactions.
• Developed a custom JSON converter (TransactionLineConverter) to handle polymorphic deserialization for different transaction line types (ItemLine and FuelLine).
• Structured the system to centralize POSJournal data, aiming to incorporate discount, tax, and loyalty functionalities.
• Successfully handled ItemLine and FuelLine objects within transactions.

To-Do:

• Implement loyalty and discount processing within the CompleteTransaction route.
• Extend the functionality to handle tax calculations more comprehensively (both per line and for the whole transaction).
• Finalize documentation with a detailed sequence using PlantUML to illustrate the transaction process flow, including loyalty, discount, and POSJournal handling.

Week 3 10/08/2024

Attendance: Emre DEMIR, Dogukan ATAKUR, Mert Can VURAL

Summary:

• This week, our team focused on implementing the TransactionService and loyalty system functionality. We ensured dynamic, line-level loyalty processing for each transaction detail. The handling of transaction lines (ItemLine, FuelLine, and DiscountLine) was also completed, ensuring that loyalty is correctly applied to each line.

Accomplishments:

• Created the AssignLoyaltyToTransaction feature, allowing the system to attach loyalty info to a transaction and generate specific loyalty details for each relevant transaction line.
• Enhanced the TransactionLineController (renamed the ItemLineController) so it can now return mock data for FuelLine, ItemLine, and DiscountLine, making our API more robust and versatile.

• Investigated the openapi.json file to explore ways to connect hardware and software by analyzing components like POS Terminal Identification, TerminalStatus, and Register

• Built the CreateLineLevelLoyalty function to automatically generate line-level loyalty for each ItemLine or FuelLine and integrated it into both the AddTransactionDetail and AssignLoyaltyToTransaction processes.
• CompleteTransaction now prints a summary of each line's original amount and loyalty.

To-Do:

• Implement the remaining five transaction line types: MerchandiseCodeLine, FuelPrepayLine, TransactionTax, TenderInfo, and AgeVerificationLine.
• Simulate a POS machine to test our implementations.

Week 4 10/16/2024

Attendance: Emre DEMIR, Dogukan ATAKUR, Mert Can VURAL

Summary:

This week, we focused on unit testing, further enhancements to our transaction components, and ensuring compliance with the RLM (Retailer Loyalty Management) specifications. We implemented unit tests for both the **LoyaltyService** and **TransactionService**, adding functionality to check loyalty eligibility at the fuel line level. Additionally, we worked on components required to structure a complete transaction and established communication with the RLM group to align our process flows. We also implemented a method to retrieve POS device information.

Accomplishments:

• Unit Tests:

   - Implemented unit tests for LoyaltyService to ensure transactions with and without loyalty apply correctly.  
   - Developed tests for TransactionService that validate loyalty and non-loyalty scenarios, ensuring the correct final amount is calculated for both cases.

• Fuel Line Loyalty Check:

   - Implemented logic to verify loyalty eligibility for FuelLine transaction types. This ensures that both item lines and fuel lines can process loyalty correctly, aligned with RLM standards.

• POS Device Information:

   - Created a method to retrieve critical POS device information, including **Register ID**, MAC Address, and Terminal Status, which will help simulate transactions accurately in future demos.

• Transaction Structure:

   - Worked on aligning the necessary components required to form a complete transaction. This includes timestamps, customer details, loyalty information, product IDs, **inventory IDs, and total amounts.  
   - Ensured that error handling works properly, even if a customer does not have loyalty, so that the transaction still completes successfully.

• Communication with RLM Group:

   - Began comparing our transaction processes with RLM group specifications to ensure our system aligns with their standards. This includes mapping transaction data components like Loyalty ID, Product ID, Inventory ID, and final amounts.

To-Do:

• Continue refining unit tests to cover more scenarios, including transactions with multiple items and various discount conditions.
• Finalize error-handling logic for transactions that encounter issues, ensuring smooth completion.
• Prepare for a demo showcasing transactions with and without loyalty, ensuring full functionality across both cases.
• Explore ways to simulate POS devices to ensure hardware and software components interact correctly.

Week 5 10/23/2024

Attendance: Emre DEMIR, Dogukan ATAKUR, Mert Can VURAL

Summary:

This week, we tried to figure out: 1) Whether the cost is totaled or item by item

   - We first thought TransactionDetailsObject could be the thing we are looking for, but it has specific fields like nozzleNo, pumpNo and modeNo as "required"... 
   - Then thought using "LoyaltyLine" not the "loyalty" that appears for each Line in "TransactionDetailGroup" since it has a field like "originalAmount" and it is for the whole transaction unlike the "loyalty". But again, this would not meaningful because LoyaltyLine being created when loyalty id provided...

2) How it is summing up everything and incorporated with the unit testing.

   - What we are doing is that the MerchandiseInfo class calculates the total for each item by multiplying the regular price with the sales quantity, and then adjusting for any discounts, taxes, and promotions. 

3) What 'Discount' takes as input?

   - The "paymentSystemsProductCode" is essential for line-level discounts because it ties the discount directly to a specific item in the transaction. However, it becomes irrelevant for transaction-level discounts, like those in loyaltyLine or discountLine, because these discounts apply to the entire transaction rather than individual items, making item-specific codes unnecessary.

4) Finding the total

   - Same as the first answer.

Accomplishments:

   - Reviewed how Conexxus standards apply to calculating item and transaction level discounts.
   - Searched for any field related to "total amount of the transaction".