Skip to content

Instantly share code, notes, and snippets.

What would you like to do?
**** DÉBUT DU JOURNAL À Tue Dec 14 19:42:03 2010
déc. 14 19:42:25 <inspiran> in typical e-commerce software (and which probably most php'ers would do) is just say 'just update the sales order'
déc. 14 19:42:59 <inspiran> but in lots of business cases, actually in almost all europe companies due to legal constraints, you can not do that
déc. 14 19:43:18 <inspiran> (you are modifying a sales order / invoice which was already sent)
déc. 14 19:43:27 <inspiran> so what do you need to do?
déc. 14 19:43:44 <inspiran> you need to cancel the old sales order and create a new one
déc. 14 19:44:13 <inspiran> (which involves updating the accounting balances twice)
déc. 14 19:44:57 <florian__> yes, I already had to face this kind of problesm
déc. 14 19:45:14 <inspiran> yeah? i am interesting to hear about how you dealt with it
déc. 14 19:46:34 <florian__> it's part of a dev specific app developed for a client
déc. 14 19:46:54 <florian__> but you maybe want to continue
déc. 14 19:47:16 <florian__> sorry to cut the conv
déc. 14 19:47:25 <inspiran> no it's ok, we need to share thoughts florian_
déc. 14 19:47:38 <florian__> yes we're here for this
déc. 14 19:47:41 <iampersistent> yeah, this is good :)
déc. 14 19:47:47 <florian__> but it's not easy to keep focues
déc. 14 19:47:52 <florian__> focused*
déc. 14 19:48:02 <inspiran> for me it's important that before we even go think about a technical design, we first understand order processes in detail
déc. 14 19:48:13 <florian__> yes you're right
déc. 14 19:48:46 <inspiran> this is: understanding various situations, various deviations and have some of a common way of doing things
déc. 14 19:49:14 <florian__> so, indeed we have to think the billing process flexible enough to permit accounting balances for example
déc. 14 19:49:37 <inspiran> true, but that doesn't mean that we need to develop everything, some goods hooks will suffice
déc. 14 19:49:45 <inspiran> i mean, we can't just recreate a full SAP / ERP solutions
déc. 14 19:49:48 <inspiran> that's not the goal
déc. 14 19:50:00 <inspiran> the goal is having which is very scalable in terms of development
déc. 14 19:50:00 <florian__> yes see what you mean
déc. 14 19:50:17 <iampersistent> I'm with inspiran on that, a solid interface for now, build it simple, but we have the ability to expand it in the future to specific needs
déc. 14 19:50:25 <inspiran> yes
déc. 14 19:50:37 <florian__> much than that, we *have* to think the billing process to handle differnet kind of impl
déc. 14 19:50:38 <inspiran> and sf2 is ideal for it
déc. 14 19:50:54 <florian__> yes i think so
déc. 14 19:51:01 <inspiran> another example: 'goods movement processes'
déc. 14 19:51:26 <inspiran> (and after that i'll eat some cheese, i'm hungry)
déc. 14 19:51:33 <florian__> lol
déc. 14 19:51:38 <florian__> mee too
déc. 14 19:51:40 <inspiran> usually if you a products, you want to know where they are
déc. 14 19:51:45 <inspiran> *have
déc. 14 19:51:56 <inspiran> there are various possibilities
déc. 14 19:52:04 <inspiran> a)you have them all in your kitchen
déc. 14 19:52:13 <inspiran> b)you still need to steal it
déc. 14 19:52:41 <inspiran> c)you don't have anything, you just buy it at your supplier when a customer orders
déc. 14 19:53:00 <inspiran> suppose you have your products
déc. 14 19:53:19 <inspiran> then you want to know which products you have
déc. 14 19:53:34 <inspiran> you'll probably use an unique identification to identify your products
déc. 14 19:53:53 <inspiran> at some point, you need to order your products with your supplier/vendor
déc. 14 19:53:59 <inspiran> what reference will you use?
déc. 14 19:54:28 <inspiran> you could say: i'll use the unique reference the vendor gives me
déc. 14 19:54:54 <inspiran> but that's dumb because it often happens that you purchase the same goods from multiple vendors
déc. 14 19:55:20 <inspiran> so ok: you create your own unique product codes, maybe very fancy with barcodes
déc. 14 19:55:36 <inspiran> this means that for a given product, you'll need to maintaing multiple things
déc. 14 19:55:41 <inspiran> -g
déc. 14 19:56:07 <inspiran> 1) for supplier X, 'wonderbra cup B' has supplier id 'WOND-B-1'
déc. 14 19:56:27 <inspiran> 2)for supplier Y, 'wonderbra cup B' has supplier id '12809298309'
déc. 14 19:56:38 <florian__> yeah see what you meen
déc. 14 19:56:48 <inspiran> even more, the relationship with your supplier is _extremely_ important
déc. 14 19:57:28 <inspiran> espescially for e-commerces: most e-commerce businesses i see start just with one or two main suppliers
déc. 14 19:57:35 <inspiran> (because they get higher discounts)
déc. 14 19:57:51 <inspiran> This also means that you actually have to maintain more information than you think
déc. 14 19:57:57 <inspiran> a)general product information
déc. 14 19:58:14 <inspiran> b)product information related to each of your suppliers
déc. 14 19:58:20 <inspiran> think about discounts
déc. 14 19:58:46 <inspiran> or 'if I buy 100 units of wonderbra, i get a 20% discount with supplier Z'
déc. 14 19:59:15 <inspiran> you could probably even already incorporate this in your product price which you show on your site
déc. 14 19:59:49 <inspiran> for instance, some vendors give at christmas special discounts on specific brands
déc. 14 20:00:06 <inspiran> this information has to go *somewhere*
déc. 14 20:00:33 <inspiran> and then there is an even nicer one:
déc. 14 20:00:38 <inspiran> it's called consignment stock
déc. 14 20:01:25 <inspiran> basicly, you have in your kitchen already 100 products from your vendor, but it's not in any of your financial statings, so it's technically not yours
déc. 14 20:01:40 <inspiran> you could say you stole it b)
déc. 14 20:01:44 <inspiran> but how does it works:
déc. 14 20:02:12 <inspiran> you sell 25 products and and the end of the month you communicate to your vendor that you have sold 25 products
déc. 14 20:02:24 <inspiran> now the vendor will send you an invoice for those 25 products
déc. 14 20:02:36 <inspiran> now where are you going to store this information?
déc. 14 20:03:08 <inspiran> it's product level information, and you typically would think of having a column 'stock_quantity' but that's bullshit
déc. 14 20:03:46 <inspiran> in simple e-commerce sites this works fine, but at some point you just one to know more information
déc. 14 20:03:54 <inspiran> (which involves hacking a lot)
déc. 14 20:04:48 <inspiran> a typical consignment stock example: if you buy a newspaper, technically the store from which you have bought it, is not the owner
déc. 14 20:05:15 <inspiran> he just sends the ones he didn't want back, and he is billed for the once he sold
déc. 14 20:05:26 <inspiran> he just sends the ones back he didn't want back, and he is billed for the once he sold
déc. 14 20:05:33 <inspiran> hmm, ignore last sentence :)
déc. 14 20:05:56 <florian__> :)
déc. 14 20:06:12 <inspiran> from a technical point of view: yes, you can have one field for stock quantity, but you need hooks to have *more* information
déc. 14 20:06:39 <inspiran> to finish the story about goods movement
déc. 14 20:06:53 <inspiran> suppose you want sell drugs onlnie
déc. 14 20:06:54 <inspiran> online
déc. 14 20:07:09 <inspiran> (medicins)
déc. 14 20:07:37 <inspiran> warehouse management is *x-tremely* important
déc. 14 20:07:43 <inspiran> let me explain:
déc. 14 20:08:05 <inspiran> for starters, you need to know in which locations each medicin is
déc. 14 20:08:45 <inspiran> and if you move this medicin from one to another warehouse, you are obligied from the government to have an audit trail
déc. 14 20:09:10 <inspiran> This audit trail contains *all* information who the person was who moved the products
déc. 14 20:09:14 <inspiran> who authorized this, and so on
déc. 14 20:09:37 <inspiran> Let's come back to our stock quantity to explain me the relationship
déc. 14 20:10:10 <inspiran> so if you would allow more detail on your inventory, you could say, i'll have a table containing:
déc. 14 20:10:18 <inspiran> warehouse1: product3: 14 units
déc. 14 20:10:25 <inspiran> warehouse: product3: 11 units
déc. 14 20:10:42 <inspiran> now, you could create an user interface which allows the user to update the units
déc. 14 20:11:18 <inspiran> but in this case for medicins, you would really to *somewhere* store in a table who 'moved' it, so who changed the quanties
déc. 14 20:11:24 <inspiran> quantities
déc. 14 20:11:42 <inspiran> (i think this could be easily done with the event dispatcher)
déc. 14 20:11:58 <florian__> yes
déc. 14 20:12:21 <inspiran> but just wanting to show you how people often overlook things which eventually they need to hack
déc. 14 20:12:37 <inspiran> A good example is Magento, developed by Zend members
déc. 14 20:13:04 <inspiran> great technical guys, but their product is just a mess because all these situations were not taken into account early enough
déc. 14 20:13:17 <florian__> that's true
déc. 14 20:13:40 <inspiran> i mean, it's very simple to see what they have forgotten: see the plugins
déc. 14 20:14:10 <florian__> yes
déc. 14 20:14:40 <inspiran> but one the thing i've learned so far: don't hate business logic
déc. 14 20:14:48 <inspiran> they can be *very* craz
déc. 14 20:14:49 <inspiran> y
déc. 14 20:15:04 <florian__> but plugins shouldn't be a way to let userland devs to customize easily a flexible core solution?
déc. 14 20:15:34 <inspiran> honestly, they should be allowed to do it, even the core will faill at some times
déc. 14 20:15:49 <inspiran> i mean, the dependency injection is great way
déc. 14 20:15:55 <inspiran> i mean, the dependency injection is great way to do so
déc. 14 20:15:57 <florian__> yes
déc. 14 20:16:03 <inspiran> i just started some prototyping
déc. 14 20:16:56 <inspiran> on my first sf2 project
déc. 14 20:17:09 <inspiran>
déc. 14 20:17:20 <florian__> cool
déc. 14 20:17:39 <inspiran> on which i am trying to figure out how my way of thinking could be applied for more generic processes
déc. 14 20:18:24 <inspiran> it's a simple case: my customer wants a simple reservation system to book a holiday villa they own
déc. 14 20:18:33 <inspiran> so the process is pretty simple:
déc. 14 20:19:05 <inspiran> customer books villa -> customer pays -> villa is booked and unavailable for the requested period
déc. 14 20:19:22 <inspiran> (it's modeled by the Booking entity)
déc. 14 20:19:41 <inspiran> but i realize that the process can be different if you work with third party agents / booking sites
déc. 14 20:20:26 <inspiran> customer books villa at third party site -> third party sends booking confirmation -> payment is done at end of the month by the 3th party
déc. 14 20:21:21 <inspiran> so what i have done is introduced a 'business object profile' which can hold information for both scenarios (or others which i don't know of yet)
déc. 14 20:21:47 <iampersistent> if I can interject here briefly
déc. 14 20:21:52 <inspiran> sure
déc. 14 20:22:22 <iampersistent> I think that this project is a great example of a product and order flow that is outside of what most people thing about for ecommerce
déc. 14 20:23:00 <iampersistent> so this is coming back to what you are working on florian__ with the product/product mgr
déc. 14 20:23:03 <florian__> totally agree
déc. 14 20:23:34 <florian__> kind of the same problem you described before with multiple vendors
déc. 14 20:23:43 <iampersistent> how do we make the interface uniform enough to work within any order flow, but be inclusive enough to handle something like a reservation system
déc. 14 20:24:08 <florian__> great example
déc. 14 20:24:47 <iampersistent> I could easily envision a site for a spa that sells reservations for a treatment, but also sell products and maybe sell mp3s of relaxing music, all in the same site
déc. 14 20:25:13 <iampersistent> having that level of flexiblity that you can fully implement all of those things, would be great
déc. 14 20:25:22 <inspiran> indee
déc. 14 20:25:23 <inspiran> d
déc. 14 20:25:31 <iampersistent> right now its like you sell the items but they are all managed in different places and in different ways
déc. 14 20:25:47 <inspiran> yep
déc. 14 20:26:11 <inspiran> basicly from a conceptual point of view you only have two things: products and services
déc. 14 20:26:19 <iampersistent> so right now, I'm not 100% how to make sure the interface can handle all of this, but I think as long as we are keeping it in mind, we'll figure out a way
déc. 14 20:26:31 <iampersistent> right, but products can be a lot of different things
déc. 14 20:26:41 <inspiran> i predict that the product interface will be different from services
déc. 14 20:27:08 <inspiran> because for service the notion of 'periods' is more important than goods
déc. 14 20:27:13 <iampersistent> right, but I feel like we need some commonality so that a product and service can be processed in a similar way
déc. 14 20:27:26 <florian__> do services can handle all the logic by htemselves?
déc. 14 20:27:30 <iampersistent> yeah, well and I'm also thinking about selling subscriptions
déc. 14 20:27:51 <iampersistent> florian__ I think so, I think the product/service has to be resposible to know how to handle itself
déc. 14 20:28:04 <iampersistent> including fulfillment
déc. 14 20:28:30 <iampersistent> but communicate back when a product has been fulfilled, in what ever form that is
déc. 14 20:28:57 <inspiran> hmm, but what if your products needs a third party to be fulfilled?
déc. 14 20:29:13 <iampersistent> with a digital download, you could just add it to a dashboard for the user or push it out as a file
déc. 14 20:29:34 <iampersistent> a physical product would need to be picked and shipped before it is considered fulfilled
déc. 14 20:29:46 <inspiran> eg. 'fix my door' service is only forfilled when the door is really fixed
déc. 14 20:30:01 <inspiran> *fulffilled
déc. 14 20:30:19 <inspiran> then you need some kind of a call back
déc. 14 20:30:44 <iampersistent> right, so in that case, when the order is placed, it goes into a queue of tasks that need to be assign to a serviceman, its assign, manually or just as tasks comes off
déc. 14 20:30:53 <inspiran> hmm, the product could listen to an event 'service_delivered_correctly'
déc. 14 20:31:02 <florian__> should we apply this kind of -*/service- pattern to thoses differents processes ?
déc. 14 20:31:23 <iampersistent> when the serviceman has finished fixing the door, he would go into the system, mark the project completed, add an notes needs for the future
déc. 14 20:31:29 <florian__> and separate fulfillment from others
déc. 14 20:31:31 <iampersistent> signally that it has been fulfilled
déc. 14 20:32:02 <inspiran> ok, then we'll need some kind of a background task
déc. 14 20:32:10 <inspiran> fine enough :)
déc. 14 20:32:33 <iampersistent> I think before an "order" can be completed, everything has to be fulfilled, what ever that means for the specific product
déc. 14 20:33:01 <inspiran> hmm, i'm not sure about that assumption
déc. 14 20:33:03 <iampersistent> in my spa example, the order is finished when the mp3 has been pushed out, the product has been picked and shipped and the treatment is over
déc. 14 20:33:20 <iampersistent> how so inspiran?
déc. 14 20:33:29 <inspiran> i'm still thinking about an example
déc. 14 20:33:36 <iampersistent> k
déc. 14 20:33:40 <inspiran> something where you order, pay and then get your goods later on
déc. 14 20:33:57 <inspiran> ah, the Groupon is maybe such a case
déc. 14 20:34:04 <iampersistent> a think a subscription would fall into this category
déc. 14 20:34:21 <inspiran> i mean, there is currently a hype about 'internet best offer of the day'
déc. 14 20:34:31 <inspiran> which illustrates perfectly:
déc. 14 20:34:56 <inspiran> my girlfriend orders something from
déc. 14 20:34:59 <iampersistent> if you subscribe to basecamp, the order would never be "complete" until you canceled the service
déc. 14 20:35:21 <inspiran> she first orders, then pays, then the goods are gathered from a 3th party supplier which it ships
déc. 14 20:35:31 <inspiran> (the process takes up to three weeks)
déc. 14 20:36:22 <iampersistent> there are several points where you could call the order "complete" depending on your business process
déc. 14 20:36:46 <inspiran> true
déc. 14 20:37:08 <iampersistent> you could say the order is complete (from vente-exclusive's perspective) when you tell the 3rd party what to ship and pay them their share of the money collected
déc. 14 20:37:27 <inspiran> (taken the example of my status management profile prototype, this would mean that in the status schema you specify for a given status whether or not it is from that point fullfilled)
déc. 14 20:37:37 <iampersistent> or in the same case, you could require the 3rd party to signal back to you that it has been picked and shipped before it is "complete"
déc. 14 20:38:05 <iampersistent> which is why I think ultimately, we'll have to look at an order workflow system with a similar design to what you are doing on your booking bundle
déc. 14 20:38:21 <inspiran> yeah
déc. 14 20:38:54 <inspiran> using the status management process you could even have two very similar processes but with different fullfillments
déc. 14 20:39:15 <iampersistent> so how do we translate all of these ideas into interfaces? :)
déc. 14 20:39:45 <florian__> very interesting
déc. 14 20:39:46 <inspiran> i will take the example of 3 suisses, which is a kind of a book from which my girlfriend often orders
déc. 14 20:40:15 <inspiran> she orders, she gets the products, and pays 3 weeks after she received the goods
déc. 14 20:40:40 <inspiran> but some customers can't do this because their level of credebility is low
déc. 14 20:40:54 <inspiran> so they need to first pay before the order is shipped
déc. 14 20:42:09 <inspiran> and if they pay on time, they are allowed to pay after delivery
déc. 14 20:43:02 <florian__> didn't know this process, but it show how much the system has to be flexible
déc. 14 20:43:55 <iampersistent> florian__ agreed, to make it useful across many projects, we really have to look the flexiblity
déc. 14 20:44:08 <florian__> so if we resume,
déc. 14 20:44:10 <iampersistent> I think this is the flaw in most OS ecommerce software
déc. 14 20:45:04 <florian__> we have fulfillment, order status and product meta information which need to be flexible
déc. 14 20:45:41 <iampersistent> yes and payment also, based on the different scenarios that insprian has laid out
déc. 14 20:46:25 <inspiran> we should, base on our current discussion, go back to previous scenarios which you have crossed and think about these
déc. 14 20:46:41 <inspiran> just think about daily activities
déc. 14 20:46:44 <florian__> we could use the pattern showed in your prototype to handle these different kinds of processes
déc. 14 20:47:08 <inspiran> eg. suppose your local bakery would want to sell bread online, how would he do it
déc. 14 20:47:13 <florian__> yes u're right
déc. 14 20:47:46 <inspiran> you'll quickly discover two target audiences 1) people and 2)companies
déc. 14 20:48:02 <inspiran> people need to pay directly, companies can pay at the end of the month
déc. 14 20:48:59 <inspiran> i everybody of us thinks about these procesess before elaborating on a technical design, i think the solution would be much better
déc. 14 20:49:42 <florian__> i agree
déc. 14 20:50:38 <inspiran> maybe each could start with writing down any scenario you could think of and have them on a wiki by next week?
déc. 14 20:51:16 <inspiran> or by mail
déc. 14 20:51:42 <florian__> that's the first point we should have done: writing some use cases :)
déc. 14 20:52:03 <inspiran> then, we could come up with some common concepts we need
déc. 14 20:52:47 <inspiran> and test them against our scenarios
déc. 14 20:53:10 <inspiran> but be awere: i do not believe that all scenarios can fit perfectly, often additional developments are needed
déc. 14 20:53:34 <iampersistent> I think these should go up on the wiki
déc. 14 20:53:48 <florian__> yes
déc. 14 20:53:49 <iampersistent> I think the more information that is available, the greater the chances of getting others invovled
déc. 14 20:55:09 <inspiran> it would even be better if we could talk to people doing the actual business
déc. 14 20:55:21 <inspiran> i have contacts in retail but non in real estate
déc. 14 20:55:35 <inspiran> i think real estate is also a very interesting one to look at
déc. 14 20:55:40 <iampersistent> I know someone in real estate, I'll shoot her an email
déc. 14 20:55:58 <inspiran> because in real estate, there normally no payment
déc. 14 20:56:03 <inspiran> not online
déc. 14 20:56:18 <florian__> great idea
déc. 14 20:56:43 <inspiran> but i can assume you want to track your sales , so the administration would fill them in manually
déc. 14 20:56:57 <iampersistent> right
déc. 14 20:58:24 <iampersistent> well, lets start putting some use cases up on the wiki, at least get something started
déc. 14 20:58:37 <iampersistent> the great thing about a wiki is we can expand on each others ideas
déc. 14 20:58:59 <inspiran> where would the wiki be?
déc. 14 20:59:20 <iampersistent> well, right now we could do it on the Symfony2-e-commerce-bundle github account
déc. 14 20:59:27 <florian__> you mean in what place?
déc. 14 20:59:44 <iampersistent> I think alecs said something about maybe using the resources already set up for sfShop
déc. 14 20:59:53 <florian__> yes I thought to
déc. 14 21:00:18 <iampersistent> florian__ I agree this is the best solution for right now
déc. 14 21:00:21 <inspiran> github is fine by for me
déc. 14 21:00:41 <inspiran> also guys, don't forget something
déc. 14 21:00:51 <iampersistent> by using github we increase the chance of getting community feedback
déc. 14 21:01:11 <florian__> the wiki itself is very flexible, you can even have a git access to it
déc. 14 21:01:39 <inspiran> lots of business are stores which think they need e-commerce because "everybody does it"
déc. 14 21:02:16 <iampersistent> do we need a section about helping the customer understand what they REALLY need? ;)
déc. 14 21:02:17 <inspiran> so often there is an interface needed to legacy systems or a way to allow them to enter orders
déc. 14 21:02:28 <inspiran> manually
déc. 14 21:02:35 <iampersistent> right
déc. 14 21:02:46 <inspiran> the manual process should be more flexible than others
déc. 14 21:03:10 <inspiran> eg, when you enter the order, the system threats it already as fulfille
déc. 14 21:03:12 <inspiran> d
déc. 14 21:03:28 <inspiran> they only enter it manually for a reference and reporting purposes
déc. 14 21:03:49 <inspiran> but they should be differently saved
déc. 14 21:04:30 <inspiran> for instance, the sales order entity should have a column allowing to differentiate between the manual and normal order
déc. 14 21:04:42 <inspiran> so in their reporting they can easily differentiate
déc. 14 21:06:12 <inspiran> eg. in the administration console, there is no point of being able to select the status 'waiting for customer payment'
déc. 14 21:06:27 <inspiran> if you know it's already paid
déc. 14 21:08:30 <iampersistent> true
déc. 14 21:08:45 <inspiran> (ps, we need also a sexy name for the project)
déc. 14 21:08:58 <iampersistent> how about sexy ecommerce ;)
déc. 14 21:09:17 <florian__> sexy-commerce
déc. 14 21:09:34 <iampersistent> actually, thats pretty cool
déc. 14 21:09:54 <inspiran> hmm, would prefer something more abstract
déc. 14 21:10:04 <florian__> actullay didn't tought to a name
déc. 14 21:10:05 <iampersistent> not sure if that would confuse people or not
déc. 14 21:10:09 <inspiran> eg. magento is nice sounding
déc. 14 21:10:11 <florian__> idem
déc. 14 21:10:24 <iampersistent> someone might think its a system to build porn sites :p
déc. 14 21:10:29 <florian__> first proposition was for fun :)
déc. 14 21:10:50 <inspiran> anybody wanting to investigate the porn scenarios and how to perform fullfillment?
déc. 14 21:10:56 <florian__> héhé, yes too much ambiguous
déc. 14 21:10:59 <iampersistent> lol
déc. 14 21:11:17 <florian__> there are a lot of scenarios in there :)
déc. 14 21:11:26 <iampersistent> I think a cool name will help
déc. 14 21:11:35 <inspiran> yup
déc. 14 21:12:03 <florian__> "my 2 e-cents"
déc. 14 21:12:34 <florian__> don't know why i thought to this
déc. 14 21:12:57 <inspiran> one word is nicer, easier to google :)
déc. 14 21:13:06 <inspiran> anyhow, it's not yet needed now
déc. 14 21:13:07 <florian__> sure
déc. 14 21:13:32 <inspiran> but i wouldn't want to have the name commerce in it
déc. 14 21:13:43 <florian__> agree
déc. 14 21:14:14 <florian__> a "magento" like or "ubuntu" like
déc. 14 21:14:30 <inspiran> if you need do create some kind of a service based subscription site for organisations like unicef, you don't to have it labeled in the footer 'powered by sf-commmerce'
déc. 14 21:14:33 <florian__> words that don't need to embed their usage
déc. 14 21:15:07 <inspiran> maguntu :)
déc. 14 21:15:14 <florian__> haha :)
déc. 14 21:16:23 <florian__> but you're right, the question has not to be asked yet
déc. 14 21:17:01 <florian__> let's see how things move until next week
déc. 14 21:17:08 <florian__> let's write some scenarios
déc. 14 21:17:21 <florian__> think of possibles solutions
déc. 14 21:17:24 <iampersistent> yes, and I think we should post on the sfShop group and on the wiki that we are doing weekly meetings
déc. 14 21:17:39 <florian__> yes i'm planning to do that
déc. 14 21:19:07 <iampersistent> ok, cool
déc. 14 21:20:12 <inspiran> so we would weekly meetings? ok :)
déc. 14 21:21:03 <iampersistent> I think we should, just to keep on track
déc. 14 21:22:51 <inspiran> but i must say honestly, it was a bit too early today
déc. 14 21:22:57 <inspiran> i would prefer it a bit later
déc. 14 21:23:08 <inspiran> like 19h GMT
déc. 14 21:23:27 <florian__> ok for me
déc. 14 21:23:50 <iampersistent> I'm ok with that
déc. 14 21:24:02 <inspiran> ok
déc. 14 21:24:04 <iampersistent> florian__ where do you want me to put the log?
déc. 14 21:24:06 <florian__> cool :)
déc. 14 21:24:22 <florian__> please send the on florian.klein [at]
déc. 14 21:24:46 <florian__> i'm just missing first part, the rest is logged, but you can send them
déc. 14 21:25:04 <florian__> thanks!
déc. 14 21:25:07 <inspiran> heh, funny email address
déc. 14 21:25:10 <inspiran> it's f^4
déc. 14 21:25:16 <inspiran> hmm, never mind
déc. 14 21:25:22 <inspiran> i thought i read four 'f'
déc. 14 21:25:29 <florian__> hey, didn't noticed ;)
déc. 14 21:25:56 <florian__> 3 is not bad
déc. 14 21:25:59 <inspiran> stupid question, how do i edit a wiki page?
déc. 14 21:27:41 <florian__> do this work ?
déc. 14 21:28:10 <florian__> i pushed you to the list of collaborators
déc. 14 21:28:37 <inspiran> yep, works
déc. 14 21:28:57 <florian__> if tou want, you can fork the wiki on a dedicated git repo
déc. 14 21:30:24 <florian__> as seen here
déc. 14 21:31:41 <inspiran> ah, not needed
déc. 14 21:31:46 <inspiran> i got my page created
déc. 14 21:31:47 <inspiran>
déc. 14 21:32:53 <florian__> good
déc. 14 21:32:55 <inspiran> would you guys be interested in some kind of a webcast on which i explain a bit more how sap handles business process configuration?
déc. 14 21:33:58 <florian__> sounds cool
déc. 14 21:34:10 <iampersistent> florian__ I just sent the log
déc. 14 21:34:15 <iampersistent> inspiran yes please :)
déc. 14 21:34:19 <florian__> thanks
déc. 14 21:34:22 <iampersistent> np
déc. 14 21:34:49 <inspiran> what is interesting software to use?
déc. 14 21:34:55 <inspiran> i'm not familiar what is handy
déc. 14 21:35:03 <iampersistent> not sure on that
déc. 14 21:35:12 <iampersistent> guys I have to go for now, I'll be around later
déc. 14 21:35:19 <iampersistent> good talk, I feel it was very productive
déc. 14 21:35:58 <florian__> yes thanks for all
déc. 14 21:36:04 <inspiran> thx for being here all
déc. 14 21:36:05 <florian__> very inspirative
déc. 14 21:36:13 <florian__> I think your name is well chose :)
déc. 14 21:36:16 <florian__> n
déc. 14 21:36:22 <inspiran> heh :)
déc. 14 21:36:49 <florian__> see you next week -- or before
déc. 14 21:37:40 <inspiran> we can always remain in this channel
déc. 14 21:37:54 <florian__> clearly a productive talk
déc. 14 21:38:01 <florian__> yeah
déc. 14 21:38:48 <inspiran> absolutely
**** FIN DU JOURNAL À Tue Dec 14 21:42:54 2010
**** DÉBUT DU JOURNAL À Tue Dec 14 21:42:54 2010
déc. 14 21:51:58 <inspiran> florian_> do you like red wine?
déc. 14 21:52:07 <florian__> i do :)
déc. 14 21:52:57 <inspiran> maybe we should pick up a nice sounding red wine brand derivative name
déc. 14 21:53:05 <inspiran> i know iampersistent likes wine too
déc. 14 21:53:06 <inspiran> alecs?
déc. 14 21:54:10 <florian__> not a bad idea!
déc. 14 21:55:47 <florian__> I know a very good wine names "gewurtzraminner", but luckily, it's white wine ;)
déc. 14 21:58:07 <inspiran> the name is not sexy, it sounds like a german gestapo officer
déc. 14 21:58:09 <inspiran> :)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment