cancel
Showing results for 
Search instead for 
Did you mean: 

Batch-input

Former Member
0 Kudos

Dear abapers,

The environment: SAP R/3 4.0B

The problem: a batch-input program for entering physical inventory differences (tcode MI10).

The program uploads into memory physical inventory data form a text file and then, using a CALL TRANSACTION mechanism, creates the documents.

The program is used for recouting three kinds of stock: normal (own), "consignment vendor" stock (stock in custody at the reseller) and "consignment customer" stock (in custody at the customer).

Running the program against the first two types of stock produces the expected output. The physical inventory differences documents are created correctly.

The following effects are observed when running the program against the third type of stock:

- the inventory documents are not created, although the corresponding numbers from the physical inventory documents number range are allocated.

- The user receives a message in his SAPOffice inbox stating that the update process is finished (transaction code MI10, update code XXXXX).

Furthermore: the manual creation of the documents for this kind of stock is always succesful.

And more:

- running the program on this type of stock for creating a document with two lines is succesful.

- imediatly after that, running the program for a document with 20 lines failes to create the document (the user receives the message in the inbox).

- imediatly after that, increasing the document size (3 lines, 4 lines, ... 20 lines) in successive executions leads to succesful creations of documents.

Could you help me understand where the problem is?

Thank you,

Bogdan

Accepted Solutions (1)

Accepted Solutions (1)

christian_wohlfahrt
Active Contributor
0 Kudos

Hello Bogdan,

you describe a strange behavior, indeed. Have you checked for shortdumps (ST22) and SYS-log(SM21) already?

Call transactions (CT) are executed in a 'standard' window size - whatever this might be in your case (might be system and user dependent). If you try to enter to much lines, CT will abort - but then no booking would be started, document number wouldn't be taken out of number range.

Perhaps, try to run 'secure' options: use only 6 lines (because that worked), use 'L' (instead of 'A' or 'S') for booking mode.

Regards,

Christian

Former Member
0 Kudos

Christian,

The problem originates in a not-very-well-written user-exit at MB_DOCUMENT_POST when saving a material document.

Creating a difference document in physical inventory has also the effect of creating a material document (to record a movement (+/-) in the stock of materials).

The purpose of the user-exit (which is triggered when saving a material document) was to create a corresponding accounting document for certain kinds of material documents.

In certain conditions, this accounting document isn't created correctly, and this has the effect of rolling-back all the work. But the number allocation out of the number range for inventory documents (and also for material documents) would not be rolled-back, so I have my explanation.

My batch input does not depend on the number of lines to be inserted in the document, because I use a "new-line" mechanism.

So, and I checked this, the batch-input is 100% correct.

But I found useful your suggestion to check the syslog (SM21). This log lead me to SM13 - "Update Records" where I found a more detailed description of the problem, and ofcourse of its causes.

Answers (1)

Answers (1)

christian_wohlfahrt
Active Contributor
0 Kudos

Hi Bogdan,

glad to hear you found the reason for your problem.

Having an (implicit) commit work in update task (MB_DOCUMENT_POST) is starting point for technical problem. If you like to correct this: create (own) change pointers and a job-event. In a second report, you are free to have additional commit works.

In 4.7 some scaring documentation can be found for MB_DOCUMENT_BADI:

If this business add-in is not set up properly, it may result in an inconsistency between the documents and the stocks and between the material documents and the accounting documents. Inconsistencies like these may be caused by the following elements in the business add-in:

COMMIT WORK

Remote function call (CALL FUNCTION ... DESTINATION)

Own updates in document tables or stock tables (for example, update in tables MBEW, MARD, MSEG)

The unlocking of data (for example, via DEQUEUE_ALL)

Before the two business add-ins are called up, data is already flagged for the UPDATE. If a COMMIT WORK or a Remote Function Call is transmitted in the enhancement, these are written in the database. If another error occurs after the business add-ins are processed, you cannot carry out a complete ROLL BACK, as the data up to the COMMIT or Remote Function Call has already been written in the database. This can result in an inconsistent status (for example, material document without accounting document), which can only be repaired with considerable cost and effort.

If data inconsistencies have already occurred in your system as a result of the business add-in, remove the critical coding so that it does not cause any further inconsistencies.

(Bad quoting, sorry)

Regards,

Christian

Former Member
0 Kudos

Christian,

You offered me a very detailed, technical and accurate analysis.

I might add to your list of things that could cause inconsistencies between material documents and accounting documents (in a business add-in - customer exit) the following: the creation of the non-standard accounting document through direct-input (AC_DOCUMENT_DIRECT_INPUT).

Fortunately the problem only occured in the testing system, not in the productive system because the changes in the customer exit weren't transported yet.

Still, it is essential for us to use this customer exit.

The error that occurs is the following:

"RW 022: FI/CO interface: Balance in transaction curre[?]"

This means that the accounting document is not balanced.

The amounts on debit and on credit are calculated by the business add-in. So, the error must be HERE, or I shall go mad.

The problem is that I cannot debug this customer-exit. Or can I?

Thank you,

Bogdan