¡Welcome to the JavaRanch, Sr. Perez!
JSF has a special bean management subsystem whose sole function is to instantiate JSF backing beans and inject Managed Properties into them. Once that has been done, the managed beans look just like any other
J2EE application, session or request-scope objects. Instantiation is done on-demand. That is, if a View is requested and there's an EL expression on the View Template (.xhtml) that references a bean such as facturaHome, the EL processor attempts to find a J2EE object of that name and use it. If one cannot be found, then the JSF bean manager takes over, instantiating a bean and returning it for processing.
Managed Beans are all POJOs. This means that you must have either a no-argument constructor for it or at least not have any explicit constructors that require arguments and thus obstruct the ability of the bean manager to instantiate a copy of the managed bean without constructor arguments. Managed Properties are simply EL expressions that return a value that can be injected into the managed bean via its public "set" methods. So first the bean is instantiated, then the Managed Properties are injected, then the bean is presented for use.
Defining a managed bean in JSF1 was done via XML ManagedBean elements in the faces-config.xml. In JSF2, it was also possible to define managed beans and their managed properties via annotations on the bean's
Java source.
CDI is an attempt to consolidate a number of different bean management functions under a common annotation set, and it looks like that's what you're using. I haven't been using CDI because it's not compatible with my legacy code, thus I'm not an expert on it. However the important things to do whether you use JSF annotations or CDI annotations is to mark the bean as managed and to define the JSF scope of the bean - application, session, view or request-scoped.
Incidentally request scope is almost 100% useless in JSF and doubly so when using JSF model façade objects - meaning selectOneMenu or dataTable elements. Use ViewScoped if your bean is only required for processing that particular page, and SessionScoped if more than one page needs its contents/capabilities.
That's how beans come into the world in JSF. What I think you REALLY wanted to know, however, is how data gets in and out of Managed Beans. Initially, as I said, ManagedProperties can inject values into a ManagedBean. But once the bean has been rendered up as a web page, what then?
Well, JSF is a Model/View/Controller architecture. The xhtml View Templates define Views, the backing beans are Models (and action processors, which are something outside of MVC). And the Controllers are all pre-supplied for you. You don't write Controller logic for JSF. You don't have to.
Once a bean's property is bound to a control in a View via an EL expression referencing it, JSF's lifecycle processing will automatically ensure that changes to the View such as selection made on the "activa" control are copied to the Model (item.moneda). Since "item" is a row cursor for the dataTable, that means that the corresponding facturaHome.itemFacturasTemp row's "moneda" property is automatically set by JSF. Conversely, when the View is rendered, whatever value was in that property will be reflected in the rendered web page.
It is important to be aware, however, that JSF is built on HTML/HTTP. That means that nothing will work right unless the control is in a from (JSF h:form) and that simply changing the control won't update the backing bean. The form has to be submitted, either via a submit control (h:commandButton or h:commandLink) or via AJAX. Once the form has been submitted, the JSF lifecycle takes over - inputs are validated, and - if valid - listeners are invoked, the bean's properties are updated and the submit action method and/or listener method(s) are fired.