What is REPTPASS used for 1

[vbajock]

Using Macola 7x, btrieve, noticed that a file called REPTPASS gets updated whenever an order changes status. Just wondering if anyone can tell me what it is doing.

 

[MacolaHelp]

The customer_bal_method is written into the order header based on the flag set in the customer master file. It is a hidden field in the order header screen & it's only valid values are O & B. Since a value was in the field that was improper, macola btrieve apparently really didn't like it & the result was loss of data in the entire file.

Why, if MSSQL is supposed to be bulletproof on referential integrity, does it not detect an invalid value in this field?

 

[vbajock]

This wasn't on the MSSQL version, it was on a PSQl platform. I don't know if MSSQL would act in the same way to this typo.

 

[MacolaHelp]

My apologies. I thought I saw a reference in this post that MSSQL behaved as you expected, but re-rereading the post, I don't find evidence that you thought MSSQL behaved as expected.

So, I would hope that both btrieve & mssql would choke on values that were non-valid in the oeordhrd file based on info provided in the arcusfil, providing referential integrity to both db managers. I don't think what you experienced is a bad thing. It identified programming enhancements that you needed to make in order for the file upload to perform correctly. As long as you don't have pp/pull item master records involved in the upload you should be fine. If you have pp.pull items, you have a lot more coding ahead of you to do this externally rather than through macola OE or EDI upload.

 

[vbajock]

pp/pull item master records ? Could you elaborate on that?

Thanks

 

[maccrystal]

PP/Pull items (Item Cat =Mfg, MFG Method =PP and Force demand =Pull in Item master) and are setup to automatically create Production orders when they are processed through order entry. This process spawns many diffent record entries or updates into the Macola database (PPORDFIL, IMLOCFIL and IMTRXFIL. This Pull order process is only triggered if the OE items, requested quantity is less than the amount available to ship. If there is quantity in stock no POP pull order is generated. The process can be more complicated if the production orders are configured to release dependant or subassembly Work orders. In effect if client has items setup this way then your application would need to generate all necessary Macola records for the down stream POP processes to work correctly. *** Cliff Notes version ***

http://www.appstratinc.com

 

[vbajock]

Thanks. Pretty much all my clients create POP orders via MRP, but this is good to know in case they don't.

 

[MacolaHelp]

I'm going back here to your question about the pre_select_status field. This appears to be a field dynamically stored that takes a snapshot of the order status prior to selection for billing (where the order status becomes 8). This way, if you unselect, it rolls back to the status the order had before you attempted to bill it out. Another hidden field on the screen that is updated in the db. It may also be a field you need to populate when appending orders. If you are bringing in the orders already selected, you might think about running some more test data through using macola's user interface to determine what the value here should be. I assume you have the file layouts for 103d & higher so you know what the field properties are for the various tables? Finding the valid values for a particular field in a particular table can be more of a challenge, but it sounds like you are at a point where this information would help you troubleshoot your hiccups faster and/or better.

 

[vbajock]

IF the order is being uploaded as selected for billing, what would be the proper value for the pre_select_status field?

 

[dgillz]

I would code this as a 4 - pick ticket printed, or a 1 - booked order.

Is the client using Confirm Ship or Confirm Pick?

Software Sales, Training, Implementation and Support for Exact Macola, eSynergy, and Crystal Reports

http://www.trianglepartners.com

 

[vbajock]

We coded it as 4.

I don't believe customer is using either Confirm Pick or Ship. Their using SAS IPS with a custom picking program. The Macola Pick tickets are sent to a PDF and deleted because they don't need the Macola tickets but they do have to run the picking program to make the orders available to IPS.

 

[vbajock]

Ok, we have all of this working great in the test company with the exception of one thing. The orders upload fine, they print&post to invoice fine, backflush Inventory fine, but when the Accounts Receivable Aging Report is run, the Apply To # is zero. When I look at hand entered orders, OEORDHDR has an apply to # field, but it is 0, and it is also 0 in OEHDRHST. We tried setting this number to the order# to get the correct apply to, but no dice. Can anyone tip me off as to what might be happening?
Thanks

 

[kscheeler]

The apply to number field on oeordhdr or orhdrhst is for credit memo's to know if they should automatically apply to an invoice in AR or not.

When you created the orders originally, did you set the ord_type to 'O', 'C' or 'I'

Do those invoices show up correctly when viewing them in Order Entry? Can you drill down from AR accounts view to the invoice in OE?

Kevin Scheeler

 

[vbajock]

Kevin, I'm just passing it Macola selected orders - they will do the invoice posting as usual in Macola.

In answer to your questions:
When you created the orders originally, did you set the ord_type to 'O', 'C' or 'I'
Type of uploaded order is O

Do those invoices show up correctly when viewing them in Order Entry?
Yes
Can you drill down from AR accounts view to the invoice in OE?
I haven't checked this, let me re-run my test.

 

[maccrystal]

The apply to number on the A/R side should be the actual invoice number that was assigned during Macola's Invoice Print. Both the DOC No and Apply to number should be the invoice number when it hits AR, unless it is a credit memo. The Apply to field should be 0 when the order is initially entered in OE unless as Kevin stated it is a Credit memo. This assumes you are configured to not to have Invoice No = Order Number.

The invoice print also changes the reference field, assigns the invoice number, billing date and status/Selection are updated. It is this information that is used to create the Doc and Apply to info on the A/R side. I could easily duplicate the "0" apply to number on the A/R aging side by clearing the Invoice number field in the OE Header, then posting. Macola posted the transaction ok with that exception. IF you are attempting to make the order ready for Post to A/R, your application will need to replicate the invoice print process including incrimenting the Invoice number in the Control file.

http://www.appstratinc.com

 

[vbajock]

maccrystal- the order is being uploaded as selected for billing. The user then handles the printing and posting of the order to AR, during which I assume the update to the control file and to AROPNFIL, etc is taking place. So the problem is, what is it about my order that is causing the Macola print process to not assign an Apply to # to the AROPNFIL record after the print and post operation is complete?

 

[maccrystal]

We have done several VB apps that are simular to this. These types of problems are usually due to incorrect Codes or how fields have been initialized(number zero verse letter O or use of <Nulls>)or conflicting status codes and field initializations. Our apps made the order appear to have been picked and selected for Billing. IT appears that the Print Invoice process is not assigning the Invoice number to the order header or possibly the details are not statused correctly. I would clear the OE Header and Detail. Key a order manually, select it for billing. The add your order throught your process and compare the respective headers and details on a field by field bases.

http://www.appstratinc.com

 

[vbajock]

We have fixed this particular problem. This customer is doing a freight pre-paid thing, and we set the prepay flag to P, but the code that entered the freight account numbers into FREIGHT_MN_ACCT, etc was still in there. We took them out and the apply to problem is now fixed. Go figure.
maccrystal, we did as you suggested when we initially wrote the app. The change to the pre-pay flag in our code took place after we had done that, so I imagine that if we had had the user enter the manual order setting pre-paid to P we would have picked up on it then.