Menu
▾
▴
fisterra-devel — Mailing list about Fisterra development.
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(22) |
Jun
(10) |
Jul
(9) |
Aug
(4) |
Sep
(6) |
Oct
(1) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(2) |
Feb
|
Mar
(8) |
Apr
(11) |
May
(1) |
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
(12) |
Nov
|
Dec
|
| 2005 |
Jan
(4) |
Feb
(2) |
Mar
(9) |
Apr
(20) |
May
(8) |
Jun
(4) |
Jul
(9) |
Aug
(25) |
Sep
(6) |
Oct
(1) |
Nov
(3) |
Dec
|
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
(1) |
Jul
(4) |
Aug
(1) |
Sep
|
Oct
(2) |
Nov
|
Dec
|
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(5) |
Jun
|
Jul
(18) |
Aug
(17) |
Sep
(19) |
Oct
(1) |
Nov
(3) |
Dec
|
|
From: Alejandro G. C. <ac...@ig...> - 2005-08-17 08:47:14
|
On Wed, Aug 17, 2005 at 10:30:52AM +0200, Wolfgang Keller wrote: > Hello, > > it's mentioned on the web site that you want to allow for > implementation of extensions for/customisation of Fisterra in Python, > but I couldn't find any further information on the actual state of > Python support in Fisterra 2...? > None, it is a pity but we have not time to work on this feature :-/. We still have not plans to work on it, just some ideas about Gazpacho integration. Best regards. -- Alejandro Garcia Castro mailto: ac...@ig... http://www.igalia.com |
|
From: Wolfgang K. <wol...@gm...> - 2005-08-17 08:31:04
|
Hello, it's mentioned on the web site that you want to allow for implementation of extensions for/customisation of Fisterra in Python, but I couldn't find any further information on the actual state of Python support in Fisterra 2...? TIA, Sincerely, Wolfgang Keller -- P.S.: My From-address is correct |
|
From: Eloy F. <ef...@ig...> - 2005-08-12 14:43:02
|
We've added a generic listing controller (FControlListing) and a gene=
ric
listing builder (FControlListingBuiled), we can use it to implement a=
ll
type of listing window, (with filter, result table and other widgets)=
.
How is a listing window implemented using the generic controller and
builder?
We have to implement a controller, it is a subclass of a generic list=
ing
controller (FControlListing).=20
The instance init method of the new controller has to set the name of
tree variables of the generic controller: the listing window name, th=
e
listing filter name and the client data directory.=20
The controller has to redefine the "f_control_listing_define_actions"
method of the generic listing controller, with the actions of the
listing window.
If the listing window contains a filter and the result table only, it=
is
not needed create a new glade file for this window. If this window
contains other widgets we have to create a new glade file with a
container of the generic listing window, the new glade file and the
container of the generic listing window are specified in the controll=
er
definition ('file' and 'widget' parameters).
A example of implementation is:
f_warehouse_controller_stock_management_listing of fisterra-repair.
For more information, view the section 'Listing window implementation=
'
of the 'fisterra-base' doc.
greetings.
--=20
Eloy Froufe P=C3=A9rez
Computer Science Engineer
Telf: +34 981 91 39 91
Fax: +34 981 91 39 49
mailto: ef...@ig...
IGALIA, S.L. http://www.igalia.com
|
|
From: Alejandro G. C. <ac...@ig...> - 2005-08-08 17:37:09
|
Hi, we have added a new repository with the basic fisterra modules (fisterra-bmodules on igalia cvs). Right now it has just a simple actor module with data as API. The use of this kind of modules is interesting feature, the last unstable release of fisterra-ditribution is already depending on it. It means that we can develop data definitions a share them, even without writing any code, just the xml, besides the module will use this predefinition in order to generate, compile and share the API of the data, reducing the final project compilation time. The class diagram exported by the actor module can be found on the documentation of the module. The bmodules repository has the debian package structure as usual. The compilation has been added to the tinderbox and bonsai system: http://tinderbox.fisterra.org/fisterra_bmodules/status.html The API of the modules allows us to reuse *business data dependent* code, you can create and reuse transparently: * class diagrams, xml * EGBs * widgets * controllers * models * facades/delegates * client binaries * server binaries The most important feature of this structure is that you can create and share your best data definitions and all the code that depends on them with other projects. This compilation structure has been a great requirement of fisterra. We are still testing and working on it, so browse the code and if you have any doubt or any suggestion to improve it just send an email ;-). Best regards. -- Alejandro Garcia Castro mailto: ac...@ig... http://www.igalia.com |
|
From: Alejandro C. <ac...@ig...> - 2005-08-01 12:50:15
|
Hi, due to the remove of the classid from the code we have changed the code_generation system, the new features are: * No rewrite of the data definition xml file * No IDs adding system * New class attribute: ancestor, it allows to do inheritance just with the name of the parent, we don't have to explicitly write the children inside the parents xml tag. I've added an example to the fisterra-distribution data_definition file, the incident uses now the ancestor attribute. * Include files system, it allows to use the XInclude system in order to user the data definition of other Fisterra modules. This way you can use data defined in other modules, link to it or even inherit from it in your own database system. It also generates the code just for the local part, reducing the compilation time of the dataobjects and the daos. * Backwards compatible, all the old files are valid. * Added a macro that registers all data types You must notice that all these features are still being tested, you can find them in the CVS HEAD. Best regards. -- Alejandro Garcia Castro mailto: ac...@ig... http://www.igalia.com |
|
From: Carlos <csa...@ig...> - 2005-08-01 12:42:46
|
> > (2) All CORBA objets must be freed independently of service dataobjets > > have been defined in, out or in/out (whenever a mapping has been made, > > of course) ? > I don't understand this question completely. Are you talking about the > client or the server? Sorry ... about client, i erased the name of file (f_com_corba_model_delegate.c). > you can say that: in the server you should not free any corba memory and in > the client you must free always the memory. I think so. Greetings. |
|
From: alex <al...@ig...> - 2005-08-01 12:18:42
|
On Mon, Aug 01, 2005 at 01:58:00PM +0200, Carlos Sanmartín wrote:
> Hi folks,
>
> I've been looking at communication services of fisterra-distribution and
> i want talk with you two things:
>
> (1) In some services, there is a exception management like this:
>
> > /* Check errors */
> > if (!f_ctk_raised_exception_is_a (&ev, ex_CORBA_COMM_FAILURE)) {
> > if (f_com_corba_handle_corba_exception(&ev,error)) {
> > return FALSE
> > }
> > } else {
> > f_client_util_open_error_window(COMM_ERROR_MESSAGE);
> > g_error(COMM_ERROR_MESSAGE);
> > }
>
> Rest services only make this:
>
> > result = !f_com_corba_handle_corba_exception(&ev, error) && result;
>
> The difference seems to be checking for CORBA_COMM_FAILURE and showing a
> error dilog for it.
>
> Must be this behaviour for all services?
>
AFAIK you should use the function f_com_corba_handle_corba_exception, I
think someone implement it in order to write a cleaner code.
>
> (2) All CORBA objets must be freed independently of service dataobjets
> have been defined in, out or in/out (whenever a mapping has been made,
> of course) ?
>
I don't understand this question completely. Are you talking about the
client or the server? I think that as a rule that almost always may be true
you can say that: in the server you should not free any corba memory and in
the client you must free always the memory. The memory of the types in, out
or in/out of a parameter has to do with the one in charge of the allocation.
By the way, I would test your case with valgrind in order to avoid any
error, you can also look for a more accurate description the CORBA standard
or browse the ORBit2 API.
Greetings.
|
|
From: Carlos <csa...@ig...> - 2005-08-01 11:58:30
|
Hi folks,
I've been looking at communication services of fisterra-distribution and
i want talk with you two things:
(1) In some services, there is a exception management like this:
> /* Check errors */
> if (!f_ctk_raised_exception_is_a (&ev, ex_CORBA_COMM_FAILURE)) {
> if (f_com_corba_handle_corba_exception(&ev,error)) {
> return FALSE
> }
> } else {
> f_client_util_open_error_window(COMM_ERROR_MESSAGE);
> g_error(COMM_ERROR_MESSAGE);
> }
Rest services only make this:
> result = !f_com_corba_handle_corba_exception(&ev, error) && result;
The difference seems to be checking for CORBA_COMM_FAILURE and showing a
error dilog for it.
Must be this behaviour for all services?
(2) All CORBA objets must be freed independently of service dataobjets
have been defined in, out or in/out (whenever a mapping has been made,
of course) ?
Thanks.
|
|
From: Sergio V. S. <sv...@ig...> - 2005-08-01 09:42:30
|
Hi, after the recent release of Fisterra2 Distribution 2.0.0 packages we want to notify all developers that a stable branch was created in the CVS in order to manage bug fixes and new features in the stable release source code. In order to work with the stable branch, developers must "move" to the stable branch with: cvs update -r fisterra2-distribution-release_2_0_0-branch Bye. |
|
From: Alejandro C. <ac...@ig...> - 2005-07-28 12:37:27
|
On Thu, Jul 28, 2005 at 01:15:54PM +0200, Alejandro García Castro wrote: > > [...] > > We have removed all the identification of class inside the code of the > barnacle. It is an important change in order to do modules that can export > the data in its API, it will be very nice if we want to reuse data from > other module transparently. > I forgot something important, the numbers of the data_definition.xml are not necessary anymore therefore don't worry if there are classes without them, however the change it is backward compatible so the old files are valid. As I said in the former email you just have to compile again and rebuild the database. Greetings. -- Alejandro Garcia Castro mailto: ac...@ig... http://www.igalia.com |
|
From: Alejandro C. <ac...@ig...> - 2005-07-28 11:16:07
|
Hi, please notice that the HEAD right now it is an unstable release and that if you want to use the current fisterra-distribution stable release (fisterra-distribution-2_0_*) you should use the fisterra-base-2_0_0 tag, we will create a branch from that tag in order to add bug fixes. The current HEAD of fisterra-distribution works with the HEAD of fisterra-base, it has had a little API change on the generated functions, and a very big change on the class management. If you have a binary probably you just have to compile again and regenerate the database, just if have used the remote replication objects system the work will be a bit harder because you will have to change one call to the API. We have removed all the identification of class inside the code of the barnacle. It is an important change in order to do modules that can export the data in its API, it will be very nice if we want to reuse data from other module transparently. We will add a 2_1 tag when the system has almost all the features implemented and working. Greetings. -- Alejandro Garcia Castro mailto: ac...@ig... http://www.igalia.com |
|
From: Javier F. <jfe...@ig...> - 2005-07-22 16:42:49
|
Hello. I recently have installed Fisterra Distribution on my Debian GNU/Linux as Sarge distribution. I have some errors during installation process : * Not checked dedendencies : - recode - libmagick6 These not checked dependecies causes an incompleted installation process and a segmentation fault when tried to load shared library libWand.so. * Orbit name server not started I think that could be a good idea to include a init script on name server package, or include it on fisterra2-fistribtion-server package to init automatically the name server at boot time, as session and fisterra servers do. Greetings, |
|
From: Eloy F. <ef...@ig...> - 2005-07-22 07:37:11
|
Fisterra 2 was published yestarday, at the moment contains:
"fisterra-base": is a stable and mature GNOME framework to develop
sectorial applications.
=20
"fisterra-distribution": is a beta implementation yet, with POS (point
of sell) functionality.
you can download the packages (GNU/Linux Debian Sarge) from:
https://sourceforge.net/projects/fisterra/
or use the 'apt' server of Igalia:
http://community.igalia.com/twiki/bin/view/Fisterra/ProjectDownloadStable
For more information, visit the web of the Fisterra project:
http://community.igalia.com/twiki/bin/view/Fisterra/
greetings.
--=20
Eloy Froufe P=C3=A9rez
Computer Science Engineer
Telf: +34 981 91 39 91
Fax: +34 981 91 39 49
mailto: ef...@ig...
IGALIA, S.L. http://www.igalia.com
|
|
From: Sergio V. S. <sv...@ig...> - 2005-07-13 17:39:03
|
El mi=E9, 13-07-2005 a las 19:30 +0200, Xabier Rodriguez Calvar escribi=F3: > GNOME uses UTF-8, why to use LATIN9 instead of UNICODE? I had changed > it to UNICODE, I guess... >=20 > Gr=FC=DFe aus Deutschland! Because may be UTF8 could cause a lack of performance, we did not evaluate it. Ok I will change it again to UTF8. > M=E9r, 2005-07-13 =E0s 19:22 +0200, Sergio Villar Senin escreveu: > > Hi, > >=20 > > in order to allow symbols like euro (=A4) to be stored in the database,= I > > changed the encoding to LATIN9, so if you use some kind of script for > > creating the database do not forget to add "-E LATIN9" to your > > "createdb" command. The package creates also the database with this > > encoding. > >=20 > > Greetings. > >=20 >=20 >=20 |
|
From: <ju...@ay...> - 2005-07-13 17:36:05
|
Gracias por contactar con Juan Enrique Gómez, ahora mismo me encuentro de vacaciones desde el 1 de Julio al 17 de Julio de 2005. Si el motivo de tu consulta o correo no puede esperar por favor contacta con el 902 01 35 34 o bien con el 687 24 39 56 si es muy urgente. A mi vuelta atenderé todos los correos de manera inmediata. Gracias y disculpa las molestias. Juan Enrique Gómez AYAVOO I+D, S.L. |
|
From: Sergio V. S. <sv...@ig...> - 2005-07-13 17:22:54
|
Hi, in order to allow symbols like euro (=A4) to be stored in the database, I changed the encoding to LATIN9, so if you use some kind of script for creating the database do not forget to add "-E LATIN9" to your "createdb" command. The package creates also the database with this encoding. Greetings. |
|
From: Eloy F. <ef...@ig...> - 2005-07-06 11:20:06
|
El mi=C3=A9, 06-07-2005 a las 12:46 +0200, Sergio Villar Senin escribi=C3= =B3: > I spent this morning gathering information about unused interface > options and unused legacy code like widgets, models or controllers. I > would like you to review this listing searching for errors.=20 i've reviewed it and think that all is right, you do not forgot to update the API documentation and the data dictionaries. --=20 Eloy Froufe P=C3=A9rez Computer Science Engineer Telf: +34 981 91 39 91 Fax: +34 981 91 39 49 mailto: ef...@ig... IGALIA, S.L. http://www.igalia.com |
|
From: Sergio V. S. <sv...@ig...> - 2005-07-06 10:46:25
|
Hi,
I spent this morning gathering information about unused interface
options and unused legacy code like widgets, models or controllers. I
would like you to review this listing searching for errors.
I hope I can begin removing all this stuff this evening.
Menu options to remove
* File Menu
* New Object
* New client
* New provider
* New item
* New order
* New sales order
* New country
* New type of day
* Edit Menu
* Preferences
* Countries
* Types of day
* Enterprise
* Stock Menu
* Orders
* Accept Orders
* Sales Orders
* Sales Orders Dispatchs
* People
* Clients
* Providers
Widgets to remove
* f_model_item.c
* f_widget_address_model.c (Change name)
* f_widget_cash_audit_model.c
* f_widget_cash_audit_validation_model.c
* f_widget_client_model.c
* f_widget_combo_model.c
* f_widget_country_model.c
* f_widget_enterprise_model.c
* f_widget_observation_model.c
* f_widget_order_accept_model.c
* f_widget_order_line_accept_model.c
* f_widget_order_line_dispatch_model.c
* f_widget_order_line_model.c
* f_widget_order_model.c
* f_widget_sales_order_dispatch_model.c
* f_widget_sales_order_model.c
* f_widget_sell_document_interface_model.c
* f_widget_sell_document_lines_interface_model.c
* f_widget_typeday_model.c
Models to remove
* f_widget_order_accept_view.c
* f_widget_order_line_accept_view.c
* f_widget_order_line_dispatch_view.c
* f_widget_order_line_view.c
* f_widget_order_view.c
* f_widget_sales_order_dispatch_view.c
* f_widget_sales_order_view.c
* f_widget_typeday_view.c
* f_widget_enterprise_view.c
* f_widget_item_view.c
* f_widget_country_view.c
* f_widget_observation_view.c
Glades to remove
* f_widget_accept.glade
* f_widget_typeday.glade
* f_widget_enterprise.glade
* f_widget_new.glade
* f_widget_order.glade
* f_widget_order_line.glade
* f_widget_order_line_accept.glade
* f_widget_order_accept.glade
* f_widget_order_modify.glade
* f_widget_modify.glade
* f_widget_enterprise.glade
* f_widget_item.glade
* f_widget_item_modify.glade
* f_widget_item_select.glade
* f_widget_sales_order.glade
* f_widget_sales_order_dispatch.glade
* f_widget_observation.glade
* f_widget_country.glade
Configuration controllers to remove
* f_configuration_controller_client_detail_modify_builder.c
* f_configuration_controller_client_detail_modify.c
* f_configuration_controller_client_detail_new_builder.c
* f_configuration_controller_client_detail_new.c
* f_configuration_controller_client_listing_builder.c
* f_configuration_controller_client_listing.c
* f_configuration_controller_country_detail_modify_builder.c
* f_configuration_controller_country_detail_modify.c
* f_configuration_controller_country_detail_new_builder.c
* f_configuration_controller_country_detail_new.c
* f_configuration_controller_country_listing_builder.c
* f_configuration_controller_country_listing.c
* f_configuration_controller_enterprise_builder.c
* f_configuration_controller_enterprise.c
* f_configuration_controller_item_detail_modify_builder.c
* f_configuration_controller_item_detail_modify.c
* f_configuration_controller_item_detail_new_builder.c
* f_configuration_controller_item_detail_new.c
* f_configuration_controller_item_listing_builder.c
* f_configuration_controller_item_listing.c
* f_configuration_controller_item_select_builder.c
* f_configuration_controller_item_select.c
* f_configuration_controller_order_accept_builder.c
* f_configuration_controller_order_accept.c
* f_configuration_controller_order_accept_listing_builder.c
* f_configuration_controller_order_accept_listing.c
* f_configuration_controller_order_detail_modify_builder.c
* f_configuration_controller_order_detail_modify.c
* f_configuration_controller_order_detail_new_builder.c
* f_configuration_controller_order_detail_new.c
* f_configuration_controller_order_line_builder.c
* f_configuration_controller_order_listing_builder.c
* f_configuration_controller_order_listing.c
* f_configuration_controller_provider_detail_modify_builder.c
* f_configuration_controller_provider_detail_modify.c
* f_configuration_controller_provider_detail_new_builder.c
* f_configuration_controller_provider_detail_new.c
* f_configuration_controller_provider_listing_builder.c
* f_configuration_controller_provider_listing.c
* f_configuration_controller_sales_order_detail_modify_builder.c
* f_configuration_controller_sales_order_detail_modify.c
* f_configuration_controller_sales_order_detail_new_builder.c
* f_configuration_controller_sales_order_detail_new.c
* f_configuration_controller_sales_order_dispatch_builder.c
* f_configuration_controller_sales_order_dispatch.c
* f_configuration_controller_sales_order_dispatch_listing_builder.c
* f_configuration_controller_sales_order_dispatch_listing.c
* f_configuration_controller_sales_order_listing_builder.c
* f_configuration_controller_sales_order_listing.c
* f_configuration_controller_typeday_detail_modify_builder.c
* f_configuration_controller_typeday_detail_modify.c
* f_configuration_controller_typeday_detail_new_builder.c
* f_configuration_controller_typeday_detail_new.c
* f_configuration_controller_typeday_listing_builder.c
* f_configuration_controller_typeday_listing.c
EGBs to remove
* f_egb_country.c
* f_egb_currency.c
* f_egb_enterprise.c
* f_egb_orders.c
* f_egb_order_line.c
|
|
From: Sergio V. S. <sv...@ig...> - 2005-06-27 15:57:17
|
Hi, sometimes we want to know if a given double value is zero or not. We can not be sure that (number == 0) will work due to gdouble way for representing values. That is why I have just added a new function to the util component of fisterra base with the next interface gboolean u_gdouble_is_zero(const gdouble number, const gdouble accuracy) the first argument is the quantity to check, and the second one is a factor that determines the precision that will be used in order to recognize the number as zero or not. This accuracy could be * DOUBLE_IS_ZERO_MAXIMUM_PRECISION * DOUBLE_IS_ZERO_HIGH_PRECISIO * DOUBLE_IS_ZERO_MEDIUM_PRECISION * DOUBLE_IS_ZERO_LOW_PRECISION Most of time, medium precision (or even low) is enough. Maximum precision satisfies 1+DOUBLE_IS_ZERO_MAXIMUM_PRECISION==DOUBLE_IS_ZERO_MAXIMUM_PRECISION The function returns TRUE when we can assume the value is zero with some degree of precision. Greetings. |
|
From: Eloy F. <ef...@ig...> - 2005-06-22 13:52:18
|
El mi=C3=A9, 22-06-2005 a las 13:34 +0200, Alejandro Garc=C3=ADa Castro esc=
ribi=C3=B3:
> The old code continues compiling and woking out without any change. Tip
> about the use of this function (please send any comment about it in order=
to
> homogenize it's use): always call it after a dao call, in the body of the=
if
> free the variables and arrange all the post-conditions. Example:
>=20
> ...
> f_dao_get ... ();
> if (f_egb_check_database_exception(F_EGB(f_egb), message)) {
> =20
> /* all the f_do_destroys and the code needed to get the post-conditions=
,
> think about the use of gotos in order to clean the code ;-)*/
> }
i think that we must check the database exception after all f_dao_*
calls, not only in the f_dao_get_*, we have to solve the problem of the
destroys replication in each check database exception.
bye.
--=20
Eloy Froufe P=C3=A9rez
Computer Science Engineer
Telf: +34 981 91 39 91
Fax: +34 981 91 39 49
mailto: ef...@ig...
IGALIA, S.L. http://www.igalia.com
|
|
From: Alejandro C. <ac...@ig...> - 2005-06-22 11:36:08
|
Hi, in order to avoid all the if (f_do != NULL) f_do_destroy(f_do), we have added the test inside the destroy functions. If you regenerate the code that ifs are not necessary anymore. We should also review the egb_destroys if we want to clean the code a little bit, on the next installment :-). Greetings. -- Alejandro Garcia Castro mailto: ac...@ig... http://www.igalia.com |
|
From: Alejandro C. <ac...@ig...> - 2005-06-22 11:34:56
|
Hi,
we have changed the API of the function f_egb_check_database_exception, the
former API was:
void f_egb_check_database_exception(FEgb *egb,
const gchar *message);
The new API is:
gboolean f_egb_check_database_exception(FEgb *egb,
const gchar *message);
This function was already testing if there was an exception but it did not
say anything about this test.
Therefore you can change your code this way:
...
f_egb_check_database_exception(F_EGB(f_egb), message);
if (f_egb_is_there_exception(F_EGB(f_egb))) {
...
...
if (f_egb_check_database_exception(F_EGB(f_egb), message)) {
...
The old code continues compiling and woking out without any change. Tip
about the use of this function (please send any comment about it in order to
homogenize it's use): always call it after a dao call, in the body of the if
free the variables and arrange all the post-conditions. Example:
...
f_dao_get ... ();
if (f_egb_check_database_exception(F_EGB(f_egb), message)) {
/* all the f_do_destroys and the code needed to get the post-conditions,
think about the use of gotos in order to clean the code ;-)*/
}
...
Greetings.
--
Alejandro Garcia Castro
mailto: ac...@ig...
http://www.igalia.com
|
|
From: Sergio V. S. <sv...@ig...> - 2005-05-13 12:22:13
|
Hi, Fisterra Base has now its own log system. It was migrated from Fisterra Distribution to the framework. Now every application developed with Fisterra Technology is able to use this new log System. In order to check how it works please review the Fisterra Base Documentation. This change affects also Fisterra Distribution. All log system functions were removed. Enjoy Fisterra. Bye. |
|
From: Sergio V. S. <sv...@ig...> - 2005-05-03 16:23:36
|
On Mar, 2005-05-03 at 18:16 +0200, Eloy Froufe P=E9rez wrote: > El mar, 03-05-2005 a las 17:02 +0200, Sergio Villar Senin escribi=F3: > > On Mar, 2005-05-03 at 11:53 +0200, Eloy Froufe P=E9rez wrote: > > > > Should we consider the incidents as another kind of Document? > > >=20 > > > yes. > > So If I understood ell, it will be only one incident per document with > > multiple lines. >=20 > No, a closings of shop register can has several incidents associated > (Cash unsquare, credit card unsquare and gift cheque unsquare) >=20 > The tickets paid with credit card can has only a incident associated of > (ticket credit card unsquare) >=20 Mmmm, I think it could be a problem because documents have lines. Why not having an unique incident for unsquares with different line types (credit card unsquare incident line, in cash unsquare incident line...) Best regards. |
|
From: Eloy F. <ef...@ig...> - 2005-05-03 16:16:41
|
El mar, 03-05-2005 a las 17:02 +0200, Sergio Villar Senin escribi= =C3=B3: > On Mar, 2005-05-03 at 11:53 +0200, Eloy Froufe P=C3=A9rez wrote: > > > Should we consider the incidents as another kind of Document? > >=20 > > yes. > So If I understood ell, it will be only one incident per document w= ith > multiple lines. No, a closings of shop register can has several incidents associated (Cash unsquare, credit card unsquare and gift cheque unsquare) The tickets paid with credit card can has only a incident associated = of (ticket credit card unsquare) Greetings. --=20 Eloy Froufe P=C3=A9rez Computer Science Engineer Telf: +34 981 91 39 91 Fax: +34 981 91 39 49 mailto: ef...@ig... IGALIA, S.L. http://www.igalia.com |