Project:
| View Issue Details[ Jump to Notes ] | [ Issue History ] [ Print ] | |||||||
| ID | ||||||||
| 0052913 | ||||||||
| Type | Category | Severity | Reproducibility | Date Submitted | Last Update | |||
| defect | [Openbravo Localizations] Localization Portugal | major | always | 2023-07-03 14:05 | 2023-08-16 15:16 | |||
| Reporter | sofidossant | View Status | public | |||||
| Assigned To | jonae | |||||||
| Priority | high | Resolution | no change required | Fixed in Version | ||||
| Status | closed | Fix in branch | Fixed in SCM revision | |||||
| Projection | none | ETA | none | Target Version | ||||
| OS | Any | Database | Any | Java version | ||||
| OS Version | Database version | Ant version | ||||||
| Product Version | SCM revision | |||||||
| Regression date | ||||||||
| Regression introduced by commit | ||||||||
| Regression level | ||||||||
| Regression introduced in release | ||||||||
| Summary | 0052913: EWI -Não é possível alterar o NIF de um Terceiro utilizado em documentos SAF-T, a menos que esteja vazio ou seja o NIF genérico | |||||||
| Description | When I create a bp, make a sale, and then want to edit the name, this EWI is generated: Não é possível alterar o NIF de um Terceiro utilizado em documentos SAF-T, a menos que esteja vazio ou seja o NIF genérico | |||||||
| Steps To Reproduce | - Open a terminal with the configuration for portugal - We add a bp without NIF - We make a sale - Edit name in the bp | |||||||
| Proposed Solution | It should not be possible to edit and change the name of a BP already used in a sale, for which there is no NIF. This fact should be warned to the user, therefore that change can not take place, preventing the creation of an EWI in the back-end. Even more the message give refers to the NIF not to the name. Please review this, by taking into account that: It would be possible to change the name of the BP if that BP has a valid NIF. It would be possible to change the NIF of the BP if it is empty or if it is the generic one (99999990) It is not possible to change the name of the BP if that BP has no NIF | |||||||
| Tags | No tags attached. | |||||||
| Attached Files | ||||||||
 Relationships [ Relation Graph ]
[ Dependency Graph ]
|
|
 Relationships |
|
Notes |
|
|
(0152052) sofidossant (developer) 2023-07-03 14:07 |
video https://drive.google.com/file/d/17zN_STfZb6t8dyhfmNu2zREkXX5rkx79/view?usp=sharing [^] |
|
(0152093) seaweedfrock (reporter) 2023-07-04 09:14 |
see more: https://dinosaurgames.io [^] |
|
(0152841) sofidossant (developer) 2023-07-24 14:37 |
news? |
|
(0153285) jonae (developer) 2023-08-07 12:09 |
Let me explain the behaviour around this functionality: There is validation around the customer edition (name and cif), that happens only when there are documents assigned to the customer. Currently, what is considered a document assigned is when the customer has an invoice created. When the customer created does not have tax id, there is validation saying that the invoice is not being generated. This means that when a ticket is processed for a customer without a tax id, means that the invoice is not generated, so the system considers that the customer does not have any document assigned. This means that the validation in step 1 is not done and that’s why the name can be changed as the issue in mantis describes. Apart from that, if the customer does not have a tax id, the saft hash generation code is not performed, so the order is not properly synchronized. Several questions here: The system is considering only the invoice as a document to validate if the customer has documents assigned. Is that correct? When the customer does not have a tax id assigned, the hash is not generated (what means that the ticket is not properly synchronized). Is that correct? The validation of not generating the invoice if the customer does not have a tax id, is correct? For me the solution could be that, if the customer does not have a tax id, the invoice can be generated using the “fake“ tax id. |
|
(0153545) jonae (developer) 2023-08-16 15:16 |
This validation in working fine in the core distribution. The front validates the requirements of the change in the terms described in the descripcion of the issue and shows a message to the user when needed. In the case of the customer, this is not working fine due to a custom module related to the integration with an external CRM. In this case, this custom module needs to be modified to implement the same validation than the saft module, to show the appropiate message to the cashier. |
|
Notes |
|
Issue History |
|||
| Date Modified | Username | Field | Change |
| 2023-07-03 14:05 | sofidossant | New Issue | |
| 2023-07-03 14:05 | sofidossant | Assigned To | => psanjuan |
| 2023-07-03 14:07 | sofidossant | Note Added: 0152052 | |
| 2023-07-04 09:14 | seaweedfrock | Note Added: 0152093 | |
| 2023-07-04 09:57 | psanjuan | Proposed Solution updated | |
| 2023-07-04 09:58 | psanjuan | Assigned To | psanjuan => Triage Omni OMS |
| 2023-07-04 11:17 | aferraz | Assigned To | Triage Omni OMS => jonae |
| 2023-07-24 14:37 | sofidossant | Note Added: 0152841 | |
| 2023-08-07 12:09 | jonae | Note Added: 0153285 | |
| 2023-08-16 15:16 | jonae | Note Added: 0153545 | |
| 2023-08-16 15:16 | jonae | Status | new => closed |
| 2023-08-16 15:16 | jonae | Resolution | open => no change required |
|
Issue History |
| Copyright © 2000 - 2009 MantisBT Group |
 |