Convert binary bytes to Labview Extended Precision type

Hello All:
I am reading a binary file that was written in Windows. One of the types used in the data structure
is the Delphi extended precision type, which is 10 bytes. When reading this in using Labview's
"read binary file" VI, there is only one choice, and that is to read it in as an array of 10 bytes
(Labview's extended precision is 16 bytes.) I have tried using the type cast with no results.
So....how to convert the data in the 10 byte array to a 16 byte extended precision format in
Labview? I guess part of the problem is not really understanding how the extended precision
type is stored in IEEE format.
Has anyone performed this conversion before that could help out? I'm sure this must have
been done by someone....somewhere....I have no hair left....
Any help would be appreciated!
Thanks,
Gary.

Uhm, something must have gone wrong, the link TST sent,
mentions that LabVIEW stores extended data as 80 bit (10 bytes) on Intel platform.
Complex double is stored as two doubles (=16 byes). My guess is that Altenbach's latest note mentioning the endianess should help you.
If the endiannes is right you should be able to just typecast the data:
Free Code Capture Tool! Version 2.1.3 with comments, web-upload, back-save and snippets!
Nederlandse LabVIEW user groep www.lvug.nl
My LabVIEW Ideas
LabVIEW, programming like it should be!

Similar Messages

Converting binary data to cluster

Hello,
I have a problem converting binary data to a cluster. I have to create a VI that reads out some parameter from a device, which is connected via RS232. I get an array of 128 Byte from the device. The data has the following (C-)structure:
struct PARAM
char cVersion[64];
float fDeviceID;
float fChannels;
float fSensor;
float fTrigger;
float fConst[5];
char cReserved[28];
How can I convert the binary array to a cluster? I created a cluster (see attachment), but I couldn't connect it with the "Type Cast" VI. Has anyone an idea how to solve this problem?
Thanks, Martin
Attachments:
cluster.jpg ‏16 KB

It is tedious to convert binary data to LabVIEW data when you have arrays. You have to typecast the data with clusters of the same fixed length as in the structure. Large clusters are easily created on the diagram using Array to Cluster primitive. See the attavhed picture.
LabVIEW, C'est LabVIEW
Attachments:
conversion.gif ‏11 KB

How to convert a certificate from byte[] typeback to its original type

Doing work about transfer Certificate through network using socket, after using
Certificate.getEncode() convert it into byte[] type, then send through network, but
at the receiver side, don't know how to convert the byte[] format back to the
Certificate? Or there is a better way to transfer Certificate as a file through
socket?

If it is an X509 one:
Certificates are instantiated using a certificate factory. The following is an example of how to instantiate an X.509 certificate:
InputStream inStream = new FileInputStream("fileName-of-cert");
CertificateFactory cf = CertificateFactory.getInstance("X.509");
X509Certificate cert = (X509Certificate)cf.generateCertificate(inStream);
inStream.close();

Do numerical indicators display extended precision floats correctly?

I'm using windows XP sp2 on a new computer with a new intel processor, nothing weird. I'm displaying an extended precision floating point number using a numeric indicator that is set to display an extended data type with thirty digits of precision. I expect to see at least 19 or 20 significant digits out of my extended precision float, but the numeric indicator only ever displays 17 significant digits before going to a trail of zeros. Does the display routine that converts the float to a display string use double precision or what?
global variables make robots angry

Yes, I understand what you are saying and you are completely correct. The problem I have is not that I expect a mathematically perfect representation of a number, but rather that LabVIEW calculates and produces an 80-bit extended precision number on my computer and then appears to convert it to a 64-bit representation of that number before displaying it!
If you convert the extended precision value into an unflattened string in order to attempt to access the binary representation of the data, you’ll find that it is represented by 80-bits. This is a 64-bit fraction plus a 15-bit exponent plus one bit for the sign. Delightfully, the flatten to string function appears to scramble the bits into “noncontiguous” pieces, so about all I can tell for certain is that we have, as expected, an 80-bit extended precision number in memory. The documentation for the other number-to-Boolean array and bit manipulation functions I looked at (even the exponent-mantissa function) all claim to only be able to handle a maximum input of a 64-bit number (double precision float max) -correct me if I’m wrong on this one, because I’d really like to be able to see the contiguous binary representation of 80-bit extended floats.
It turns out though that what you said about not being able to tell whether we have twenty digits of precision without bit fiddling is not true at all. If you look at the program I wrote, you can prove with simple addition and subtraction that beyond the shadow of a doubt the extended numbers are being stored and calculated with twenty digits of precision on my computer yet being displayed with less precision.
As you can plainly see in the previous example I sent:
A =          0.1111111111
B =         0.00000000001111111111
A+B=C= 0.11111111111111111111
We know that
C-A=B
The actual answer we get is
C-A=0.00000000001111111110887672
Instead of the unattainable ideal of
C-A=0.00000000001111111111
The first nineteen digits of the calculated answer are exactly correct. The remainder of the actual answer is equal to 88.7672% of the remainder of the perfect answer, so we effectively have 19.887672 digits of accuracy.
That all sounds well and good until you realize that no individual number displayed on the front panel seems to be displayed with more than 16-17 significant digits of accuracy.
As you see below, the number displayed for the value of A+B was definitely not as close to being the right answer as the number LabVIEW stores internally in memory.
A+B=0.11111111111111111111 (the mathematically ideal result)
A+B=0.111111111111111105     (what LabVIEW displays as its result)
We know darned well that if the final answer of A+B-A was accurate to twenty digits, then the intermediate step of A-B did not have a huge error in the seventeenth or eighteenth digit! The value being displayed by LabVIEW is not close to being the value in the LabVIEW variable because if it were then the result of the subtract operation would be drastically different!
0.11111111111111110500       (this is what LabVIEW shows as A+B)
0.11111111110000000000       (this is what we entered and what LabVIEW shows for A)
0.00000000001111110500    (this is the best we can expect for A+B-A)
0.00000000001111111110887672 this is what LabVIEW manages to calculate.
The final number LabVIEW calculates magically has extra accuracy conjured back into it somehow! It’s more than 1000 times more accurate than a perfect calculation using the corrupted value of A+B that the display shows us – the three extra digits give us three orders of magnitude better resolution than should be possible unless LabVIEW is displaying a less accurate version of A+B than is actually being used!
This would be like making a huge mistake at the beginning of a math problem, and then making a huge mistake at the end and having them cancel each other out. Except imagine getting that lucky on every answer on every question. No matter what numbers I plug into my LabVIEW program, the intermediate step of A+B has only about 16-17 digits of accuracy, but miraculously the final step of A+B-A will have 19-20 digits of accuracy. The final box at the bottom of the program shows why.
If you convert the numbers to double and use doubles to calculate the final answer, you only get 16-17 digits of accuracy. That’s no surprise because 16 digits of accuracy is about as good as you’re gonna do with a 64-bit floating point representation. So it’s no wonder all the extended numbers I display appear to only have the same accuracy as a 64-bit representation because the display routine is using double precision numbers, not extended precision.
This is not cool at all. The indicator is labeled as being able to accept an extended precision number and it allows the user to crank out a ridiculous number of significant digits. There is no little red dot on the input wire telling me, ‘hey, I’m converting to a less accurate representation here, ok!’ Instead, the icon shows me ‘EXT’ for ‘Hey, I’m set to extended precision!’
The irony is that the documentation for the addition function indicates that it converts input to double. It obviously can handle extended.
I’ve included a modified version of the vi for you to tinker with. Enter some different numbers on the front panel and see what I mean.
Regardless of all this jazz, if someone knows the real scoop on the original question, please end our suffering: Can LabVIEW display extended floating point numbers properly, or is it converting to double precision somewhere before numerals get written to the front panel indicator?
Message Edited by Root Canal on 06-09-2008 07:16 PM
global variables make robots angry
Attachments:
numerical display maxes out at double precision 21.vi ‏17 KB

Sample code converting binary data to image file

Hi experts ,
I need sample code to convert binary data (bytes) in to an image file.
any help will be appreciated.
Thanks and Regards,
Naresh

You need to show binary and decimal? Or now just decimal?
If binary and decimal, you can right click on your indicator and choose "Display Format...". If you select the Advanced Editing Mode, you can make soft interesting display formats. This includes showing the same value in mulitple ways in the indicator. Try something like "%032b - %d" for the format string.
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines

Convert Binary Data into Pdf & send it as attachment in a mail in Workflow

Hi,
Scenario:
The interactive form saved in WebDynpro Application is sent to R/3 in binary format. It has to be converted into pdf and sent it as an attachment in mail to the respective person in workflow.
Kindly help on these issues :
1. How to receive the binary data in R/3 sent by the WebDynpro Application ?
To my knowledge we can receive the binary in XSTRING data type. Plz correct me if am wrong.
2. How do i convert the received binary data into pdf ?
Thanks,
Bharath Kaushik

Hi Bharath,
I think you should try to write dat being sent to R/3 to spool first, as in R/3 there is FM <i>CONVERT_ABAPSPOOLJOB_2_PDF</i> , with the help of which you will be able to convert Binary data to PDF format.
Pls find one of the threads related to this , and see if this is useful to you.
Problem in CONVERT_ABAPSPOOLJOB_2_PDF.
Hope this atleast helps to start off.
Regds,
Akshay Bhagwat
PS: Some points would be nice if it helps:)

