The hybris documentation about this extension is so detailed, that it may take some hours to read it throughly. It wrote this summary for the Hybris eCommerce certification.

Key Concepts

  • Base Store which offers products from different catalogs (products and classification). It doesn't have a physical address. It may be linked to warehouses to keep track of "web" stock.
  • Point of Service: It is a physical branch store with an address. It may be linked to warehouses to keep track of the "in store" stock.

Services

 They shouldn't be used in production without customization.

Order Cancel Service

  • An order can be canceled as long as it wasn't shipped.
  • Digital products cannot be canceled
  • A recalculation of the orders is done for partial cancellations

Return Service

  • The customer calls a customer representative who looks for the order, check the goods and ask for authorization to accept them. The goods are sent to the inventory.
  • Creates, returns and process
    • ReturnRequets for an order
    • Return Merchandise Autorization (RMA)
    • Replacement Order with the RMA value
    • Refund based on order entries
  • Checks if a product is returnable using a ReturnableCheckStrategy. The default implementation allows the return if the product wasn't returned yet.
  • An implementation for ReturnEntryProcessor, ReplacementOrderProcessor and RefundOrderProcessor must be provided 

Refund Service

  • The call center agent checks if the customer could receive a replacement or a refund for the returned goods.
  • It works together with a returnRequest following this flow:
    • With OrderModel createRefundOrderPreview(OrderModel original) a clone of the original order is created. This allows the system to preview the refund
    • Create refundEntryModels with the quantity and the orderEntries to be refunded.
    • Use the method void apply(List<RefundEntryModel> refunds, OrderModel order) to subtract the refunded products from the preview order. The order is recalculated by this method.
    • If the customer accepts the refund, the method void apply(OrderModel previewOrder, ReturnRequestModel request) is called to modify the original order of the return request.

Order Versioning

This functionality is privided by the OrderHistoryService. Please see https://wiki.hybris.com/download/attachments/141793368/OrderHistoryVersioning.png?version=1&modificationDate=1260982346000&api=v2 the classes involved.

  • The OrderHistoryEntryModels are used to register the steps of the order. They are created using the model service and associated manually to the order. No new version of the order is created.
  • When the order is modfied and a snapshot of the old states is required:
    • Call OrderModel createHistorySnapshot(OrderModel paramOrderModel) to create a clone of the current order. This clone would have a version number and will be associated to the current order through the field originalVersion.
    • Make changes to the original order. It doesn't have an version number and it represents the actual state of the order.
    • A OrderHistoryEntryModel with the cloned order as the previous order and the actual order as order may be created to document the changes.
    • Call void saveHistorySnapshot(OrderModel clonedOrder) to save the order created by createHistorySnapshot. Jalo attributes like the tax total values and the calculated flag are updated in this step.
    • Save the modified order and the order history entry using the model service. 
  • When searching for orders, remember that the actual order doesn't have a version number. Orders with version numbers are snapshots.

Order Splitting

  • The OrderSplittingService defines the interface used by this service. It contains implementations of SplittingStrategy.
  • The default strategies are SplitByAvailableCount, SplitByDeliveryMode, SplitByNamedDeliveryDate and SplitByWarehouse.
  • WarehouseService: Contains utility methods for the splitByWarehouse strategy.
  • Consigment: Each group of order entries sent to a warehouse which make up a delilvery.
  • ConsigmentService: Creates consigments and choose the warehouse for each one of them. The default implementation choose one randomly.
  • There are also order entry groups which are not exactly the same as consigmentshttps://wiki.hybris.com/display/accdoc/Pickup+In+Store+in+the+hybris+Commerce+Accelerator
&nbsp Order Entry Groups Consignments
Applies to Cart and Order entries Order entries
Grouping by A charateristic like the delivery address or pickup location  By the delivery location
 Further splitting?  No  Yes, a consignment can be splitted
 Has it owns status?  No  Yes
 Result of one order entry  Maximal one group  It may result in many consigments
Are applicable to every entry? Yes, each entry must belong to a group

No, some entries may no have a consignment. In that situation could this happens?

