Bueno, luego de jugar un poco con mis mappings, he llegado a la siguiente
solucion
1.- Comparto el criterio siguiente
Una factura existe, sin su retencion
Una retencion no tiene razon de ser sin la factura
Con esto, a nivel de bdd, la tabla factura no tiene mas la columna
RetencionId
A nivel de objetos mi objeto Factura se ve asi
public class Factura : BaseEntity
{
.......
public virtual RetencionFuenteVenta Retencion { get; set; }
.......
}
su mapping tiene lo siguiente
<one-to-one name="Retencion" class="RetencionFuenteVenta" cascade="all"
property-ref="FacturaAplicada" />
a nivel de bdd, la tabla retencion, tiene un columna FacturaId, no null, con
los constraint sugeridos
a nivel de objetos se asi
public class RetencionFuenteVenta : BaseEntity
{
........
public virtual Factura FacturaAplicada { get; set; }
........
}
su mapping correspondiente
<many-to-one name="FacturaAplicada" class="Factura" column="FacturaId"
unique="true" />
todo esto me permite persistir una factura con su correspondiente retencion
cuando este aplique, y recuperar mis objetos
para mi caso, de tipo Factura y para efectos de calculos verificar si esta
genero una retencion o no.
Todo anda muy bien, pero de todas formas me gustaria saber sus comentarios
No se a lo mejor en cuanto rendimiento, que sucede con esto
property-ref="FacturaAplicada"
Saludos
Edgar
El 29 de junio de 2011 09:17, Edgar Ramos <[email protected]> escribió:
> Gracias a todos por sus comentarios.
>
> Como dice Carlos son todos excelentes consejos.
>
> Carlos, mis apreciaciones
> ----
>
> en mi opinion no deberias tener una referencia desde la Factura a la
> Retencion.
> ---
>
> Esta logica me ha estado sonando bastante desde ayer.
>
> -----
>
> Pregunta: si la factura no tiene retencion, sigue siendo una factura? si la
> respuesta es SI, entonces no es correcto colocar esa referencia.
> -----
>
> Efectivamente la respuesta es si, pero mi duda de principiante, por que no
> es correcto colocar esta referencia aqui ?
> Este es síntoma de un mal analisis de mi parte ?, el por que me ayudaría a
> enteder mejor mi problema
>
> ----
>
> Lo mismo para la retencion: si la retencion no tiene factura, sigue siendo
> una retencion? creo que la respuesta es NO, no puede existir retencion sin
> el comprobante asociado (sea factura u otro).
> ----
>
> Nuevamente es correcta esta apreciacion, la respuesta es no
>
> Pero
> ---
>
> Otro punto seria: la factura necesita la retencion para algun calculo? que
> pasa cuando no la hay? como funciona ese calculo?
> ---
>
> Si la factura no necesita retencion, los calculos son iguales, hay un
> subtotal+impuestos, lo que nos da un total
> Si la factura requiere una retencion, los calculos cambian.
>
> Retencion = PorcentajeDeRetencion * Subtotal
> SaldoApagar = total-Retencion
>
> El nuevo total de factura es igual a SaldoAPagar.
> Aqui, para efectos de mis calculos, que posiblemente mi analisis preliminar
> este mal planteado.
>
> Verificaba que si mi objeto Factura.Retencion == null, SaldoAPagar = Total,
> caso contrario, efectuaba los calculos anteriormente expuestos
>
> Gracias por sus comentarios
>
> Saludos
>
> Edgar
>
> El 29 de junio de 2011 04:55, Carlos Peix <[email protected]>escribió:
>
> Hola Edgar,
>>
>> Advertencia: esta es una respuesta disruptiva con el hilo.
>>
>> Como dice el tano, cuanto mejor es tu modelo de objetos, mas facil es
>> mapearlo con un ORM.
>>
>> Tu dignostico es correcto: "Me he liado un poco con la relacion de estos
>> objetos" pero creo que estas buscando la solucion en el lugar equivocado.
>>
>> Al margen de los excelentes consejos que te estan dando, en mi opinion no
>> deberias tener una referencia desde la Factura a la Retencion.
>>
>> Pregunta: si la factura no tiene retencion, sigue siendo una factura? si
>> la respuesta es SI, entonces no es correcto colocar esa referencia.
>>
>> Lo mismo para la retencion: si la retencion no tiene factura, sigue siendo
>> una retencion? creo que la respuesta es NO, no puede existir retencion sin
>> el comprobante asociado (sea factura u otro).
>>
>> Otro punto seria: la factura necesita la retencion para algun calculo? que
>> pasa cuando no la hay? como funciona ese calculo?
>>
>> ----------------------------------
>> Carlos Peix
>>
>> 2011/6/28 Edgar Ramos <[email protected]>
>>
>>> Gente un Saludo
>>>
>>> Me he liado un poco con la relacion de estos objetos
>>>
>>> Factura y Retencion
>>>
>>> A una Factura le corresponde una retencion, siempre y cuando el cliente
>>> lo exija, caso contrario no aplica, para este efecto
>>>
>>>
>>> Mis clases
>>>
>>> public class Factura
>>> {
>>> .......
>>> public virtual RetencionFuenteVenta Retencion { get; set; }
>>> .......
>>> }
>>>
>>> public class RetencionFuenteVenta
>>> {
>>> ........
>>> public virtual Factura FacturaAplicada { get; set; }
>>> ......
>>> }
>>>
>>> Mis mappings
>>>
>>> <class name="RetencionFuenteVenta">
>>> <id name="Id">
>>> <generator class="hilo"/>
>>> </id>
>>>
>>> .........
>>> <many-to-one name="FacturaAplicada" class="Factura" column="FacturaId"
>>> />
>>> </class>
>>>
>>> <class name="Factura">
>>> <id name="Id">
>>> <generator class="hilo"/>
>>> </id>
>>>
>>> <many-to-one name="Retencion" class="RetencionFuenteVenta"
>>> column="RetencionId" cascade="all" />
>>> </class>
>>>
>>> En el esquema de la bdd, la tabla Factura tiene el campo RetencionId como
>>> permitir valores nulos, que para mi
>>> caso es lo que requiero.
>>> Por otro lado La tabla RetencionFuenteVenta, campo FacturaId, tiene
>>> tambien permitir valores nulos, no me parece
>>> que sea lo correcto, pero lo puesto asi para que nh persista estas
>>> entidades y lo hace sin problemas
>>>
>>> Pero al quitar de RetencionFuenteVenta, campo FacturaID el permitir
>>> valores nulos, nh me tira un error
>>> -------------------------------
>>> {"No se puede insertar el valor NULL en la columna 'FacturaID', tabla
>>> 'RetencionFuenteVenta'. La columna no admite valores NULL. INSERT falla.\r\n
>>> Se terminó la instrucción."}
>>> ---------------------------------
>>>
>>> Cualquier comentario o sugerencia les estoy muy agradecido
>>>
>>> Saludos
>>>
>>> Edgar
>>>
>>>
>>>
>>> --
>>> Para escribir al Grupo, hágalo a esta dirección:
>>> [email protected]
>>> Para más, visite: http://groups.google.com/group/NHibernate-Hispano
>>>
>>
>> --
>> Para escribir al Grupo, hágalo a esta dirección:
>> [email protected]
>> Para más, visite: http://groups.google.com/group/NHibernate-Hispano
>>
>
>
--
Para escribir al Grupo, hágalo a esta dirección:
[email protected]
Para más, visite: http://groups.google.com/group/NHibernate-Hispano