- Table: C_BPartner
- Generated Access Layer: X_C_BPartner.java (extends PO.java)
- The Business functionality class : MBPartner.java (extends X_C_BPartner.java)
Posted by Jorg Janke on 04/07/2021 at 12:50 PM in Technology | Permalink | Comments (0) | TrackBack (0)
Reblog
(0)
| | Digg This
| Save to del.icio.us
|
|
The Compiere data model is consistently based on the principle of surrogate or anonymous key. As an example, the product table (called "M_Product") has the column "M_Product_ID" as the primary key. The primary key is a unique number generated based on a sequence table. For entities maintained by Compiere (e.g. dictionary), these IDs are below one million whereas the ID for normal entries are above one million.
The user key value for the product is maintained in the column "Value" (40 unicode characters) and the product table has other standard columns as "Name" (60 characters), "Description" (255) and "Help" (2000). You will find the columns Value (or DocumentNo), Name, Description and Help in most of the tables.
The standard columns are the primary key " _ID" (e.g. M_Table_ID), the tenant "AD_Client_ID" and organization "AD_Org_ID", the active flag "IsActive", the time, the record was created and last updated "Created", "Updated" and the user who created the record and updated it - "CreatedBy" and "UpdatedBy". The latter are foreign keys to the user table AD_User and it's primary key AD_User_ID. The user key "Value" is unique for a tenant (supported by a unique key) and could be used for the product number or a harmonized product name for easier search.
In addition to this, UPC (or EAN) and SKU can be used as alternative user keys. In this example, they are not unique and supported by an index. The user can easily make UPC and/or SKU unique by switching the flag on the index.
Continue reading "Keys, IDs and table structure in Compiere" »
Posted by Jorg Janke on 03/24/2008 at 06:59 AM in Technology | Permalink | Comments (0) | TrackBack (0)
Reblog
(0)
| | Digg This
| Save to del.icio.us
|
|
The majority of complex functionality is defined in processes - the other area are the "Business Model Classes" (M*.java). In some situations a process just calls a method in the Business Model class, in others it is more appropriate to put the logic in a separete process class.
A Compiere Process can be called from the menu, a button or command line. The process may run on a Client (Swing or Web Server) or on the application server. As part of Compiere's "save-fail" architecture, a process may run on the client, if the application server is not available.
Compiere processes extend the abstract class org.compiere.process.SvrProcess and you find most of the processes in Compiere in the package org.compiere.process. To set up the process, you log in with the System Administrator role and create a record in the window Report & Process referencing the class you created. This process then can be added to the menu or in the Table and Column window as a button.
Continue reading "Starting Compiere Process from Command Line" »
Posted by Jorg Janke on 03/09/2021 at 10:05 AM in Technology | Permalink | Comments (0) | TrackBack (0)
Reblog
(0)
| | Digg This
| Save to del.icio.us
|
|
Compiere allows to schedule any process or report and run them based on a set of dynamic parameters. You can execute batch process or generate reports on a regular basis.
The Schedule defines when it is run and how often. You can define particular week days or month days in addition to flexible frequencies (every two days/weeks/...). You can optionally restrict the execution to certain week days and time windows. Compiere supports multiple application servers for load balancing. In the schedule you can restrict the execution to certain servers or set of servers.
The Scheduler determines the process or report to run. It is easy to write your own process in the Compiere framework extending the class SvrProcess - or you run any of the currently 270 core processes or reports in Compiere. The parameters can be hardcoded or use dynamic variables, like @Date@ for the current date or @AD_Org_ID@ for the current organization. The power of the scheduler is in it's ability to define a list of result recipients. This allows the Scheduler to be used for report bursting to a set of individual users or groups (roles). The recipients are not restricted to internal users, but can include also external consultants or business partners. You can send the results either via email - the result is then added as a PDF document - or via a Notice. You can view Notices in the Swing or Web user interface - or in the Self-Service (Web Store) part of the application. The latter also allows external parties to view their Notices and it is a user preference if you want to receive emails and/ or notices.
You could also start processes from operating system schedulers. This approach might be preferred for importing data when the process should be started after the new data or file is available. You could also do polling from Compiere processes directly. The option you select is an implementation choice. You can also start workflows from batch, but here, we just concentrate on starting a process in this posting. The easiest way to start a process is to code a static Java "main" method as follows:
Posted by Jorg Janke on 02/12/2020 at 02:04 PM in Technology | Permalink | Comments (0) | TrackBack (0)
Reblog
(0)
| | Digg This
| Save to del.icio.us
|
|
All reporting in Compiere has two parts: The data ("model") and the format ("view").
You can have multiple views on the same model (Model Driven Architecture) - i.e. you use the invoice data to create a daily invoice report and a customer history report - you would use different columns, different sorting and different summary information, but it is based on the same data (model).
In this posting, I'll concentrate on how to add a new model for reporting. For that, you can use database tables directly, or database views. The creation of a vew is much easier in Compiere, as you do not have to de-reference the fields. Example: when you want to list the payment term of an invoice, you just add the column C_PaymentTerm_ID to the report, Compiere autimatically re-references the ID and prints the name of the payment term.
When using a third party reporting tool, you would have to program the view to display the payment term name. Also, in Compiere reporting, all security rules are automatically applied - example: if a user of the system would not have access to the payment term, you would have to create a separate report for that user. So, to create a custom report, you "just" have to create a database view.
Posted by Jorg Janke on 08/22/2007 at 08:55 AM in How-To, Technology | Permalink | Comments (1) | TrackBack (0)
Reblog
(0)
| | Digg This
| Save to del.icio.us
|
|
Recent Comments