Brazil CFOP : 571848 - How to Implement the CFOP Legal Change 2003
Symptom
The Brazilian government released the legal change Ajuste SINIEF 07/01 which impacts the CFOP
format and determination in practically all Brazilian logistic processes.
SAP developed a solution which was delivered via Support Packages and Notes.
This solution also affects the business processes in terms of migration, customizing and handling of transactions. This note will explain how the solution works and give some guidance for a successful implementation.
Other Terms
CFOP, Brazil, Brasil, Legal Change, Problem, Apply Note, Handling,
Customizing
Reason and Prerequisites
Legal Change. Relevant for all Brazilian Company Codes.
Solution
1. About this note
This note is intended to give information how to apply the very complex correction of the
CFOP legal change for 2003. It will be constantly updated with new information for
troubleshooting and handling, so in case of any problems related to the legal Change 2003, please verify if an updated version of this note is available and consult it first.
Changes of Current Version:
30.10.2013: File Z_CFOP_MIGRATE.TXT was enhanced in order to update table LIPS as well.
11.03.2011: The correction instruction of the program was deleted and the source code
were attached to the file Z_CFOP_MIGRATE.TXT, also the note were extended to subsequent versions.
20.03.2006: The program Z_CFOP_MIGRATE delivered with this note was enhanced with the
option to run the program additionally for VBAP
(Please create textelement 120: Sales Document Items (VBAP)).
12.03.2004: After upgrading to release 4.70 from lower releases, problems can occur when
reports or queries are used with the usage of select-options for the CFOP. For details
see below.
23.01.2004: After upgrading to release 4.70 from lower releases, problems can occur when
taking over CFOP customizing from the lower release. For details see below.
15.1.2003: View J_1BNFITMRULEV implemented by SAPSERV transport contains error; section 7
d ("troubleshooting") gives a description how to correct it.
7.1.2003: Regenerating View J_1BTREGV described in more detail
Attachment CFOP_2003.TXT updated with corrected texts
Attachment CFOP_SAMPLES.PDF uploaded (Screenshots and Samples)
2. Technical Information
Due to the complexity and the tight deadlines, the solution was not delivered as a whole.
Instead, an initial solution was delivered, which is complemented by corrective notes.
Before beginning any setup, it is strongly recommended to apply all available corrections.
These are the Notes:
Appl. Rel. Initial Note SP Correction Notes SP
4.70 553750 05 568942 05
4.6C 553750 39 568942 39
573983 40 (after 1.1.2003)
4.6B 571476 48 573971 49 (after 1.1.2003)
4.5B 569513 58 572431 59 (after 1.1.2003)
4.0B 571316 80 573960 81 (after 1.1.2003)
In addition there are changes in the ABA layer, which are on a differentrelease cycle for 4.6C
and 4.70:
ABA Rel. Initial Note SP Correction Note SP
6.20 553750 14
4.6C 553750 39
4.6B 553750 48
for the older releases these changes are contained in the same Note and
Support Package as the Application Correction.
It is strongly recommended apply the corrections via Support Package. However, since they are
only available in Mid-December 2002, you may opt to apply the notes manually. In this case,
you should at least apply the latest available Support Package (i.e. the above stated SP for
the respective release minus 1). Otherwise, the application of prerequisite notes may be very time consuming, since a large number of program objects is affected,
which causes interdependencies.
The notes were implemented successful by some companies in only a few days by following the
steps you find below. Therefore we strongly recommend to follow this implementation strategy:
Implementation of the prerequisite notes. According to this successful implementations,
many of these notes (including the large DSEG optimization note 523948) were implemented
with the note assistant.
Implementation of the SAPserv transport relevant for your release
Manual application of all objects described in the note "CFOP legal change 2003
(Ajuste SINIEF 07/01)" for the related R/3 release which are not coding
(this includes function modules, includes, views, etc.)
Application all coding changes with note assistant version 1.2
Carrying out the same steps 3 & 4 for correction notes for the relevant release.
Please note that the content of some of the correction notes is contained in the same SP as
the basic note. In this case, if the solution is applied via SP and not manually, there is no
need to apply the correction. For those releases, where the corrections are contained in the
following SP only, the correction note must be applied on top of the base SP
(e.g. for Release 4.5B). When applying the solution manually, it is always required to apply
both notes.
Further comment:
The tables / fields and documentation are available in English. The Portuguese version is
released via Support Package. If you'd like to translate it before the SP, please use the
transaction SE61 to translate it for your own.
Creation of new objects via transport:
If the corrections are applied manually, a lot of objects (for example DDIC objects like new
data elements, tables, views etc.) must be created, before the source code corrections can be
applied. In order to facilitate this, the new objects are alternatively supplied via a
transport which is attached to each note or available on SapServ:
sapserv4.sfo.sap-ag.de/dist/cfop2003/
When applying the transport, the objects included in it need not be
created manually.
Warning: the transport does not support any versioning and will overwrite all existing objects
which are contained in the transport. Since the delivered transports contain only the new
objects described in the note, this should not occur. However, be aware about the risks
involved with the transport. Please refer to note 13719 for details on applying transports
to your system.
3. How to use the solution
The Support Packages and Notes contain already the documentation for all new data elements,
maintenance views and IMG activities. However, in this section the whole procedure what to do
after implementing the note is described as complementary information.
a) Using the migration report J_1BCFOP_MIGRATE
Attached to this note you find the file "CFOP_2003.TXT". Store this file on your local PC
(e.g. C:\CFOP_2003.TXT).
With the help of this program the following tables can be filled:
J_1BCFOPVER, J_1BCFOPVERT, J_1BCFOP_XREGN, J_1BAGN, J_1BAGNT, J_1BAON and J_1BAPN
You should run the program J_1BCFOP_MIGRATE ONCE (!) in a productive (i.e. non testrun).
You have also the option to delete the entries of the new tables and to repeat program run of
the migration program.
If you have business places in SP and/or SC, it's important that the entries in J_1BCFOP_XREGV
are maintained
country region description/region extension length
BR SC Santa Catarina 2
BR SP São Paulo 1
That's important because only in this case 4 versions are generated:
version 1 - old default; version 2/3 for SP/SC and version 4 - new 2003 CFOPs Otherwise you
will not the versions used for SP and SC. Please keep in mind, that the records from the
tables J_1BAOX and J_1BAPX (exception tables for states with CFOP extensions) are used for
filling the new CFOP determination tables J_1BAON and J_1BAPN.
Additional comment:
Be aware, that the migration report J_1BCFOP_MIGRATE takes the logon language as language for
the new 2003-CFOPs while creating the entries into J_1BAGNT. Furthermore, the delivered file
"CFOP_2003.TXT" contains only Portuguese text. Therefore, you should login in Portuguese, if
you want to have the new 2003-CFOP texts in Portuguese.
Troubleshooting Information:
A prerequisite for running the program is that the latest version of the conversion exit for
the CFOP (function modules CONVERSION_EXIT_CFOBR_OUTPUT and CONVERSION_EXIT_CFOBR_INPUT) are
already implemented.
b) Defining CFOP Versions
The first major change of the solution consists in the versioning of the CFOP codes.
This allows to have both the old formats and the new format coexistent in the system,
which is necessary to handle pending documents. After applying the solution, you have
to define CFOP versions. We suggest to use 1 for the old regular CFOPs, 2 for the old CFOPs
of Santa Catarina, 3 for the old CFOPs of São Paulo and 4 for the new CFOPs coming in 2003.
In principle you could define any other version numbering and the concept allows to handle
possible future legal changes in a straightforward fashion.
Activities required: The new View J_1BCFOPVERV can be maintained via a new IMG activity which
is part of the correction.
c) Assigning Versions
The CFOP Versions are assigned to a validity which may depend on time and region. For example
assign version 4 to a valid from date of 1.1.2003, country BR (leave region blank, since
the version is valid forall of Brazil) and version 3 to a valid from date of 1.1.2001,
country BR and region SP.
Activities required: The new view J_1BCFOP_XREGNV can be maintained via a new IMG activity
which is part of the correction.
d) Defining CFOP Codes
The definition table of the CFOP codes has been changed in order to consider the versioning,
by adding it as a key field. From now on you have to maintain each CFOP code for a certain
version, which could mean that some CFOP codes may be redundant in the system (e.g. the CFOP
512/01 is valid for versions 1, 2 and 3). The migration report which is delivered with the
solution will create all these entries from the old customizing. From then on, you most
likely only need to maintain the new CFOP codes (for the 2003 version).
Activities required: The new view J_1BAGNV can be maintained via a new IMG activity which
is part of the correction. Please note that the old view J_1BAGV is obsolete and should no
longer be used!
Troubleshooting Information:
Problem: when trying to save a CFOP code which is seemingly correct, the Error Message
8B 034 or similar appears.
Solution: verify if the ABA corrections (possibly contained in the respective correction
note) of the conversion exits are correctly applied.
a) Defining Tax Free Zones
A new concept which was developed for SAP Enterprise has been downgraded with this solution
in order to allow correct handling of tax free zones (like Zona Franca de Manaus or Cidades
Conveniadas). In this concept, a tax region ( = jurisdiction code, for example ZF) is flagged
as tax free. This information is used in the CFOP determination (e.g. for CFOP 5.910).
Activities required: The changed view J_1BTREGV can be maintained via the IMG activity Define
Tax Regions. Create a separate Tax Region for each Free Trade Zone and assign it to the
proper region and flag it as tax free.
Troubleshooting Information:
Problem: The Tax Free flag is not saved to the database after view maintenance.
Solution: Regenerate maintenance objects of the view J_1BTREGV as follows:
Use Transaction SE11 in change mode
Verify that all parameters are conforming to the descriptions in the respective note for your
release.
Via Men choose Utilites -> Table maintenance generator
Select generated Objects -> Change.
Flag all fields except 'Maintenance Type Changed' on the following two popups and confirm.
Afterwards, verify and adapt the layout on the screen painter.
a) Defining Nota Fiscal Item Types
A new concept which was developed for SAP Enterprise has been downgraded with this solution in
order to allow custom definition of Nota Fiscal Item Types (which were previously Domain Fix
Values). Now, the NF Item Types have a value table with customer namespace A0 to ZZ and SAP
namespace 00 to 9Z. Most of the new cases in automatic CFOP determination can be solved by
making use of an appropriate item type. However, since the cases are so numerous and may vary
with the business needs, it was decided not to define new fix values, but to allow customers
a free definition of new item types. This is one of the main efforts to be done after
implementaion of the note: define, which new item types have to be created and how they
should be used in CFOP determination. This should be done by a project team with both
solid technical and business (fiscal) background. SAP Brasil has developed a number of
suggestions in cooperation with ASUG Brasil.
Activities required: The new view J_1BITEMTYPES can be maintained via transaction SM30.
SAP delivers the migration report J_1BFILLRECTYPES. This report fills the table J_1BITEMTYPES
with a number of item types (see section below, 'Customizing NF Item Types').
If you have modified the domain J_1BITMTYP before (adding fix values), please save the data
before application of the note in order to be able to reenter them in the table.
Troubleshooting Information:
Problem: It is not possible to maintain new entries in the table.
Solution: Verify that the domain J_1BITMTYP does not contain any fix values any more.
Verify the maintenance screen of the view J_1BITEMTYPES using the screen painter. Make
sure that the field for the item type is NOT a listbox. If necessary, change and
activate.
a) Customizing NF Item Types
The NF Item Types have a lot of implications for Brazilian coding apart from the CFOP
determination. Previously, a lot of functionality was hard-coded depending on the NF Item Type.
With allowing custom definition, this is no longer possible. Therefore, a fairly large number of flags was
introduced to control the program logic
(e.g. for tax calculation and reporting purposes), which can be attributed to each item type.
SAP delivers the migration report J_1BFILLRECTYPES. This report fills the table J_1BITEMTYPES with following item types:
1 Normal Item
2 Transfer shipment item
21 Returnable packaging shipment item
31 Subcontracting invoice item
32 Subcontracting component shipment item
33 Subcontracting component symbolic shipment item
41 Future delivery invoice item with ICMS
42 Future delivery shipment item with IPI
43 Future delivery invoice item without ICMS/IPI
44 Future delivery shipment item with ICMS/IPI
51 Consignment invoice item
52 Consignment shipment item
61 Third party invoice item from vendor
62 Third party invoice item from supplier
63 Third party shipment item from supplier
64 Third party future delivery invoice item from supplier
65 Third party future delivery symbolic shipment item from supp
Additionally, the report J_1BFILLRECTYPES fills the rules required for the item types,
i.e. it populates the view J_1BNFITMRULEV. The solution contains the customization for all NF Item Types that were
part of SAP standard.
Additional comments:
It's sufficient to run the migration report J_1BFILLRECTYPES once after you have finished the implementation of the note.
When you create new item types it is a good idea to clone existing item types with similar properties and adapt the
customization if necessary.
Activities required: The new view J_1BITEMRULEV can be maintained via a new IMG activity which is part of the correction.
If you want to create new NF Item Types, please (1) create the respective value in the view J_1BITEMTYPES. (2)
Afterwards you have to maintain the view J_1BITEMRULEV (via SM30 or the new IMG activity) by pressing the
'New Entries (F5)' button and selecting the new NF Item Type.
b) Other Parameter Changes
Some of the parameters needed for CFOP determination have been enhanced such as Material CFOP category or Customer
CFOP category. The added domain fix values are delivered and available for CFOP determination.
Activities required: none.
c) Defining CFOP Determination
The tables for automatic CFOP determination in MM and SD have remained similar to the previous tables, only the
version was included in the key. Similar to the CFOP definition itself, the determination logic (i.e. table entries)
have to be duplicated for each old version, which is done by the migration report. After running the migration report,
it should only be necessary to define new rules for the 2003 CFOP version.
Activities required: The new view J_1BAPNV can be used to maintain automatic CFOP determination in SD, the new view
J_1BAONV can be used to maintain automatic CFOP determination in MM. In order to do this, the new domain values
(Material-, Customer CFOP Category, etc.) can be used as well as the custom defined item types. This should be done
by a project team with both solid technical and business (fiscal) background. SAP Brasil has
developed a number of suggestions in cooperation with ASUG Brasil.
Troubleshooting Information:
Problem: CFOP that is entered in J_1BAPNV disappears.
Solution: Verify that in the view J_1BAPNV, the field CFOP refers to J_1BAPNV (not J_1BAGNV) and is not
flagged as key field. Regenerate the maintenance objects as described in the respective correction note.
Problem: CFOP is not an input field in view J_1BAPNV.
Solution: Verify the maintenance screen of the view J_1BAPNV using the screen painter. Make sure that the
field for CFOP is NOT belonging to the group KEY and is flagged as input field. If necessary, change and activate.
a) Special Cases for CFOP Determination
There are some special cases in CFOP determination which shold be treated with care:
- Free Trade Zones
In order to handle CFOP determination for Free Trade Zones, new destination categories 3 and 4 were introduced.
They are determined based on the Tax Free Flag of the recipient tax region. For example a sale from Amazonia to
Zona Franca de Manaus (flagged as Tax Free) would yield a destination Category of 3, whereas a sale from São Paulo
to ZF de Manaus would yield 4. This can be used to determine CFOP 5.910 and 6.910, respectively.
- Purchasing for special purposes
There are some purchasing CFOPs which depend on the intended usage, e.g.application of a material
in a service or purchasing a material for later exportation. For such business cases it is necessary
to define new NF item types and customize the CFOP determination based on them.
- Selling of materials purchased under certain circumstances
There are some CFOPs, which need a link to a previous purchase. E.g. when exporting a material,
which was previously purchased for this purpose. Or when selling materials, which were previously
purchased in consignment. Or when selling materials which were previously purchased under certain
conditions of Substituição Tributária (SubTrib).Unfortunately there is no satisfactory 'out of the
box solution'. However, here are some alternatives given:
Using a dedicated NF Item Type: This is always possible, but has the implication that you have to assign a
dedicated Sales Item Category as well. This means duplication of the according customizing plus the necessity
of either additional user interaction (choose correct item type in the sales order) or duplicating order types as well.
However, for some scenarios, this would anyway be the regular business case (Example: Export of goods purchased for
this purpose. In such cases, typically the sale order would be created first with a special item type which triggers
the correct CFOP, then a purchase requisition is created based on this sales order, which in turn would require the
correct item type to be entered for the incoming invoice in MM).
Via Business Add In (BAdI) or Customer Exit: A more difficult, but more flexible solution is to make use of the new
BAdIs (Releases 4.6+) or Customer Exits (4.0B and 4.5B). This requires the implementation of customer specific ABAP
coding and can therefore only be done by ABAP consultants in team with fiscal experts. The main idea is to allow the
input parameters stored in the structure J_1BINCFOP to be modified by the customer coding before the actual CFOP
determination is carried out.The intended usage is to modify the Special Case Indicator (J_1BSPCSTO) which has a
reserved customer range between 60 and 99. Maintain the view J_1BAPNV with freely defined values of this Special
Case Indicator for each special business case and fill the parameter in the ABAP coding as needed. How this is
done depends entirely on the individual business pracices. For example, if you are selling goods which were
previously purchased in consignment, you need somehow to distinguish these materials from regular ones in the
sales transaction. This could be done by split valuation (assign a special valuation type when purchasing for consignment).
In this case the customer ABAP could fill the special case indicator based on a valuation type (which may be entered
in the sales order or delivery). Or it could be done to assign a dedicated storage location for consigned goods.
In this case the customer ABAP could fill the special case indicator based in the plant and storage location
(which may be entered in the sales order or delivery). There are various other possibilities, which have to be analyzed case by case.
a) Customizing Modelo texts:
Please enter the following texts from modelo 1 and 2 into the view J_1BMODTEXTV:
082 Simples Faturamento
084 Simples Faturamento de merc. cons. NF
085 Rem. em Consignação
086 Ref. a NF Simp Rem.
087 Rem. p/Industrial.
088 Ret. de Industrial.
090 Ref. a NF Simp Fat.
105 NF Simpl Faturamento
107 Simples Faturamento de merc. consign. NF
108 NF Rem em Consignaç.
109 Ref a NF Simples Rem
110 Rem p/Industrializaç
111 Ret de Industrializ.
113 Ref a NF Simples Fat
Troubleshooting Information:
Problem: In view J_1BAPNV it is not possible to enter different values for the special stock indicator
Solution: Verify that the input field on the maintenance screens of view J_1BAPNV for J_1BSPCSTO is NOT a Listbox.
If necessary, change and reactivate the screen. Furthermore, verify that the Domain J_1BSPCSTO has the following
intervals on the Values Tab, lower part. In case it is missing, add them and re- activate the domain.
Lower Limit Upper Limit
50 59
60 69
70 79
80 89
90 99
1. How to implement a BAdI (4.6C and 4.7 only)
Use Transaction SE18 (Business Add In Builder)
Definition Name CFOP_DET_PREP (Display)
a) Viewing the sample coding
The sample coding can be viewed via Goto->Sample Coding->Display
A list of methods is displayed in a table control, containing the 3 methods defined by the
BAdI itself (IF_...) plus two sample methods (see also below). By selecting a line and
pressing the Parameters button, you can view the input and output parameters of the
respective method (similar to the interface of a function module), which are available
for operations inside the method. By pressing on the blue screen icon, you can view the
source code of the samples. These samples show how the exporting parameters can be
fille based on some programming using the importing parameters.
To create an own implementation, go back to the initial screen and choose from the menu
Implementation->Create (you can view the existing implementations using Implementation->Overview).
Choose a package where you want to store the implementation.
Click on the interface tab, which produces the list of the available
methods.
You can now select each method and enter the source code according to
your requirements for each method.
The methods are used in the following contexts:
CHANGE_PARAMETERS_SD: is called immediately before the system (re-)determines the CFOP code.
Inside the method, you can change the input parameters for the CFOP determination, which are
stored in the structure J_1BINCFOP. We suggest that you only modify the parameter J_1BSPCSTO,
since overwriting the other values of the structure may lead to unpredictable behaviour.
The available input parameters on which you may build your logic, can be viewed by pushing
the signature button. Note that not all of the optional parameters are always filled, e.g.
the VBAK and VBAP are only filled when called from sales. Therefore you should check for
initial values and program for different cases (e.g. when called from Sales, Shipping or Billing).
1. Example: use of the storage location in order to influence the CFOP Determination
It is assumed, that the Plant BR01, Storage Location 0001 is used for consignment and the
Storage Location 0002 is used to store materials for exportation purposes. Furthermore,
it is assumed, that the table J_1BAPNV is maintained with the following special case indicators J_1BSPCSTO:
# 60 to distinguish sales of stock purchased in consignment
# 61 to distinguish export of stock purchased for this purpose
data: lv_plant type werks,
lv_sloc type lgort.
if not is_vbrp is initial.
lv_plant = is_vbrp-werks.
lv_sloc = is_vbrp-lgort.
elseif not is_lips is initial.
lv_plant = is_lips-werks.
lv_sloc = is_lips-lgort.
elseif not is_vbap is initial.
lv_plant = is_vbap-werks.
lv_sloc = is_vbap-lgort.
endif.
if lv_plant eq 'BR01'.
if lv_sloc eq '0001'.
cs_cfop_determination-spcsto = 60.
elseif lv_sloc eq '0002'.
cs_cfop_determination-spcsto = 61.
endif.
endif.
2. Example: valuation types are used in order to influence the CFOP determination
( CONSIG for materials purchased in consignment, EXPORT for materials purchased for exportation)
It is assumed, that the table J_1BAPNV is maintained with the following special
case indicators J_1BSPCSTO:
# 60 to distinguish sales of stock purchased in consignment
# 61 to distinguish export of stock purchased for this purpose
if is_mbew-bwtar = 'CONSIG'.
cs_cfop_determination-spcsto = 60.
elseif is_mbew-bwtar = 'EXPORT'.
cs_cfop_determination-spcsto = 61.
endif.
CHECK_PARAMETERS_SA: normally, when entering a sales order, the CFOP determination is triggered anew,
only when certain parameters are changed (e.g. the plant or the material number). Depending on your
coding in the method CHANGE_PARAMETERS_SD, you may want that the CFOP is redetermined, when other
parameters change, which are normally not considered (if for example you have programmed something
depending on the storage location, you may want that the CFOP determination is triggered, whenever
the storage location is changed. You should include a comparison for each such parameter and return
a 'X' in case a CFOP determination is necessary.
Example: trigger redetermination when storage location is changed
if is_vbap_new-lgort ne is_vbap_old-lgort.
ev_determination = 'X'.
endif.
CHECK_PARAMETERS_SH: the purpose is the same as CHECK_PARAMETERS_SH, only that this method is called in shipping instead of order entry.
For better modularization, you may create your own methods by defining a name, the signature (input/output parameters) which must be a subset of the main method and implement part of the coding as desired.
Example: trigger redetermination when storage location is changed
if is_lips_new-lgort ne is_lips_old-lgort.
ev_determination = 'X'.
endif.
After finishing the coding changes, save and activate the implementation.
Further guidance is available via online help of the BAdI Builder.
2. How to implement User Exits (version 4.0B, 4.5B, 4.6B)
Use transaction CMOD.
The user exits serve the same purpose and are called in the same context (with the same interface parameters) with the following correspondence:
User Exit BAdI method
EXIT_SAPLJ1BH_001 CHANGE_PARAMETERS_SD
EXIT_SAPLJ1BJ_001 CHECK_PARAMETERS_SA
EXIT_SAPLJ1BK_001 CHECK_PARAMETERS_SH
Semantically the implementation is analog to what was described for the BAdI.
For further guidance, consult the online help of the transaction CMOD and the function builder (SE37).
For explanation how to use and sample coding, please see also section above for the BAdIs.
3. Behaviour of the system during transactions
One of the main problems with the legal change is the treatment of pending documents. I.e. when a sales order
is created in 2002, the CFOP which is determined will be of version 1 (or 2 or 3, if it is in SC or SC, respectively).
However, if the delivery and billing takes place in 2003, then the new CFOP (version 4) has
to appear on the Nota Fiscal. Previously, there was no redetermination in the Delivery or Billing and the
CFOP determination was not time-dependent. With the new solution, itis possible to trigger a
redetermination in Delivery and Billing. To accomplish this, the redetermination flag of the new Version (e.g. 4) must be set.
In this case, a redetermination may occur in delivery or billing, when the billing date
deviates from the preliminary billing date of the referred sales order. This means, if the CFOP determination is customized
correctly for the new version and the redetermination flag is set, the system should
automatically redetermine the CFOP if needed. However, there is a pitfall: if the automatic CFOP determination should fail for
whatever reason (J_1BAPNV not correctly maintained etc.) and the redetermination in
Billing fails, then the billing document may contain the wrong CFOP (billing typically happens in batch processing without user
interaction and the field CFOP is not open for edit in billing). In such cases,
it may be necessary to cancel erroneous billing documents, change the CFOP code in the delivery, deactivate the redetermination
flag and bill anew!
4. Update to release 4.70 from lower releases:
After upgrading to release 4.70 from lower releases, and taking over CFOP customizing from the lower release,
the error 058(00) "Entry 9999AAdoes not exist at J_1BAG" can occur when entering CFOP at the NF writer.Please implement the program
Z_CFOP_MIGRATE that you find below into your system locally and run it once.
This program converts the encoded CFOPs into uncoded entries in the tables J_1BAG, J_1BAGT, J_1BAGN and J_1BAGNT. This is possible
because the CFOP length (domain J_1BCFOP) was enhanced to 10 digits
(instead of 5 digits at the lower releases).
Modification of the report (12.03.04): After running the report as described above,
all dialogs (purchase and billing processes, NF writer, maintenance views) including the reporting are working properly.
However, the usage of select options for CFOPs in local reports or queries is not possible.
If you want to use this functionality the CFOP in the NF database table (J_1BNFLIN) must be
uncoded (i.e. from encoded CFOPs into uncoded entries). The latest version of the program
Z_CFOP_MIGRATE offers the possibility to uncode the CFOPs at NF database table (J_1BNFLIN)
additionally to the functionality as described already above (Please maintain the selection texts in the following way:
BAGN - 'Tables J_1BAG(N)/J_1BAG(N)T'; BNFLIN - 'NF database table (J_1BNFLIN)'; PVBRP - 'Billing Document: Item Data' (VBRP);
TESTRUN - 'Testrun').
Be aware, that this conversion is only required if you want to use select options for
CFOPs in local reports or queries; otherwise it's recommended to leave the entries at J_1BNFLIN and VBRP unchanged.
a) Troubleshooting
b) coding implementation - LJ1BGF01:
If your support package level is for rel. 40B equal/lower than 77, for rel. 45B equal/lower
than 55, for rel. 46B equal/lower than 43, for rel. 46C equal/lower than 32 the coding line
PERFORM SUBST_WTXDATA_FROM_CONDITIONS.
will not exist. Please implement the required coding just by ignoring
the coding lines
* for new condition-based calculation, get wtxdata
PERFORM subst_wtxdata_from_conditions.
After the implementation the coding should look like this:
.......
wnfdoc-subser = j_1bb2-subser. " Subseries
ENDFORM.
*"----------------------------------------------------------------------
*" Fill interface NF Tax per line
*"----------------------------------------------------------------------
FORM fill_nf_taxes_line_interf.
* fill item type rules table "note 553750
if gt_nfitmrule[] is initial. "note 553750
select * from j_1bnfitmrule into table gt_nfitmrule. "note 553750
endif. "note 553750
c) Prerequisites for implementation of note 553750 (rel. 46C) and 571476 (rel. 46B)
Ih your support package level of your Application Basis (ABA) is lower 26 (rel. 46B)
and 15 (rel. 46C), please implement additionally note 192251.
d) Coding correction - J_1BLB01/J_1BLB02 (release 46C):
Modelo 1 and 2 (J_1BLB01/J_1BLB02) show following syntax error after
implementation of note 553750 in release 46C:
'The sum of offset (1)and length (3) exceeds the field length (3).'
Please implement the coding below to correct the error:
J_1BLB01:
.....
data: begin of key,
pstdat like j_1bnfdoc-pstdat,"posting date
species(2) type c, "species of fiscal document:
"NF = Nota Fiscal
"CO = Conhecimento
regio like j_1binnad-regio, "region
parid like j_1bnfdoc-parid, "partner identification
series like j_1bnfdoc-series,"series
"of the fiscal document
subser like j_1bnfdoc-subser,"subseries of the fiscal doc.
nfnum like j_1bnfdoc-nfnum, "number of fiscal document
docnum like j_1bnfdoc-docnum,"to distinguish different
"documents (summing)
Delete line:
cfop_noext(3) type n, "cfop no. without extension
Insert lines:
* cfop_noext(3) type n, "cfop no. without extension note 553750
cfop_noext(4) type n, "cfop no. note 553750
J_1BLB02:
.......
data: begin of key,
pstdat like j_1bnfdoc-pstdat,"posting date
species(2) type c, "species of fiscal document
"NF = Nota Fiscal
"CO = Conhecimento
series like j_1bnfdoc-series,"series of the fiscal document
subser like j_1bnfdoc-subser,"subseries of the fisc. doc.
nfnum like j_1bnfdoc-nfnum, "number of fiscal document
regio like j_1binnad-regio, "region
docnum like j_1bnfdoc-docnum,"to distinguish different
"documents (summing)
Delete line:
cfop_noext(3) type n, "cfop number without extension
Insert lines
* cfop_noext(3) type n, "cfop number without extension note 553750
cfop_noext(4) type n, "cfop number note 553750
e) Description of itemtpyes is missing in J_1BNFITMRULEV when view implemented via SAPSERV transport
Please follow following steps to correct this error (Important: The screens are not deleted,
only the maintenance dialog is created correctly, if you follow the steps below).
Edit table View J_1BNFITMRULE and change the field type of fields MAINITEM1, MAINITEM2, ...,
MAINITEM10 from J_1BRTMAINITEM to J_1BITMTYP
Edit the view J_1BNFITMRULEV. Goto the tab 'Table/join conditions' and remove the tables
J_1BITEMTYPEST and J_1BITEMTYPES. Then create the join conditions again and take care,
that the join conditions look like:
J_1BITEMTYPES MANDT = J_1BNFITMRULE MANDT
J_1BITEMTYPES ITMTYP = J_1BNFITMRULE ITMTYP
J_1BITEMTYPES MANDT = J_1BITEMTYPEST MANDT
J_1BITEMTYPES ITMTYP = J_1BITEMTYPEST ITMTYP
Goto the tab 'view fields' and enter
TEXT J_1BITEMTYPEST TEXT
as additional entry.
Start SE54. Enter view J_1BNFITMRULEV. Mark 'generated objects' and click on 'delete'.
At the following popup, mark checkbox 'Maintenance mod' and confirm all warning messages.
When the system has finished, mark 'generated objects' and click on 'create/change'.
At the following screen, click on 'create' and create the maintenance dialog again.
Posts
Post a Comment