Legend:

  • CR = Change Requests
  • UC = (Business) Use Case
  • In Ciel: Total Efforts
  • In Blue : Efforts spent till 10/07/2023

=====================================================

INFRASTRUCTURE

  • OD has 1 Common DB for KIA, HYUNDAI, SEAT
    • Merging & Migrating OPEN Orders / BPs  - (CRITICAL/RISK)
      • (CR). Merge KIA & HYU DBs to 1 Multibrand DB (Installation) with:
        • Open Orders migrated from KIA, HYUNDAI
        • Any order migrated to the integrated envrionment must populate (somehow) the Order Document Dynamic Mappings (ID relations) from SAP VMS.
        • Any open/migrated order should be able to be processed in the workflow (To Vehicle Delivery or Cancel) 
          •  Notice that Orders in the past were priced based on the gross model prices (kia/hyu tenant logic) and price calculations when/if opening previous orders would require a valid previous model tree (ie. net unit prices valid at the time the order was opened.)
          • Notice 2, all "Inquiries" (Interest), Leads, WF Sessions need to be migrated as well, of course, if there is a possiblity to bring all open orders to a state that they can be moved to either Vehicle Delivery or Order Cancel. 
        • All BPs involved in any previous order. (along with CPs, Addresses, Data Privacies).

Effort Est (OD Integration): TBC (After Migration strategy is concluded)

Effort Est (ODIL): TBC  (After Migration strategy is concluded)


  • Master DATA Integration
    • Model Prices: XLS Αρχείο ModelTree
    • Model Master Data: XLS Αρχείο ModelTree
    • Net Unit Prices are necessary.

    • (CR) ModelPrices should include priceProtection flag per model which protect the price of the model and not model-discounts can be applied in the order creating process.

      • TBD

Effort Est (OD Integration): TBC  (After Migration strategy is concluded)

Effort Est (ODIL): TBC  (After Migration strategy is concluded)


Integration Scope

Business Partners Integration journey (Customers API)

UC1. As a sales advisor, I will only send (create/update) the Customer only if/when an order is created or changed.

  • Acceptance Criteria: If Customer is not created then the user must be notified that the BP was not created.

Effort Est (OD): 0.5d (this will be covered with DSW Configuration)

Effort Est (ODIL): N/A


UC2. As a sales advisor, altering the BP through the BP Card Page, I will only UPDATE the Customer if Business Partner has an order document in DSW.

  • Updates should be sent only in BPType is Customer.

Effort Est (OD): N/A (Covered by UC1)

Effort Est (ODIL): N/A


UC3. As a sales advisor, when creating a new BP, that already exists on another company, the User can select the needed Business Partner

  • Get Business Partner by AFM is required here in order to validate and get the DMSCode.
    • Acceptance Criteria: The DSW should check if the BP exists based on the "AFM" or "Name".
    • Acceptance Criteria: The Data Privacy Statement of the old BP needs to invalidated if transferred to a different company. [out of scope]

Effort Est (OD): N/A (Covered by SAP CPI ie. TEKA has implemented already an AFM Check which responds to TR their BP Id in order to define the dyncamic mappings accordingly)

Effort Est (ODIL): N/A


Fundamental Agreements:

  • GDPR is not relevant for SAP. [out of scope]

Vehicle Integrations

UC4. As DSW, I can retrieve Autohellas Stock vehicles (for Leads) from 2 possible interest types:


Stock Locator (Stock Search API):

UC4.1. As a sales advisor I can define/search using the following filters

  • Family, Make, Model, Availability Status, FuelType
  • Dimensions (Company, branch, location)

Acceptance Criteria: Response Data to be shown are the ones agreed from the integration Analysis (Stock Search Workshop)

Acceptance Criteria: Code of the SAP Vehicle Entity can/will be responded.

Effort Est (OD Integration): N/A

Effort Est (ODIL): N/A


UC4.2. As a sales advisor, Viewing the stock vehicles responded from SAP/VMS in the Stock locator page, I can see all available (stock) vehicle configurations (as currently in KIA/HYUNDAI), and not all the existing stock vehicles  (actual VINs)  [CRITICAL/RISK]

Acceptance Criteria: Each individual line contains an individual vehicle Make/Family./Model/Color/Trim/(extra) Equipment.

