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".

Week 6 10/30/2024

Attendance: Emre DEMIR, Dogukan ATAKUR, Mert Can VURAL

Summary:

   We have integrated the TransactionDetailsObject into our development process and accumulated the prices of individual lines into its Amount field. Additionally, we analyzed the provided RLM message and mapped it to corresponding Conexxus specification objects. Our project code is now ready to be pushed into the Bitbucket ecosystem. We also documented further testing protocols to ensure the codebase remains robust as it grows.

Accomplishments:

   1)Fixed previous database errors and successfully parsed items from the fake database.
   2)Mapped out the correlations between the provided RLM message to our Conexxus Specifications document
   3)Calculated and accumulated the total amount in the Amount field of the TransactionDetailsObject.
   4)Prepared the project for integration and deployment into the Bitbucket repository.discounts. Searched for any field related to "total amount of the transaction".

To-Do

   1)Create a fake database
   2)Continue testing the implemented components

Week 7 11/06/2024

Attendance: Emre DEMIR, Dogukan ATAKUR, Mert Can VURAL

Summary:

This week, we focused on refining the code and ensuring seamless integration within our repository. Updates were made to the RLM message table, enhancing its accuracy and relevance for the current development stage. In addition, we tested our IP addresses and sent those IP addresses to Denis.

Accomplishments:

   1) Pushed fixed code updates to the Bitbucket repository, incorporating recent
   enhancements and bug fixes.
   2) Tested the IP addresses and sent to Denis.
   3) Enhanced the RLM message table based on feedback from last week's analysis, aligning              
   it with updated specifications and usage requirements.

To-Do

   1) Continue iterative testing and documentation to maintain code stability.

Week 8 11/20/2024

Attendance:Dogukan ATAKUR, Mert Can VURAL, Emre DEMIR

Summary:

This week, we finalized the database schema design and completed documentation to align with Conexxus specifications. We made enhancements to support transaction handling, loyalty systems, and discounts while ensuring scalability and data integrity.

Accomplishments:

• Finalized the DBML schema:

 - Included key tables such as `Transactions`, `TransactionDetails`, `TransactionItems`, and `TransactionFuels` for managing transaction metadata and details.  

• Enhanced loyalty and discount structures:

 - Added the `LoyaltyTransactions` table with fields like `rewards_earned` to track loyalty points.
 - Developed `LoyaltyPrograms` and `LoyaltyAccounts` tables to support multiple loyalty configurations and account management.
 - Designed the `Discounts` table to handle line-level and transaction-level discounts with tax implications.

• Completed documentation:

 - Documented schema differences and justifications for new tables and fields.
 - Provided detailed explanations of table purposes, relationships, and key fields.

• Delivered project artifacts:

 - Submitted the DBML schema and Entity Relationship Diagram (ERD).
 - Included implementation notes and assumptions for the schema.

To-Do:

• Review schema and documentation with stakeholders for additional feedback.