Persistent? No, it is a DataObject Yes, it is Hybris Item Type

Warehouse Integration

  • Hybris may place orders on the warehouses (Process2WarehouseAdapter.prepareConsignment and shipConsignment methods)
  • The warehouses may inform Hybris about updates (Warehouse2ProcessAdapter.receiveConsignmentStatus method)
  • An implementation for these two interfaces must be developed.

Replenishment and Order Scheduling

  • It is iimplemented in the basecommerce extension but it belongs to the order management for B2B
  • The customer can create an order which will be place in the future.
    • The developer has to clone an existing cart or order
    • A better alternative is to use the ScheduleOrderService which creates CronjobModels. A trigger must be provided. The methods createOrderFromOrderTemplateCronJob and createOrderFromCartCronJob use an order or a cart to create a new order which is scheduled in the future. createScheduledOrderCronJob creates recurring orders. For this to work, the default implementation of OrderUtility must be extended and the method runOrder(OrderModel order) must be written. It may also make recurring orders based on a schedule. These orders are based on a previous order or basket.

Store Locator

  • The geographical information is saved in a pointOfService.
  • Any item to be searched must be associated to a pointOfService.
  • Each point of service may have an OpeningSchedule with the opening times.
  • A defaultLocation associates a pointOfSale with GPS coordinates.
  • A locationDTOWrapper associates a POJO address with GPS coordinates.
  • The interface GPS represents a geographical position
  • LocationService: Finds the list of nearest pointOfServices (Locations) to a town, postal code or GPS coordinate. 
    • Getting locations from neighborhood
    • Getting locations near a temporary location, e.g. my current location.
    • CRUD operations on locations
  • LocationMapService: It finds the same as LocationService but it returns a map.
  • GeoWebServiceWrapper: This interface is used to integrate geocoding services.
  • There is a default integration for GoogleMaps. It generates geographical information from addresses. It uses two methods:
    • Javascript for geocoding the address entered by the customer
    • HTTP Requets for geocoding points of services using the geocodingCronJob.
  • Google don't allow to save the GPS information for more than 30 days and it must be used in a Google Map. To meet these legal requirements a mock implementation is shipped with the basecommerce extension
  • MapService: Generates maps with the given points of service.
  • RouteService
  • Use Case
    • Geocode the address of the customer
    • Get nearby points of services
    • Use them to create a map
    • The customer choose a point
    • Return the route to that point.
  • To use the extension the locations of the base store must be configured. The geocodingCronJob will then get the GPS coordinates.
  • Steps to activate the buy and pick up functionality: https://wiki.hybris.com/display/tr52/Enable+Pickup+In+Store

 Deep Linking

  • Translates a short URL into a long URL
  • deepUrlModel: It is used for the short URL generation
  • A DeeplinkUrlRule generates an URL from an Item.
  • DeeplinkUrlService: Generates long and shorts URLs from an Item.
  • GenericDeeplinkUrlServlet: Detects a short URL and redirects the request to a long URL.

Fraud Detection

Explanation of the data model: https://wiki.hybris.com/display/release5/Fraud+Detection

  • FraudService: Generates a report for a customer, an order or a cart (any abstract order) using a given provider. It returns a non-persistent response.
  • Symptoms are recognized and their points are sum up to calculate a score. This score doesn't trigger any decision.
  • FraudReport: It persists the response from FraudService. It contains a list of FraudSymptomScoringModel. You would have to create a converter from the fraudServiceResponse to the FraudReport if you want to save it into the database.
  • FraudServiceProvider: Interface for third party providers. It is used by the Fraud Service.
  • OrderFraudSymptomDetection: Basic Implementation of symptoms provided by Hybris. It doesn't use any third party services.
    • BlackListSymptom, WhiteListSymptom, FirstTimeOrderSymptom, DifferentAddressesSymptom, OrderThresholdSymptom and OrderEntriesSymptom are the default symptoms.
    • There aren't any default symptoms related to the customer.
  • The fraud detection could be done in an action in a workflow.

 Based on Hybris 5.3

Add comment


Security code
Refresh