How to Convert Binary Data in Binary File

hi,
my telecom client puts a binary file which is asn.1 encoded with BER.
how to handle binary data in java.
how to convert binary to hexa to ascii format
how to convert binary to octet to ascii format
please help me in this.
regards,
s.mohamed asif

You don't need to convert the data.
Only you can do is print it in that formats, like it:
public static String byteArrayToHex(byte[] b) {
    StringBuffer sb = new StringBuffer();
    for (int i = 0; i < b.length; i++)
         sb.append(Integer.toHexString(b&255) + " ");
return sb.toString();
take a look at this
http://java.sun.com/docs/books/tutorial/essential/io/

FM to convert binary to image

Hi All,
Does anyone know any function module to convert 'image binary data' back to 'image' (bmp, jpeg..etc) format?
I appreciate any help.
Regards.
Edited by: mike curtis on Aug 12, 2010 9:10 PM

hello mike .
I am facing with the similar problem that u have faced . I am very happy to see that your question has been answered.
Conversion of binary data into photo in sap. the binary data is of the same type as u faced , but still i am sending the data
FFD8FFE000104A46494600010101006000600000FFDB004300080606070605080707070909080A0C140D0C0B0B0C1912130F141D1A1F1E1D1A1C1C20242E2720
this data i need to convert into image (or) photo.
could you please help me in finding the solution for it. i will be very thankful and will be waiting for ur reply.
thanks in advance.

May I get this program converted to readable in Labview 2010?

May I get the following programs converted to readable in Labview 2010? I think the real files are in Labview 2013!
Thank you
Solved!
Go to Solution.
Attachments:
Loop for RAE Read.vi ‏13 KB
Test to separate bits from Binary.vi ‏9 KB

http://forums.ni.com/t5/Version-Conversion/bd-p/VersionConversion

Converting a byte[] into a char[]

Hi All,
what's the best way to convert a byte[] into a char[]?
Any advice appreciated. Thanks in advance.

you will need a encoding schema...
byte is binary data, char is interpret from byte by the system...
easiest way without extra coding...
new String(byte[], encoding).toCharArray()
if you don't specify encoding... system default is used.

Converting a byte[] back to key problem

I CAN create a key and convert the key to a byte array, then convert the array to a string(base 64):
KeyGenerator generator = KeyGenerator.getInstance("DES");
generator.init(new SecureRandom());
key = generator.generateKey();
byte[] keyBytes = key.getEncoded;
BASE64Encoder encoder = new BASE64Encoder();
String randomKey = encoder.encode(keyBytes);
and I CAN save that string to a database, forget about it, then sometime later reload it and convert it to a byte array again:
String loadedKey = "WhAt3Ver-It-I5" //from DB
BASE64Decoder decoder = new BASE64Decoder();
byte[] loadedKeyBytes = decoder.decodeBuffer(loadedKey);
what I CAN'T do is convert the loadedKeyBytes back into the key of the same type as it was originally, enabling me to decrypt whatever that key originally encrypted.
Does anyone know.
I know I need to convert it to a KeySpec, I presume as:
DESKeySpec keySpec = new DESKeySpec(loadedKeyBytes);
this compiles correctly.... but how do i then recreate the key so i can use it for decryption.
Once i've finished this test program I should be able to port it to my application.
Many thanks in advance guys!
Cheers!
Relisys
================ CODE FOLLOWS ======================
import java.io.*;
import java.security.*;
import java.security.spec.*;
import javax.crypto.*;
import javax.crypto.spec.*;
import com.sun.crypto.provider.SunJCE;
import sun.misc.*;
public class SecPrescrip {
public static void main(String[] args) throws Exception {
// Create Key.
Key key;
KeyGenerator generator = KeyGenerator.getInstance("DES");
generator.init(new SecureRandom());
key = generator.generateKey();
// Get a cipher object
Cipher cipher = Cipher.getInstance("DES/ECB/PKCS5Padding");
// Encrypt the input string:
cipher.init(Cipher.ENCRYPT_MODE, key);
String input = "Medicare Secure Prescription: 30 Tamazopan 200mg tablets. Dosage: 1 to be taken every 4 hours";
System.out.println("Stage 1: ENCRYPT PRESCRIPTION WITH A RANDOM DES KEY");
System.out.println("===================================================");
System.out.println(" - Input Plain Text: "+input);
System.out.println("");
byte[] stringBytes = input.getBytes("UTF8");
byte[] raw = cipher.doFinal(stringBytes);
BASE64Encoder encoder = new BASE64Encoder();
String ciphertext1 = encoder.encode(raw);
System.out.println(" - Cipher Text: "+ciphertext1);
System.out.println("");
byte[] keybytes = key.getEncoded();
String randomkey = encoder.encode(keybytes);
System.out.println(" - Random Prescription Key: "+randomkey);
System.out.println("");
System.out.println("ENCRYPTION SUCESSFULL");
System.out.println("");
System.out.println("");
System.out.println("Stage 2: ENCRYPT RANDOM KEY WITH PATIENT MEDICARE KEY");
System.out.println("=====================================================");
BASE64Decoder decoder = new BASE64Decoder();
String passphrase = "ABCD1234efghIJ56"; //Patient Medicare Key
System.out.println(" - Patient Medicare Key: "+passphrase);
System.out.println("");
System.out.println(" - Input Plain Text: "+randomkey);
String algorithm = "PBEWithMD5AndDES";
byte[] salt = new byte[8];
int iteration = 20;
KeySpec ks = new PBEKeySpec(passphrase.toCharArray());
SecretKeyFactory skf = SecretKeyFactory.getInstance(algorithm);
SecretKey key2 = skf.generateSecret(ks);
byte[] input2 = decoder.decodeBuffer(randomkey);
MessageDigest md = MessageDigest.getInstance("MD5");
md.update(passphrase.getBytes());
md.update(input2);
byte[] digest = md.digest();
System.arraycopy(digest, 0, salt, 0, 8);
AlgorithmParameterSpec aps = new PBEParameterSpec(salt, iteration);
cipher = Cipher.getInstance(algorithm);
cipher.init(Cipher.ENCRYPT_MODE, key2, aps);
byte[] outputFinalKey = cipher.doFinal(input2);
String ciphertext2 = encoder.encode(outputFinalKey);
String saltString = encoder.encode(salt);
String encryptedCiphertext = saltString+ciphertext2;
System.out.println("");
System.out.println(" - Cipher Text (Final Prescription Key): "+ciphertext2);
System.out.println("");
System.out.println(" - Salt: "+saltString);
System.out.println("");
System.out.println(" - Full Encrypted Output: "+encryptedCiphertext);
System.out.println("");
System.out.println("ENCRYPTION SUCESSFULL");
System.out.println("");
System.out.println("");
System.out.println("Stage 3: DECRYPT PRESCRIPTION KEY USING PATIENT MEDICARE KEY");
System.out.println("============================================================");
//NOT CHANGED String passphrase = "ABCD1234efghIJ56";
System.out.println(" - Patient Medicare Key: "+passphrase);
System.out.println("");
System.out.println(" - Input Plain Text: "+ciphertext2);
algorithm = "PBEWithMD5AndDES";
salt = new byte[8];
iteration = 20;
ks = new PBEKeySpec(passphrase.toCharArray());
skf = SecretKeyFactory.getInstance(algorithm);
SecretKey key3 = skf.generateSecret(ks);
//Load in the input bytes as if they had been loaded from an sql database or the like
String saltIn = encryptedCiphertext.substring(0,12);
String ciphertext3 = encryptedCiphertext.substring(12,encryptedCiphertext.length());
byte[] saltArray = decoder.decodeBuffer(saltIn);
byte[] ciphertextarray = decoder.decodeBuffer(ciphertext3);
aps = new PBEParameterSpec(saltArray, iteration);
cipher = Cipher.getInstance(algorithm);
cipher.init(Cipher.DECRYPT_MODE, key3, aps);
byte[] outputKey2 = cipher.doFinal(ciphertextarray);
String plaintext2 = encoder.encode(outputKey2);
System.out.println(" - Plain Text (Random Generated Key): "+plaintext2);
System.out.println("");
System.out.println("");
System.out.println("ENCRYPTION SUCESSFULL");
System.out.println("");
System.out.println("");
System.out.println("Stage 4: DECRYPT PRESCRIPTION KEY USING PATIENT MEDICARE KEY");
System.out.println("============================================================");
// The decrypter string plaintext should be the same as the BASE64 Encoded representation of the random DES string
byte[] randomKeyFetched = decoder.decodeBuffer(plaintext2);
generator = KeyGenerator.getInstance("DES");
DESKeySpec keyspec = new DESKeySpec(randomKeyFetched);
* Stuck here! Once the key is reformed it will be complete!
}

You need to use a SecretKeyFactory to convert the byte array back to a SecretKey to use in decryption. Continuing your example:
SecretKeyFactory skf = SecretKeyFactory.getInstance("DES");
DESKeySpec desKeySpec = new DESKeySpec(loadedKeyBytes);
SecretKey sk = skf.generateSecret(desKeySpec);
Use sk in the call to the Cipher init() function. (Note that you don't call KeyGenerator to restore a key from its bytes.)
Incidently, if you're using ECB mode for encryption I don't think you need to worry about the Initialization Vector. However, if you're using CBC mode (which is the default DES mode for the default SunJCE provider), I believe you also have to make sure that the decryption system starts from the same Initialization Vector that was used for encryption. To deal with this, if 'cipher' is your encryption Cipher object, then you call
byte bytIV[] = cipher.getIV();
to get the 8-byte IV array. To decrypt, you need to call:
IvParameterSpec iv = new IvParameterSpec(bytIV);
This is an AlgorithmParameterSpec, and can be used as the third argument to the init() function for Cipher to set up decryption, e.g.
Cipher cd = Cipher.getInstance("DES/ECB/PKCS5Padding");
cd.init(Cipher.DECRYPT_MODE, sk, iv);
I believe that CBC mode is more secure than ECB mode when you have more than 8 bytes of material to encode (e.g. use "DES/CBC/PKCS5Padding"
when you create the Cipher objects).
To simplify things a bit, you might just want to use a fixed 8-byte Initialization Vector by constructing a IvParameterSpec and using it for all DES encryption and decryption.
The documentation on all of this is extraodinarily obscure.

CONVERT 4 bytes WCHAR_T in SOLARIS COMPILER TO UNSIGNED SHORTTO

All,
Do you guys know any code or function that could convert 4-bytes wchar_t string literal (Solaris defined 4 bytes for wchar_t) to array of unsigned short?

Unlike MSFT Windows VC++/C#/VB where you will get UCS-2/UTF-32 when your program has UNICODE macro defined at the start of your source program, POSIX defines wchart as an opaque data type.
Solaris is a POSIX system and thus we treat the wchar_t also as an opaque data type that can be different from one locale to another.
(We didn't have Unicode or at least it wasn't that popular when there was wchar_t data type and intefaces first created and also implemented at various Unix systems even though Sun was a founding member company of the Unicode consortium.)
We though guarantee that the wchar_t will be in UTF-32 for all Solaris Unicode/UTF-8 locales.
Hence, to have proper conversions between any codeset/codepage or the codeset of the current locale, i.e., nl_langinfo(CODESET), and UTF-32 or UCS-4, please use iconv(3C), iconv(1), or sdtconvtool(1) and such conversion interfaces. By the way, UCS-4 is being obsoleted and so using of UTF-32 is recommended.
The iconv code conversions between UTF-32 and any other codesets in Solaris will also screen out any illegal characters or byte sequences as specified in the latest Unicode Standard and UTF-8 Corrigendum at Uniocde 3.1 and 3.2.

RMA 생성시 CREDIT PRICE가 EXTENDED PRECISION이 적용되지 않는 문제

제품 : MFG_OE
작성날짜 : 2003-05-16
RMA 생성시 CREDIT PRICE가 EXTENDED PRECISION이 적용되지 않는 문제
=======================================================
PURPOSE
Original Order를 참조하여 RMA 생성시 Credit Price가 extended precision이 적용되지 않는다. 일반 user들은 이 상황을 문제로 제기하지만 이는 현재 standard function이며 11,11i 동일하게 design 되어 있다.
Explanation
Currency standard precision = 2, Extended precision = 5 로 정의되어 있
고, Prifle option-unit price precision type이 'Extended', OM(OE)에서
사용하는 price list rounding factor = -2 인 경우.
Order 생성시 selling price = 1.63200으로 입력,
이 order를 참조하여 RMA를 생성하면 Credir price = 1.63000으로 조회된다.
이 경우 대부분의 고객은 RMA credit price가 orginal order의 selling price
인 1.63200 으로 조회되는것이 맞는 function이라 생각하나, 현재 design은
extended precision 과 무관하게 사용한 price list rounding factor 값을
기준으로 credit price를 입력하고 있다.
다음은 bug 1316874에 developer가 update한 내용이며 이는 11i에서도 동일
하게 적용된다.
If Customer wants to see the price of the item up to 3 decimal place,
they should NOT make the rounding factor of the Price List -2.
Instead they should set the rounding factor as -3.
If the OE:Unit price Precision Type is EXTENDED and Extended Precision is 5, then it would be logical to set the rounding factor of Price List as -5 only, in order to avoid any rounding off.
While displaying the unit price, OE takes care of both Precision
and Price List Rounding Factor.
I checked both Sales Order form and RMA forms and the behavior is same.
Even the original price at discount screen (RMA form) also displayed
the price rounded to the price list rounding factor.
All of the fields show price in EXTENDED precision (as desired) and
round off the price to the PRICE LIST ROUNDING FACTOR (as desired).
결론적으로 OM(OE)의 보여지는 price 자리수는 extended precision을 따르지만,price의 round off는 price list rounding factor에 따라 결정된다.
Example
Reference Documents
bug 1316874

Checking and Converting binary, octal, decimal, and hex

Hi,
I have a classroom project which will need to validate that data entered in a text is of a certain type with a keyListener, and then convert that value to the other 3 types.
I know character.isDigit will handle the decimal case, and that I can then use Integer.otString methods to convert to binary, octal, and hex, but what about the other cases?
Thanks

OK, this isn't working. If I've already established
that the string entered into, for example, the
integer-only textfield is a valid integer, I should be
able to simply use integer.parseint(s, 2) to convert
it into binary, right?Not exactly. You should be able to use Integer.parseInt(s, 2) to return the result of converting it from binary representation. You appear to think that this affects whatever "s" refers to, which is not the case. Note also, that method returns an int which is the decimal value in question.
When you are thinking of int variables, be careful not to think of them as "decimal" or "binary". They are neither. They are just numbers. "Decimal" and "binary" are text representations of numbers, so those concepts can only be applied to strings.
Integer.parseInt(s, 2);
txtBin.setText(s);So here you want to assume that the input is a string that represents a number in decimal, and you want to find the string that represents the number in binary. Like this:// convert string in decimal representation to number
int dec = Integer.parseInt(s);
// convert int to binary representation as string:
String binary = Integer.toBinaryString(dec);
// write that to the text field
txtBin.setText(binary);You could use a one-liner to do that, but you'll need the "dec" variable to set the other text boxes.
Rembering why I hate OO...All of what I said there is true in just about all computer languages, OO or otherwise.
PC²

How to send IDOC with extended message type MATMAS

Hi Experts,
I am looking for a solution to send open PR & open PO related data for diffrent materials through as IDCO in XML file.
Scenario is i have to show a report in a 3rd party system for open PR & open PR that too will come after selection some materials. That means select a materials & it will show all the open PO & related data in a report.
The rough idea for the solution i got is I can save the data in XML file in the system. For this i have to send IDOC. but the problem is there is no message type for PR. IF i am not wrong i can extend the MATMAS05 for a segment that will have PR related info.
Now what to do with that how to send the IDOC do i need to create another report to send IDOC or i can send the extended one through BD10. I tried it but it shows error message "0 communication idoc sent" so I dont no y such error is coming i think i am not filling the extended idoc. But again my QUestion is how to do that.
Can i use BAPI also for such work, if then how it can be helpful.
If anyone have any other solution Please help me out of this.
Regards,
Nik

Hi Mahesh,
Thanks for your reply.
My requirement is bit different. i have to send Open PR data for diffrent materials. In a 3rd party application user will search for few materials which will generate a report that will show the PR related data for those material.
That means for few selected materials there will be few PR's which may be open, i have to show those in my report.
Eg: material A, B. are in PR 00001 & material B, C in PR 00002.
After selecting materials A to C report will show
Material                 PR No                   Item No                Quantity
A                           00001                    10                             1
B                           00001                     20                            3
B                           00002                     10                            3
C                           00002                      10                           1
Same thing i have to do for open PO & open Sales order also.
Can u please help me to provide the solution how can i proceed for it. U have given the Message type & a bapi how it will help in my issue?
I got a suggesion from someone that extend message type matmas for PR, PO, SD related data & send the idoc. but i am confused how to pass that much data ina single IDOC.
Regards,
Nik

Convert binary bytes to Labview Extended Precision type

Similar Messages

Maybe you are looking for