Openbravo Issue Tracking System - Openbravo ERP | |||||
| View Issue Details | |||||
| ID | Project | Category | View Status | Date Submitted | Last Update |
| 0004618 | Openbravo ERP | F. Localization | public | 2008-08-13 09:34 | 2008-12-17 11:09 |
| Reporter | boianv | ||||
| Assigned To | rmorley | ||||
| Priority | normal | Severity | major | Reproducibility | have not tried |
| Status | acknowledged | Resolution | open | ||
| Platform | OS | 5 | OS Version | ||
| Product Version | 2.40beta | ||||
| Target Version | Fixed in Version | ||||
| Merge Request Status | |||||
| Review Assigned To | |||||
| OBNetwork customer | |||||
| Web browser | |||||
| Modules | Core | ||||
| Support ticket | |||||
| Regression level | |||||
| Regression date | |||||
| Regression introduced in release | |||||
| Regression introduced by commit | |||||
| Triggers an Emergency Pack | No | ||||
| Summary | 0004618: Printed invoices do not have all needed data | ||||
| Description | There are some mandatory fields, which should be printed on trade documents, according to our regulations (Bulgaria). For example, Sales invoice must have following data: - Identification numbers of both parties (international VAT numbers for companies or United Personal number for persons) - Names and addresses of both parties - 10 digit number of the invoice (letters not allowed) - Date of the invoice - Date of the tax event (which is the same, but should be printed separately) - Payment terms, including payment type (for example Bank Transfer) - Bank account (for invoices with bank payment) - Payment due date - Place of origin (The city where the invoice was issued) - Name of the Person, who filled the invoice - Reason for using current taxation – several predefined texts, for example ‘Sales with 0 % VAT for EU intra community supplies’ - Text 'ORIGINAL' on the first copy of the document. Text 'COPY' on all other copies. And (not obligatory any more, I think) – Sum of invoice by words. For credit and debit notes, there are some supplementary fields: - number of the invoice, on which the credit/debit note is based - date of this invoice - Some mark for the type of document (For example a checked checkbox with text CREDIT NOTE) when the name of the document is INVOICE, or directly using name CREDIT NOTE instead of INVOICE By regulations, one invoice could not mix different tax types, all rows inside must be with same tax type (and same taxation reason). Next, I believe that no rows could have negative values (as when Discounts are used). Instead, it is possible to add columns in the invoice, showing discount percent and final value. Or, pre-calculating the discounts into the product prices. It is related with profits, too (when calculating profit gains by products). After confirmation and print, any change of the invoice should be denied. Any correction should be made only with another document (Credit note for example). The ideal case is when even the header data remains static - Partner name, address, ID number etc. If they could change in time (For example, partner changes address), the organization has to keep all documents printed on paper. For an organization with large number of invoices this is a problem. | ||||
| Steps To Reproduce | |||||
| Proposed Solution | |||||
| Additional Information | |||||
| Tags | ToBeReviewed | ||||
| Relationships | |||||
| Attached Files | |||||
| Issue History | |||||
| Date Modified | Username | Field | Change | ||
| 2008-08-13 09:34 | boianv | New Issue | |||
| 2008-08-13 09:34 | boianv | Assigned To | => cromero | ||
| 2008-08-13 09:34 | boianv | sf_bug_id | 0 => 2049196 | ||
| 2008-11-10 13:10 | cromero | Assigned To | cromero => pjuvara | ||
| 2008-11-16 18:40 | pjuvara | Status | new => acknowledged | ||
| 2008-11-16 18:40 | pjuvara | Category | 07. Sales management => F. Localization | ||
| 2008-11-16 18:40 | pjuvara | Tag Attached: ToBeReviewed | |||
| 2008-12-17 11:09 | pjuvara | Assigned To | pjuvara => rmorley | ||
| There are no notes attached to this issue. |