Product Information
ATCUD para Portugal: Prepare-se para o novo requisito legal da Portaria 195/2020
(Scroll down for the English version)
Como já deve saber, o governo português publicou a Portaria 195/2020 e, juntamente com o código QR, introduziu o Código de Documento Único (ATCUD) como um novo requisito legal.
Com o Despacho 351/2021.XXII publicado dia 11 de novembro de 2021, ATCUD será opcional em 2022 e obrigatório a partir de janeiro de 2023.
As empresas precisam obter um novo código de validação de série e usá-lo para gerar o ATCUD, sendo este um código único atribuído a documentos fiscais relevantes, como faturas e notas de crédito.
O ATCUD é reportado no ficheiro (SAF-T) e incluido no código QR. Ele deverá também ser incluido nos documentos impressos e eletrônicos.
Para mais informações sobre a solução de código QR, veja o blog post Código QR e ATCUD para Portugal: Fique por dentro das últimas atualizações da Portaria 195/2020.
A solução SAP
Um framework centralizado para gerir as séries e os códigos de validação AT por módulo será disponibilizado, suportando a comunicação manual e eletrônica.
Essa solução está planejada para estar disponível em duas fases:
- Fase 1: Âmbito reduzido (serviços web não incluídos). Está planejado para ser disponibilizado em meados de novembro de 2021.
- Fase 2: Funcionalidade relacionada aos serviços web. Está prevista para ser disponibilizada em meados de dezembro de 2021.
Os pré-requisitos
Existem algumas atividades de preparação que podem ajudar a acelerar as etapas de implementação assim que a solução estiver disponível:
Implementação de SAP Notes
Certifique-se de que implementou as SAP Notes relacionadas ao Despacho 8632/2014:
Comunicação com as autoridades fiscais
Pode utilizar os serviços da Web para comunicar automaticamente com as autoridades fiscais. Para esta comunicação, é necessário integrar o seu sistema com SAP Cloud Integration.
Para mais informações, consulte a SAP Note 2903776 ou entre em contato com seu gestor de conta SAP.
Atividades de configuração
Certifique-se de atualizar as configurações necessárias:
-
- Crie novos intervalos de numeração e defina as respectivas séries únicas para assinatura digital. A nova nomenclatura deve seguir os requisitos legais (não são permitidos caracteres especiais). Para mais informações sobre as atividades de customizing, veja Customizing for Digital Signature of Invoices. Aguarde também as novas instruções que serão publicadas em breve.
- Atribua os novos intervalos de numeração aos respectivos tipos de documento SAF-T.
- Adapte os seus layouts de impressão para incluir o ATCUD nos formulários.
Poderá utilizar os intervalos de numeração e séries atuais enquanto prepara os novos intervalos de numeração. Após 1 de janeiro de 2022, deverá utilizar os novos intervalos de numeração.
SAP Notes lançadas e atualizadas em 2022
Agora você já pode consultar a nota coletiva 3154599 que lhe dará toda a informação relevante para a implementação da solução, inclusive nos diversos módulos (SD, FI, FI-CA, Settlement Management, etc.). Veja também a documentação incluída. Esta nota será atualizada sempre que for liberada a solução de um novo módulo.
Guia de solução de problemas e perguntas frequentes
Consulte o SAP Knowledge Base Article 3274103 para um guia de solução de problemas e respostas a perguntas frequentes para ajudar você no processo de implementação da solução.
Fique atento às notícias mais recentes
Fique atento! Pretendemos atualizar este blog regularmente.
Também pode verificar mais informações no grupo SAP Jam SAP Portugal Collaboration Forum. Se ainda não for membro deste grupo, envie sua solicitação de convite para o seguinte e-mail: marta.pereira@sap.com.
Fique à vontade para deixar seus comentários abaixo se tiver alguma dúvida ou sugestões para uma publicação futura. E não se esqueça de seguir a tag do SAP S/4HANA aqui na SAP Community para ficar atento às notícias mais recentes.
Até à próxima,
Ailane Kuhn
#SAPGoGlobal #SAPLocalization
***
ATCUD for Portugal: Get ready for the new legal requirement on Portaria 195/2020
Hi everyone,
As you might be aware, the Portuguese government published Portaria 195/2020 and, together with the QR code, introduced AT-Validation Code (ATCUD) as a new legal requirement.
With Despacho 351/2021.XXII published on November 11, 2021, ATCUD will be optional in 2022 and mandatory as of January 2023.
Companies need to obtain a validation code for their series and then use it to generate the ATCUD, which is a unique document code assigned to relevant documents, such as invoices and credit memos.
You must include the ATCUD on printed documents and in electronic invoices and also report the ATCUD via the Standard Audit File for Tax Purposes (SAF-T). It must also be included in the QR code.
For more information about the QR code solution, see QR Code and ATCUD for Portugal: Stay Tuned to the Latest Updates on Portaria 195/2020.
The SAP solution
A centralized framework to manage the Series and AT-Validation Codes across modules will be provided, supporting both the manual and the automatic communication.
This solution is planned to be available in two phases:
- Phase 1: Reduced scope (web services not included), planned to be available not earlier than mid November 2021.
- Phase 2: Web service-related functionality, planned to be available not earlier than mid December 2021.
The prerequisites
There are some preparation activities that could help you to speed up the implementation steps once the solution is available:
SAP Notes implementation
Make sure you have the SAP Notes related to Despacho 8632/2014 implemented:
Communication with the tax authorities
You can use webservices to communicate with the tax authorities automatically. For this communication, you need to integrate your system with SAP Cloud Integration.
For more information, see SAP Note 2903776 or contact your account executive.
Configuration activities
Make sure you maintain the required configuration settings:
-
- Create new number ranges and define their unique series for Digital Signature. The new nomenclature should follow the legal requirements (special characters aren’t allowed). For more information about the Customizing activities, see Customizing for Digital Signature of Invoices. Further instructions will be published soon.
- Assign the new number ranges to the respective SAF-T document types.
- Adapt your print layouts to include the ATCUD in the forms.
Note that you can use the current number ranges and series while defining the new number ranges. After January 1, 2022, you must use the new number ranges.
New and Updated SAP Notes Released in 2022
The Collective Note 3154599 has been released with all the information you need to know about the solution implementation for ATCUD in different modules. You can also check the product documentation for more information.
This SAP Note will be updated every time there’s a new solution release for the different modules. Stay tuned!
Troubleshooting Guide and FAQ
Check the SAP Knowledge Base Article 3274103 for a troubleshooting guide and answers to frequently asked questions to help you in the implementation process.
Stay tuned to the latest news
Stay tuned! We plan to update this blog post regularly.
You can also check out the SAP Jam group Portugal SAP Collaboration Forum. If you are not a member of this SAP Jam group yet, please send your invitation request to the following email: marta.pereira@sap.com .
Feel free to leave your comments below if you have any questions or suggestions for an upcoming post. And don’t forget to follow the SAP S/4HANA tag here on SAP Community to stay tuned to the latest news.
See you next time,
Ailane Kuhn
#SAPGoGlobal #SAPLocalization
Hello,
We are testing the ATCUD at SD billing smartforms and we have a 0 value.
The class CL_SIPT_SD_BIL_PRINT01 returns a 0 at method
IF_BADI_SD_BIL_PRINT01~GET_HEAD_DETAILS
ms_header-atcud = mo_print_util->get_atcud( ).
METHOD get_atcud.
"temporary solution definat by tax authority
atcud = '0'.
ENDMETHOD.
Do you know how to change to the real value?
Thank you
Hello Raquel,
If you are using custom forms, the below class might help you:
CL_SIPT_SERIES_REP_SD=>GET_ATCUD_DATA_DOC.
It worked for us.
Thanks,
Jagadeesh
Thank you !!
Hello,
When we try to save the series validation code in GLO_PT_SVC we end up with ABAP dump
Dump analysis indicates that no function module can be found named "ENQUEUE_E_GLO_PT_SVC".
Is there a specific note which need to be implemented to correct this?
Hi
The only note that I see with this is 3137062.
If the problem maintains please open one incident in FI-LOC-LO-PT
Regards,
Marta
Hi Marta,
Thank you ,
the issue was resolved by activating the lock object E_GLO_PT_SVC
Good morning,
We have learned that the transaction GLO_PT_SVC can’t be used with the webservice option in Self-billing process.
We have many suppliers (hundreds) that we will need to execute this option and the solution to do it manually is very difficult to manage in time for this legal request.
We understand that we can only send the request to AT after the vendor has confirmed and given their acceptance in AT portal, but we can manage that control. Obviously we will only send after the vendor has given the approval.
As we have yearly number ranges, this implies that we have a heavy workload every year with this process.
Is SAP going to change the transaction behavior in order to allow the webservice communication to AT for Self-billing process? This is critical for our go-live in the beginning of the year. At the end it is really our responsibility in reporting the correct information.
Thanks in advance
Sérgio Mota
Hi Sergio
When the solution for Webservice was released, the TA still didn´t had the webservice specification available to selfbilling communication.
Only last week, this was released by TA, and we don´t have the time to release it before the year end.
So for this 2023 communication the webservice will not be release, but we are analyzing the possibility to release a solution for automatic communication by webservice for selfbilling during 2023.
Regards, Marta
Bom dia Marta,
Ao atualizar as séries na transação GLO_PT_SVC, os campos Series Start Date e Series Registration Date são preenchidos automáticamente.
No exemplo em baixo, registamos a serie no dia 19.12.2022 e o sistema coloca essa data no campo data de inicio da serie quando pela descrição deveria ser preenchido no campo data reisto da série.
Estive a verificar outros clientes e têm o mesmo comportamento.
Verifico um comportamento diferente quando série é registada na tabela SIPT_NUMBR_FI_V com o ano 9999 para que fique independente de ano. Dessa forma ambos os campos assumem a data de registo.
Agradeço explicação para o preenchimento automático destes campos.
Cumprimentos,
Tiago Baptista
Hello,
When trying to maintain SIPT_NUMBR_SD_V2, we are getting no values to select for SAF-T Document Type:
SIPT_NUMBR_SD_V2
We have also checked in SE11 that SIPT_NUMBR_SD_V2 view is active, GLO_PT_SERIES_DT is also active and GLO_PT_SERIES_DT Domain is also Active with values on its Value Range:
GLO_PT_SERIES_DT
We have checked Notes once and again but all are implemented including manual steps if any. Any possible solution?
Thank you.
Hi Alberto
You need to follow the steps:
Record Number Ranges for Digital Signature of Billing Documents (SD) – SIPT_NUMBR_SD_V
Assign SAF-T Document Types to Number Ranges (SD) – SIPT_NUMBR_SD_V2
GLO_PT_SVC: Manage Series Validation Code for Portugal
It should appear
Regards
Marta
Hi Marta,
Thanks for the answer. But this is what I am doing precisely (following Customizing Digital Signature and ATCUD for SD Billing Documents | SAP Help Portal). I first mantained SIPT_NUMBR_SD_V with a couple of records, and such records are the ones appearing now in SIPT_NUMBR_SD_V2 which I cannot maintain.
PD: I am trying maintaining the view SIPT_NUMBR_SD_V2 directly via tcode SM30 instead of the SPRO "Assign SAF-T Document Types to Number Ranges (SD)" point because this one is not appearing in Customizing, but it should not be the issue (and in case it is, any suggestion to make it appear in SPRO?)
Thank you
Hello,
Implementing ATCUD SBI MM solution and trying to add all the entries on table SIPT_NUMBR_MMN_V, I am getting the following error:
We are using RO - Self Billing GR posted via MRER. Why the entries with Series identifier "V" are not being accepted?
Do we need to do additional configuration beyond NRIV/SNRO?
The same is happening with Series Identifier "N".
We use KO and KN doc type for SBI in consignment and we are not able to add such entries on SIPT_NUMBR_MMN_V.
The only entries that we are able to add are the ones that have Series Identifier started by "S".
Could you please help to understand what is missing to not be able to add "V" and "N" Series Identifiers?
Thank you in advance!
Cátia Ribeiro
Hi Cátia
In the work zone for SAP Portugal Collaboration Forum we added a demo step by step of selfbilling configuration.
Please check that information and use it as a guide.
If you still don´t have access to work zone, please send me one email requesting it (marta.pereira@sap.com)
Regards, Marta
Hi Marta
We need to exclude billing type (used for internal process) from SAF-T reporting.
We have created new Billing type and assigned new number range.
We have maintained SIPT_NUMBR_SD_V for digital signature, but we have not assigned any SAF-T document type in table SIPT_NUMBR_SD_V2 and we have not maintained ATCUD code in GLO_PT_SVC.
However when running SAF-T report, the new billing type create is included in the report.
How to exclude it?
Thank you in advance and best regards
Barbara
Hi Marta
Question about Self- billing.
When I want to include another one Vendor with the number range and serie in the SIPT_NUMBR_MMN_V but the system said to me that I can´t duplicate the serie.
The system indicate "Number range 02 for subobject 000003 has already been used"
This is mean that I must create a different serie/range for each vendor/doc. with the same suboject 000003?
I think that it is so crazy to create different ranges for each vendor
Thank you
Hello,
We are facing the same issue.
Thanks
Sérgio
Hi Blas
This means that for vendor/ SAF-T document type you only can have one NR.
Are you trying to create 2 types of invoices with the same Number range 02 for subobject 000003?
has already been used.
Regards,
Marta
Please also check the video with the customization of selfbilling, that is in work zone
Hi Marta, the last week I sent you an email for access to SAP Portugal Collaboration Forum.
I would like to access. Thank you.
Hi Blas
Can you please send me one email to marta.pereira@sap.com, because I did not received the request
Regards, Marta
Hello Marta,
We have followed the useful video posted in work zone, however the video has only one vendor entry. The main issue is if we need to have a different number range per vendor, if we need to have a different "subobject" per vendor, or shouldn't SAP check only when the combination: Vendor / Subobject / Number range are the same?
Thanks for your assistance.
Regards,
Sérgio
Hi Marta,
No, I want to use for 1 types invoices with a specific range and subobject with all different vendor and the system doesn´t let me.
For exemple:
Hello Marta
I created the new series in SIPT_NUMBR_FI_V and SIPT_NUMBR_FI_V2 for 2023.
my question is, can we register these series for 2023 at GLO_PT_SVC today? or will we only be able to register in 2023?
regards
Hi Hugo
You can register them now with 2023 date
Regards,
Marta
Hi,
I tried posting a FI invoice in Dev/Qas system with a 2023 date and it was not registered in table SIPT_BKPF. Is this normal? I tried using program SIPT_INTERVAL_SIGN_FI but it checks the invoice date is not greater than today's date. It worries me to not be able to test this in Dev/Qas system.
Regards,
Paula.
Hello Marta
Thanks for the answer.
I have one more question related to MM number ranges (self-billing).
as the interval starts every year and the series has to be constituted by, for example, S1+Subobject value+Number interval numbering. in my case it would be something like S1-Z00001-H5 the question is, as I am going to start a new year, I will necessarily have to create a new numbering range to also change the series, correct?
another issue is, if the series does not accept special characters, the probability of running out of number range with letters and numbers only, will be spent very quickly. What is the solution when I no longer have intervals with numbers and letters or letters and numbers, if I cannot use the same series in different years?
regards
Hi Marta:
I am implementing the paymenyt receipts with ATCUD in the SAFT (RG type). I have an issue, because de ATCUD is always zero in the SAFT XML brand payments.
I have done all the customizing and I printed the form (filling the table FIPT_PRI_RECEIPT) but the issue remains. I also have implemented the OSS Note 3231465 (https://launchpad.support.sap.com/#/notes/3231465) which describes the same symptom, but the issue remains.
I need urgent help because we have only 4 days before the Go-live and we need to solve this issue previously.
Thank for your attention.
Regards.
Hi Carlos
Have you already introduced the validation code in the series of doc type reported in SAF-T file?
If you follow all the customization steps you should be able to see the ATCUD in SAF-T file tab 4.4 Payments.
If even so you don´t see the correct ATCUD code please open one incident in FI-LOC-SAF-PT
Regards,
Marta
Hi Marta,
Thank you for your quick answer.
I did it but the issue remains in the development environment. Then, I imported all the transport orders to test environment and the result have been OK. So maybe the cause of the issue would be for the data I am used or some inconsistency in the document type I have been used.
I have another issue in the “payment” brand, because all the data seems are fine in the XML, excepto the label <PaymentMechanism>, which is always filled with the value "OU". Even when I have customized the table FIEUD_PAYM with the mapping with the different payment methods (although I see that this table is only for sales invoices).
This field is mandatory according Portaria n.º 274/2013, so I need to know how configurate the mapping of this label in the branch "payments".
Thank you in advance. Regards.
Hi Marta:
We are facing the following issue when trying to enter the Series for ACTUD in SIPT_NUMBR_SD_V.
ATCUD naming convention for series not enabled yet
Where I should enable the naming convention?.
As second issue I am unable to perform any action on table SIPT_NUMBR_SD_V2
Display View _Number range and Document type Mapping__ Overview.png
Is this normal ?.
Thanks in advance for your help.
Juan Morales de Castro
Hi Marta,
SD-SAF-T document types are not showing in series validation code for Portugal (GLO_PT_SVC)
But SD-SAF-T document types are not showing in GLO_PT_SVC series validation code for Portugal
GLO_PT_SVC
Hi Vasmi
Looking for this screens I can´t see why this is hapenning.
If you have done a similar configuration for all the documents in the different companies (SIPT_NUMST_SD_V and V_2) and even so they are not appearing in GLO, please create one incident)
1 - SIPT_NUMBR_SD_V
2 - SIPT_NUMBR_SD_V2
3 - GLO_PT_SVC
Regards, Marta
Hi Marta,
Thanks for reply and I have raised SAP Incident - 956710
Regards,
Vamsi
Hi Marta:
We are facing the following issue when trying to enter the Series for ACTUD in SIPT_NUMBR_SD_V.
ATCUD naming convention for series not enabled yet
Where I should enable the naming convention?.
As second issue I am unable to perform any action on table SIPT_NUMBR_SD_V2
Display View _Number range and Document type Mapping__ Overview.png
Is this normal ?.
Thanks in advance for your help.
Juan Morales de Castro
Hi Marta,
We have maintained SIPT_NUMBR_OBD table and GLO_PT_SVC with corresponding validation codes...
NUMST OBD
2. GLO_PT_SVC contains only partial entries from NUMBR_OBD table... Could there be a reason for missing entries?
GLOPTSVC
Hello Marta,
We are facing an issue while we post delivery and send for edelivery to get the digital signature we are getting an error "
simple-type 1: element ReturnMessage is not a valid instance of the element type. Value is 'Warning: The document communicated does not have a valid ATCUD. You should check the reason for this anomaly with your software provider. Until the resolution of this".
But I didn;t came across any note or any solutiuon speaking of this ATCUD code mapping to the websevice we use to connect and get digital signature with Portugal government. could you please check and get back to me asap as we have a planned golive of this application in next week Tuesday probably and this is the final step we halted.
Thanks,
Anil
Hi Anil,
First of all I would like to explain that the situation was failing on the Tax Authorities side but the previous situation was restored, so now you should be able to make correct communication of deliveries, even without the ATCUD in the webservice message.
Let me explain what is happening:
The Tax Authorities published the technical instructions on the changes to the WS-message structure on December 12, where the inclusion of the ATCUD fields was described as optional. Internally we triggered the change to be done in our solution, to be delivered during January 2023.
Yesterday however, the Tax Authorities made a change on their portal, changing the reception of the WS-files to the new XSD, where the inclusion of the ATCUD was, however, mandatory.
This is inconsistent with the description of the legal requirement and the XSD should also be changed to optional. This inconsistency is what caused all the problem yesterday.
We expect this problem not to ocurr anymore. In the meantime we keep on working on our solution to include the ATCUD.
Regards,
Daniela Schobert
Hi Daniela,
I work with Anil (initial poster) and wanted to know if there is any action needed from our side to resolve the error? We continue to receive the error message.
Regards,
Raj
Hi Daniela,
Still it seems the ATCUD is mandatory on the tax portal, as we are unable to get the digital signature and aproval id updated in our system when we sent the documents for govt approval. Is there any temporary solution or note to add ATCUD field to proxy structure WSPTSTOCK_MOVEMENT_REQUEST which is the structure used to map the data to the tax authority. When I checked with the document issued by PT tax authority with the name "MANUAL DE INTEGRAÇÃO DE SOFTWARE - Comunicação dos Documentos de Transporte à AT " in section 4.2 it outlined all the data fields to be passed while communicating with the tax authority.
This structure WSPTSTOCK_MOVEMENT_REQUEST has all fields except ATCUD field. Even i see this structure is required to communicate as per ordinance No. 160/2013 Arpil 23.
Hi Daniela Schobert,
Any news on this topic about ATCUD in the webservice delivery documents to AT?
The AT started send email to customers with possible threat, if this issue is not resolved.
Best Regards,
Daniel Cunha
Hi Daniel,
Plz, check if you implement this note: 3293843 - Portugal: Web Service - ATCUD Code Mapping Changes
Best Regards,
Marco
Hi and happy new year to you all. Quick question, should working documents be included in the saft file? our file has two sections under 'source documents': 'sales invoices' and 'working documents' . Is that accurate?
-<SourceDocuments>
+<SalesInvoices>
+<WorkingDocuments>
</SourceDocuments>
Thanks for clarifying!
Regards,
Venecia
Hi Venecia
Yes, working documents should be reported in tab 4.3 - WorkingDocuments
Regards,
Marta
Hi Marta
Can you pl. explain the relevance of field Series Type code in Table GLO_PT_SVC ?
There are 4 values here"
This field is auto updated as "N" when we save the table SIPT_NUMBR_SD_V2.
How and when is this field updated to the Other values. Especially "F"?
Can we use "F" for Testing purpose ?
Would be good if you provide some isights of this field.
Hi Marta
Awaiting your response.
Hi Violet
We only support N and R from standard
N for normal invoice/delivery
R for special Billing/Delivery Types which are configured as recovery document type in SIPT_SDT* tables
When you communicate with TA from the test system, and with the webservice, then TA will know that this is one F.
F is for the cases were the software can generate from the same system Productive and non productive documents. This is not the case from SAP, were we have a productive system and a test system.
Regards
Marta
Hello Marta and Team,
Implementing ATCUD SBI MM solution we are facing 2 issues in Production:
When posting ISAUTO_MRNB we are not able to get the correct serie - S2, we always get the S1 which is defined for invoices posted using MRER.
How should be the series defined on SIPT_NUMBR_MMN_V in order to have the proper behavior?
2. Not all the series that we have defined on the table SIPT_NUMBR_MMN_V were automatically defined on the GLO_PT_SVC table.
Why is this happening and how to solve this issue?
We have both SIPT_NUMBR_MMN_V and SIPT_NUMBR_MM_V maintained.
Thank you in advance for your support!
HI Catia
Can you please open 2 incident. Incident 1 for topic 1 and incident 2 for topic 2.
Colleagues from development will help you and see what is the problem.
Regards
Marta
Hello,
We need to know how to proceed with the LR and LG invoice types.
Is it correct to assign it to the SAF-T document type 'OU' (Other)?
Thank you in advance.
Hi Raquel
If they are invoices reported for e-fatura (monthly Billing SAF-T file) they need to be classified as:
If this are invoices then needs to be FT.
If they are Credit Memos need to be NC
If they are Debit Memos need to be ND
........
OU is only for documents that are not defined in the law (usually special working documents).
Regards,
Marta
Hi,
Can anyone tell me how to exclude non digitally signed documents from the SAFT file please? we have some documents which update accounting but are not sent to the customer and thus are NOT digitally signed. View SIPT_NUMBR_SD_V with 'digital signature' blank.
This was previously allowed as per note 1713631, but then, the functionality was removed by SAP due to Governmental resolution Despacho 8632/2014. But in this removal SAP did not consider some documents which are created when using the Standard SAP customer self-billing functionality whereby:
1- an internal billing document is created in our system
2- the customer sends us their self-billing document via EDI
3- the customer document is reconciled with our internally generated document via VSB1
4- differences are posted from this tcode as debit/credit memo
The customer sends us the SAFT file to be submitted for their self-billed document; therefore, our internally generated documents cannot be digitally signed or sent in the SAFT file we create for non self-billing customers.
Marta, I do not know if you are reading these questions anymore; I hope you are and that you please connect with your internal team to see what SAP solution provided for this since we are using STANDARD SAP functionality.
Looking forward to an answer or at least some directions.
Regards,
Venecia
Hello All,
We are facing an issue in QR Code string 'G'(invoice number of Self Billing documents) post the implementation of ATCUD.
The length of invoice number stored in SIPT_RBKP table has increased to 24 characters due to the new series identifiers. The Invoice number field in standard utility class CL_SIPT_QRCODE_PT--header-invoice_no. is only 20 characters long. The last 4 digits are getting truncated. It would be helpful if someone can confirm this same issue happening in the QR Code details(tag G) of Self billing documents.
If there is no such issues can you please let me know the standard object that you are using which has enough length to print all the 24 characters of the invoice number stored in SIPT_RBKP.
Thanks in advance,
Jagadeesh
Hi Maria
Want to check with you on how to address the scenario below :
There is a Series which we have allocated for Testing in the test Server and we now have a new series for the Production Server. We have assigned the Test Series to the New Number Ranges Number in table SIPT_NUMBR_SD_V
We need to use the Same Number Range Number (which we have created new) for Production and assign the Production Series to it.
We cannot change the Series attached to the Number Range Number as there are documents created against it. But we need to Transport the same Number Range Number with a different series (Production series)
How do we manage this ?
Also can you explain how and when one uses the "Finish Series" and "Cancel Series" in Tcode GLO_PT_SVC
Hi Marta,
I have an issue about Self-billing without agreement.
In this situation AT said:
So how can I use the same ATCUD series for more than 1 vendor? Will SAP provide a solution?
Best Regards,
Marco Oliveira
Hi Marco
The Selfbilling ERS solution implies that there is an agreement and that each vendor has it's own dedicated number range. In this scenario is not required a specific number range for each vendor. This implies that SAP ERS solution (dedicated for selfbilling) should not be used.
And this scenario is out of scope of the SAP solution
Regards,
Marta
Hello Marta,
We have a problem with the number range in SIPT_NUMBR_SD_V.We already have digital signature and numnber range for it with start date. We need to keep same series now also for the ATCUD code.How we can achieve this in case we cannot have two number ranges for one Billing type? Can we stop the exisitng range and start from the next number in a new one and how to activate in case Start date is grayed out ?
Thank you in advance!
Best regards,
Teodora
Hi Marta,
I would like to know the expected date on which SAP will make available the delivery comunication solution with AT, with the ATCUD information.
Best Regards
Silvia Ferreira
Hello, Marta, is there an SAP news about this topic? We're also being questioning about out accounting department on this topic.
Best regards,
Paula.
Olá Marta,
Implementámos a Nota 3293843 - Portugal: Web Service - ATCUD Code Mapping Changes, para enviar o ATCUD no WS para a AT.
Mas agora estamos com um erro :
Erro resolvido, faltava implementar o requisito: Note 3295176 - Portugal ATCUD in Outbound Deliveries: Data Utility for fetching Validation code.
No entanto, estamos a obter a seguinte mensagem de erro do WS:
Entrega aprovada. Mensagem de retorno de WS:Alerta: O documento não apresenta um ATCUD válido. Para efeitos de controlo de bens em circulação, deverá fazer-se acompanhar do documento de transporte imp
Nº mensagem BL001
Obrigado.