CR. A new Stock Locator Page is required here that groups together vehicle configurations, instead of actual VINs.

Effort Est (OD Integration): N/A  (the requirement above must be covered by the DSW DEV Team by providing a different stock-locator page that groups results based on responded vehicles' configuration ie. by the cimbination of Make/Family./Model/Color/Trim/(extra) Equipment))

Effort Est (ODIL): N/A


Vehicle API:

UC5. As SAP VMS, I can send (create) and update all  customer vehicles so that they can be reflected in our (Vehicle) Inventory Gridlist, 

Acceptance Criteria: Only when a vehicle is delivered to customer

Effort Est (OD Integration): N/A

Effort Est (ODIL): N/A


Fundamental Agreements:

Elias Koutsabelas Here HYUNDAI desires a similar solution to what they have in the current Kia/Hyundai Stock Locator Page whereas DSW requests the vehicleAvailability of a specific configuration by passing the following information:

  1. Make
  2. ModelCode 

The response is a list of vehicle configurations* of the requested Make+Model "filter" and not a list of all actual vehicles (with ID/VIN), as we currently do in our Product Application. A similar approach is required whereas the Stock Locator list shown groups together the vehicles that are of the same configuration. [UNDER DISCUSSION]

It is worth-to-mention, that this logic is an extension of what we currently offer as at the moment in both:

  • Filtering Logic (More filters are required in UC4.1)
  • Stock Locator Grouping Logic (grouping by Equipment is not currently supported, but only by Make/Model/Color/Trim)


(*) By configurations above, we mean that the combination of Make-Model-Color-Trim-Equipment(Extras) is what makes an available configuration unique, in order to be responded as an individual line.


Sales Flow (Sales Deal Jacket API)

UC5. (DESCOPED) As a sales advisor, I can simulate the prices of the Document lines in order to retrieve from SAP any added discounts.

UC6. As a sales advisor, I can Start a lead from Configurator or Stock Locator vehicles

Stock Locator Interest Flow:

  • UC6.1. As a sales advisor, I can define the Customs Classification (πολυτεκνικές, πρεσβείες).
    • [UNDER DISCUSSION]

Effort Est (OD Integration): 1d

Effort Est (ODIL): 1d 


  • UC6.2.As a sales advisor, in the Sales Process Page, right before creating an order (from Stock Locator Interest), I need to check that, there is - at least - one such Model Configuration (Model Tree Codes + Equipment) available for "reservation" in Autohellas's Stock. (by checking if a Vehicle could be reserved (by Vehicle Configuration)).
    • Acceptance criteria: I need to see (an error) a notification, if a stock locator vehicle (configuration) in sales is not available for reservation.
    • Acceptance criteria: DSW should always validate that a stock vehicle (configuration) is not internally reserved

Effort Est (OD Integration): N/A

Effort Est (ODIL): N/A 

Configurator Interest Flow:

  • UC6.3. As a sales advisor, I can send in VehicleToSell the Configuration data (only Codes of Model, Options) of the vehicle, so that the Importer system can open a correctly billed order.
    • (Only Model and Option Codes are taken into account. Orders are billed based on the to-date option model prices as are in SAP at this moment and may vary from Model/Option Prices that OD has at the same exact time).

Effort Est (OD Integration): N/A

Effort Est (ODIL): N/A

Both Interests (Stock & Configurator):

  • UC6.5. As a sales advisor, before creating a sales order, I can add more than one customer. 
    • Acceptance Criteria: All referenced BPs are sent down before the order in order to be known to SAP. (Based on CR1)
  • UC6.6. In DSW when before a sales order, I can choose if the importer is going to bill the Dealer or the customer. (eg. new property isDealerBilled needs to be added to Document)
    • CR4. New field on Document model is required that reflects if the importer is billing the Customer or the Dealer Company.
    • CR5. New Transition required view (on Tenant) is required,  in which the user can select if the Dealership is the BillTo customer. (ie. if the Dealership is billed by the importer)


UC7. As the importer System (SAP VMS), can systematically update open orders the following Information:

  • VIN
  • Importer Status
  • PaymentCode (RF)
  • ArrivalDate
  • SalesInvoiceDate
  • VehicleLocation
    • (CR). New Update type on UpdateCompoOffer
  • RemainingAmount
    • (CR). New Update type on UpdateCompoOffer

Acceptance criteria: This is only presentational

Acceptance criteria: The information is only populated from the Importer system to the DSW and not vice-versa.

Effort Est (OD Integration): 2d

Effort Est (ODIL): 1d


UC7.1. As the importer System (SAP VMS), I must create a Customer vehicle to DSW, when the vehicle delivery process is concluded, via the vehicle API. (see UC5)

  • Acceptance Criteria: User should be able to see the vehicle in DSW Inventory gridlist
  • Acceptance Criteria: Each customer vehicle should have License Number, First registration Date & VIN

Effort Est (OD Integration): 0.5d (Tenant Specific API Validation is needed here to support the UC Acceptance Criteria)

Effort Est (ODIL): N/A


UC8. [Sales Order Update] As a sales advisor in DSW, upon customer vehicle delivery, I can update and send to SAP the following info:

  • FirstregistrationDate   (CR)
  • LicenseNumber            (CR)
  • OrderDeliveryDate      
  • DocumentStatus           (CR)
    • Sales Order Status Update
    • Document Status is a static mapping


Effort Est (OD Integration): 2d (Tenant Specific )

Effort Est (ODIL): 1d



UC9. [Change Order service] As a sales advisor in DSW, viewing any open order, I can change the underlying vehicle and eventually Change the Order.

  • Acceptance criteria: Order must be not-locked by the Importer
    • This info is retrieved by GetImporterStatus response and based on the "IsLocked" flag
  • Acceptance criteria: In the case of a locked order, DSW must show the reason as replied by the importer (ie. "Model Discontinued", "Price Invalidated"). 
    • SAP/VMS is the only responsible to hold this "Order Locking" business logic and respond the Reason as "Text"

Effort Est (OD Integration): 1d

Effort Est (ODIL): N/A



UC10. [Update Order Status] As a sales advisor in DSW, I can Cancel an Order only if the Importer Status is cancellable and update the Status in VMS

  • Acceptance criteria: Order must be cancellable by the Importer
    • This info is retrieved by GetImporterStatus response and based on the "IsCancellable" flag.
  • Acceptance criteria: Order Closing Reason must be populated to VMS

Effort Est (OD Integration): N/A

Effort Est (ODIL): N/A


Fundamental Agreements

SAP/VMS is the only responsible to hold this "Order Cancellable" or "Order Locking" business tier logic and always respond the Importer Status Reason to be shown to the DSW User.


Purchase Flow (Purchase Deal Jacket API)

N/A


Service Orders flows (Aftersales API)

Scope Analysis > Planned for  

Go-Live: Planned for Phase 2.

  • Exact same WF/Process as in Autohellas.
  • Exact same Integration Scope as in Autohellas.
    • A GAP is to be estimated by ThinkRit as the Old ODIL's logic needs to be transferred to Neuro Ap [Effort for OD = 0]


Effort Est (OD Integration): N/A

Effort Est (ODIL): 

  • Environment Setup 3 MD
  • Custom Adapter 10 MD
  • SIT 2 MD
  • UAT 3 MD



Agreements

  • No DMS,
  • Oracle DB
  • Exists in KIA/HYUNDAI


MISCELANEOUS

Workshops:

  • Effort  OD: 2.5d (2.5d spent)
  • Effort  ODIL: Will be Charged on T&M Basis  Actual until 20/07: 0,5d

Status Meetings:

  • Effort  OD: 4.5d (2d spent)
  • Effort  ODIL: Will be Charged on T&M Basis  HLE 2FTEs x 40h= 8d

On-Site project/scope analysis

  • Effort  OD: 3d (3d spent)
  • Effort  ODIL: Will be Charged on T&M Basis  Actual until 20/07: 9d (3d spent x 3 FTEs ) 

On-Site Testing/SIT-Support

  • Effort  OD: 2w (2.5d spent)
  • Effort  ODIL: Will be Charged on T&M Basis  HLE 1W

On-Site Testing/UAT-Support

  • Effort  OD: 1w 
  • Effort  ODIL: Will be Charged on T&M Basis HLE 1W

Environment Setup

  • Effort  OD: 1d
  • Effort  ODIL:
    • 3 ODIL environments x 1,5 d = 4,5 d                       
    • SAP Login/Authentication  1d




Write a comment…