Cell Phone Interface for PBX use

Cellphone interfaces for PBX are
a good way to reduce costs

After realizing that over 50% of the company's cell phone bill is due to local to mobile calls I decided to investigate the possibility of using a Cell Phone Interface for our PBX (generaly called PABX in Brazil).


We have a Digital Telephone Central model Intelbras 141. Which, according to the companies website, supports the ITC 4000 Cellphone Interface.


However, this model is priced nearly twice as much as a model from a different manufacturer (Naccell, ITS, Plugcell).


These are said to be compatible with *any* PBX on the market, however I fear they might only be compatible with Analogic or Hybrid Telephone Centrals.


Another issue involved is the selection of the carrier plan: one major catch here: STATIC USE CLAUSE.


Most carriers, on their general purpuse plans, have a clause on their contract stating the following (extracted from TIM contract for a Liberty plan) that is said to void the contract and cause loss of benefits:


3.3.1.3. Uso estático (sem mobilidade) do aparelho celular em cerca de 60% do tráfego originado pelo CLIENTE e recebimento de ligações em proporção inferior a 33% do volume originado, por
mês.


Meaning:


3.3.1.3. Static Use (no mobility) of the celular device in around 60% of traffic originated by the client and receival of calls in proportion inferior than 33% of the originated volume, each month.


With that in mind, I have to find a plan that does not forbid you from having a staticaly allocated sim card carrying calls for my PBX.

Hiring a webdesign company and giving straightforward intelligible guidelines

Gathering successful examples is
a great way to start

Being an ordinary software developer involves knowing your deficiencies and not being a wiseass who thinks he knows about everything.

And that means, sometimes, you will hire someone to do a better job than you would. Or maybe you just don't have the time and need it done fast. Or even further, sometimes it needs to be cute, and let's face it, it is yet to be born a software developer who grasps the concepts of cuteness.

That said, we're in the process of hiring a web designing company to refurbish our web site.

The Marketing and Creative Director (MCD) has scheduled a meeting between me and the designer, because, from their conversations, some technical details surfaced, and I am supposed to interface them in this matter.

I recognize that criticizing design is one of my weaknesses, however, I might as well meander in the usability issues given that, to the least, I am a well experienced "user" of websites.

I gathered, in a short time, a couple of references that are quite good and that I summarize below.

Top Five Web Design Mistakes Small Businesses Make

1) Poor navigation: people visit your site for specific information, and if they cannot find it they will quickly go elsewhere, leaving with the impression that your business is disorganized in more than just its website.

2) No clear calls to action: if you aren’t leading users to commit to an action (buy a product, contact you or subscribe, for example), then you are losing them.

Choosing colours may be
the most dificult task

3) Color and contrast: if your website text does not have sufficient contrast compared to its background, people will have difficulty reading your content. 

4) Content: people visit your website for its content, and how that is structured is a huge factor in its success or failure. 

5) Clutter: challenge every item on each page and ask, “Does it really need to be there? Does it serve a specific purpose? Can I live without it?”. Even the greatest content can become lost in a mess of words and graphics, so de-cluttering is essential.

Preparing Your Web Content for iPad

1) Test your web site in iPad, iPhone and desktop. Update user agent detection code if necessary

2) Use W3C standards instead of plugins. Prefer HTML5. (and by plugins, yes, we mean Flash and Java)

3) Check viewport settings. Do not hardcode width elements

4) Modify code that relies on CSS fixed positioning. These do not work *as expected* on iPhone and iPad, because the viewport is the window and window size is set to the size of the physical screen and is, therefore, not resizable on these devices.

5) Prepare for touch interface. Most importantly: avoid hovering actions or any other *typical mouse* related features.

6) Use textareas instead of contenteditable elements.

Implementing complex pricing schemes using a Nested Set Model

To accomplish the proposed pricing scheme which would allow for arbitrary multiplication of any given factor by a detirmined index, the model has to be adjusted accordingly.


mysql> describe nested_set;
+----------------+---------+------+-----+---------+----------------+
| Field          | Type    | Null | Key | Default | Extra          |
+----------------+---------+------+-----+---------+----------------+
| id             | int(11) | NO   | PRI | NULL    | auto_increment |
| name           | text    | YES  |     | NULL    |                |
| additive       | int(11) | YES  |     | 0       |                |
| multiplicative | int(11) | YES  |     | 1       |                |
| lft            | int(11) | NO   |     | NULL    |                |
| rgt            | int(11) | NO   |     | NULL    |                |
+----------------+---------+------+-----+---------+----------------+

As evidenced, I droped the value field and added a couple more, namely: additive and multiplicative. This way, the pricing view is now described as follows:

