Openbravo Forum End of Life Notice

Dear Openbravo Forum User,

Because of continued very low usage we decided to stop the forums on 31st of August 2017

In case of questions: webmaster "at" openbravo.com

Scope

<<

Richard Morley

Posts: 52

Joined: Tue Mar 17, 2009 8:48 am

Post Wed May 19, 2010 4:29 pm

Scope

Feedback from Paolo:


Here are my comments.



Rather than starting with the use cases I would start with a characterization of the personas that we are trying to target. Here is what I would consider:



  • Sales person taking an order in front of a in person customer

    • Think of the person that sold you a car last time you bought one at a dealership

    • NOTE: these are relatively low volume situations (see comment below on we are an ERP, not a CRM)



  • Sales person taking an order with the customer on the phone

    • This is not a call center situation.  The user here is not a heads down order entry person but somebody that performs different tasks and that happens to take an order on the phone.

    • A possible situation is: you just bought a car and went home; at that point, you realize that you made a mistake in not buying the extended warranty and you call the guy that sold you the car. With you on the phone, he describes you the various options and prepares a new sales order. When the order is ready, he emails it to you for confirmation (or faxes it), you approve it and call him back to confirm. At that point, he completes the order.



  • Sales person visiting a customer and proposing a product. When he gets back to the office, he prepares an order and sends it to the customer for confirmation.

    • Think of Moncho taking orders for Openbravo professional subscriptions



  • Administrative person receiving an email from a sales person asking her to create a sales order for a deal that just closed

    • Think of Elizabeth receiving emails from Frank or Andreu



  • Sales person reviewing past orders for a particular customer in order to prepare a meeting with the customer

    • Think of Frank



  • Sales person reviewing orders he booked in this quarter to see how much of his quota he achieved

    • Think of Frank



  • Sales manager reviewing orders booked by his team

    • Think of Steve or Cees



  • Sales manager reviewing an order that was placed on hold for some reason (either credit hold or non compliance) and wanting to approve / cancel the order (in some companies, sales managers have the authority to do it)

    • Think of Steve or Cees



  • Shop owner reviewing orders that came in electronically through a web store

  • Credit department person reviewing an order that was placed on credit hold

    • Think of Oscar



  • Finance department person responding to a customer inquiry complaining that the invoice they received does not match the order they placed

    • Think of Vanesa



  • Warehouse manager reviewing the orders that have been taken recently and that have not yet been shipped.


I strongly recommend (in fact, I require it) that you listen to the Accounting Control for Order Entry podcasts (we must ensure these controls either out of the box or through configuration):





(NOTE: the full list is available at:


http://accountingtools.com/Podcast_Sign_Up.html

)






Let's keep in mind that we are working on an ERP, not a CRM so the following personas should not be considered:





  • Call center person spending a shift taking sales orders over the phone (I know that some of our customers use Openbravo - in some modified form - for this purpose; for example: Frilac. This is a specialized function and I am OK if it is not supported by the reduced core of the Community Edition and it requires an alternate data entry screen delivered by an extension module)

  • Mobile sales agent: sales person taking orders in front of a customer at the customer premise (example: the guy selling door to door)


With regards to the documented use cases:





  • Fast order entry with total price promise

    • I am not sure we need customer and product selector that remember the most recent selections. The new selector behavior seems to be enough to me.

    • It is very important that the user is able to register a new customer in the middle of this flow

    • It would be desirable that once the order is taken the user can easily rearrange the sorting of the lines. Putting the most expensive product on top usually result in more professionally looking orders when printed or emailed

    • Keep in mind the current functionality that should be preserved but improved:

      • Copy order allows to copy from a previous order (or a template)

      • Copy lines from (to be renamed: I proposed Quick line entry) that allows to select the products that the customer has been recently ordered (within a specific period of time that is defined at business partner level - should it be more generic than that? it is a pain to define this value business partner by business partner). This is very useful for businesses having repeating customers.

        Also Pablo Sarobe had an excellent idea: this screen can be enhanced to additionally (by checking a flag or something like that) display all products in a given price list, regardless of the order history of the customer - this way we would be able to cover customers that do not always buy the same products.

      • Printing or emailing order





  • Stock available to promise (ATP)

    • This is very important functionality

    • We need to be aware, however, that implementing ATP is not trivial and requires a lot of back end calculations. Currently this functionality is in the backlog but not scheduled for 3.0 (we have it planned for 3.1)

    • We therefore need to design the flow without it for 3.0 but in a manner that allows us to add ATP as an extension on top of 3.1

    • The current functionality - which should be preserved - shows current stock availability but not future planned availability (ATP)

    • A possible improvement to be done in 3.0 is to show, next to the current stock availability, the unreserved quantity (currently the product places the reservation when the SO is complete but when create a second SO the reserved quantity is not considered when the user reviews availability - example: on hand quantity is 100; first order is for 10 and 10 are reserved; when the user places a second order, they still see 100 available units while they should see 100 units in stock, 90 available).

      This is very useful to handle scenarios where your best customer wants to order something that has been reserved for another order. In that case, you can make the choice to "bump" the previous order (NOTE: the process does not need to be fully supported in the product - the most important thing is that the sales persons see the situation - they can then handle it out of the system by calling the warehouse manager that does the right thing)



  • Order Up Selling

    • To me this is not a critical flow to cover by 3.0



  • Customer credit management

    • Given the personas above, the most important thing is to prevent the user from violating the credit limit. Currently the system raises a warning if the order violates credit limits but users can ignore the warning and continue. That is not correct.

    • Instead the order should go on hold (a credit hold is placed on the order) and only a person with the appropriate level of authority (perhaps the sales person herself) has the authority to remove the hold.

    • Holds should be removed automatically if conditions change

    • Having the system suggesting the next action to avoid the hold is desirable but not mandatory for 3.0. I would recommend to leave it for a future release.




Additionally, the following should be considered. These are not use cases but features - I think we need to evaluate use cases that require these features (I am pretty sure that we need them but we should not bypass the process so we need to define use cases and see if they are legitimate for the above personas):





  • Order close process

    • Currently we have a close order process (you close the order when no further actions are needed / allowed, typically when it is fully shipped or invoiced) but it is completely manual (you need to close order by order). This results in poor control of the order documents and we should consider automating it (when the order is fully shipped and fully invoiced - or within a given tolerance - close it automatically)



  • Split order to create a back order (i.e. customer buys paper and pen but only paper is available and has been shipped - the current order should be closed with some unshipped quantities and a new order is created for the unshipped portion)

  • Ship this order (initiate the shipping flow for this document)

  • Invoice this order (initiate the order flow for this document)

  • Create return for this order: from a sales order, users should be able to initiate a return flow. There two flavors:

    1. A customer return document (RMA or Return Material Authorization) is created, approved and sent to the customer. The customer can send the material back only with the RMA and the material is accepted in receiving only if it is accompanied by a valid RMA number - listen to http://media.libsyn.com/media/stevebragg/Episode7RR.mp3 for details. Once the RMA has been received, a customer credit can be issued or a replacement can be sent.

    2. A customer return document is created and the return is created at the same time. In this case the RMA is not a control document but serves for the purpose of tracking.



    • In both cases, the RMA should be linked to the original sales order (probably the link is at line level)



  • Order matching - match a sales order to an independently created sales invoice

  • Price list compliance control. Some businesses allow sales people to offer arbitrary discounts that they negotiate; others require strict compliance with what the system calculates based on price lists and standard discounts. You should be able to configure Openbravo to operate both ways. This can get quite complex as the compliance level could be defined by product, sales person, amount, customer, etc. For the sake of simplicity, I suggest to add this as a flag on the document type so that users can set this control with some degree of flexibility without having to do anything complex. In addition, we should plan for an additional step during the sales order completion process where people could plug in through an extension point any sophisticated compliance checking.

  • Contextual information: while creating an order users should be presented with contextual information such as customer value, customer class, past order volume by period, etc. The issue here is that before you can display contextual information, you must have it available in your system and Openbravo does not have much to show in this regard. I think that in this case we need to design the UI with something in mind that most likely is not going to be available by the time we ship 3.0. Also, this is a great opportunity to plug in widgets delivered by extension modules. For instance, there could be a module that offer loyalty management based on points (for example: airline miles); that module should provide a widget that display the point status of the customer and a system administrator should be able to configure the system to show that widget in the context of a sales order.


Paolo

<<

Richard Morley

Posts: 52

Joined: Tue Mar 17, 2009 8:48 am

Post Wed May 19, 2010 4:30 pm

RE:Scope

Comment from Rob:


Here is one more, which is a variant of nr.4 below.



  • Administrative person receiving an automated email from an e-commerce or payment platform for an order that was placed and paid. She now has to create a sales order, the invoice (?) and register that payment was received.

    • Think of Elizabeth receiving emails from the Plimus e-business platform for a training that was sold online.



<<

Dmitry Mezentsev

Posts: 280

Joined: Wed Mar 18, 2009 7:25 pm

Post Fri May 21, 2010 9:30 am

RE:Scope

 
Here are my several cents.

 

* I added Introduction chapter with a BPMN link to the Order to Cash business process into the Functional Specs.

 

* In terms of characteristics and customer stories.

** I think following roles like Sales person or Administrative person are also involved in different clarification / complain management from the Customers. For example, Client is calling and complaining that her order is not arrived or she received less then expected or different items.

Based on that system should allow to

*** Search through Sales Orders effectively, for example not only based on the SO number, BP and time but also products ordered (in case Customer is mentioning I ordered these products and they are not arrived),

*** Easy track from the Sales Order status of all related activities / documents: Shipments, Invoices; Created or not, Sent or Not (this is one of the items from our current backlog), Payed or not.


 


* In the current Sales Order we also manage quotations by specifying different document type. It is agreed that it is not the best practice so I guess we would like to avoid it in the new Sales Order. If this is the case then we should add to the Roadmap of 3.0 separate task about managing quotations.

** If we do so I think we need to support scenario of adding products and calculating price without entering the business partner which can be related to the first scenario from Paolo´s email "Sales person taking an order in front of a in person customer". Sales person is preparing quotation (or order) by entering products, reviewing with customer, changing it, agreeing on price and only after agreement is reached filling in BP (creating new from the same flow).

* Actually similar situation is with RMA. Paolo mentioned about having a button at the Sales Order screen to launch this flow. I think we can design it and have it for future use but hide in 3.0 and still use negative Sales Orders to manage RMAs.

 

Also yesterday I browsed several feature requests that seems valuable for me:


* 0010629: Invoicing terms should be specified at line level on a sales order

* 0006323: RFE: Sales Order: Add 'Scheduled Delivery date' at line level

* 0006326: RFE: Sales Order: Add 'Customer Request Date'

* 0005913: Default sales order delivery location from business partner ship-to-address


<<

Rob Goris

Posts: 309

Joined: Wed Mar 18, 2009 7:26 pm

Post Fri May 21, 2010 7:46 pm

RE:Scope

 I´ve distilled the personas and added typical tasks for those and copied them into the functional documentation.  I´ve interviewed a couple of representatives of the personas, more to follow.

<<

Jan Hendrik Mensen

Posts: 158

Joined: Wed Mar 18, 2009 7:25 pm

Post Thu May 27, 2010 7:43 pm

RE:Scope

Just a quick note on what functionality I could use in sales:


+ sales bill of material: I enter one material number, but this actually a container for 3 products that make up a bundle. In the sales order I can actually see what materials belong tho this single product container and preferably also ATP.


+ sales contracts: customer value and/or quantity contract that customer can call of from. Customer can call of limited quantity for a set price. If contract expires normal prices are valid. Sales orders are called of withr eferenceto contract. Open quantity on contract can be tracked.


+ Cross-selling: suggest complementary products.


Regards,


Jan Hendrik



Post Edited by mensenjh at 05/27/2010 18:45
<<

Rob Goris

Posts: 309

Joined: Wed Mar 18, 2009 7:26 pm

Post Wed Jun 02, 2010 4:19 pm

RE:Scope

 Find attached a first scenario for 


(1) Jim, The Computer Seller.



