先不废话，直接截图。呵呵~此帖借鉴了“友茗堂”的发货单

在快递单中插入一个“矩形对象”，然后可以非常方便的插入我截图中的代理，实现上海地区的邮件打印出“发件人身份证号码：3212XXX等”

需要的朋友可以试试。现在对代码进行解释：

[SFZ]

begin
SFZ1:='发件人身份证号码：32120XXX';
SFZ2:='';
SFZ:=[IF([ADOQuery1."RcvProvince"]='上海', [SFZ1], [SFZ2])] ;
end

注释部分：

[SFZ]代表一个函数，我的取名来自身份证的拼音

SFZ1和SFZ2分别代表了个判断出来的结果。1的结果是打印身份证信息为“XXX”，2个结果为不打印。当然也可以打印其他信息。呵呵。

SFZ:=[IF([ADOQuery1."RcvProvince"]='上海', [SFZ1], [SFZ2])] ;

这段代码的意思为：如果省份等于上海，则SFZ=SFZ1，如果省份不等于上海，则SFZ=SFZ2

非常的简单，大家可以举一反三，把脚本程序用到其他方面。

不错，灵活应用，基础扎实啊。

非常实用，不知道是否可以用来剔除一些指定快递不到的区域。

举个例子，我在申通快递的快递单按照以上方式设置，只要收件人地址里包含“张家口”这个词，则显示申通超区

[CQ]

begin
CQ1:='申通超区';
CQ2:='';
SFZ:=[IF([ADOQuery1."RcvProvince"]='张家口', [SFZ1], [SFZ2])] ;
end

红字部分，不知道该用什么字段来替代实现，收件人地址是什么字段 ？

红字部分的等号，应该用包含来替代，包含是用什么呢？ and ？

如果该方法可行，估计要添加很多个矩形框了。用来分别识别超区部分的地址，工作量也够大的

而且添加的矩形框多了。打印时候的反应速度会有影响不？

------该帖子于2010-8-31 16:06:57被作者编辑过------

很详细,很实用,学习了!感谢分享!

应该可以的吧，你可以试试。IF OR语句就应该可以的啊。

泰州，你那个是为世博用的，字段取错了不实用，有的时候顾客省份栏会是空的。但地址栏不会空

begin
txt_sb:='';
if pos('上海',[ADOQuery1."RcvAdr"])>0 then txt_sb:='发件人:xxxxxxxxxxx';
if pos('江苏',[ADOQuery1."RcvAdr"])>0 then txt_sb:='发件人:xxxxxxxxxxx';
if pos('浙江',[ADOQuery1."RcvAdr"])>0 then txt_sb:='发件人:xxxxxxxxxxx';
end

如果担心地址是XX省XX市上海路...上海街....上海商城。可以改为:
if copy([ADOQuery1."RcvAdr"],1,4)='上海' then

另外还有
txt_df:=''
if pos('顺丰',[ADOQuery1."PostID"])>0 then
 if [ADOQuery1."PostFee"])=0 then txt_df:='到付运费';

呵呵，可惜快递单模板老大没给留postFee字段。哈哈，慢慢的你会发现，只要老大给足字段，什么都可以是你自己定规则的。

牛。我也来学学，谢谢了。

if pos('申通',[ADOQuery1."PostID"])>0 then

 if pos('张家口',[ADOQuery1."RcvAdr"])>0 then

 begin

  messagebox('警告','脑子灌水了吧,张家口也敢发申通？');

 end;

这个就是快递超区警告提示。。

所以泰州,你原来说的商品编号的规则是核心中的核心，将成为销售规则中条件判断的依据，这也就是商品编号除了基本码还要有为了满意各项销售规则需要而设的功能码。
而报表打印中的编程在确认订单，收款发货等环节的运用，将可以完成自己对销售员，发货员，财务等环节的规则自定义。

呵呵，不过很可惜，老大认为这没必要，已经给销售员的报表打印功能关闭了，也就是说你无法在管家中给所有的销售员制定统一的内部规则。呵呵，除非你和我一样，退回0305版，你会发现确认订单环节有销售明细打印和标签打印功能。销售明细打印可作为自定义销售规则的编程，而标签打印可作为邮费计算规则编程，二者和后面发货环节的快递单打印配货单打印相呼应，可在编程方面实现发货组和销售组之间相互监督和协调。

有很多你想得到而做不到，比如限制某商品只发某地区;建立统一的优惠报表出示给顾客，以人性化的统一来应对网上没完没了的讨价还价。。。。呵呵

不会截图啊,网店管家企业版,版本:2.1 build 20100305

这个版本确认订单中有标签和列表打印按钮,通过对这2个报表编程,你可以让客服在销售准备环节就明确自定义的规则.

谢谢大家的讨论。借助于报表脚本的确可以灵活处理很多细节。对于设计业务流程的检查等，我们会通过预留sql存储过程入口的办法，给用户更加自由的空间。新版本在关键环节的处理中均有此类接口。比如订单审核时：

CREATE procedure G_OrderNextCHK(@TradeID int,@Operator varchar(20),@bResult varchar(100) output)
as
 set nocount on
 exec G_TradeCHK @TradeID,@bResult output
 if @bResult<>'1'
  return
 exec E_TradeCHK @TradeID,@bResult output --用户存储过程
 if @bResult<>'1'
  return

...

用户可以在预留存储过程 E_TradeCHK 中加入自己的处理

CREATE procedure E_TradeCHK(@TradeID int,@bResult varchar(20) output)
as
 set nocount on
 --用户定义部分
 set @bResult='1'

GO

管家的扩展需要借助于用户的力量，后面我们会做一些工作协助用户的二次开发

呵呵，看样子3.0又要重头开始学了。老大给个3.0发布时间表吧，期待多库管理，期待POS收银，期待自定义销售规则，自定义流程。期待发配货环节嵌入摄像功能，期待语音提示，期待手持盘点机，手持销售终端。。。。。。。。。。

是的啊，需要慢慢学了，我准备过些天论坛发一个帖子，说如何用盘点机盘点的。哈哈。还有盘点机的应用。

把我说成友茗堂。。。。。。