CREATE VIEW `pricing` AS select `node`.`id` AS `id`,`node`.`name` AS `name`,sum((`children`.`multiplicative` * `children`.`additive`)) AS `price` from (`nested_set` `node` join `nested_set` `children`) where (`children`.`lft` between `node`.`lft` and `node`.`rgt`) group by `node`.`name` order by `node`.`id`

However, it makes sense to have an independent factor entity given that one single factor may apply to several diferent node values. The following modifications make this feasible:


mysql> describe factor;
+-------+---------+------+-----+---------+----------------+
| Field | Type    | Null | Key | Default | Extra          |
+-------+---------+------+-----+---------+----------------+
| id    | int(11) | NO   | PRI | NULL    | auto_increment |
| name  | text    | YES  |     | NULL    |                |
| value | int(11) | NO   |     | 1       |                |
+-------+---------+------+-----+---------+----------------+

Add caption

and the new view as follows:

CREATE VIEW `pricing` AS select `node`.`id` AS `id`,`node`.`name` AS `name`,sum((`factor`.`value` * `children`.`additive`)) AS `price` from (`nested_set` `node` join (`nested_set` `children` join `factor` on((`factor`.`id` = `children`.`multiplicative`)))) where (`children`.`lft` between `node`.`lft` and `node`.`rgt`) group by `node`.`name` order by `node`.`id`

With this, I am able to have this sort of formulas implemented on a tree structure:

Node_Price = Sum(1,N) [ Child1 * Factor_for_child1 + Child2 * Factor_for_Child2 + ... ChildN * Factor_for_ChildN)

Estudo sobre modelos para composição de preço de produtos manufaturados

[Fonte: http://www.revistamedievo.com]

Hoje vou tentar criar um modelo simples para composição de preços para produtos manufaturados com múltiplas matérias primas e mútiplas etapas de trabalho. E que suporte historiamento de precificação, ou seja, parâmetros variáveis com o tempo afetam a determinação de um preço e a cada determinação de preço deve ser mantido um histórico.

Ademais, cada precificação é composta, além da matéria e do trabalho, de outros fatores mercadológicos, que incidem sobre o preço final ou sobre cada elemento da composição sob forma de um índice de correção. Cada aplicação de índice deve também também ser historiada e rastreável, ou seja, a aplicação de um desconto sobre uma determinada matéria por razão X deve ser armazenada para futura auditoria.

Estou estudando os modelos de relacionamento em árvore e se eles serão capazes de implementar este modelo, e sobretudo, se serão escaláveis para futuras adições de complexidade.

A questão é se seria possível modelar em uma entidade só "coisas" que são diversas (mão de obra VS matéria prima).

From now on, it's about to get technical, so I decided to write in plain english.

1st attempt: simple hierarchical tree model:

Every tree has a root, roots might have zero or more nodes and nodes might have zero or more nodes. Each node has only one parent node.

In this model, the price composition is as follows:

Given a node, its price is the sum of the price of each individual children multiplied by a factor inherent and unique to this node.

The exception being for those nodes that *do not* have children, in which case, their price is explicitly assigned and multiplied by a factor inherent and unique to itself.

The simplest representation for this model would require a single entitie: Node.

Node
--------------------
id
parent_id
price
factor

This model may, howerver, be further normalized, considering several nodes might share the same factor and would benefit from depending on a single entry of a different entity. Thus:

Node

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

id

parent_id

price 

factor_id

Factor

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

id

factor

Howerver, it gets misty as to how the price property behaves given that there is no easy awareness of the tree's depth, and the aggregate calculations might get nasty.

2nd Attempt: Nested Set Model

Nested set models use two properties, lft and rgt, to localize each node in its set hierarchy. This localizations makes for an easier querying when dealing with unlimited depth sets (and thus, trees).

Graphical representation of Nested Set Model, with lft and rgt properties depicted. [source: dev.mysql.com]

MySQL has a good descritption of Nested Set Models.

With this Model, I am able to easily query prices as aggregate functions using one single entity:


CREATE TABLE `nested_set` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` text,
  `value` int(11) DEFAULT NULL,
  `lft` int(11) NOT NULL,
  `rgt` int(11) NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=MyISAM AUTO_INCREMENT=6 DEFAULT CHARSET=latin1


Querying a price is as simple as creating the following view:

CREATE VIEW `pricing` AS select `node`.`id` AS `id`,`node`.`name` AS `name`,sum(`children`.`value`) AS `price` from (`nested_set` `node` join `nested_set` `children`) where (`children`.`lft` between `node`.`lft` and `node`.`rgt`) group by `node`.`name` order by `node`.`id`