Difference between revisions of "HOWTO Process Documents"
m |
m |
||
Line 15: | Line 15: | ||
* [[DocType_Invoice_Customer|Invoice for the Customer]] | * [[DocType_Invoice_Customer|Invoice for the Customer]] | ||
* [[DocType_Invoice_Vendor|Vendor's Invoice]] | * [[DocType_Invoice_Vendor|Vendor's Invoice]] | ||
− | * [[DocType_Shipment|Shipment]] | + | * [[DocType_Shipment|Shipment]] for the sold products |
− | * [[DocType_Material_Receipt|Material Receipt]] | + | * [[DocType_Material_Receipt|Material Receipt]] for the purchased stock |
− | * [[DocType_AR_Receipt|Payment from Customer]] | + | * [[DocType_AR_Receipt|Payment from Customer]] |
− | * [[DocType_AP_Payment|Payment to Vendor]] | + | * [[DocType_AP_Payment|Payment to Vendor]] |
− | * | + | * [[DocType_Material_Physical_Inventory|Inventory]] of the Waehouses |
+ | * [[DocType_Material_Movement|Movement]] of Products | ||
+ | == Points for the advanced users == | ||
The questions touched in these documents' inspections just skim the deeper matters related to document processing. When looking at those explanations some prior knowledge might be useful: | The questions touched in these documents' inspections just skim the deeper matters related to document processing. When looking at those explanations some prior knowledge might be useful: | ||
* About the [[Default_Accounts_Usage|usage of DEFAULT_ACCOUNTS]] - these are special accounts from the Chart Of Accounts, which are bound in the source code to standard processes. So the posting of mainstream activities is backed up and automated. | * About the [[Default_Accounts_Usage|usage of DEFAULT_ACCOUNTS]] - these are special accounts from the Chart Of Accounts, which are bound in the source code to standard processes. So the posting of mainstream activities is backed up and automated. | ||
'''Note that all the examples given include accounts from the American COA which comes along with the ADempiere installation.''' | '''Note that all the examples given include accounts from the American COA which comes along with the ADempiere installation.''' | ||
− | * | + | *In General there are two types of classes defining the behavior of the documents. These are: |
+ | # '''[[DocTypesClasses_CommonClasses|Common classes]]''' | ||
+ | - DocumentEngine.java - | ||
+ | |||
+ | 2. '''Specific classes'''. As their names point out these classes are the implementors of the concrete behavior of the corresponding type. | ||
+ | * There are '''16''' ''model classes'' describing the behavior of the '''34''' active ''Document Types''. | ||
* Concerning ''accounting'' there are '''15''' ''document classes'' which are responsible for posting the documents. The mapping between the classes and their corresponding document types are provided in the following table. | * Concerning ''accounting'' there are '''15''' ''document classes'' which are responsible for posting the documents. The mapping between the classes and their corresponding document types are provided in the following table. | ||
* When we talk about automatic generation of documents the consequent "papers" in the corresponding workflow should be minded, and the automation is provided by the workflow itself. That means with the completion of a single document the set of connected ones is generated and posted in a sequence. The automatic generation is not about using certain form to choose from which document to produce other type (e.g. to produce Shipment from Sales Order through the ''Generate Shipment (manual)'' form). | * When we talk about automatic generation of documents the consequent "papers" in the corresponding workflow should be minded, and the automation is provided by the workflow itself. That means with the completion of a single document the set of connected ones is generated and posted in a sequence. The automatic generation is not about using certain form to choose from which document to produce other type (e.g. to produce Shipment from Sales Order through the ''Generate Shipment (manual)'' form). |
Revision as of 07:47, 27 December 2007
Contents
Processing Basics
In ADempiere there are several predefined types of documents, as can be seen in the picture below.
This window can be reached in the ADempiere Client App's menue (if you are logged in a role with access level 'Client+Organization') this way:
Menu -> Performance Analysis -> Accounting Rules -> Document Type
The automated internal processing of those documents is a complex matter. What we start here is a simple FAQ-like explanation of those base documents. Where appropriate a further explanations are provided, redirecting to database entities, source code and articles by other ADempiereans.
List of described documents
- Invoice for the Customer
- Vendor's Invoice
- Shipment for the sold products
- Material Receipt for the purchased stock
- Payment from Customer
- Payment to Vendor
- Inventory of the Waehouses
- Movement of Products
Points for the advanced users
The questions touched in these documents' inspections just skim the deeper matters related to document processing. When looking at those explanations some prior knowledge might be useful:
- About the usage of DEFAULT_ACCOUNTS - these are special accounts from the Chart Of Accounts, which are bound in the source code to standard processes. So the posting of mainstream activities is backed up and automated.
Note that all the examples given include accounts from the American COA which comes along with the ADempiere installation.
- In General there are two types of classes defining the behavior of the documents. These are:
- DocumentEngine.java -
2. Specific classes. As their names point out these classes are the implementors of the concrete behavior of the corresponding type.
- There are 16 model classes describing the behavior of the 34 active Document Types.
- Concerning accounting there are 15 document classes which are responsible for posting the documents. The mapping between the classes and their corresponding document types are provided in the following table.
- When we talk about automatic generation of documents the consequent "papers" in the corresponding workflow should be minded, and the automation is provided by the workflow itself. That means with the completion of a single document the set of connected ones is generated and posted in a sequence. The automatic generation is not about using certain form to choose from which document to produce other type (e.g. to produce Shipment from Sales Order through the Generate Shipment (manual) form).
Model class | Document Type | Document-Posting Class |
---|---|---|
MInvoice | AP CreditMemo | Doc_Invoice |
MInvoice | AP Invoice | Doc_Invoice |
MPayment | AP Payment | Doc_Payment |
MInvoice | AR Credit Memo | Doc_Invoice |
MInvoice | AR Pro Forma Invoice | Doc_Invoice |
MInvoice | AR Invoice | Doc_Invoice |
MInvoice | AR Invoice Indirect | Doc_Invoice |
MPayment | AR Receipt | Doc_Payment |
MAllocationHdr | Payment Allocation | Doc_Allocation |
MBankStatement | Bank Statement | Doc_Bank |
MCash | Cash Journal | Doc_Cash |
GL Document | (??? Doc_ProjectIssue ???) | |
MJournal | GL Journal | Doc_GLJournal |
MInventory | Material Physical Inventory | Doc_Inventory |
MMovement | Material Movement | Doc_Movement |
Material Production | Doc_Production | |
MInOut | MM Receipt | Doc_InOut |
MInOutConfirm | MM Receipt with Confirmation | Doc_InOut |
MInOut | MM Shipment | Doc_InOut |
MInOut | MM Shipment Indirect | Doc_InOut |
MInOut | MM Shipment with Pick | Doc_InOut |
Match Invoice | Doc_MatchInv | |
Match PO | Doc_MatchPO | |
Project Issue | Doc_ProjectIssue | |
MOrder | Purchase Order | Doc_Order |
Purchase Requisition | Doc_Requisition | |
MOrder | On Credit Order | Doc_Order |
MOrder | POS Order | Doc_Order |
MOrder | Prepay Order | Doc_Order |
MOrder | Proposal | Doc_Order |
MOrder | Quotation | Doc_Order |
MRMA | Return Material | Doc_Order |
MOrder | Standard Order | Doc_Order |
MOrder | Warehouse Order | Doc_Order |
Specific automations common to the most types of documents
- Payment Term specifics - for documents defining Payment Term other than 'Immediate' the contents of the tab Payment Schedule are automatically populated with data, based on the chosen rule. If the Payment Term is changed after the document is Completed, the Payment Schedule is not affected and the necessary changes must be made manually.