Post Edited by rgoris at 02/06/2010 18:29
Attachments
eso-01-jim-v0.1.pptx
(974 Bytes) Downloaded 153 times
<<

Paolo Juvara

Posts: 346

Joined: Tue Mar 03, 2009 7:43 pm

Post Wed Jun 02, 2010 7:03 pm

RE:Scope

Rob,


excellent job, as always.


I really like this scenario and how it is implemented. I only have a few small comments:


1) If the customer has some level of entitlement to discount, like in this case the frequent flyer membership, rather than entering a manual discount, Jim would typically pick a different price list that automates the discount policy.


2) Although Herman might declare himself as a new customer, an existing record might already exist for him (perhaps he did business with the company already and he forgot about it or he did business with another company that has been acquired by this one... ). Duplicate customer records are a significant issue from a data quality perspective, so it would be very good to add some level of duplicate checking when Jim tries to save the record for Herman. Ideally the system would search based on unique identifiers like the tax ID of the customer but also would perform fuzzy matching of non unique identifiers like name, address or phone number and propmpt Jim that a customer with for instance a similar name already exists in the system and would ask whether he wants to create a new record or update the existing one.


3) The system should stop Jim from making a mistake and trying to complete the quote with the Unkwonw customer. Jim should be able to save the quote without the specific customer name but not complete it or convert it to a sales order.


Paolo


------------


Follow me at http://www.google.com/profiles/pjuvara#buzz

<<

Jan Hendrik Mensen

Posts: 158

Joined: Wed Mar 18, 2009 7:25 pm

Post Wed Jun 02, 2010 7:52 pm

RE:Scope

Hi Rob,


We just happen to write the functional design for a multi-store computer retailer. We are looking at webshop, ERP and POS. For their store sales your scenario is very similar except typically in a store they work from the POS and scan products and loyalty cards. Hence I think your scenario could be further improved by thinking of integrating it with POS functionality. Store sales in ERP feels kind of retail unfriendly. Of course it is a matter of design, but at the same time stores need integration with their cash register and payment gateways, etc.


Ideally the store sales tool would offer cross-selling functionality that is also offered to customers shopping on the web-store, however now the advice is presented to the store clerk instead of customer direct.


Also in our case, customers will pick-up web orders. So we need to check the system for existing orders (bar code) and reserved inventory for that order. THis information all needs to be presented in the POS, data being fed from ERP.


Openbravo has the unique ability to integrate ERP and POS further and also integrate it more with webshops. We are going to make an effort and I don't mind putting some minds together for this.


Regards,


Jan Hendrik


 

<<

Rob Goris

Posts: 309

Joined: Wed Mar 18, 2009 7:26 pm

Post Thu Jun 03, 2010 9:49 pm

RE:Scope

@ Jan-Hendrik: thanks for the input. Integrating ERP and POS for the store scenario sounds like a great idea, not sure this is on the roadmap anytime soon though. Please bear with us and help me review the more down-to-earth common scenarios (that most of our users will use) for the moment. When we got that one tackled we can start thinking about more advanced functionality.


@ Paolo: good points, I have updated the scenario accordingly


Find attached a newer version of Jim, The Computer Seller.


 


 

Attachments
eso-01-jim.pdf
(974 Bytes) Downloaded 135 times
<<

Jan Hendrik Mensen

Posts: 158

Joined: Wed Mar 18, 2009 7:25 pm

Post Fri Jun 04, 2010 1:05 pm

RE:Scope

Hi Rob,

What you call more down-to-earth is essentially business-to-business scenarios. As soon as you focus on consumer goods I bet (but will not academically provide proof for it ;) ) majority of sales is done through sales channels: store and internet. I understand the limiting factor.



In that case your process seems perfect :) (although also here a cross-selling function would be nice). Also in most medical companies it is customary to sell one item and add a second automatically (with or without cost). E.g. sell 2 liters of insuline and also automatically add to the order 1000 syringes and 1000 needles. I am aware that you focus on process and user experience, but i'll make you aware anyway.



Regards,

Jan Hendrik
Next

Return to Discussion

Who is online

Users browsing this forum: No registered users and 1 guest

cron
Website Terms


Designed by ST Software for PTF.