Openbravo Issue Tracking System - Openbravo Localizations |
| View Issue Details |
|
| ID | Project | Category | View Status | Date Submitted | Last Update |
| 0052913 | Openbravo Localizations | Localization Portugal | public | 2023-07-03 14:05 | 2023-08-16 15:16 |
|
| Reporter | sofidossant | |
| Assigned To | jonae | |
| Priority | high | Severity | major | Reproducibility | always |
| Status | closed | Resolution | no change required | |
| Platform | | OS | 5 | OS Version | |
| Product Version | | |
| Target Version | | Fixed in Version | | |
| Merge Request Status | |
| Regression date | |
| Regression introduced by commit | |
| Regression level | |
| Support ticket | |
| OBNetwork customer | |
| 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 |
| Additional Information | |
| Tags | No tags attached. |
| Relationships | |
| Attached Files | |
|
| 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 |
|
Notes |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
(0153285)
|
|
jonae
|
|
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
|
|
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. |
|