I did a similar deal for a company that invoices Siemens with 1,000's of invoices per month about 2 years ago. except for the fact that they are now invoicing canada and we had no plans for that, it works without a hiccup.
I don't have the code with me right now but I can get it.. basically I took the header and detail tables from the a/r system and then I had two tables I would zap every time before starting. do a do while or end scan on the a/r system and append the data to the two blank tables with some fields added to keep track of things.. then once the tables were populated, I would scan through them and write the lines out to a text file in the format they expected.. first line was the company that it was coming from and the last line was the totals of all lines lines 2 and 3 were the header and line 3 would be multiple detail lines sometimes.. Piece of cake. If memory serves me correctly at 25 per hour it cost them about 3,400 two years ago. Thought we were going to do a new rewrite recently because siemens changed to a EDI 12 (I believe it was) requirement, but apparently that fell through On 3/24/2010 3:12 PM, Kurt Wendt wrote: > Hey folks, > > > > I'd like to get people's Opinion - or a little input - on this thing I'm > trying to tackle. > > > > One of our clients has a request from their Trading partner (Burlington > Coat Factory) - having to do with sending back their EDI Invoice. What > it boils down to is this complicated issue that multiple Invoice lines > must be considered together when calculating the Dollar amounts getting > sent back via EDI. The problem is that they have these kind of > PrePacks/Assortments. And, normally - for the processing of the Invoices > - each line is considered by itself - and calculations made. > > > > So - for the changes I need to make to the Invoicing - I'm building this > Cursor which I will use for the lines that require these special > calculations for the Shipment $ amounts. The problem - is that for a > particular Sales Order (the one I am looking at) has 5717 lines. And, > they could invoice the order by specific lines, or by Stores (there are > LOTS of Stores in this particular Order), or by a group of different > styles. And, this Cursor I am using to group the Lines together for a > PrePack - I will have a flag in the Cursor Records - so that I only run > a calc once per the group - but, when the processing hits one of the > other styles for that Group - it will skip the calc and just pass back > Zero. > > > > During the invoicing - I could be hitting that Cursor A LOT - and if it > starts to get big (like, for instance - if their selection ended up > including 3000 of the original 5717 records) - I think the searches > within that Cursor may start to get slow! (At 3000 Records - I would > essentially hit that Cursor 3000 times to Search for each record - which > doesn't include when I add in the Records). And - I think this could end > up being REALLY Slow. And, I prefer to make optimized code that doesn't > slow to a crawl. > > > > So - is just searching a Cursor of 3000 records like that - would it end > up being relatively slow (especially if searched between 6000 to 9000 > times during the processing of a Single Invoice - since there are > MULTIPLE references in the existing code where the Shipment Amount for a > line must be calculated)? > > > > I guess I could create a temporary IDX file to help me Index the Cursor > (and - no - I've never done that - but, am just assuming it can be > done)! > > > > Or - should I just make this thing a Temporary DBF with a Temp Index - > and just forget the idea of a Cursor for this situation??? > > > > Sorry about the lengthy explanation - which I hope makes sense... > > > > Thanks, > > -K- > > > > Developer > > Mr. Software of East Coast, Inc. > > Division of Waitex Information System, Inc. > > > > > > --- StripMime Report -- processed MIME parts --- > multipart/alternative > text/plain (text body -- kept) > text/html > --- > [excessive quoting removed by server] _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/[email protected] ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
