Announcement

Collapse
No announcement yet.

OTM 5.5.03: Implementing Multiple Rate Models within 1 domain

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • OTM 5.5.03: Implementing Multiple Rate Models within 1 domain

    Hi everyone,

    I have an interesting implementation requirement and would like to find out if any of you guys have done anything similiar.

    Requirement
    The customer is a 3PL that manages 20+ customers (in the hi-tec / bearings / automotive spares business). They want to implement OTM for all these 20+ customers. Because of their organisational setup, they have a team of 3 people currently managing these 20+ customers. Also, this team of 3 people are backups for each other. Hence, all 3 people need to login to 1 single domain.

    Also, they want to be able to have separate sell-side models for each of these 20+ customers. They have a common service provider but the buy-side model may be different for each of these 20+ customers because of contracts established.

    Solution
    1) Create 1 single domain
    2) All 20+ external customers will be implemented in 1 single domain - with standardised order input
    3) Sell Side service provider = 3PL customer
    • Sell side Rate Offering will be different for each of the 20+ customers
    • Sell side Rate record under the rate offering will implement customer specific sell side billing model / logic
    4) Buy Side service provider = 3PL's service provider
    • Buy side Rate Offering can be different for each of the 20+ customers
    • Buy side Rate record under the rate offering will implement customer vs service provider specific buy side billing model / logic
    5) Orders from the 20+ customers will be interfaced into OTM. When the order is received into OTM, business rules will help determine which buy side / sell side rate offering is to be used for the order.

    Would like your kind inputs on the following:
    1) Do you think this model will work?
    2) Have you implemented something like this before and what were the possible issues / concerns that might happen?
    3) Given the requirements, is there another better and cleaner way to do this in OTM?

    Thanks very much for all your time and help! Apprecaite any replies!

    Regards,
    Ian

  • #2
    Re: OTM 5.5.03: Implementing Multiple Rate Models within 1 domain

    Hi Ian,
    I didn't read through the whole detail of your requirements.
    But I think maybe you can try
    Corporation Profile (Rate Offering) + ORDEROWNER (Involved Party) + ADA
    --
    Joseph Liang
    MavenWire APAC
    http://www.mavenwire.com/

    Comment


    • #3
      Re: OTM 5.5.03: Implementing Multiple Rate Models within 1 domain

      Hi Joseph,

      Thanks for the quick reply! Could you please kindly elaborate abit more about Corporation Profile and ORDEROWNER? Also I understand that ADA is Automatic Data Association - so for that I think I understand where you are coming from.

      But I am unclear about Corporation Profile and ORDEROWNER.

      Apprecaite your kind help!

      Regards,
      Ian

      Comment


      • #4
        Re: OTM 5.5.03: Implementing Multiple Rate Models within 1 domain

        1) Create Location (including primary Contact) and Corporation for each customer

        2) Create Corporation Profile to be compatible (or not compatible) with one (or many) Corporation.

        3) Assign Corporation Profile to Rate Offering

        4) Assign (manually or via ADA) Location, defined in (1), as Involved Party Location and ORDEROWNER as Involved Party Qualifier to Order.

        Please note that if you decide to use this feature, all rate must have Corporation Profile. Otherwise, the result may not be suitable for your case.
        For example, if you have:
        Corporation: C1 and C2
        Corporation Profile: C1_ONLY (compatible with C1)
        Rate Offering:R1 (C1_ONLY) and R2 (no corporation profile)

        If Order has not ORDEROWNER, both rates are valid (if glog.order.rule.pass_corp_profile=true).
        If Order has ORDEROWNER=C2, only R2 is valid.
        If Order has ORDEROWNER=c1, both rates are valid.


        Additonally, there are two glog properties related to this feature:
        glog.order.order_owner.inv_party_qual
        Determines which involved party qualifier will identify the owner of the order.
        An involved party qualifier is associated with a location, which can be a customer. A customer can be associated with a corporation profile. A corporation profile may be associated with a rate offering or itinerary so this property can affect rating.
        For example, say you set this to ORDEROWNER. When an order has an involved party qualifier of ORDEROWNER, the rate offerings and itineraries which have corporation profiles compatible with the involved party location will be valid for rating.
        When an order has as an involved party qualifier of ORDEROWNER and the rate offerings and itineraries do not have corporation profiles (no constraints), it will be valid for rating.
        If the order has no involved party qualifier, and the rate offerings and itineraries do not have corporation profiles, the order will again be valid for rating.
        If there is an involved party qualifier and the rate offering and itineraries have corporation profiles that are not compatible, rating will not occur.
        glog.order.rule.pass_corp_profile
        Note: When true, it is compatible with OTM releases prior to 5.5.CU3. When it is false, it uses the new CUSTOMER concept differentiating a customer from a domain.
        When true, ItineraryCorporationRule and RateOfferingCorporationRule will pass if there is a corporation profile defined on Itinerary or RateOffering but there is no ORDEROWNER on Order or no customer entered from Rate Inquiry/International Rate Inquiry.
        When this property is set to false, ItineraryCorporationRule and RateOfferingCorporationRule will fail if there is a corporation profile defined on Itinerary or RateOffering but there is no ORDEROWNER on Order or no customer entered from Rate Inquiry/International Rate Inquiry.
        --
        Joseph Liang
        MavenWire APAC
        http://www.mavenwire.com/

        Comment


        • #5
          Re: OTM 5.5.03: Implementing Multiple Rate Models within 1 domain

          Hi Ian,

          The only thing you describe is the relationship clients to sell/buy rates. What about differences in workflow? Would all client orders be processed in the same way? Could orders from different clients be planned on the same shipment?

          Based on your scenario, I would look into the option to create sub domains for each client. This is a typical setup for 3PLs. It all depends on the analysis of the differences and similarities of the 20+ clients.

          Lourens

          Comment


          • #6
            Re: OTM 5.5.03: Implementing Multiple Rate Models within 1 domain

            Hi Lourens,

            You made some very good observations.

            1) Workflow
            - We will have to define a basic similiar workflow for all the customers. However, there will always be some form of custom workflows required.
            - The most obvious would be to create agents specific to each customer and use that to drive the workflows. However to manage multiple such agents in a single domain would be a nightmare.

            2) Planning
            - Yes it would be possible in the near future that the orders from different clients would be planned on the same shipment. These orders would of course be in the 1 single domain.

            Un-neogtiable Constraints
            1) Because the users don't want to login to a different domain everytime they have to execute an order from a different customer (thats potentially 20+ logins everytime they use the system), they only want to login to 1 domain and be able to plan and execute the orders for the 20+ customers.

            2) We have to be flexible enough to allow customised workflows for each of the 20+ customers.

            Proposed Solution
            1) Create 1 common domain called CENTRAL
            2) Create sub domains from the CENTRAL domain for each customer i.e. CENTRAL/CUST1, CENTRAL/CUST2, CENTRAL/CUST3 ....
            3) All orders, sell and buy shipments, invoices and bills will be created in the CENTRAL domain
            4) All customer specific sell and buy side rate model will be created in the subdomains
            5) All customer specific workflows and customised agents will be created in the subdomains and will listen and activate based on the business objects in the CENTRAL domain.
            6) Agents in the subdomain will set the role to be OBJECT.

            Will this work? Will #4, #5 and #6 be possible?

            Regards,
            Ian

            Comment


            • #7
              Re: OTM 5.5.03: Implementing Multiple Rate Models within 1 domain

              I think your proposed solution is possible if you don't plan to consolidate multiple clients' orders into one shipment.

              That's why we store rates in parent domain and use Corportaion Profile to link customer specific rates.
              --
              Joseph Liang
              MavenWire APAC
              http://www.mavenwire.com/

              Comment


              • #8
                Re: OTM 5.5.03: Implementing Multiple Rate Models within 1 domain

                Hi Ian,
                I had implemented the following model at one of our 3PL implementations:

                Parent domain: This is the planning domain which will have the master data viz. Locations, Buy & Sell Rates, Buy Shipments, Carrier Invoices, Agents

                Sub-domain: Each sub-domain will represent a customer. Customer order's will be in the sub-domain and hence the sell shipments and bills will be in the sub-domains.

                Rating: As explained by other guys, you will have to use Involved Party + corporation profile rule to ensure that buy and sell rates are selected as per customer contracts.

                Planning: All three users can login to the parent domain. They can select all unplanned orders from across the customer (sub-domains) and run a bulk plan. Using corporation profiles on the bulk plan, you can control any possible consolidation between customers. This feature enables you to control which customers orders can be shipped on the same shipment.

                Visibility: Each customer can be given access to their own sub-domains for looking up shipment status or checking bills etc. You need to set-up agent to copy events from buy to sell shipment

                Advantage of this model:
                1) Separate customer domains resulting in simplification of agents, lesser security issues, lesser VPD's etc
                2) possibility of cross-customer consolidation: this is a very powerful capability for a 3PL


                Regards
                Hrishikesh
                7Hills Business Solutions
                Regards
                Hrishikesh Mhatre

                Comment


                • #9
                  Re: OTM 5.5.03: Implementing Multiple Rate Models within 1 domain

                  Hi Ian,

                  In answer to your proposal: you could easily put all buy/sell rates and agents in the same parent domain. I don't see a reason for subdomains in your CENTRAL domain solution. You say that managing multiple client agents in one domain is a nightmare: if you user proper naming conventions (for example same prefix as for client order ID) this should not be a problem, but be aware that agents that are not running in the same domain as the object are known to cause issues.

                  Couple of questions for you though:
                  1) Are you aware that logging into the master domain will give your users full access to the subdomains as well, so they don't need to continuously logout/login?
                  2) Do you have the possibility in the integration to have the orders loaded in the appropriate subdomain, or doesn't your feeder system know this?
                  3) Do you plan to give the 20+ clients access to the system now or in the future?

                  Just a final note: I am a big fan of single domain solutions, as they are the most powerful and I believe the performance issues with VPDs are exaggerated.

                  Lourens

                  Comment


                  • #10
                    Re: OTM 5.5.03: Implementing Multiple Rate Models within 1 domain

                    Hi Joseph Liang,

                    I am Dave, working in Ian's team. I am able to configure it based on your points. Thanks. I have a question to for you. Since now i am able to tie the customer to the rate offering via Corporation Profile and Order Involved Party Location. Is there any way to tie the itinerary to the customer as well?

                    Thanks in advance.


                    Originally posted by josephliang View Post
                    1) Create Location (including primary Contact) and Corporation for each customer

                    2) Create Corporation Profile to be compatible (or not compatible) with one (or many) Corporation.

                    3) Assign Corporation Profile to Rate Offering

                    4) Assign (manually or via ADA) Location, defined in (1), as Involved Party Location and ORDEROWNER as Involved Party Qualifier to Order.

                    Please note that if you decide to use this feature, all rate must have Corporation Profile. Otherwise, the result may not be suitable for your case.
                    For example, if you have:
                    Corporation: C1 and C2
                    Corporation Profile: C1_ONLY (compatible with C1)
                    Rate Offering:R1 (C1_ONLY) and R2 (no corporation profile)

                    If Order has not ORDEROWNER, both rates are valid (if glog.order.rule.pass_corp_profile=true).
                    If Order has ORDEROWNER=C2, only R2 is valid.
                    If Order has ORDEROWNER=c1, both rates are valid.


                    Additonally, there are two glog properties related to this feature:
                    glog.order.order_owner.inv_party_qual

                    glog.order.rule.pass_corp_profile

                    Comment


                    • #11
                      Re: OTM 5.5.03: Implementing Multiple Rate Models within 1 domain

                      Yes, there is Corporation Profile in Itinerary as well.
                      --
                      Joseph Liang
                      MavenWire APAC
                      http://www.mavenwire.com/

                      Comment


                      • #12
                        Re: OTM 5.5.03: Implementing Multiple Rate Models within 1 domain

                        Originally posted by josephliang View Post
                        Yes, there is Corporation Profile in Itinerary as well.
                        Thanks. I manage to test it.

                        Comment


                        • #13
                          Re: OTM 5.5.03: Implementing Multiple Rate Models within 1 domain

                          Originally posted by josephliang View Post
                          1) Create Location (including primary Contact) and Corporation for each customer

                          2) Create Corporation Profile to be compatible (or not compatible) with one (or many) Corporation.

                          3) Assign Corporation Profile to Rate Offering

                          4) Assign (manually or via ADA) Location, defined in (1), as Involved Party Location and ORDEROWNER as Involved Party Qualifier to Order.

                          Please note that if you decide to use this feature, all rate must have Corporation Profile. Otherwise, the result may not be suitable for your case.
                          For example, if you have:
                          Corporation: C1 and C2
                          Corporation Profile: C1_ONLY (compatible with C1)
                          Rate Offering:R1 (C1_ONLY) and R2 (no corporation profile)

                          If Order has not ORDEROWNER, both rates are valid (if glog.order.rule.pass_corp_profile=true).
                          If Order has ORDEROWNER=C2, only R2 is valid.
                          If Order has ORDEROWNER=c1, both rates are valid.


                          Additonally, there are two glog properties related to this feature:
                          glog.order.order_owner.inv_party_qual

                          glog.order.rule.pass_corp_profile
                          Hi Joseph

                          Thanks for the detailed input.

                          Could you please help me understand how to assign location using ADA? As a matter of fact I dont know what ADA is all about.

                          Please guide.

                          Regards

                          Medha

                          Comment


                          • #14
                            Re: OTM 5.5.03: Implementing Multiple Rate Models within 1 domain

                            Originally posted by LourensGlog View Post
                            Hi Ian,

                            In answer to your proposal: you could easily put all buy/sell rates and agents in the same parent domain. I don't see a reason for subdomains in your CENTRAL domain solution. You say that managing multiple client agents in one domain is a nightmare: if you user proper naming conventions (for example same prefix as for client order ID) this should not be a problem, but be aware that agents that are not running in the same domain as the object are known to cause issues.

                            Couple of questions for you though:
                            1) Are you aware that logging into the master domain will give your users full access to the subdomains as well, so they don't need to continuously logout/login?
                            2) Do you have the possibility in the integration to have the orders loaded in the appropriate subdomain, or doesn't your feeder system know this?
                            3) Do you plan to give the 20+ clients access to the system now or in the future?

                            Just a final note: I am a big fan of single domain solutions, as they are the most powerful and I believe the performance issues with VPDs are exaggerated.

                            Lourens
                            Hi Lourens,

                            Sorry for replying late!

                            Thanks for the information. It has given me something more to think about and perhaps a sub-domain concept may work!

                            Appreciate the help!

                            Ian

                            Comment


                            • #15
                              Re: OTM 5.5.03: Implementing Multiple Rate Models within 1 domain

                              Originally posted by Dave Lee View Post
                              Hi Joseph Liang,

                              I am Dave, working in Ian's team. I am able to configure it based on your points. Thanks. I have a question to for you. Since now i am able to tie the customer to the rate offering via Corporation Profile and Order Involved Party Location. Is there any way to tie the itinerary to the customer as well?

                              Thanks in advance.
                              Hello,

                              I just need to know if we have two domains and while planning if rate record is captured by shipment from other domain how to stop shipment to take rate from other domain.

                              can anyone suggest

                              regards,

                              Comment

                              Working...
                              X